Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next

RFC 4949

Internet Security Glossary, Version 2

Pages: 365
Group: ~sec
FYI 36
Obsoletes:  2828
Part 1 of 13 – Pages 1 to 9
None   None   Next

ToP   noToC   RFC4949 - Page 1
Network Working Group                                          R. Shirey
Request for Comments: 4949                                   August 2007
FYI: 36
Obsoletes: 2828
Category: Informational

                 Internet Security Glossary, Version 2

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

RFC Editor Note

   This document is both a major revision and a major expansion of the
   Security Glossary in RFC 2828. This revised Glossary is an extensive
   reference that should help the Internet community to improve the
   clarity of documentation and discussion in an important area of
   Internet technology. However, readers should be aware of the

   (1) The recommendations and some particular interpretations in
   definitions are those of the author, not an official IETF position.
   The IETF has not taken a formal position either for or against
   recommendations made by this Glossary, and the use of RFC 2119
   language (e.g., SHOULD NOT) in the Glossary must be understood as
   unofficial. In other words, the usage rules, wording interpretations,
   and other recommendations that the Glossary offers are personal
   opinions of the Glossary's author. Readers must judge for themselves
   whether or not to follow his recommendations, based on their own
   knowledge combined with the reasoning presented in the Glossary.

   (2) The glossary is rich in the history of early network security
   work, but it may be somewhat incomplete in describing recent security
   work, which has been developing rapidly.
ToP   noToC   RFC4949 - Page 2

   This Glossary provides definitions, abbreviations, and explanations
   of terminology for information system security. The 334 pages of
   entries offer recommendations to improve the comprehensibility of
   written material that is generated in the Internet Standards Process
   (RFC 2026). The recommendations follow the principles that such
   writing should (a) use the same term or definition whenever the same
   concept is mentioned; (b) use terms in their plainest, dictionary
   sense; (c) use terms that are already well-established in open
   publications; and (d) avoid terms that either favor a particular
   vendor or favor a particular technology or mechanism over other,
   competing techniques that already exist or could be developed.

Table of Contents

   1. Introduction ....................................................3
   2. Format of Entries ...............................................4
      2.1. Order of Entries ...........................................4
      2.2. Capitalization and Abbreviations ...........................5
      2.3. Support for Automated Searching ............................5
      2.4. Definition Type and Context ................................5
      2.5. Explanatory Notes ..........................................6
      2.6. Cross-References ...........................................6
      2.7. Trademarks .................................................6
      2.8. The New Punctuation ........................................6
   3. Types of Entries ................................................7
      3.1. Type "I": Recommended Definitions of Internet Origin .......7
      3.2. Type "N": Recommended Definitions of Non-Internet Origin ...8
      3.3. Type "O": Other Terms and Definitions To Be Noted ..........8
      3.4. Type "D": Deprecated Terms and Definitions .................8
      3.5. Definition Substitutions ...................................8
   4. Definitions .....................................................9
   5. Security Considerations .......................................343
   6. Normative Reference ...........................................343
   7. Informative References ........................................343
   8. Acknowledgments ...............................................364
