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.
Shirey Informational [Page 1]
RFC 4949 Internet Security Glossary, Version 2 August 2007
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
Shirey Informational [Page 2]
RFC 4949 Internet Security Glossary, Version 2 August 2007
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
Shirey Informational [Page 3]
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.
Shirey Informational [Page 4]
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".
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.".
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.
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").
Shirey Informational [Page 5]
RFC 4949 Internet Security Glossary, Version 2 August 2007
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.
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.
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.
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."
Shirey Informational [Page 6]
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:
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.
Shirey Informational [Page 7]
RFC 4949 Internet Security Glossary, Version 2 August 2007
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.
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.
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.
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,
Shirey Informational [Page 8]
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.
$ *-property
(N) Synonym for "confinement property" in the context of the Bell-
LaPadula model. Pronunciation: star property.
$ 3DES
(N) See: Triple Data Encryption Algorithm.
$ A1 computer system
(O) /TCSEC/ See: Tutorial under "Trusted Computer System
Evaluation Criteria". (Compare: beyond A1.)
$ AA
(D) See: Deprecated Usage under "attribute authority".
$ ABA Guidelines
(N) "American Bar Association (ABA) Digital Signature Guidelines"
[DSG], a framework of legal principles for using digital
signatures and digital certificates in electronic commerce.
$ Abstract Syntax Notation One (ASN.1)
(N) A standard for describing data objects. [Larm, X680] (See:
CMS.)
Usage: IDOCs SHOULD use the term "ASN.1" narrowly to describe the
notation or language called "Abstract Syntax Notation One". IDOCs
MAY use the term more broadly to encompass the notation, its
Shirey Informational [Page 9]
RFC 4949 Internet Security Glossary, Version 2 August 2007
associated encoding rules (see: BER), and software tools that
assist in its use, when the context makes this meaning clear.
Tutorial: OSIRM defines computer network functionality in layers.
Protocols and data objects at higher layers are abstractly defined
to be implemented using protocols and data objects from lower
layers. A higher layer may define transfers of abstract objects
between computers, and a lower layer may define those transfers
concretely as strings of bits. Syntax is needed to specify data
formats of abstract objects, and encoding rules are needed to
transform abstract objects into bit strings at lower layers. OSI
standards use ASN.1 for those specifications and use various
encoding rules for those transformations. (See: BER.)
In ASN.1, formal names are written without spaces, and separate
words in a name are indicated by capitalizing the first letter of
each word except the first word. For example, the name of a CRL is
"certificateRevocationList".
$ ACC
(I) See: access control center.
$ acceptable risk
(I) A risk that is understood and tolerated by a system's user,
operator, owner, or accreditor, usually because the cost or
difficulty of implementing an effective countermeasure for the
associated vulnerability exceeds the expectation of loss. (See:
adequate security, risk, "second law" under "Courtney's laws".)
$ access
1a. (I) The ability and means to communicate with or otherwise
interact with a system to use system resources either to handle
information or to gain knowledge of the information the system
contains. (Compare: handle.)
Usage: The definition is intended to include all types of
communication with a system, including one-way communication in
either direction. In actual practice, however, passive users might
be treated as not having "access" and, therefore, be exempt from
most requirements of the system's security policy. (See: "passive
user" under "user".)
1b. (O) "Opportunity to make use of an information system (IS)
resource." [C4009]
2. (O) /formal model/ "A specific type of interaction between a
subject and an object that results in the flow of information from
one to the other." [NCS04]
Shirey Informational [Page 10]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ Access Certificate for Electronic Services (ACES)
(O) A PKI operated by the U.S. Government's General Services
Administration in cooperation with industry partners. (See: CAM.)
$ access control
1. (I) Protection of system resources against unauthorized access.
2. (I) A process by which use of system resources is regulated
according to a security policy and is permitted only by authorized
entities (users, programs, processes, or other systems) according
to that policy. (See: access, access control service, computer
security, discretionary access control, mandatory access control,
role-based access control.)
3. (I) /formal model/ Limitations on interactions between subjects
and objects in an information system.
4. (O) "The prevention of unauthorized use of a resource,
including the prevention of use of a resource in an unauthorized
manner." [I7498-2]
5. (O) /U.S. Government/ A system using physical, electronic, or
human controls to identify or admit personnel with properly
authorized access to a SCIF.
$ access control center (ACC)
(I) A computer that maintains a database (possibly in the form of
an access control matrix) defining the security policy for an
access control service, and that acts as a server for clients
requesting access control decisions.
Tutorial: An ACC is sometimes used in conjunction with a key
center to implement access control in a key-distribution system
for symmetric cryptography. (See: BLACKER, Kerberos.)
$ access control list (ACL)
(I) /information system/ A mechanism that implements access
control for a system resource by enumerating the system entities
that are permitted to access the resource and stating, either
implicitly or explicitly, the access modes granted to each entity.
(Compare: access control matrix, access list, access profile,
capability list.)
$ access control matrix
(I) A rectangular array of cells, with one row per subject and one
column per object. The entry in a cell -- that is, the entry for a
particular subject-object pair -- indicates the access mode that
the subject is permitted to exercise on the object. Each column is
Shirey Informational [Page 11]
RFC 4949 Internet Security Glossary, Version 2 August 2007
equivalent to an "access control list" for the object; and each
row is equivalent to an "access profile" for the subject.
$ access control service
(I) A security service that protects against a system entity using
a system resource in a way not authorized by the system's security
policy. (See: access control, discretionary access control,
identity-based security policy, mandatory access control, rule-
based security policy.)
Tutorial: This service includes protecting against use of a
resource in an unauthorized manner by an entity (i.e., a
principal) that is authorized to use the resource in some other
manner. (See: insider.) The two basic mechanisms for implementing
this service are ACLs and tickets.
$ access level
1. (D) Synonym for the hierarchical "classification level" in a
security level. [C4009] (See: security level.)
2. (D) Synonym for "clearance level".
Deprecated Definitions: IDOCs SHOULD NOT use this term with these
definitions because they duplicate the meaning of more specific
terms. Any IDOC that uses this term SHOULD provide a specific
definition for it because access control may be based on many
attributes other than classification level and clearance level.
$ access list
(I) /physical security/ Roster of persons who are authorized to
enter a controlled area. (Compare: access control list.)
$ access mode
(I) A distinct type of data processing operation (e.g., read,
write, append, or execute, or a combination of operations) that a
subject can potentially perform on an object in an information
system. [Huff] (See: read, write.)
$ access policy
(I) A kind of "security policy". (See: access, access control.)
$ access profile
(O) Synonym for "capability list".
Usage: IDOCs that use this term SHOULD state a definition for it
because the definition is not widely known.
Shirey Informational [Page 12]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ access right
(I) Synonym for "authorization"; emphasizes the possession of the
authorization by a system entity.
$ accountability
(I) The property of a system or system resource that ensures that
the actions of a system entity may be traced uniquely to that
entity, which can then be held responsible for its actions. [Huff]
(See: audit service.)
Tutorial: Accountability (a.k.a. individual accountability)
typically requires a system ability to positively associate the
identity of a user with the time, method, and mode of the user's
access to the system. This ability supports detection and
subsequent investigation of security breaches. Individual persons
who are system users are held accountable for their actions after
being notified of the rules of behavior for using the system and
the penalties associated with violating those rules.
$ accounting See: COMSEC accounting.
$ accounting legend code (ALC)
(O) /U.S. Government/ Numeric system used to indicate the minimum
accounting controls required for items of COMSEC material within
the CMCS. [C4009] (See: COMSEC accounting.)
$ accreditation
(N) An administrative action by which a designated authority
declares that an information system is approved to operate in a
particular security configuration with a prescribed set of
safeguards. [FP102, SP37] (See: certification.)
Tutorial: An accreditation is usually based on a technical
certification of the system's security mechanisms. To accredit a
system, the approving authority must determine that any residual
risk is an acceptable risk. Although the terms "certification" and
"accreditation" are used more in the U.S. DoD and other U.S.
Government agencies than in commercial organizations, the concepts
apply any place where managers are required to deal with and
accept responsibility for security risks. For example, the
American Bar Association is developing accreditation criteria for
CAs.
$ accreditation boundary
(O) Synonym for "security perimeter". [C4009]
Shirey Informational [Page 13]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ accreditor
(N) A management official who has been designated to have the
formal authority to "accredit" an information system, i.e., to
authorize the operation of, and the processing of sensitive data
in, the system and to accept the residual risk associated with the
system. (See: accreditation, residual risk.)
$ ACES
(O) See: Access Certificate for Electronic Services.
$ ACL
(I) See: access control list.
$ acquirer
1. (O) /SET/ "The financial institution that establishes an
account with a merchant and processes payment card authorizations
and payments." [SET1]
2. (O) /SET/ "The institution (or its agent) that acquires from
the card acceptor the financial data relating to the transaction
and initiates that data into an interchange system." [SET2]
$ activation data
(N) Secret data, other than keys, that is required to access a
cryptographic module. (See: CIK. Compare: initialization value.)
$ active attack
(I) See: secondary definition under "attack".
$ active content
1a. (I) Executable software that is bound to a document or other
data file and that executes automatically when a user accesses the
file, without explicit initiation by the user. (Compare: mobile
code.)
Tutorial: Active content can be mobile code when its associated
file is transferred across a network.
1b. (O) "Electronic documents that can carry out or trigger
actions automatically on a computer platform without the
intervention of a user. [This technology enables] mobile code
associated with a document to execute as the document is
rendered." [SP28]
$ active user
(I) See: secondary definition under "system user".
Shirey Informational [Page 14]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ active wiretapping
(I) A wiretapping attack that attempts to alter data being
communicated or otherwise affect data flow. (See: wiretapping.
Compare: active attack, passive wiretapping.)
$ add-on security
(N) The retrofitting of protection mechanisms, implemented by
hardware or software, in an information system after the system
has become operational. [FP039] (Compare: baked-in security.)
$ adequate security
(O) /U.S. DoD/ "Security commensurate with the risk and magnitude
of harm resulting from the loss, misuse, or unauthorized access to
or modification of information." (See: acceptable risk, residual
risk.)
$ administrative security
1. (I) Management procedures and constraints to prevent
unauthorized access to a system. (See: "third law" under
"Courtney's laws", manager, operational security, procedural
security, security architecture. Compare: technical security.)
Examples: Clear delineation and separation of duties;
configuration control.
Usage: Administrative security is usually understood to consist of
methods and mechanisms that are implemented and executed primarily
by people, rather than by automated systems.
2. (O) "The management constraints, operational procedures,
accountability procedures, and supplemental controls established
to provide an acceptable level of protection for sensitive data."
[FP039]
$ administrator
1. (O) /Common Criteria/ A person that is responsible for
configuring, maintaining, and administering the TOE in a correct
manner for maximum security. (See: administrative security.)
2. (O) /ITSEC/ A person in contact with the TOE, who is
responsible for maintaining its operational capability.
$ Advanced Encryption Standard (AES)
(N) A U.S. Government standard [FP197] (the successor to DES) that
(a) specifies "the AES algorithm", which is a symmetric block
cipher that is based on Rijndael and uses key sizes of 128, 192,
or 256 bits to operate on a 128-bit block, and (b) states policy
for using that algorithm to protect unclassified, sensitive data.
Shirey Informational [Page 15]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: Rijndael was designed to handle additional block sizes
and key lengths that were not adopted in the AES. Rijndael was
selected by NIST through a public competition that was held to
find a successor to the DEA; the other finalists were MARS, RC6,
Serpent, and Twofish.
$ adversary
1. (I) An entity that attacks a system. (Compare: cracker,
intruder, hacker.)
2. (I) An entity that is a threat to a system.
$ AES
(N) See: Advanced Encryption Standard.
$ Affirm
(O) A formal methodology, language, and integrated set of software
tools developed at the University of Southern California's
Information Sciences Institute for specifying, coding, and
verifying software to produce correct and reliable programs.
[Cheh]
$ aggregation
(I) A circumstance in which a collection of information items is
required to be classified at a higher security level than any of
the items is classified individually. (See: classification.)
$ AH
(I) See: Authentication Header
$ air gap
(I) An interface between two systems at which (a) they are not
connected physically and (b) any logical connection is not
automated (i.e., data is transferred through the interface only
manually, under human control). (See: sneaker net. Compare:
gateway.)
Example: Computer A and computer B are on opposite sides of a
room. To move data from A to B, a person carries a disk across the
room. If A and B operate in different security domains, then
moving data across the air gap may involve an upgrade or downgrade
operation.
$ ALC
(O) See: accounting legend code.
Shirey Informational [Page 16]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ algorithm
(I) A finite set of step-by-step instructions for a problem-
solving or computation procedure, especially one that can be
implemented by a computer. (See: cryptographic algorithm.)
$ alias
(I) A name that an entity uses in place of its real name, usually
for the purpose of either anonymity or masquerade.
$ Alice and Bob
(I) The parties that are most often called upon to illustrate the
operation of bipartite security protocols. These and other
dramatis personae are listed by Schneier [Schn].
$ American National Standards Institute (ANSI)
(N) A private, not-for-profit association that administers U.S.
private-sector voluntary standards.
Tutorial: ANSI has approximately 1,000 member organizations,
including equipment users, manufacturers, and others. These
include commercial firms, governmental agencies, and other
institutions and international entities.
ANSI is the sole U.S. representative to (a) ISO and (b) (via the
U.S. National Committee) the International Electrotechnical
Commission (IEC), which are the two major, non-treaty,
international standards organizations.
ANSI provides a forum for ANSI-accredited standards development
groups. Among those groups, the following are especially relevant
to Internet security:
- International Committee for Information Technology
Standardization (INCITS) (formerly X3): Primary U.S. focus of
standardization in information and communications technologies,
encompassing storage, processing, transfer, display,
management, organization, and retrieval of information.
Example: [A3092].
- Accredited Standards Committee X9: Develops, establishes,
maintains, and promotes standards for the financial services
industry. Example: [A9009].
- Alliance for Telecommunications Industry Solutions (ATIS):
Develops standards, specifications, guidelines, requirements,
technical reports, industry processes, and verification tests
for interoperability and reliability of telecommunications
networks, equipment, and software. Example: [A1523].
Shirey Informational [Page 17]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ American Standard Code for Information Interchange (ASCII)
(N) A scheme that encodes 128 specified characters -- the numbers
0-9, the letters a-z and A-Z, some basic punctuation symbols, some
control codes that originated with Teletype machines, and a blank
space -- into the 7-bit binary integers. Forms the basis of the
character set representations used in most computers and many
Internet standards. [FP001] (See: code.)
$ Anderson report
(O) A 1972 study of computer security that was written by James P.
Anderson for the U.S. Air Force [Ande].
Tutorial: Anderson collaborated with a panel of experts to study
Air Force requirements for multilevel security. The study
recommended research and development that was urgently needed to
provide secure information processing for command and control
systems and support systems. The report introduced the reference
monitor concept and provided development impetus for computer and
network security technology. However, many of the security
problems that the 1972 report called "current" still plague
information systems today.
$ anomaly detection
(I) An intrusion detection method that searches for activity that
is different from the normal behavior of system entities and
system resources. (See: IDS. Compare: misuse detection.)
$ anonymity
(I) The condition of an identity being unknown or concealed. (See:
alias, anonymizer, anonymous credential, anonymous login,
identity, onion routing, persona certificate. Compare: privacy.)
Tutorial: An application may require security services that
maintain anonymity of users or other system entities, perhaps to
preserve their privacy or hide them from attack. To hide an
entity's real name, an alias may be used; for example, a financial
institution may assign account numbers. Parties to transactions
can thus remain relatively anonymous, but can also accept the
transactions as legitimate. Real names of the parties cannot be
easily determined by observers of the transactions, but an
authorized third party may be able to map an alias to a real name,
such as by presenting the institution with a court order. In other
applications, anonymous entities may be completely untraceable.
$ anonymizer
(I) An internetwork service, usually provided via a proxy server,
that provides anonymity and privacy for clients. That is, the
service enables a client to access servers (a) without allowing
Shirey Informational [Page 18]
RFC 4949 Internet Security Glossary, Version 2 August 2007
anyone to gather information about which servers the client
accesses and (b) without allowing the accessed servers to gather
information about the client, such as its IP address.
$ anonymous credential
(D) /U.S. Government/ A credential that (a) can be used to
authenticate a person as having a specific attribute or being a
member of a specific group (e.g., military veterans or U.S.
citizens) but (b) does not reveal the individual identity of the
person that presents the credential. [M0404] (See: anonymity.)
Deprecated Term: IDOCs SHOULD NOT use this term; it mixes concepts
in a potentially misleading way. For example, when the credential
is an X.509 certificate, the term could be misunderstood to mean
that the certificate was signed by a CA that has a persona
certificate. Instead, use "attribute certificate", "organizational
certificate", or "persona certificate" depending on what is meant,
and provide additional explanations as needed.
$ anonymous login
(I) An access control feature (actually, an access control
vulnerability) in many Internet hosts that enables users to gain
access to general-purpose or public services and resources of a
host (such as allowing any user to transfer data using FTP)
without having a pre-established, identity-specific account (i.e.,
user name and password). (See: anonymity.)
Tutorial: This feature exposes a system to more threats than when
all the users are known, pre-registered entities that are
individually accountable for their actions. A user logs in using a
special, publicly known user name (e.g., "anonymous", "guest", or
"ftp"). To use the public login name, the user is not required to
know a secret password and may not be required to input anything
at all except the name. In other cases, to complete the normal
sequence of steps in a login protocol, the system may require the
user to input a matching, publicly known password (such as
"anonymous") or may ask the user for an e-mail address or some
other arbitrary character string.
$ ANSI
(N) See: American National Standards Institute.
$ anti-jam
(N) "Measures ensuring that transmitted information can be
received despite deliberate jamming attempts." [C4009] (See:
electronic security, frequency hopping, jam, spread spectrum.)
Shirey Informational [Page 19]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ apex trust anchor
(N) The trust anchor that is superior to all other trust anchors
in a particular system or context. (See: trust anchor, top CA.)
$ API
(I) See: application programming interface.
$ APOP
(I) See: POP3 APOP.
$ Application Layer
See: Internet Protocol Suite, OSIRM.
$ application program
(I) A computer program that performs a specific function directly
for a user (as opposed to a program that is part of a computer
operating system and exists to perform functions in support of
application programs).
$ architecture
(I) See: security architecture, system architecture.
$ archive
1a. (I) /noun/ A collection of data that is stored for a
relatively long period of time for historical and other purposes,
such as to support audit service, availability service, or system
integrity service. (Compare: backup, repository.)
1b. (I) /verb/ To store data in such a way as to create an
archive. (Compare: back up.)
Tutorial: A digital signature may need to be verified many years
after the signing occurs. The CA -- the one that issued the
certificate containing the public key needed to verify that
signature -- may not stay in operation that long. So every CA
needs to provide for long-term storage of the information needed
to verify the signatures of those to whom it issues certificates.
$ ARPANET
(I) Advanced Research Projects Agency (ARPA) Network, a pioneer
packet-switched network that (a) was designed, implemented,
operated, and maintained by BBN from January 1969 until July 1975
under contract to the U.S. Government; (b) led to the development
of today's Internet; and (c) was decommissioned in June 1990.
[B4799, Hafn]
$ ASCII
(N) See: American Standard Code for Information Interchange.
Shirey Informational [Page 20]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ ASN.1
(N) See: Abstract Syntax Notation One.
$ asset
(I) A system resource that is (a) required to be protected by an
information system's security policy, (b) intended to be protected
by a countermeasure, or (c) required for a system's mission.
$ association
(I) A cooperative relationship between system entities, usually
for the purpose of transferring information between them. (See:
security association.)
$ assurance See: security assurance.
$ assurance level
(N) A rank on a hierarchical scale that judges the confidence
someone can have that a TOE adequately fulfills stated security
requirements. (See: assurance, certificate policy, EAL, TCSEC.)
Example: U.S. Government guidance [M0404] describes four assurance
levels for identity authentication, where each level "describes
the [U.S. Federal Government] agency's degree of certainty that
the user has presented [a credential] that refers to [the user's]
identity." In that guidance, assurance is defined as (a) "the
degree of confidence in the vetting process used to establish the
identity of the individual to whom the credential was issued" and
(b) "the degree of confidence that the individual who uses the
credential is the individual to whom the credential was issued."
The four levels are described as follows:
- Level 1: Little or no confidence in the asserted identity.
- Level 2: Some confidence in the asserted identity.
- Level 3: High confidence in the asserted identity.
- Level 4: Very high confidence in the asserted identity.
Standards for determining these levels are provided in a NIST
publication [SP12]. However, as noted there, an assurance level is
"a degree of confidence, not a true measure of how secure the
system actually is. This distinction is necessary because it is
extremely difficult -- and in many cases, virtually impossible --
to know exactly how secure a system is."
$ asymmetric cryptography
(I) A modern branch of cryptography (popularly known as "public-
key cryptography") in which the algorithms use a pair of keys (a
public key and a private key) and use a different component of the
pair for each of two counterpart cryptographic operations (e.g.,
Shirey Informational [Page 21]
RFC 4949 Internet Security Glossary, Version 2 August 2007
encryption and decryption, or signature creation and signature
verification). (See: key pair, symmetric cryptography.)
Tutorial: Asymmetric algorithms have key management advantages
over equivalently strong symmetric ones. First, one key of the
pair need not be known by anyone but its owner; so it can more
easily be kept secret. Second, although the other key is shared by
all entities that use the algorithm, that key need not be kept
secret from other, non-using entities; thus, the key-distribution
part of key management can be done more easily.
Asymmetric cryptography can be used to create algorithms for
encryption, digital signature, and key agreement:
- In an asymmetric encryption algorithm (e.g., "RSA"), when Alice
wants to ensure confidentiality for data she sends to Bob, she
encrypts the data with a public key provided by Bob. Only Bob
has the matching private key that is needed to decrypt the
data. (Compare: seal.)
- In an asymmetric digital signature algorithm (e.g., "DSA"),
when Alice wants to ensure data integrity or provide
authentication for data she sends to Bob, she uses her private
key to sign the data (i.e., create a digital signature based on
the data). To verify the signature, Bob uses the matching
public key that Alice has provided.
- In an asymmetric key-agreement algorithm (e.g., "Diffie-
Hellman-Merkle"), Alice and Bob each send their own public key
to the other party. Then each uses their own private key and
the other's public key to compute the new key value.
$ asymmetric key
(I) A cryptographic key that is used in an asymmetric
cryptographic algorithm. (See: asymmetric cryptography, private
key, public key.)
$ ATIS
(N) See: "Alliance for Telecommunications Industry Solutions"
under "ANSI".
$ attack
1. (I) An intentional act by which an entity attempts to evade
security services and violate the security policy of a system.
That is, an actual assault on system security that derives from an
intelligent threat. (See: penetration, violation, vulnerability.)
2. (I) A method or technique used in an assault (e.g.,
masquerade). (See: blind attack, distributed attack.)
Shirey Informational [Page 22]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: Attacks can be characterized according to intent:
- An "active attack" attempts to alter system resources or affect
their operation.
- A "passive attack" attempts to learn or make use of information
from a system but does not affect system resources of that
system. (See: wiretapping.)
The object of a passive attack might be to obtain data that is
needed for an off-line attack.
- An "off-line attack" is one in which the attacker obtains data
from the target system and then analyzes the data on a
different system of the attacker's own choosing, possibly in
preparation for a second stage of attack on the target.
Attacks can be characterized according to point of initiation:
- An "inside attack" is one that is initiated by an entity inside
the security perimeter (an "insider"), i.e., an entity that is
authorized to access system resources but uses them in a way
not approved by the party that granted the authorization.
- An "outside attack" is initiated from outside the security
perimeter, by an unauthorized or illegitimate user of the
system (an "outsider"). In the Internet, potential outside
attackers range from amateur pranksters to organized criminals,
international terrorists, and hostile governments.
Attacks can be characterized according to method of delivery:
- In a "direct attack", the attacker addresses attacking packets
to the intended victim(s).
- In an "indirect attack", the attacker addresses packets to a
third party, and the packets either have the address(es) of the
intended victim(s) as their source address(es) or indicate the
intended victim(s) in some other way. The third party responds
by sending one or more attacking packets to the intended
victims. The attacker can use third parties as attack
amplifiers by providing a broadcast address as the victim
address (e.g., "smurf attack"). (See: reflector attack.
Compare: reflection attack, replay attack.)
Shirey Informational [Page 23]
RFC 4949 Internet Security Glossary, Version 2 August 2007
The term "attack" relates to some other basic security terms as
shown in the following diagram:
+ - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+
| An Attack: | |Counter- | | A System Resource: |
| i.e., A Threat Action | | measure | | Target of the Attack |
| +----------+ | | | | +-----------------+ |
| | Attacker |<==================||<========= | |
| | i.e., | Passive | | | | | Vulnerability | |
| | A Threat |<=================>||<========> | |
| | Agent | or Active | | | | +-------|||-------+ |
| +----------+ Attack | | | | VVV |
| | | | | Threat Consequences |
+ - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+
$ attack potential
(I) The perceived likelihood of success should an attack be
launched, expressed in terms of the attacker's ability (i.e.,
expertise and resources) and motivation. (Compare: threat, risk.)
$ attack sensing, warning, and response
(I) A set of security services that cooperate with audit service
to detect and react to indications of threat actions, including
both inside and outside attacks. (See: indicator.)
$ attack tree
(I) A branching, hierarchical data structure that represents a set
of potential approaches to achieving an event in which system
security is penetrated or compromised in a specified way. [Moor]
Tutorial: Attack trees are special cases of fault trees. The
security incident that is the goal of the attack is represented as
the root node of the tree, and the ways that an attacker could
reach that goal are iteratively and incrementally represented as
branches and subnodes of the tree. Each subnode defines a subgoal,
and each subgoal may have its own set of further subgoals, etc.
The final nodes on the paths outward from the root, i.e., the leaf
nodes, represent different ways to initiate an attack. Each node
other than a leaf is either an AND-node or an OR-node. To achieve
the goal represented by an AND-node, the subgoals represented by
all of that node's subnodes must be achieved; and for an OR-node,
at least one of the subgoals must be achieved. Branches can be
labeled with values representing difficulty, cost, or other attack
attributes, so that alternative attacks can be compared.
Shirey Informational [Page 24]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ attribute
(N) Information of a particular type concerning an identifiable
system entity or object. An "attribute type" is the component of
an attribute that indicates the class of information given by the
attribute; and an "attribute value" is a particular instance of
the class of information indicated by an attribute type. (See:
attribute certificate.)
$ attribute authority (AA)
1. (N) A CA that issues attribute certificates.
2. (O) "An authority [that] assigns privileges by issuing
attribute certificates." [X509]
Deprecated Usage: The abbreviation "AA" SHOULD NOT be used in an
IDOC unless it is first defined in the IDOC.
$ attribute certificate
1. (I) A digital certificate that binds a set of descriptive data
items, other than a public key, either directly to a subject name
or to the identifier of another certificate that is a public-key
certificate. (See: capability token.)
2. (O) "A data structure, digitally signed by an [a]ttribute
[a]uthority, that binds some attribute values with identification
information about its holder." [X509]
Tutorial: A public-key certificate binds a subject name to a
public key value, along with information needed to perform certain
cryptographic functions using that key. Other attributes of a
subject, such as a security clearance, may be certified in a
separate kind of digital certificate, called an attribute
certificate. A subject may have multiple attribute certificates
associated with its name or with each of its public-key
certificates.
An attribute certificate might be issued to a subject in the
following situations:
- Different lifetimes: When the lifetime of an attribute binding
is shorter than that of the related public-key certificate, or
when it is desirable not to need to revoke a subject's public
key just to revoke an attribute.
- Different authorities: When the authority responsible for the
attributes is different than the one that issues the public-key
certificate for the subject. (There is no requirement that an
attribute certificate be issued by the same CA that issued the
associated public-key certificate.)
Shirey Informational [Page 25]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ audit
See: security audit.
$ audit log
(I) Synonym for "security audit trail".
$ audit service
(I) A security service that records information needed to
establish accountability for system events and for the actions of
system entities that cause them. (See: security audit.)
$ audit trail
(I) See: security audit trail.
$ AUTH
(I) See: POP3 AUTH.
$ authenticate
(I) Verify (i.e., establish the truth of) an attribute value
claimed by or for a system entity or system resource. (See:
authentication, validate vs. verify, "relationship between data
integrity service and authentication services" under "data
integrity service".)
Deprecated Usage: In general English usage, this term is used with
the meaning "to prove genuine" (e.g., an art expert authenticates
a Michelangelo painting); but IDOCs should restrict usage as
follows:
- IDOCs SHOULD NOT use this term to refer to proving or checking
that data has not been changed, destroyed, or lost in an
unauthorized or accidental manner. Instead, use "verify".
- IDOCs SHOULD NOT use this term to refer to proving the truth or
accuracy of a fact or value such as a digital signature.
Instead, use "verify".
- IDOCs SHOULD NOT use this term to refer to establishing the
soundness or correctness of a construct, such as a digital
certificate. Instead, use "validate".
$ authentication
(I) The process of verifying a claim that a system entity or
system resource has a certain attribute value. (See: attribute,
authenticate, authentication exchange, authentication information,
credential, data origin authentication, peer entity
authentication, "relationship between data integrity service and
authentication services" under "data integrity service", simple
authentication, strong authentication, verification, X.509.)
Shirey Informational [Page 26]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: Security services frequently depend on authentication of
the identity of users, but authentication may involve any type of
attribute that is recognized by a system. A claim may be made by a
subject about itself (e.g., at login, a user typically asserts its
identity) or a claim may be made on behalf of a subject or object
by some other system entity (e.g., a user may claim that a data
object originates from a specific source, or that a data object is
classified at a specific security level).
An authentication process consists of two basic steps:
- Identification step: Presenting the claimed attribute value
(e.g., a user identifier) to the authentication subsystem.
- Verification step: Presenting or generating authentication
information (e.g., a value signed with a private key) that acts
as evidence to prove the binding between the attribute and that
for which it is claimed. (See: verification.)
$ authentication code
(D) Synonym for a checksum based on cryptography. (Compare: Data
Authentication Code, Message Authentication Code.)
Deprecated Term: IDOCs SHOULD NOT use this uncapitalized term as a
synonym for any kind of checksum, regardless of whether or not the
checksum is cryptographic. Instead, use "checksum", "Data
Authentication Code", "error detection code", "hash", "keyed
hash", "Message Authentication Code", "protected checksum", or
some other recommended term, depending on what is meant.
The term mixes concepts in a potentially misleading way. The word
"authentication" is misleading because the checksum may be used to
perform a data integrity function rather than a data origin
authentication function.
$ authentication exchange
1. (I) A mechanism to verify the identity of an entity by means of
information exchange.
2. (O) "A mechanism intended to ensure the identity of an entity
by means of information exchange." [I7498-2]
$ Authentication Header (AH)
(I) An Internet protocol [R2402, R4302] designed to provide
connectionless data integrity service and connectionless data
origin authentication service for IP datagrams, and (optionally)
to provide partial sequence integrity and protection against
replay attacks. (See: IPsec. Compare: ESP.)
Shirey Informational [Page 27]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: Replay protection may be selected by the receiver when a
security association is established. AH authenticates the upper-
layer PDU that is carried as an IP SDU, and also authenticates as
much of the IP PCI (i.e., the IP header) as possible. However,
some IP header fields may change in transit, and the value of
these fields, when the packet arrives at the receiver, may not be
predictable by the sender. Thus, the values of such fields cannot
be protected end-to-end by AH; protection of the IP header by AH
is only partial when such fields are present.
AH may be used alone, or in combination with the ESP, or in a
nested fashion with tunneling. Security services can be provided
between a pair of communicating hosts, between a pair of
communicating security gateways, or between a host and a gateway.
ESP can provide nearly the same security services as AH, and ESP
can also provide data confidentiality service. The main difference
between authentication services provided by ESP and AH is the
extent of the coverage; ESP does not protect IP header fields
unless they are encapsulated by AH.
$ authentication information
(I) Information used to verify an identity claimed by or for an
entity. (See: authentication, credential, user. Compare:
identification information.)
Tutorial: Authentication information may exist as, or be derived
from, one of the following: (a) Something the entity knows (see:
password); (b) something the entity possesses (see: token); (c)
something the entity is (see: biometric authentication).
$ authentication service
(I) A security service that verifies an identity claimed by or for
an entity. (See: authentication.)
Tutorial: In a network, there are two general forms of
authentication service: data origin authentication service and
peer entity authentication service.
$ authenticity
(I) The property of being genuine and able to be verified and be
trusted. (See: authenticate, authentication, validate vs. verify.)
$ authority
(D) /PKI/ "An entity [that is] responsible for the issuance of
certificates." [X509]
Shirey Informational [Page 28]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Deprecated Usage: IDOCs SHOULD NOT use this term as a synonym for
attribute authority, certification authority, registration
authority, or similar terms; the shortened form may cause
confusion. Instead, use the full term at the first instance of
usage and then, if it is necessary to shorten text, use AA, CA,
RA, and other abbreviations defined in this Glossary.
$ authority certificate
(D) "A certificate issued to an authority (e.g. either to a
certification authority or to an attribute authority)." [X509]
(See: authority.)
Deprecated Term: IDOCs SHOULD NOT use this term because it is
ambiguous. Instead, use the full term "certification authority
certificate", "attribute authority certificate", "registration
authority certificate", etc. at the first instance of usage and
then, if it is necessary to shorten text, use AA, CA, RA, and
other abbreviations defined in this Glossary.
$ Authority Information Access extension
(I) The private extension defined by PKIX for X.509 certificates
to indicate "how to access CA information and services for the
issuer of the certificate in which the extension appears.
Information and services may include on-line validation services
and CA policy data." [R3280] (See: private extension.)
$ authorization
1a. (I) An approval that is granted to a system entity to access a
system resource. (Compare: permission, privilege.)
Usage: Some synonyms are "permission" and "privilege". Specific
terms are preferred in certain contexts:
- /PKI/ "Authorization" SHOULD be used, to align with
"certification authority" in the standard [X509].
- /role-based access control/ "Permission" SHOULD be used, to
align with the standard [ANSI].
- /computer operating systems/ "Privilege" SHOULD be used, to
align with the literature. (See: privileged process, privileged
user.)
Tutorial: The semantics and granularity of authorizations depend
on the application and implementation (see: "first law" under
"Courtney's laws"). An authorization may specify a particular
access mode -- such as read, write, or execute -- for one or more
system resources.
1b. (I) A process for granting approval to a system entity to
access a system resource.
Shirey Informational [Page 29]
RFC 4949 Internet Security Glossary, Version 2 August 2007
2. (O) /SET/ "The process by which a properly appointed person or
persons grants permission to perform some action on behalf of an
organization. This process assesses transaction risk, confirms
that a given transaction does not raise the account holder's debt
above the account's credit limit, and reserves the specified
amount of credit. (When a merchant obtains authorization, payment
for the authorized amount is guaranteed -- provided, of course,
that the merchant followed the rules associated with the
authorization process.)" [SET2]
$ authorization credential
(I) See: /access control/ under "credential".
$ authorize
(I) Grant an authorization to a system entity.
$ authorized user
(I) /access control/ A system entity that accesses a system
resource for which the entity has received an authorization.
(Compare: insider, outsider, unauthorized user.)
Deprecated Usage: IDOCs that use this term SHOULD state a
definition for it because the term is used in many ways and could
easily be misunderstood.
$ automated information system
See: information system.
$ availability
1. (I) The property of a system or a system resource being
accessible, or usable or operational upon demand, by an authorized
system entity, according to performance specifications for the
system; i.e., a system is available if it provides services
according to the system design whenever users request them. (See:
critical, denial of service. Compare: precedence, reliability,
survivability.)
2. (O) "The property of being accessible and usable upon demand by
an authorized entity." [I7498-2]
3. (D) "Timely, reliable access to data and information services
for authorized users." [C4009]
Deprecated Definition: IDOCs SHOULD NOT use the term with
definition 3; the definition mixes "availability" with
"reliability", which is a different property. (See: reliability.)
Shirey Informational [Page 30]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: Availability requirements can be specified by
quantitative metrics, but sometimes are stated qualitatively, such
as in the following:
- "Flexible tolerance for delay" may mean that brief system
outages do not endanger mission accomplishment, but extended
outages may endanger the mission.
- "Minimum tolerance for delay" may mean that mission
accomplishment requires the system to provide requested
services in a short time.
$ availability service
(I) A security service that protects a system to ensure its
availability.
Tutorial: This service addresses the security concerns raised by
denial-of-service attacks. It depends on proper management and
control of system resources, and thus depends on access control
service and other security services.
$ avoidance
(I) See: secondary definition under "security".
$ B1, B2, or B3 computer system
(O) /TCSEC/ See: Tutorial under "Trusted Computer System
Evaluation Criteria".
$ back door
1. (I) /COMPUSEC/ A computer system feature -- which may be (a) an
unintentional flaw, (b) a mechanism deliberately installed by the
system's creator, or (c) a mechanism surreptitiously installed by
an intruder -- that provides access to a system resource by other
than the usual procedure and usually is hidden or otherwise not
well-known. (See: maintenance hook. Compare: Trojan Horse.)
Example: A way to access a computer other than through a normal
login. Such an access path is not necessarily designed with
malicious intent; operating systems sometimes are shipped by the
manufacturer with hidden accounts intended for use by field
service technicians or the vendor's maintenance programmers.
2. (I) /cryptography/ A feature of a cryptographic system that
makes it easily possible to break or circumvent the protection
that the system is designed to provide.
Example: A feature that makes it possible to decrypt cipher text
much more quickly than by brute-force cryptanalysis, without
having prior knowledge of the decryption key.
Shirey Informational [Page 31]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ back up
(I) /verb/ Create a reserve copy of data or, more generally,
provide alternate means to perform system functions despite loss
of system resources. (See: contingency plan. Compare: archive.)
$ backup
(I) /noun or adjective/ Refers to alternate means of performing
system functions despite loss of system resources. (See:
contingency plan).
Example: A reserve copy of data, preferably one that is stored
separately from the original, for use if the original becomes lost
or damaged. (Compare: archive.)
$ bagbiter
(D) /slang/ "An entity, such as a program or a computer, that
fails to work or that works in a remarkably clumsy manner. A
person who has caused some trouble, inadvertently or otherwise,
typically by failing to program the computer properly." [NCSSG]
(See: flaw.)
Deprecated Term: It is likely that other cultures use different
metaphors for these concepts. Therefore, to avoid international
misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated
Usage under "Green Book".)
$ baggage
(O) /SET/ An "opaque encrypted tuple, which is included in a SET
message but appended as external data to the PKCS encapsulated
data. This avoids superencryption of the previously encrypted
tuple, but guarantees linkage with the PKCS portion of the
message." [SET2]
Deprecated Usage: IDOCs SHOULD NOT use this term to describe a
data element, except in the form "SET(trademark) baggage" with the
meaning given above.
$ baked-in security
(D) The inclusion of security mechanisms in an information system
beginning at an early point in the system's lifecycle, i.e.,
during the design phase, or at least early in the implementation
phase. (Compare: add-on security.)
Deprecated Term: It is likely that other cultures use different
metaphors for this concept. Therefore, to avoid international
misunderstanding, IDOCs SHOULD NOT use this term (unless they also
provide a definition like this one). (See: Deprecated Usage under
"Green Book".)
Shirey Informational [Page 32]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ bandwidth
(I) The total width of the frequency band that is available to or
used by a communication channel; usually expressed in Hertz (Hz).
(RFC 3753) (Compare: channel capacity.)
$ bank identification number (BIN)
1. (O) The digits of a credit card number that identify the
issuing bank. (See: primary account number.)
2. (O) /SET/ The first six digits of a primary account number.
$ Basic Encoding Rules (BER)
(I) A standard for representing ASN.1 data types as strings of
octets. [X690] (See: Distinguished Encoding Rules.)
Deprecated Usage: Sometimes incorrectly treated as part of ASN.1.
However, ASN.1 properly refers only to a syntax description
language, and not to the encoding rules for the language.
$ Basic Security Option
(I) See: secondary definition under "IPSO".
$ bastion host
(I) A strongly protected computer that is in a network protected
by a firewall (or is part of a firewall) and is the only host (or
one of only a few) in the network that can be directly accessed
from networks on the other side of the firewall. (See: firewall.)
Tutorial: Filtering routers in a firewall typically restrict
traffic from the outside network to reaching just one host, the
bastion host, which usually is part of the firewall. Since only
this one host can be directly attacked, only this one host needs
to be very strongly protected, so security can be maintained more
easily and less expensively. However, to allow legitimate internal
and external users to access application resources through the
firewall, higher-layer protocols and services need to be relayed
and forwarded by the bastion host. Some services (e.g., DNS and
SMTP) have forwarding built in; other services (e.g., TELNET and
FTP) require a proxy server on the bastion host.
$ BBN Technologies Corp. (BBN)
(O) The research-and-development company (originally called Bolt
Baranek and Newman, Inc.) that built the ARPANET.
$ BCA
(O) See: brand certification authority.
Shirey Informational [Page 33]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ BCR
(O) See: BLACK/Crypto/RED.
$ BCI
(O) See: brand CRL identifier.
$ Bell-LaPadula model
(N) A formal, mathematical, state-transition model of
confidentiality policy for multilevel-secure computer systems
[Bell]. (Compare: Biba model, Brewer-Nash model.)
Tutorial: The model, devised by David Bell and Leonard LaPadula at
The MITRE Corporation in 1973, characterizes computer system
elements as subjects and objects. To determine whether or not a
subject is authorized for a particular access mode on an object,
the clearance of the subject is compared to the classification of
the object. The model defines the notion of a "secure state", in
which the only permitted access modes of subjects to objects are
in accordance with a specified security policy. It is proven that
each state transition preserves security by moving from secure
state to secure state, thereby proving that the system is secure.
In this model, a multilevel-secure system satisfies several rules,
including the "confinement property" (a.k.a. the "*-property"),
the "simple security property", and the "tranquility property".
$ benign
1. (N) /COMSEC/ "Condition of cryptographic data [such] that [the
data] cannot be compromised by human access [to the data]."
[C4009]
2. (O) /COMPUSEC/ See: secondary definition under "trust".
$ benign fill
(N) Process by which keying material is generated, distributed,
and placed into an ECU without exposure to any human or other
system entity, except the cryptographic module that consumes and
uses the material. (See: benign.)
$ BER
(I) See: Basic Encoding Rules.
$ beyond A1
1. (O) /formal/ A level of security assurance that is beyond the
highest level (level A1) of criteria specified by the TCSEC. (See:
Tutorial under "Trusted Computer System Evaluation Criteria".)
Shirey Informational [Page 34]
RFC 4949 Internet Security Glossary, Version 2 August 2007
2. (O) /informal/ A level of trust so high that it is beyond
state-of-the-art technology; i.e., it cannot be provided or
verified by currently available assurance methods, and especially
not by currently available formal methods.
$ Biba integrity
(N) Synonym for "source integrity".
$ Biba model
(N) A formal, mathematical, state-transition model of integrity
policy for multilevel-secure computer systems [Biba]. (See: source
integrity. Compare: Bell-LaPadula model.)
Tutorial: This model for integrity control is analogous to the
Bell-LaPadula model for confidentiality control. Each subject and
object is assigned an integrity level and, to determine whether or
not a subject is authorized for a particular access mode on an
object, the integrity level of the subject is compared to that of
the object. The model prohibits the changing of information in an
object by a subject with a lesser or incomparable level. The rules
of the Biba model are duals of the corresponding rules in the
Bell-LaPadula model.
$ billet
(N) "A personnel position or assignment that may be filled by one
person." [JCP1] (Compare: principal, role, user.)
Tutorial: In an organization, a "billet" is a populational
position, of which there is exactly one instance; but a "role" is
functional position, of which there can be multiple instances.
System entities are in one-to-one relationships with their
billets, but may be in many-to-one and one-to-many relationships
with their roles.
$ BIN
(O) See: bank identification number.
$ bind
(I) To inseparably associate by applying some security mechanism.
Example: A CA creates a public-key certificate by using a digital
signature to bind together (a) a subject name, (b) a public key,
and usually (c) some additional data items (e.g., "X.509 public-
key certificate").
$ biometric authentication
(I) A method of generating authentication information for a person
by digitizing measurements of a physical or behavioral
Shirey Informational [Page 35]
RFC 4949 Internet Security Glossary, Version 2 August 2007
characteristic, such as a fingerprint, hand shape, retina pattern,
voiceprint, handwriting style, or face.
$ birthday attack
(I) A class of attacks against cryptographic functions, including
both encryption functions and hash functions. The attacks take
advantage of a statistical property: Given a cryptographic
function having an N-bit output, the probability is greater than
1/2 that for 2**(N/2) randomly chosen inputs, the function will
produce at least two outputs that are identical. (See: Tutorial
under "hash function".)
Derivation: From the somewhat surprising fact (often called the
"birthday paradox") that although there are 365 days in a year,
the probability is greater than 1/2 that two of more people share
the same birthday in any randomly chosen group of 23 people.
Birthday attacks enable an adversary to find two inputs for which
a cryptographic function produces the same cipher text (or find
two inputs for which a hash functions produces the same hash
result) much faster than a brute-force attack can; and a clever
adversary can use such a capability to create considerable
mischief. However, no birthday attack can enable an adversary to
decrypt a given cipher text (or find a hash input that results in
a given hash result) any faster than a brute-force attack can.
$ bit
(I) A contraction of the term "binary digit"; the smallest unit of
information storage, which has two possible states or values. The
values usually are represented by the symbols "0" (zero) and "1"
(one). (See: block, byte, nibble, word.)
$ bit string
(I) A sequence of bits, each of which is either "0" or "1".
$ BLACK
1. (N) Designation for data that consists only of cipher text, and
for information system equipment items or facilities that handle
only cipher text. Example: "BLACK key". (See: BCR, color change,
RED/BLACK separation. Compare: RED.)
2. (O) /U.S. Government/ "Designation applied to information
systems, and to associated areas, circuits, components, and
equipment, in which national security information is encrypted or
is not processed." [C4009]
3. (D) Any data that can be disclosed without harm.
Shirey Informational [Page 36]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Deprecated Definition: IDOCs SHOULD NOT use the term with
definition 3 because the definition is ambiguous with regard to
whether or not the data is protected.
$ BLACK/Crypto/RED (BCR)
(N) An experimental, end-to-end, network packet encryption system
developed in a working prototype form by BBN and the Collins Radio
division of Rockwell Corporation in the 1975-1980 time frame for
the U.S. DoD. BCR was the first network security system to support
TCP/IP traffic, and it incorporated the first DES chips that were
validated by the U.S. National Bureau of Standards (now called
NIST). BCR also was the first to use a KDC and an ACC to manage
connections.
$ BLACK key
(N) A key that is protected with a key-encrypting key and that
must be decrypted before use. (See: BLACK. Compare: RED key.)
$ BLACKER
(O) An end-to-end encryption system for computer data networks
that was developed by the U.S. DoD in the 1980s to provide host-
to-host data confidentiality service for datagrams at OSIRM Layer
3. [Weis] (Compare: CANEWARE, IPsec.)
Tutorial: Each user host connects to its own bump-in-the-wire
encryption device called a BLACKER Front End (BFE, TSEC/KI-111),
through which the host connects to the subnetwork. The system also
includes two types of centralized devices: one or more KDCs
connect to the subnetwork and communicate with assigned sets of
BFEs, and one or more ACCs connect to the subnetwork and
communicate with assigned KDCs. BLACKER uses only symmetric
encryption. A KDC distributes session keys to BFE pairs as
authorized by an ACC. Each ACC maintains a database for a set of
BFEs, and the database determines which pairs from that set (i.e.,
which pairs of user hosts behind the BFEs) are authorized to
communicate and at what security levels.
The BLACKER system is MLS in three ways: (a) The BFEs form a
security perimeter around a subnetwork, separating user hosts from
the subnetwork, so that the subnetwork can operate at a different
security level (possibly a lower, less expensive level) than the
hosts. (b) The BLACKER components are trusted to separate
datagrams of different security levels, so that each datagram of a
given security level can be received only by a host that is
authorized for that security level; and thus BLACKER can separate
host communities that operate at different security levels. (c)
The host side of a BFE is itself MLS and can recognize a security
label on each packet, so that an MLS user host can be authorized
Shirey Informational [Page 37]
RFC 4949 Internet Security Glossary, Version 2 August 2007
to successively transmit datagrams that are labeled with different
security levels.
$ blind attack
(I) A type of network-based attack method that does not require
the attacking entity to receive data traffic from the attacked
entity; i.e., the attacker does not need to "see" data packets
sent by the victim. Example: SYN flood.
Tutorial: If an attack method is blind, the attacker's packets can
carry (a) a false IP source address (making it difficult for the
victim to find the attacker) and (b) a different address on every
packet (making it difficult for the victim to block the attack).
If the attacker needs to receive traffic from the victim, the
attacker must either (c) reveal its own IP address to the victim
(which enables the victim to find the attacker or block the attack
by filtering) or (d) provide a false address and also subvert
network routing mechanisms to divert the returning packets to the
attacker (which makes the attack more complex, more difficult, or
more expensive). [R3552]
$ block
(I) A bit string or bit vector of finite length. (See: bit, block
cipher. Compare: byte, word.)
Usage: An "N-bit block" contains N bits, which usually are
numbered from left to right as 1, 2, 3, ..., N.
$ block cipher
(I) An encryption algorithm that breaks plain text into fixed-size
segments and uses the same key to transform each plaintext segment
into a fixed-size segment of cipher text. Examples: AES, Blowfish,
DEA, IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream
cipher.)
Tutorial: A block cipher can be adapted to have a different
external interface, such as that of a stream cipher, by using a
mode of cryptographic operation to package the basic algorithm.
(See: CBC, CCM, CFB, CMAC, CTR, DEA, ECB, OFB.)
$ Blowfish
(N) A symmetric block cipher with variable-length key (32 to 448
bits) designed in 1993 by Bruce Schneier as an unpatented,
license-free, royalty-free replacement for DES or IDEA. [Schn]
(See: Twofish.)
Shirey Informational [Page 38]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ brain-damaged
(D) /slang/ "Obviously wrong: extremely poorly designed. Calling
something brain-damaged is very extreme. The word implies that the
thing is completely unusable, and that its failure to work is due
to poor design, not accident." [NCSSG] (See: flaw.)
Deprecated Term: It is likely that other cultures use different
metaphors for this concept. Therefore, to avoid international
misunderstanding, IDOCs SHOULD NOT use this term. (See: Deprecated
Usage under "Green Book".)
$ brand
1. (I) A distinctive mark or name that identifies a product or
business entity.
2. (O) /SET/ The name of a payment card. (See: BCA.)
Tutorial: Financial institutions and other companies have founded
payment card brands, protect and advertise the brands, establish
and enforce rules for use and acceptance of their payment cards,
and provide networks to interconnect the financial institutions.
These brands combine the roles of issuer and acquirer in
interactions with cardholders and merchants. [SET1]
$ brand certification authority (BCA)
(O) /SET/ A CA owned by a payment card brand, such as MasterCard,
Visa, or American Express. [SET2] (See: certification hierarchy,
SET.)
$ brand CRL identifier (BCI)
(O) /SET/ A digitally signed list, issued by a BCA, of the names
of CAs for which CRLs need to be processed when verifying
signatures in SET messages. [SET2]
$ break
(I) /cryptography/ To successfully perform cryptanalysis and thus
succeed in decrypting data or performing some other cryptographic
function, without initially having knowledge of the key that the
function requires. (See: penetrate, strength, work factor.)
Usage: This term applies to encrypted data or, more generally, to
a cryptographic algorithm or cryptographic system. Also, while the
most common use is to refer to completely breaking an algorithm,
the term is also used when a method is found that substantially
reduces the work factor.
Shirey Informational [Page 39]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ Brewer-Nash model
(N) A security model [BN89] to enforce the Chinese wall policy.
(Compare: Bell-LaPadula model, Clark-Wilson model.)
Tutorial: All proprietary information in the set of commercial
firms F(1), F(2), ..., F(N) is categorized into mutually exclusive
conflict-of-interest classes I(1), I(2), ..., I(M) that apply
across all firms. Each firm belongs to exactly one class. The
Brewer-Nash model has the following mandatory rules:
- Brewer-Nash Read Rule: Subject S can read information object O
from firm F(i) only if either (a) O is from the same firm as
some object previously read by S *or* (b) O belongs to a class
I(i) from which S has not previously read any object. (See:
object, subject.)
- Brewer-Nash Write Rule: Subject S can write information object
O to firm F(i) only if (a) S can read O by the Brewer-Nash Read
Rule *and* (b) no object can be read by S from a different firm
F(j), no matter whether F(j) belongs to the same class as F(i)
or to a different class.
$ bridge
(I) A gateway for traffic flowing at OSIRM Layer 2 between two
networks (usually two LANs). (Compare: bridge CA, router.)
$ bridge CA
(I) A PKI consisting of only a CA that cross-certifies with CAs of
some other PKIs. (See: cross-certification. Compare: bridge.)
Tutorial: A bridge CA functions as a hub that enables a
certificate user in any of the PKIs that attach to the bridge, to
validate certificates issued in the other attached PKIs.
For example, a bridge CA (BCA) CA1
could cross-certify with four ^
PKIs that have the roots CA1, |
CA2, CA3, and CA4. The cross- v
certificates that the roots CA2 <-> BCA <-> CA3
exchange with the BCA enable an ^
end entity EE1 certified under |
under CA1 in PK1 to construct v
a certification path needed to CA4
validate the certificate of
end entity EE2 under CA2, CA1 -> BCA -> CA2 -> EE2
or vice versa. CA2 -> BCA -> CA1 -> EE1
Shirey Informational [Page 40]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ British Standard 7799
(N) Part 1 of the standard is a code of practice for how to secure
an information system. Part 2 specifies the management framework,
objectives, and control requirements for information security
management systems. [BS7799] (See: ISO 17799.)
$ browser
(I) A client computer program that can retrieve and display
information from servers on the World Wide Web. Examples: Netscape
Navigator and Microsoft Internet Explorer.
$ brute force
(I) A cryptanalysis technique or other kind of attack method
involving an exhaustive procedure that tries a large number of
possible solutions to the problem. (See: impossible, strength,
work factor.)
Tutorial: In some cases, brute force involves trying all of the
possibilities. For example, for cipher text where the analyst
already knows the decryption algorithm, a brute-force technique
for finding matching plain text is to decrypt the message with
every possible key. In other cases, brute force involves trying a
large number of possibilities but substantially fewer than all of
them. For example, given a hash function that produces an N-bit
hash result, the probability is greater than 1/2 that the analyst
will find two inputs that have the same hash result after trying
only 2**(N/2) randomly chosen inputs. (See: birthday attack.)
$ BS7799
(N) See: British Standard 7799.
$ buffer overflow
(I) Any attack technique that exploits a vulnerability resulting
from computer software or hardware that does not check for
exceeding the bounds of a storage area when data is written into a
sequence of storage locations beginning in that area.
Tutorial: By causing a normal system operation to write data
beyond the bounds of a storage area, the attacker seeks to either
disrupt system operation or cause the system to execute malicious
software inserted by the attacker.
$ buffer zone
(I) A neutral internetwork segment used to connect other segments
that each operate under a different security policy.
Shirey Informational [Page 41]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Tutorial: To connect a private network to the Internet or some
other relatively public network, one could construct a small,
separate, isolated LAN and connect it to both the private network
and the public network; one or both of the connections would
implement a firewall to limit the traffic that could pass through
the buffer zone.
$ bulk encryption
1. (I) Encryption of multiple channels by aggregating them into a
single transfer path and then encrypting that path. (See:
channel.)
2. (O) "Simultaneous encryption of all channels of a multichannel
telecommunications link." [C4009] (Compare: bulk keying material.)
Usage: The use of "simultaneous" in definition 2 could be
interpreted to mean that multiple channels are encrypted
separately but at the same time. However, the common meaning of
the term is that multiple data flows are combined into a single
stream and then that stream is encrypted as a whole.
$ bulk key
(D) In a few published descriptions of hybrid encryption for SSH,
Windows 2000, and other applications, this term refers to a
symmetric key that (a) is used to encrypt a relatively large
amount of data and (b) is itself encrypted with a public key.
(Compare: bulk keying material, session key.)
Example: To send a large file to Bob, Alice (a) generates a
symmetric key and uses it to encrypt the file (i.e., encrypt the
bulk of the information that is to be sent) and then (b) encrypts
that symmetric key (the "bulk key") with Bob's public key.
Deprecated Term: IDOCs SHOULD NOT use this term or definition; the
term is not well-established and could be confused with the
established term "bulk keying material". Instead, use "symmetric
key" and carefully explain how the key is applied.
$ bulk keying material
(N) Refers to handling keying material in large quantities, e.g.,
as a dataset that contains many items of keying material. (See:
type 0. Compare: bulk key, bulk encryption.)
$ bump-in-the-stack
(I) An implementation approach that places a network security
mechanism inside the system that is to be protected. (Compare:
bump-in-the-wire.)
Shirey Informational [Page 42]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Example: IPsec can be implemented inboard, in the protocol stack
of an existing system or existing system design, by placing a new
layer between the existing IP layer and the OSIRM Layer 3 drivers.
Source code access for the existing stack is not required, but the
system that contains the stack does need to be modified [R4301].
$ bump-in-the-wire
(I) An implementation approach that places a network security
mechanism outside of the system that is to be protected. (Compare:
bump-in-the-stack.)
Example: IPsec can be implemented outboard, in a physically
separate device, so that the system that receives the IPsec
protection does not need to be modified at all [R4301]. Military-
grade link encryption has mainly been implemented as bump-in-the-
wire devices.
$ business-case analysis
(N) An extended form of cost-benefit analysis that considers
factors beyond financial metrics, including security factors such
as the requirement for security services, their technical and
programmatic feasibility, their qualitative benefits, and
associated risks. (See: risk analysis.)
$ byte
(I) A fundamental unit of computer storage; the smallest
addressable unit in a computer's architecture. Usually holds one
character of information and, today, usually means eight bits.
(Compare: octet.)
Usage: Understood to be larger than a "bit", but smaller than a
"word". Although "byte" almost always means "octet" today, some
computer architectures have had bytes in other sizes (e.g., six
bits, nine bits). Therefore, an STD SHOULD state the number of
bits in a byte where the term is first used in the STD.
$ C field
(D) See: Compartments field.
$ C1 or C2 computer system
(O) /TCSEC/ See: Tutorial under "Trusted Computer System
Evaluation Criteria".
$ CA
(I) See: certification authority.
Shirey Informational [Page 43]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ CA certificate
(D) "A [digital] certificate for one CA issued by another CA."
[X509]
Deprecated Definition: IDOCs SHOULD NOT use the term with this
definition; the definition is ambiguous with regard to how the
certificate is constructed and how it is intended to be used.
IDOCs that use this term SHOULD provide a technical definition for
it. (See: certificate profile.)
Tutorial: There is no single, obvious choice for a technical
definition of this term. Different PKIs can use different
certificate profiles, and X.509 provides several choices of how to
issue certificates to CAs. For example, one possible definition is
the following: A v3 X.509 public-key certificate that has a
"basicConstraints" extension containing a "cA" value of "TRUE".
That would specifically indicate that "the certified public key
may be used to verify certificate signatures", i.e., that the
private key may be used by a CA.
However, there also are other ways to indicate such usage. The
certificate may have a "key Usage" extension that indicates the
purposes for which the public key may be used, and one of the
values that X.509 defines for that extension is "keyCertSign", to
indicate that the certificate may be used for verifying a CA's
signature on certificates. If "keyCertSign" is present in a
certificate that also has a "basicConstraints" extension, then
"cA" is set to "TRUE" in that extension. Alternatively, a CA could
be issued a certificate in which "keyCertSign" is asserted without
"basicConstraints" being present; and an entity that acts as a CA
could be issued a certificate with "keyUsage" set to other values,
either with or without "keyCertSign".
$ CA domain
(N) /PKI/ A security policy domain that "consists of a CA and its
subjects [i.e., the entities named in the certificates issued by
the CA]. Sometimes referred to as a PKI domain." [PAG] (See:
domain.)
$ Caesar cipher
(I) A cipher that is defined for an alphabet of N characters,
A(1), A(2), ..., A(N), and creates cipher text by replacing each
plaintext character A(i) by A(i+K, mod N) for some 0<K<N+1. [Schn]
Examples: (a) During the Gallic wars, Julius Caesar used a cipher
with K=3. In a Caesar cipher with K=3 for the English alphabet, A
is replaced by D, B by E, C by F, ..., W by Z, X by A, Y by B, Z
Shirey Informational [Page 44]
RFC 4949 Internet Security Glossary, Version 2 August 2007
by C. (b) UNIX systems sometimes include "ROT13" software that
implements a Caesar cipher with K=13 (i.e., ROTate by 13).
$ call back
(I) An authentication technique for terminals that remotely access
a computer via telephone lines; the host system disconnects the
caller and then reconnects on a telephone number that was
previously authorized for that terminal.
$ CAM
(O) See: Certificate Arbitrator Module.
$ CANEWARE
(O) An end-to-end encryption system for computer data networks
that was developed by the U.S. DoD in the 1980s to provide host-
to-host data confidentiality service for datagrams in OSIRM Layer
3. [Roge] (Compare: BLACKER, IPsec.)
Tutorial: Each user host connects to its own bump-in-the-wire
encryption device called a CANEWARE Front End (CFE), through which
the host connects to the subnetwork. CANEWARE uses symmetric
encryption for CFE-to-CFE traffic, but also uses FIREFLY to
establish those session keys. The public-key certificates issued
by the FIREFLY system include credentials for mandatory access
control. For discretionary access control, the system also
includes one or more centralized CANEWARE Control Processors
(CCPs) that connect to the subnetwork, maintain a database for
discretionary access control authorizations, and communicate those
authorizations to assigned sets of CFEs.
The CANEWARE system is MLS in only two of the three ways that
BLACKER is MLS: (a) Like BLACKER BFEs, CFEs form a security
perimeter around a subnetwork, separating user hosts from the
subnetwork, so that the subnetwork can operate at a different
security level than the hosts. (b) Like BLACKER, the CANEWARE
components are trusted to separate datagrams of different security
levels, so that each datagram of a given security level can be
received only by a host that is authorized for that security
level; and thus CANEWARE can separate host communities that
operate at different security levels. (c) Unlike a BFE, the host
side of a CFE is not MLS, and treats all packets received from a
user host as being at the same mandatory security level.
$ capability list
(I) /information system/ A mechanism that implements access
control for a system entity by enumerating the system resources
that the entity is permitted to access and, either implicitly or
explicitly, the access modes granted for each resource. (Compare:
Shirey Informational [Page 45]
RFC 4949 Internet Security Glossary, Version 2 August 2007
access control list, access control matrix, access profile,
capability token.)
$ capability token
(I) A token (usually an unforgeable data object) that gives the
bearer or holder the right to access a system resource. Possession
of the token is accepted by a system as proof that the holder has
been authorized to access the resource indicated by the token.
(See: attribute certificate, capability list, credential, digital
certificate, ticket, token.)
$ Capability Maturity Model (CMM)
(N) Method for judging the maturity of software processes in an
organization and for identifying crucial practices needed to
increase process maturity. [Chris] (Compare: Common Criteria.)
Tutorial: The CMM does not specify security evaluation criteria
(see: assurance level), but its use may improve security
assurance. The CMM describes principles and practices that can
improve software processes in terms of evolving from ad hoc
processes to disciplined processes. The CMM has five levels:
- Initial: Software processes are ad hoc or chaotic, and few are
well-defined. Success depends on individual effort and heroics.
- Repeatable: Basic project management processes are established
to track cost, schedule, and functionality. Necessary process
discipline is in place to repeat earlier successes on projects
with similar applications.
- Defined: Software process for both management and engineering
activities is documented, standardized, and integrated into a
standard software process for the organization. Each project
uses an approved, tailored version of the organization's
standard process for developing and maintaining software.
- Managed: Detailed measures of software process and product
quality are collected. Both software process and products are
quantitatively understood and controlled.
- Optimizing: Continuous process improvement is enabled by
quantitative feedback from the process and from piloting
innovative ideas and technologies.
$ CAPI
(I) See: cryptographic application programming interface.
$ CAPSTONE
(N) An integrated microcircuit (in MYK-8x series manufactured by
Mykotronx, Inc.) that implements SKIPJACK, KEA, DSA, SHA, and
basic mathematical functions needed to support asymmetric
cryptography; has a non-deterministic random number generator; and
supports key escrow. (See: FORTEZZA. Compare: CLIPPER.)
Shirey Informational [Page 46]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ card
See: cryptographic card, FORTEZZA, payment card, PC card, smart
card, token.
$ card backup
See: token backup.
$ card copy
See: token copy.
$ card restore
See: token restore.
$ cardholder
1. (I) An entity to whom or to which a card has been issued.
Usage: Usually refers to a living human being, but might refer (a)
to a position (see: billet, role) in an organization or (b) to an
automated process. (Compare: user.)
2. (O) /SET/ "The holder of a valid payment card account and user
of software supporting electronic commerce." [SET2] A cardholder
is issued a payment card by an issuer. SET ensures that in the
cardholder's interactions with merchants, the payment card account
information remains confidential. [SET1]
$ cardholder certificate
(O) /SET/ A digital certificate that is issued to a cardholder
upon approval of the cardholder's issuing financial institution
and that is transmitted to merchants with purchase requests and
encrypted payment instructions, carrying assurance that the
account number has been validated by the issuing financial
institution and cannot be altered by a third party. [SET1]
$ cardholder certification authority (CCA)
(O) /SET/ A CA responsible for issuing digital certificates to
cardholders and operated on behalf of a payment card brand, an
issuer, or another party according to brand rules. A CCA maintains
relationships with card issuers to allow for the verification of
cardholder accounts. A CCA does not issue a CRL but does
distribute CRLs issued by root CAs, brand CAs, geopolitical CAs,
and payment gateway CAs. [SET2]
$ CAST
(N) A design procedure for symmetric encryption algorithms, and a
resulting family of algorithms, invented by Carlisle Adams (C.A.)
and Stafford Tavares (S.T.). [R2144, R2612]
Shirey Informational [Page 47]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ category
(I) A grouping of sensitive information items to which a non-
hierarchical restrictive security label is applied to increase
protection of the data. (See: formal access approval. Compare:
compartment, classification.)
$ CAW
(N) See: certification authority workstation.
$ CBC
(N) See: cipher block chaining.
$ CCA
(O) See: cardholder certification authority.
$ CCEP
(O) See: Commercial COMSEC Endorsement Program.
$ CCI
(O) See: Controlled Cryptographic Item.
$ CCITT
(N) Acronym for French translation of International Telephone and
Telegraph Consultative Committee. Now renamed ITU-T.
$ CCM
(N) See: Counter with Cipher Block Chaining-Message Authentication
Code.
$ CERIAS
(O) Purdue University's Center for Education and Research in
Information Assurance and Security, which includes faculty from
multiple schools and departments and takes a multidisciplinary
approach to security problems ranging from technical to ethical,
legal, educational, communicational, linguistic, and economic.
$ CERT
(I) See: computer emergency response team.
$ certificate
1. (I) /general English/ A document that attests to the truth of
something or the ownership of something.
2. (I) /general security/ See: capability token, digital
certificate.
3. (I) /PKI/ See: attribute certificate, public-key certificate.
Shirey Informational [Page 48]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ Certificate Arbitrator Module (CAM)
(O) An open-source software module that is designed to be
integrated with an application for routing, replying to, and
otherwise managing and meditating certificate validation requests
between that application and the CAs in the ACES PKI.
$ certificate authority
(D) Synonym for "certification authority".
Deprecated Term: IDOCs SHOULD NOT use this term; it suggests
careless use of the term "certification authority", which is
preferred in PKI standards (e.g., [X509, R3280]).
$ certificate chain
(D) Synonym for "certification path". (See: trust chain.)
Deprecated Term: IDOCs SHOULD NOT use this term; it duplicates the
meaning of a standardized term. Instead, use "certification path".
$ certificate chain validation
(D) Synonym for "certificate validation" or "path validation".
Deprecated Term: IDOCs SHOULD NOT use this term; it duplicates the
meaning of standardized terms and mixes concepts in a potentially
misleading way. Instead, use "certificate validation" or "path
validation", depending on what is meant. (See: validate vs.
verify.)
$ certificate creation
(I) The act or process by which a CA sets the values of a digital
certificate's data fields and signs it. (See: issue.)
$ certificate expiration
(I) The event that occurs when a certificate ceases to be valid
because its assigned lifetime has been exceeded. (See: certificate
revocation, expire.)
Tutorial: The assigned lifetime of an X.509 certificate is stated
in the certificate itself. (See: validity period.)
$ certificate extension
(I) See: extension.
$ certificate holder
(D) Synonym for the "subject" of a digital certificate. (Compare:
certificate owner, certificate user.)
Shirey Informational [Page 49]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym
for the subject of a digital certificate; the term is potentially
ambiguous. For example, the term could be misunderstood as
referring to a system entity or component, such as a repository,
that simply has possession of a copy of the certificate.
$ certificate management
(I) The functions that a CA may perform during the lifecycle of a
digital certificate, including the following:
- Acquire and verify data items to bind into the certificate.
- Encode and sign the certificate.
- Store the certificate in a directory or repository.
- Renew, rekey, and update the certificate.
- Revoke the certificate and issue a CRL.
(See: archive management, certificate management, key management,
security architecture, token management.)
$ certificate management authority (CMA)
(D) /U.S. DoD/ Used to mean either a CA or an RA. [DoD7, SP32]
Deprecated Term: IDOCs SHOULD NOT use this term because it is
potentially ambiguous, such as in a context involving ICRLs.
Instead, use CA, RA, or both, depending on what is meant.
$ certificate owner
(D) Synonym for the "subject" of a digital certificate. (Compare:
certificate holder, certificate user.)
Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym
for the subject of a digital certificate; the term is potentially
ambiguous. For example, the term could refer to a system entity,
such as a corporation, that has purchased a certificate to operate
equipment, such as a Web server.
$ certificate path
(D) Synonym for "certification path".
Deprecated Term: IDOCs SHOULD NOT use this term; it suggests
careless use of "certification path", which is preferred in PKI
standards (e.g., [X509, R3280]).
$ certificate policy
(I) "A named set of rules that indicates the applicability of a
certificate to a particular community and/or class of application
with common security requirements." [X509] (Compare: CPS, security
policy.)
Shirey Informational [Page 50]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Example: U.S. DoD's certificate policy [DoD7] defined four classes
(i.e., assurance levels) for X.509 public-key certificates and
defines the applicability of those classes. (See: class 2.)
Tutorial: A certificate policy can help a certificate user to
decide whether a certificate should be trusted in a particular
application. "For example, a particular certificate policy might
indicate applicability of a type of certificate for the
authentication of electronic data interchange transactions for the
trading of goods within a given price range." [R3647]
A v3 X.509 public-key certificate may have a "certificatePolicies"
extension that lists certificate policies, recognized by the
issuing CA, that apply to the certificate and govern its use. Each
policy is denoted by an object identifier and may optionally have
certificate policy qualifiers. (See: certificate profile.)
Each SET certificate specifies at least one certificate policy,
that of the SET root CA. SET uses certificate policy qualifiers to
point to the actual policy statement and to add qualifying
policies to the root policy. (See: SET qualifier.)
$ certificate policy qualifier
(I) Information that pertains to a certificate policy and is
included in a "certificatePolicies" extension in a v3 X.509
public-key certificate.
$ certificate profile
(I) A specification (e.g., [DoD7, R3280]) of the format and
semantics of public-key certificates or attribute certificates,
constructed for use in a specific application context by selecting
from among options offered by a broader standard. (Compare:
protection profile.)
$ certificate reactivation
(I) The act or process by which a digital certificate, that a CA
has designated for revocation but not yet listed on a CRL, is
returned to the valid state.
$ certificate rekey
1. (I) The act or process by which an existing public-key
certificate has its key value changed by issuing a new certificate
with a different (usually new) public key.