https://DevOpsCloud.io -- Cloud Monk Losang Jinpa

Return to RFC 4949 Internet Security Glossary Definitions, RFC 4949 Internet Security Glossary, RFC 4949 Internet Security Glossary Bibliography, Cybersecurity, Awesome Security

---

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TACACS

(I) See: Terminal Access Controller (TAC) Access Control System.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• tampering

(I) /threat action/ See: secondary definitions under “corruption” and “misuse”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TCB

(N) See: trusted computing base.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TCC field

(I) See: Transmission Control Code field.

Shirey Informational Page 301]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TCG

(N) See: Trusted Computing Group.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TCP

(I) See: Transmission Control Protocol.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TCP/IP

(I) Synonym for “Internet Protocol Suite”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TCSEC

(N) See: Trusted Computer System Evaluation Criteria. (Compare: TSEC.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TDEA

(I) See: Triple Data Encryption Algorithm.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• technical non-repudiation

(I) See: (secondary definition under) non-repudiation.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TELNET

(I) A TCP-based, Application-Layer, Internet Standard protocol (RFC 854) for remote login from one host to another.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TESS

(I) See: The Exponential Encryption System.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• theft

(I) /threat action/ See: secondary definitions under “interception” and “misappropriation”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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. © 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, © 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 © 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”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• threat agent

(I) A system entity that performs a threat action, or an event that results in a threat action.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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).

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• timing channel

(I) See: covert timing channel.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TLS

(I) See: Transport Layer Security.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TLSP

(N) See: Transport Layer Security Protocol.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TOE

(N) See: target of evaluation.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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 id[[entity in an authentication process.

3b. (D) /U.S. Government/ Something that the claimant in an authentication process (i.e., the entity that claims an id[[entity) 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”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• token storage key

(I) A cryptographic key used to protect data that is stored on a security token.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• top CA

(I) Synonym for “root” in a certification hierarchy. (See: apex trust anchor.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TPM

(N) See: Trusted Platform Module.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• traceback

(I) Identification of the source of a data packet. (See: masquerade, network weaving.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• tracker

(N) An attack technique for achieving unauthorized disclosure from a statistical database. [Denns] (See: Tutorial under “inference control”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• traffic-flow analysis

(I) Synonym for “traffic analysis”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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 id[[entity from her competitors. However, the id[[entity 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 id[[entity. 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.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• traffic padding

(I) “The generation of spurious instances of communication, spurious data units, and/or spurious data within data units.” [I7498-2]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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 semantic]s survive [[system failures.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TRANSEC

(I) See: transmission security.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Transport Layer

See: Internet Protocol Suite, OSIRM.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• trap door

(I) Synonym for “back door”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• trespass

(I) /threat action/ See: secondary definition under “intrusion”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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, © 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.”

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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 © 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.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• trust anchor information

(I) See: secondary definition under “trust anchor”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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 © implementation analysis to ensure that the system provides an appropriate degree of trust.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• trusted

(I) See: secondary definition under “trust”.

Shirey Informational Page 318]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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).

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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 © a certificate provided with an application that uses a trust-file PKI.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]] [[domain]]s.
 [[Class]]  B2 [[Structured]] [[protect]]ion. (See: Multics.)
 [[Class]]  B1 [[Label]]ed [[security]] [[protect]]ion.

Shirey Informational Page 319]

RFC 4949 Internet Security Glossary, Version 2 August 2007

- Division C: Discretionary protection.

 [[Class]]  C2 [[Controlled]] [[access]] [[protect]]ion.
 [[Class]]  C1 Discretionary [[security]] [[protect]]ion.

- Division D: Minimal protection, i.e., has been evaluated but does not meet the requirements for a higher evaluation class.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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).

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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 © any key accepted by the user in a trust-file PKI.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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; © are reasonably suited to performing their intended functions; and (d) adhere to generally accepted security principles.” [DSG]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• TSEC

(O) See: Telecommunications Security Nomenclature System. (Compare: TCSEC.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• 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]

---

Fair Use Sources:

• RFC 4949 Internet Security Glossary