ToP   noToC   RFC4949 - Page 3
1. Introduction

   This Glossary is *not* an Internet Standard, and its recommendations
   represent only the opinions of its author. However, this Glossary
   gives reasons for its recommendations -- especially for the SHOULD
   NOTs -- so that readers can judge for themselves what to do.

   This Glossary provides an internally consistent and self-contained
   set of terms, abbreviations, and definitions -- supported by
   explanations, recommendations, and references -- for terminology that
   concerns information system security. The intent of this Glossary is
   to improve the comprehensibility of written materials that are
   generated in the Internet Standards Process (RFC 2026) -- i.e., RFCs,
   Internet-Drafts, and other items of discourse -- which are referred
   to here as IDOCs. A few non-security, networking terms are included
   to make the Glossary self-contained, but more complete glossaries of
   such terms are available elsewhere [A1523, F1037, R1208, R1983].

   This Glossary supports the goals of the Internet Standards Process:

   o  Clear, Concise, Easily Understood Documentation

      This Glossary seeks to improve comprehensibility of security-
      related content of IDOCs. That requires wording to be clear and
      understandable, and requires the set of security-related terms and
      definitions to be consistent and self-supporting. Also,
      terminology needs to be uniform across all IDOCs; i.e., the same
      term or definition needs to be used whenever and wherever the same
      concept is mentioned. Harmonization of existing IDOCs need not be
      done immediately, but it is desirable to correct and standardize
      terminology when new versions are issued in the normal course of
      standards development and evolution.

   o  Technical Excellence

      Just as Internet Standard (STD) protocols should operate
      effectively, IDOCs should use terminology accurately, precisely,
      and unambiguously to enable standards to be implemented correctly.

   o  Prior Implementation and Testing

      Just as STD protocols require demonstrated experience and
      stability before adoption, IDOCs need to use well-established
      language; and the robustness principle for protocols -- "be
      liberal in what you accept, and conservative in what you send" --
      is also applicable to the language used in IDOCs that describe
      protocols. Using terms in their plainest, dictionary sense (when
      appropriate) helps to make them more easily understood by
ToP   noToC   RFC4949 - Page 4
      international readers. IDOCs need to avoid using private, newly
      invented terms in place of generally accepted terms from open
      publications. IDOCs need to avoid substituting new definitions
      that conflict with established ones. IDOCs need to avoid using
      "cute" synonyms (e.g., "Green Book"), because no matter how
      popular a nickname may be in one community, it is likely to cause
      confusion in another.

      However, although this Glossary strives for plain, internationally
      understood English language, its terms and definitions are biased
      toward English as used in the United States of America (U.S.).
      Also, with regard to terminology used by national governments and
      in national defense areas, the glossary addresses only U.S. usage.

   o  Openness, Fairness, and Timeliness

      IDOCs need to avoid using proprietary and trademarked terms for
      purposes other than referring to those particular systems. IDOCs
      also need to avoid terms that either favor a particular vendor or
      favor a particular security technology or mechanism over other,
      competing techniques that already exist or might be developed in
      the future. The set of terminology used across the set of IDOCs
      needs to be flexible and adaptable as the state of Internet
      security art evolves.

   In support of those goals, this Glossary offers guidance by marking
   terms and definitions as being either endorsed or deprecated for use
   in IDOCs. The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are intended to be interpreted the same way as in an
   Internet Standard (i.e., as specified in RFC 2119 [R2119]). Other
   glossaries (e.g., [Raym]) list additional terms that deal with
   Internet security but have not been included in this Glossary because
   they are not appropriate for IDOCs.

2. Format of Entries

   Section 4 presents Glossary entries in the following manner:

2.1. Order of Entries

   Entries are sorted in lexicographic order, without regard to
   capitalization. Numeric digits are treated as preceding alphabetic
   characters, and special characters are treated as preceding digits.
   Blanks are treated as preceding non-blank characters, except that a
   hyphen or slash between the parts of a multiword entry (e.g.,
   "RED/BLACK separation") is treated like a blank.
ToP   noToC   RFC4949 - Page 5
   If an entry has multiple definitions (e.g., "domain"), they are
   numbered beginning with "1", and any of those multiple definitions
   that are RECOMMENDED for use in IDOCs are presented before other
   definitions for that entry. If definitions are closely related (e.g.,
   "threat"), they are denoted by adding letters to a number, such as
   "1a" and "1b".

2.2. Capitalization and Abbreviations

   Entries that are proper nouns are capitalized (e.g., "Data Encryption
   Algorithm"), as are other words derived from proper nouns (e.g.,
   "Caesar cipher"). All other entries are not capitalized (e.g.,
   "certification authority"). Each acronym or other abbreviation that
   appears in this Glossary, either as an entry or in a definition or
   explanation, is defined in this Glossary, except items of common
   English usage, such as "a.k.a.", "e.g.", "etc.", "i.e.", "vol.",
   "pp.", and "U.S.".

