S <- 4. Definitions -> U
T
$ TACACS
(I) See: Terminal Access Controller (TAC) Access Control System.
$ TACACS+
(I) A TCP-based protocol that improves on TACACS by separating the
functions of authentication, authorization, and accounting and by
encrypting all traffic between the network access server and
Shirey Informational [Page 300]
RFC 4949 Internet Security Glossary, Version 2 August 2007
authentication server. TACACS+ is extensible to allow any
authentication mechanism to be used with TACACS+ clients.
$ tamper
(I) Make an unauthorized modification in a system that alters the
system's functioning in a way that degrades the security services
that the system was intended to provide. (See: QUADRANT. Compare:
secondary definitions under "corruption" and "misuse".)
$ tamper-evident
(I) A characteristic of a system component that provides evidence
that an attack has been attempted on that component or system.
Usage: Usually involves physical evidence. (See: tamper.)
$ tamper-resistant
(I) A characteristic of a system component that provides passive
protection against an attack. (See: tamper.)
Usage: Usually involves physical means of protection.
$ tampering
(I) /threat action/ See: secondary definitions under "corruption"
and "misuse".
$ target of evaluation (TOE)
(N) /Common Criteria/ An information technology product or system
that is the subject of a security evaluation, together with the
product's associated administrator and user documentation.
(Compare: protection profile.)
Tutorial: The security characteristics of the target of evaluation
(TOE) are described in specific terms by a corresponding security
target, or in more general terms by a protection profile. In
Common Criteria philosophy, it is important that a TOE be
evaluated against the specific set of criteria expressed in the
target. This evaluation consists of rigorous analysis and testing
performed by an accredited, independent laboratory. The scope of a
TOE evaluation is set by the EAL and other requirements specified
in the target. Part of this process is an evaluation of the target
itself, to ensure that it is correct, complete, and internally
consistent and can be used as the baseline for the TOE evaluation.
$ TCB
(N) See: trusted computing base.
$ TCC field
(I) See: Transmission Control Code field.
Shirey Informational [Page 301]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ TCG
(N) See: Trusted Computing Group.
$ TCP
(I) See: Transmission Control Protocol.
$ TCP/IP
(I) Synonym for "Internet Protocol Suite".
$ TCSEC
(N) See: Trusted Computer System Evaluation Criteria. (Compare:
TSEC.)
$ TDEA
(I) See: Triple Data Encryption Algorithm.
$ teardrop attack
(D) /slang/ A denial-of-service attack that sends improperly
formed IP packet fragments with the intent of causing the
destination system to fail.
Deprecated Term: IDOCs that use this term SHOULD state a
definition for it because the term is often used imprecisely and
could easily be misunderstood. (See: Deprecated Usage under "Green
Book".)
$ technical non-repudiation
(I) See: (secondary definition under) non-repudiation.
$ technical security
(I) Security mechanisms and procedures that are implemented in and
executed by computer hardware, firmware, or software to provide
automated protection for a system. (See: security architecture.
Compare: administrative security.)
$ Telecommunications Security Word System (TSEC)
(O) /U.S. Government/ A terminology for designating
telecommunication security equipment. (Compare: TCSEC.)
Tutorial: A TSEC designator has the following parts:
- Prefix "TSEC/" for items and systems, or suffix "/TSEC" for
assemblies. (Often omitted when the context is clear.)
- First letter, for function: "C" COMSEC equipment system, "G"
general purpose, "K" cryptographic, "H" crypto-ancillary, "M"
manufacturing, "N" noncryptographic, "S" special purpose.
- Second letter, for type or purpose: "G" key generation, "I"
data transmission, "L" literal conversion, "N" signal
conversion, "O" multipurpose, "P" materials production, "S"
Shirey Informational [Page 302]
RFC 4949 Internet Security Glossary, Version 2 August 2007
special purpose, "T" testing or checking, "U" television, "W"
teletypewriter, "X" facsimile, "Y" speech.
- Optional third letter, used only in designations of assemblies,
for type or purpose: "A" advancing, "B" base or cabinet, "C"
combining, "D" drawer or panel, "E" strip or chassis, "F" frame
or rack, "G" key generator, "H" keyboard, "I" translator or
reader, "J" speech processing, "K" keying or permuting, "L"
repeater, "M" memory or storage, "O" observation, "P" power
supply or converter, "R" receiver, "S" synchronizing, "T"
transmitter, "U" printer, "V" removable COMSEC component, "W"
logic programmer/programming, "X" special purpose.
- Model number, usually two or three digits, assigned
sequentially within each letter combination (e.g., KG-34, KG-
84).
- Optional suffix letter, used to designate a version. First
version has no letter, next version has "A" (e.g., KG-84, KG-
84A), etc.
$ TELNET
(I) A TCP-based, Application-Layer, Internet Standard protocol
(RFC 854) for remote login from one host to another.
$ TEMPEST
1. (N) Short name for technology and methods for protecting
against data compromise due to electromagnetic emanations from
electrical and electronic equipment. [Army, Russ] (See:
inspectable space, soft TEMPEST, TEMPEST zone. Compare: QUADRANT)
2. (O) /U.S. Government/ "Short name referring to investigation,
study, and control of compromising emanations from IS equipment."
[C4009]
Deprecated Usage: IDOCs SHOULD NOT use this term as a synonym for
"electromagnetic emanations security"; instead, use EMSEC. Also,
the term is NOT an acronym for Transient Electromagnetic Pulse
Surveillance Technology.
Tutorial: The U.S. Federal Government issues security policies
that (a) state specifications and standards for techniques to
reduce the strength of emanations from systems and reduce the
ability of unauthorized parties to receive and make use of
emanations and (b) state rules for applying those techniques.
Other nations presumably do the same.
$ TEMPEST zone
(O) "Designated area [i.e., a physical volume] within a facility
where equipment with appropriate TEMPEST characteristics ... may
Shirey Informational [Page 303]
RFC 4949 Internet Security Glossary, Version 2 August 2007
be operated." [C4009] (See: emanation security, TEMPEST. Compare:
control zone, inspectable space.)
Tutorial: The strength of an electromagnetic signal decreases in
proportion to the square of the distance between the source and
the receiver. Therefore, EMSEC for electromagnetic signals can be
achieved by a combination of (a) reducing the strength of
emanations to a defined level and (b) establishing around that
equipment an appropriately sized physical buffer zone from which
unauthorized entities are excluded. By making the zone large
enough, it is possible to limit the signal strength available to
entities outside the zone to a level lower than can be received
and read with known, state-of-the-art methods. Typically, the need
for and size of a TEMPEST zone established by a security policy
depends not only on the measured level of signal emitted by
equipment, but also on the perceived threat level in the
equipment's environment.
$ Terminal Access Controller (TAC) Access Control System (TACACS)
(I) A UDP-based authentication and access control protocol [R1492]
in which a network access server receives an identifier and
password from a remote terminal and passes them to a separate
authentication server for verification. (See: TACACS+.)
Tutorial: TACACS can provide service not only for network access
servers but also routers and other networked computing devices via
one or more centralized authentication servers. TACACS was
originally developed for ARPANET and has evolved for use in
commercial equipment.
$ TESS
(I) See: The Exponential Encryption System.
$ The Exponential Encryption System (TESS)
(I) A system of separate but cooperating cryptographic mechanisms
and functions for the secure authenticated exchange of
cryptographic keys, the generation of digital signatures, and the
distribution of public keys. TESS uses asymmetric cryptography,
based on discrete exponentiation, and a structure of self-
certified public keys. [R1824]
$ theft
(I) /threat action/ See: secondary definitions under
"interception" and "misappropriation".
$ threat
1a. (I) A potential for violation of security, which exists when
there is an entity, circumstance, capability, action, or event
Shirey Informational [Page 304]
RFC 4949 Internet Security Glossary, Version 2 August 2007
that could cause harm. (See: dangling threat, INFOCON level,
threat action, threat agent, threat consequence. Compare: attack,
vulnerability.)
1b. (N) Any circumstance or event with the potential to adversely
affect a system through unauthorized access, destruction,
disclosure, or modification of data, or denial of service. [C4009]
(See: sensitive information.)
Usage: (a) Frequently misused with the meaning of either "threat
action" or "vulnerability". (b) In some contexts, "threat" is used
more narrowly to refer only to intelligent threats; for example,
see definition 2 below. (c) In some contexts, "threat" is used
more broadly to cover both definition 1 and other concepts, such
as in definition 3 below.
Tutorial: A threat is a possible danger that might exploit a
vulnerability. Thus, a threat may be intentional or not:
- "Intentional threat": A possibility of an attack by an
intelligent entity (e.g., an individual cracker or a criminal
organization).
- "Accidental threat": A possibility of human error or omission,
unintended equipment malfunction, or natural disaster (e.g.,
fire, flood, earthquake, windstorm, and other causes listed in
[FP031]).
The Common Criteria characterizes a threat in terms of (a) a
threat agent, (b) a presumed method of attack, (c) any
vulnerabilities that are the foundation for the attack, and (d)
the system resource that is attacked. That characterization agrees
with the definitions in this Glossary (see: diagram under
"attack").
2. (O) The technical and operational ability of a hostile entity
to detect, exploit, or subvert a friendly system and the
demonstrated, presumed, or inferred intent of that entity to
conduct such activity.
Tutorial: To be likely to launch an attack, an adversary must have
(a) a motive to attack, (b) a method or technical ability to make
the attack, and (c) an opportunity to appropriately access the
targeted system.
3. (D) "An indication of an impending undesirable event." [Park]
Deprecated Definition: IDOCs SHOULD NOT use this term with
definition 3 because the definition is ambiguous; the definition
was intended to include the following three meanings:
Shirey Informational [Page 305]
RFC 4949 Internet Security Glossary, Version 2 August 2007
- "Potential threat": A possible security violation; i.e., the
same as definition 1.
- "Active threat": An expression of intent to violate security.
(Context usually distinguishes this meaning from the previous
one.)
- "Accomplished threat" or "actualized threat": That is, a threat
action. Deprecated Usage: IDOCs SHOULD NOT use the term
"threat" with this meaning; instead, use "threat action".
$ threat action
(I) A realization of a threat, i.e., an occurrence in which system
security is assaulted as the result of either an accidental event
or an intentional act. (See: attack, threat, threat consequence.)
Tutorial: A complete security architecture deals with both
intentional acts (i.e., attacks) and accidental events [FP031].
(See: various kinds of threat actions defined under the four kinds
of "threat consequence".)
$ threat agent
(I) A system entity that performs a threat action, or an event
that results in a threat action.
$ threat analysis
(I) An analysis of the threat actions that might affect a system,
primarily emphasizing their probability of occurrence but also
considering their resulting threat consequences. Example: RFC
3833. (Compare: risk analysis.)
$ threat consequence
(I) A security violation that results from a threat action.
Tutorial: The four basic types of threat consequence are
"unauthorized disclosure", "deception", "disruption", and
"usurpation". (See main Glossary entries of each of these four
terms for lists of the types of threat actions that can result in
these consequences.)
$ thumbprint
1. (I) A pattern of curves formed by the ridges on the tip of a
thumb. (See: biometric authentication, fingerprint.)
2. (D) Synonym for some type of "hash result". (See: biometric
authentication. Compare: fingerprint.)
Deprecated Usage: IDOCs SHOULD NOT use this term with definition 2
because that meaning mixes concepts in a potentially misleading
way.
Shirey Informational [Page 306]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ ticket
(I) Synonym for "capability token".
Tutorial: A ticket is usually granted by a centralized access
control server (ticket-granting agent) to authorize access to a
system resource for a limited time. Tickets can be implemented
with either symmetric cryptography (see: Kerberos) or asymmetric
cryptography (see: attribute certificate).
$ tiger team
(O) A group of evaluators employed by a system's managers to
perform penetration tests on the system.
Deprecated Usage: 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".)
$ time stamp
1. (I) /noun/ With respect to a data object, a label or marking in
which is recorded the time (time of day or other instant of
elapsed time) at which the label or marking was affixed to the
data object. (See: Time-Stamp Protocol.)
2. (O) /noun/ "With respect to a recorded network event, a data
field in which is recorded the time (time of day or other instant
of elapsed time) at which the event took place." [A1523]
Tutorial: A time stamp can be used as evidence to prove that a
data object existed (or that an event occurred) at or before a
particular time. For example, a time stamp might be used to prove
that a digital signature based on a private key was created while
the corresponding public-key certificate was valid, i.e., before
the certificate either expired or was revoked. Establishing this
proof would enable the certificate to be used after its expiration
or revocation, to verify a signature that was created earlier.
This kind of proof is required as part of implementing PKI
services, such as non-repudiation service, and long-term security
services, such as audit.
$ Time-Stamp Protocol
(I) An Internet protocol (RFC 3161) that specifies how a client
requests and receives a time stamp from a server for a data object
held by the client.
Tutorial: The protocol describes the format of (a) a request sent
to a time-stamp authority and (b) the response that is returned
containing a time stamp. The authority creates the stamp by
Shirey Informational [Page 307]
RFC 4949 Internet Security Glossary, Version 2 August 2007
concatenating (a) a hash value of the input data object with (b) a
UTC time value and other parameters (policy OID, serial number,
indication of time accuracy, nonce, DN of the authority, and
various extensions), and then signing that dataset with the
authority's private key as specified in CMS. Such an authority
typically would operate as a trusted third-party service, but
other operational models might be used.
$ timing channel
(I) See: covert timing channel.
$ TKEY
(I) A mnemonic referring to an Internet protocol (RFC 2930) for
establishing a shared secret key between a DNS resolver and a DNS
name server. (See: TSIG.)
$ TLS
(I) See: Transport Layer Security.
$ TLSP
(N) See: Transport Layer Security Protocol.
$ TOE
(N) See: target of evaluation.
$ token
1. (I) /cryptography/ See: cryptographic token. (Compare: dongle.)
2. (I) /access control/ An object that is used to control access
and is passed between cooperating entities in a protocol that
synchronizes use of a shared resource. Usually, the entity that
currently holds the token has exclusive access to the resource.
(See: capability token.)
Usage: This term is heavily overloaded in the computing
literature; therefore, IDOCs SHOULD NOT use this term with any
definition other than 1 or 2.
3a. (D) /authentication/ A data object or a physical device used
to verify an identity in an authentication process.
3b. (D) /U.S. Government/ Something that the claimant in an
authentication process (i.e., the entity that claims an identity)
possesses and controls, and uses to prove the claim during the
verification step of the process. [SP63]
Deprecated usage: IDOCs SHOULD NOT use this term with definitions
3a and 3b; instead, use more specifically descriptive and
Shirey Informational [Page 308]
RFC 4949 Internet Security Glossary, Version 2 August 2007
informative terms such as "authentication information" or
"cryptographic token", depending on what is meant.
NIST defines four types of claimant tokens for electronic
authentication in an information system [SP63]. IDOCs SHOULD NOT
use these four NIST terms; they mix concepts in potentially
confusing ways and duplicate the meaning of better-established
terms. These four terms can be avoided by using more specifically
descriptive terms as follows:
- NIST "hard token": A hardware device that contains a protected
cryptographic key. (This is a type of "cryptographic token",
and the key is a type of "authentication information".)
- NIST "one-time password device token": A personal hardware
device that generates one-time passwords. (One-time passwords
are typically generated cryptographically. Therefore, this is a
type of "cryptographic token", and the key is a type of
"authentication information".)
- NIST "soft token": A cryptographic key that typically is stored
on disk or some other magnetic media. (The key is a type of
"authentication information"; "authentication key" would be a
better description.)
- NIST "password token": A secret data value that the claimant
memorizes. (This is a "password" that is being used as
"authentication information".)
$ token backup
(I) A token management operation that stores sufficient
information in a database (e.g., in a CAW) to recreate or restore
a security token (e.g., a smart card) if it is lost or damaged.
$ token copy
(I) A token management operation that copies all the personality
information from one security token to another. However, unlike in
a token restore operation, the second token is initialized with
its own, different local security values such as PINs and storage
keys.
$ token management
(I) The process that includes initializing security tokens (e.g.,
"smart card"), loading data into the tokens, and controlling the
tokens during their lifecycle. May include performing key
management and certificate management functions; generating and
installing PINs; loading user personality data; performing card
backup, card copy, and card restore operations; and updating
firmware.
Shirey Informational [Page 309]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ token restore
(I) A token management operation that loads a security token with
data for the purpose of recreating (duplicating) the contents
previously held by that or another token. (See: recovery.)
$ token storage key
(I) A cryptographic key used to protect data that is stored on a
security token.
$ top CA
(I) Synonym for "root" in a certification hierarchy. (See: apex
trust anchor.)
$ top-level specification
(I) "A non-procedural description of system behavior at the most
abstract level; typically a functional specification that omits
all implementation details." [NCS04] (See: formal top-level
specification, Tutorial under "security policy".)
Tutorial: A top-level specification is at a level of abstraction
below "security model" and above "security architecture" (see:
Tutorial under "security policy").
A top-level specification may be descriptive or formal:
- "Descriptive top-level specification": One that is written in a
natural language like English or an informal design notation.
- "Formal top-level specification": One that is written in a
formal mathematical language to enable theorems to be proven
that show that the specification correctly implements a set of
formal requirements or a formal security model. (See:
correctness proof.)
$ TPM
(N) See: Trusted Platform Module.
$ traceback
(I) Identification of the source of a data packet. (See:
masquerade, network weaving.)
$ tracker
(N) An attack technique for achieving unauthorized disclosure from
a statistical database. [Denns] (See: Tutorial under "inference
control".)
$ traffic analysis
1. (I) Gaining knowledge of information by inference from
observable characteristics of a data flow, even if the information
is not directly available (e.g., when the data is encrypted).
Shirey Informational [Page 310]
RFC 4949 Internet Security Glossary, Version 2 August 2007
These characteristics include the identities and locations of the
source(s) and destination(s) of the flow, and the flow's presence,
amount, frequency, and duration of occurrence. The object of the
analysis might be information in SDUs, information in the PCI, or
both. (See: inference, traffic-flow confidentiality, wiretapping.
Compare: signal analysis.)
2. (O) "The inference of information from observation of traffic
flows (presence, absence, amount, direction, and frequency)."
[I7498-2]
$ traffic-flow analysis
(I) Synonym for "traffic analysis".
$ traffic-flow confidentiality (TFC)
1. (I) A data confidentiality service to protect against traffic
analysis. (See: communications cover.)
2. (O) "A confidentiality service to protect against traffic
analysis." [I7498-2]
Tutorial: Confidentiality concerns involve both direct and
indirect disclosure of data, and the latter includes traffic
analysis. However, operational considerations can make TFC
difficult to achieve. For example, if Alice sends a product idea
to Bob in an email message, she wants data confidentiality for the
message's content, and she might also want to conceal the
destination of the message to hide Bob's identity from her
competitors. However, the identity of the intended recipient, or
at least a network address for that recipient, needs to be made
available to the mail system. Thus, complex forwarding schemes may
be needed to conceal the ultimate destination as the message
travels through the open Internet (see: onion routing).
Later, if Alice uses an ATM during a clandestine visit to
negotiate with Bob, she might prefer that her bank conceal the
origin of her transaction, because knowledge of the ATM's location
might allow a competitor to infer Bob's identity. The bank, on the
other hand, might prefer to protect only Alice's PIN (see:
selective-field confidentiality).
A TFC service can be either full or partial:
- "Full TFC": This type of service conceals all traffic
characteristics.
- "Partial TFC": This type of service either (a) conceals some
but not all of the characteristics or (b) does not completely
conceal some characteristic.
Shirey Informational [Page 311]
RFC 4949 Internet Security Glossary, Version 2 August 2007
On point-to-point data links, full TFC can be provided by
enciphering all PDUs and also generating a continuous, random data
stream to seamlessly fill all gaps between PDUs. To a wiretapper,
the link then appears to be carrying an unbroken stream of
enciphered data. In other cases -- including on a shared or
broadcast medium, or end-to-end in a network -- only partial TFC
is possible, and that may require a combination of techniques. For
example, a LAN that uses "carrier sense multiple access with
collision detection" (CSMA/CD; a.k.a. "listen while talk") to
control access to the medium, relies on detecting intervals of
silence, which prevents using full TFC. Partial TFC can be
provided on that LAN by measures such as adding spurious PDUs,
padding PDUs to a constant size, or enciphering addresses just
above the Physical Layer; but these measures reduce the efficiency
with which the LAN can carry traffic. At higher protocol layers,
SDUs can be protected, but addresses and other items of PCI must
be visible at the layers below.
$ traffic key
(I) A cryptographic key used by a device for protecting
information that is being transmitted between devices, as opposed
to protecting information that being is maintained in the device.
(Compare: storage key.)
$ traffic padding
(I) "The generation of spurious instances of communication,
spurious data units, and/or spurious data within data units."
[I7498-2]
$ tranquility property
(N) /formal model/ Property of a system whereby the security level
of an object cannot change while the object is being processed by
the system. (See: Bell-LaPadula model.)
$ transaction
1. (I) A unit of interaction between an external entity and a
system, or between components within a system, that involves a
series of system actions or events.
2. (O) "A discrete event between user and systems that supports a
business or programmatic purpose." [M0404]
Tutorial: To maintain secure state, transactions need to be
processed coherently and reliably. Usually, they need to be
designed to be atomic, consistent, isolated, and durable [Gray]:
- "Atomic": All actions and events that comprise the transaction
are guaranteed to be completed successfully, or else the result
is as if none at all were executed.
Shirey Informational [Page 312]
RFC 4949 Internet Security Glossary, Version 2 August 2007
- "Consistent": The transaction satisfies correctness constraints
defined for the data that is being processed.
- "Isolated": If two transactions are performed concurrently,
they do not interfere with each other, and it appears as though
the system performs one at a time.
- "Durable": System state and transaction semantics survive
system failures.
$ TRANSEC
(I) See: transmission security.
$ Transmission Control Code field (TCC field)
(I) A data field that provides a means to segregate traffic and
define controlled communities of interest in the security option
(option type = 130) of IPv4's datagram header format. The TCC
values are alphanumeric trigraphs assigned by the U.S. Government
as specified in RFC 791.
$ Transmission Control Protocol (TCP)
(I) An Internet Standard, Transport-Layer protocol (RFC 793) that
reliably delivers a sequence of datagrams from one computer to
another in a computer network. (See: TCP/IP.)
Tutorial: TCP is designed to fit into a layered suite of protocols
that support internetwork applications. TCP assumes it can obtain
a simple but potentially unreliable end-to-end datagram service
(such as IP) from the lower-layer protocols.
$ transmission security (TRANSEC)
(I) COMSEC measures that protect communications from interception
and exploitation by means other than cryptanalysis. Example:
frequency hopping. (Compare: anti-jam, traffic flow
confidentiality.)
$ Transport Layer
See: Internet Protocol Suite, OSIRM.
$ Transport Layer Security (TLS)
(I) TLS is an Internet protocol [R4346] that is based on, and very
similar to, SSL Version 3.0. (Compare: TLSP.)
Tutorial: The TLS protocol is misnamed. The name misleadingly
suggests that TLS is situated in the IPS Transport Layer, but TLS
is always layered above a reliable Transport-Layer protocol
(usually TCP) and either layered immediately below or integrated
with an Application-Layer protocol (often HTTP).
Shirey Informational [Page 313]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ Transport Layer Security Protocol (TLSP)
(N) An end-to-end encryption protocol (ISO 10736) that provides
security services at the bottom of OSIRM Layer 4, i.e., directly
above Layer 3. (Compare: TLS.)
Tutorial: TLSP evolved directly from SP4.
$ transport mode
(I) One of two ways to apply AH or ESP to protect data packets; in
this mode, the IPsec protocol encapsulates (i.e., the protection
applies to) the packets of an IPS Transport-Layer protocol (e.g.,
TCP, UDP), which normally is carried directly above IP in an IPS
protocol stack. (Compare: tunnel mode.)
Tutorial: An IPsec transport-mode security association is always
between two hosts; neither end has the role of a security gateway.
Whenever either end of an IPsec security association is a security
gateway, the association is required to be in tunnel mode.
$ transposition
(I) /cryptography/ A method of encryption in which elements of the
plain text retain their original form but undergo some change in
their sequential position. (Compare: substitution.)
$ trap door
(I) Synonym for "back door".
$ trespass
(I) /threat action/ See: secondary definition under "intrusion".
$ Triple Data Encryption Algorithm
(I) A block cipher that transforms each 64-bit plaintext block by
applying the DEA three successive times, using either two or three
different keys for an effective key length of 112 or 168 bits.
[A9052, SP67]
Example: A variation proposed for IPsec's ESP uses a 168-bit key,
consisting of three independent 56-bit values used by the DEA, and
a 64-bit initialization vector. Each datagram contains an IV to
ensure that each received datagram can be decrypted even when
other datagrams are dropped or a sequence of datagrams is
reordered in transit. [R1851]
$ triple-wrapped
(I) /S-MIME/ Data that has been signed with a digital signature,
then encrypted, and then signed again. [R2634]
Shirey Informational [Page 314]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ Trojan horse
(I) A computer program that appears to have a useful function, but
also has a hidden and potentially malicious function that evades
security mechanisms, sometimes by exploiting legitimate
authorizations of a system entity that invokes the program. (See:
malware, spyware. Compare: logic bomb, virus, worm.)
$ trust
1. (I) /information system/ A feeling of certainty (sometimes
based on inconclusive evidence) either (a) that the system will
not fail or (b) that the system meets its specifications (i.e.,
the system does what it claims to do and does not perform unwanted
functions). (See: trust level, trusted system, trustworthy system.
Compare: assurance.)
Tutorial: Components of a system can be grouped into three classes
of trust [Gass]:
- "Trusted": The component is responsible for enforcing security
policy on other components; the system's security depends on
flawless operation of the component. (See: trusted process.)
- "Benign": The component is not responsible for enforcing
security policy, but it has sensitive authorizations. It must
be trusted not to intentionally violate security policy, but
security violations are assumed to be accidental and not likely
to affect overall system security.
- "Untrusted": The component is of unknown or suspicious
provenance and must be treated as deliberately malicious. (See:
malicious logic.)
2. (I) /PKI/ A relationship between a certificate user and a CA in
which the user acts according to the assumption that the CA
creates only valid digital certificates.
Tutorial: "Generally, an entity is said to 'trust' a second entity
when the first entity makes the assumption that the second entity
will behave exactly as the first entity expects. This trust may
apply only for some specific function. The key role of trust in
[X.509] is to describe the relationship between an entity [i.e., a
certificate user] and a [CA]; an entity shall be certain that it
can trust the CA to create only valid and reliable certificates."
[X509]
$ trust anchor
(I) /PKI/ An established point of trust (usually based on the
authority of some person, office, or organization) from which a
certificate user begins the validation of a certification path.
(See: apex trust anchor, path validation, trust anchor CA, trust
anchor certificate, trust anchor key.)
Shirey Informational [Page 315]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Usage: IDOCs that use this term SHOULD state a definition for it
because it is used in various ways in existing IDOCs and other PKI
literature. The literature almost always uses this term in a sense
that is equivalent to this definition, but usage often differs
with regard to what constitutes the point of trust.
Tutorial: A trust anchor may be defined as being based on a public
key, a CA, a public-key certificate, or some combination or
variation of those:
- 1. A public key as a point of trust: Although a certification
path is defined as beginning with a "sequence of public-key
certificates", an implementation of a path validation process
might not explicitly handle a root certificate as part of the
path, but instead begin the process by using a trusted root key
to verify the signature on a certificate that was issued by the
root.
Therefore, "trust anchor" is sometimes defined as just a public
key. (See: root key, trust anchor key, trusted key.)
- 2. A CA as a point of trust: A trusted public key is just one
of the data elements needed for path validation; the IPS path
validation algorithm [R3280] also needs the name of the CA to
which that key belongs, i.e., the DN of the issuer of the first
X.509 certificate to be validated on the path. (See: issue.)
Therefore, "trust anchor" is sometimes defined as either just a
CA (where some public key is implied) or as a CA together with
a specified public key belonging to that CA. (See: root, trust
anchor CA, trusted CA.)
Example: "A public key and the name of a [CA] that is used to
validate the first certificate in a sequence of certificates.
The trust anchor public key is used to verify the signature on
a certificate issued by a trust anchor [CA]." [SP57]
- 3. A public-key certificate as a point of trust: Besides the
trusted CA's public key and name, the path validation algorithm
needs to know the digital signature algorithm and any
associated parameters with which the public key is used, and
also any constraints that have been placed on the set of paths
that may be validated using the key. All of this information is
available from a CA's public-key certificate.
Therefore, "trust anchor" is sometimes defined as a public-key
certificate of a CA. (See: root certificate, trust anchor
certificate, trusted certificate.)
Shirey Informational [Page 316]
RFC 4949 Internet Security Glossary, Version 2 August 2007
- 4. Combinations: Combinations and variations of the first three
definitions are also used in the PKI literature.
Example: "trust anchor information". The IPS standard for path
validation [R3280] specifies the information that describes "a
CA that serves as a trust anchor for the certification path.
The trust anchor information includes: (a) the trusted issuer
name, (b) the trusted public key algorithm, (c) the trusted
public key, and (d) optionally, the trusted public key
parameters associated with the public key. The trust anchor
information may be provided to the path processing procedure in
the form of a self-signed certificate. The trusted anchor
information is trusted because it was delivered to the path
processing procedure by some trustworthy out-of-band procedure.
If the trusted public key algorithm requires parameters, then
the parameters are provided along with the trusted public key."
$ trust anchor CA
(I) A CA that is the subject of a trust anchor certificate or
otherwise establishes a trust anchor key. (See: root, trusted CA.)
Tutorial: The selection of a CA to be a trust anchor is a matter
of policy. Some of the possible choices include (a) the top CA in
a hierarchical PKI, (b) the CA that issued the verifier's own
certificate, or (c) any other CA in a network PKI. Different
applications may rely on different trust anchors, or may accept
paths that begin with any of a set of trust anchors. The IPS path
validation algorithm is the same, regardless of the choice.
$ trust anchor certificate
(I) A public-key certificate that is used to provide the first
public key in a certification path. (See: root certificate, trust
anchor, trusted certificate.)
$ trust anchor key
(I) A public key that is used as the first public key in a
certification path. (See: root key, trust anchor, trusted public
key.)
$ trust anchor information
(I) See: secondary definition under "trust anchor".
$ trust chain
(D) Synonym for "certification path". (See: trust anchor, trusted
certificate.)
Shirey Informational [Page 317]
RFC 4949 Internet Security Glossary, Version 2 August 2007
Deprecated Term: IDOCs SHOULD NOT use this term, because it
unnecessarily duplicates the meaning of the internationally
standardized term.
Also, the term mixes concepts in a potentially misleading way.
Having "trust" involves factors unrelated to simply verifying
signatures and performing other tests as specified by a standard
algorithm for path validation (e.g., RFC 3280). Thus, even if a
user is able to validate a certification path algorithmically, the
user still might distrust one of the CAs that issued certificates
in that path or distrust some other aspects of the PKI.
$ trust-file PKI
(I) A non-hierarchical PKI in which each certificate user has its
own local file (which is used by application software) of trust
anchors, i.e., either public keys or public-key certificates that
the user trusts as starting points for certification paths. (See:
trust anchor, web of trust. Compare: hierarchical PKI, mesh PKI.)
Example: Popular browsers are distributed with an initial file of
trust anchor certificates, which often are self-signed
certificates. Users can add certificates to the file or delete
from it. The file may be directly managed by the user, or the
user's organization may manage it from a centralized server.
$ trust hierarchy
(D) Synonym for "certification hierarchy".
Deprecated Usage: IDOCs SHOULD NOT use this term because it mixes
concepts in a potentially misleading way, and because a trust
hierarchy could be implemented in other ways. (See: trust, trust
chain, web of trust.)
$ trust level
(N) A characterization of a standard of security protection to be
met by an information system. (See: Common Criteria, TCSEC.)
Tutorial: A trust level is based not only on (a) the presence of
security mechanisms, but also on the use of (b) systems
engineering discipline to properly structure the system and (c)
implementation analysis to ensure that the system provides an
appropriate degree of trust.
$ trusted
(I) See: secondary definition under "trust".
Shirey Informational [Page 318]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ trusted CA
(I) A CA upon which a certificate user relies as issuing valid
certificates; especially a CA that is used as a trust anchor CA.
(See: certification path, root, trust anchor CA, validation.)
Tutorial. This trust is transitive to the extent that the X.509
certificate extensions permit; that is, if a trusted CA issues a
certificate to another CA, a user that trusts the first CA also
trusts the second CA if the user succeeds in validating the
certificate path (see: path validation).
$ trusted certificate
(I) A digital certificate that a certificate user accepts as being
valid "a priori", i.e., without testing the certificate to
validate it as the final certificate on a certification path;
especially a certificate that is used as a trust anchor
certificate. (See: certification path, root certificate, trust
anchor certificate, trust-file PKI, validation.)
Tutorial: The acceptance of a certificate as trusted is a matter
of policy and choice. Usually, a certificate is accepted as
trusted because the user obtained it by reliable, out-of-band
means that cause the user to believe the certificate accurately
binds its subject's name to the subject's public key or other
attribute values. Many choices are possible; e.g., a trusted
public-key certificate might be (a) the root certificate in a
hierarchical PKI, (b) the certificate of the CA that issued the
user's own certificate in a mesh PKI, or (c) a certificate
provided with an application that uses a trust-file PKI.
$ Trusted Computer System Evaluation Criteria (TCSEC)
(N) A standard for evaluating the security provided by operating
systems [CSC1, DoD1]. Known as the "Orange Book" because of the
color of its cover; first document in the Rainbow Series. (See:
Common Criteria, Deprecated Usage under "Green Book", Orange Book,
trust level, trusted system. Compare: TSEC.)
Tutorial: The TCSEC defines classes of hierarchically ordered
assurance levels for rating computer systems. From highest to
lowest, the classes are as follows:
- Division A: Verified protection.
Beyond A1 Beyond current technology. (See: beyond A1.)
Class A1 Verified design. (See: SCOMP.)
- Division B: Mandatory protection.
Class B3 Security domains.
Class B2 Structured protection. (See: Multics.)
Class B1 Labeled security protection.
Shirey Informational [Page 319]
RFC 4949 Internet Security Glossary, Version 2 August 2007
- Division C: Discretionary protection.
Class C2 Controlled access protection.
Class C1 Discretionary security protection.
- Division D: Minimal protection, i.e., has been evaluated but
does not meet the requirements for a higher evaluation class.
$ trusted computing base (TCB)
(N) "The totality of protection mechanisms within a computer
system, including hardware, firmware, and software, the
combination of which is responsible for enforcing a security
policy." [NCS04] (See: "trusted" under "trust". Compare: TPM.)
$ Trusted Computing Group (TCG)
(N) A not-for-profit, industry standards organization formed to
develop, define, and promote open standards for hardware-enabled
trusted computing and security technologies, including hardware
building blocks and software interfaces, across multiple
platforms, peripherals, and devices. (See: TPM, trusted system.
Compare: TSIG.)
$ trusted distribution
(I) /COMPUSEC/ "A trusted method for distributing the TCB
hardware, software, and firmware components, both originals and
updates, that provides methods for protecting the TCB from
modification during distribution and for detection of any changes
to the TCB that may occur." [NCS04] (See: code signing,
configuration control.)
$ trusted key
(D) Abbreviation for "trusted public key" and also for other types
of keys. (See: root key, trust anchor key.)
Deprecated Usage: IDOCs SHOULD either (a) state a definition for
this term or (b) use a different, less ambiguous term. This term
is ambiguous when it stands alone; e.g., it could refer to a
trusted public key or to a private key or symmetric key that is
believed to be secure (i.e., not compromised).
$ trusted path
1a. (I) /COMPUSEC/ A mechanism by which a computer system user can
communicate directly and reliably with the TCB and that can only
be activated by the user or the TCB and cannot be imitated by
untrusted software within the computer. [NCS04]
1b. (I) /COMSEC/ A mechanism by which a person or process can
communicate directly with a cryptographic module and that can only
be activated by the person, process, or module, and cannot be
imitated by untrusted software within the module. [FP140]
Shirey Informational [Page 320]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ Trusted Platform Module (TPM)
(N) The name of a specification, published by the TCG, for a
microcontroller that can store secured information; and also the
general name of implementations of that specification. (Compare:
TCB.)
$ trusted process
(I) A system component that has privileges that enable it to
affect the state of system security and that can, therefore,
through incorrect or malicious execution, violate the system's
security policy. (See: privileged process, trusted system.)
$ trusted public key
(I) A public key upon which a user relies; especially a public key
that is used as a trust anchor key. (See: certification path, root
key, trust anchor key, validation.)
Tutorial: A trusted public key could be (a) the root key in a
hierarchical PKI, (b) the key of the CA that issued the user's own
certificate in a mesh PKI, or (c) any key accepted by the user in
a trust-file PKI.
$ trusted recovery
(I) A process that, after a system has experienced a failure or an
attack, restores the system to normal operation (or to a secure
state) without causing a security compromise. (See: recovery.)
$ trusted subnetwork
(I) A subnetwork containing hosts and routers that trust each
other not to engage in active or passive attacks. (There also is
an assumption that the underlying communication channels, such as
telephone lines or a LAN, are protected from attack.)
$ trusted system
1. (I) /information system/ A system that operates as expected,
according to design and policy, doing what is required -- despite
environmental disruption, human user and operator errors, and
attacks by hostile parties -- and not doing other things [NRC98].
(See: trust level, trusted process. Compare: trustworthy.)
2. (N) /multilevel secure/ "A [trusted system is a] system that
employs sufficient hardware and software assurance measures to
allow its use for simultaneous processing of a range of sensitive
or classified information." [NCS04] (See: multilevel security
mode.)
Shirey Informational [Page 321]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ Trusted Systems Interoperability Group (TSIG)
(N) A forum of computer vendors, system integrators, and users
devoted to promoting interoperability of trusted computer systems.
(See: trusted system. Compare: TCG.)
$ trustworthy system
1. (I) A system that not only is trusted, but also warrants that
trust because the system's behavior can be validated in some
convincing way, such as through formal analysis or code review.
(See: trust. Compare: trusted.)
2. (O) /Digital Signature Guidelines/ "Computer hardware,
software, and procedures that: (a) are reasonably secure from
intrusion and misuse; (b) provide a reasonably reliable level of
availability, reliability, and correct operation; (c) are
reasonably suited to performing their intended functions; and (d)
adhere to generally accepted security principles." [DSG]
$ TSEC
(O) See: Telecommunications Security Nomenclature System.
(Compare: TCSEC.)
$ TSIG
1. (N) See: Trusted System Interoperability Group.
2. (I) A mnemonic (presumed to be derived from "Transaction
SIGnature") referring to an Internet protocol (RFC 2845) for data
origin authentication and data integrity for certain DNS
operations. (See: TKEY.)
$ tunnel
1. (I) A communication channel created in a computer network by
encapsulating (i.e., layering) a communication protocol's data
packets in (i.e., above) a second protocol that normally would be
carried above, or at the same layer as, the first one. (See: L2TP,
tunnel mode, VPN. Compare: covert channel.)
Tutorial: Tunneling can involve almost any two IPS protocol
layers. For example, a TCP connection between two hosts could
conceivably be carried above SMTP (i.e., in SMTP messages) as a
covert channel to evade access controls that a security gateway
applies to the normal TCP layer that is below SMTP.
Usually, however, a tunnel is a logical point-to-point link --
i.e., an OSIRM Layer 2 connection -- created by encapsulating the
Layer 2 protocol in one of the following three types of IPS
protocols: (a) an IPS Transport-Layer protocol (such as TCP), (b)
an IPS Network-Layer or Internet-Layer protocol (such as IP), or
Shirey Informational [Page 322]
RFC 4949 Internet Security Glossary, Version 2 August 2007
(c) another Layer 2 protocol. In many cases, the encapsulation is
accomplished with an extra, intermediate protocol (i.e., a
"tunneling protocol"; e.g., L2TP) that is layered below the
tunneled Layer 2 protocol and above the encapsulating protocol.
Tunneling can be used to move data between computers that use a
protocol not supported by the network connecting them. Tunneling
also can enable a computer network to use the services of a second
network as though the second network were a set of point-to-point
links between the first network's nodes. (See: VPN.)
2. (O) /SET/ The name of a SET private extension that indicates
whether the CA or the payment gateway supports passing encrypted
messages to the cardholder through the merchant. If so, the
extension lists OIDs of symmetric encryption algorithms that are
supported.
$ tunnel mode
(I) One of two ways to apply the IPsec protocols (AH and ESP) to
protect data packets; in this mode, the IPsec protocol
encapsulates (i.e., the protection applies to) IP packets, rather
than the packets of higher-layer protocols. (See: tunnel. Compare:
transport mode.)
Tutorial: Each end of a tunnel-mode security association may be
either a host or a security gateway. Whenever either end of an
IPsec security association is a security gateway, the association
is required to be in tunnel mode.
$ two-person control
(I) The close surveillance and control of a system, a process, or
materials (especially with regard to cryptography) at all times by
a minimum of two appropriately authorized persons, each capable of
detecting incorrect and unauthorized procedures with respect to
the tasks to be performed and each familiar with established
security requirements. (See: dual control, no-lone zone.)
$ Twofish
(O) A symmetric, 128-bit block cipher with variable key length
(128, 192, or 256 bits), developed by Counterpane Labs as a
candidate for the AES. (See: Blowfish.)
$ type 0 product
(O) /cryptography, U.S. Government/ Classified cryptographic
equipment endorsed by NSA for use (when appropriately keyed) in
electronically distributing bulk keying material.
Shirey Informational [Page 323]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ type 1 key
(O) /cryptography, U.S. Government/ "Generated and distributed
under the auspices of NSA for use in a cryptographic device for
the protection of classified and sensitive national security
information." [C4009]
$ type 1 product
(O) /cryptography, U.S. Government/ "Cryptographic equipment,
assembly or component classified or certified by NSA for
encrypting and decrypting classified and sensitive national
security information when appropriately keyed. Developed using
established NSA business processes and containing NSA approved
algorithms. Used to protect systems requiring the most stringent
protection mechanisms." [C4009]
Tutorial: The current definition of this term is less specific
than an earlier version: "Classified or controlled cryptographic
item endorsed by the NSA for securing classified and sensitive
U.S. Government information, when appropriately keyed. The term
refers only to products, and not to information, key, services, or
controls. Type 1 products contain classified NSA algorithms. They
are available to U.S. Government users, their contractors, and
federally sponsored non-U.S. Government activities subject to
export restrictions in accordance with International Traffic in
Arms Regulation." [from an earlier version of C4009] (See: ITAR.)
$ type 2 key
(O) /cryptography, U.S. Government/ "Generated and distributed
under the auspices of NSA for use in a cryptographic device for
the protection of unclassified national security information."
[C4009]
$ type 2 product
(O) /cryptography, U.S. Government/ "Cryptographic equipment,
assembly, or component certified by NSA for encrypting or
decrypting sensitive national security information when
appropriately keyed. Developed using established NSA business
processes and containing NSA approved algorithms. Used to protect
systems requiring protection mechanisms exceeding best commercial
practices including systems used for the protection of
unclassified national security information." [C4009]
Tutorial: The current definition of this term is less specific
than an earlier version: "Unclassified cryptographic equipment,
assembly, or component, endorsed by the NSA, for use in national
security systems as defined in Title 40 U.S.C. Section 1452."
[from an earlier version of C4009] (See: national security system.
Compare: EUCI.)
Shirey Informational [Page 324]
RFC 4949 Internet Security Glossary, Version 2 August 2007
$ type 3 key
(O) /cryptography, U.S. Government/ "Used in a cryptographic
device for the protection of unclassified sensitive information,
even if used in a Type 1 or Type 2 product." [C4009]
$ type 3 product
(O) /cryptography, U.S. Government/ "Unclassified cryptographic
equipment, assembly, or component used, when appropriately keyed,
for encrypting or decrypting unclassified sensitive U.S.
Government or commercial information, and to protect systems
requiring protection mechanisms consistent with standard
commercial practices. Developed using established commercial
standards and containing NIST approved cryptographic
algorithms/modules or successfully evaluated by the National
Information Assurance Partnership (NIAP)." [C4009]
type 4 key
(O) /cryptography, U.S. Government/ "Used by a cryptographic
device in support of its Type 4 functionality; i.e., any provision
of key that lacks U.S. Government endorsement or oversight."
[C4009]
$ type 4 product
(O) /cryptography, U.S. Government/ "Unevaluated commercial
cryptographic equipment, assemblies, or components that neither
NSA nor NIST certify for any Government usage. These products are
typically delivered as part of commercial offerings and are
commensurate with the vendor's commercial practices. These
products may contain either vendor proprietary algorithms,
algorithms registered by NIST, or algorithms registered by NIST
and published in a FIPS." [C4009]
S <- 4. Definitions -> U