Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 4949

Internet Security Glossary, Version 2

Pages: 365
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
   following:

   (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

Abstract

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 noting.

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