2.3. Support for Automated Searching

   Each entry is preceded by a dollar sign ($) and a space. This makes
   it possible to find the defining entry for an item "X" by searching
   for the character string "$ X", without stopping at other entries in
   which "X" is used in explanations.

2.4. Definition Type and Context

   Each entry is preceded by a character -- I, N, O, or D -- enclosed in
   parentheses, to indicate the type of definition (as is explained
   further in Section 3):
   -  "I" for a RECOMMENDED term or definition of Internet origin.
   -  "N" if RECOMMENDED but not of Internet origin.
   -  "O" for a term or definition that is NOT recommended for use in
      IDOCs but is something that authors of Internet documents should
      know about.
   -  "D" for a term or definition that is deprecated and SHOULD NOT be
      used in Internet documents.

   If a definition is valid only in a specific context (e.g.,
   "baggage"), that context is shown immediately following the
   definition type and is enclosed by a pair of slash symbols (/). If
   the definition is valid only for specific parts of speech, that is
   shown in the same way (e.g., "archive").
ToP   noToC   RFC4949 - Page 6
2.5. Explanatory Notes

   Some entries have explanatory text that is introduced by one or more
   of the following keywords:
   -  Deprecated Abbreviation (e.g., "AA")
   -  Deprecated Definition (e.g., "digital certification")
   -  Deprecated Usage (e.g., "authenticate")
   -  Deprecated Term (e.g., "certificate authority")
   -  Pronunciation (e.g., "*-property")
   -  Derivation (e.g., "discretionary access control")
   -  Tutorial (e.g., "accreditation")
   -  Example (e.g., "back door")
   -  Usage (e.g., "access")

   Explanatory text in this Glossary MAY be reused in IDOCs. However,
   this text is not intended to authoritatively supersede text of an
   IDOC in which the Glossary entry is already used.

2.6. Cross-References

   Some entries contain a parenthetical remark of the form "(See: X.)",
   where X is a list of other, related terms. Some entries contain a
   remark of the form "(Compare: X)", where X is a list of terms that
   either are antonyms of the entry or differ in some other manner worth

2.7. Trademarks

   All servicemarks and trademarks that appear in this Glossary are used
   in an editorial fashion and to the benefit of the mark owner, without
   any intention of infringement.

2.8. The New Punctuation

   This Glossary uses the "new" or "logical" punctuation style favored
   by computer programmers, as described by Raymond [Raym]: Programmers
   use pairs of quotation marks the same way they use pairs of
   parentheses, i.e., as balanced delimiters. For example, if "Alice
   sends" is a phrase, and so are "Bill receives" and "Eve listens",
   then a programmer would write the following sentence:

      "Alice sends", "Bill receives", and "Eve listens".

   According to standard American usage, the punctuation in that
   sentence is incorrect; the continuation commas and the final period
   should go inside the string quotes, like this:

      "Alice sends," "Bill receives," and "Eve listens."
ToP   noToC   RFC4949 - Page 7
   However, a programmer would not include a character in a literal
   string if the character did not belong there, because that could
   cause an error. For example, suppose a sentence in a draft of a
   tutorial on the vi editing language looked like this:

      Then delete one line from the file by typing "dd".

   A book editor following standard usage might change the sentence to
   look like this:

      Then delete one line from the file by typing "dd."

   However, in the vi language, the dot character repeats the last
   command accepted. So, if a reader entered "dd.", two lines would be
   deleted instead of one.

   Similarly, use of standard American punctuation might cause
   misunderstanding in entries in this Glossary. Thus, the new
   punctuation is used here, and we recommend it for IDOCs.

3. Types of Entries

   Each entry in this Glossary is marked as type I, N, O, or D:

