Table of Contents
RFC 4949 Internet Security Glossary
Return to Security Glossary, Glossaries, RFC 6239 TOTP Time-Based One-Time Password Algorithm, Authenticator, MFA, java.net.Authenticator, Lastpass Authenticator, Microsoft Authenticator, Google Authenticator, Yubico Authenticator, Password management, Password fatigue, Authentication, Personal identification number (PIN), Password, Password manager, Single signon, MFA-2FA, Microsoft Hello, Apple Face ID, Facial recognition, Biometric authentication, Iris recognition, Retinal scan, Eye vein verification, Recognition, Fingerprint recognition
RFC 4949: #, A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z (navbar_rfc4949)
Internet Security Glossary, Version 2
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 (C) The IETF Trust (2007).
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.
RFC 4949 Internet Security Glossary, Version 2 August 2007
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; © 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.
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
RFC 4949 Internet Security Glossary, Version 2 August 2007
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.
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
RFC 4949 Internet Security Glossary, Version 2 August 2007
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.
Section 4 presents Glossary entries in the following manner:
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.
RFC 4949 Internet Security Glossary, Version 2 August 2007
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):
IDOCs but is something that authors of Internet documents should know about.
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”).
RFC 4949 Internet Security Glossary, Version 2 August 2007
2.5. Explanatory Notes
Some entries have explanatory text that is introduced by one or more of the following keywords:
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.”
RFC 4949 Internet Security Glossary, Version 2 August 2007
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.
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:
Standards Process or Internet community is authoritative for the definition
Glossary can freely state a definition without contradicting a non-Internet authority (e.g., “attack”).
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.
RFC 4949 Internet Security Glossary, Version 2 August 2007
3.2. Type “N”: Recommended Definitions of Non-Internet Origin
The marking “N” indicates two things:
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
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,
RFC 4949 Internet Security Glossary, Version 2 August 2007
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.
Request for Comments (RFC): List of RFCs, GitHub RFCs, Awesome RFCs, (navbar_rfc)
Cloud Monk is Retired (for now). Buddha with you. © 2005 - 2024 Losang Jinpa or Fair Use. Disclaimers
SYI LU SENG E MU CHYWE YE. NAN. WEI LA YE. WEI LA YE. SA WA HE.