3.1. Type "I": Recommended Definitions of Internet Origin

   The marking "I" indicates two things:
   -  Origin: "I" (as opposed to "N") means either that the Internet
      Standards Process or Internet community is authoritative for the
      definition *or* that the term is sufficiently generic that this
      Glossary can freely state a definition without contradicting a
      non-Internet authority (e.g., "attack").
   -  Recommendation: "I" (as opposed to "O") means that the term and
      definition are RECOMMENDED for use in IDOCs. However, some "I"
      entries may be accompanied by a "Usage" note that states a
      limitation (e.g., "certification"), and IDOCs SHOULD NOT use the
      defined term outside that limited context.

   Many "I" entries are proper nouns (e.g., "Internet Protocol") for
   which the definition is intended only to provide basic information;
   i.e., the authoritative definition of such terms is found elsewhere.
   For a proper noun described as an "Internet protocol", please refer
   to the current edition of "Internet Official Protocol Standards"
   (Standard 1) for the standardization status of the protocol.
ToP   noToC   RFC4949 - Page 8
3.2. Type "N": Recommended Definitions of Non-Internet Origin

   The marking "N" indicates two things:
   -  Origin: "N" (as opposed to "I") means that the entry has a non-
      Internet basis or origin.
   -  Recommendation: "N" (as opposed to "O") means that the term and
      definition are RECOMMENDED for use in IDOCs, if they are needed at
      all in IDOCs. Many of these entries are accompanied by a label
      that states a context (e.g., "package") or a note that states a
      limitation (e.g., "data integrity"), and IDOCs SHOULD NOT use the
      defined term outside that context or limit. Some of the contexts
      are rarely if ever expected to occur in an IDOC (e.g., "baggage").
      In those cases, the listing exists to make Internet authors aware
      of the non-Internet usage so that they can avoid conflicts with
      non-Internet documents.

3.3. Type "O": Other Terms and Definitions To Be Noted

   The marking "O" means that the definition is of non-Internet origin
   and SHOULD NOT be used in IDOCs *except* in cases where the term is
   specifically identified as non-Internet.

   For example, an IDOC might mention "BCA" (see: brand certification
   authority) or "baggage" as an example of some concept; in that case,
   the document should specifically say "SET(trademark) BCA" or
   "SET(trademark) baggage" and include the definition of the term.

3.4. Type "D": Deprecated Terms and Definitions

   If this Glossary recommends that a term or definition SHOULD NOT be
   used in IDOCs, then the entry is marked as type "D", and an
   explanatory note -- "Deprecated Term", "Deprecated Abbreviation",
   "Deprecated Definition", or "Deprecated Usage" -- is provided.

3.5. Definition Substitutions

   Some terms have a definition published by a non-Internet authority --
   a government (e.g., "object reuse"), an industry (e.g., "Secure Data
   Exchange"), a national authority (e.g., "Data Encryption Standard"),
   or an international body (e.g., "data confidentiality") -- that is
   suitable for use in IDOCs. In those cases, this Glossary marks the
   definition "N", recommending its use in Internet documents.

   Other such terms have definitions that are inadequate or
   inappropriate for IDOCs. For example, a definition might be outdated
   or too narrow, or it might need clarification by substituting more
   careful wording (e.g., "authentication exchange") or explanations,
   using other terms that are defined in this Glossary. In those cases,
ToP   noToC   RFC4949 - Page 9
   this Glossary marks the entry "O", and provides an "I" or "N" entry
   that precedes, and is intended to supersede, the "O" entry.

   In some cases where this Glossary provides a definition to supersede
   an "O" definition, the substitute is intended to subsume the meaning
   of the "O" entry and not conflict with it. For the term "security
   service", for example, the "O" definition deals narrowly with only
   communication services provided by layers in the OSIRM and is
   inadequate for the full range of IDOC usage, while the new "I"
   definition provided by this Glossary can be used in more situations
   and for more kinds of service. However, the "O" definition is also
   listed so that IDOC authors will be aware of the context in which the
   term is used more narrowly.

   When making substitutions, this Glossary attempts to avoid
   contradicting any non-Internet authority. Still, terminology differs
   between authorities such as the American Bar Association, OSI, SET,
   the U.S. DoD, and other authorities; and this Glossary probably is
   not exactly aligned with any of them.

(page 9 continued on part 2)

Next Section