7 Network Working Group R. Shirey
8 Request for Comments: 2828 GTE / BBN Technologies
10 Category: Informational
13 Internet Security Glossary
17 This memo provides information for the Internet community. It does
18 not specify an Internet standard of any kind. Distribution of this
23 Copyright (C) The Internet Society (2000). All Rights Reserved.
27 This Glossary (191 pages of definitions and 13 pages of references)
28 provides abbreviations, explanations, and recommendations for use of
29 information system security terminology. The intent is to improve the
30 comprehensibility of writing that deals with Internet security,
31 particularly Internet Standards documents (ISDs). To avoid confusion,
32 ISDs should use the same term or definition whenever the same concept
33 is mentioned. To improve international understanding, ISDs should use
34 terms in their plainest, dictionary sense. ISDs should use terms
35 established in standards documents and other well-founded
36 publications and should avoid substituting private or newly made-up
37 terms. ISDs should avoid terms that are proprietary or otherwise
38 favor a particular vendor, or that create a bias toward a particular
39 security technology or mechanism versus other, competing techniques
40 that already exist or might be developed in the future.
58 Shirey Informational [Page 1]
60 RFC 2828 Internet Security Glossary May 2000
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Explanation of Paragraph Markings . . . . . . . . . . . . . . 4
67 2.1 Recommended Terms with an Internet Basis ("I") . . . . . . 4
68 2.2 Recommended Terms with a Non-Internet Basis ("N") . . . . 5
69 2.3 Other Definitions ("O") . . . . . . . . . . . . . . . . . 5
70 2.4 Deprecated Terms, Definitions, and Uses ("D") . . . . . . 6
71 2.5 Commentary and Additional Guidance ("C") . . . . . . . . . 6
72 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
73 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 197
74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 211
75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 211
76 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 211
77 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 212
81 This Glossary provides an internally consistent, complementary set of
82 abbreviations, definitions, explanations, and recommendations for use
83 of terminology related to information system security. The intent of
84 this Glossary is to improve the comprehensibility of Internet
85 Standards documents (ISDs)--i.e., RFCs, Internet-Drafts, and other
86 material produced as part of the Internet Standards Process [R2026]--
87 and of all other Internet material, too. Some non-security terms are
88 included to make the Glossary self-contained, but more complete lists
89 of networking terms are available elsewhere [R1208, R1983].
91 Some glossaries (e.g., [Raym]) list terms that are not listed here
92 but could be applied to Internet security. However, those terms have
93 not been included in this Glossary because they are not appropriate
96 This Glossary marks terms and definitions as being either endorsed or
97 deprecated for use in ISDs, but this Glossary is not an Internet
98 standard. The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
99 and "OPTIONAL" are intended to be interpreted the same way as in an
100 Internet Standard [R2119], but this guidance represents only the
101 recommendations of this author. However, this Glossary includes
102 reasons for the recommendations--particularly for the SHOULD NOTs--so
103 that readers can judge for themselves whether to follow the
114 Shirey Informational [Page 2]
116 RFC 2828 Internet Security Glossary May 2000
119 This Glossary supports the goals of the Internet Standards Process:
121 o Clear, Concise, and Easily Understood Documentation
123 This Glossary seeks to improve comprehensibility of security-
124 related content of ISDs. That requires wording to be clear and
125 understandable, and requires the set of security-related terms and
126 definitions to be consistent and self-supporting. Also, the
127 terminology needs to be uniform across all ISDs; i.e., the same
128 term or definition needs to be used whenever and wherever the same
129 concept is mentioned. Harmonization of existing ISDs need not be
130 done immediately, but it is desirable to correct and standardize
131 the terminology when new versions are issued in the normal course
132 of standards development and evolution.
134 o Technical Excellence
136 Just as Internet Standard (STD) protocols should operate
137 effectively, ISDs should use terminology accurately, precisely,
138 and unambiguously to enable Internet Standards to be implemented
141 o Prior Implementation and Testing
143 Just as STD protocols require demonstrated experience and
144 stability before adoption, ISDs need to use well-established
145 language. Using terms in their plainest, dictionary sense (when
146 appropriate) helps to ensure international understanding. ISDs
147 need to avoid using private, made-up terms in place of generally-
148 accepted terms from standards and other publications. ISDs need to
149 avoid substituting new definitions that conflict with established
150 ones. ISDs need to avoid using "cute" synonyms (e.g., see: Green
151 Book); no matter how popular a nickname may be in one community,
152 it is likely to cause confusion in another.
154 o Openness, Fairness, and Timeliness
156 ISDs need to avoid terms that are proprietary or otherwise favor a
157 particular vendor, or that create a bias toward a particular
158 security technology or mechanism over other, competing techniques
159 that already exist or might be developed in the future. The set of
160 terminology used across the set of ISDs needs to be flexible and
161 adaptable as the state of Internet security art evolves.
170 Shirey Informational [Page 3]
172 RFC 2828 Internet Security Glossary May 2000
175 2. Explanation of Paragraph Markings
177 Section 3 marks terms and definitions as follows:
179 o Capitalization: Only terms that are proper nouns are capitalized.
181 o Paragraph Marking: Definitions and explanations are stated in
182 paragraphs that are marked as follows:
184 - "I" identifies a RECOMMENDED Internet definition.
185 - "N" identifies a RECOMMENDED non-Internet definition.
186 - "O" identifies a definition that is not recommended as the first
187 choice for Internet documents but is something that authors of
188 Internet documents need to know.
189 - "D" identifies a term or definition that SHOULD NOT be used in
191 - "C" identifies commentary or additional usage guidance.
193 The rest of Section 2 further explains these five markings.
195 2.1 Recommended Terms with an Internet Basis ("I")
197 The paragraph marking "I" (as opposed to "O") indicates a definition
198 that SHOULD be the first choice for use in ISDs. Most terms and
199 definitions of this type MAY be used in ISDs; however, some "I"
200 definitions are accompanied by a "D" paragraph that recommends
201 against using the term. Also, some "I" definitions are preceded by an
202 indication of a contextual usage limitation (e.g., see:
203 certification), and ISDs should not the term and definition outside
206 An "I" (as opposed to an "N") also indicates that the definition has
207 an Internet basis. That is, either the Internet Standards Process is
208 authoritative for the term, or the term is sufficiently generic that
209 this Glossary can freely state a definition without contradicting a
210 non-Internet authority (e.g., see: attack).
212 Many terms with "I" definitions are proper nouns (e.g., see:
213 Internet Protocol). For such terms, the "I" definition is intended
214 only to provide basic information; the authoritative definition is
217 For a proper noun identified as an "Internet protocol", please refer
218 to the current edition of "Internet Official Protocol Standards" (STD
219 1) for the standardization state and status of the protocol.
226 Shirey Informational [Page 4]
228 RFC 2828 Internet Security Glossary May 2000
231 2.2 Recommended Terms with a Non-Internet Basis ("N")
233 The paragraph marking "N" (as opposed to "O") indicates a definition
234 that SHOULD be the first choice for the term, if the term is used at
235 all in Internet documents. Terms and definitions of this type MAY be
236 used in Internet documents (e.g., see: X.509 public-key certificate).
238 However, an "N" (as opposed to an "I") also indicates a definition
239 that has a non-Internet basis or origin. Many such definitions are
240 preceded by an indication of a contextual usage limitation, and this
241 Glossary's endorsement does not apply outside that context. Also,
242 some contexts are rarely if ever expected to occur in a Internet
243 document (e.g., see: baggage). In those cases, the listing exists to
244 make Internet authors aware of the non-Internet usage so that they
245 can avoid conflicts with non-Internet documents.
247 Many terms with "N" definitions are proper nouns (e.g., see:
248 Computer Security Objects Register). For such terms, the "N"
249 definition is intended only to provide basic information; the
250 authoritative definition is found elsewhere.
252 2.3 Other Definitions ("O")
254 The paragraph marking "O" indicates a definition that has a non-
255 Internet basis, but indicates that the definition SHOULD NOT be used
256 in ISDs *except* in cases where the term is specifically identified
259 For example, an ISD might mention "BCA" (see: brand certification
260 authority) or "baggage" as an example to illustrate some concept; in
261 that case, the document should specifically say "SET(trademark) BCA"
262 or "SET(trademark) baggage" and include the definition of the term.
264 For some terms that have a definition published by a non-Internet
265 authority--government (see: object reuse), industry (see: Secure Data
266 Exchange), national (see: Data Encryption Standard), or international
267 (see: data confidentiality)--this Glossary marks the definition "N",
268 recommending its use in Internet documents. In other cases, the non-
269 Internet definition of a term is inadequate or inappropriate for
270 ISDs. For example, it may be narrow or outdated, or it may need
271 clarification by substituting more careful or more explanatory
272 wording using other terms that are defined in this Glossary. In those
273 cases, this Glossary marks the tern "O" and provides an "I"
274 definition (or sometimes a different "N" definition), which precedes
275 and supersedes the definition marked "O".
282 Shirey Informational [Page 5]
284 RFC 2828 Internet Security Glossary May 2000
287 In most of the cases where this Glossary provides a definition to
288 supersede one from a non-Internet standard, the substitute is
289 intended to subsume the meaning of the superseded "O" definition and
290 not conflict with it. For the term "security service", for example,
291 the "O" definition deals narrowly with only communication services
292 provided by layers in the OSI model and is inadequate for the full
293 range of ISD usage; the "I" definition can be used in more situations
294 and for more kinds of service. However, the "O" definition is also
295 provided here so that ISD authors will be aware of the context in
296 which the term is used more narrowly.
298 When making substitutions, this Glossary attempts to use
299 understandable English that does not contradict any non-Internet
300 authority. Still, terminology differs between the standards of the
301 American Bar Association, OSI, SET, the U.S. Department of Defense,
302 and other authorities, and this Glossary probably is not exactly
303 aligned with all of them.
305 2.4 Deprecated Terms, Definitions, and Uses ("D")
307 If this Glossary recommends that a term or definition SHOULD NOT be
308 used in ISDs, then either the definition has the paragraph marking
309 "D", or the restriction is stated in a "D" paragraph that immediately
310 follows the term or definition.
312 2.5 Commentary and Additional Guidance ("C")
314 The paragraph marking "C" identifies text that is advisory or
315 tutorial. This text MAY be reused in other Internet documents. This
316 text is not intended to be authoritative, but is provided to clarify
317 the definitions and to enhance this Glossary so that Internet
318 security novices can use it as a tutorial.
322 Note: Each acronym or other abbreviation (except items of common
323 English usage, such as "e.g.", "etc.", "i.e.", "vol.", "pp.", "U.S.")
324 that is used in this Glossary, either in a definition or as a subpart
325 of a defined term, is also defined in this Glossary.
331 (N) (Pronounced "star property".) See: "confinement property"
332 under Bell-LaPadula Model.
338 Shirey Informational [Page 6]
340 RFC 2828 Internet Security Glossary May 2000
344 (N) "American Bar Association (ABA) Digital Signature Guidelines"
345 [ABA], a framework of legal principles for using digital
346 signatures and digital certificates in electronic commerce.
348 $ Abstract Syntax Notation One (ASN.1)
349 (N) A standard for describing data objects. [X680]
351 (C) OSI standards use ASN.1 to specify data formats for protocols.
352 OSI defines functionality in layers. Information objects at higher
353 layers are abstractly defined to be implemented with objects at
354 lower layers. A higher layer may define transfers of abstract
355 objects between computers, and a lower layer may define transfers
356 concretely as strings of bits. Syntax is needed to define abstract
357 objects, and encoding rules are needed to transform between
358 abstract objects and bit strings. (See: Basic Encoding Rules.)
360 (C) In ASN.1, formal names are written without spaces, and
361 separate words in a name are indicated by capitalizing the first
362 letter of each word except the first word. For example, the name
363 of a CRL is "certificateRevocationList".
366 See: access control center.
369 (I) The ability and means to communicate with or otherwise
370 interact with a system in order to use system resources to either
371 handle information or gain knowledge of the information the system
374 (O) "A specific type of interaction between a subject and an
375 object that results in the flow of information from one to the
378 (C) In this Glossary, "access" is intended to cover any ability to
379 communicate with a system, including one-way communication in
380 either direction. In actual practice, however, entities outside a
381 security perimeter that can receive output from the system but
382 cannot provide input or otherwise directly interact with the
383 system, might be treated as not having "access" and, therefore, be
384 exempt from security policy requirements, such as the need for a
388 (I) Protection of system resources against unauthorized access; a
389 process by which use of system resources is regulated according to
390 a security policy and is permitted by only authorized entities
394 Shirey Informational [Page 7]
396 RFC 2828 Internet Security Glossary May 2000
399 (users, programs, processes, or other systems) according to that
400 policy. (See: access, access control service.)
402 (O) "The prevention of unauthorized use of a resource, including
403 the prevention of use of a resource in an unauthorized manner."
406 $ access control center (ACC)
407 (I) A computer containing a database with entries that define a
408 security policy for an access control service.
410 (C) An ACC is sometimes used in conjunction with a key center to
411 implement access control in a key distribution system for
412 symmetric cryptography.
414 $ access control list (ACL)
415 (I) A mechanism that implements access control for a system
416 resource by enumerating the identities of the system entities that
417 are permitted to access the resource. (See: capability.)
419 $ access control service
420 (I) A security service that protects against a system entity using
421 a system resource in a way not authorized by the system's security
422 policy; in short, protection of system resources against
423 unauthorized access. (See: access control, discretionary access
424 control, identity-based security policy, mandatory access control,
425 rule-based security policy.)
427 (C) This service includes protecting against use of a resource in
428 an unauthorized manner by an entity that is authorized to use the
429 resource in some other manner. The two basic mechanisms for
430 implementing this service are ACLs and tickets.
433 (I) A distinct type of data processing operation--e.g., read,
434 write, append, or execute--that a subject can potentially perform
435 on an object in a computer system.
438 (I) The property of a system (including all of its system
439 resources) that ensures that the actions of a system entity may be
440 traced uniquely to that entity, which can be held responsible for
441 its actions. (See: audit service.)
443 (C) Accountability permits detection and subsequent investigation
444 of security breaches.
450 Shirey Informational [Page 8]
452 RFC 2828 Internet Security Glossary May 2000
457 (I) An administrative declaration by a designated authority that
458 an information system is approved to operate in a particular
459 security configuration with a prescribed set of safeguards.
460 [FP102] (See: certification.)
462 (C) An accreditation is usually based on a technical certification
463 of the system's security mechanisms. The terms "certification" and
464 "accreditation" are used more in the U.S. Department of Defense
465 and other government agencies than in commercial organizations.
466 However, the concepts apply any place where managers are required
467 to deal with and accept responsibility for security risks. The
468 American Bar Association is developing accreditation criteria for
472 See: access control list.
475 (N) SET usage: "The financial institution that establishes an
476 account with a merchant and processes payment card authorizations
477 and payments." [SET1]
479 (O) "The institution (or its agent) that acquires from the card
480 acceptor the financial data relating to the transaction and
481 initiates that data into an interchange system." [SET2]
484 See: (secondary definition under) attack.
487 See: (secondary definition under) wiretapping.
490 (I) "The retrofitting of protection mechanisms, implemented by
491 hardware or software, after the [automatic data processing] system
492 has become operational." [FP039]
494 $ administrative security
495 (I) Management procedures and constraints to prevent unauthorized
496 access to a system. (See: security architecture.)
498 (O) "The management constraints, operational procedures,
499 accountability procedures, and supplemental controls established
500 to provide an acceptable level of protection for sensitive data."
506 Shirey Informational [Page 9]
508 RFC 2828 Internet Security Glossary May 2000
511 (C) Examples include clear delineation and separation of duties,
512 and configuration control.
514 $ Advanced Encryption Standard (AES)
515 (N) A future FIPS publication being developed by NIST to succeed
516 DES. Intended to specify an unclassified, publicly-disclosed,
517 symmetric encryption algorithm, available royalty-free worldwide.
520 (I) An entity that attacks, or is a threat to, a system.
523 (I) A circumstance in which a collection of information items is
524 required to be classified at a higher security level than any of
525 the individual items that comprise it.
528 See: Authentication Header
531 (I) A finite set of step-by-step instructions for a problem-
532 solving or computation procedure, especially one that can be
533 implemented by a computer. (See: cryptographic algorithm.)
536 (I) A name that an entity uses in place of its real name, usually
537 for the purpose of either anonymity or deception.
539 $ American National Standards Institute (ANSI)
540 (N) A private, not-for-profit association of users, manufacturers,
541 and other organizations, that administers U.S. private sector
544 (C) ANSI is the sole U.S. representative to the two major non-
545 treaty international standards organizations, ISO and, via the
546 U.S. National Committee (USNC), the International Electrotechnical
550 (I) The condition of having a name that is unknown or concealed.
551 (See: anonymous login.)
553 (C) An application may require security services that maintain
554 anonymity of users or other system entities, perhaps to preserve
555 their privacy or hide them from attack. To hide an entity's real
556 name, an alias may be used. For example, a financial institution
557 may assign an account number. Parties to a transaction can thus
558 remain relatively anonymous, but can also accept the transaction
562 Shirey Informational [Page 10]
564 RFC 2828 Internet Security Glossary May 2000
567 as legitimate. Real names of the parties cannot be easily
568 determined by observers of the transaction, but an authorized
569 third party may be able to map an alias to a real name, such as by
570 presenting the institution with a court order. In other
571 applications, anonymous entities may be completely untraceable.
574 (I) An access control feature (or, rather, an access control
575 weakness) in many Internet hosts that enables users to gain access
576 to general-purpose or public services and resources on a host
577 (such as allowing any user to transfer data using File Transfer
578 Protocol) without having a pre-established, user-specific account
579 (i.e., user name and secret password).
581 (C) This feature exposes a system to more threats than when all
582 the users are known, pre-registered entities that are individually
583 accountable for their actions. A user logs in using a special,
584 publicly known user name (e.g., "anonymous", "guest", or "ftp").
585 To use the public login name, the user is not required to know a
586 secret password and may not be required to input anything at all
587 except the name. In other cases, to complete the normal sequence
588 of steps in a login protocol, the system may require the user to
589 input a matching, publicly known password (such as "anonymous") or
590 may ask the user for an e-mail address or some other arbitrary
597 (I) (1.) Noun: A collection of data that is stored for a
598 relatively long period of time for historical and other purposes,
599 such as to support audit service, availability service, or system
600 integrity service. (See: backup.) (2.) Verb: To store data in such
601 a way. (See: back up.)
603 (C) A digital signature may need to be verified many years after
604 the signing occurs. The CA--the one that issued the certificate
605 containing the public key needed to verify that signature--may not
606 stay in operation that long. So every CA needs to provide for
607 long-term storage of the information needed to verify the
608 signatures of those to whom it issues certificates.
611 (N) Advanced Research Projects Agency Network, a pioneer packet-
612 switched network that was built in the early 1970s under contract
613 to the U.S. Government, led to the development of today's
614 Internet, and was decommissioned in June 1990.
618 Shirey Informational [Page 11]
620 RFC 2828 Internet Security Glossary May 2000
624 See: Abstract Syntax Notation One.
627 (I) A cooperative relationship between system entities, usually
628 for the purpose of transferring information between them. (See:
629 security association.)
632 (I) (1.) An attribute of an information system that provides
633 grounds for having confidence that the system operates such that
634 the system security policy is enforced. (2.) A procedure that
635 ensures a system is developed and operated as intended by the
636 system's security policy.
639 (I) Evaluation usage: A specific level on a hierarchical scale
640 representing successively increased confidence that a target of
641 evaluation adequately fulfills the requirements. (E.g., see:
644 $ asymmetric cryptography
645 (I) A modern branch of cryptography (popularly known as "public-
646 key cryptography") in which the algorithms employ a pair of keys
647 (a public key and a private key) and use a different component of
648 the pair for different steps of the algorithm. (See: key pair.)
650 (C) Asymmetric algorithms have key management advantages over
651 equivalently strong symmetric ones. First, one key of the pair
652 does not need to be known by anyone but its owner; so it can more
653 easily be kept secret. Second, although the other key of the pair
654 is shared by all entities that use the algorithm, that key does
655 not need to be kept secret from other, non-using entities; so the
656 key distribution part of key management can be done more easily.
658 (C) For encryption: In an asymmetric encryption algorithm (e.g.,
659 see: RSA), when Alice wants to ensure confidentiality for data she
660 sends to Bob, she encrypts the data with a public key provided by
661 Bob. Only Bob has the matching private key that is needed to
664 (C) For signature: In an asymmetric digital signature algorithm
665 (e.g., see: DSA), when Alice wants to ensure data integrity or
666 provide authentication for data she sends to Bob, she uses her
667 private key to sign the data (i.e., create a digital signature
668 based on the data). To verify the signature, Bob uses the matching
669 public key that Alice has provided.
674 Shirey Informational [Page 12]
676 RFC 2828 Internet Security Glossary May 2000
679 (C) For key agreement: In an asymmetric key agreement algorithm
680 (e.g., see: Diffie-Hellman), Alice and Bob each send their own
681 public key to the other person. Then each uses their own private
682 key and the other's public key to compute the new key value.
685 (I) An assault on system security that derives from an intelligent
686 threat, i.e., an intelligent act that is a deliberate attempt
687 (especially in the sense of a method or technique) to evade
688 security services and violate the security policy of a system.
689 (See: penetration, violation, vulnerability.)
691 - Active vs. passive: An "active attack" attempts to alter system
692 resources or affect their operation. A "passive attack"
693 attempts to learn or make use of information from the system
694 but does not affect system resources. (E.g., see: wiretapping.)
696 - Insider vs. outsider: An "inside attack" is an attack initiated
697 by an entity inside the security perimeter (an "insider"),
698 i.e., an entity that is authorized to access system resources
699 but uses them in a way not approved by those who granted the
700 authorization. An "outside attack" is initiated from outside
701 the perimeter, by an unauthorized or illegitimate user of the
702 system (an "outsider"). In the Internet, potential outside
703 attackers range from amateur pranksters to organized criminals,
704 international terrorists, and hostile governments.
706 (C) The term "attack" relates to some other basic security terms
707 as shown in the following diagram:
709 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+
710 | An Attack: | |Counter- | | A System Resource: |
711 | i.e., A Threat Action | | measure | | Target of the Attack |
712 | +----------+ | | | | +-----------------+ |
713 | | Attacker |<==================||<========= | |
714 | | i.e., | Passive | | | | | Vulnerability | |
715 | | A Threat |<=================>||<========> | |
716 | | Agent | or Active | | | | +-------|||-------+ |
717 | +----------+ Attack | | | | VVV |
718 | | | | | Threat Consequences |
719 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+
721 $ attribute authority
722 (I) A CA that issues attribute certificates.
724 (O) "An authority, trusted by the verifier to delegate privilege,
725 which issues attribute certificates." [FPDAM]
730 Shirey Informational [Page 13]
732 RFC 2828 Internet Security Glossary May 2000
735 $ attribute certificate
736 (I) A digital certificate that binds a set of descriptive data
737 items, other than a public key, either directly to a subject name
738 or to the identifier of another certificate that is a public-key
741 (O) "A set of attributes of a user together with some other
742 information, rendered unforgeable by the digital signature created
743 using the private key of the CA which issued it." [X509]
745 (O) "A data structure that includes some attribute values and
746 identification information about the owner of the attribute
747 certificate, all digitally signed by an Attribute Authority. This
748 authority's signature serves as the guarantee of the binding
749 between the attributes and their owner." [FPDAM]
751 (C) A public-key certificate binds a subject name to a public key
752 value, along with information needed to perform certain
753 cryptographic functions. Other attributes of a subject, such as a
754 security clearance, may be certified in a separate kind of digital
755 certificate, called an attribute certificate. A subject may have
756 multiple attribute certificates associated with its name or with
757 each of its public-key certificates.
759 (C) An attribute certificate might be issued to a subject in the
760 following situations:
762 - Different lifetimes: When the lifetime of an attribute binding
763 is shorter than that of the related public-key certificate, or
764 when it is desirable not to need to revoke a subject's public
765 key just to revoke an attribute.
767 - Different authorities: When the authority responsible for the
768 attributes is different than the one that issues the public-key
769 certificate for the subject. (There is no requirement that an
770 attribute certificate be issued by the same CA that issued the
771 associated public-key certificate.)
774 (I) A security service that records information needed to
775 establish accountability for system events and for the actions of
776 system entities that cause them. (See: security audit.)
779 See: security audit trail.
786 Shirey Informational [Page 14]
788 RFC 2828 Internet Security Glossary May 2000
794 $ authentic signature
795 (I) A signature (particularly a digital signature) that can be
796 trusted because it can be verified. (See: validate vs. verify.)
799 (I) Verify (i.e., establish the truth of) an identity claimed by
800 or for a system entity. (See: authentication.)
802 (D) In general English usage, this term usually means "to prove
803 genuine" (e.g., an art expert authenticates a Michelangelo
804 painting). But the recommended definition carries a much narrower
805 meaning. For example, to be precise, an ISD SHOULD NOT say "the
806 host authenticates each received datagram". Instead, the ISD
807 SHOULD say "the host authenticates the origin of each received
808 datagram". In most cases, we also can say "and verifies the
809 datagram's integrity", because that is usually implied. (See:
810 ("relationship between data integrity service and authentication
811 services" under) data integrity service.)
813 (D) ISDs SHOULD NOT talk about authenticating a digital signature
814 or digital certificate. Instead, we "sign" and then "verify"
815 digital signatures, and we "issue" and then "validate" digital
816 certificates. (See: validate vs. verify.)
819 (I) The process of verifying an identity claimed by or for a
820 system entity. (See: authenticate, authentication exchange,
821 authentication information, credential, data origin
822 authentication, peer entity authentication.)
824 (C) An authentication process consists of two steps:
826 1. Identification step: Presenting an identifier to the security
827 system. (Identifiers should be assigned carefully, because
828 authenticated identities are the basis for other security
829 services, such as access control service.)
831 2. Verification step: Presenting or generating authentication
832 information that corroborates the binding between the entity
833 and the identifier. (See: verification.)
835 (C) See: ("relationship between data integrity service and
836 authentication services" under) data integrity service.
842 Shirey Informational [Page 15]
844 RFC 2828 Internet Security Glossary May 2000
847 $ authentication code
848 (D) ISDs SHOULD NOT use this term as a synonym for any form of
849 checksum, whether cryptographic or not. The word "authentication"
850 is misleading because the mechanism involved usually serves a data
851 integrity function rather than an authentication function, and the
852 word "code" is misleading because it implies that either encoding
853 or encryption is involved or that the term refers to computer
854 software. (See: message authentication code.)
856 $ authentication exchange
857 (I) A mechanism to verify the identity of an entity by means of
858 information exchange.
860 (O) "A mechanism intended to ensure the identity of an entity by
861 means of information exchange." [I7498 Part 2]
863 $ Authentication Header (AH)
864 (I) An Internet IPsec protocol [R2402] designed to provide
865 connectionless data integrity service and data origin
866 authentication service for IP datagrams, and (optionally) to
867 provide protection against replay attacks.
869 (C) Replay protection may be selected by the receiver when a
870 security association is established. AH authenticates upper-layer
871 protocol data units and as much of the IP header as possible.
872 However, some IP header fields may change in transit, and the
873 value of these fields, when the packet arrives at the receiver,
874 may not be predictable by the sender. Thus, the values of such
875 fields cannot be protected end-to-end by AH; protection of the IP
876 header by AH is only partial when such fields are present.
878 (C) AH may be used alone, or in combination with the IPsec ESP
879 protocol, or in a nested fashion with tunneling. Security services
880 can be provided between a pair of communicating hosts, between a
881 pair of communicating security gateways, or between a host and a
882 gateway. ESP can provide the same security services as AH, and ESP
883 can also provide data confidentiality service. The main difference
884 between authentication services provided by ESP and AH is the
885 extent of the coverage; ESP does not protect IP header fields
886 unless they are encapsulated by AH.
888 $ authentication information
889 (I) Information used to verify an identity claimed by or for an
890 entity. (See: authentication, credential.)
892 (C) Authentication information may exist as, or be derived from,
893 one of the following:
898 Shirey Informational [Page 16]
900 RFC 2828 Internet Security Glossary May 2000
903 - Something the entity knows. (See: password).
904 - Something the entity possesses. (See: token.)
905 - Something the entity is. (See: biometric authentication.)
907 $ authentication service
908 (I) A security service that verifies an identity claimed by or for
909 an entity. (See: authentication.)
911 (C) In a network, there are two general forms of authentication
912 service: data origin authentication service and peer entity
913 authentication service.
916 (I) The property of being genuine and able to be verified and be
917 trusted. (See: authenticate, authentication, validate vs. verify)
920 (D) "An entity, responsible for the issuance of certificates."
923 (C) ISDs SHOULD NOT use this term as a synonym for AA, CA, RA,
924 ORA, or similar terms, because it may cause confusion. Instead,
925 use the full term at the first instance of usage and then, if it
926 is necessary to shorten text, use the style of abbreviation
927 defined in this Glossary.
929 (C) ISDs SHOULD NOT use this definition for any PKI entity,
930 because the definition is ambiguous with regard to whether the
931 entity actually issues certificates (e.g., attribute authority or
932 certification authority) or just has accountability for processes
933 that precede or follow signing (e.g., registration authority).
936 $ authority certificate
937 (D) "A certificate issued to an authority (e.g. either to a
938 certification authority or to an attribute authority)." [FPDAM]
941 (C) ISDs SHOULD NOT use this term or definition because they are
942 ambiguous with regard to which specific types of PKI entities they
945 $ authority revocation list (ARL)
946 (I) A data structure that enumerates digital certificates that
947 were issued to CAs but have been invalidated by their issuer prior
948 to when they were scheduled to expire. (See: certificate
949 expiration, X.509 authority revocation list.)
954 Shirey Informational [Page 17]
956 RFC 2828 Internet Security Glossary May 2000
959 (O) "A revocation list containing a list of public-key
960 certificates issued to authorities, which are no longer considered
961 valid by the certificate issuer." [FPDAM]
965 (I) (1.) An "authorization" is a right or a permission that is
966 granted to a system entity to access a system resource. (2.) An
967 "authorization process" is a procedure for granting such rights.
968 (3.) To "authorize" means to grant such a right or permission.
971 (O) SET usage: "The process by which a properly appointed person
972 or persons grants permission to perform some action on behalf of
973 an organization. This process assesses transaction risk, confirms
974 that a given transaction does not raise the account holder's debt
975 above the account's credit limit, and reserves the specified
976 amount of credit. (When a merchant obtains authorization, payment
977 for the authorized amount is guaranteed--provided, of course, that
978 the merchant followed the rules associated with the authorization
981 $ automated information system
982 (I) An organized assembly of resources and procedures--i.e.,
983 computing and communications equipment and services, with their
984 supporting facilities and personnel--that collect, record,
985 process, store, transport, retrieve, or display information to
986 accomplish a specified set of functions.
989 (I) The property of a system or a system resource being accessible
990 and usable upon demand by an authorized system entity, according
991 to performance specifications for the system; i.e., a system is
992 available if it provides services according to the system design
993 whenever users request them. (See: critical, denial of service,
994 reliability, survivability.)
996 (O) "The property of being accessible and usable upon demand by an
997 authorized entity." [I7498 Part 2]
999 $ availability service
1000 (I) A security service that protects a system to ensure its
1003 (C) This service addresses the security concerns raised by denial-
1004 of-service attacks. It depends on proper management and control of
1005 system resources, and thus depends on access control service and
1006 other security services.
1010 Shirey Informational [Page 18]
1012 RFC 2828 Internet Security Glossary May 2000
1016 (I) A hardware or software mechanism that (a) provides access to a
1017 system and its resources by other than the usual procedure, (b)
1018 was deliberately left in place by the system's designers or
1019 maintainers, and (c) usually is not publicly known. (See: trap
1022 (C) For example, a way to access a computer other than through a
1023 normal login. Such access paths do not necessarily have malicious
1024 intent; e.g., operating systems sometimes are shipped by the
1025 manufacturer with privileged accounts intended for use by field
1026 service technicians or the vendor's maintenance programmers. (See:
1029 $ back up vs. backup
1030 (I) Verb "back up": To store data for the purpose of creating a
1031 backup copy. (See: archive.)
1033 (I) Noun/adjective "backup": (1.) A reserve copy of data that is
1034 stored separately from the original, for use if the original
1035 becomes lost or damaged. (See: archive.) (2.) Alternate means to
1036 permit performance of system functions despite a disaster to
1037 system resources. (See: contingency plan.)
1040 (D) ISDs SHOULD NOT use this term to describe a data element
1041 except when stated as "SET(trademark) baggage" with the following
1044 (O) SET usage: An "opaque encrypted tuple, which is included in a
1045 SET message but appended as external data to the PKCS encapsulated
1046 data. This avoids superencryption of the previously encrypted
1047 tuple, but guarantees linkage with the PKCS portion of the
1051 (I) Commonly used to mean the capacity of a communication channel
1052 to pass data through the channel in a given amount of time.
1053 Usually expressed in bits per second.
1055 $ bank identification number (BIN)
1056 (N) The digits of a credit card number that identify the issuing
1057 bank. (See: primary account number.)
1059 (O) SET usage: The first six digits of a primary account number.
1066 Shirey Informational [Page 19]
1068 RFC 2828 Internet Security Glossary May 2000
1071 $ Basic Encoding Rules (BER)
1072 (I) A standard for representing ASN.1 data types as strings of
1073 octets. [X690] (See: Distinguished Encoding Rules.)
1076 (I) A strongly protected computer that is in a network protected
1077 by a firewall (or is part of a firewall) and is the only host (or
1078 one of only a few hosts) in the network that can be directly
1079 accessed from networks on the other side of the firewall.
1081 (C) Filtering routers in a firewall typically restrict traffic
1082 from the outside network to reaching just one host, the bastion
1083 host, which usually is part of the firewall. Since only this one
1084 host can be directly attacked, only this one host needs to be very
1085 strongly protected, so security can be maintained more easily and
1086 less expensively. However, to allow legitimate internal and
1087 external users to access application resources through the
1088 firewall, higher layer protocols and services need to be relayed
1089 and forwarded by the bastion host. Some services (e.g., DNS and
1090 SMTP) have forwarding built in; other services (e.g., TELNET and
1091 FTP) require a proxy server on the bastion host.
1094 See: brand certification authority.
1097 See: brand CRL identifier.
1099 $ Bell-LaPadula Model
1100 (N) A formal, mathematical, state-transition model of security
1101 policy for multilevel-secure computer systems. [Bell]
1103 (C) The model separates computer system elements into a set of
1104 subjects and a set of objects. To determine whether or not a
1105 subject is authorized for a particular access mode on an object,
1106 the clearance of the subject is compared to the classification of
1107 the object. The model defines the notion of a "secure state", in
1108 which the only permitted access modes of subjects to objects are
1109 in accordance with a specified security policy. It is proven that
1110 each state transition preserves security by moving from secure
1111 state to secure state, thereby proving that the system is secure.
1113 (C) In this model, a multilevel-secure system satisfies several
1114 rules, including the following:
1122 Shirey Informational [Page 20]
1124 RFC 2828 Internet Security Glossary May 2000
1127 - "Confinement property" (also called "*-property", pronounced
1128 "star property"): A subject has write access to an object only
1129 if classification of the object dominates the clearance of the
1132 - "Simple security property": A subject has read access to an
1133 object only if the clearance of the subject dominates the
1134 classification of the object.
1136 - "Tranquillity property": The classification of an object does
1137 not change while the object is being processed by the system.
1140 See: Basic Encoding Rules.
1143 (O) (1.) Formally, a level of security assurance that is beyond
1144 the highest level of criteria specified by the TCSEC. (2.)
1145 Informally, a level of trust so high that it cannot be provided or
1146 verified by currently available assurance methods, and
1147 particularly not by currently available formal methods.
1150 See: bank identification number.
1153 (I) To inseparably associate by applying some mechanism, such as
1154 when a CA uses a digital signature to bind together a subject and
1155 a public key in a public-key certificate.
1157 $ biometric authentication
1158 (I) A method of generating authentication information for a person
1159 by digitizing measurements of a physical characteristic, such as a
1160 fingerprint, a hand shape, a retina pattern, a speech pattern
1161 (voiceprint), or handwriting.
1164 (I) The smallest unit of information storage; a contraction of the
1165 term "binary digit"; one of two symbols--"0" (zero) and "1" (one)
1166 --that are used to represent binary numbers.
1169 (I) Designation for information system equipment or facilities
1170 that handle (and for data that contains) only ciphertext (or,
1171 depending on the context, only unclassified information), and for
1172 such data itself. This term derives from U.S. Government COMSEC
1173 terminology. (See: RED, RED/BLACK separation.)
1178 Shirey Informational [Page 21]
1180 RFC 2828 Internet Security Glossary May 2000
1184 (I) An encryption algorithm that breaks plaintext into fixed-size
1185 segments and uses the same key to transform each plaintext segment
1186 into a fixed-size segment of ciphertext. (See: mode, stream
1189 (C) For example, Blowfish, DEA, IDEA, RC2, and SKIPJACK. However,
1190 a block cipher can be adapted to have a different external
1191 interface, such as that of a stream cipher, by using a mode of
1192 operation to "package" the basic algorithm.
1195 (N) A symmetric block cipher with variable-length key (32 to 448
1196 bits) designed in 1993 by Bruce Schneier as an unpatented,
1197 license-free, royalty-free replacement for DES or IDEA. [Schn]
1200 (I) A distinctive mark or name that identifies a product or
1203 (O) SET usage: The name of a payment card. Financial institutions
1204 and other companies have founded payment card brands, protect and
1205 advertise the brands, establish and enforce rules for use and
1206 acceptance of their payment cards, and provide networks to
1207 interconnect the financial institutions. These brands combine the
1208 roles of issuer and acquirer in interactions with cardholders and
1211 $ brand certification authority (BCA)
1212 (O) SET usage: A CA owned by a payment card brand, such as
1213 MasterCard, Visa, or American Express. [SET2] (See: certification
1216 $ brand CRL identifier (BCI)
1217 (O) SET usage: A digitally signed list, issued by a BCA, of the
1218 names of CAs for which CRLs need to be processed when verifying
1219 signatures in SET messages. [SET2]
1222 (I) Cryptographic usage: To successfully perform cryptanalysis and
1223 thus succeed in decrypting data or performing some other
1224 cryptographic function, without initially having knowledge of the
1225 key that the function requires. (This term applies to encrypted
1226 data or, more generally, to a cryptographic algorithm or
1227 cryptographic system.)
1234 Shirey Informational [Page 22]
1236 RFC 2828 Internet Security Glossary May 2000
1240 (I) A computer that is a gateway between two networks (usually two
1241 LANs) at OSI layer 2. (See: router.)
1243 $ British Standard 7799
1244 (N) Part 1 is a standard code of practice and provides guidance on
1245 how to secure an information system. Part 2 specifies the
1246 management framework, objectives, and control requirements for
1247 information security management systems [B7799]. The certification
1248 scheme works like ISO 9000. It is in use in the UK, the
1249 Netherlands, Australia, and New Zealand and might be proposed as
1250 an ISO standard or adapted to be part of the Common Criteria.
1253 (I) An client computer program that can retrieve and display
1254 information from servers on the World Wide Web.
1256 (C) For example, Netscape's Navigator and Communicator, and
1257 Microsoft's Explorer.
1260 (I) A cryptanalysis technique or other kind of attack method
1261 involving an exhaustive procedure that tries all possibilities,
1264 (C) For example, for ciphertext where the analyst already knows
1265 the decryption algorithm, a brute force technique to finding the
1266 original plaintext is to decrypt the message with every possible
1270 See: British Standard 7799.
1273 (I) A fundamental unit of computer storage; the smallest
1274 addressable unit in a computer's architecture. Usually holds one
1275 character of information and, today, usually means eight bits.
1278 (C) Larger than a "bit", but smaller than a "word". Although
1279 "byte" almost always means "octet" today, bytes had other sizes
1280 (e.g., six bits, nine bits) in earlier computer architectures.
1283 See: certification authority.
1290 Shirey Informational [Page 23]
1292 RFC 2828 Internet Security Glossary May 2000
1296 (I) "A [digital] certificate for one CA issued by another CA."
1299 (C) That is, a digital certificate whose holder is able to issue
1300 digital certificates. A v3 X.509 public-key certificate may have a
1301 "basicConstraints" extension containing a "cA" value that
1302 specifically "indicates whether or not the public key may be used
1303 to verify certificate signatures."
1306 (I) An authentication technique for terminals that remotely access
1307 a computer via telephone lines. The host system disconnects the
1308 caller and then calls back on a telephone number that was
1309 previously authorized for that terminal.
1312 (I) A token, usually an unforgeable data value (sometimes called a
1313 "ticket") that gives the bearer or holder the right to access a
1314 system resource. Possession of the token is accepted by a system
1315 as proof that the holder has been authorized to access the
1316 resource named or indicated by the token. (See: access control
1317 list, credential, digital certificate.)
1319 (C) This concept can be implemented as a digital certificate.
1320 (See: attribute certificate.)
1323 See: cryptographic application programming interface.
1326 (N) An integrated circuit (the Mykotronx, Inc. MYK-82) with a Type
1327 II cryptographic processor that implements SKIPJACK, KEA, DSA,
1328 SHA, and basic mathematical functions to support asymmetric
1329 cryptography, and includes the key escrow feature of the CLIPPER
1330 chip. (See: FORTEZZA card.)
1333 See: cryptographic card, FORTEZZA card, payment card, PC card,
1346 Shirey Informational [Page 24]
1348 RFC 2828 Internet Security Glossary May 2000
1355 (I) An entity that has been issued a card.
1357 (O) SET usage: "The holder of a valid payment card account and
1358 user of software supporting electronic commerce." [SET2] A
1359 cardholder is issued a payment card by an issuer. SET ensures that
1360 in the cardholder's interactions with merchants, the payment card
1361 account information remains confidential. [SET1]
1363 $ cardholder certificate
1364 (O) SET usage: A digital certificate that is issued to a
1365 cardholder upon approval of the cardholder's issuing financial
1366 institution and that is transmitted to merchants with purchase
1367 requests and encrypted payment instructions, carrying assurance
1368 that the account number has been validated by the issuing
1369 financial institution and cannot be altered by a third party.
1372 $ cardholder certification authority (CCA)
1373 (O) SET usage: A CA responsible for issuing digital certificates
1374 to cardholders and operated on behalf of a payment card brand, an
1375 issuer, or another party according to brand rules. A CCA maintains
1376 relationships with card issuers to allow for the verification of
1377 cardholder accounts. A CCA does not issue a CRL but does
1378 distribute CRLs issued by root CAs, brand CAs, geopolitical CAs,
1379 and payment gateway CAs. [SET2]
1382 (N) A design procedure for symmetric encryption algorithms, and a
1383 resulting family of algorithms, invented by C.A. (Carlisle Adams)
1384 and S.T. (Stafford Tavares). [R2144, R2612]
1387 (I) A grouping of sensitive information items to which a non-
1388 hierarchical restrictive security label is applied to increase
1389 protection of the data. (See: compartment.)
1392 See: certification authority workstation.
1395 See: cipher block chaining.
1398 See: cardholder certification authority.
1402 Shirey Informational [Page 25]
1404 RFC 2828 Internet Security Glossary May 2000
1408 (N) Acronym for French translation of International Telephone and
1409 Telegraph Consultative Committee. Now renamed ITU-T.
1412 See: computer emergency response team.
1415 (I) General English usage: A document that attests to the truth of
1416 something or the ownership of something.
1418 (C) Security usage: See: capability, digital certificate.
1420 (C) PKI usage: See: attribute certificate, public-key certificate.
1422 $ certificate authority
1423 (D) ISDs SHOULD NOT use this term because it looks like sloppy use
1424 of "certification authority", which is the term standardized by
1428 (D) ISDs SHOULD NOT use this term because it duplicates the
1429 meaning of a standardized term. Instead, use "certification path".
1431 $ certificate chain validation
1432 (D) ISDs SHOULD NOT use this term because it duplicates the
1433 meaning of standardized terms and mixes concepts in a potentially
1434 misleading way. Instead, use "certificate validation" or "path
1435 validation", depending on what is meant. (See: validate vs.
1438 $ certificate creation
1439 (I) The act or process by which a CA sets the values of a digital
1440 certificate's data fields and signs it. (See: issue.)
1442 $ certificate expiration
1443 (I) The event that occurs when a certificate ceases to be valid
1444 because its assigned lifetime has been exceeded. (See: certificate
1445 revocation, validity period.)
1447 $ certificate extension
1458 Shirey Informational [Page 26]
1460 RFC 2828 Internet Security Glossary May 2000
1463 $ certificate holder
1464 (D) ISDs SHOULD NOT use this term as a synonym for the subject of
1465 a digital certificate because the term is potentially ambiguous.
1466 For example, the term could also refer to a system entity, such as
1467 a repository, that simply has possession of a copy of the
1468 certificate. (See: certificate owner.)
1470 $ certificate management
1471 (I) The functions that a CA may perform during the life cycle of a
1472 digital certificate, including the following:
1474 - Acquire and verify data items to bind into the certificate.
1475 - Encode and sign the certificate.
1476 - Store the certificate in a directory or repository.
1477 - Renew, rekey, and update the certificate.
1478 - Revoke the certificate and issue a CRL.
1480 (See: archive management, certificate management, key management,
1481 security architecture, token management.)
1484 (D) ISDs SHOULD NOT use this term as a synonym for the subject of
1485 a digital certificate because the term is potentially ambiguous.
1486 For example, the term could also refer to a system entity, such as
1487 a corporation, that has acquired a certificate to operate some
1488 other entity, such as a Web server. (See: certificate holder.)
1490 $ certificate policy
1491 (I) "A named set of rules that indicates the applicability of a
1492 certificate to a particular community and/or class of application
1493 with common security requirements." [X509] (See: certification
1494 practice statement.)
1496 (C) A certificate policy can help a certificate user decide
1497 whether a certificate should be trusted in a particular
1498 application. "For example, a particular certificate policy might
1499 indicate applicability of a type of certificate for the
1500 authentication of electronic data interchange transactions for the
1501 trading goods within a given price range." [R2527]
1503 (C) A v3 X.509 public-key certificate may have a
1504 "certificatePolicies" extension that lists certificate policies,
1505 recognized by the issuing CA, that apply to the certificate and
1506 govern its use. Each policy is denoted by an object identifier and
1507 may optionally have certificate policy qualifiers.
1514 Shirey Informational [Page 27]
1516 RFC 2828 Internet Security Glossary May 2000
1519 (C) SET usage: Every SET certificate specifies at least one
1520 certificate policy, that of the SET root CA. SET uses certificate
1521 policy qualifiers to point to the actual policy statement and to
1522 add qualifying policies to the root policy. (See: SET qualifier.)
1524 $ certificate policy qualifier
1525 (I) Information that pertains to a certificate policy and is
1526 included in a "certificatePolicies" extension in a v3 X.509
1527 public-key certificate.
1529 $ certificate reactivation
1530 (I) The act or process by which a digital certificate, which a CA
1531 has designated for revocation but not yet listed on a CRL, is
1532 returned to the valid state.
1535 (I) The act or process by which an existing public-key certificate
1536 has its public key value changed by issuing a new certificate with
1537 a different (usually new) public key. (See: certificate renewal,
1538 certificate update, rekey.)
1540 (C) For an X.509 public-key certificate, the essence of rekey is
1541 that the subject stays the same and a new public key is bound to
1542 that subject. Other changes are made, and the old certificate is
1543 revoked, only as required by the PKI and CPS in support of the
1544 rekey. If changes go beyond that, the process is a "certificate
1547 (O) MISSI usage: To rekey a MISSI X.509 public-key certificate
1548 means that the issuing authority creates a new certificate that is
1549 identical to the old one, except the new one has a new, different
1550 KEA key; or a new, different DSS key; or new, different KEA and
1551 DSS keys. The new certificate also has a different serial number
1552 and may have a different validity period. A new key creation date
1553 and maximum key lifetime period are assigned to each newly
1554 generated key. If a new KEA key is generated, that key is assigned
1555 a new KMID. The old certificate remains valid until it expires,
1556 but may not be further renewed, rekeyed, or updated.
1558 $ certificate renewal
1559 (I) The act or process by which the validity of the data binding
1560 asserted by an existing public-key certificate is extended in time
1561 by issuing a new certificate. (See: certificate rekey, certificate
1564 (C) For an X.509 public-key certificate, this term means that the
1565 validity period is extended (and, of course, a new serial number
1566 is assigned) but the binding of the public key to the subject and
1570 Shirey Informational [Page 28]
1572 RFC 2828 Internet Security Glossary May 2000
1575 to other data items stays the same. The other data items are
1576 changed, and the old certificate is revoked, only as required by
1577 the PKI and CPS to support the renewal. If changes go beyond that,
1578 the process is a "certificate rekey" or "certificate update".
1580 $ certificate request
1581 (D) ISDs SHOULD NOT use this term because it looks like imprecise
1582 use of a term standardized by PKCS #10 and used in PKIX. Instead,
1583 use the standard term, "certification request".
1585 $ certificate revocation
1586 (I) The event that occurs when a CA declares that a previously
1587 valid digital certificate issued by that CA has become invalid;
1588 usually stated with a revocation date.
1590 (C) In X.509, a revocation is announced to potential certificate
1591 users by issuing a CRL that mentions the certificate. Revocation
1592 and listing on a CRL is only necessary before certificate
1595 $ certificate revocation list (CRL)
1596 (I) A data structure that enumerates digital certificates that
1597 have been invalidated by their issuer prior to when they were
1598 scheduled to expire. (See: certificate expiration, X.509
1599 certificate revocation list.)
1601 (O) "A signed list indicating a set of certificates that are no
1602 longer considered valid by the certificate issuer. After a
1603 certificate appears on a CRL, it is deleted from a subsequent CRL
1604 after the certificate's expiry. CRLs may be used to identify
1605 revoked public-key certificates or attribute certificates and may
1606 represent revocation of certificates issued to authorities or to
1607 users. The term CRL is also commonly used as a generic term
1608 applying to all the different types of revocation lists, including
1609 CRLs, ARLs, ACRLs, etc." [FPDAM]
1611 $ certificate revocation tree
1612 (I) A mechanism for distributing notice of certificate
1613 revocations; uses a tree of hash results that is signed by the
1614 tree's issuer. Offers an alternative to issuing a CRL, but is not
1615 supported in X.509. (See: certificate status responder.)
1617 $ certificate serial number
1618 (I) An integer value that (a) is associated with, and may be
1619 carried in, a digital certificate; (b) is assigned to the
1620 certificate by the certificate's issuer; and (c) is unique among
1621 all the certificates produced by that issuer.
1626 Shirey Informational [Page 29]
1628 RFC 2828 Internet Security Glossary May 2000
1631 (O) "An integer value, unique within the issuing CA, which is
1632 unambiguously associated with a certificate issued by that CA."
1635 $ certificate status responder
1636 (N) FPKI usage: A trusted on-line server that acts for a CA to
1637 provide authenticated certificate status information to
1638 certificate users. [FPKI] Offers an alternative to issuing a CRL,
1639 but is not supported in X.509. (See: certificate revocation tree.)
1641 $ certificate update
1642 (I) The act or process by which non-key data items bound in an
1643 existing public-key certificate, especially authorizations granted
1644 to the subject, are changed by issuing a new certificate. (See:
1645 certificate rekey, certificate renewal.)
1647 (C) For an X.509 public-key certificate, the essence of this
1648 process is that fundamental changes are made in the data that is
1649 bound to the public key, such that it is necessary to revoke the
1650 old certificate. (Otherwise, the process is only a "certificate
1651 rekey" or "certificate renewal".)
1654 (I) A system entity that depends on the validity of information
1655 (such as another entity's public key value) provided by a digital
1656 certificate. (See: relying party.)
1658 (O) "An entity that needs to know, with certainty, the public key
1659 of another entity." [X509]
1661 (C) The system entity may be a human being or an organization, or
1662 a device or process under the control of a human or an
1665 (D) ISDs SHOULD NOT use this term as a synonym for the "subject"
1668 $ certificate validation
1669 (I) An act or process by which a certificate user establishes that
1670 the assertions made by a digital certificate can be trusted. (See:
1671 valid certificate, validate vs. verify.)
1673 (O) "The process of ensuring that a certificate is valid including
1674 possibly the construction and processing of a certification path,
1675 and ensuring that all certificates in that path have not expired
1676 or been revoked." [FPDAM]
1682 Shirey Informational [Page 30]
1684 RFC 2828 Internet Security Glossary May 2000
1687 (C) To validate a certificate, a certificate user checks that the
1688 certificate is properly formed and signed and currently in force:
1690 - Checks the signature: Employs the issuer's public key to verify
1691 the digital signature of the CA who issued the certificate in
1692 question. If the verifier obtains the issuer's public key from
1693 the issuer's own public-key certificate, that certificate
1694 should be validated, too. That validation may lead to yet
1695 another certificate to be validated, and so on. Thus, in
1696 general, certificate validation involves discovering and
1697 validating a certification path.
1699 - Checks the syntax and semantics: Parses the certificate's
1700 syntax and interprets its semantics, applying rules specified
1701 for and by its data fields, such as for critical extensions in
1702 an X.509 certificate.
1704 - Checks currency and revocation: Verifies that the certificate
1705 is currently in force by checking that the current date and
1706 time are within the validity period (if that is specified in
1707 the certificate) and that the certificate is not listed on a
1708 CRL or otherwise announced as invalid. (CRLs themselves require
1709 a similar validation process.)
1712 (I) Information system usage: Technical evaluation (usually made
1713 in support of an accreditation action) of an information system's
1714 security features and other safeguards to establish the extent to
1715 which the system's design and implementation meet specified
1716 security requirements. [FP102] (See: accreditation.)
1718 (I) Digital certificate usage: The act or process of vouching for
1719 the truth and accuracy of the binding between data items in a
1720 certificate. (See: certify.)
1722 (I) Public key usage: The act or process of vouching for the
1723 ownership of a public key by issuing a public-key certificate that
1724 binds the key to the name of the entity that possesses the
1725 matching private key. In addition to binding a key to a name, a
1726 public-key certificate may bind those items to other restrictive
1727 or explanatory data items. (See: X.509 public-key certificate.)
1729 (O) SET usage: "The process of ascertaining that a set of
1730 requirements or criteria has been fulfilled and attesting to that
1731 fact to others, usually with some written instrument. A system
1732 that has been inspected and evaluated as fully compliant with the
1733 SET protocol by duly authorized parties and process would be said
1734 to have been certified compliant." [SET2]
1738 Shirey Informational [Page 31]
1740 RFC 2828 Internet Security Glossary May 2000
1743 $ certification authority (CA)
1744 (I) An entity that issues digital certificates (especially X.509
1745 certificates) and vouches for the binding between the data items
1748 (O) "An authority trusted by one or more users to create and
1749 assign certificates. Optionally, the certification authority may
1750 create the user's keys." [X509]
1752 (C) Certificate users depend on the validity of information
1753 provided by a certificate. Thus, a CA should be someone that
1754 certificate users trust, and usually holds an official position
1755 created and granted power by a government, a corporation, or some
1756 other organization. A CA is responsible for managing the life
1757 cycle of certificates (see: certificate management) and, depending
1758 on the type of certificate and the CPS that applies, may be
1759 responsible for the life cycle of key pairs associated with the
1760 certificates (see: key management).
1762 $ certification authority workstation (CAW)
1763 (I) A computer system that enables a CA to issue digital
1764 certificates and supports other certificate management functions
1767 $ certification hierarchy
1768 (I) A tree-structured (loop-free) topology of relationships among
1769 CAs and the entities to whom the CAs issue public-key
1770 certificates. (See: hierarchical PKI.)
1772 (C) In this structure, one CA is the top CA, the highest level of
1773 the hierarchy. (See: root, top CA.) The top CA may issue public-
1774 key certificates to one or more additional CAs that form the
1775 second highest level. Each of these CAs may issue certificates to
1776 more CAs at the third highest level, and so on. The CAs at the
1777 second-lowest of the hierarchy issue certificates only to non-CA
1778 entities, called "end entities" that form the lowest level. (See:
1779 end entity.) Thus, all certification paths begin at the top CA and
1780 descend through zero or more levels of other CAs. All certificate
1781 users base path validations on the top CA's public key.
1783 (O) MISSI usage: A MISSI certification hierarchy has three or four
1786 - A CA at the highest level, the top CA, is a "policy approving
1788 - A CA at the second-highest level is a "policy creation
1794 Shirey Informational [Page 32]
1796 RFC 2828 Internet Security Glossary May 2000
1799 - A CA at the third-highest level is a local authority called a
1800 "certification authority".
1801 - A CA at the fourth-highest (optional) level is a "subordinate
1802 certification authority".
1804 (O) PEM usage: A PEM certification hierarchy has three levels of
1807 - The highest level is the "Internet Policy Registration
1809 - A CA at the second-highest level is a "policy certification
1811 - A CA at the third-highest level is a "certification authority".
1813 (O) SET usage: A SET certification hierarchy has three or four
1816 - The highest level is a "SET root CA".
1817 - A CA at the second-highest level is a "brand certification
1819 - A CA at the third-highest (optional) level is a "geopolitical
1820 certification authority".
1821 - A CA at the fourth-highest level is a "cardholder CA", a
1822 "merchant CA", or a "payment gateway CA".
1824 $ certification path
1825 (I) An ordered sequence of public-key certificates (or a sequence
1826 of public-key certificates followed by one attribute certificate)
1827 that enables a certificate user to verify the signature on the
1828 last certificate in the path, and thus enables the user to obtain
1829 a certified public key (or certified attributes) of the entity
1830 that is the subject of that last certificate. (See: certificate
1831 validation, valid certificate.)
1833 (O) "An ordered sequence of certificates of objects in the [X.500
1834 Directory Information Tree] which, together with the public key of
1835 the initial object in the path, can be processed to obtain that of
1836 the final object in the path." [X509, R2527]
1838 (C) The path is the "list of certificates needed to allow a
1839 particular user to obtain the public key of another." [X509] The
1840 list is "linked" in the sense that the digital signature of each
1841 certificate (except the first) is verified by the public key
1842 contained in the preceding certificate; i.e., the private key used
1843 to sign a certificate and the public key contained in the
1844 preceding certificate form a key pair owned by the entity that
1850 Shirey Informational [Page 33]
1852 RFC 2828 Internet Security Glossary May 2000
1855 (C) In the X.509 quotation in the previous "C" paragraph, the word
1856 "particular" points out that a certification path that can be
1857 validated by one certificate user might not be able to be
1858 validated by another. That is because either the first certificate
1859 should be a trusted certificate (it might be a root certificate)
1860 or the signature on the first certificate should be verified by a
1861 trusted key (it might be a root key), but such trust is defined
1862 relative to each user, not absolutely for all users.
1864 $ certification policy
1865 (D) ISDs SHOULD NOT use this term. Instead, use either
1866 "certificate policy" or "certification practice statement",
1867 depending on what is meant.
1869 $ certification practice statement (CPS)
1870 (I) "A statement of the practices which a certification authority
1871 employs in issuing certificates." [ABA96, R2527] (See: certificate
1874 (C) A CPS is a published security policy that can help a
1875 certificate user to decide whether a certificate issued by a
1876 particular CA can be trusted enough to use in a particular
1877 application. A CPS may be (a) a declaration by a CA of the details
1878 of the system and practices it employs in its certificate
1879 management operations, (b) part of a contract between the CA and
1880 an entity to whom a certificate is issued, (c) a statute or
1881 regulation applicable to the CA, or (d) a combination of these
1882 types involving multiple documents. [ABA]
1884 (C) A CPS is usually more detailed and procedurally oriented than
1885 a certificate policy. A CPS applies to a particular CA or CA
1886 community, while a certificate policy applies across CAs or
1887 communities. A CA with a single CPS may support multiple
1888 certificate policies, which may be used for different application
1889 purposes or by different user communities. Multiple CAs, each with
1890 a different CPS, may support the same certificate policy. [R2527]
1892 $ certification request
1893 (I) A algorithm-independent transaction format, defined by PCKS
1894 #10 and used in PKIX, that contains a DN, a public key, and
1895 optionally a set of attributes, collectively signed by the entity
1896 requesting certification, and sent to a CA, which transforms the
1897 request to an X.509 public-key certificate or another type of
1906 Shirey Informational [Page 34]
1908 RFC 2828 Internet Security Glossary May 2000
1912 1. (I) Issue a digital certificate and thus vouch for the truth,
1913 accuracy, and binding between data items in the certificate (e.g.,
1914 see: X.509 public key certificate), such as the identity of the
1915 certificate's subject and the ownership of a public key. (See:
1918 (C) To "certify a public key" means to issue a public-key
1919 certificate that vouches for the binding between the certificate's
1920 subject and the key.
1922 2. (I) The act by which a CA employs measures to verify the truth,
1923 accuracy, and binding between data items in a digital certificate.
1925 (C) A description of the measures used for verification should be
1926 included in the CA's CPS.
1929 See: cipher feedback.
1931 $ Challenge Handshake Authentication Protocol (CHAP)
1932 (I) A peer entity authentication method for PPP, using a randomly-
1933 generated challenge and requiring a matching response that depends
1934 on a cryptographic hash of the challenge and a secret key. [R1994]
1935 (See: challenge-response, PAP.)
1937 $ challenge-response
1938 (I) An authentication process that verifies an identity by
1939 requiring correct authentication information to be provided in
1940 response to a challenge. In a computer system, the authentication
1941 information is usually a value that is required to be computed in
1942 response to an unpredictable challenge value.
1944 $ Challenge-Response Authentication Mechanism (CRAM)
1945 (I) IMAP4 usage: A mechanism [R2195], intended for use with IMAP4
1946 AUTHENTICATE, by which an IMAP4 client uses a keyed hash [R2104]
1947 to authenticate itself to an IMAP4 server. (See: POP3 APOP.)
1949 (C) The server includes a unique timestamp in its ready response
1950 to the client. The client replies with the client's name and the
1951 hash result of applying MD5 to a string formed from concatenating
1952 the timestamp with a shared secret that is known only to the
1953 client and the server.
1956 (I) An information transfer path within a system. (See: covert
1962 Shirey Informational [Page 35]
1964 RFC 2828 Internet Security Glossary May 2000
1968 See: Challenge Handshake Authentication Protocol.
1971 (I) A value that (a) is computed by a function that is dependent
1972 on the contents of a data object and (b) is stored or transmitted
1973 together with the object, for the purpose of detecting changes in
1974 the data. (See: cyclic redundancy check, data integrity service,
1975 error detection code, hash, keyed hash, protected checksum.)
1977 (C) To gain confidence that a data object has not been changed, an
1978 entity that later uses the data can compute a checksum and compare
1979 it with the checksum that was stored or transmitted with the
1982 (C) Computer systems and networks employ checksums (and other
1983 mechanisms) to detect accidental changes in data. However, active
1984 wiretapping that changes data could also change an accompanying
1985 checksum to match the changed data. Thus, some checksum functions
1986 by themselves are not good countermeasures for active attacks. To
1987 protect against active attacks, the checksum function needs to be
1988 well-chosen (see: cryptographic hash), and the checksum result
1989 needs to be cryptographically protected (see: digital signature,
1992 $ chosen-ciphertext attack
1993 (I) A cryptanalysis technique in which the analyst tries to
1994 determine the key from knowledge of plaintext that corresponds to
1995 ciphertext selected (i.e., dictated) by the analyst.
1997 $ chosen-plaintext attack
1998 (I) A cryptanalysis technique in which the analyst tries to
1999 determine the key from knowledge of ciphertext that corresponds to
2000 plaintext selected (i.e., dictated) by the analyst.
2003 See: Computer Incident Advisory Capability.
2006 See: cryptographic ignition key.
2009 (I) A cryptographic algorithm for encryption and decryption.
2011 $ cipher block chaining (CBC)
2012 (I) An block cipher mode that enhances electronic codebook mode by
2013 chaining together blocks of ciphertext it produces. [FP081] (See:
2018 Shirey Informational [Page 36]
2020 RFC 2828 Internet Security Glossary May 2000
2023 (C) This mode operates by combining (exclusive OR-ing) the
2024 algorithm's ciphertext output block with the next plaintext block
2025 to form the next input block for the algorithm.
2027 $ cipher feedback (CFB)
2028 (I) An block cipher mode that enhances electronic code book mode
2029 by chaining together the blocks of ciphertext it produces and
2030 operating on plaintext segments of variable length less than or
2031 equal to the block length. [FP081]
2033 (C) This mode operates by using the previously generated
2034 ciphertext segment as the algorithm's input (i.e., by "feeding
2035 back" the ciphertext) to generate an output block, and then
2036 combining (exclusive OR-ing) that output block with the next
2037 plaintext segment (block length or less) to form the next
2041 (I) Data that has been transformed by encryption so that its
2042 semantic information content (i.e., its meaning) is no longer
2043 intelligible or directly available. (See: cleartext, plaintext.)
2045 (O) "Data produced through the use of encipherment. The semantic
2046 content of the resulting data is not available." [I7498 Part 2]
2048 $ ciphertext-only attack
2049 (I) A cryptanalysis technique in which the analyst tries to
2050 determine the key solely from knowledge of intercepted ciphertext
2051 (although the analyst may also know other clues, such as the
2052 cryptographic algorithm, the language in which the plaintext was
2053 written, the subject matter of the plaintext, and some probable
2057 See: Common IP Security Option.
2060 See: compromised key list.
2062 $ class 2, 3, 4, or 5
2063 (O) U.S. Department of Defense usage: Levels of PKI assurance
2064 based on risk and value of information to be protected [DOD3]:
2066 - Class 2: For handling low-value information (unclassified, not
2067 mission-critical, or low monetary value) or protection of
2068 system-high information in low- to medium-risk environment.
2074 Shirey Informational [Page 37]
2076 RFC 2828 Internet Security Glossary May 2000
2079 - Class 3: For handling medium-value information in low- to
2080 medium-risk environment. Typically requires identification of a
2081 system entity as a legal person, rather than merely a member of
2084 - Class 4: For handling medium- to high-value information in any
2085 environment. Typically requires identification of an entity as
2086 a legal person, rather than merely a member of an organization,
2087 and a cryptographic hardware token for protection of keying
2090 - Class 5: For handling high-value information in a high-risk
2094 $ classification level
2095 (I) (1.) A grouping of classified information to which a
2096 hierarchical, restrictive security label is applied to increase
2097 protection of the data. (2.) The level of protection that is
2098 required to be applied to that information. (See: security level.)
2101 (I) Refers to information (stored or conveyed, in any form) that
2102 is formally required by a security policy to be given data
2103 confidentiality service and to be marked with a security label
2104 (which in some cases might be implicit) to indicate its protected
2105 status. (See: unclassified.)
2107 (C) The term is mainly used in government, especially in the
2108 military, although the concept underlying the term also applies
2109 outside government. In the U.S. Department of Defense, for
2110 example, it means information that has been determined pursuant to
2111 Executive Order 12958 ("Classified National Security Information",
2112 20 April 1995) or any predecessor order to require protection
2113 against unauthorized disclosure and is marked to indicate its
2114 classified status when in documentary form.
2117 (I) A computer system in which the operating system and
2118 application system software and files have just been freshly
2119 installed from trusted software distribution media.
2121 (C) A clean system is not necessarily in a secure state.
2124 See: security clearance.
2130 Shirey Informational [Page 38]
2132 RFC 2828 Internet Security Glossary May 2000
2136 (I) The security level of information to which a security
2137 clearance authorizes a person to have access.
2140 (I) Data in which the semantic information content (i.e., the
2141 meaning) is intelligible or is directly available. (See:
2144 (O) "Intelligible data, the semantic content of which is
2145 available." [I7498 Part 2]
2147 (D) ISDs SHOULD NOT use this term as a synonym for "plaintext",
2148 the input to an encryption operation, because the plaintext input
2149 to encryption may itself be ciphertext that was output from
2150 another operation. (See: superencryption.)
2153 (I) A system entity that requests and uses a service provided by
2154 another system entity, called a "server". (See: server.)
2156 (C) Usually, the requesting entity is a computer process, and it
2157 makes the request on behalf of a human user. In some cases, the
2158 server may itself be a client of some other server.
2161 (N) The Mykotronx, Inc. MYK-82, an integrated microcircuit with a
2162 cryptographic processor that implements the SKIPJACK encryption
2163 algorithm and supports key escrow. (See: CAPSTONE, Escrowed
2164 Encryption Standard.)
2166 (C) The key escrow scheme for a chip involves a SKIPJACK key
2167 common to all chips that protects the unique serial number of the
2168 chip, and a second SKIPJACK key unique to the chip that protects
2169 all data encrypted by the chip. The second key is escrowed as
2170 split key components held by NIST and the U.S. Treasury
2173 $ closed security environment
2174 (O) U.S. Department of Defense usage: A system environment that
2175 meets both of the following conditions: (a) Application developers
2176 (including maintainers) have sufficient clearances and
2177 authorizations to provide an acceptable presumption that they have
2178 not introduced malicious logic. (b) Configuration control provides
2179 sufficient assurance that system applications and the equipment
2180 they run on are protected against the introduction of malicious
2181 logic prior to and during the operation of applications. [NCS04]
2182 (See: open security environment.)
2186 Shirey Informational [Page 39]
2188 RFC 2828 Internet Security Glossary May 2000
2192 (I) noun: A system of symbols used to represent information, which
2193 might originally have some other representation. (See: encode.)
2195 (D) ISDs SHOULD NOT use this term as synonym for the following:
2196 (a) "cipher", "hash", or other words that mean "a cryptographic
2197 algorithm"; (b) "ciphertext"; or (c) "encrypt", "hash", or other
2198 words that refer to applying a cryptographic algorithm.
2200 (D) ISDs SHOULD NOT this word as an abbreviation for the following
2201 terms: country code, cyclic redundancy code, Data Authentication
2202 Code, error detection code, Message Authentication Code, object
2203 code, or source code. To avoid misunderstanding, use the fully
2204 qualified term, at least at the point of first usage.
2207 (I) In a system that is being operated in periods processing mode,
2208 the act of purging all information from one processing period and
2209 then changing over to the next processing period.
2212 $ Common Criteria for Information Technology Security
2213 (N) "The Common Criteria" is a standard for evaluating information
2214 technology products and systems, such as operating systems,
2215 computer networks, distributed systems, and applications. It
2216 states requirements for security functions and for assurance
2219 (C) Canada, France, Germany, the Netherlands, the United Kingdom,
2220 and the United States (NIST and NSA) began developing this
2221 standard in 1993, based on the European ITSEC, the Canadian
2222 Trusted Computer Product Evaluation Criteria (CTCPEC), and the
2223 U.S. "Federal Criteria for Information Technology Security" (FC)
2224 and its precursor, the TCSEC. Work was done in cooperation with
2225 ISO/IEC Joint Technical Committee 1 (Information Technology),
2226 Subcommittee 27 (Security Techniques), Working Group 3 (Security
2227 Criteria). Version 2.1 of the Criteria is equivalent to ISO's
2228 International Standard 15408 [I15408]. The U.S. Government intends
2229 that this standard eventually will supersede both the TCSEC and
2230 FIPS PUB 140-1. (See: NIAP.)
2232 (C) The standard addresses data confidentiality, data integrity,
2233 and availability and may apply to other aspects of security. It
2234 focuses on threats to information arising from human activities,
2235 malicious or otherwise, but may apply to non-human threats. It
2236 applies to security measures implemented in hardware, firmware, or
2237 software. It does not apply to (a) administrative security not
2238 related directly to technical security, (b) technical physical
2242 Shirey Informational [Page 40]
2244 RFC 2828 Internet Security Glossary May 2000
2247 aspects of security such as electromagnetic emanation control, (c)
2248 evaluation methodology or administrative and legal framework under
2249 which the criteria may be applied, (d) procedures for use of
2250 evaluation results, or (e) assessment of inherent qualities of
2251 cryptographic algorithms.
2253 $ Common IP Security Option (CIPSO)
2254 See: (secondary definition under) Internet Protocol Security
2258 (I) A character string that (a) may be a part of the X.500 DN of a
2259 Directory object ("commonName" attribute), (b) is a (possibly
2260 ambiguous) name by which the object is commonly known in some
2261 limited scope (such as an organization), and (c) conforms to the
2262 naming conventions of the country or culture with which it is
2263 associated. [X520] (See: ("subject" and "issuer" under) X.509
2264 public-key certificate.)
2266 (C) For example, "Dr. E. F. Moore", "The United Nations", or
2267 "12-th Floor Laser Printer".
2269 $ communication security (COMSEC)
2270 (I) Measures that implement and assure security services in a
2271 communication system, particularly those that provide data
2272 confidentiality and data integrity and that authenticate
2273 communicating entities.
2275 (C) Usually understood to include cryptographic algorithms and key
2276 management methods and processes, devices that implement them, and
2277 the life cycle management of keying material and devices.
2280 (I) A community name in the form of an octet string that serves as
2281 a cleartext password in SNMP version 1. [R1157]
2284 (I) A grouping of sensitive information items that require special
2285 access controls beyond those normally provided for the basic
2286 classification level of the information. (See: category.)
2288 (C) The term is usually understood to include the special handling
2289 procedures to be used for the information.
2292 See: data compromise, security compromise.
2298 Shirey Informational [Page 41]
2300 RFC 2828 Internet Security Glossary May 2000
2303 $ compromised key list (CKL)
2304 (O) MISSI usage: A list that identifies keys for which
2305 unauthorized disclosure or alteration may have occurred. (See:
2308 (C) A CKL is issued by an CA, like a CRL is issued. But a CKL
2309 lists only KMIDs, not subjects that hold the keys, and not
2310 certificates in which the keys are bound.
2313 See: computer security.
2315 $ computer emergency response team (CERT)
2316 (I) An organization that studies computer and network INFOSEC in
2317 order to provide incident response services to victims of attacks,
2318 publish alerts concerning vulnerabilities and threats, and offer
2319 other information to help improve computer and network security.
2320 (See: CSIRT, security incident.)
2322 (C) For example, the CERT Coordination Center at Carnegie-Mellon
2323 University (sometimes called "the" CERT) and the Computer Incident
2324 Advisory Capability.
2326 $ Computer Incident Advisory Capability (CIAC)
2327 (N) A computer emergency response team in the U.S. Department of
2331 (I) A collection of host computers together with the subnetwork or
2332 internetwork through which they can exchange data.
2334 (C) This definition is intended to cover systems of all sizes and
2335 types, ranging from the complex Internet to a simple system
2336 composed of a personal computer dialing in as a remote terminal of
2339 $ computer security (COMPUSEC)
2340 (I) Measures that implement and assure security services in a
2341 computer system, particularly those that assure access control
2344 (C) Usually understood to include functions, features, and
2345 technical characteristics of computer hardware and software,
2346 especially operating systems.
2354 Shirey Informational [Page 42]
2356 RFC 2828 Internet Security Glossary May 2000
2359 $ computer security incident response team (CSIRT)
2360 (I) An organization "that coordinates and supports the response to
2361 security incidents that involve sites within a defined
2362 constituency." [R2350] (See: CERT, FIRST, security incident.)
2364 (C) To be considered a CSIRT, an organization must do as follows:
2366 - Provide a (secure) channel for receiving reports about
2367 suspected security incidents.
2368 - Provide assistance to members of its constituency in handling
2370 - Disseminate incident-related information to its constituency
2371 and other involved parties.
2373 $ computer security object
2374 (I) The definition or representation of a resource, tool, or
2375 mechanism used to maintain a condition of security in computerized
2376 environments. Includes many elements referred to in standards that
2377 are either selected or defined by separate user communities.
2378 [CSOR] (See: object identifier, Computer Security Objects
2381 $ Computer Security Objects Register (CSOR)
2382 (N) A service operated by NIST is establishing a catalog for
2383 computer security objects to provide stable object definitions
2384 identified by unique names. The use of this register will enable
2385 the unambiguous specification of security parameters and
2386 algorithms to be used in secure data exchanges.
2388 (C) The CSOR follows registration guidelines established by the
2389 international standards community and ANSI. Those guidelines
2390 establish minimum responsibilities for registration authorities
2391 and assign the top branches of an international registration
2392 hierarchy. Under that international registration hierarchy the
2393 CSOR is responsible for the allocation of unique identifiers under
2394 the branch {joint-iso-ccitt(2) country(16) us(840) gov(101)
2398 See: communication security.
2401 See: data confidentiality.
2403 $ configuration control
2404 (I) The process of regulating changes to hardware, firmware,
2405 software, and documentation throughout the development and
2406 operational life of a system. (See: administrative security.)
2410 Shirey Informational [Page 43]
2412 RFC 2828 Internet Security Glossary May 2000
2415 (C) Configuration control helps protect against unauthorized or
2416 malicious alteration of a system and thus provides assurance of
2417 system integrity. (See: malicious logic.)
2419 $ confinement property
2420 See: (secondary definition under) Bell-LaPadula Model.
2422 $ connectionless data integrity service
2423 (I) A security service that provides data integrity service for an
2424 individual IP datagram, by detecting modification of the datagram,
2425 without regard to the ordering of the datagram in a stream of
2428 (C) A connection-oriented data integrity service would be able to
2429 detect lost or reordered datagrams within a stream of datagrams.
2432 (I) A plan for emergency response, backup operations, and post-
2433 disaster recovery in a system as part of a security program to
2434 ensure availability of critical system resources and facilitate
2435 continuity of operations in a crisis. [NCS04] (See: availability.)
2437 $ controlled security mode
2438 (D) ISDs SHOULD NOT use this term. It was defined in an earlier
2439 version of the U.S. Department of Defense policy that regulates
2440 system accreditation, but was subsumed by "partitioned security
2441 mode" in the current version. [DOD2]
2443 (C) The term refers to a mode of operation of an information
2444 system, wherein at least some users with access to the system have
2445 neither a security clearance nor a need-to-know for all classified
2446 material contained in the system. However, separation and control
2447 of users and classified material on the basis, respectively, of
2448 clearance and classification level are not essentially under
2449 operating system control like they are in "multilevel security
2452 (C) Controlled mode was intended to encourage ingenuity in meeting
2453 the security requirements of Defense policy in ways less
2454 restrictive than "dedicated security mode" and "system high
2455 security mode", but at a level of risk lower than that generally
2456 associated with the true "multilevel security mode". This was to
2457 be accomplished by implementation of explicit augmenting measures
2458 to reduce or remove a substantial measure of system software
2459 vulnerability together with specific limitation of the security
2460 clearance levels of users permitted concurrent access to the
2466 Shirey Informational [Page 44]
2468 RFC 2828 Internet Security Glossary May 2000
2472 (I) access control usage: A synonym for "capability" or "ticket"
2473 in an access control system.
2475 (I) IPsec usage: Data exchanged by ISAKMP to prevent certain
2476 denial-of-service attacks during the establishment of a security
2479 (I) HTTP usage: Data exchanged between an HTTP server and a
2480 browser (a client of the server) to store state information on the
2481 client side and retrieve it later for server use.
2483 (C) An HTTP server, when sending data to a client, may send along
2484 a cookie, which the client retains after the HTTP connection
2485 closes. A server can use this mechanism to maintain persistent
2486 client-side state information for HTTP-based applications,
2487 retrieving the state information in later connections. A cookie
2488 may include a description of the range of URLs for which the state
2489 is valid. Future requests made by the client in that range will
2490 also send the current value of the cookie to the server. Cookies
2491 can be used to generate profiles of web usage habits, and thus may
2492 infringe on personal privacy.
2494 $ Coordinated Universal Time (UTC)
2495 (N) UTC is derived from International Atomic Time (TAI) by adding
2496 a number of leap seconds. The International Bureau of Weights and
2497 Measures computes TAI once each month by averaging data from many
2498 laboratories. (See: GeneralizedTime, UTCTime.)
2503 $ correctness integrity
2504 (I) Accuracy and consistency of the information that data values
2505 represent, rather than of the data itself. Closely related to
2506 issues of accountability and error handling. (See: data integrity,
2510 (I) A mathematical proof of consistency between a specification
2511 for system security and the implementation of that specification.
2512 (See: formal specification.)
2515 (I) An action, device, procedure, or technique that reduces a
2516 threat, a vulnerability, or an attack by eliminating or preventing
2517 it, by minimizing the harm it can cause, or by discovering and
2518 reporting it so that corrective action can be taken.
2522 Shirey Informational [Page 45]
2524 RFC 2828 Internet Security Glossary May 2000
2527 (C) In an Internet protocol, a countermeasure may take the form of
2528 a protocol feature, an element function, or a usage constraint.
2531 (I) An identifier that is defined for a nation by ISO. [I3166]
2533 (C) For each nation, ISO Standard 3166 defines a unique two-
2534 character alphabetic code, a unique three-character alphabetic
2535 code, and a three-digit code. Among many uses of these codes, the
2536 two-character codes are used as top-level domain names.
2539 (I) A intra-system channel that permits two cooperating entities,
2540 without exceeding their access authorizations, to transfer
2541 information in a way that violates the system's security policy.
2542 (See: channel, out of band.)
2544 (O) "A communications channel that allows two cooperating
2545 processes to transfer information in a manner that violates the
2546 system's security policy." [NCS04]
2548 (C) The cooperating entities can be either two insiders or an
2549 insider and an outsider. Of course, an outsider has no access
2550 authorization at all. A covert channel is a system feature that
2551 the system architects neither designed nor intended for
2552 information transfer:
2554 - "Timing channel": A system feature that enable one system
2555 entity to signal information to another by modulating its own
2556 use of a system resource in such a way as to affect system
2557 response time observed by the second entity.
2559 - "Storage channel": A system feature that enables one system
2560 entity to signal information to another entity by directly or
2561 indirectly writing a storage location that is later directly or
2562 indirectly read by the second entity.
2565 See: certification practice statement.
2568 (I) Someone who tries to break the security of, and gain access
2569 to, someone else's system without being invited to do so. (See:
2570 hacker and intruder.)
2573 See: Challenge-Response Authentication Mechanism.
2578 Shirey Informational [Page 46]
2580 RFC 2828 Internet Security Glossary May 2000
2584 See: cyclic redundancy check.
2587 (I) Data that is transferred or presented to establish either a
2588 claimed identity or the authorizations of a system entity. (See:
2589 authentication information, capability, ticket.)
2591 (O) "Data that is transferred to establish the claimed identity of
2592 an entity." [I7498 Part 2]
2595 1. (I) "Critical" system resource: A condition of a service or
2596 other system resource such that denial of access to (i.e., lack of
2597 availability of) that resource would jeopardize a system user's
2598 ability to perform a primary function or would result in other
2599 serious consequences. (See: availability, sensitive.)
2601 2. (N) "Critical" extension: Each extension of an X.509
2602 certificate (or CRL) is marked as being either critical or non-
2603 critical. If an extension is critical and a certificate user (or
2604 CRL user) does not recognize the extension type or does not
2605 implement its semantics, then the user is required to treat the
2606 certificate (or CRL) as invalid. If an extension is non-critical,
2607 a user that does not recognize or implement that extension type is
2608 permitted to ignore the extension and process the rest of the
2609 certificate (or CRL).
2612 See: certificate revocation list.
2614 $ CRL distribution point
2615 See: distribution point.
2621 See: cross-certification.
2623 $ cross-certification
2624 (I) The act or process by which two CAs each certify a public key
2625 of the other, issuing a public-key certificate to that other CA.
2627 (C) Cross-certification enables users to validate each other's
2628 certificate when the users are certified under different
2629 certification hierarchies.
2634 Shirey Informational [Page 47]
2636 RFC 2828 Internet Security Glossary May 2000
2640 (I) The mathematical science that deals with analysis of a
2641 cryptographic system in order to gain knowledge needed to break or
2642 circumvent the protection that the system is designed to provide.
2645 (O) "The analysis of a cryptographic system and/or its inputs and
2646 outputs to derive confidential variables and/or sensitive data
2647 including cleartext." [I7498 Part 2]
2649 (C) The "O" definition states the traditional goal of
2650 cryptanalysis--convert the ciphertext to plaintext (which usually
2651 is cleartext) without knowing the key--but that definition applies
2652 only to encryption systems. Today, the term is used with reference
2653 to all kinds of cryptographic algorithms and key management, and
2654 the "I" definition reflects that. In all cases, however, a
2655 cryptanalyst tries to uncover or reproduce someone else's
2656 sensitive data, such as cleartext, a key, or an algorithm. The
2657 basic cryptanalytic attacks on encryption systems are ciphertext-
2658 only, known-plaintext, chosen-plaintext, and chosen-ciphertext;
2659 and these generalize to the other kinds of cryptography.
2662 (D) Except as part of certain long-established terms listed in
2663 this Glossary, ISDs SHOULD NOT use this abbreviated term because
2664 it may be misunderstood. Instead, use "cryptography" or
2667 $ cryptographic algorithm
2668 (I) An algorithm that employs the science of cryptography,
2669 including encryption algorithms, cryptographic hash algorithms,
2670 digital signature algorithms, and key agreement algorithms.
2672 $ cryptographic application programming interface (CAPI)
2673 (I) The source code formats and procedures through which an
2674 application program accesses cryptographic services, which are
2675 defined abstractly compared to their actual implementation. For
2676 example, see: PKCS #11, [R2628].
2678 $ cryptographic card
2679 (I) A cryptographic token in the form of a smart card or a PC
2682 $ cryptographic component
2683 (I) A generic term for any system component that involves
2684 cryptography. (See: cryptographic module.)
2690 Shirey Informational [Page 48]
2692 RFC 2828 Internet Security Glossary May 2000
2695 $ cryptographic hash
2696 See: (secondary definition under) hash function.
2698 $ cryptographic ignition key (CIK)
2699 (I) A physical (usually electronic) token used to store,
2700 transport, and protect cryptographic keys. (Sometimes abbreviated
2701 as "crypto ignition key".)
2703 (C) A typical use is to divide a split key between a CIK and a
2704 cryptographic module, so that it is necessary to combine the two
2705 to regenerate a key-encrypting key and thus activate the module
2706 and other keys it contains.
2709 (I) Usually shortened to just "key". An input parameter that
2710 varies the transformation performed by a cryptographic algorithm.
2712 (O) "A sequence of symbols that controls the operations of
2713 encipherment and decipherment." [I7498 Part 2]
2715 (C) If a key value needs to be kept secret, the sequence of
2716 symbols (usually bits) that comprise it should be random, or at
2717 least pseudo-random, because that makes the key hard for an
2718 adversary to guess. (See: cryptanalysis, brute force attack.)
2720 $ Cryptographic Message Syntax (CMS)
2721 (I) A encapsulation syntax for digital signatures, hashes, and
2722 encryption of arbitrary messages. [R2630]
2724 (C) CMS was derived from PKCS #7. CMS values are specified with
2725 ASN.1 and use BER encoding. The syntax permits multiple
2726 encapsulation with nesting, permits arbitrary attributes to be
2727 signed along with message content, and supports a variety of
2728 architectures for digital certificate-based key management.
2730 $ cryptographic module
2731 (I) A set of hardware, software, firmware, or some combination
2732 thereof that implements cryptographic logic or processes,
2733 including cryptographic algorithms, and is contained within the
2734 module's cryptographic boundary, which is an explicitly defined
2735 contiguous perimeter that establishes the physical bounds of the
2738 $ cryptographic system
2739 (I) A set of cryptographic algorithms together with the key
2740 management processes that support use of the algorithms in some
2741 application context.
2746 Shirey Informational [Page 49]
2748 RFC 2828 Internet Security Glossary May 2000
2751 (C) This "I" definition covers a wider range of algorithms than
2752 the following "O" definition:
2754 (O) "A collection of transformations from plaintext into
2755 ciphertext and vice versa [which would exclude digital signature,
2756 cryptographic hash, and key agreement algorithms], the particular
2757 transformation(s) to be used being selected by keys. The
2758 transformations are normally defined by a mathematical algorithm."
2761 $ cryptographic token
2762 (I) A portable, user-controlled, physical device used to store
2763 cryptographic information and possibly perform cryptographic
2764 functions. (See: cryptographic card, token.)
2766 (C) A smart token may implement some set of cryptographic
2767 algorithms and may implement related algorithms and key management
2768 functions, such as a random number generator. A smart
2769 cryptographic token may contain a cryptographic module or may not
2770 be explicitly designed that way.
2773 (I) The mathematical science that deals with transforming data to
2774 render its meaning unintelligible (i.e., to hide its semantic
2775 content), prevent its undetected alteration, or prevent its
2776 unauthorized use. If the transformation is reversible,
2777 cryptography also deals with restoring encrypted data to
2778 intelligible form. (See: cryptology, steganography.)
2780 (O) "The discipline which embodies principles, means, and methods
2781 for the transformation of data in order to hide its information
2782 content, prevent its undetected modification and/or prevent its
2783 unauthorized use. . . . Cryptography determines the methods used
2784 in encipherment and decipherment." [I7498 Part 2]
2787 See: (secondary definition under) PKCS #11.
2790 (I) The science that includes both cryptography and cryptanalysis,
2791 and sometimes is said to include steganography.
2794 (I) A group of system entities that share a secret cryptographic
2795 key for a symmetric algorithm.
2802 Shirey Informational [Page 50]
2804 RFC 2828 Internet Security Glossary May 2000
2808 (I) The time span during which a particular key is authorized to
2809 be used in a cryptographic system. (See: key management.)
2811 (C) A cryptoperiod is usually stated in terms of calendar or clock
2812 time, but sometimes is stated in terms of the maximum amount of
2813 data permitted to be processed by a cryptographic algorithm using
2814 the key. Specifying a cryptoperiod involves a tradeoff between the
2815 cost of rekeying and the risk of successful cryptanalysis.
2817 (C) Although we deprecate its prefix, this term is long-
2818 established in COMPUSEC usage. (See: crypto) In the context of
2819 certificates and public keys, "key lifetime" and "validity period"
2820 are often used instead.
2823 (D) ISDs SHOULD NOT use this term as an abbreviation for
2824 cryptographic system. (For rationale, see: crypto.)
2827 See: computer security incident response team.
2830 See: Computer Security Objects Register.
2832 $ cut-and-paste attack
2833 (I) An active attack on the data integrity of ciphertext, effected
2834 by replacing sections of ciphertext with other ciphertext, such
2835 that the result appears to decrypt correctly but actually decrypts
2836 to plaintext that is forged to the satisfaction of the attacker.
2838 $ cyclic redundancy check (CRC)
2839 (I) Sometimes called "cyclic redundancy code". A type of checksum
2840 algorithm that is not a cryptographic hash but is used to
2841 implement data integrity service where accidental changes to data
2845 See: Data Authentication Code, discretionary access control.
2848 See: Distributed Authentication Security Service.
2851 (I) Information in a specific physical representation, usually a
2852 sequence of symbols that have meaning; especially a representation
2853 of information that can be processed or produced by a computer.
2858 Shirey Informational [Page 51]
2860 RFC 2828 Internet Security Glossary May 2000
2863 $ Data Authentication Algorithm
2864 (N) A keyed hash function equivalent to DES cipher block chaining
2865 with IV = 0. [A9009]
2867 (D) ISDs SHOULD NOT use the uncapitalized form of this term as a
2868 synonym for other kinds of checksums.
2870 $ data authentication code vs. Data Authentication Code (DAC)
2871 1. (N) Capitalized: "The Data Authentication Code" refers to a
2872 U.S. Government standard [FP113] for a checksum that is computed
2873 by the Data Authentication Algorithm. (Also known as the ANSI
2874 standard Message Authentication Code [A9009].)
2876 2. (D) Not capitalized: ISDs SHOULD NOT use "data authentication
2877 code" as a synonym for another kind of checksum, because this term
2878 mixes concepts in a potentially misleading way. (See:
2879 authentication code.) Instead, use "checksum", "error detection
2880 code", "hash", "keyed hash", "Message Authentication Code", or
2881 "protected checksum", depending on what is meant.
2884 (I) A security incident in which information is exposed to
2885 potential unauthorized access, such that unauthorized disclosure,
2886 alteration, or use of the information may have occurred. (See:
2889 $ data confidentiality
2890 (I) "The property that information is not made available or
2891 disclosed to unauthorized individuals, entities, or processes
2892 [i.e., to any unauthorized system entity]." [I7498 Part 2]. (See:
2893 data confidentiality service.)
2895 (D) ISDs SHOULD NOT use this term as a synonym for "privacy",
2896 which is a different concept.
2898 $ data confidentiality service
2899 (I) A security service that protects data against unauthorized
2900 disclosure. (See: data confidentiality.)
2902 (D) ISDs SHOULD NOT use this term as a synonym for "privacy",
2903 which is a different concept.
2905 $ Data Encryption Algorithm (DEA)
2906 (N) A symmetric block cipher, defined as part of the U.S.
2907 Government's Data Encryption Standard. DEA uses a 64-bit key, of
2908 which 56 bits are independently chosen and 8 are parity bits, and
2909 maps a 64-bit block into another 64-bit block. [FP046] (See: DES,
2910 symmetric cryptography.)
2914 Shirey Informational [Page 52]
2916 RFC 2828 Internet Security Glossary May 2000
2919 (C) This algorithm is usually referred to as "DES". The algorithm
2920 has also been adopted in standards outside the Government (e.g.,
2923 $ data encryption key (DEK)
2924 (I) A cryptographic key that is used to encipher application data.
2925 (See: key-encrypting key.)
2927 $ Data Encryption Standard (DES)
2928 (N) A U.S. Government standard [FP046] that specifies the Data
2929 Encryption Algorithm and states policy for using the algorithm to
2930 protect unclassified, sensitive data. (See: AES, DEA.)
2933 (I) The property that data has not been changed, destroyed, or
2934 lost in an unauthorized or accidental manner. (See: data integrity
2937 (O) "The property that information has not been modified or
2938 destroyed in an unauthorized manner." [I7498 Part 2]
2940 (C) Deals with constancy of and confidence in data values, not
2941 with the information that the values represent (see: correctness
2942 integrity) or the trustworthiness of the source of the values
2943 (see: source integrity).
2945 $ data integrity service
2946 (I) A security service that protects against unauthorized changes
2947 to data, including both intentional change or destruction and
2948 accidental change or loss, by ensuring that changes to data are
2949 detectable. (See: data integrity.)
2951 (C) A data integrity service can only detect a change and report
2952 it to an appropriate system entity; changes cannot be prevented
2953 unless the system is perfect (error-free) and no malicious user
2954 has access. However, a system that offers data integrity service
2955 might also attempt to correct and recover from changes.
2957 (C) Relationship between data integrity service and authentication
2958 services: Although data integrity service is defined separately
2959 from data origin authentication service and peer entity
2960 authentication service, it is closely related to them.
2961 Authentication services depend, by definition, on companion data
2962 integrity services. Data origin authentication service provides
2963 verification that the identity of the original source of a
2964 received data unit is as claimed; there can be no such
2965 verification if the data unit has been altered. Peer entity
2970 Shirey Informational [Page 53]
2972 RFC 2828 Internet Security Glossary May 2000
2975 authentication service provides verification that the identity of
2976 a peer entity in a current association is as claimed; there can be
2977 no such verification if the claimed identity has been altered.
2979 $ data origin authentication
2980 (I) "The corroboration that the source of data received is as
2981 claimed." [I7498 Part 2] (See: authentication.)
2983 $ data origin authentication service
2984 (I) A security service that verifies the identity of a system
2985 entity that is claimed to be the original source of received data.
2986 (See: authentication, authentication service.)
2988 (C) This service is provided to any system entity that receives or
2989 holds the data. Unlike peer entity authentication service, this
2990 service is independent of any association between the originator
2991 and the recipient, and the data in question may have originated at
2992 any time in the past.
2994 (C) A digital signature mechanism can be used to provide this
2995 service, because someone who does not know the private key cannot
2996 forge the correct signature. However, by using the signer's public
2997 key, anyone can verify the origin of correctly signed data.
2999 (C) This service is usually bundled with connectionless data
3000 integrity service. (See: (relationship between data integrity
3001 service and authentication services under) data integrity service.
3004 (D) ISDs SHOULD NOT use this term because it mix concepts in a
3005 potentially misleading way. Instead, use either "data
3006 confidentiality" or "privacy", depending on what is meant.
3009 (I) The protection of data from disclosure, alteration,
3010 destruction, or loss that either is accidental or is intentional
3013 (C) Both data confidentiality service and data integrity service
3014 are needed to achieve data security.
3017 (I) "A self-contained, independent entity of data carrying
3018 sufficient information to be routed from the source to the
3019 destination." [R1983]
3022 See: Data Encryption Algorithm.
3026 Shirey Informational [Page 54]
3028 RFC 2828 Internet Security Glossary May 2000
3032 See: (secondary definition under) threat consequence.
3035 (D) ISDs SHOULD NOT use this term as a synonym for "decrypt",
3036 except in special circumstances. (See: (usage discussion under)
3040 (D) ISDs SHOULD NOT use this term as a synonym for "decryption",
3041 except in special circumstances. (See: (usage discussion under)
3045 (I) Convert encoded data back to its original form of
3046 representation. (See: decrypt.)
3048 (D) ISDs SHOULD NOT use this term as a synonym for "decrypt",
3049 because that would mix concepts in a potentially misleading way.
3052 (I) Cryptographically restore ciphertext to the plaintext form it
3053 had before encryption.
3056 See: (secondary definition under) encryption.
3058 $ dedicated security mode
3059 (I) A mode of operation of an information system, wherein all
3060 users have the clearance or authorization, and the need-to-know,
3061 for all data handled by the system. In this mode, the system may
3062 handle either a single classification level or category of
3063 information or a range of levels and categories. [DOD2]
3065 (C) This mode is defined formally in U.S. Department of Defense
3066 policy regarding system accreditation, but the term is also used
3067 outside the Defense Department and outside the Government.
3070 (I) A system login account (usually accessed with a user name and
3071 password) that has been predefined in a manufactured system to
3072 permit initial access when the system is first put into service.
3074 (C) Sometimes, the default user name and password are the same in
3075 each copy of the system. In any case, when the system is put into
3076 service, the default password should immediately be changed or the
3077 default account should be disabled.
3082 Shirey Informational [Page 55]
3084 RFC 2828 Internet Security Glossary May 2000
3088 (N) Apply a magnetic field to permanently remove, erase, or clear
3089 data from a magnetic storage medium, such as a tape or disk
3090 [NCS25]. Reduce magnetic flux density to zero by applying a
3091 reversing magnetic field.
3094 (N) An electrical device that can degauss magnetic storage media.
3097 See: data encryption key.
3100 (I) A partial CRL that only contains entries for X.509
3101 certificates that have been revoked since the issuance of a prior,
3102 base CRL. This method can be used to partition CRLs that become
3103 too large and unwieldy.
3106 (I) The prevention of authorized access to a system resource or
3107 the delaying of system operations and functions. (See:
3108 availability, critical (resource of a system), flooding.)
3111 See: Data Encryption Standard.
3114 (I) An attack that uses a brute-force technique of successively
3115 trying all the words in some large, exhaustive list.
3117 (C) For example, an attack on an authentication service by trying
3118 all possible passwords; or an attack on encryption by encrypting
3119 some known plaintext phrase with all possible keys so that the key
3120 for any given encrypted message containing that phrase may be
3124 (N) A key agreement algorithm published in 1976 by Whitfield
3125 Diffie and Martin Hellman [DH76, R2631].
3127 (C) Diffie-Hellman does key establishment, not encryption.
3128 However, the key that it produces may be used for encryption, for
3129 further key management operations, or for any other cryptography.
3131 (C) The difficulty of breaking Diffie-Hellman is considered to be
3132 equal to the difficulty of computing discrete logarithms modulo a
3133 large prime. The algorithm is described in [R2631] and [Schn]. In
3134 brief, Alice and Bob together pick large integers that satisfy
3138 Shirey Informational [Page 56]
3140 RFC 2828 Internet Security Glossary May 2000
3143 certain mathematical conditions, and then use the integers to each
3144 separately compute a public-private key pair. They send each other
3145 their public key. Each person uses their own private key and the
3146 other person's public key to compute a key, k, that, because of
3147 the mathematics of the algorithm, is the same for each of them.
3148 Passive wiretapping cannot learn the shared k, because k is not
3149 transmitted, and neither are the private keys needed to compute k.
3150 However, without additional mechanisms to authenticate each party
3151 to the other, a protocol based on the algorithm may be vulnerable
3152 to a man-in-the-middle attack.
3155 See: message digest.
3157 $ digital certificate
3158 (I) A certificate document in the form of a digital data object (a
3159 data object used by a computer) to which is appended a computed
3160 digital signature value that depends on the data object. (See:
3161 attribute certificate, capability, public-key certificate.)
3163 (D) ISDs SHOULD NOT use this term to refer to a signed CRL or CKL.
3164 Although the recommended definition can be interpreted to include
3165 those items, the security community does not use the term with
3168 $ digital certification
3169 (D) ISDs SHOULD NOT use this term as a synonym for
3170 "certification", unless the context is not sufficient to
3171 distinguish between digital certification and another kind of
3172 certification, in which case it would be better to use "public-key
3173 certification" or another phrase that indicates what is being
3177 (I) An electronic data object that represents information
3178 originally written in a non-electronic, non-magnetic medium
3179 (usually ink on paper) or is an analogue of a document of that
3183 (I) A digital envelope for a recipient is a combination of (a)
3184 encrypted content data (of any kind) and (b) the content
3185 encryption key in an encrypted form that has been prepared for the
3186 use of the recipient.
3188 (C) In ISDs, this term should be defined at the point of first use
3189 because, although the term is defined in PKCS #7 and used in
3190 S/MIME, it is not yet widely established.
3194 Shirey Informational [Page 57]
3196 RFC 2828 Internet Security Glossary May 2000
3199 (C) Digital enveloping is not simply a synonym for implementing
3200 data confidentiality with encryption; digital enveloping is a
3201 hybrid encryption scheme to "seal" a message or other data, by
3202 encrypting the data and sending both it and a protected form of
3203 the key to the intended recipient, so that no one other than the
3204 intended recipient can "open" the message. In PCKS #7, it means
3205 first encrypting the data using a symmetric encryption algorithm
3206 and a secret key, and then encrypting the secret key using an
3207 asymmetric encryption algorithm and the public key of the intended
3208 recipient. In S/MIME, additional methods are defined for
3209 conveying the content encryption key.
3211 $ Digital ID(service mark)
3212 (D) ISDs SHOULD NOT use this term as a synonym for "digital
3213 certificate" because (a) it is the service mark of a commercial
3214 firm, (b) it unnecessarily duplicates the meaning of other, well-
3215 established terms, and (c) a certificate is not always used as
3216 authentication information. In some contexts, however, it may be
3217 useful to explain that the key conveyed in a public-key
3218 certificate can be used to verify an identity and, therefore, that
3219 the certificate can be thought of as digital identification
3220 information. (See: identification information.)
3223 (C) The adjective "digital" need not be used with "key" or
3224 "cryptographic key", unless the context is insufficient to
3225 distinguish the digital key from another kind of key, such as a
3226 metal key for a door lock.
3229 (I) Analogous to a notary public. Provides a trusted date-and-time
3230 stamp for a document, so that someone can later prove that the
3231 document existed at a point in time. May also verify the
3232 signature(s) on a signed document before applying the stamp. (See:
3236 (I) A value computed with a cryptographic algorithm and appended
3237 to a data object in such a way that any recipient of the data can
3238 use the signature to verify the data's origin and integrity. (See:
3239 data origin authentication service, data integrity service,
3240 digitized signature, electronic signature, signer.)
3242 (I) "Data appended to, or a cryptographic transformation of, a
3243 data unit that allows a recipient of the data unit to prove the
3244 source and integrity of the data unit and protect against forgery,
3245 e.g. by the recipient." [I7498 Part 2]
3250 Shirey Informational [Page 58]
3252 RFC 2828 Internet Security Glossary May 2000
3255 (C) Typically, the data object is first input to a hash function,
3256 and then the hash result is cryptographically transformed using a
3257 private key of the signer. The final resulting value is called the
3258 digital signature of the data object. The signature value is a
3259 protected checksum, because the properties of a cryptographic hash
3260 ensure that if the data object is changed, the digital signature
3261 will no longer match it. The digital signature is unforgeable
3262 because one cannot be certain of correctly creating or changing
3263 the signature without knowing the private key of the supposed
3266 (C) Some digital signature schemes use a asymmetric encryption
3267 algorithm (e.g., see: RSA) to transform the hash result. Thus,
3268 when Alice needs to sign a message to send to Bob, she can use her
3269 private key to encrypt the hash result. Bob receives both the
3270 message and the digital signature. Bob can use Alice's public key
3271 to decrypt the signature, and then compare the plaintext result to
3272 the hash result that he computes by hashing the message himself.
3273 If the values are equal, Bob accepts the message because he is
3274 certain that it is from Alice and has arrived unchanged. If the
3275 values are not equal, Bob rejects the message because either the
3276 message or the signature was altered in transit.
3278 (C) Other digital signature schemes (e.g., see: DSS) transform the
3279 hash result with an algorithm (e.g., see: DSA, El Gamal) that
3280 cannot be directly used to encrypt data. Such a scheme creates a
3281 signature value from the hash and provides a way to verify the
3282 signature value, but does not provide a way to recover the hash
3283 result from the signature value. In some countries, such a scheme
3284 may improve exportability and avoid other legal constraints on
3287 $ Digital Signature Algorithm (DSA)
3288 (N) An asymmetric cryptographic algorithm that produces a digital
3289 signature in the form of a pair of large numbers. The signature is
3290 computed using rules and parameters such that the identity of the
3291 signer and the integrity of the signed data can be verified. (See:
3292 Digital Signature Standard.)
3294 $ Digital Signature Standard (DSS)
3295 (N) The U.S. Government standard [FP186] that specifies the
3296 Digital Signature Algorithm (DSA), which involves asymmetric
3299 $ digital watermarking
3300 (I) Computing techniques for inseparably embedding unobtrusive
3301 marks or labels as bits in digital data--text, graphics, images,
3302 video, or audio--and for detecting or extracting the marks later.
3306 Shirey Informational [Page 59]
3308 RFC 2828 Internet Security Glossary May 2000
3311 (C) The set of embedded bits (the digital watermark) is sometimes
3312 hidden, usually imperceptible, and always intended to be
3313 unobtrusive. Depending on the particular technique that is used,
3314 digital watermarking can assist in proving ownership, controlling
3315 duplication, tracing distribution, ensuring data integrity, and
3316 performing other functions to protect intellectual property
3319 $ digitized signature
3320 (D) ISDs SHOULD NOT use this term because there is no current
3321 consensus on its definition. Although it appears to be used mainly
3322 to refer to various forms of digitized images of handwritten
3323 signatures, the term should be avoided because it might be
3324 confused with "digital signature".
3328 See: directory vs. Directory.
3330 $ Directory Access Protocol (DAP)
3331 (N) An OSI protocol [X519] for communication between a Directory
3332 User Agent (a client) and a Directory System Agent (a server).
3333 (See: Lightweight Directory Access Protocol.)
3335 $ directory vs. Directory
3336 1. (I) Not capitalized: The term "directory" refers generically to
3337 a database server or other system that provides information--such
3338 as a digital certificate or CRL--about an entity whose name is
3341 2. (I) Capitalized: "Directory" refers specifically to the X.500
3342 Directory. (See: repository.)
3345 (D) A synonym for "contingency plan". In the interest of
3346 consistency, ISDs SHOULD use "contingency plan" instead of
3349 $ disclosure (i.e., unauthorized disclosure)
3350 See: (secondary definition under) threat consequence.
3352 $ discretionary access control (DAC)
3353 (I) An access control service that enforces a security policy
3354 based on the identity of system entities and their authorizations
3355 to access system resources. (See: access control list, identity-
3356 based security policy, mandatory access control.)
3362 Shirey Informational [Page 60]
3364 RFC 2828 Internet Security Glossary May 2000
3367 (C) This service is termed "discretionary" because an entity might
3368 have access rights that permit the entity, by its own volition, to
3369 enable another entity to access some resource.
3371 (O) "A means of restricting access to objects based on the
3372 identity of subjects and/or groups to which they belong. The
3373 controls are discretionary in the sense that a subject with a
3374 certain access permission is capable of passing that permission
3375 (perhaps indirectly) on to any other subject." [DOD1]
3378 See: (secondary definition under) threat consequence.
3380 $ Distinguished Encoding Rules (DER)
3381 (N) A subset of the Basic Encoding Rules, which gives exactly one
3382 way to represent any ASN.1 value as an octet string [X690].
3384 (C) Since there is more than one way to encode ASN.1 in BER, DER
3385 is used in applications in which a unique encoding is needed, such
3386 as when a digital signature is computed on an ASN.1 value.
3388 $ distinguished name (DN)
3389 (I) An identifier that uniquely represents an object in the X.500
3390 Directory Information Tree (DIT) [X501]. (See: domain name.)
3392 (C) A DN is a set of attribute values that identify the path
3393 leading from the base of the DIT to the object that is named. An
3394 X.509 public-key certificate or CRL contains a DN that identifies
3395 its issuer, and an X.509 attribute certificate contains a DN or
3396 other form of name that identifies its subject.
3398 $ Distributed Authentication Security Service (DASS)
3399 (I) An experimental Internet protocol [R1507] that uses
3400 cryptographic mechanisms to provide strong, mutual authentication
3401 services in a distributed environment.
3403 $ distribution point
3404 (I) An X.500 Directory entry or other information source that is
3405 named in a v3 X.509 public-key certificate extension as a location
3406 from which to obtain a CRL that might list the certificate.
3408 (C) A v3 X.509 public-key certificate may have a
3409 "cRLDistributionPoints" extension that names places to get CRLs on
3410 which the certificate might be listed. A CRL obtained from a
3411 distribution point may (a) cover either all reasons for which a
3412 certificate might be revoked or only some of the reasons, (b) be
3413 issued by either the authority that signed the certificate or some
3418 Shirey Informational [Page 61]
3420 RFC 2828 Internet Security Glossary May 2000
3423 other authority, and (c) contain revocation entries for only a
3424 subset of the full set of certificates issued by one CA or (c')
3425 contain revocation entries for multiple CAs.
3428 See: distinguished name.
3431 See: Domain Name System.
3434 See: Domain of Interpretation.
3437 (I) Security usage: An environment or context that is defined by a
3438 security policy, security model, or security architecture to
3439 include a set of system resources and the set of system entities
3440 that have the right to access the resources. (See: domain of
3441 interpretation, security perimeter.)
3443 (I) Internet usage: That part of the Internet domain name space
3444 tree [R1034] that is at or below the name the specifies the
3445 domain. A domain is a subdomain of another domain if it is
3446 contained within that domain. For example, D.C.B.A is a subdomain
3447 of C.B.A. (See: Domain Name System.)
3449 (O) MISSI usage: The domain of a MISSI CA is the set of MISSI
3450 users whose certificates are signed by the CA.
3452 (O) OSI usage: An administrative partition of a complex
3453 distributed OSI system.
3456 (I) The style of identifier--a sequence of case-insensitive ASCII
3457 labels separated by dots ("bbn.com.")--defined for subtrees in the
3458 Internet Domain Name System [R1034] and used in other Internet
3459 identifiers, such as host names (e.g., "rosslyn.bbn.com."),
3460 mailbox names (e.g., "rshirey@bbn.com."), and URLs (e.g.,
3461 "http://www.rosslyn.bbn.com/foo"). (See: distinguished name,
3464 (C) The domain name space of the DNS is a tree structure in which
3465 each node and leaf holds records describing a resource. Each node
3466 has a label. The domain name of a node is the list of labels on
3467 the path from the node to the root of the tree. The labels in a
3468 domain name are printed or read left to right, from the most
3469 specific (lowest, farthest from the root) to the least specific
3470 (highest, closest to the root). The root's label is the null
3474 Shirey Informational [Page 62]
3476 RFC 2828 Internet Security Glossary May 2000
3479 string, so a complete domain name properly ends in a dot. The top-
3480 level domains, those immediately below the root, include COM, EDU,
3481 GOV, INT, MIL, NET, ORG, and two-letter country codes (such as US)
3482 from ISO-3166. [R1591] (See: country code.)
3484 $ Domain Name System (DNS)
3485 (I) The main Internet operations database, which is distributed
3486 over a collection of servers and used by client software for
3487 purposes such as translating a domain name-style host name into an
3488 IP address (e.g., "rosslyn.bbn.com" is "192.1.7.10") and locating
3489 a host that accepts mail for some mailbox address. [R1034]
3491 (C) The DNS has three major components:
3493 - Domain name space and resource records: Specifications for the
3494 tree-structured domain name space, and data associated with the
3497 - Name servers: Programs that hold information about a subset of
3498 the tree's structure and data holdings, and also hold pointers
3499 to other name servers that can provide information from any
3502 - Resolvers: Programs that extract information from name servers
3503 in response to client requests; typically, system routines
3504 directly accessible to user programs.
3506 (C) Extensions to the DNS [R2065, R2137, R2536] support (a) key
3507 distribution for public keys needed for the DNS and for other
3508 protocols, (b) data origin authentication service and data
3509 integrity service for resource records, (c) data origin
3510 authentication service for transactions between resolvers and
3511 servers, and (d) access control of records.
3513 $ domain of interpretation (DOI)
3514 (I) IPsec usage: An ISAKMP/IKE DOI defines payload formats,
3515 exchange types, and conventions for naming security-relevant
3516 information such as security policies or cryptographic algorithms
3519 (C) For example, see [R2407]. The DOI concept is based on work by
3520 the TSIG's CIPSO Working Group.
3523 (I) Security level A is said to "dominate" security level B if the
3524 hierarchical classification level of A is greater (higher) than or
3525 equal to that of B and the nonhierarchical categories of A include
3530 Shirey Informational [Page 63]
3532 RFC 2828 Internet Security Glossary May 2000
3536 (I) A portable, physical, electronic device that is required to be
3537 attached to a computer to enable a particular software program to
3540 (C) A dongle is essentially a physical key used for copy
3541 protection of software, because the program will not run unless
3542 the matching dongle is attached. When the software runs, it
3543 periodically queries the dongle and quits if the dongle does not
3544 reply with the proper authentication information. Dongles were
3545 originally constructed as an EPROM (erasable programmable read-
3546 only memory) to be connected to a serial input-output port of a
3550 (I) Reduce the classification level of information in an
3554 (D) ISDs SHOULD NOT use this term, because the Request for Comment
3555 series is archival in nature and does not have a "draft" category.
3556 (Instead, see: Internet Draft, Draft Standard (in Internet
3560 See: Digital Signature Algorithm.
3563 See: Digital Signature Standard.
3566 (I) A procedure that uses two or more entities (usually persons)
3567 operating in concert to protect a system resource, such that no
3568 single entity acting alone can access that resource. (See: no-lone
3569 zone, separation of duties, split knowledge.)
3572 (D) ISDs SHOULD NOT use this term except when stated as
3573 "SET(trademark) dual signature" with the following meaning:
3575 (O) SET usage: A single digital signature that protects two
3576 separate messages by including the hash results for both sets in a
3577 single encrypted value. [SET2]
3586 Shirey Informational [Page 64]
3588 RFC 2828 Internet Security Glossary May 2000
3591 (C) Generated by hashing each message separately, concatenating
3592 the two hash results, and then hashing that value and encrypting
3593 the result with the signer's private key. Done to reduce the
3594 number of encryption operations and to enable verification of data
3595 integrity without complete disclosure of the data.
3598 See: Extensible Authentication Protocol
3601 (I) Passive wiretapping done secretly, i.e., without the knowledge
3602 of the originator or the intended recipients of the communication.
3605 See: electronic codebook.
3608 See: Elliptic Curve Digital Signature Algorithm.
3610 $ economy of mechanism
3611 (I) The principle that each security mechanism should be designed
3612 to be as simple as possible, so that the mechanism can be
3613 correctly implemented and so that it can be verified that the
3614 operation of the mechanism enforces the containing system's
3615 security policy. (See: least privilege.)
3618 See: electronic data interchange.
3621 See: (secondary definition under) electronic data interchange.
3624 (D) ISDs SHOULD NOT use this abbreviation because of possible
3625 confusion among "end entity", "end-to-end encryption", "escrowed
3626 encryption standard", and other terms.
3629 See: Escrowed Encryption Standard.
3631 $ El Gamal algorithm
3632 (N) An algorithm for asymmetric cryptography, invented in 1985 by
3633 Taher El Gamal, that is based on the difficulty of calculating
3634 discrete logarithms and can be used for both encryption and
3635 digital signatures. [ElGa, Schn]
3642 Shirey Informational [Page 65]
3644 RFC 2828 Internet Security Glossary May 2000
3647 $ electronic codebook (ECB)
3648 (I) An block cipher mode in which a plaintext block is used
3649 directly as input to the encryption algorithm and the resultant
3650 output block is used directly as ciphertext [FP081].
3652 $ electronic commerce
3653 (I) General usage: Business conducted through paperless exchanges
3654 of information, using electronic data interchange, electronic
3655 funds transfer (EFT), electronic mail, computer bulletin boards,
3656 facsimile, and other paperless technologies.
3658 (O) SET usage: "The exchange of goods and services for payment
3659 between the cardholder and merchant when some or all of the
3660 transaction is performed via electronic communication." [SET2]
3662 $ electronic data interchange (EDI)
3663 (I) Computer-to-computer exchange, between trading partners, of
3664 business data in standardized document formats.
3666 (C) EDI formats have been standardized primarily by ANSI X12 and
3667 by EDIFACT (EDI for Administration, Commerce, and Transportation),
3668 which is an international, UN-sponsored standard primarily used in
3669 Europe and Asia. X12 and EDIFACT are aligning to create a single,
3670 global EDI standard.
3672 $ electronic signature
3673 (D) ISDs SHOULD NOT use this term because there is no current
3674 consensus on its definition. (Instead, see: digital signature.)
3676 $ elliptic curve cryptography (ECC)
3677 (I) A type of asymmetric cryptography based on mathematics of
3678 groups that are defined by the points on a curve.
3680 (C) The most efficient implementation of ECC is claimed to be
3681 stronger per bit of key (against cryptanalysis that uses a brute
3682 force attack) than any other known form of asymmetric
3683 cryptography. ECC is based on mathematics different than the kinds
3684 originally used to define the Diffie-Hellman algorithm and the
3685 Digital Signature Algorithm. ECC is based on the mathematics of
3686 groups defined by the points on a curve, where the curve is
3687 defined by a quadratic equation in a finite field. ECC can be used
3688 to define both an algorithm for key agreement that is an analog of
3689 Diffie-Hellman and an algorithm for digital signature that is an
3690 analog of DSA. (See: ECDSA.)
3692 $ Elliptic Curve Digital Signature Algorithm (ECDSA)
3693 (N) A standard [A9062] that is the elliptic curve cryptography
3694 analog of the Digital Signature Algorithm.
3698 Shirey Informational [Page 66]
3700 RFC 2828 Internet Security Glossary May 2000
3704 (I) An signal (electromagnetic, acoustic, or other medium) that is
3705 emitted by a system (through radiation or conductance) as a
3706 consequence (i.e., byproduct) of its operation, and that may
3707 contain information. (See: TEMPEST.)
3709 $ emanations security (EMSEC)
3710 (I) Physical constraints to prevent information compromise through
3711 signals emanated by a system, particular the application of
3712 TEMPEST technology to block electromagnetic radiation.
3715 (D) A synonym for "contingency plan". In the interest of
3716 consistency, ISDs SHOULD use "contingency plan" instead of
3720 See: emanations security.
3723 (I) An abbreviation of "Europay, MasterCard, Visa". Refers to a
3724 specification for smart cards that are used as payment cards, and
3725 for related terminals and applications. [EMV1, EMV2, EMV3]
3727 $ Encapsulating Security Payload (ESP)
3728 (I) An Internet IPsec protocol [R2406] designed to provide a mix
3729 of security services--especially data confidentiality service--in
3730 the Internet Protocol. (See: Authentication Header.)
3732 (C) ESP may be used alone, or in combination with the IPsec AH
3733 protocol, or in a nested fashion with tunneling. Security services
3734 can be provided between a pair of communicating hosts, between a
3735 pair of communicating security gateways, or between a host and a
3736 gateway. The ESP header is encapsulated by the IP header, and the
3737 ESP header encapsulates either the upper layer protocol header
3738 (transport mode) or an IP header (tunnel mode). ESP can provide
3739 data confidentiality service, data origin authentication service,
3740 connectionless data integrity service, an anti-replay service, and
3741 limited traffic flow confidentiality. The set of services depends
3742 on the placement of the implementation and on options selected
3743 when the security association is established.
3746 (D) ISDs SHOULD NOT use this term as a synonym for "encrypt".
3747 However, see the usage note under "encryption".
3754 Shirey Informational [Page 67]
3756 RFC 2828 Internet Security Glossary May 2000
3760 (D) ISDs SHOULD NOT use this term as a synonym for "encryption",
3761 except in special circumstances that are explained in the usage
3762 discussion under "encryption".
3765 (I) Use a system of symbols to represent information, which might
3766 originally have some other representation. (See: decode.)
3768 (C) Examples include Morse code, ASCII, and BER.
3770 (D) ISDs SHOULD NOT use this term as a synonym for "encrypt",
3771 because encoding is not usually intended to conceal meaning.
3774 (I) Cryptographically transform data to produce ciphertext. (See:
3778 (I) Cryptographic transformation of data (called "plaintext") into
3779 a form (called "ciphertext") that conceals the data's original
3780 meaning to prevent it from being known or used. If the
3781 transformation is reversible, the corresponding reversal process
3782 is called "decryption", which is a transformation that restores
3783 encrypted data to its original state. (See: cryptography.)
3785 (C) Usage note: For this concept, ISDs should use the verb "to
3786 encrypt" (and related variations: encryption, decrypt, and
3787 decryption). However, because of cultural biases, some
3788 international usage, particularly ISO and CCITT standards, avoids
3789 "to encrypt" and instead uses the verb "to encipher" (and related
3790 variations: encipherment, decipher, decipherment).
3792 (O) "The cryptographic transformation of data (see: cryptography)
3793 to produce ciphertext." [I7498 Part 2]
3795 (C) Usually, the plaintext input to an encryption operation is
3796 cleartext. But in some cases, the plaintext may be ciphertext that
3797 was output from another encryption operation. (See:
3800 (C) Encryption and decryption involve a mathematical algorithm for
3801 transforming data. In addition to the data to be transformed, the
3802 algorithm has one or more inputs that are control parameters: (a)
3803 a key value that varies the transformation and, in some cases, (b)
3804 an initialization value that establishes the starting state of the
3810 Shirey Informational [Page 68]
3812 RFC 2828 Internet Security Glossary May 2000
3815 $ encryption certificate
3816 (I) A public-key certificate that contains a public key that is
3817 intended to be used for encrypting data, rather than for verifying
3818 digital signatures or performing other cryptographic functions.
3820 C) A v3 X.509 public-key certificate may have a "keyUsage"
3821 extension that indicates the purpose for which the certified
3822 public key is intended.
3825 (I) A system entity that is the subject of a public-key
3826 certificate and that is using, or is permitted and able to use,
3827 the matching private key only for a purpose or purposes other than
3828 signing a digital certificate; i.e., an entity that is not a CA.
3830 (D) "A certificate subject which uses its public [sic] key for
3831 purposes other than signing certificates." [X509]
3833 (C) ISDs SHOULD NOT use the X.509 definition, because it is
3834 misleading and incomplete. First, the X.509 definition should say
3835 "private key" rather than "public key" because certificates are
3836 not usefully signed with a public key. Second, the X.509
3837 definition is weak regarding whether an end entity may or may not
3838 use the private key to sign a certificate, i.e., whether the
3839 subject may be a CA. The intent of X.509's authors was that an end
3840 entity certificate is not valid for use in verifying a signature
3841 on an X.509 certificate or X.509 CRL. Thus, it would have been
3842 better for the X.509 definition to have said "only for purposes
3843 other than signing certificates".
3845 (C) Despite the problems in the X.509 definition, the term itself
3846 is useful in describing applications of asymmetric cryptography.
3847 The way the term is used in X.509 implies that it was meant to be
3848 defined, as we have done here, relative to roles that an entity
3849 (which is associated with an OSI end system) is playing or is
3850 permitted to play in applications of asymmetric cryptography other
3851 than the PKI that supports applications.
3853 (C) Whether a subject can play both CA and non-CA roles, with
3854 either the same or different certificates, is a matter of policy.
3855 (See: certification practice statement.) A v3 X.509 public-key
3856 certificate may have a "basicConstraints" extension containing a
3857 "cA" value that specifically "indicates whether or not the public
3858 key may be used to verify certificate signatures".
3866 Shirey Informational [Page 69]
3868 RFC 2828 Internet Security Glossary May 2000
3872 (I) An OSI term for a computer that implements all seven layers of
3873 the OSIRM and may attach to a subnetwork. (In the context of the
3874 Internet Protocol Suite, usually called a "host".)
3876 $ end-to-end encryption
3877 (I) Continuous protection of data that flows between two points in
3878 a network, provided by encrypting data when it leaves its source,
3879 leaving it encrypted while it passes through any intermediate
3880 computers (such as routers), and decrypting only when the data
3881 arrives at the intended destination. (See: link encryption,
3884 (C) When two points are separated by multiple communication links
3885 that are connected by one or more intermediate relays, end-to-end
3886 encryption enables the source and destination systems to protect
3887 their communications without depending on the intermediate systems
3888 to provide the protection.
3891 (I) General usage: A system entity, usually a human individual,
3892 that makes use of system resources, primarily for application
3893 purposes as opposed to system management purposes.
3895 (I) PKI usage: A synonym for "end entity"; but the term "end
3896 entity" is preferred.
3902 (I) "The deliberate planting of apparent flaws in a system for the
3903 purpose of detecting attempted penetrations or confusing an
3904 intruder about which flaws to exploit." [FP039] (See: honey pot.)
3907 (I) A public key or a private key that is relatively short-lived.
3910 $ error detection code
3911 (I) A checksum designed to detect, but not correct, accidental
3912 (i.e., unintentional) changes in data.
3914 $ Escrowed Encryption Standard (EES)
3915 (N) A U.S. Government standard [FP185] that specifies use of a
3916 symmetric encryption algorithm (SKIPJACK) and a Law Enforcement
3922 Shirey Informational [Page 70]
3924 RFC 2828 Internet Security Glossary May 2000
3927 Access Field (LEAF) creation method to implement part of a key
3928 escrow system that provides for decryption of encrypted
3929 telecommunications when interception is lawfully authorized.
3931 (C) Both SKIPJACK and the LEAF are to be implemented in equipment
3932 used to encrypt and decrypt unclassified, sensitive
3933 telecommunications data.
3936 See: Encapsulating Security Payload.
3939 (N) A language (ISO 9074-1989) for formal specification of
3940 computer network protocols.
3942 $ evaluated products list
3943 (O) General usage: A list of information system equipment items
3944 that have been evaluated against, and found to be compliant with,
3945 a particular set of criteria.
3947 (O) U.S. Department of Defense usage: The Evaluated Products List
3948 (http://www.radium.ncsc.mil/tpep/epl/) contains items that have
3949 been evaluated against the TCSEC by the NCSC, or against the
3950 Common Criteria by the NCSC or one of its partner agencies in
3951 another county. The List forms Chapter 4 of NSA's "Information
3952 Systems Security Products and Services Catalogue".
3955 (I) Refers to a system that has been evaluated against security
3956 criteria such as the TCSEC or the Common Criteria.
3959 See: certificate expiration.
3962 See: (secondary definition under) threat consequence.
3964 $ Extensible Authentication Protocol
3965 (I) A framework that supports multiple, optional authentication
3966 mechanisms for PPP, including cleartext passwords, challenge-
3967 response, and arbitrary dialog sequences. [R2284]
3969 (C) This protocol is intended for use primarily by a host or
3970 router that connects to a PPP network server via switched circuits
3978 Shirey Informational [Page 71]
3980 RFC 2828 Internet Security Glossary May 2000
3984 (I) A data item defined for optional inclusion in a v3 X.509
3985 public-key certificate or a v2 X.509 CRL.
3987 (C) The formats defined in X.509 can be extended to provide
3988 methods for associating additional attributes with subjects and
3989 public keys and for managing a certification hierarchy:
3991 - "Certificate extension": X.509 defines standard extensions that
3992 may be included in v3 certificates to provide additional key
3993 and security policy information, subject and issuer attributes,
3994 and certification path constraints.
3996 - "CRL extension": X.509 defines extensions that may be included
3997 in v2 CRLs to provide additional issuer key and name
3998 information, revocation reasons and constraints, and
3999 information about distribution points and delta CRLs.
4001 - "Private extension": Additional extensions, each named by an
4002 OID, can be locally defined as needed by applications or
4003 communities. (See: PKIX private extension, SET private
4007 (I) A computer network that an organization uses to carry
4008 application data traffic between the organization and its business
4009 partners. (See: intranet.)
4011 (C) An extranet can be implemented securely, either on the
4012 Internet or using Internet technology, by constructing the
4016 (I) A mode of system termination that automatically leaves system
4017 processes and components in a secure state when a failure occurs
4018 or is detected in the system.
4021 (I) Selective termination of affected non-essential system
4022 functions and processes when a failure occurs or is detected in
4026 (I) A methodology used to provide fail-safe or fail-soft
4027 termination and recovery of functions and processes when failures
4028 are detected or occur in a system. [FP039]
4034 Shirey Informational [Page 72]
4036 RFC 2828 Internet Security Glossary May 2000
4039 $ Federal Information Processing Standards (FIPS)
4040 (N) The Federal Information Processing Standards Publication (FIPS
4041 PUB) series issued by the U.S. National Institute of Standards and
4042 Technology as technical guidelines for U.S. Government
4043 procurements of information processing system equipment and
4044 services. [FP031, FP039, FP046, FP081, FP102, FP113, FP140, FP151,
4045 FP180, FP185, FP186, FP188]
4047 (C) Issued under the provisions of section 111(d) of the Federal
4048 Property and Administrative Services Act of 1949 as amended by the
4049 Computer Security Act of 1987, Public Law 100-235.
4051 $ Federal Public-key Infrastructure (FPKI)
4052 (N) A PKI being planned to establish facilities, specifications,
4053 and policies needed by the U.S. Federal Government to use public-
4054 key certificates for INFOSEC, COMSEC, and electronic commerce
4055 involving unclassified but sensitive applications and interactions
4056 between Federal agencies as well as with entities of other
4057 branches of the Federal Government, state, and local governments,
4058 business, and the public. [FPKI]
4060 $ Federal Standard 1027
4061 (N) An U.S. Government document defining emanation, anti-tamper,
4062 security fault analysis, and manual key management criteria for
4063 DES encryption devices, primary for OSI layer 2. Was renamed "FIPS
4064 PUB 140" when responsibility for protecting unclassified,
4065 sensitive information was transferred from NSA to NIST, and then
4066 was superseded by FIPS PUB 140-1.
4068 $ File Transfer Protocol (FTP)
4069 (I) A TCP-based, application-layer, Internet Standard protocol
4070 [R0959] for moving data files from one computer to another.
4073 (I) An internetwork router that selectively prevents the passage
4074 of data packets according to a security policy.
4076 (C) A filtering router may be used as a firewall or part of a
4077 firewall. A router usually receives a packet from a network and
4078 decides where to forward it on a second network. A filtering
4079 router does the same, but first decides whether the packet should
4080 be forwarded at all, according to some security policy. The policy
4081 is implemented by rules (packet filters) loaded into the router.
4082 The rules mostly involve values of data packet control fields
4083 (especially IP source and destination addresses and TCP port
4090 Shirey Informational [Page 73]
4092 RFC 2828 Internet Security Glossary May 2000
4095 $ financial institution
4096 (N) "An establishment responsible for facilitating customer-
4097 initiated transactions or transmission of funds for the extension
4098 of credit or the custody, loan, exchange, or issuance of money."
4102 (I) A pattern of curves formed by the ridges on a fingertip. (See:
4103 biometric authentication, thumbprint.)
4105 (D) ISDs SHOULD NOT use this term as a synonym for "hash result"
4106 because it mixes concepts in a potentially misleading way.
4108 (D) ISDs SHOULD NOT use this term with the following PGP
4109 definition, because the term and definition mix concepts in a
4110 potentially misleading way and duplicate the meaning of "hash
4113 (O) PGP usage: A hash result used to authenticate a public key
4114 (key fingerprint) or other data. [PGP]
4117 See: Federal Information Processing Standards.
4120 (N) The U.S. Government standard [FP140] for security requirements
4121 to be met by a cryptographic module used to protect unclassified
4122 information in computer and communication systems. (See: Common
4123 Criteria, FIPS, Federal Standard 1027.)
4125 (C) The standard specifies four increasing levels (from "Level 1"
4126 to "Level 4") of requirements to cover a wide range of potential
4127 applications and environments. The requirements address basic
4128 design and documentation, module interfaces, authorized roles and
4129 services, physical security, software security, operating system
4130 security, key management, cryptographic algorithms,
4131 electromagnetic interference and electromagnetic compatibility
4132 (EMI/EMC), and self-testing. NIST and the Canadian Communication
4133 Security Establishment jointly certify modules.
4136 (I) An internetwork gateway that restricts data communication
4137 traffic to and from one of the connected networks (the one said to
4138 be "inside" the firewall) and thus protects that network's system
4139 resources against threats from the other network (the one that is
4140 said to be "outside" the firewall). (See: guard, security
4146 Shirey Informational [Page 74]
4148 RFC 2828 Internet Security Glossary May 2000
4151 (C) A firewall typically protects a smaller, secure network (such
4152 as a corporate LAN, or even just one host) from a larger network
4153 (such as the Internet). The firewall is installed at the point
4154 where the networks connect, and the firewall applies security
4155 policy rules to control traffic that flows in and out of the
4158 (C) A firewall is not always a single computer. For example, a
4159 firewall may consist of a pair of filtering routers and one or
4160 more proxy servers running on one or more bastion hosts, all
4161 connected to a small, dedicated LAN between the two routers. The
4162 external router blocks attacks that use IP to break security (IP
4163 address spoofing, source routing, packet fragments), while proxy
4164 servers block attacks that would exploit a vulnerability in a
4165 higher layer protocol or service. The internal router blocks
4166 traffic from leaving the protected network except through the
4167 proxy servers. The difficult part is defining criteria by which
4168 packets are denied passage through the firewall, because a
4169 firewall not only needs to keep intruders out, but usually also
4170 needs to let authorized users in and out.
4173 (I) Computer programs and data stored in hardware--typically in
4174 read-only memory (ROM) or programmable read-only memory (PROM)--
4175 such that the programs and data cannot be dynamically written or
4176 modified during execution of the programs. (See: hardware,
4180 See: Forum of Incident Response and Security Teams.
4182 $ flaw hypothesis methodology
4183 (I) An evaluation or attack technique in which specifications and
4184 documentation for a system are analyzed to hypothesize flaws in
4185 the system. The list of hypothetical flaws is prioritized on the
4186 basis of the estimated probability that a flaw exists and,
4187 assuming it does, on the ease of exploiting it and the extent of
4188 control or compromise it would provide. The prioritized list is
4189 used to direct a penetration test or attack against the system.
4193 (I) An attack that attempts to cause a failure in (especially, in
4194 the security of) a computer system or other data processing entity
4195 by providing more input than the entity can process properly.
4196 (See: denial of service.)
4202 Shirey Informational [Page 75]
4204 RFC 2828 Internet Security Glossary May 2000
4208 (I) An analysis performed on a nonprocedural formal system
4209 specification that locates potential flows of information between
4210 system variables. By assigning security levels to the variables,
4211 the analysis can find some types of covert channels.
4214 (I) A procedure or technique to ensure that information transfers
4215 within a system are not made from one security level to another
4216 security level, and especially not from a higher level to a lower
4217 level. (See: covert channel, simple security property, confinement
4220 $ formal specification
4221 (I) A specification of hardware or software functionality in a
4222 computer-readable language; usually a precise mathematical
4223 description of the behavior of the system with the aim of
4224 providing a correctness proof.
4227 (I) A technique for enabling a decision to grant or deny access to
4228 be made dynamically at the time the access is attempted, rather
4229 than earlier when an access control list or ticket is created.
4231 $ FORTEZZA(trademark)
4232 (N) A registered trademark of NSA, used for a family of
4233 interoperable security products that implement a NIST/NSA-approved
4234 suite of cryptographic algorithms for digital signature, hash,
4235 encryption, and key exchange. The products include a PC card that
4236 contains a CAPSTONE chip, serial port modems, server boards, smart
4237 cards, and software implementations.
4239 $ Forum of Incident Response and Security Teams (FIRST)
4240 (N) An international consortium of CSIRTs that work together to
4241 handle computer security incidents and promote preventive
4242 activities. (See: CSIRT, security incident.)
4244 (C) FIRST was founded in 1990 and, as of September 1999, had
4245 nearly 70 members spanning the globe. Its mission includes:
4247 - Provide members with technical information, tools, methods,
4248 assistance, and guidance.
4249 - Coordinate proactive liaison activities and analytical support.
4250 - Encourage development of quality products and services.
4251 - Improve national and international information security for
4252 government, private industry, academia, and the individual.
4253 - Enhance the image and status of the CSIRT community.
4258 Shirey Informational [Page 76]
4260 RFC 2828 Internet Security Glossary May 2000
4264 See: public-key forward secrecy.
4267 See: Federal Public-Key Infrastructure.
4270 See: File Transfer Protocol.
4273 (I) A relay mechanism that attaches to two (or more) computer
4274 networks that have similar functions but dissimilar
4275 implementations and that enables host computers on one network to
4276 communicate with hosts on the other; an intermediate system that
4277 is the interface between two computer networks. (See: bridge,
4278 firewall, guard, internetwork, proxy server, router, and
4281 (C) In theory, gateways are conceivable at any OSI layer. In
4282 practice, they operate at OSI layer 3 (see: bridge, router) or
4283 layer 7 (see: proxy server). When the two networks differ in the
4284 protocol by which they offer service to hosts, the gateway may
4285 translate one protocol into another or otherwise facilitate
4286 interoperation of hosts (see: Internet Protocol).
4289 See: geopolitical certificate authority.
4292 (N) The ASN.1 data type "GeneralizedTime" (specified in ISO 8601)
4293 contains a calendar date (YYYYMMDD) and a time of day, which is
4294 either (a) the local time, (b) the Coordinated Universal Time, or
4295 (c) both the local time and an offset allowing Coordinated
4296 Universal Time to be calculated. (See: Coordinated Universal Time,
4299 $ Generic Security Service Application Program Interface (GSS-API)
4300 (I) An Internet Standard protocol [R2078] that specifies calling
4301 conventions by which an application (typically another
4302 communication protocol) can obtain authentication, integrity, and
4303 confidentiality security services independently of the underlying
4304 security mechanisms and technologies, thus allowing the
4305 application source code to be ported to different environments.
4307 (C) "A GSS-API caller accepts tokens provided to it by its local
4308 GSS-API implementation and transfers the tokens to a peer on a
4309 remote system; that peer passes the received tokens to its local
4314 Shirey Informational [Page 77]
4316 RFC 2828 Internet Security Glossary May 2000
4319 GSS-API implementation for processing. The security services
4320 available through GSS-API in this fashion are implementable (and
4321 have been implemented) over a range of underlying mechanisms based
4322 on [symmetric] and [asymmetric cryptography]." [R2078]
4324 $ geopolitical certificate authority (GCA)
4325 (O) SET usage: In a SET certification hierarchy, an optional level
4326 that is certified by a BCA and that may certify cardholder CAs,
4327 merchant CAs, and payment gateway CAs. Using GCAs enables a brand
4328 to distribute responsibility for managing certificates to
4329 geographic or political regions, so that brand policies can vary
4330 between regions as needed.
4333 (D) Except as an explanatory appositive, ISDs SHOULD NOT use this
4334 term as a synonym for "Defense Password Management Guideline"
4335 [CSC2]. Instead, use the full proper name of the document or, in
4336 subsequent references, a conventional abbreviation. (See: Rainbow
4339 (D) Usage note: To improve international comprehensibility of
4340 Internet Standards and the Internet Standards Process, ISDs SHOULD
4341 NOT use "cute" synonyms for document titles. No matter how popular
4342 and clearly understood a nickname may be in one community, it is
4343 likely to cause confusion in others. For example, several other
4344 information system standards also are called "the Green Book". The
4345 following are some examples:
4347 - Each volume of 1992 ITU-T (at that time, CCITT) standards.
4348 - "PostScript Language Program Design", Adobe Systems, Addison-
4350 - IEEE 1003.1 POSIX Operating Systems Interface.
4351 - "Smalltalk-80: Bits of History, Words of Advice", Glenn
4352 Krasner, Addison-Wesley, 1983.
4353 - "X/Open Compatibility Guide".
4354 - A particular CD-ROM format developed by Phillips.
4357 (I) A contraction of "Guidelines and Recommendations for Security
4358 Incident Processing", the name of the IETF working group that
4359 seeks to facilitate consistent handling of security incidents in
4360 the Internet community. (See: security incident.)
4362 (C) Guidelines to be produced by the WG will address technology
4363 vendors, network service providers, and response teams in their
4364 roles assisting organizations in resolving security incidents.
4365 These relationships are functional and can exist within and across
4366 organizational boundaries.
4370 Shirey Informational [Page 78]
4372 RFC 2828 Internet Security Glossary May 2000
4376 See: Generic Security Service Application Program Interface.
4379 (I) A gateway that is interposed between two networks (or
4380 computers, or other information systems) operating at different
4381 security levels (one level is usually higher than the other) and
4382 is trusted to mediate all information transfers between the two
4383 levels, either to ensure that no sensitive information from the
4384 first (higher) level is disclosed to the second (lower) level, or
4385 to protect the integrity of data on the first (higher) level.
4389 See: anonymous login.
4392 (I) Generic Upper Layer Security service element (ISO 11586), a
4393 five-part standard for the exchange of security information and
4394 security-transformation functions that protect confidentiality and
4395 integrity of application data.
4398 (I) Someone with a strong interest in computers, who enjoys
4399 learning about them and experimenting with them. (See: cracker.)
4401 (C) The recommended definition is the original meaning of the term
4402 (circa 1960), which then had a neutral or positive connotation of
4403 "someone who figures things out and makes something cool
4404 happen". Today, the term is frequently misused, especially by
4405 journalists, to have the pejorative meaning of cracker.
4408 (I) (1.) Verb: Perform processing operations on data, such as
4409 receive and transmit, collect and disseminate, create and delete,
4410 store and retrieve, read and write, and compare. (2.) Noun: An on-
4411 line pseudonym, particularly one used by a cracker; derived from
4412 citizens band radio culture.
4415 (I) The material physical components of a computer system. (See:
4416 firmware, software.)
4426 Shirey Informational [Page 79]
4428 RFC 2828 Internet Security Glossary May 2000
4432 (D) ISDs SHOULD NOT use this term (especially not as a synonym for
4433 "hash result") because it mixes concepts in a potentially
4434 misleading way. A hash result is not a "code" in any sense defined
4435 by this glossary. (See: code, hash result, hash value, message
4439 (I) An algorithm that computes a value based on a data object
4440 (such as a message or file; usually variable-length; possibly very
4441 large), thereby mapping the data object to a smaller data object
4442 (the "hash result") which is usually a fixed-size value. (See:
4443 checksum, keyed hash.)
4445 (O) "A (mathematical) function which maps values from a large
4446 (possibly very large) domain into a smaller range. A 'good' hash
4447 function is such that the results of applying the function to a
4448 (large) set of values in the domain will be evenly distributed
4449 (and apparently at random) over the range." [X509]
4451 (C) The kind of hash function needed for security applications is
4452 called a "cryptographic hash function", an algorithm for which it
4453 is computationally infeasible (because no attack is significantly
4454 more efficient than brute force) to find either (a) a data object
4455 that maps to a pre-specified hash result (the "one-way" property)
4456 or (b) two data objects that map to the same hash result (the
4457 "collision-free" property). (See: MD2, MD4, MD5, SHA-1.)
4459 (C) A cryptographic hash is "good" in the sense stated in the "O"
4460 definition for hash function. Any change to an input data object
4461 will, with high probability, result in a different hash result, so
4462 that the result of a cryptographic hash makes a good checksum for
4466 (I) The output of a hash function. (See: hash code, hash value.)
4468 (O) "The output produced by a hash function upon processing a
4469 message" (where "message" is broadly defined as "a digital
4470 representation of data"). [ABA] (The recommended definition is
4471 compatible with this ABA definition, but we avoid the unusual
4472 definition of "message".)
4475 (D) ISDs SHOULD NOT use this term (especially not as a synonym for
4476 "hash result", the output of a hash function) because it might be
4477 confused with "hashed value" (the input to a hash function). (See:
4478 hash code, hash result, message digest.)
4482 Shirey Informational [Page 80]
4484 RFC 2828 Internet Security Glossary May 2000
4488 (I) A PKI architecture based on a certification hierarchy. (See:
4489 mesh PKI, trust-file PKI.)
4491 $ hierarchy management
4492 (I) The process of generating configuration data and issuing
4493 public-key certificates to build and operate a certification
4496 $ hierarchy of trust
4497 (D) ISDs SHOULD NOT use this term with regard to PKI, especially
4498 not as a synonym for "certification hierarchy", because this term
4499 mixes concepts in a potentially misleading way. (See:
4500 certification hierarchy, trust, web of trust.)
4503 (I) A form of active wiretapping in which the attacker seizes
4504 control of a previously established communication association.
4505 (See: man-in-the-middle attack, pagejacking, piggyback attack.)
4508 (I) A keyed hash [R2104] that can be based on any iterated
4509 cryptographic hash (e.g., MD5 or SHA-1), so that the cryptographic
4510 strength of HMAC depends on the properties of the selected
4511 cryptographic hash. (See: [R2202, R2403, R2404].)
4513 (C) Assume that H is a generic cryptographic hash in which a
4514 function is iterated on data blocks of length B bytes. L is the
4515 length of the of hash result of H. K is a secret key of length L
4516 <= K <= B. The values IPAD and OPAD are fixed strings used as
4517 inner and outer padding and defined as follows: IPAD = the byte
4518 0x36 repeated B times, OPAD = the byte 0x5C repeated B times. HMAC
4519 is computed by H(K XOR OPAD, H(K XOR IPAD, inputdata)).
4521 (C) The goals of HMAC are as follows:
4523 - To use available cryptographic hash functions without
4524 modification, particularly functions that perform well in
4525 software and for which software is freely and widely available.
4526 - To preserve the original performance of the selected hash
4527 without significant degradation.
4528 - To use and handle keys in a simple way.
4529 - To have a well-understood cryptographic analysis of the
4530 strength of the mechanism based on reasonable assumptions about
4531 the underlying hash function.
4532 - To enable easy replacement of the hash function in case a
4533 faster or stronger hash is found or required.
4538 Shirey Informational [Page 81]
4540 RFC 2828 Internet Security Glossary May 2000
4544 (I) A system (e.g., a web server) or a system resource (e.g., a
4545 file on a server), that is designed to be attractive to potential
4546 crackers and intruders, like honey is attractive to bears. (See:
4549 (D) It is likely that other cultures have different metaphors for
4550 this concept. To ensure international understanding, ISDs should
4551 not use this term unless they also provide an explanation like
4552 this one. (See: (usage note under) Green Book.)
4555 (I) General computer network usage: A computer that is attached to
4556 a communication subnetwork or internetwork and can use services
4557 provided by the network to exchange data with other attached
4558 systems. (See: end system.)
4560 (I) Specific Internet Protocol Suite usage: A networked computer
4561 that does not forward Internet Protocol packets that are not
4562 addressed to the computer itself. (See: router.)
4564 (C) Derivation: As viewed by its users, a host "entertains"
4565 guests, providing application layer services or access to other
4566 computers attached to the network. However, even though some
4567 traditional peripheral service devices, such as printers, can now
4568 be independently connected to networks, they are not usually
4572 See: Hypertext Markup Language.
4575 See: Hypertext Transfer Protocol.
4578 (I) When used in the first part of a URL (the part that precedes
4579 the colon and specifies an access scheme or protocol), this term
4580 specifies the use of HTTP enhanced by a security mechanism, which
4581 is usually SSL. (See: S-HTTP.)
4584 (I) An application of cryptography that combines two or more
4585 encryption algorithms, particularly a combination of symmetric and
4586 asymmetric encryption. (E.g., see: digital envelope.)
4588 (C) Asymmetric algorithms require more computation than
4589 equivalently strong symmetric ones. Thus, asymmetric encryption is
4590 not normally used for data confidentiality except in distributing
4594 Shirey Informational [Page 82]
4596 RFC 2828 Internet Security Glossary May 2000
4599 symmetric keys in applications where the key data is usually short
4600 (in terms of bits) compared to the data it protects. (E.g., see:
4604 (I) In hypertext or hypermedia, an information object (such as a
4605 word, a phrase, or an image; usually highlighted by color or
4606 underscoring) that points (indicates how to connect) to related
4607 information that is located elsewhere and can be retrieved by
4608 activating the link (e.g., by selecting the object with a mouse
4609 pointer and then clicking).
4612 (I) A generalization of hypertext; any media that contain
4613 hyperlinks that point to material in the same or another data
4617 (I) A computer document, or part of a document, that contains
4618 hyperlinks to other documents; i.e., text that contains active
4619 pointers to other text. Usually written in Hypertext Markup
4620 Language and accessed using a web browser. (See: hypermedia.)
4622 $ Hypertext Markup Language (HTML)
4623 (I) A platform-independent system of syntax and semantics for
4624 adding characters to data files (particularly text files) to
4625 represent the data's structure and to point to related data, thus
4626 creating hypertext for use in the World Wide Web and other
4627 applications. [R1866]
4629 $ Hypertext Transfer Protocol (HTTP)
4630 (I) A TCP-based, application-layer, client-server, Internet
4631 protocol [R2616] used to carry data requests and responses in the
4632 World Wide Web. (See: hypertext.)
4635 See: Internet Architecture Board.
4638 See: Internet Assigned Numbers Authority.
4641 See: Internet Corporation for Assigned Names and Numbers.
4644 See: Internet Control Message Protocol.
4650 Shirey Informational [Page 83]
4652 RFC 2828 Internet Security Glossary May 2000
4656 (I) A denial of service attack that sends a host more ICMP echo
4657 request ("ping") packets than the protocol implementation can
4658 handle. (See: flooding, smurf.)
4661 See: indirect certificate revocation list.
4664 See: International Data Encryption Algorithm.
4667 (I) An act or process that presents an identifier to a system so
4668 that the system can recognize a system entity and distinguish it
4669 from other entities. (See: authentication.)
4671 $ Identification Protocol
4672 (I) An client-server Internet protocol [R1413] for learning the
4673 identity of a user of a particular TCP connection.
4675 (C) Given a TCP port number pair, the server returns a character
4676 string that identifies the owner of that connection on the
4677 server's system. The protocol is not intended for authorization or
4678 access control. At best, it provides additional auditing
4679 information with respect to TCP.
4681 $ identity-based security policy
4682 (I) "A security policy based on the identities and/or attributes
4683 of users, a group of users, or entities acting on behalf of the
4684 users and the resources/objects being accessed." [I7498 Part 2]
4685 (See: rule-based security policy.)
4688 See: Institute of Electrical and Electronics Engineers, Inc.
4691 (N) An IEEE committee developing security standards for local area
4692 networks. (See: SILS.)
4695 (N) An IEEE working group, Standard for Public-Key Cryptography,
4696 developing a comprehensive reference standard for asymmetric
4697 cryptography. Covers discrete logarithm (e.g., DSA), elliptic
4698 curve, and integer factorization (e.g., RSA); and covers key
4699 agreement, digital signature, and encryption.
4702 See: Internet Engineering Steering Group.
4706 Shirey Informational [Page 84]
4708 RFC 2828 Internet Security Glossary May 2000
4712 See: Internet Engineering Task Force.
4715 See: IPsec Key Exchange.
4718 See: Internet Message Access Protocol, version 4.
4720 $ IMAP4 AUTHENTICATE
4721 (I) A IMAP4 "command" (better described as a transaction type, or
4722 a protocol-within-a-protocol) by which an IMAP4 client optionally
4723 proposes a mechanism to an IMAP4 server to authenticate the client
4724 to the server and provide other security services. (See: POP3.)
4726 (C) If the server accepts the proposal, the command is followed by
4727 performing a challenge-response authentication protocol and,
4728 optionally, negotiating a protection mechanism for subsequent POP3
4729 interactions. The security mechanisms that are used by IMAP4
4730 AUTHENTICATE--including Kerberos, GSSAPI, and S/Key--are described
4734 (I) Not encrypted. (See: cleartext.)
4736 $ indirect certificate revocation list (ICRL)
4737 (I) In X.509, a CRL that may contain certificate revocation
4738 notifications for certificates issued by CAs other than the issuer
4741 $ indistinguishability
4742 (I) An attribute of an encryption algorithm that is a
4743 formalization of the notion that the encryption of some string is
4744 indistinguishable from the encryption of an equal-length string of
4747 (C) Under certain conditions, this notion is equivalent to
4748 "semantic security".
4751 (I) Facts and ideas, which can be represented (encoded) as various
4754 $ Information Technology Security Evaluation Criteria (ITSEC)
4755 (N) Standard developed for use in the European Union; accommodates
4756 a wider range of security assurance and functionality combinations
4757 than the TCSEC. Superseded by the Common Criteria. [ITSEC]
4762 Shirey Informational [Page 85]
4764 RFC 2828 Internet Security Glossary May 2000
4768 (I) Abbreviation for "information security", referring to security
4769 measures that implement and assure security services in computer
4770 systems (i.e., COMPUSEC) and communication systems (i.e., COMSEC).
4772 $ initialization value (IV)
4773 (I) An input parameter that sets the starting state of a
4774 cryptographic algorithm or mode. (Sometimes called "initialization
4775 vector" or "message indicator".)
4777 (C) An IV can be used to introduce cryptographic variance in
4778 addition to that provided by a key (see: salt), and to synchronize
4779 one cryptographic process with another. For an example of the
4780 latter, cipher block chaining mode requires an IV. [R2405]
4782 $ initialization vector
4783 (D) For consistency, ISDs SHOULD NOT use this term as a synonym
4784 for "initialization value".
4787 See: (secondary definition under) attack.
4789 $ Institute of Electrical and Electronics Engineers, Inc. (IEEE)
4790 (N) The IEEE is a not-for-profit association of more than 330,000
4791 individual members in 150 countries. The IEEE produces 30 percent
4792 of the world's published literature in electrical engineering,
4793 computers, and control technology; holds annually more than 300
4794 major conferences; and has more than 800 active standards with 700
4795 under development. (See: Standards for Interoperable LAN/MAN
4799 See: data integrity, correctness integrity, source integrity,
4803 (D) ISDs SHOULD NOT use this term as a synonym for "cryptographic
4804 hash" or "protected checksum", because this term unnecessarily
4805 duplicates the meaning of other, well-established terms.
4807 $ intelligent threat
4808 (I) A circumstance in which an adversary has the technical and
4809 operational capability to detect and exploit a vulnerability and
4810 also has the demonstrated, presumed, or inferred intent to do so.
4818 Shirey Informational [Page 86]
4820 RFC 2828 Internet Security Glossary May 2000
4823 $ International Data Encryption Algorithm (IDEA)
4824 (N) A patented, symmetric block cipher that uses a 128-bit key and
4825 operates on 64-bit blocks. [Schn] (See: symmetric cryptography.)
4827 $ International Standard
4828 See: (secondary definition under) ISO.
4830 $ International Traffic in Arms Regulations (ITAR)
4831 (N) Rules issued by the U.S. State Department, by authority of the
4832 Arms Export Control Act (22 U.S.C. 2778), to control export and
4833 import of defense articles and defense services, including
4834 information security systems, such as cryptographic systems, and
4835 TEMPEST suppression technology. (See: Wassenaar Arrangement.)
4839 See: internet vs. Internet.
4841 $ Internet Architecture Board (IAB)
4842 (I) A technical advisory group of the ISOC, chartered by the ISOC
4843 Trustees to provide oversight of Internet architecture and
4844 protocols and, in the context of Internet Standards, a body to
4845 which decisions of the IESG may be appealed. Responsible for
4846 approving appointments to the IESG from among nominees submitted
4847 by the IETF nominating committee. [R2026]
4849 $ Internet Assigned Numbers Authority (IANA)
4850 (I) From the early days of the Internet, the IANA was chartered by
4851 the ISOC and the U.S. Government's Federal Network Council to be
4852 the central coordination, allocation, and registration body for
4853 parameters for Internet protocols. Superseded by ICANN.
4855 $ Internet Control Message Protocol (ICMP)
4856 (I) An Internet Standard protocol [R0792] that is used to report
4857 error conditions during IP datagram processing and to exchange
4858 other information concerning the state of the IP network.
4860 $ Internet Corporation for Assigned Names and Numbers (ICANN)
4861 (I) The non-profit, private corporation that has assumed
4862 responsibility for the IP address space allocation, protocol
4863 parameter assignment, domain name system management, and root
4864 server system management functions formerly performed under U.S.
4865 Government contract by IANA and other entities.
4867 (C) The Internet Protocol Suite, as defined by the IETF and the
4868 IESG, contains numerous parameters, such as internet addresses,
4869 domain names, autonomous system numbers, protocol numbers, port
4870 numbers, management information base object identifiers, including
4874 Shirey Informational [Page 87]
4876 RFC 2828 Internet Security Glossary May 2000
4879 private enterprise numbers, and many others. The Internet
4880 community requires that the values used in these parameter fields
4881 be assigned uniquely. ICANN makes those assignments as requested
4882 and maintains a registry of the current values.
4884 (C) ICANN was formed in October 1998, by a coalition of the
4885 Internet's business, technical, and academic communities. The U.S.
4886 Government designated ICANN to serve as the global consensus
4887 entity with responsibility for coordinating four key functions for
4888 the Internet: the allocation of IP address space, the assignment
4889 of protocol parameters, the management of the DNS, and the
4890 management of the DNS root server system.
4893 (I) A working document of the IETF, its areas, and its working
4894 groups. (Other groups may also distribute working documents as
4895 Internet Drafts.) An Internet Draft is not an archival document
4896 like an RFC is. Instead, an Internet Draft is a preliminary or
4897 working document that is valid for a maximum of six months and may
4898 be updated, replaced, or made obsolete by other documents at any
4899 time. It is inappropriate to use an Internet Draft as reference
4900 material or to cite it other than as "work in progress."
4902 $ Internet Engineering Steering Group (IESG)
4903 (I) The part of the ISOC responsible for technical management of
4904 IETF activities and administration of the Internet Standards
4905 Process according to procedures approved by the ISOC Trustees.
4906 Directly responsible for actions along the "standards track",
4907 including final approval of specifications as Internet Standards.
4908 Composed of IETF Area Directors and the IETF chairperson, who also
4909 chairs the IESG. [R2026]
4911 $ Internet Engineering Task Force (IETF)
4912 (I) A self-organized group of people who make contributions to the
4913 development of Internet technology. The principal body engaged in
4914 developing Internet Standards, although not itself a part of the
4915 ISOC. Composed of Working Groups, which are arranged into Areas
4916 (such as the Security Area), each coordinated by one or more Area
4917 Directors. Nominations to the IAB and the IESG are made by a
4918 committee selected at random from regular IETF meeting attendees
4919 who have volunteered. [R2026, R2323]
4921 $ Internet Message Access Protocol, version 4 (IMAP4)
4922 (I) An Internet protocol [R2060] by which a client workstation can
4923 dynamically access a mailbox on a server host to manipulate and
4924 retrieve mail messages that the server has received and is holding
4925 for the client. (See: POP3.)
4930 Shirey Informational [Page 88]
4932 RFC 2828 Internet Security Glossary May 2000
4935 (C) IMAP4 has mechanisms for optionally authenticating a client to
4936 a server and providing other security services. (See: IMAP4
4939 $ Internet Policy Registration Authority (IPRA)
4940 (I) An X.509-compliant CA that is the top CA of the Internet
4941 certification hierarchy operated under the auspices of the ISOC
4942 [R1422]. (See: (PEM usage under) certification hierarchy.)
4944 $ Internet Protocol (IP)
4945 (I) A Internet Standard protocol (version 4 [R0791] and version 6
4946 [R2460]) that moves datagrams (discrete sets of bits) from one
4947 computer to another across an internetwork but does not provide
4948 reliable delivery, flow control, sequencing, or other end-to-end
4949 services that TCP provides. (See: IP address, TCP/IP.)
4951 (C) In the OSIRM, IP would be located at the top of layer 3.
4953 $ Internet Protocol security (IPsec)
4954 (I) (1.) The name of the IETF working group that is specifying a
4955 security architecture [R2401] and protocols to provide security
4956 services for Internet Protocol traffic. (2.) A collective name for
4957 that architecture and set of protocols. (Implementation of IPsec
4958 protocols is optional for IP version 4, but mandatory for IP
4959 version 6.) (See: Internet Protocol Security Option.)
4961 (C) Note that the letters "sec" are lower-case.
4963 (C) The IPsec architecture specifies (a) security protocols (AH
4964 and ESP), (b) security associations (what they are, how they work,
4965 how they are managed, and associated processing), (c) key
4966 management (IKE), and (d) algorithms for authentication and
4967 encryption. The set of security services include access control
4968 service, connectionless data integrity service, data origin
4969 authentication service, protection against replays (detection of
4970 the arrival of duplicate datagrams, within a constrained window),
4971 data confidentiality service, and limited traffic flow
4974 $ Internet Protocol Security Option (IPSO)
4975 (I) Refers to one of three types of IP security options, which are
4976 fields that may be added to an IP datagram for the purpose of
4977 carrying security information about the datagram. (See: IPsec.)
4979 (D) ISDs SHOULD NOT use this term without a modifier to indicate
4980 which of the three types is meant.
4986 Shirey Informational [Page 89]
4988 RFC 2828 Internet Security Glossary May 2000
4991 1. "DoD Basic Security Option" (IP option type 130): Defined for
4992 use on U.S. Department of Defense common user data networks.
4993 Identifies the Defense classification level at which the
4994 datagram is to be protected and the protection authorities
4995 whose rules apply to the datagram. [R1108]
4997 A "protection authority" is a National Access Program (e.g.,
4998 GENSER, SIOP-ESI, SCI, NSA, Department of Energy) or Special
4999 Access Program that specifies protection rules for transmission
5000 and processing of the information contained in the datagram.
5003 2. "DoD Extended Security Option" (IP option type 133): Permits
5004 additional security labeling information, beyond that present
5005 in the Basic Security Option, to be supplied in the datagram to
5006 meet the needs of registered authorities. [R1108]
5008 3. "Common IP Security Option" (CIPSO) (IP option type 134):
5009 Designed by TSIG to carry hierarchic and non-hierarchic
5010 security labels. (Formerly called "Commercial IP Security
5011 Option".) Was published as Internet-Draft [CIPSO]; not advanced
5014 $ Internet Protocol Suite
5015 See: (secondary definition under) Internet.
5017 $ Internet Security Association and Key Management Protocol (ISAKMP)
5018 (I) An Internet IPsec protocol [R2408] to negotiate, establish,
5019 modify, and delete security associations, and to exchange key
5020 generation and authentication data, independent of the details of
5021 any specific key generation technique, key establishment protocol,
5022 encryption algorithm, or authentication mechanism.
5024 (C) ISAKMP supports negotiation of security associations for
5025 protocols at all TCP/IP layers. By centralizing management of
5026 security associations, ISAKMP reduces duplicated functionality
5027 within each protocol. ISAKMP can also reduce connection setup
5028 time, by negotiating a whole stack of services at once. Strong
5029 authentication is required on ISAKMP exchanges, and a digital
5030 signature algorithm based on asymmetric cryptography is used
5031 within ISAKMP's authentication component.
5033 $ Internet Society (ISOC)
5034 (I) A professional society concerned with Internet development
5035 (including technical Internet Standards); with how the Internet is
5036 and can be used; and with social, political, and technical issues
5042 Shirey Informational [Page 90]
5044 RFC 2828 Internet Security Glossary May 2000
5047 that result. The ISOC Board of Trustees approves appointments to
5048 the IAB from among nominees submitted by the IETF nominating
5052 (I) A specification, approved by the IESG and published as an RFC,
5053 that is stable and well-understood, is technically competent, has
5054 multiple, independent, and interoperable implementations with
5055 substantial operational experience, enjoys significant public
5056 support, and is recognizably useful in some or all parts of the
5057 Internet. [R2026] (See: RFC.)
5059 (C) The Internet Standards Process is an activity of the ISOC and
5060 is organized and managed by the IAB and the IESG. The process is
5061 concerned with all protocols, procedures, and conventions used in
5062 or by the Internet, whether or not they are part of the Internet
5063 Protocol Suite. The "Internet Standards Track" has three levels of
5064 increasing maturity: Proposed Standard, Draft Standard, and
5065 Standard. (See: (standards levels under) ISO.)
5067 $ Internet Standards document (ISD)
5068 (C) In this Glossary, this term refers to an RFC, Internet-Draft,
5069 or other item that is produced as part of the Internet Standards
5070 Process [R2026]. However, neither the term nor the abbreviation is
5071 widely accepted and, therefore, SHOULD NOT be used in an ISD
5072 unless it is accompanied by an explanation like this. (See:
5075 $ internet vs. Internet
5076 1. (I) Not capitalized: A popular abbreviation for "internetwork".
5078 2. (I) Capitalized: "The Internet" is the single, interconnected,
5079 worldwide system of commercial, government, educational, and other
5080 computer networks that share the set of protocols specified by the
5081 IAB [R2026] and the name and address spaces managed by the ICANN.
5083 (C) The protocol set is named the "Internet Protocol Suite". It
5084 also is popularly known as "TCP/IP", because TCP and IP are two of
5085 its fundamental components. These protocols enable a user of any
5086 one of the networks in the Internet to communicate with, or use
5087 services located on, any of the other networks.
5089 (C) Although the Internet does have architectural principles
5090 [R1958], no Internet Standard formally defines a layered reference
5091 model for the IPS that is similar to the OSIRM. However, Internet
5092 community documents do refer (inconsistently) to layers:
5093 application, socket, transport, internetwork, network, data link,
5098 Shirey Informational [Page 91]
5100 RFC 2828 Internet Security Glossary May 2000
5103 and physical. In this Glossary, Internet layers are referred to by
5104 name to avoid confusing them with OSIRM layers, which are referred
5108 (I) A system of interconnected networks; a network of networks.
5109 Usually shortened to "internet". (See: internet vs. Internet.)
5111 (C) An internet is usually built using OSI layer 3 gateways to
5112 connect a set of subnetworks. When the subnetworks differ in the
5113 OSI layer 3 protocol service they provide, the gateways sometimes
5114 implement a uniform internetwork protocol (e.g., IP) that operates
5115 at the top of layer 3 and hides the underlying heterogeneity from
5116 hosts that use communication services provided by the internet.
5120 (I) A computer network, especially one based on Internet
5121 technology, that an organization uses for its own internal, and
5122 usually private, purposes and that is closed to outsiders. (See:
5123 extranet, virtual private network.)
5126 (I) An entity that gains or attempts to gain access to a system or
5127 system resource without having authorization to do so. (See:
5131 See: security intrusion.
5133 $ intrusion detection
5134 (I) A security service that monitors and analyzes system events
5135 for the purpose of finding, and providing real-time or near real-
5136 time warning of, attempts to access system resources in an
5137 unauthorized manner.
5140 (N) An X.509 CRL entry extension that "indicates the date at which
5141 it is known or suspected that the [revoked certificate's private
5142 key] was compromised or that the certificate should otherwise be
5143 considered invalid" [X509].
5145 (C) This date may be earlier than the revocation date in the CRL
5146 entry, and may even be earlier than the date of issue of earlier
5147 CRLs. However, the invalidity date is not, by itself, sufficient
5148 for purposes of non-repudiation service. For example, to
5154 Shirey Informational [Page 92]
5156 RFC 2828 Internet Security Glossary May 2000
5159 fraudulently repudiate a validly-generated signature, a private
5160 key holder may falsely claim that the key was compromised at some
5164 See: Internet Protocol.
5167 (I) A computer's internetwork address that is assigned for use by
5168 the Internet Protocol and other protocols.
5170 (C) An IP version 4 [R0791] address is written as a series of four
5171 8-bit numbers separated by periods. For example, the address of
5172 the host named "rosslyn.bbn.com" is 192.1.7.10.
5174 (C) An IP version 6 [R2373] address is written as x:x:x:x:x:x:x:x,
5175 where each "x" is the hexadecimal value of one of the eight 16-bit
5176 parts of the address. For example, 1080:0:0:0:8:800:200C:417A and
5177 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210.
5179 $ IP Security Option
5180 See: Internet Protocol Security Option.
5183 See: Internet Policy Registration Authority.
5186 See: Internet Protocol security.
5188 $ IPsec Key Exchange (IKE)
5189 (I) An Internet, IPsec, key-establishment protocol [R2409] (partly
5190 based on OAKLEY) that is intended for putting in place
5191 authenticated keying material for use with ISAKMP and for other
5192 security associations, such as in AH and ESP.
5195 See: Internet Protocol Security Option.
5198 See: Internet Security Association and Key Management Protocol.
5201 See: Internet Standards document.
5204 (I) International Organization for Standardization, a voluntary,
5205 non-treaty, non-government organization, established in 1947, with
5206 voting members that are designated standards bodies of
5210 Shirey Informational [Page 93]
5212 RFC 2828 Internet Security Glossary May 2000
5215 participating nations and non-voting observer organizations. (See:
5218 (C) Legally, ISO is a Swiss, non-profit, private organization. ISO
5219 and the IEC (the International Electrotechnical Commission) form
5220 the specialized system for worldwide standardization. National
5221 bodies that are members of ISO or IEC participate in developing
5222 international standards through ISO and IEC technical committees
5223 that deal with particular fields of activity. Other international
5224 governmental and non-governmental organizations, in liaison with
5225 ISO and IEC, also take part. (ANSI is the U.S. voting member of
5226 ISO. ISO is a class D member of ITU-T.)
5228 (C) The ISO standards development process has four levels of
5229 increasing maturity: Working Draft (WD), Committee Draft (CD),
5230 Draft International Standard (DIS), and International Standard
5231 (IS). (See: (standards track levels under) Internet Standard.) In
5232 information technology, ISO and IEC have a joint technical
5233 committee, ISO/IEC JTC 1. DISs adopted by JTC 1 are circulated to
5234 national bodies for voting, and publication as an IS requires
5235 approval by at least 75% of the national bodies casting a vote.
5238 See: Internet Society.
5240 $ issue (a digital certificate or CRL)
5241 (I) Generate and sign a digital certificate (or CRL) and, usually,
5242 distribute it and make it available to potential certificate users
5243 (or CRL users). (See: certificate creation.)
5245 (C) The ABA Guidelines [ABA] explicitly limit this term to
5246 certificate creation, and exclude the act of publishing. In
5247 general usage, however, "issuing" a digital certificate (or CRL)
5248 includes not only certificate creation but also making it
5249 available to potential users, such as by storing it in a
5250 repository or other directory or otherwise publishing it.
5253 1. (I) "Issuer" of a certificate or CRL: The CA that signs the
5254 digital certificate or CRL.
5256 (C) An X.509 certificate always includes the issuer's name. The
5257 name may include a common name value.
5259 2. (N) "Issuer" of a payment card: SET usage: "The financial
5260 institution or its agent that issues the unique primary account
5261 number to the cardholder for the payment card brand." [SET2]
5266 Shirey Informational [Page 94]
5268 RFC 2828 Internet Security Glossary May 2000
5271 (C) The institution that establishes the account for a cardholder
5272 and issues the payment card also guarantees payment for authorized
5273 transactions that use the card in accordance with card brand
5274 regulations and local legislation. [SET1]
5277 See: International Traffic in Arms Regulations.
5280 See: Information Technology System Evaluation Criteria.
5283 (N) International Telecommunications Union, Telecommunication
5284 Standardization Sector (formerly "CCITT"), a United Nations treaty
5285 organization that is composed mainly of postal, telephone, and
5286 telegraph authorities of the member countries and that publishes
5287 standards called "Recommendations". (See: X.400, X.500.)
5289 (C) The Department of State represents the United States. ITU-T
5290 works on many kinds of communication systems. ITU-T cooperates
5291 with ISO on communication protocol standards, and many
5292 Recommendations in that area are also published as an ISO standard
5293 with an ISO name and number.
5296 See: initialization value.
5299 See: Key Distribution Center.
5302 See: Key Exchange Algorithm.
5305 See: key-encrypting key.
5308 (N) A system developed at the Massachusetts Institute of
5309 Technology that depends on passwords and symmetric cryptography
5310 (DES) to implement ticket-based, peer entity authentication
5311 service and access control service distributed in a client-server
5312 network environment. [R1510, Stei]
5314 (C) Kerberos was developed by Project Athena and is named for the
5315 three-headed dog guarding Hades.
5318 See: cryptographic key.
5322 Shirey Informational [Page 95]
5324 RFC 2828 Internet Security Glossary May 2000
5327 $ key agreement (algorithm or protocol)
5328 (I) A key establishment method (especially one involving
5329 asymmetric cryptography) by which two or more entities, without
5330 prior arrangement except a public exchange of data (such as public
5331 keys), each computes the same key value. I.e., each can
5332 independently generate the same key value, but that key cannot be
5333 computed by other entities. (See: Diffie-Hellman, key
5334 establishment, Key Exchange Algorithm, key transport.)
5336 (O) "A method for negotiating a key value on line without
5337 transferring the key, even in an encrypted form, e.g., the Diffie-
5338 Hellman technique." [X509]
5340 (O) "The procedure whereby two different parties generate shared
5341 symmetric keys such that any of the shared symmetric keys is a
5342 function of the information contributed by all legitimate
5343 participants, so that no party [alone] can predetermine the value
5344 of the key." [A9042]
5346 (C) For example, a message originator and the intended recipient
5347 can each use their own private key and the other's public key with
5348 the Diffie-Hellman algorithm to first compute a shared secret
5349 value and, from that value, derive a session key to encrypt the
5352 $ key authentication
5353 (N) "The assurance of the legitimate participants in a key
5354 agreement that no non-legitimate party possesses the shared
5355 symmetric key." [A9042]
5358 (I) A centralized key distribution process (used in symmetric
5359 cryptography), usually a separate computer system, that uses key-
5360 encrypting keys (master keys) to encrypt and distribute session
5361 keys needed in a community of users.
5363 (C) An ANSI standard [A9017] defines two types of key center: key
5364 distribution center and key translation center.
5367 (N) "The assurance of the legitimate participants in a key
5368 establishment protocol that the intended parties sharing the
5369 symmetric key actually possess the shared symmetric key." [A9042]
5372 (I) A process that delivers a cryptographic key from the location
5373 where it is generated to the locations where it is used in a
5374 cryptographic algorithm. (See: key management.)
5378 Shirey Informational [Page 96]
5380 RFC 2828 Internet Security Glossary May 2000
5383 $ key distribution center (KDC)
5384 (I) A type of key center (used in symmetric cryptography) that
5385 implements a key distribution protocol to provide keys (usually,
5386 session keys) to two (or more) entities that wish to communicate
5387 securely. (See: key translation center.)
5389 (C) A KDC distributes keys to Alice and Bob, who (a) wish to
5390 communicate with each other but do not currently share keys, (b)
5391 each share a KEK with the KDC, and (c) may not be able to generate
5392 or acquire keys by themselves. Alice requests the keys from the
5393 KDC. The KDC generates or acquires the keys and makes two
5394 identical sets. The KDC encrypts one set in the KEK it shares with
5395 Alice, and sends that encrypted set to Alice. The KDC encrypts the
5396 second set in the KEK it shares with Bob, and either sends that
5397 encrypted set to Alice for her to forward to Bob, or sends it
5398 directly to Bob (although the latter option is not supported in
5399 the ANSI standard [A9017]).
5402 See: (secondary definition under) key recovery.
5404 $ key-encrypting key (KEK)
5405 (I) A cryptographic key that is used to encrypt other keys, either
5406 DEKs or other KEKs, but usually is not used to encrypt application
5410 See: (secondary definition under) key recovery.
5412 $ key establishment (algorithm or protocol)
5413 (I) A process that combines the key generation and key
5414 distribution steps needed to set up or install a secure
5415 communication association. (See: key agreement, key transport.)
5417 (O) "The procedure to share a symmetric key among different
5418 parties by either key agreement or key transport." [A9042]
5420 (C) Key establishment involves either key agreement or key
5423 - Key transport: One entity generates a secret key and securely
5424 sends it to the other entity. (Or each entity generates a
5425 secret value and securely sends it to the other entity, where
5426 the two values are combined to form a secret key.)
5428 - Key agreement: No secret is sent from one entity to another.
5429 Instead, both entities, without prior arrangement except a
5430 public exchange of data, compute the same secret value. I.e.,
5434 Shirey Informational [Page 97]
5436 RFC 2828 Internet Security Glossary May 2000
5439 each can independently generate the same value, but that value
5440 cannot be computed by other entities.
5442 $ Key Exchange Algorithm (KEA)
5443 (N) A key agreement algorithm [NIST] that is similar to the
5444 Diffie-Hellman algorithm, uses 1024-bit asymmetric keys, and was
5445 developed and formerly classified at the "Secret" level by NSA.
5446 (See: CAPSTONE, CLIPPER, FORTEZZA, SKIPJACK.)
5448 (C) On 23 June 1998, the NSA announced that KEA had been
5452 (I) A process that creates the sequence of symbols that comprise a
5453 cryptographic key. (See: key management.)
5456 1. (I) An algorithm that uses mathematical rules to
5457 deterministically produce a pseudo-random sequence of
5458 cryptographic key values.
5460 2. (I) An encryption device that incorporates a key generation
5461 mechanism and applies the key to plaintext (e.g., by exclusive OR-
5462 ing the key bit string with the plaintext bit string) to produce
5466 (I) The number of symbols (usually bits) needed to be able to
5467 represent any of the possible values of a cryptographic key. (See:
5471 (N) MISSI usage: An attribute of a MISSI key pair that specifies a
5472 time span that bounds the validity period of any MISSI X.509
5473 public-key certificate that contains the public component of the
5474 pair. (See: cryptoperiod.)
5477 (I) The process of handling and controlling cryptographic keys and
5478 related material (such as initialization values) during their life
5479 cycle in a cryptographic system, including ordering, generating,
5480 distributing, storing, loading, escrowing, archiving, auditing,
5481 and destroying the material. (See: key distribution, key escrow,
5482 keying material, public-key infrastructure.)
5484 (O) "The generation, storage, distribution, deletion, archiving
5485 and application of keys in accordance with a security policy."
5490 Shirey Informational [Page 98]
5492 RFC 2828 Internet Security Glossary May 2000
5495 (O) "The activities involving the handling of cryptographic keys
5496 and other related security parameters (e.g., IVs, counters) during
5497 the entire life cycle of the keys, including their generation,
5498 storage, distribution, entry and use, deletion or destruction, and
5501 $ Key Management Protocol (KMP)
5502 (N) A protocol to establish a shared symmetric key between a pair
5503 (or a group) of users. (One version of KMP was developed by SDNS,
5504 and another by SILS.)
5506 $ key material identifier (KMID)
5507 (N) MISSI usage: A 64-bit identifier that is assigned to a key
5508 pair when the public key is bound in a MISSI X.509 public-key
5512 (I) A set of mathematically related keys--a public key and a
5513 private key--that are used for asymmetric cryptography and are
5514 generated in a way that makes it computationally infeasible to
5515 derive the private key from knowledge of the public key (e.g.,
5516 see: Diffie-Hellman, Rivest-Shamir-Adleman).
5518 (C) A key pair's owner discloses the public key to other system
5519 entities so they can use the key to encrypt data, verify a digital
5520 signature, compute a protected checksum, or generate a key in a
5521 key agreement algorithm. The matching private key is kept secret
5522 by the owner, who uses it to decrypt data, generate a digital
5523 signature, verify a protected checksum, or generate a key in a key
5524 agreement algorithm.
5527 1. (I) A process for learning the value of a cryptographic key
5528 that was previously used to perform some cryptographic operation.
5529 (See: cryptanalysis.)
5531 2. (I) Techniques that provide an intentional, alternate (i.e.,
5532 secondary) means to access the key used for data confidentiality
5533 service in an encrypted association. [DOD4]
5535 (C) We assume that the encryption mechanism has a primary means of
5536 obtaining the key through a key establishment algorithm or
5537 protocol. For the secondary means, there are two classes of key
5538 recovery techniques--key escrow and key encapsulation:
5546 Shirey Informational [Page 99]
5548 RFC 2828 Internet Security Glossary May 2000
5551 - "Key escrow": A key recovery technique for storing knowledge of
5552 a cryptographic key or parts thereof in the custody of one or
5553 more third parties called "escrow agents", so that the key can
5554 be recovered and used in specified circumstances.
5556 Key escrow is typically implemented with split knowledge
5557 techniques. For example, the Escrowed Encryption Standard
5558 [FP185] entrusts two components of a device-unique split key to
5559 separate escrow agents. The agents provide the components only
5560 to someone legally authorized to conduct electronic
5561 surveillance of telecommunications encrypted by that specific
5562 device. The components are used to reconstruct the device-
5563 unique key, and it is used to obtain the session key needed to
5564 decrypt communications.
5566 - "Key encapsulation": A key recovery technique for storing
5567 knowledge of a cryptographic key by encrypting it with another
5568 key and ensuring that that only certain third parties called
5569 "recovery agents" can perform the decryption operation to
5570 retrieve the stored key.
5572 Key encapsulation typically allows direct retrieval of the
5573 secret key used to provide data confidentiality.
5576 (I) The range of possible values of a cryptographic key; or the
5577 number of distinct transformations supported by a particular
5578 cryptographic algorithm. (See: key length.)
5580 $ key translation center
5581 (I) A type of key center (used in a symmetric cryptography) that
5582 implements a key distribution protocol to convey keys between two
5583 (or more) parties who wish to communicate securely. (See: key
5584 distribution center.)
5586 (C) A key translation center translates keys for future
5587 communication between Bob and Alice, who (a) wish to communicate
5588 with each other but do not currently share keys, (b) each share a
5589 KEK with the center, and (c) have the ability to generate or
5590 acquire keys by themselves. Alice generates or acquires a set of
5591 keys for communication with Bob. Alice encrypts the set in the KEK
5592 she shares with the center and sends the encrypted set to the
5593 center. The center decrypts the set, reencrypts the set in the KEK
5594 it shares with Bob, and either sends that encrypted set to Alice
5595 for her to forward to Bob, or sends it directly to Bob (although
5596 direct distribution is not supported in the ANSI standard
5602 Shirey Informational [Page 100]
5604 RFC 2828 Internet Security Glossary May 2000
5607 $ key transport (algorithm or protocol)
5608 (I) A key establishment method by which a secret key is generated
5609 by one entity in a communication association and securely sent to
5610 another entity in the association. (See: key agreement.)
5612 (O) "The procedure to send a symmetric key from one party to other
5613 parties. As a result, all legitimate participants share a common
5614 symmetric key in such a way that the symmetric key is determined
5615 entirely by one party." [A9042]
5617 (C) For example, a message originator can generate a random
5618 session key and then use the Rivest-Shamir-Adleman algorithm to
5619 encrypt that key with the public key of the intended recipient.
5622 (I) Derive a new key from an existing key. (See: certificate
5626 (N) "The procedure for the receiver of a public key to check that
5627 the key conforms to the arithmetic requirements for such a key in
5628 order to thwart certain types of attacks." [A9042]
5631 (I) A cryptographic hash (e.g., [R1828]) in which the mapping to a
5632 hash result is varied by a second input parameter that is a
5633 cryptographic key. (See: checksum.)
5635 (C) If the input data object is changed, a new hash result cannot
5636 be correctly computed without knowledge of the secret key. Thus,
5637 the secret key protects the hash result so it can be used as a
5638 checksum even when there is a threat of an active attack on the
5639 data. There are least two forms of keyed hash:
5641 - A function based on a keyed encryption algorithm. (E.g., see:
5642 Data Authentication Code.)
5644 - A function based on a keyless hash that is enhanced by
5645 combining (e.g., by concatenating) the input data object
5646 parameter with a key parameter before mapping to the hash
5647 result. (E.g., see: HMAC.)
5650 (I) Data (such as keys, key pairs, and initialization values)
5651 needed to establish and maintain a cryptographic security
5658 Shirey Informational [Page 101]
5660 RFC 2828 Internet Security Glossary May 2000
5664 See: key material identifier.
5666 $ known-plaintext attack
5667 (I) A cryptanalysis technique in which the analyst tries to
5668 determine the key from knowledge of some plaintext-ciphertext
5669 pairs (although the analyst may also have other clues, such as the
5670 knowing the cryptographic algorithm).
5673 See: Layer 2 Forwarding Protocol.
5676 See: Layer 2 Tunneling Protocol.
5679 See: security label.
5681 $ Language of Temporal Ordering Specification (LOTOS)
5682 (N) A language (ISO 8807-1990) for formal specification of
5683 computer network protocols; describes the order in which events
5687 (I) A security model for flow control in a system, based on the
5688 lattice that is formed by the finite security levels in a system
5689 and their partial ordering. [Denn] (See: flow control, security
5690 level, security model.)
5692 (C) The model describes the semantic structure formed by a finite
5693 set of security levels, such as those used in military
5696 (C) A lattice is a finite set together with a partial ordering on
5697 its elements such that for every pair of elements there is a least
5698 upper bound and a greatest lower bound. For example, a lattice is
5699 formed by a finite set S of security levels -- i.e., a set S of all
5700 ordered pairs (x, c), where x is one of a finite set X of
5701 hierarchically ordered classification levels (X1, ..., Xm), and c
5702 is a (possibly empty) subset of a finite set C of non-hierarchical
5703 categories (C1, ..., Cn) -- together with the "dominate" relation.
5706 $ Law Enforcement Access Field (LEAF)
5707 (N) A data item that is automatically embedded in data encrypted
5708 by devices (e.g., see: CLIPPER chip) that implement the Escrowed
5709 Encryption Standard.
5714 Shirey Informational [Page 102]
5716 RFC 2828 Internet Security Glossary May 2000
5719 $ Layer 2 Forwarding Protocol (L2F)
5720 (N) An Internet protocol (originally developed by Cisco
5721 Corporation) that uses tunneling of PPP over IP to create a
5722 virtual extension of a dial-up link across a network, initiated by
5723 the dial-up server and transparent to the dial-up user. (See:
5726 $ Layer 2 Tunneling Protocol (L2TP)
5727 (N) An Internet client-server protocol that combines aspects of
5728 PPTP and L2F and supports tunneling of PPP over an IP network or
5729 over frame relay or other switched network. (See: virtual private
5732 (C) PPP can in turn encapsulate any OSI layer 3 protocol. Thus,
5733 L2TP does not specify security services; it depends on protocols
5734 layered above and below it to provide any needed security.
5737 See: Lightweight Directory Access Protocol.
5740 (I) The principle that a security architecture should be designed
5741 so that each system entity is granted the minimum system resources
5742 and authorizations that the entity needs to do its work. (See:
5743 economy of mechanism.)
5745 (C) This principle tends to limit damage that can be caused by an
5746 accident, error, or unauthorized act.
5748 $ Lightweight Directory Access Protocol (LDAP)
5749 (N) A client-server protocol that supports basic use of the X.500
5750 Directory (or other directory servers) without incurring the
5751 resource requirements of the full Directory Access Protocol (DAP).
5754 (C) Designed for simple management and browser applications that
5755 provide simple read/write interactive directory service. Supports
5756 both simple authentication and strong authentication of the client
5757 to the directory server.
5760 (I) World Wide Web usage: See: hyperlink.
5762 (I) Subnetwork usage: A point-to-point communication channel
5763 connecting two subnetwork relays (especially one between two
5764 packet switches) that is implemented at OSI layer 2. (See: link
5770 Shirey Informational [Page 103]
5772 RFC 2828 Internet Security Glossary May 2000
5775 (C) The relay computers assume that links are logically passive.
5776 If a computer at one end of a link sends a sequence of bits, the
5777 sequence simply arrives at the other end after a finite time,
5778 although some bits may have been changed either accidentally
5779 (errors) or by active wiretapping.
5781 $ link-by-link encryption
5783 (I) Stepwise protection of data that flows between two points in a
5784 network, provided by encrypting data separately on each network
5785 link, i.e., by encrypting data when it leaves a host or subnetwork
5786 relay and decrypting when it arrives at the next host or relay.
5787 Each link may use a different key or even a different algorithm.
5788 [R1455] (See: end-to-end encryption.)
5791 (I) Malicious logic that activates when specified conditions are
5792 met. Usually intended to cause denial of service or otherwise
5793 damage system resources. (See: Trojan horse, virus, worm.)
5796 (I) The act of a system entity gaining access to a session in
5797 which the entity can use system resources; usually accomplished by
5798 providing a user name and password to an access control system
5799 that authenticates the user.
5801 (C) Derives from "log" file", a security audit trail that records
5802 security events, such as the beginning of sessions, and who
5806 See: Language of Temporal Ordering Specification.
5809 See: mandatory access control, Message Authentication Code.
5812 (I) Hardware, software, or firmware that is intentionally included
5813 or inserted in a system for a harmful purpose. (See: logic bomb,
5814 Trojan horse, virus, worm.)
5817 (I) A contraction of "malicious software". (See: malicious logic.)
5819 (D) ISDs SHOULD NOT use this term because it is not listed in most
5820 dictionaries and could confuse international readers.
5826 Shirey Informational [Page 104]
5828 RFC 2828 Internet Security Glossary May 2000
5832 (I) A form of active wiretapping attack in which the attacker
5833 intercepts and selectively modifies communicated data in order to
5834 masquerade as one or more of the entities involved in a
5835 communication association. (See: hijack attack, piggyback attack.)
5837 (C) For example, suppose Alice and Bob try to establish a session
5838 key by using the Diffie-Hellman algorithm without data origin
5839 authentication service. A "man in the middle" could (a) block
5840 direct communication between Alice and Bob and then (b) masquerade
5841 as Alice sending data to Bob, (c) masquerade as Bob sending data
5842 to Alice, (d) establish separate session keys with each of them,
5843 and (e) function as a clandestine proxy server between them in
5844 order to capture or modify sensitive information that Alice and
5845 Bob think they are sending only to each other.
5847 $ mandatory access control (MAC)
5848 (I) An access control service that enforces a security policy
5849 based on comparing (a) security labels (which indicate how
5850 sensitive or critical system resources are) with (b) security
5851 clearances (which indicate system entities are eligible to access
5852 certain resources). (See: discretionary access control, rule-based
5855 (C) This kind of access control is called "mandatory" because an
5856 entity that has clearance to access a resource may not, just by
5857 its own volition, enable another entity to access that resource.
5859 (O) "A means of restricting access to objects based on the
5860 sensitivity (as represented by a label) of the information
5861 contained in the objects and the formal authorization (i.e.,
5862 clearance) of subjects to access information of such sensitivity."
5865 $ manipulation detection code
5866 (D) ISDs SHOULD NOT use this term as a synonym for "checksum"
5867 because the word "manipulation" implies protection against active
5868 attacks, which an ordinary checksum might not provide. Instead, if
5869 such protection is intended, use "protected checksum" or some
5870 particular type thereof, depending on which is meant. If such
5871 protection is not intended, use "error detection code" or some
5872 specific type of checksum that is not protected.
5875 (I) A type of attack in which one system entity illegitimately
5876 poses as (assumes the identity of) another entity. (See: spoofing
5882 Shirey Informational [Page 105]
5884 RFC 2828 Internet Security Glossary May 2000
5888 See: merchant certificate authority.
5891 (N) A cryptographic hash [R1319] that produces a 128-bit hash
5892 result, was designed by Ron Rivest, and is similar to MD4 and MD5
5893 but slower. (See: message digest.)
5896 (N) A cryptographic hash [R1320] that produces a 128-bit hash
5897 result and was designed by Ron Rivest. (See: message digest and
5901 (N) A cryptographic hash [R1321] that produces a 128-bit hash
5902 result and was designed by Ron Rivest to be an improved version of
5906 (O) SET usage: "A seller of goods, services, and/or other
5907 information who accepts payment for these items electronically."
5908 [SET2] A merchant may also provide electronic selling services
5909 and/or electronic delivery of items for sale. With SET, the
5910 merchant can offer its cardholders secure electronic interactions,
5911 but a merchant that accepts payment cards is required to have a
5912 relationship with an acquirer. [SET1, SET2]
5914 $ merchant certificate
5915 (O) SET usage: A public-key certificate issued to a merchant.
5916 Sometimes used to refer to a pair of such certificates where one
5917 is for digital signature use and the other is for encryption.
5919 $ merchant certification authority (MCA)
5920 (O) SET usage: A CA that issues digital certificates to merchants
5921 and is operated on behalf of a payment card brand, an acquirer, or
5922 another party according to brand rules. Acquirers verify and
5923 approve requests for merchant certificates prior to issuance by
5924 the MCA. An MCA does not issue a CRL, but does distribute CRLs
5925 issued by root CAs, brand CAs, geopolitical CAs, and payment
5929 (I) A non-hierarchical PKI architecture in which there are several
5930 trusted CAs rather than a single root. Each certificate user bases
5931 path validations on the public key of one of the trusted CAs,
5932 usually the one that issued that user's own public-key
5933 certificate. Rather than having superior-to-subordinate
5938 Shirey Informational [Page 106]
5940 RFC 2828 Internet Security Glossary May 2000
5943 relationships between CAs, the relationships are peer-to-peer, and
5944 CAs issue cross-certificates to each other. (See: hierarchical
5945 PKI, trust-file PKI.)
5947 $ message authentication code vs. Message Authentication Code (MAC)
5948 1. (N) Capitalized: "(The) Message Authentication Code" refers to
5949 an ANSI standard for a checksum that is computed with a keyed hash
5950 that is based on DES. [A9009] (Also known as the U.S. Government
5951 standard Data Authentication Code. [FP113])
5953 (C) The ANSI standard MAC algorithm is equivalent to cipher block
5954 chaining with IV = 0.
5956 2. (D) Not capitalized: ISDs SHOULD NOT use the uncapitalized form
5957 "message authentication code", because this term mixes concepts in
5958 a potentially misleading way. Instead, use "checksum", "error
5959 detection code", "hash", "keyed hash", "Message Authentication
5960 Code", or "protected checksum", depending on what is meant. (See:
5961 authentication code.)
5963 (C) In the uncapitalized form, the word "message" is misleading
5964 because it implies that the mechanism is particularly suitable for
5965 or limited to electronic mail (see: Message Handling Systems), the
5966 word "authentication" is misleading because the mechanism
5967 primarily serves a data integrity function rather than an
5968 authentication function, and the word "code" is misleading because
5969 it implies that either encoding or encryption is involved or that
5970 the term refers to computer software.
5973 (D) ISDs SHOULD NOT use this term as a synonym for "hash result"
5974 because it unnecessarily duplicates the meaning of the other, more
5975 general term and mixes concepts in a potentially misleading way.
5976 (See: cryptographic hash, Message Handling System.)
5978 $ Message Handling Systems
5979 (I) A ITU-T/ISO system concept, which encompasses the notion of
5980 electronic mail but defines more comprehensive OSI systems and
5981 services that enable users to exchange messages on a store-and-
5982 forward basis. (The ISO equivalent is "Message Oriented Text
5983 Interchange System".) (See: X.400.)
5986 (D) ISDs SHOULD NOT use this term as a synonym for "initialization
5987 value" because it mixes concepts in a potentially misleading way.
5994 Shirey Informational [Page 107]
5996 RFC 2828 Internet Security Glossary May 2000
5999 $ message integrity check
6000 $ message integrity code
6001 (D) ISDs SHOULD NOT use these terms because they mix concepts in a
6002 potentially misleading way. (The word "message" is misleading
6003 because it suggests that the mechanism is particularly suitable
6004 for or limited to electronic mail. The word "code" is misleading
6005 because it suggests that either encoding or encryption is
6006 involved, or that the term refers to computer software.) Instead,
6007 use "checksum", "error detection code", "hash", "keyed hash",
6008 "Message Authentication Code", or "protected checksum", depending
6011 $ Message Security Protocol (MSP)
6012 (N) A secure message handling protocol [SDNS7] for use with X.400
6013 and Internet mail protocols. Developed by NSA's SDNS program and
6014 used in the U.S. Defense Message System.
6017 See: message handling system.
6020 See: Multipurpose Internet Mail Extensions.
6022 $ MIME Object Security Services (MOSS)
6023 (I) An Internet protocol [R1848] that applies end-to-end
6024 encryption and digital signature to MIME message content, using
6025 symmetric cryptography for encryption and asymmetric cryptography
6026 for key distribution and signature. MOSS is based on features and
6027 specifications of PEM. (See: S/MIME.)
6029 $ Minimum Interoperability Specification for PKI Components (MISPC)
6030 (N) A technical description to provide a basis for interoperation
6031 between PKI components from different vendors; consists primarily
6032 of a profile of certificate and CRL extensions and a set of
6033 transactions for PKI operation. [MISPC]
6036 See: Minimum Interoperability Specification for PKI Components.
6039 (N) Multilevel Information System Security Initiative, an NSA
6040 program to encourage development of interoperable, modular
6041 products for constructing secure network information systems in
6042 support of a wide variety of Government missions. (See: MSP.)
6050 Shirey Informational [Page 108]
6052 RFC 2828 Internet Security Glossary May 2000
6056 (O) MISSI usage: A system entity that is the subject of one or
6057 more MISSI X.509 public-key certificates issued under a MISSI
6058 certification hierarchy. (See: personality.)
6060 (C) MISSI users include both end users and the authorities that
6061 issue certificates. A MISSI user is usually a person but may be a
6062 machine or other automated process. Some machines are required to
6063 operate non-stop. To avoid downtime needed to exchange the
6064 FORTEZZA cards of machine operators at shift changes, the machines
6065 may be issued their own cards, as if they were persons.
6069 (I) Encryption usage: A technique for enhancing the effect of a
6070 cryptographic algorithm or adapting the algorithm for an
6071 application, such as applying a block cipher to a sequence of data
6072 blocks or a data stream. (See: electronic codebook, cipher block
6073 chaining, cipher feedback, output feedback.)
6075 (I) System operation usage: A type of security policy that states
6076 the range of classification levels of information that a system is
6077 permitted to handle and the range of clearances and authorizations
6078 of users who are permitted to access the system. (See: dedicated
6079 security mode, multilevel security mode, partitioned security
6080 mode, system high security mode.)
6083 (I) The defining constant in modular arithmetic, and usually a
6084 part of the public key in asymmetric cryptography that is based on
6085 modular arithmetic. (See: Diffie-Hellman, Rivest-Shamir-Adleman.)
6088 (I) A worm program written by Robert T. Morris, Jr. that flooded
6089 the ARPANET in November, 1988, causing problems for thousands of
6093 See: MIME Object Security Services.
6096 See: Message Security Protocol.
6098 $ multilevel secure (MLS)
6099 (I) A class of system that has system resources (particularly
6100 stored information) at more than one security level (i.e., has
6101 different types of sensitive resources) and that permits
6106 Shirey Informational [Page 109]
6108 RFC 2828 Internet Security Glossary May 2000
6111 concurrent access by users who differ in security clearance and
6112 need-to-know, but is able to prevent each user from accessing
6113 resources for which the user lacks authorization.
6115 $ multilevel security mode
6116 (I) A mode of operation of an information system, that allows two
6117 or more classification levels of information to be processed
6118 concurrently within the same system when not all users have a
6119 clearance or formal access authorization for all data handled by
6122 (C) This mode is defined formally in U.S. Department of Defense
6123 policy regarding system accreditation [DOD2], but the term is also
6124 used outside the Defense Department and outside the Government.
6126 $ Multipurpose Internet Mail Extensions (MIME)
6127 (I) An Internet protocol [R2045] that enhances the basic format of
6128 Internet electronic mail messages [R0822] to be able to use
6129 character sets other than US-ASCII for textual headers and text
6130 content, and to carry non-textual and multi-part content. (See:
6134 (I) The state that exists between two interacting system entities
6135 in which neither entity can trust the other to function correctly
6136 with regard to some security requirement.
6138 $ National Computer Security Center (NCSC)
6139 (N) A U.S. Department of Defense organization, housed in NSA, that
6140 has responsibility for encouraging widespread availability of
6141 trusted computer systems throughout the Federal Government. It has
6142 established criteria for, and performs evaluations of, computer
6143 and network systems that have a trusted computing base. (See:
6144 Evaluated Products List, Rainbow Series, TCSEC.)
6146 $ National Information Assurance Partnership (NIAP)
6147 (N) An organization created by NIST and NSA to enhance the quality
6148 of commercial products for information security and increase
6149 consumer confidence in those products through objective evaluation
6150 and testing methods.
6152 (C) NIAP is registered, through the U.S. Department of Defense, as
6153 a National Performance Review Reinvention Laboratory. NIAP
6154 functions include the following:
6156 - Developing tests, test methods, and other tools that developers
6157 and testing laboratories may use to improve and evaluate
6162 Shirey Informational [Page 110]
6164 RFC 2828 Internet Security Glossary May 2000
6167 - Collaborating with industry and others on research and testing
6169 - Using the Common Criteria to develop protection profiles and
6170 associated test sets for security products and systems.
6171 - Cooperating with the NIST National Voluntary Laboratory
6172 Accreditation Program to develop a program to accredit private-
6173 sector laboratories for the testing of information security
6174 products using the Common Criteria.
6175 - Working to establish a formal, international mutual recognition
6176 scheme for a Common Criteria-based evaluation.
6178 $ National Institute of Standards and Technology (NIST)
6179 (N) A U.S. Department of Commerce agency that promotes U.S.
6180 economic growth by working with industry to develop and apply
6181 technology, measurements, and standards. Has primary Government
6182 responsibility for INFOSEC standards for unclassified but
6183 sensitive information. (See: ANSI, DES, DSA, DSS, FIPS, NIAP,
6186 $ National Security Agency (NSA)
6187 (N) A U.S. Department of Defense intelligence agency that has
6188 primary Government responsibility for INFOSEC for classified
6189 information and for unclassified but sensitive information handled
6190 by national security systems. (See: FORTEZZA, KEA, MISSI, NIAP,
6194 (I) The necessity for access to, knowledge of, or possession of
6195 specific information required to carry out official duties.
6197 (C) This criterion is used in security procedures that require a
6198 custodian of sensitive information, prior to disclosing the
6199 information to someone else, to establish that the intended
6200 recipient has proper authorization to access the information.
6203 See: computer network.
6206 See: National Information Assurance Partnership.
6209 See: National Institute of Standards and Technology.
6212 Network Layer Security Protocol. An OSI protocol (IS0 11577) for
6213 end-to-end encryption services at the top of OSI layer 3. NLSP is
6214 derived from an SDNS protocol, SP3, but is much more complex.
6218 Shirey Informational [Page 111]
6220 RFC 2828 Internet Security Glossary May 2000
6224 (I) A room or other space to which no person may have
6225 unaccompanied access and that, when occupied, is required to be
6226 occupied by two or more appropriately authorized persons. (See:
6230 (I) A random or non-repeating value that is included in data
6231 exchanged by a protocol, usually for the purpose of guaranteeing
6232 liveness and thus detecting and protecting against replay attacks.
6235 See: critical (extension of certificate).
6237 $ non-repudiation service
6238 (I) A security service that provide protection against false
6239 denial of involvement in a communication. (See: repudiation.)
6241 (C) Non-repudiation service does not and cannot prevent an entity
6242 from repudiating a communication. Instead, the service provides
6243 evidence that can be stored and later presented to a third party
6244 to resolve disputes that arise if and when a communication is
6245 repudiated by one of the entities involved. There are two basic
6246 kinds of non-repudiation service:
6248 - "Non-repudiation with proof of origin" provides the recipient
6249 of data with evidence that proves the origin of the data, and
6250 thus protects the recipient against an attempt by the
6251 originator to falsely deny sending the data. This service can
6252 be viewed as a stronger version of an data origin
6253 authentication service, in that it proves authenticity to a
6256 - "Non-repudiation with proof of receipt" provides the originator
6257 of data with evidence that proves the data was received as
6258 addressed, and thus protects the originator against an attempt
6259 by the recipient to falsely deny receiving the data.
6261 (C) Phases of a Non-Repudiation Service: Ford [For94, For97] uses
6262 the term "critical action" to refer to the act of communication
6263 that is the subject of the service:
6274 Shirey Informational [Page 112]
6276 RFC 2828 Internet Security Glossary May 2000
6279 -------- -------- -------- -------- -------- . --------
6280 Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6:
6281 Request Generate Transfer Verify Retain . Resolve
6282 Service Evidence Evidence Evidence Evidence . Dispute
6283 -------- -------- -------- -------- -------- . --------
6285 Service Critical Evidence Evidence Archive . Evidence
6286 Request => Action => Stored => Is => Evidence . Is
6287 Is Made Occurs For Later Tested In Case . Verified
6288 and Use | ^ Critical . ^
6289 Evidence v | Action Is . |
6290 Is +-------------------+ Repudiated . |
6291 Generated |Verifiable Evidence|------> ... . ----+
6292 +-------------------+
6296 1. Before the critical action, the service requester asks, either
6297 implicitly or explicitly, to have evidence of the action be
6299 2. When the critical action occurs, evidence is generated by a
6300 process involving the potential repudiator and possibly also a
6301 trusted third party.
6302 3. The evidence is transferred to the requester, or stored by a
6303 third party, for later use if needed.
6304 4. The entity that holds the evidence tests to be sure that it
6305 will suffice if a dispute arises.
6306 5. The evidence is retained for possible future retrieval and use.
6307 6. In this phase, which occurs only if the critical action is
6308 repudiated, the evidence is retrieved from storage, presented,
6309 and verified to resolve the dispute.
6312 (O) MISSI usage: An organizational RA that operates in a mode in
6313 which the ORA performs no card management functions and,
6314 therefore, does not require knowledge of either the SSO PIN or
6315 user PIN for an end user's FORTEZZA PC card.
6321 (I) Registration of data under the authority or in the care of a
6322 trusted third party, thus making it possible to provide subsequent
6323 assurance of the accuracy of characteristics claimed for the data,
6324 such as content, origin, time, and delivery. [I7498 Part 2] (See:
6330 Shirey Informational [Page 113]
6332 RFC 2828 Internet Security Glossary May 2000
6335 $ NULL encryption algorithm
6336 (I) An algorithm [R2410] that does nothing to transform plaintext
6337 data; i.e., a no-op. It originated because of IPsec ESP, which
6338 always specifies the use of an encryption algorithm to provide
6339 confidentiality. The NULL encryption algorithm is a convenient way
6340 to represent the option of not applying encryption in ESP (or in
6341 any other context where this is needed).
6344 (I) A key establishment protocol (proposed for IPsec but
6345 superseded by IKE) based on the Diffie-Hellman algorithm and
6346 designed to be a compatible component of ISAKMP. [R2412]
6348 (C) OAKLEY establishes a shared key with an assigned identifier
6349 and associated authenticated identities for parties. I.e., OAKLEY
6350 provides authentication service to ensure the entities of each
6351 other's identity, even if the Diffie-Hellman exchange is
6352 threatened by active wiretapping. Also, provides public-key
6353 forward secrecy for the shared key and supports key updates,
6354 incorporation of keys distributed by out-of-band mechanisms, and
6355 user-defined abstract group structures for use with Diffie-
6359 (I) Trusted computer system modeling usage: A system element that
6360 contains or receives information. (See: Bell-LaPadula Model,
6361 trusted computer system.)
6363 $ object identifier (OID)
6364 (I) An official, globally unique name for a thing, written as a
6365 sequence of integers (which are formed and assigned as defined in
6366 the ASN.1 standard) and used to reference the thing in abstract
6367 specifications and during negotiation of security services in a
6370 (O) "A value (distinguishable from all other such values) which is
6371 associated with an object." [X680]
6373 (C) Objects named by OIDs are leaves of the object identifier tree
6374 (which is similar to but different from the X.500 Directory
6375 Information Tree). Each arc (i.e., each branch of the tree) is
6376 labeled with a non-negative integer. An OID is the sequence of
6377 integers on the path leading from the root of the tree to a named
6380 (C) The OID tree has three arcs immediately below the root: {0}
6381 for use by ITU-T, {1} for use by ISO, and {2} for use by both
6382 jointly. Below ITU-T are four arcs, where {0 0} is for ITU-T
6386 Shirey Informational [Page 114]
6388 RFC 2828 Internet Security Glossary May 2000
6391 recommendations. Below {0 0} are 26 arcs, one for each series of
6392 recommendations starting with the letters A to Z, and below these
6393 are arcs for each recommendation. Thus, the OID for ITU-T
6394 Recommendation X.509 is {0 0 24 509}. Below ISO are four arcs,
6395 where {1 0 }is for ISO standards, and below these are arcs for
6396 each ISO standard. Thus, the OID for ISO/IEC 9594-8 (the ISO
6397 number for X.509) is {1 0 9594 8}.
6399 (C) The following are additional examples: ANSI registers
6400 organization names below the branch {joint-iso-ccitt(2)
6401 country(16) US(840) organization(1)}. The NIST CSOR records PKI
6402 objects below the branch {joint-iso-ccitt(2) country(16) us(840)
6403 gov(101) csor(3) pki(4)}. The U.S. Department of Defense registers
6404 INFOSEC objects below the branch {joint-iso-ccitt(2) country(16)
6405 us(840) organization(1) gov(101) dod(2) infosec(1)}. The OID for
6406 the PKIX private extension is defined in an arc below the arc for
6407 the PKIX name space, as {iso(1) identified-organization(3) dod(6)
6408 internet(1) security(5) mechanisms(5) pkix(7) 1 1}.
6411 (N) "The reassignment and reuse of a storage medium (e.g., page
6412 frame, disk sector, magnetic tape) that once contained one or more
6413 [information] objects. To be securely reused and assigned to a new
6414 subject, storage media must contain no residual data (magnetic
6415 remanence) from the object(s) previously contained in the media."
6419 See: On-line Certificate Status Protocol.
6422 (I) A data unit of eight bits. (See: byte.)
6424 (c) This term is used in networking (especially in OSI standards)
6425 in preference to "byte", because some systems use "byte" for data
6426 storage units of a size other than eight.
6429 See: output feedback.
6432 (C) That minuscule fraction of time in which you realize that your
6433 private key has been compromised.
6436 See: object identifier.
6442 Shirey Informational [Page 115]
6444 RFC 2828 Internet Security Glossary May 2000
6447 $ On-line Certificate Status Protocol (OCSP)
6448 (I) An Internet protocol used by a client to obtain from a server
6449 the validity status and other information concerning a digital
6452 (C) In some applications, such as those involving high-value
6453 commercial transactions, it may be necessary to obtain certificate
6454 revocation status that is more timely than is possible with CRLs
6455 or to obtain other kinds of status information. OCSP may be used
6456 to determine the current revocation status of a digital
6457 certificate, in lieu of or as a supplement to checking against a
6458 periodic CRL. An OCSP client issues a status request to an OCSP
6459 server and suspends acceptance of the certificate in question
6460 until the server provides a response.
6463 (I) An encryption algorithm in which the key is a random sequence
6464 of symbols and each symbol is used for encryption only one time--
6465 to encrypt only one plaintext symbol to produce only one
6466 ciphertext symbol--and a copy of the key is used similarly for
6469 (C) To ensure one-time use, the copy of the key used for
6470 encryption is destroyed after use, as is the copy used for
6471 decryption. This is the only encryption algorithm that is truly
6472 unbreakable, even given unlimited resources for cryptanalysis
6473 [Schn], but key management costs and synchronization problems make
6474 it impractical except in special situations.
6477 $ One-Time Password (OTP)
6478 1. Not capitalized: A "one-time password" is a simple
6479 authentication technique in which each password is used only once
6480 as authentication information that verifies an identity. This
6481 technique counters the threat of a replay attack that uses
6482 passwords captured by wiretapping.
6484 2. Capitalized: "One-Time Password" is an Internet protocol
6485 [R1938] that is based on S/KEY and uses a cryptographic hash
6486 function to generate one-time passwords for use as authentication
6487 information in system login and in other processes that need
6488 protection against replay attacks.
6490 $ one-way encryption
6491 (I) Irreversible transformation of plaintext to ciphertext, such
6492 that the plaintext cannot be recovered from the ciphertext by
6493 other than exhaustive procedures even if the cryptographic key is
6494 known. (See: encryption.)
6498 Shirey Informational [Page 116]
6500 RFC 2828 Internet Security Glossary May 2000
6504 (I) "A (mathematical) function, f, which is easy to compute, but
6505 which for a general value y in the range, it is computationally
6506 difficult to find a value x in the domain such that f(x) = y.
6507 There may be a few values of y for which finding x is not
6508 computationally difficult." [X509]
6510 (D) ISDs SHOULD NOT use this term as a synonym for "cryptographic
6513 $ open security environment
6514 (O) U.S. Department of Defense usage: A system environment that
6515 meets at least one of the following conditions: (a) Application
6516 developers (including maintainers) do not have sufficient
6517 clearance or authorization to provide an acceptable presumption
6518 that they have not introduced malicious logic. (b) Configuration
6519 control does not provide sufficient assurance that applications
6520 and the equipment are protected against the introduction of
6521 malicious logic prior to and during the operation of system
6522 applications. [NCS04] (See: closed security environment.)
6524 $ Open Systems Interconnection (OSI) Reference Model (OSIRM)
6525 (N) A joint ISO/ITU-T standard [I7498 Part 1] for a seven-layer,
6526 architectural communication framework for interconnection of
6527 computers in networks.
6529 (C) OSI-based standards include communication protocols that are
6530 mostly incompatible with the Internet Protocol Suite, but also
6531 include security models, such as X.509, that are used in the
6534 (C) The OSIRM layers, from highest to lowest, are (7) Application,
6535 (6) Presentation, (5) Session, (4) Transport, (3) Network, (2)
6536 Data Link, and (1) Physical. In this Glossary, these layers are
6537 referred to by number to avoid confusing them with Internet
6538 Protocol Suite layers, which are referred to by name.
6540 (C) Some unknown person described how the OSI layers correspond to
6541 the seven deadly sins:
6543 7. Wrath: Application is always angry at the mess it sees below
6544 itself. (Hey! Who is it to be pointing fingers?)
6545 6. Sloth: Presentation is too lazy to do anything productive by
6547 5. Lust: Session is always craving and demanding what truly
6548 belongs to Application's functionality.
6549 4. Avarice: Transport wants all of the end-to-end functionality.
6550 (Of course, it deserves it, but life isn't fair.)
6554 Shirey Informational [Page 117]
6556 RFC 2828 Internet Security Glossary May 2000
6559 3. Gluttony: (Connection-Oriented) Network is overweight and
6560 overbearing after trying too often to eat Transport's lunch.
6561 2. Envy: Poor Data Link is always starved for attention. (With
6562 Asynchronous Transfer Mode, maybe now it is feeling less
6564 1. Pride: Physical has managed to avoid much of the controversy,
6565 and nearly all of the embarrassment, suffered by the others.
6567 (C) John G. Fletcher described how the OSI layers also correspond
6568 to Snow White's dwarf friends:
6570 7. Doc: Application acts as if it is in charge, but sometimes
6572 6. Sleepy: Presentation is indolent, being guilty of the sin of
6574 5. Dopey: Session is confused because its charter is not very
6576 4. Grumpy: Transport is irritated because Network has encroached
6577 on Transport's turf.
6578 3. Happy: Network smiles for the same reason that Transport is
6580 2. Sneezy: Data Link makes loud noises in the hope of attracting
6582 1. Bashful: Physical quietly does its work, unnoticed by the
6585 $ operational integrity
6586 (I) A synonym for "system integrity"; emphasizes the actual
6587 performance of system functions rather than just the ability to
6590 $ operations security (OPSEC)
6591 (I) A process to identify, control, and protect evidence of the
6592 planning and execution of sensitive activities and operations, and
6593 thereby prevent potential adversaries from gaining knowledge of
6594 capabilities and intentions.
6597 See: operations security.
6600 See: organizational registration authority.
6603 (D) ISDs SHOULD NOT use this term as a synonym for "Trusted
6604 Computer System Evaluation Criteria" [CSC001, DOD1]. Instead, use
6610 Shirey Informational [Page 118]
6612 RFC 2828 Internet Security Glossary May 2000
6615 the full, proper name of the document or, in subsequent
6616 references, the abbreviation "TCSEC". (See: (usage note under)
6619 $ organizational certificate
6620 (O) MISSI usage: A type of MISSI X.509 public-key certificate that
6621 is issued to support organizational message handling for the U.S.
6622 Government's Defense Message System.
6624 $ organizational registration authority (ORA)
6625 (I) General usage: An RA for an organization.
6627 (O) MISSI usage: The MISSI implementation of RA. A MISSI end
6628 entity that (a) assists a PCA, CA, or SCA to register other end
6629 entities, by gathering, verifying, and entering data and
6630 forwarding it to the signing authority and (b) may also assist
6631 with card management functions. An ORA is a local administrative
6632 authority, and the term refers both to the office or role, and to
6633 the person who fills that office. An ORA does not sign
6634 certificates, CRLs, or CKLs. (See: no-PIN ORA, SSO-PIN ORA, user-
6637 $ origin authentication
6638 $ origin authenticity
6639 (D) ISDs SHOULD NOT use these terms because they look like
6640 careless use of an internationally standardized term. Instead, use
6641 "data origin authentication" or "peer entity authentication",
6642 depending which is meant.
6646 See: Open Systems Interconnection Reference Model.
6649 See: One-Time Password.
6652 (I) Transfer of information using a channel that is outside (i.e.,
6653 separate from) the channel that is normally used. (See: covert
6656 (C) Out-of-band mechanisms are often used to distribute shared
6657 secrets (e.g., a symmetric key) or other sensitive information
6658 items (e.g., a root key) that are needed to initialize or
6659 otherwise enable the operation of cryptography or other security
6660 mechanisms. (See: key distribution.)
6666 Shirey Informational [Page 119]
6668 RFC 2828 Internet Security Glossary May 2000
6671 $ output feedback (OFB)
6672 (N) A block cipher mode [FP081] that modifies electronic codebook
6673 mode to operate on plaintext segments of variable length less than
6674 or equal to the block length.
6676 (C) This mode operates by directly using the algorithm's
6677 previously generated output block as the algorithm's next input
6678 block (i.e., by "feeding back" the output block) and combining
6679 (exclusive OR-ing) the output block with the next plaintext
6680 segment (of block length or less) to form the next ciphertext
6685 See: (secondary definition under) attack.
6691 See: policy approving authority.
6694 See: (secondary definition under) filtering router.
6697 (I) A contraction of "Web page hijacking". A masquerade attack in
6698 which the attacker copies (steals) a home page or other material
6699 from the target server, rehosts the page on a server the attacker
6700 controls, and causes the rehosted page to be indexed by the major
6701 Web search services, thereby diverting browsers from the target
6702 server to the attacker's server.
6704 (D) ISDs SHOULD NOT use this term without including a definition,
6705 because the term is not listed in most dictionaries and could
6706 confuse international readers. (See: (usage note under) Green
6710 See: primary account number.
6713 See: Password Authentication Protocol.
6722 Shirey Informational [Page 120]
6724 RFC 2828 Internet Security Glossary May 2000
6727 $ partitioned security mode
6728 (N) A mode of operation of an information system, wherein all
6729 users have the clearance, but not necessarily formal access
6730 authorization and need-to-know, for all information handled by the
6731 system. This mode is defined in U.S. Department of Defense policy
6732 regarding system accreditation. [DoD2]
6735 See: (secondary definition under) attack.
6737 $ passive wiretapping
6738 See: (secondary definition under) wiretapping.
6741 (I) A secret data value, usually a character string, that is used
6742 as authentication information. (See: challenge-response.)
6744 (C) A password is usually matched with a user identifier that is
6745 explicitly presented in the authentication process, but in some
6746 cases the identity may be implicit.
6748 (C) Using a password as authentication information assumes that
6749 the password is known only by the system entity whose identity is
6750 being authenticated. Therefore, in a network environment where
6751 wiretapping is possible, simple authentication that relies on
6752 transmission of static (i.e., repetitively used) passwords as
6753 cleartext is inadequate. (See: one-time password, strong
6756 $ Password Authentication Protocol (PAP)
6757 (I) A simple authentication mechanism in PPP. In PAP, a user
6758 identifier and password are transmitted in cleartext. [R1334]
6762 (I) Passive wiretapping, usually on a local area network, to gain
6763 knowledge of passwords. (See: (usage note under) sniffing.)
6766 (I) For a digital certificate, the process of finding a set of
6767 public-key certificates that comprise a certification path from a
6768 trusted key to that specific certificate.
6771 (I) The process of validating (a) all of the digital certificates
6772 in a certification path and (b) the required relationships between
6773 those certificates, thus validating the contents of the last
6774 certificate on the path. (See: certificate validation.)
6778 Shirey Informational [Page 121]
6780 RFC 2828 Internet Security Glossary May 2000
6784 (N) SET usage: Collectively refers "to credit cards, debit cards,
6785 charge cards, and bank cards issued by a financial institution and
6786 which reflects a relationship between the cardholder and the
6787 financial institution." [SET2]
6790 (O) SET usage: A system operated by an acquirer, or a third party
6791 designated by an acquirer, for the purpose of providing electronic
6792 commerce services to the merchants in support of the acquirer, and
6793 which interfaces to the acquirer to support the authorization,
6794 capture, and processing of merchant payment messages, including
6795 payment instructions from cardholders. [SET1, SET2]
6797 $ payment gateway certification authority (SET PCA)
6798 (O) SET usage: A CA that issues digital certificates to payment
6799 gateways and is operated on behalf of a payment card brand, an
6800 acquirer, or another party according to brand rules. A SET PCA
6801 issues a CRL for compromised payment gateway certificates. [SET2]
6805 (N) A type of credit card-sized, plug-in peripheral device that
6806 was originally developed to provide memory expansion for portable
6807 computers, but is also used for other kinds of functional
6808 expansion. (See: FORTEZZA, PCMCIA.)
6810 (C) The international PC Card Standard defines a non-proprietary
6811 form factor in three standard sizes--Types I, II and III--each of
6812 which have a 68-pin interface between the card and the socket into
6813 which it plugs. All three types have the same length and width,
6814 roughly the size of a credit card, but differ in their thickness
6815 from 3.3 to 10.5 mm. Examples include storage modules, modems,
6816 device interface adapters, and cryptographic modules.
6819 (D) ISDs SHOULD NOT use this acronym without a qualifying
6820 adjective because that would be ambiguous. (See: Internet policy
6821 certification authority, (MISSI) policy creation authority, (SET)
6822 payment gateway certification authority.)
6825 (N) Personal Computer Memory Card International Association, a
6826 group of manufacturers, developers, and vendors, founded in 1989
6827 to standardize plug-in peripheral memory cards for personal
6828 computers and now extended to deal with any technology that works
6829 in the PC card form factor. (See: PC card.)
6834 Shirey Informational [Page 122]
6836 RFC 2828 Internet Security Glossary May 2000
6839 $ peer entity authentication
6840 (I) "The corroboration that a peer entity in an association is the
6841 one claimed." [I7498 Part 2] (See: authentication.)
6843 $ peer entity authentication service
6844 (I) A security service that verifies an identity claimed by or for
6845 a system entity in an association. (See: authentication,
6846 authentication service.)
6848 (C) This service is used at the establishment of, or at times
6849 during, an association to confirm the identity of one entity to
6850 another, thus protecting against a masquerade by the first entity.
6851 However, unlike data origin authentication service, this service
6852 requires an association to exist between the two entities, and the
6853 corroboration provided by the service is valid only at the current
6854 time that the service is provided.
6856 (C) See: "relationship between data integrity service and
6857 authentication services" under data integrity service.
6860 See: Privacy Enhanced Mail.
6863 (I) Successful, repeatable, unauthorized access to a protected
6864 system resource. (See: attack, violation.)
6867 (I) A system test, often part of system certification, in which
6868 evaluators attempt to circumvent the security features of the
6871 (C) Penetration testing may be performed under various constraints
6872 and conditions. However, for a TCSEC evaluation, testers are
6873 assumed to have all system design and implementation
6874 documentation, including source code, manuals, and circuit
6875 diagrams, and to work under no greater constraints than those
6876 applied to ordinary users.
6878 $ perfect forward secrecy
6879 See: (discussion under) public-key forward secrecy.
6882 See: security perimeter.
6890 Shirey Informational [Page 123]
6892 RFC 2828 Internet Security Glossary May 2000
6895 $ periods processing
6896 (I) A mode of system operation in which information of different
6897 sensitivities is processed at distinctly different times by the
6898 same system, with the system being properly purged or sanitized
6899 between periods. (See: color change.)
6902 (I) A synonym for "authorization", but "authorization" is
6903 preferred in the PKI context. (See: privilege.)
6905 $ personal identification number (PIN)
6906 (I) A character string used as a password to gain access to a
6907 system resource. (See: authentication information.)
6909 (C) Despite the words "identification" and "number", a PIN seldom
6910 serves as a user identifier, and a PIN's characters are not
6911 necessarily all numeric. A better name for this concept would have
6912 been "personal authentication system string (PASS)".
6914 (C) Retail banking applications commonly use 4-digit PINs.
6915 FORTEZZA PC card's use up to 12 characters for user or SSO PINs.
6919 (O) MISSI usage: A set of MISSI X.509 public-key certificates that
6920 have the same subject DN, together with their associated private
6921 keys and usage specifications, that is stored on a FORTEZZA PC
6922 card to support a role played by the card's user.
6924 (C) When a card's user selects a personality to use in a FORTEZZA-
6925 aware application, the data determines behavior traits (the
6926 personality) of the application. A card's user may have multiple
6927 personalities on the card. Each has a "personality label", a user-
6928 friendly character string that applications can display to the
6929 user for selecting or changing the personality to be used. For
6930 example, a military user's card might contain three personalities:
6931 GENERAL HALFTRACK, COMMANDER FORT SWAMPY, and NEW YEAR'S EVE PARTY
6932 CHAIRMAN. Each personality includes one or more certificates of
6933 different types (such as DSA versus RSA), for different purposes
6934 (such as digital signature versus encryption), or with different
6937 $ personnel security
6938 (I) Procedures to ensure that persons who access a system have
6939 proper clearance, authorization, and need-to-know as required by
6940 the system's security policy.
6946 Shirey Informational [Page 124]
6948 RFC 2828 Internet Security Glossary May 2000
6952 See: Pretty Good Privacy.
6955 (I) A UDP-based, key establishment protocol for session keys,
6956 designed for use with the IPsec protocols AH and ESP. Superseded
6960 (I) A contraction of "telephone breaking". An attack on or
6961 penetration of a telephone system or, by extension, any other
6962 communication or information system. [Raym]
6964 (D) ISDs SHOULD NOT use this term because it is not listed in most
6965 dictionaries and could confuse international readers.
6968 (I) Tangible means of preventing unauthorized physical access to a
6969 system. E.g., fences, walls, and other barriers; locks, safes, and
6970 vaults; dogs and armed guards; sensors and alarm bells. [FP031,
6974 (I) A form of active wiretapping in which the attacker gains
6975 access to a system via intervals of inactivity in another user's
6976 legitimate communication connection. Sometimes called a "between-
6977 the-lines" attack. (See: hijack attack, man-in-the-middle attack.)
6980 See: personal identification number.
6983 (I) An attack that sends an improperly large ICMP [R0792] echo
6984 request packet (a "ping") with the intent of overflowing the input
6985 buffers of the destination machine and causing it to crash.
6988 (I) An attack that sends ICMP [R0792] echo requests ("pings") to a
6989 range of IP addresses, with the goal of finding hosts that can be
6990 probed for vulnerabilities.
6993 See: Public-Key Cryptography Standards.
6996 (N) A standard [PKC07, R2315] from the PKCS series; defines a
6997 syntax for data that may have cryptography applied to it, such as
6998 for digital signatures and digital envelopes.
7002 Shirey Informational [Page 125]
7004 RFC 2828 Internet Security Glossary May 2000
7008 (N) A standard [PKC10] from the PKCS series; defines a syntax for
7009 requests for public-key certificates. (See: certification
7012 (C) A PKCS #10 request contains a DN and a public key, and may
7013 contain other attributes, and is signed by the entity making the
7014 request. The request is sent to a CA, who converts it to an X.509
7015 public-key certificate (or some other form) and returns it,
7016 possibly in PKCS #7 format.
7019 (N) A standard [PKC11] from the PKCS series; defines a software
7020 CAPI called Cryptoki (pronounced "crypto-key"; short for
7021 "cryptographic token interface") for devices that hold
7022 cryptographic information and perform cryptographic functions.
7025 See: public-key infrastructure.
7028 (I) (1.) A contraction of "Public-Key Infrastructure (X.509)", the
7029 name of the IETF working group that is specifying an architecture
7030 and set of protocols needed to support an X.509-based PKI for the
7031 Internet. (2.) A collective name for that architecture and set of
7034 (C) The goal of PKIX is to facilitate the use of X.509 public-key
7035 certificates in multiple Internet applications and to promote
7036 interoperability between different implementations that use those
7037 certificates. The resulting PKI is intended to provide a framework
7038 that supports a range of trust and hierarchy environments and a
7039 range of usage environments. PKIX specifies (a) profiles of the v3
7040 X.509 public-key certificate standards and the v2 X.509 CRL
7041 standards for the Internet; (b) operational protocols used by
7042 relying parties to obtain information such as certificates or
7043 certificate status; (c) management protocols used by system
7044 entities to exchange information needed for proper management of
7045 the PKI; and (d) information about certificate policies and CPSs,
7046 covering the areas of PKI security not directly addressed in the
7049 $ PKIX private extension
7050 (I) PKIX defines a private extension to identify an on-line
7051 verification service supporting the issuing CA.
7058 Shirey Informational [Page 126]
7060 RFC 2828 Internet Security Glossary May 2000
7064 (I) Data that is input to and transformed by an encryption
7065 process, or that is output by a decryption process.
7067 (C) Usually, the plaintext input to an encryption operation is
7068 cleartext. But in some cases, the input is ciphertext that was
7069 output from another encryption operation. (See: superencryption.)
7071 $ Point-to-Point Protocol (PPP)
7072 (I) An Internet Standard protocol [R1661] for encapsulation and
7073 full-duplex transportation of network layer (mainly OSI layer 3)
7074 protocol data packets over a link between two peers, and for
7075 multiplexing different network layer protocols over the same link.
7076 Includes optional negotiation to select and use a peer entity
7077 authentication protocol to authenticate the peers to each other
7078 before they exchange network layer data. (See: CHAP, EAP, PAP.)
7080 $ Point-to-Point Tunneling Protocol (PPTP)
7081 (I) An Internet client-server protocol (originally developed by
7082 Ascend and Microsoft) that enables a dial-up user to create a
7083 virtual extension of the dial-up link across a network by
7084 tunneling PPP over IP. (See: L2TP.)
7086 (C) PPP can encapsulate any Internet Protocol Suite network layer
7087 protocol (or OSI layer 3 protocol). Therefore, PPTP does not
7088 specify security services; it depends on protocols above and below
7089 it to provide any needed security. PPTP makes it possible to
7090 divorce the location of the initial dial-up server (i.e., the PPTP
7091 Access Concentrator, the client, which runs on a special-purpose
7092 host) from the location at which the dial-up protocol (PPP)
7093 connection is terminated and access to the network is provided
7094 (i.e., the PPTP Network Server, which runs on a general-purpose
7098 (D) ISDs SHOULD NOT use this word as an abbreviation for either
7099 "security policy" or "certificate policy". Instead, to avoid
7100 misunderstanding, use the fully qualified term, at least at the
7101 point of first usage.
7103 $ policy approving authority (PAA)
7104 (O) MISSI usage: The top-level signing authority of a MISSI
7105 certification hierarchy. The term refers both to that
7106 authoritative office or role and to the person who plays that
7107 role. (See: root registry.)
7114 Shirey Informational [Page 127]
7116 RFC 2828 Internet Security Glossary May 2000
7119 (C) A PAA registers MISSI PCAs and signs their X.509 public-key
7120 certificates. A PAA issues CRLs but does not issue a CKL. A PAA
7121 may issue cross-certificates to other PAAs.
7123 $ policy certification authority (Internet PCA)
7124 (I) An X.509-compliant CA at the second level of the Internet
7125 certification hierarchy, under the Internet Policy Registration
7126 Authority (IPRA). Each PCA operates in accordance with its
7127 published security policy (see: certification practice statement)
7128 and within constraints established by the IPRA for all PCAs.
7129 [R1422]. (See: policy creation authority.)
7131 $ policy creation authority (MISSI PCA)
7132 (O) MISSI usage: The second level of a MISSI certification
7133 hierarchy; the administrative root of a security policy domain of
7134 MISSI users and other, subsidiary authorities. The term refers
7135 both to that authoritative office or role and to the person who
7136 fills that office. (See: policy certification authority.)
7138 (C) A MISSI PCA's certificate is issued by a policy approving
7139 authority. The PCA registers the CAs in its domain, defines their
7140 configurations, and issues their X.509 public-key certificates.
7141 (The PCA may also issue certificates for SCAs, ORAs, and other end
7142 entities, but a PCA does not usually do this.) The PCA
7143 periodically issues CRLs and CKLs for its domain.
7145 $ Policy Management Authority
7146 (N) Canadian usage: An organization responsible for PKI oversight
7147 and policy management in the Government of Canada.
7150 (I) "Recognizing that, when a CA in one domain certifies a CA in
7151 another domain, a particular certificate policy in the second
7152 domain may be considered by the authority of the first domain to
7153 be equivalent (but not necessarily identical in all respects) to a
7154 particular certificate policy in the first domain." [X509]
7157 See: Post Office Protocol, version 3.
7160 (I) A POP3 "command" (better described as a transaction type, or a
7161 protocol-within-a-protocol) by which a POP3 client optionally uses
7162 a keyed hash (based on MD5) to authenticate itself to a POP3
7163 server and, depending on the server implementation, to protect
7164 against replay attacks. (See: CRAM, POP3 AUTH, IMAP4
7170 Shirey Informational [Page 128]
7172 RFC 2828 Internet Security Glossary May 2000
7175 (C) The server includes a unique timestamp in its greeting to the
7176 client. The subsequent APOP command sent by the client to the
7177 server contains the client's name and the hash result of applying
7178 MD5 to a string formed from both the timestamp and a shared secret
7179 that is known only to the client and the server. APOP was designed
7180 to provide as an alternative to using POP3's USER and PASS (i.e.,
7181 password) command pair, in which the client sends a cleartext
7182 password to the server.
7185 (I) A "command" [R1734] (better described as a transaction type,
7186 or a protocol-within-a-protocol) in POP3, by which a POP3 client
7187 optionally proposes a mechanism to a POP3 server to authenticate
7188 the client to the server and provide other security services.
7189 (See: POP3 APOP, IMAP4 AUTHENTICATE.)
7191 (C) If the server accepts the proposal, the command is followed by
7192 performing a challenge-response authentication protocol and,
7193 optionally, negotiating a protection mechanism for subsequent POP3
7194 interactions. The security mechanisms used by POP3 AUTH are those
7198 (I) An attack that sends client requests to a range of server port
7199 addresses on a host, with the goal of finding an active port and
7200 exploiting a known vulnerability of that service.
7203 (N) Portable Operating System Interface for Computer Environments,
7204 a standard [FP151, IS9945-1] (originally IEEE Standard P1003.1)
7205 that defines an operating system interface and environment to
7206 support application portability at the source code level. It is
7207 intended to be used by both application developers and system
7210 (C) P1003.1 supports security functionality like those on most
7211 UNIX systems, including discretionary access control and
7212 privilege. IEEE Draft Standard P1003.6.1 specifies additional
7213 functionality not provided in the base standard, including (a)
7214 discretionary access control, (b) audit trail mechanisms, (c)
7215 privilege mechanisms, (d) mandatory access control, and (e)
7216 information label mechanisms.
7218 $ Post Office Protocol, version 3 (POP3)
7219 (I) An Internet Standard protocol [R1939] by which a client
7220 workstation can dynamically access a mailbox on a server host to
7221 retrieve mail messages that the server has received and is holding
7222 for the client. (See: IMAP4.)
7226 Shirey Informational [Page 129]
7228 RFC 2828 Internet Security Glossary May 2000
7231 (C) POP3 has mechanisms for optionally authenticating a client to
7232 a server and providing other security services. (See: POP3 APOP,
7236 See: Point-to-Point Protocol.
7239 See: Point-to-Point Tunneling Protocol.
7242 (I) A capability of a CAW that enables certification requests to
7243 be automatically validated against data provided in advance to the
7244 CA by an authorizing entity.
7246 $ Pretty Good Privacy(trademark) (PGP(trademark))
7247 (O) Trademarks of Network Associates, Inc., referring to a
7248 computer program (and related protocols) that uses cryptography to
7249 provide data security for electronic mail and other applications
7250 on the Internet. (See: MOSS, PEM, S/MIME.)
7252 (C) PGP encrypts messages with IDEA in CFB mode, distributes the
7253 IDEA keys by encrypting them with RSA, and creates digital
7254 signatures on messages with MD5 and RSA. To establish ownership of
7255 public keys, PGP depends on the web of trust. (See: Privacy
7258 $ primary account number (PAN)
7259 (O) SET usage: "The assigned number that identifies the card
7260 issuer and cardholder. This account number is composed of an
7261 issuer identification number, an individual account number
7262 identification, and an accompanying check digit as defined by ISO
7263 7812-1985." [SET2, IS7812] (See: bank identification number.)
7265 (C) The PAN is embossed, encoded, or both on a magnetic-strip-
7266 based credit card. The PAN identifies the issuer to which a
7267 transaction is to be routed and the account to which it is to be
7268 applied unless specific instructions indicate otherwise. The
7269 authority that assigns the bank identification number part of the
7270 PAN is the American Bankers Association.
7273 (I) The right of an entity (normally a person), acting in its own
7274 behalf, to determine the degree to which it will interact with its
7275 environment, including the degree to which the entity is willing
7276 to share information about itself with others. (See: anonymity.)
7282 Shirey Informational [Page 130]
7284 RFC 2828 Internet Security Glossary May 2000
7287 (O) "The right of individuals to control or influence what
7288 information related to them may be collected and stored and by
7289 whom and to whom that information may be disclosed." [I7498 Part
7292 (D) ISDs SHOULD NOT use this term as a synonym for "data
7293 confidentiality" or "data confidentiality service", which are
7294 different concepts. Privacy is a reason for security rather than a
7295 kind of security. For example, a system that stores personal data
7296 needs to protect the data to prevent harm, embarrassment,
7297 inconvenience, or unfairness to any person about whom data is
7298 maintained, and to protect the person's privacy. For that reason,
7299 the system may need to provide data confidentiality service.
7301 $ Privacy Enhanced Mail (PEM)
7302 (I) An Internet protocol to provide data confidentiality, data
7303 integrity, and data origin authentication for electronic mail.
7304 [R1421, R1422]. (See: MOSS, MSP, PGP, S/MIME.)
7306 (C) PEM encrypts messages with DES in CBC mode, provides key
7307 distribution of DES keys by encrypting them with RSA, and signs
7308 messages with RSA over either MD2 or MD5. To establish ownership
7309 of public keys, PEM uses a certification hierarchy, with X.509
7310 public-key certificates and X.509 CRLs that are signed with RSA
7311 and MD2. (See: Pretty Good Privacy.)
7313 (C) PEM is designed to be compatible with a wide range of key
7314 management methods, but is limited to specifying security services
7315 only for text messages and, like MOSS, has not been widely
7316 implemented in the Internet.
7319 (I) A synonym for "private key".
7321 (D) In most cases, ISDs SHOULD NOT use this term; to avoid
7322 confusing readers, use "private key" instead. However, the term
7323 MAY be used when specifically discussing a key pair; e.g., "A key
7324 pair has a public component and a private component."
7327 See: (secondary definition under) extension.
7330 (I) The secret component of a pair of cryptographic keys used for
7331 asymmetric cryptography. (See: key pair, public key.)
7333 (O) "(In a public key cryptosystem) that key of a user's key pair
7334 which is known only by that user." [X509]
7338 Shirey Informational [Page 131]
7340 RFC 2828 Internet Security Glossary May 2000
7344 (I) An authorization or set of authorizations to perform security-
7345 relevant functions, especially in the context of a computer
7348 $ privilege management infrastructure
7349 (N) "The complete set of processes required to provide an
7350 authorization service", i.e., processes concerned with attribute
7351 certificates. [FPDAM] (See: PKI.)
7353 (D) ISDs SHOULD NOT use this term and its definition because the
7354 definition is vague, and there is no consensus on an alternate
7357 $ privileged process
7358 (I) An computer process that is authorized (and, therefore,
7359 trusted) to perform some security-relevant functions that ordinary
7360 processes are not. (See: privilege, trusted process.)
7362 $ procedural security
7363 (D) ISDs SHOULD NOT use this term as a synonym for "administrative
7364 security". Any type of security may involve procedures; therefore,
7365 the term may be misleading. Instead, use "administrative
7366 security", "communication security", "computer security",
7367 "emanations security", "personnel security", "physical security",
7368 or whatever specific type is meant. (See: security architecture.)
7371 (I) Refers to information (or other property) that is owned by an
7372 individual or organization and for which the use is restricted by
7375 $ protected checksum
7376 (I) A checksum that is computed for a data object by means that
7377 protect against active attacks that would attempt to change the
7378 checksum to make it match changes made to the data object. (See:
7379 digital signature, keyed hash, (discussion under) checksum.
7381 $ protected distribution system
7382 (I) A wireline or fiber-optic system that includes sufficient
7383 safeguards (acoustic, electric, electromagnetic, and physical) to
7384 permit its use for unencrypted transmission of (cleartext) data.
7386 $ protection authority
7387 See: (secondary definition under) Internet Protocol Security
7394 Shirey Informational [Page 132]
7396 RFC 2828 Internet Security Glossary May 2000
7400 (I) One of a hierarchy of privileged operation modes of a system
7401 that gives certain access rights to processes authorized to
7402 operate in that mode.
7405 (I) A set of rules (i.e., formats and procedures) to implement and
7406 control some type of association (e.g., communication) between
7407 systems. (E.g., see: Internet Protocol.)
7409 (C) In particular, a series of ordered steps involving computing
7410 and communication that are performed by two or more system
7411 entities to achieve a joint objective. [A9042]
7414 (I) A complementary collection of communication protocols used in
7415 a computer network. (See: Internet, OSI.)
7418 (I) A computer process--often used as, or as part of, a firewall--
7419 that relays a protocol between client and server computer systems,
7420 by appearing to the client to be the server and appearing to the
7421 server to be the client. (See: SOCKS.)
7423 (C) In a firewall, a proxy server usually runs on a bastion host,
7424 which may support proxies for several protocols (e.g., FTP, HTTP,
7425 and TELNET). Instead of a client in the protected enclave
7426 connecting directly to an external server, the internal client
7427 connects to the proxy server which in turn connects to the
7428 external server. The proxy server waits for a request from inside
7429 the firewall, forwards the request to the remote server outside
7430 the firewall, gets the response, then sends the response back to
7431 the client. The proxy may be transparent to the clients, or they
7432 may need to connect first to the proxy server, and then use that
7433 association to also initiate a connection to the real server.
7435 (C) Proxies are generally preferred over SOCKS for their ability
7436 to perform caching, high-level logging, and access control. A
7437 proxy can provide security service beyond that which is normally
7438 part of the relayed protocol, such as access control based on peer
7439 entity authentication of clients, or peer entity authentication of
7440 servers when clients do not have that capability. A proxy at OSI
7441 layer 7 can also provide finer-grained security service than can a
7442 filtering router at OSI layer 3. For example, an FTP proxy could
7443 permit transfers out of, but not into, a protected network.
7450 Shirey Informational [Page 133]
7452 RFC 2828 Internet Security Glossary May 2000
7456 (I) A sequence of values that appears to be random (i.e.,
7457 unpredictable) but is actually generated by a deterministic
7458 algorithm. (See: random.)
7460 $ pseudo-random number generator
7461 (I) A process used to deterministically generate a series of
7462 numbers (usually integers) that appear to be random according to
7463 certain statistical tests, but actually are pseudo-random.
7465 (C) Pseudo-random number generators are usually implemented in
7469 (I) A synonym for "public key".
7471 (D) In most cases, ISDs SHOULD NOT use this term; to avoid
7472 confusing readers, use "private key" instead. However, the term
7473 MAY be used when specifically discussing a key pair; e.g., "A key
7474 pair has a public component and a private component."
7477 (I) The publicly-disclosable component of a pair of cryptographic
7478 keys used for asymmetric cryptography. (See: key pair, private
7481 (O) "(In a public key cryptosystem) that key of a user's key pair
7482 which is publicly known." [X509]
7484 $ public-key certificate
7485 (I) A digital certificate that binds a system entity's identity to
7486 a public key value, and possibly to additional data items; a
7487 digitally-signed data structure that attests to the ownership of a
7488 public key. (See: X.509 public-key certificate.)
7490 (C) The digital signature on a public-key certificate is
7491 unforgeable. Thus, the certificate can be published, such as by
7492 posting it in a directory, without the directory having to protect
7493 the certificate's data integrity.
7495 (O) "The public key of a user, together with some other
7496 information, rendered unforgeable by encipherment with the private
7497 key of the certification authority which issued it." [X509]
7499 $ public-key cryptography
7500 (I) The popular synonym for "asymmetric cryptography".
7506 Shirey Informational [Page 134]
7508 RFC 2828 Internet Security Glossary May 2000
7511 $ Public-Key Cryptography Standards (PKCS)
7512 (I) A series of specifications published by RSA Laboratories for
7513 data structures and algorithm usage for basic applications of
7514 asymmetric cryptography. (See: PKCS #7, PKCS #10, PKCS #11.)
7516 (C) The PKCS were begun in 1991 in cooperation with industry and
7517 academia, originally including Apple, Digital, Lotus, Microsoft,
7518 Northern Telecom, Sun, and MIT. Today, the specifications are
7519 widely used, but they are not sanctioned by an official standards
7520 organization, such as ANSI, ITU-T, or IETF. RSA Laboratories
7521 retains sole decision-making authority over the PKCS.
7523 $ public-key forward secrecy (PFS)
7524 (I) For a key agreement protocol based on asymmetric cryptography,
7525 the property that ensures that a session key derived from a set of
7526 long-term public and private keys will not be compromised if one
7527 of the private keys is compromised in the future.
7529 (C) Some existing RFCs use the term "perfect forward secrecy" but
7530 either do not define it or do not define it precisely. While
7531 preparing this Glossary, we tried to find a good definition for
7532 that term, but found this to be a muddled area. Experts did not
7533 agree. For all practical purposes, the literature defines "perfect
7534 forward secrecy" by stating the Diffie-Hellman algorithm. The term
7535 "public-key forward secrecy" (suggested by Hilarie Orman) and the
7536 "I" definition stated for it here were crafted to be compatible
7537 with current Internet documents, yet be narrow and leave room for
7538 improved terminology.
7540 (C) Challenge to the Internet security community: We need a
7541 taxonomy--a family of mutually exclusive and collectively
7542 exhaustive terms and definitions to cover the basic properties
7543 discussed here--for the full range of cryptographic algorithms and
7544 protocols used in Internet Standards:
7546 (C) Involvement of session keys vs. long-term keys: Experts
7547 disagree about the basic ideas involved.
7549 - One concept of "forward secrecy" is that, given observations of
7550 the operation of a key establishment protocol up to time t, and
7551 given some of the session keys derived from those protocol runs,
7552 you cannot derive unknown past session keys or future session
7555 - A related property is that, given observations of the protocol
7556 and knowledge of the derived session keys, you cannot derive one
7557 or more of the long-term private keys.
7562 Shirey Informational [Page 135]
7564 RFC 2828 Internet Security Glossary May 2000
7567 - The "I" definition presented above involves a third concept of
7568 "forward secrecy" that refers to the effect of the compromise of
7571 - All three concepts involve the idea that a compromise of "this"
7572 encryption key is not supposed to compromise the "next" one. There
7573 also is the idea that compromise of a single key will compromise
7574 only the data protected by the single key. In Internet literature,
7575 the focus has been on protection against decryption of back
7576 traffic in the event of a compromise of secret key material held
7577 by one or both parties to a communication.
7579 (C) Forward vs. backward: Experts are unhappy with the word
7580 "forward", because compromise of "this" encryption key also is not
7581 supposed to compromise the "previous" one, which is "backward"
7582 rather than forward. In S/KEY, if the key used at time t is
7583 compromised, then all keys used prior to that are compromised. If
7584 the "long-term" key (i.e., the base of the hashing scheme) is
7585 compromised, then all keys past and future are compromised; thus,
7586 you could say that S/KEY has neither forward nor backward secrecy.
7588 (C) Asymmetric cryptography vs. symmetric: Experts disagree about
7589 forward secrecy in the context of symmetric cryptographic systems.
7590 In the absence of asymmetric cryptography, compromise of any long-
7591 term key seems to compromise any session key derived from the
7592 long-term key. For example, Kerberos isn't forward secret, because
7593 compromising a client's password (thus compromising the key shared
7594 by the client and the authentication server) compromises future
7595 session keys shared by the client and the ticket-granting server.
7597 (C) Ordinary forward secrecy vs. "perfect" forward secret: Experts
7598 disagree about the difference between these two. Some say there is
7599 no difference, and some say that the initial naming was
7600 unfortunate and suggest dropping the word "perfect". Some suggest
7601 using "forward secrecy" for the case where one long-term private
7602 key is compromised, and adding "perfect" for when both private
7603 keys (or, when the protocol is multi-party, all private keys) are
7606 (C) Acknowledgements: Bill Burr, Burt Kaliski, Steve Kent, Paul
7607 Van Oorschot, Michael Wiener, and, especially, Hilarie Orman
7608 contributed ideas to this discussion.
7610 $ public-key infrastructure (PKI)
7611 (I) A system of CAs (and, optionally, RAs and other supporting
7612 servers and agents) that perform some set of certificate
7613 management, archive management, key management, and token
7618 Shirey Informational [Page 136]
7620 RFC 2828 Internet Security Glossary May 2000
7623 management functions for a community of users in an application of
7624 asymmetric cryptography. (See: hierarchical PKI, mesh PKI,
7625 security management infrastructure, trust-file PKI.)
7627 (O) PKIX usage: The set of hardware, software, people, policies,
7628 and procedures needed to create, manage, store, distribute, and
7629 revoke digital certificates based on asymmetric cryptography.
7631 (C) The core PKI functions are (a) to register users and issue
7632 their public-key certificates, (b) to revoke certificates when
7633 required, and (c) to archive data needed to validate certificates
7634 at a much later time. Key pairs for data confidentiality may be
7635 generated (and perhaps escrowed) by CAs or RAs, but requiring a
7636 PKI client to generate its own digital signature key pair helps
7637 maintain system integrity of the cryptographic system, because
7638 then only the client ever possesses the private key it uses. Also,
7639 an authority may be established to approve or coordinate CPSs,
7640 which are security policies under which components of a PKI
7643 (C) A number of other servers and agents may support the core PKI,
7644 and PKI clients may obtain services from them. The full range of
7645 such services is not yet fully understood and is evolving, but
7646 supporting roles may include archive agent, certified delivery
7647 agent, confirmation agent, digital notary, directory, key escrow
7648 agent, key generation agent, naming agent who ensures that issuers
7649 and subjects have unique identifiers within the PKI, repository,
7650 ticket-granting agent, and time stamp agent.
7653 See: registration authority.
7656 (I) A capability of a CAW that allows a CA to divide the
7657 responsibility for certification requests among multiple RAs.
7659 (C) This capability might be used to restrict access to private
7660 authorization data that is provided with a certification request,
7661 and to distribute the responsibility to review and approve
7662 certification requests in high volume environments. RA domains
7663 might segregate certification requests according to an attribute
7664 of the certificate subject, such as an organizational unit.
7667 See: Remote Authentication Dial-In User Service.
7674 Shirey Informational [Page 137]
7676 RFC 2828 Internet Security Glossary May 2000
7680 (O) A set of more than 30 technical and policy documents with
7681 colored covers, issued by the NCSC, that discuss in detail the
7682 TCSEC and provide guidance for meeting and applying the criteria.
7683 (See: Green Book, Orange Book, Red Book, Yellow Book.)
7686 (I) General usage: In mathematics, random means "unpredictable". A
7687 sequence of values is called random if each successive value is
7688 obtained merely by chance and does not depend on the preceding
7689 values of the sequence, and a selected individual value is called
7690 random if each of the values in the total population of
7691 possibilities has equal probability of being selected. [Knuth]
7692 (See: cryptographic key, pseudo-random, random number generator.)
7694 (I) Security usage: In cryptography and other security
7695 applications, random means not only unpredictable, but also
7696 "unguessable". When selecting data values to use for cryptographic
7697 keys, "the requirement is for data that an adversary has a very
7698 low probability of guessing or determining." It is not sufficient
7699 to use data that "only meets traditional statistical tests for
7700 randomness or which is based on limited range sources, such as
7701 clocks. Frequently such random quantities are determinable [i.e.,
7702 guessable] by an adversary searching through an embarrassingly
7703 small space of possibilities." [R1750]
7705 $ random number generator
7706 (I) A process used to generate an unpredictable, uniformly
7707 distributed series of numbers (usually integers). (See: pseudo-
7710 (C) True random number generators are hardware-based devices that
7711 depend on the output of a "noisy diode" or other physical
7715 See: Role-Based Access Control.
7719 See: Rivest Cipher #2, Rivest Cipher #4.
7722 (O) Kerberos usage: The domain of authority of a Kerberos server
7723 (consisting of an authentication server and a ticket-granting
7724 server), including the Kerberized clients and the Kerberized
7730 Shirey Informational [Page 138]
7732 RFC 2828 Internet Security Glossary May 2000
7736 (I) Designation for information system equipment or facilities
7737 that handle (and for data that contains) only plaintext (or,
7738 depending on the context, classified information), and for such
7739 data itself. This term derives from U.S. Government COMSEC
7740 terminology. (See: BLACK, RED/BLACK separation.)
7743 (D) ISDs SHOULD NOT use this term as a synonym for "Trusted
7744 Network Interpretation of the Trusted Computer System Evaluation
7745 Criteria" [NCS05]. Instead, use the full proper name of the
7746 document or, in subsequent references, a more conventional
7747 abbreviation. (See: TCSEC, Rainbow Series, (usage note under)
7750 $ RED/BLACK separation
7751 (I) An architectural concept for cryptographic systems that
7752 strictly separates the parts of a system that handle plaintext
7753 (i.e., RED information) from the parts that handle ciphertext
7754 (i.e., BLACK information). This term derives from U.S. Government
7755 COMSEC terminology. (See: BLACK, RED.)
7758 (I) "An access control concept that refers to an abstract machine
7759 that mediates all accesses to objects by subjects." [NCS04] (See:
7762 (C) A reference monitor should be (a) complete (i.e., it mediates
7763 every access), (b) isolated (i.e., it cannot be modified by other
7764 system entities), and (c) verifiable (i.e., small enough to be
7765 subjected to analysis and tests to ensure that it is correct).
7768 (I) A type of replay attack in which transmitted data is sent back
7773 (I) An administrative act or process whereby an entity's name and
7774 other attributes are established for the first time at a CA, prior
7775 to the CA issuing a digital certificate that has the entity's name
7776 as the subject. (See: registration authority.)
7778 (C) Registration may be accomplished either directly, by the CA,
7779 or indirectly, by a separate RA. An entity is presented to the CA
7780 or RA, and the authority either records the name(s) claimed for
7781 the entity or assigns the entity's name(s). The authority also
7782 determines and records other attributes of the entity that are to
7786 Shirey Informational [Page 139]
7788 RFC 2828 Internet Security Glossary May 2000
7791 be bound in a certificate (such as a public key or authorizations)
7792 or maintained in the authority's database (such as street address
7793 and telephone number). The authority is responsible, possibly
7794 assisted by an RA, for authenticating the entity's identity and
7795 verifying the correctness of the other attributes, in accordance
7798 (C) Among the registration issues that a CPS may address are the
7801 - How a claimed identity and other attributes are verified.
7802 - How organization affiliation or representation is verified.
7803 - What forms of names are permitted, such as X.500 DN, domain
7804 name, or IP address.
7805 - Whether names are required to be meaningful or unique, and
7807 - How naming disputes are resolved, including the role of
7809 - Whether certificates are issued to entities that are not
7811 - Whether a person is required to appear before the CA or RA, or
7812 can instead be represented by an agent.
7813 - Whether and how an entity proves possession of the private key
7814 matching a public key.
7816 $ registration authority (RA)
7817 (I) An optional PKI entity (separate from the CAs) that does not
7818 sign either digital certificates or CRLs but has responsibility
7819 for recording or verifying some or all of the information
7820 (particularly the identities of subjects) needed by a CA to issue
7821 certificates and CRLs and to perform other certificate management
7822 functions. (See: organizational registration authority,
7825 (C) Sometimes, a CA may perform all certificate management
7826 functions for all end users for which the CA signs certificates.
7827 Other times, such as in a large or geographically dispersed
7828 community, it may be necessary or desirable to offload secondary
7829 CA functions and delegate them to an assistant, while the CA
7830 retains the primary functions (signing certificates and CRLs). The
7831 tasks that are delegated to an RA by a CA may include personal
7832 authentication, name assignment, token distribution, revocation
7833 reporting, key generation, and archiving. An RA is an optional PKI
7834 component, separate from the CA, that is assigned secondary
7835 functions. The duties assigned to RAs vary from case to case but
7836 may include the following:
7842 Shirey Informational [Page 140]
7844 RFC 2828 Internet Security Glossary May 2000
7847 - Verifying a subject's identity, i.e., performing personal
7848 authentication functions.
7849 - Assigning a name to a subject. (See: distinguished name.)
7850 - Verifying that a subject is entitled to have the attributes
7851 requested for a certificate.
7852 - Verifying that a subject possesses the private key that matches
7853 the public key requested for a certificate.
7854 - Performing functions beyond mere registration, such as
7855 generating key pairs, distributing tokens, and handling
7856 revocation reports. (Such functions may be assigned to a PKI
7857 element that is separate from both the CA and the RA.)
7859 (I) PKIX usage: An optional PKI component, separate from the
7860 CA(s). The functions that the RA performs will vary from case to
7861 case but may include identity authentication and name assignment,
7862 key generation and archiving of key pairs, token distribution, and
7863 revocation reporting. [R2510]
7865 (O) SET usage: "An independent third-party organization that
7866 processes payment card applications for multiple payment card
7867 brands and forwards applications to the appropriate financial
7868 institutions." [SET2]
7871 (I) Deliberately change the classification level of information in
7872 an authorized manner.
7875 (I) Change the value of a cryptographic key that is being used in
7876 an application of a cryptographic system. (See: certificate
7879 (C) For example, rekey is required at the end of a cryptoperiod or
7883 (I) The ability of a system to perform a required function under
7884 stated conditions for a specified period of time. (See:
7885 availability, survivability.)
7888 (N) A synonym for "certificate user". Used in a legal context to
7889 mean a recipient of a certificate who acts in reliance on that
7890 certificate. (See: ABA Guidelines.)
7892 $ Remote Authentication Dial-In User Service (RADIUS)
7893 (I) An Internet protocol [R2138] for carrying dial-in users'
7894 authentication information and configuration information between a
7898 Shirey Informational [Page 141]
7900 RFC 2828 Internet Security Glossary May 2000
7903 shared, centralized authentication server (the RADIUS server) and
7904 a network access server (the RADIUS client) that needs to
7905 authenticate the users of its network access ports. (See: TACACS.)
7907 (C) A user of the RADIUS client presents authentication
7908 information to the client, and the client passes that information
7909 to the RADIUS server. The server authenticates the client using a
7910 shared secret value, then checks the user's authentication
7911 information, and finally returns to the client all authorization
7912 and configuration information needed by the client to deliver
7913 service to the user.
7916 See: certificate renewal.
7919 (I) An attack in which a valid data transmission is maliciously or
7920 fraudulently repeated, either by the originator or by an adversary
7921 who intercepts the data and retransmits it, possibly as part of a
7922 masquerade attack. (See: active wiretapping.)
7925 (I) A system for storing and distributing digital certificates and
7926 related information (including CRLs, CPSs, and certificate
7927 policies) to certificate users. (See: directory.)
7929 (O) "A trustworthy system for storing and retrieving certificates
7930 or other information relevant to certificates." [ABA]
7932 (C) A certificate is published to those who might need it by
7933 putting it in a repository. The repository usually is a publicly
7934 accessible, on-line server. In the Federal Public-key
7935 Infrastructure, for example, the expected repository is a
7936 directory that uses LDAP, but also may be the X.500 Directory that
7937 uses DAP, or an HTTP server, or an FTP server that permits
7941 (I) Denial by a system entity that was involved in an association
7942 (especially an association that transfers information) of having
7943 participated in the relationship. (See: accountability, non-
7944 repudiation service.)
7946 (O) "Denial by one of the entities involved in a communication of
7947 having participated in all or part of the communication." [I7498
7954 Shirey Informational [Page 142]
7956 RFC 2828 Internet Security Glossary May 2000
7959 $ Request for Comment (RFC)
7960 (I) One of the documents in the archival series that is the
7961 official channel for ISDs and other publications of the Internet
7962 Engineering Steering Group, the Internet Architecture Board, and
7963 the Internet community in general. [R2026, R2223] (See: Internet
7966 (C) This term is *not* a synonym for "Internet Standard".
7969 (I) The risk that remains after countermeasures have been applied.
7975 See: certificate revocation.
7978 (N) In an X.509 CRL entry, a date-time field that states when the
7979 certificate revocation occurred, i.e., when the CA declared the
7980 digital certificate to be invalid. (See: invalidity date.)
7982 (C) The revocation date may not resolve some disputes because, in
7983 the worst case, all signatures made during the validity period of
7984 the certificate may have to be considered invalid. However, it may
7985 be desirable to treat a digital signature as valid even though the
7986 private key used to sign was compromised after the signing. If
7987 more is known about when the compromise actually occurred, a
7988 second date-time, an "invalidity date", can be included in an
7989 extension of the CRL entry.
7992 See: certificate revocation list.
7995 See: certificate revocation.
7998 See: Request for Comment.
8001 (I) An expectation of loss expressed as the probability that a
8002 particular threat will exploit a particular vulnerability with a
8003 particular harmful result.
8010 Shirey Informational [Page 143]
8012 RFC 2828 Internet Security Glossary May 2000
8015 (O) SET usage: "The possibility of loss because of one or more
8016 threats to information (not to be confused with financial or
8017 business risk)." [SET2]
8021 (I) A process that systematically identifies valuable system
8022 resources and threats to those resources, quantifies loss
8023 exposures (i.e., loss potential) based on estimated frequencies
8024 and costs of occurrence, and (optionally) recommends how to
8025 allocate resources to countermeasures so as to minimize total
8028 (C) The analysis lists risks in order of cost and criticality,
8029 thereby determining where countermeasures should be applied first.
8030 It is usually financially and technically infeasible to counteract
8031 all aspects of risk, and so some residual risk will remain, even
8032 after all available countermeasures have been deployed. [FP031,
8036 (I) The process of identifying, controlling, and eliminating or
8037 minimizing uncertain events that may affect system resources.
8038 (See: risk analysis.)
8040 $ Rivest Cipher #2 (RC2)
8041 (N) A proprietary, variable-key-length block cipher invented by
8042 Ron Rivest for RSA Data Security, Inc. (now a wholly-owned
8043 subsidiary of Security Dynamics, Inc.).
8045 $ Rivest Cipher #4 (RC4)
8046 (N) A proprietary, variable-key-length stream cipher invented by
8047 Ron Rivest for RSA Data Security, Inc. (now a wholly-owned
8048 subsidiary of Security Dynamics, Inc.).
8050 $ Rivest-Shamir-Adleman (RSA)
8051 (N) An algorithm for asymmetric cryptography, invented in 1977 by
8052 Ron Rivest, Adi Shamir, and Leonard Adleman [RSA78, Schn].
8054 (C) RSA uses exponentiation modulo the product of two large prime
8055 numbers. The difficulty of breaking RSA is believed to be
8056 equivalent to the difficulty of factoring integers that are the
8057 product of two large prime numbers of approximately equal size.
8059 (C) To create an RSA key pair, randomly choose two large prime
8060 numbers, p and q, and compute the modulus, n = pq. Randomly choose
8061 a number e, the public exponent, that is less than n and
8062 relatively prime to (p-1)(q-1). Choose another number d, the
8066 Shirey Informational [Page 144]
8068 RFC 2828 Internet Security Glossary May 2000
8071 private exponent, such that ed-1 evenly divides (p-1)(q-1). The
8072 public key is the set of numbers (n,e), and the private key is the
8075 (C) It is assumed to be difficult to compute the private key (n,d)
8076 from the public key (n,e). However, if n can be factored into p
8077 and q, then the private key d can be computed easily. Thus, RSA
8078 security depends on the assumption that it is computationally
8079 difficult to factor a number that is the product of two large
8080 prime numbers. (Of course, p and q are treated as part of the
8081 private key, or else destroyed after computing n.)
8083 (C) For encryption of a message, m, to be sent to Bob, Alice uses
8084 Bob's public key (n,e) to compute m**e (mod n) = c. She sends c to
8085 Bob. Bob computes c**d (mod n) = m. Only Bob knows d, so only Bob
8086 can compute c**d (mod n) = m to recover m.
8088 (C) To provide data origin authentication of a message, m, to be
8089 sent to Bob, Alice computes m**d (mod n) = s, where (d,n) is
8090 Alice's private key. She sends m and s to Bob. To recover the
8091 message that only Alice could have sent, Bob computes s**e (mod n)
8092 = m, where (e,n) is Alice's public key.
8094 (C) To ensure data integrity in addition to data origin
8095 authentication requires extra computation steps in which Alice and
8096 Bob use a cryptographic hash function h (as explained for digital
8097 signature). Alice computes the hash value h(m) = v, and then
8098 encrypts v with her private key to get s. She sends m and s. Bob
8099 receives m' and s', either of which might have been changed from
8100 the m and s that Alice sent. To test this, he decrypts s' with
8101 Alice's public key to get v'. He then computes h(m') = v". If v'
8102 equals v", Bob is assured that m' is the same m that Alice sent.
8104 $ role-based access control (RBAC)
8105 (I) A form of identity-based access control where the system
8106 entities that are identified and controlled are functional
8107 positions in an organization or process.
8110 (I) A CA that is directly trusted by an end entity. Acquiring the
8111 value of a root CA's public key involves an out-of-band procedure.
8113 (I) Hierarchical PKI usage: The CA that is the highest level (most
8114 trusted) CA in a certification hierarchy; i.e., the authority upon
8115 whose public key all certificate users base their trust. (See: top
8122 Shirey Informational [Page 145]
8124 RFC 2828 Internet Security Glossary May 2000
8127 (C) In a hierarchical PKI, a root issues public-key certificates
8128 to one or more additional CAs that form the second highest level.
8129 Each of these CAs may issue certificates to more CAs at the third
8130 highest level, and so on. To initialize operation of a
8131 hierarchical PKI, the root's initial public key is securely
8132 distributed to all certificate users in a way that does not depend
8133 on the PKI's certification relationships. The root's public key
8134 may be distributed simply as a numerical value, but typically is
8135 distributed in a self-signed certificate in which the root is the
8136 subject. The root's certificate is signed by the root itself
8137 because there is no higher authority in a certification hierarchy.
8138 The root's certificate is then the first certificate in every
8141 (O) MISSI usage: A name previously used for a MISSI policy
8142 creation authority, which is not a root as defined above for
8143 general usage, but is a CA at the second level of the MISSI
8144 hierarchy, immediately subordinate to a MISSI policy approving
8147 (O) UNIX usage: A user account (also called "superuser") that has
8148 all privileges (including all security-related privileges) and
8149 thus can manage the system and its other user accounts.
8152 (I) A certificate for which the subject is a root.
8154 (I) Hierarchical PKI usage: The self-signed public-key certificate
8155 at the top of a certification hierarchy.
8158 (I) A public key for which the matching private key is held by a
8162 (O) MISSI usage: A name previously used for a MISSI policy
8163 approving authority.
8166 (I) A computer that is a gateway between two networks at OSI layer
8167 3 and that relays and directs data packets through that
8168 internetwork. The most common form of router operates on IP
8169 packets. (See: bridge.)
8171 (I) Internet usage: In the context of the Internet protocol suite,
8172 a networked computer that forwards Internet Protocol packets that
8173 are not addressed to the computer itself. (See: host.)
8178 Shirey Informational [Page 146]
8180 RFC 2828 Internet Security Glossary May 2000
8184 See: Rivest-Shamir-Adleman.
8186 $ rule-based security policy
8187 (I) "A security policy based on global rules imposed for all
8188 users. These rules usually rely on comparison of the sensitivity
8189 of the resource being accessed and the possession of corresponding
8190 attributes of users, a group of users, or entities acting on
8191 behalf of users." [I7498 Part 2] (See: identity-based security
8195 (I) The property of a system being free from risk of causing harm
8196 to system entities and outside entities.
8199 See: security association identifier.
8202 (I) A random value that is concatenated with a password before
8203 applying the one-way encryption function used to protect passwords
8204 that are stored in the database of an access control system. (See:
8205 initialization value.)
8207 (C) Salt protects a password-based access control system against a
8211 (I) Delete sensitive data from a file, a device, or a system; or
8212 modify data so as to be able to downgrade its classification
8216 See: Simple Authentication and Security Layer.
8219 See: subordinate certification authority.
8222 See: (secondary definition under) threat consequence.
8225 (I) A synonym for "filtering router".
8228 See: Secure Data Exchange.
8234 Shirey Informational [Page 147]
8236 RFC 2828 Internet Security Glossary May 2000
8240 See: Secure Data Network System.
8243 (O) To use cryptography to provide data integrity service for a
8244 data object. (See: sign, wrap.)
8246 (D) ISDs SHOULD NOT use this definition; instead, use language
8247 that is more specific with regard to the mechanism(s) used, such
8248 as "sign" when the mechanism is digital signature.
8251 (I) (1.) Adjective: The condition of information being protected
8252 from being known by any system entities except those who are
8253 intended to know it. (2.) Noun: An item of information that is
8256 (C) This term applies to symmetric keys, private keys, and
8259 $ secret-key cryptography
8260 (I) A synonym for "symmetric cryptography".
8262 $ Secure Data Exchange (SDE)
8263 (N) A local area network security protocol defined by the IEEE
8266 $ Secure Data Network System (SDNS)
8267 (N) An NSA program that developed security protocols for
8268 electronic mail (Message Security Protocol), OSI layer 3 (SP3),
8269 OSI layer 4 (SP4), and key management (KMP).
8271 $ Secure Hash Standard (SHS)
8272 (N) The U.S. Government standard [FP180] that specifies the Secure
8273 Hash Algorithm (SHA-1), a cryptographic hash function that
8274 produces a 160-bit output (hash result) for input data of any
8275 length < 2**64 bits.
8277 $ Secure Hypertext Transfer Protocol (Secure-HTTP, S-HTTP)
8278 (I) A Internet protocol for providing client-server security
8279 services for HTTP communications. (See: https.)
8281 (C) S-HTTP was originally specified by CommerceNet, a coalition of
8282 businesses interested in developing the Internet for commercial
8283 uses. Several message formats may be incorporated into S-HTTP
8284 clients and servers, particularly CMS and MOSS. S-HTTP supports
8285 choice of security policies, key management mechanisms, and
8286 cryptographic algorithms through option negotiation between
8290 Shirey Informational [Page 148]
8292 RFC 2828 Internet Security Glossary May 2000
8295 parties for each transaction. S-HTTP supports both asymmetric and
8296 symmetric key operation modes. S-HTTP attempts to avoid presuming
8297 a particular trust model, but it attempts to facilitate multiply-
8298 rooted hierarchical trust and anticipates that principals may have
8299 many public key certificates.
8301 $ Secure/MIME (S/MIME)
8302 (I) Secure/Multipurpose Internet Mail Extensions, an Internet
8303 protocol [R2633] to provide encryption and digital signatures for
8304 Internet mail messages.
8306 $ Secure Sockets Layer (SSL)
8307 (N) An Internet protocol (originally developed by Netscape
8308 Communications, Inc.) that uses connection-oriented end-to-end
8309 encryption to provide data confidentiality service and data
8310 integrity service for traffic between a client (often a web
8311 browser) and a server, and that can optionally provide peer entity
8312 authentication between the client and the server. (See: Transport
8315 (C) SSL is layered below HTTP and above a reliable transport
8316 protocol (TCP). SSL is independent of the application it
8317 encapsulates, and any higher level protocol can layer on top of
8318 SSL transparently. However, many Internet applications might be
8319 better served by IPsec.
8321 (C) SSL has two layers: (a) SSL's lower layer, the SSL Record
8322 Protocol, is layered on top of the transport protocol and
8323 encapsulates higher level protocols. One such encapsulated
8324 protocol is SSL Handshake Protocol. (b) SSL's upper layer provides
8325 asymmetric cryptography for server authentication (verifying the
8326 server's identity to the client) and optional client
8327 authentication (verifying the client's identity to the server),
8328 and also enables them to negotiate a symmetric encryption
8329 algorithm and secret session key (to use for data confidentiality)
8330 before the application protocol transmits or receives data. A
8331 keyed hash provides data integrity service for encapsulated data.
8334 (I) A system condition in which no subject can access any object
8335 in an unauthorized manner. (See: (secondary definition under)
8336 Bell-LaPadula Model, clean system.)
8339 (I) (1.) Measures taken to protect a system. (2.) The condition of
8340 a system that results from the establishment and maintenance of
8346 Shirey Informational [Page 149]
8348 RFC 2828 Internet Security Glossary May 2000
8351 measures to protect the system. (3.) The condition of system
8352 resources being free from unauthorized access and from
8353 unauthorized or accidental change, destruction, or loss.
8355 $ security architecture
8356 (I) A plan and set of principles that describe (a) the security
8357 services that a system is required to provide to meet the needs of
8358 its users, (b) the system elements required to implement the
8359 services, and (c) the performance levels required in the elements
8360 to deal with the threat environment. (See: (discussion under)
8363 (C) A security architecture is the result of applying the system
8364 engineering process. A complete system security architecture
8365 includes administrative security, communication security, computer
8366 security, emanations security, personnel security, and physical
8367 security (e.g., see: [R2179]). A complete security architecture
8368 needs to deal with both intentional, intelligent threats and
8369 accidental kinds of threats.
8371 $ security association
8372 (I) A relationship established between two or more entities to
8373 enable them to protect data they exchange. The relationship is
8374 used to negotiate characteristics of protection mechanisms, but
8375 does not include the mechanisms themselves. (See: association.)
8377 (C) A security association describes how entities will use
8378 security services. The relationship is represented by a set of
8379 information that is shared between the entities and is agreed upon
8380 and considered a contract between them.
8382 (O) IPsec usage: A simplex (uni-directional) logical connection
8383 created for security purposes and implemented with either AH or
8384 ESP (but not both). The security services offered by a security
8385 association depend on the protocol selected, the IPsec mode
8386 (transport or tunnel), the endpoints, and the election of optional
8387 services within the protocol. A security association is identified
8388 by a triple consisting of (a) a destination IP address, (b) a
8389 protocol (AH or ESP) identifier, and (c) a Security Parameter
8392 $ security association identifier (SAID)
8393 (I) A data field in a security protocol (such as NLSP or SDE),
8394 used to identify the security association to which a protocol data
8395 unit is bound. The SAID value is usually used to select a key for
8396 decryption or authentication at the destination. (See: Security
8402 Shirey Informational [Page 150]
8404 RFC 2828 Internet Security Glossary May 2000
8408 (I) An independent review and examination of a system's records
8409 and activities to determine the adequacy of system controls,
8410 ensure compliance with established security policy and procedures,
8411 detect breaches in security services, and recommend any changes
8412 that are indicated for countermeasures. [I7498 Part 2, NCS01]
8414 (C) The basic audit objective is to establish accountability for
8415 system entities that initiate or participate in security-relevant
8416 events and actions. Thus, means are needed to generate and record
8417 a security audit trail and to review and analyze the audit trail
8418 to discover and investigate attacks and security compromises.
8420 $ security audit trail
8421 (I) A chronological record of system activities that is sufficient
8422 to enable the reconstruction and examination of the sequence of
8423 environments and activities surrounding or leading to an
8424 operation, procedure, or event in a security-relevant transaction
8425 from inception to final results. [NCS04] (See: security audit.)
8428 (D) A synonym for "security level". For consistency, ISDs SHOULD
8429 use "security level" instead of "security class".
8431 $ security clearance
8432 (I) A determination that a person is eligible, under the standards
8433 of a specific security policy, for authorization to access
8434 sensitive information or other system resources. (See: clearance
8437 $ security compromise
8438 (I) A security violation in which a system resource is exposed, or
8439 is potentially exposed, to unauthorized access. (See: data
8440 compromise, violation.)
8445 $ security environment
8446 (I) The set of external entities, procedures, and conditions that
8447 affect secure development, operation, and maintenance of a system.
8450 (I) A occurrence in a system that is relevant to the security of
8451 the system. (See: security incident.)
8458 Shirey Informational [Page 151]
8460 RFC 2828 Internet Security Glossary May 2000
8463 (C) The term includes both events that are security incidents and
8464 those that are not. In a CA workstation, for example, a list of
8465 security events might include the following:
8467 - Performing a cryptographic operation, e.g., signing a digital
8469 - Performing a cryptographic card operation: creation, insertion,
8471 - Performing a digital certificate lifecycle operation: rekey,
8472 renewal, revocation, or update.
8473 - Posting information to an X.500 Directory.
8474 - Receiving a key compromise notification.
8475 - Receiving an improper certification request.
8476 - Detecting an alarm condition reported by a cryptographic
8478 - Logging the operator in or out.
8479 - Failing a built-in hardware self-test or a software system
8482 $ security fault analysis
8483 (I) A security analysis, usually performed on hardware at a logic
8484 gate level, gate-by-gate, to determine the security properties of
8485 a device when a hardware fault is encountered.
8488 (I) A gateway that separates trusted (or relatively more trusted)
8489 hosts on the internal network side from untrusted (or less
8490 trusted) hosts on the external network side. (See: firewall and
8493 (O) IPsec usage: "An intermediate system that implements IPsec
8494 protocols." [R2401] Normally, AH or ESP is implemented to serve a
8495 set of internal hosts, providing security services for the hosts
8496 when they communicate with other, external hosts or gateways that
8497 also implement IPsec.
8500 (I) A security event that involves a security violation. (See:
8501 CERT, GRIP, security event, security intrusion, security
8504 (C) In other words, a security-relevant system event in which the
8505 system's security policy is disobeyed or otherwise breached.
8507 (O) "Any adverse event which compromises some aspect of computer
8508 or network security." [R2350]
8514 Shirey Informational [Page 152]
8516 RFC 2828 Internet Security Glossary May 2000
8519 (D) ISDs SHOULD NOT use this "O" definition because (a) a security
8520 incident may occur without actually being harmful (i.e., adverse)
8521 and (b) this Glossary defines "compromise" more narrowly in
8522 relation to unauthorized access.
8524 $ security intrusion
8525 (I) A security event, or a combination of multiple security
8526 events, that constitutes a security incident in which an intruder
8527 gains, or attempts to gain, access to a system (or system
8528 resource) without having authorization to do so.
8531 (I) "The hardware, firmware, and software elements of a trusted
8532 computing base that implement the reference monitor concept. It
8533 must mediate all accesses, be protected from modification, and be
8534 verifiable as correct." [NCS04] (See: reference monitor.)
8536 (C) That is, a security kernel is an implementation of a reference
8537 monitor for a given hardware base.
8540 (I) A marking that is bound to a system resource and that names or
8541 designates the security-relevant attributes of that resource.
8542 [I7498 Part 2, R1457]
8544 (C) The recommended definition is usefully broad, but usually the
8545 term is understood more narrowly as a marking that represents the
8546 security level of an information object, i.e., a marking that
8547 indicates how sensitive an information object is. [NCS04]
8549 (C) System security mechanisms interpret security labels according
8550 to applicable security policy to determine how to control access
8551 to the associated information, otherwise constrain its handling,
8552 and affix appropriate security markings to visible (printed and
8553 displayed) images thereof. [FP188]
8556 (I) The combination of a hierarchical classification level and a
8557 set of non-hierarchical category designations that represents how
8558 sensitive information is. (See: (usage note under) classification
8559 level, dominate, lattice model.)
8561 $ security management infrastructure (SMI)
8562 (I) System elements and activities that support security policy by
8563 monitoring and controlling security services and mechanisms,
8564 distributing security information, and reporting security events.
8565 The associated functions are as follows [I7498-4]:
8570 Shirey Informational [Page 153]
8572 RFC 2828 Internet Security Glossary May 2000
8575 - Controlling (granting or restricting) access to system
8576 resources: This includes verifying authorizations and
8577 identities, controlling access to sensitive security data, and
8578 modifying access priorities and procedures in the event of
8581 - Retrieving (gathering) and archiving (storing) security
8582 information: This includes logging security events and
8583 analyzing the log, monitoring and profiling usage, and
8584 reporting security violations.
8586 - Managing and controlling the encryption process: This includes
8587 performing the functions of key management and reporting on key
8588 management problems. (See: public-key infrastructure.)
8590 $ security mechanism
8591 (I) A process (or a device incorporating such a process) that can
8592 be used in a system to implement a security service that is
8593 provided by or within the system. (See: (discussion under)
8596 (C) Some examples of security mechanisms are authentication
8597 exchange, checksum, digital signature, encryption, and traffic
8601 (I) A schematic description of a set of entities and relationships
8602 by which a specified set of security services are provided by or
8603 within a system. (See: (discussion under) security policy.)
8605 (C) An example is the Bell-LaPadula Model.
8607 $ security parameters index (SPI)
8608 (I) IPsec usage: The type of security association identifier used
8609 in IPsec protocols. A 32-bit value used to distinguish among
8610 different security associations terminating at the same
8611 destination (IP address) and using the same IPsec security
8612 protocol (AH or ESP). Carried in AH and ESP to enable the
8613 receiving system to determine under which security association to
8614 process a received packet.
8616 $ security perimeter
8617 (I) The boundary of the domain in which a security policy or
8618 security architecture applies; i.e., the boundary of the space in
8619 which security services protect system resources.
8626 Shirey Informational [Page 154]
8628 RFC 2828 Internet Security Glossary May 2000
8632 (I) A set of rules and practices that specify or regulate how a
8633 system or organization provides security services to protect
8634 sensitive and critical system resources. (See: identity-based
8635 security policy, rule-based security policy, security
8636 architecture, security mechanism, security model.)
8638 (O) "The set of rules laid down by the security authority
8639 governing the use and provision of security services and
8642 (C) Ravi Sandhu notes that security policy is one of four layers
8643 of the security engineering process (as shown in the following
8644 diagram). Each layer provides a different view of security,
8645 ranging from what services are needed to how services are
8648 What Security Services Should Be Provided?
8650 | + - - - - - - - - - - - +
8651 | | Security Policy |
8652 | + - - - - - - - - - - - + + - - - - - - - - - - - - - - +
8653 | | Security Model | | A "top-level specification" |
8654 | + - - - - - - - - - - - + <- | is at a level below "model" |
8655 | | Security Architecture | | but above "architecture". |
8656 | + - - - - - - - - - - - + + - - - - - - - - - - - - - - +
8657 | | Security Mechanism |
8658 | + - - - - - - - - - - - +
8660 How Are Security Services Implemented?
8662 $ Security Protocol 3 (SP3)
8663 (O) A protocol [SDNS3] developed by SDNS to provide connectionless
8664 data security at the top of OSI layer 3. (See: NLSP.)
8666 $ Security Protocol 4 (SP4)
8667 (O) A protocol [SDNS4] developed by SDNS to provide either
8668 connectionless or end-to-end connection-oriented data security at
8669 the bottom of OSI layer 4. (See: TLSP.)
8671 $ security-relevant event
8672 See: security event.
8675 (I) A processing or communication service that is provided by a
8676 system to give a specific kind of protection to system resources.
8677 (See: access control service, audit service, availability service,
8682 Shirey Informational [Page 155]
8684 RFC 2828 Internet Security Glossary May 2000
8687 data confidentiality service, data integrity service, data origin
8688 authentication service, non-repudiation service, peer entity
8689 authentication service, system integrity service.)
8691 (O) "A service, provided by a layer of communicating open systems,
8692 which ensures adequate security of the systems or the data
8693 transfers." [I7498 Part 2]
8695 (C) Security services implement security policies, and are
8696 implemented by security mechanisms.
8698 $ security situation
8699 (I) ISAKMP usage: The set of all security-relevant information--
8700 e.g., network addresses, security classifications, manner of
8701 operation (normal or emergency)--that is needed to decide the
8702 security services that are required to protect the association
8703 that is being negotiated.
8708 $ security violation
8709 (I) An act or event that disobeys or otherwise breaches security
8710 policy. (See: compromise, penetration, security incident.)
8712 $ self-signed certificate
8713 (I) A public-key certificate for which the public key bound by the
8714 certificate and the private key used to sign the certificate are
8715 components of the same key pair, which belongs to the signer.
8716 (See: root certificate.)
8718 (C) In a self-signed X.509 public-key certificate, the issuer's DN
8719 is the same as the subject's DN.
8722 (I) An attribute of a encryption algorithm that is a formalization
8723 of the notion that the algorithm not only hides the plaintext but
8724 also reveals no partial information about the plaintext. Whatever
8725 is efficiently computable about the plaintext when given the
8726 ciphertext, is also efficiently computable without the ciphertext.
8727 (See: indistinguishability.)
8729 $ sensitive (information)
8730 (I) Information is sensitive if disclosure, alteration,
8731 destruction, or loss of the information would adversely affect the
8732 interests or business of its owner or user. (See: critical.)
8738 Shirey Informational [Page 156]
8740 RFC 2828 Internet Security Glossary May 2000
8743 $ separation of duties
8744 (I) The practice of dividing the steps in a system function among
8745 different individuals, so as to keep a single individual from
8746 subverting the process. (See: dual control, administrative
8750 See: certificate serial number.
8753 (I) A system entity that provides a service in response to
8754 requests from other system entities called clients.
8757 (I) In the context of symmetric encryption, a key that is
8758 temporary or is used for a relatively short period of time. (See:
8759 ephemeral key, key distribution center, master key.)
8761 (C) Usually, a session key is used for a defined period of
8762 communication between two computers, such as for the duration of a
8763 single connection or transaction set, or the key is used in an
8764 application that protects relatively large amounts of data and,
8765 therefore, needs to be rekeyed frequently.
8768 See: SET Secure Electronic Transaction(trademark).
8770 $ SET private extension
8771 (O) One of the private extensions defined by SET for X.509
8772 certificates. Carries information about hashed root key,
8773 certificate type, merchant data, cardholder certificate
8774 requirements, encryption support for tunneling, or message support
8775 for payment instructions.
8778 (O) A certificate policy qualifier that provides information about
8779 the location and content of a SET certificate policy.
8781 (C) In addition to the policies and qualifiers inherited from its
8782 own certificate, each CA in the SET certification hierarchy may
8783 add one qualifying statement to the root policy when the CA issues
8784 a certificate. The additional qualifier is a certificate policy
8785 for that CA. Each policy in a SET certificate may have these
8788 - A URL where a copy of the policy statement may be found.
8789 - An electronic mail address where a copy of the policy statement
8794 Shirey Informational [Page 157]
8796 RFC 2828 Internet Security Glossary May 2000
8799 - A hash result of the policy statement, computed using the
8800 indicated algorithm.
8801 - A statement declaring any disclaimers associated with the
8802 issuing of the certificate.
8804 $ SET Secure Electronic Transaction(trademark) or SET(trademark)
8805 (N) A protocol developed jointly by MasterCard International and
8806 Visa International and published as an open standard to provide
8807 confidentiality of transaction information, payment integrity, and
8808 authentication of transaction participants for payment card
8809 transactions over unsecured networks, such as the Internet. [SET1]
8810 (See: acquirer, brand, cardholder, dual signature, electronic
8811 commerce, issuer, merchant, payment gateway, third party.)
8813 (C) This term and acronym are trademarks of SETCo. MasterCard and
8814 Visa announced the SET standard on 1 February 1996. On 19 December
8815 1997, MasterCard and Visa formed SET Secure Electronic Transaction
8816 LLC (commonly referred to as "SETCo") to implement the SET 1.0
8817 specification. A memorandum of understanding adds American Express
8818 and JCB Credit Card Company as co-owners of SETCo.
8821 See: (secondary definition under) SET Secure Electronic
8825 See: Secure Hash Standard.
8828 (I) A synonym for "keying material" or "cryptographic key".
8834 (I) Create a digital signature for a data object.
8837 See: digital signature, electronic signature.
8839 $ signature certificate
8840 (I) A public-key certificate that contains a public key that is
8841 intended to be used for verifying digital signatures, rather than
8842 for encrypting data or performing other cryptographic functions.
8844 (C) A v3 X.509 public-key certificate may have a "keyUsage"
8845 extension which indicates the purpose for which the certified
8846 public key is intended.
8850 Shirey Informational [Page 158]
8852 RFC 2828 Internet Security Glossary May 2000
8856 (N) A human being or an organization entity that uses its private
8857 key to create a digital signature for a data object. [ABA]
8860 See: Standards for Interoperable LAN/MAN Security.
8862 $ simple authentication
8863 (I) An authentication process that uses a password as the
8864 information needed to verify an identity claimed for an entity.
8865 (See: strong authentication.)
8867 (O) "Authentication by means of simple password arrangements."
8870 $ Simple Authentication and Security Layer (SASL)
8871 (I) An Internet specification [R2222] for adding authentication
8872 service to connection-based protocols. To use SASL, a protocol
8873 includes a command for authenticating a user to a server and for
8874 optionally negotiating protection of subsequent protocol
8875 interactions. The command names a registered security mechanism.
8876 SASL mechanisms include Kerberos, GSSAPI, S/KEY, and others. Some
8877 protocols that use SASL are IMAP4 and POP3.
8879 $ Simple Key-management for Internet Protocols (SKIP)
8880 (I) A key distribution protocol that uses hybrid encryption to
8881 convey session keys that are used to encrypt data in IP packets.
8882 [R2356] (See: IKE, IPsec.)
8884 (C) SKIP uses the Diffie-Hellman algorithm (or could use another
8885 key agreement algorithm) to generate a key-encrypting key for use
8886 between two entities. A session key is used with a symmetric
8887 algorithm to encrypt data in one or more IP packets that are to be
8888 sent from one of the entities to the other. The KEK is used with a
8889 symmetric algorithm to encrypt the session key, and the encrypted
8890 session key is placed in a SKIP header that is added to each IP
8891 packet that is encrypted with that session key.
8893 $ Simple Mail Transfer Protocol (SMTP)
8894 (I) A TCP-based, application-layer, Internet Standard protocol
8895 [R0821] for moving electronic mail messages from one computer to
8898 $ Simple Network Management Protocol (SNMP)
8899 (I) A UDP-based, application-layer, Internet Standard protocol
8900 [R2570, R2574] for conveying management information between
8901 managers and agents.
8906 Shirey Informational [Page 159]
8908 RFC 2828 Internet Security Glossary May 2000
8911 (C) SNMP version 1 uses cleartext passwords for authentication and
8912 access control. (See: community string.) Version 2 adds
8913 cryptographic mechanisms based on DES and MD5. Version 3 provides
8914 enhanced, integrated support for security services, including data
8915 confidentiality, data integrity, data origin authentication, and
8916 message timeliness and limited replay protection.
8918 $ simple security property
8919 See: (secondary definition under) Bell-LaPadula Model.
8922 (I) A system that enables a user to access multiple computer
8923 platforms (usually a set of hosts on the same network) or
8924 application systems after being authenticated just one time. (See:
8927 (C) Typically, a user logs in just once, and then is transparently
8928 granted access to a variety of permitted resources with no further
8929 login being required until after the user logs out. Such a system
8930 has the advantages of being user friendly and enabling
8931 authentication to be managed consistently across an entire
8932 enterprise, and has the disadvantage of requiring all hosts and
8933 applications to trust the same authentication mechanism.
8936 See: security situation.
8939 (I) A security mechanism that uses a cryptographic hash function
8940 to generate a sequence of 64-bit, one-time passwords for remote
8943 (C) The client generates a one-time password by applying the MD4
8944 cryptographic hash function multiple times to the user's secret
8945 key. For each successive authentication of the user, the number of
8946 hash applications is reduced by one. (Thus, an intruder using
8947 wiretapping cannot compute a valid password from knowledge of one
8948 previously used.) The server verifies a password by hashing the
8949 currently presented password (or initialization value) one time
8950 and comparing the hash result with the previously presented
8954 See: Simple Key-management for IP.
8962 Shirey Informational [Page 160]
8964 RFC 2828 Internet Security Glossary May 2000
8968 (N) A Type II block cipher [NIST] with a block size of 64 bits and
8969 a key size of 80 bits, that was developed by NSA and formerly
8970 classified at the U.S. Department of Defense "Secret" level. (See:
8971 CAPSTONE, CLIPPER, FORTEZZA, Key Exchange Algorithm.)
8973 (C) On 23 June 1998, NSA announced that SKIPJACK had been
8977 (O) MISSI usage: One of the FORTEZZA PC card storage areas that
8978 are each able to hold an X.509 certificate and additional data
8979 that is associated with the certificate, such as the matching
8983 (I) A credit-card sized device containing one or more integrated
8984 circuit chips, which perform the functions of a computer's central
8985 processor, memory, and input/output interface. (See: PC card.)
8987 (C) Sometimes this term is used rather strictly to mean a card
8988 that closely conforms to the dimensions and appearance of the kind
8989 of plastic credit card issued by banks and merchants. At other
8990 times, the term is used loosely to include cards that are larger
8991 than credit cards, especially cards that are thicker, such as PC
8994 (C) A "smart token" is a device that conforms to the definition of
8995 smart card except that rather than having standard credit card
8996 dimensions, the token is packaged in some other form, such as a
8997 dog tag or door key shape.
9000 See: (secondary definition under) smart card.
9003 See: security management infrastructure.
9009 See: Simple Mail Transfer Protocol.
9012 (I) Software that mounts a denial-of-service attack ("smurfing")
9013 by exploiting IP broadcast addressing and ICMP ping packets to
9014 cause flooding. (See: flood, ICMP flood.)
9018 Shirey Informational [Page 161]
9020 RFC 2828 Internet Security Glossary May 2000
9023 (D) ISDs SHOULD NOT use this term because it is not listed in most
9024 dictionaries and could confuse international readers.
9026 (C) A smurf program builds a network packet that appears to
9027 originate from another address, that of the "victim", either a
9028 host or an IP router. The packet contains an ICMP ping message
9029 that is addressed to an IP broadcast address, i.e., to all IP
9030 addresses in a given network. The echo responses to the ping
9031 message return to the victim's address. The goal of smurfing may
9032 be either to deny service at a particular host or to flood all or
9033 part of an IP network.
9036 (C) A synonym for "passive wiretapping". (See: password sniffing.)
9038 (D) ISDs SHOULD NOT use this term because it unnecessarily
9039 duplicates the meaning of a term that is better established. (See:
9040 (usage note under) Green Book.
9043 See: Simple Network Management Protocol.
9045 $ social engineering
9046 (I) A euphemism for non-technical or low-technology means--such as
9047 lies, impersonation, tricks, bribes, blackmail, and threats--used
9048 to attack information systems. (See: masquerade attack.)
9050 (D) ISDs SHOULD NOT use this term because it is vague; instead,
9051 use a term that is specific with regard to the means of attack.
9054 (I) An Internet protocol [R1928] that provides a generalized proxy
9055 server that enables client-server applications--such as TELNET,
9056 FTP, and HTTP; running over either TCP or UDP--to use the services
9059 (C) SOCKS is layered under the application layer and above the
9060 transport layer. When a client inside a firewall wishes to
9061 establish a connection to an object that is reachable only through
9062 the firewall, it uses TCP to connect to the SOCKS server,
9063 negotiates with the server for the authentication method to be
9064 used, authenticates with the chosen method, and then sends a relay
9065 request. The SOCKS server evaluates the request, typically based
9066 on source and destination addresses, and either establishes the
9067 appropriate connection or denies it.
9074 Shirey Informational [Page 162]
9076 RFC 2828 Internet Security Glossary May 2000
9080 (O) The use of software techniques to reduce the radio frequency
9081 information leakage from computer displays and keyboards. [Kuhn]
9085 (I) Computer programs (which are stored in and executed by
9086 computer hardware) and associated data (which also is stored in
9087 the hardware) that may be dynamically written or modified during
9088 execution. (See: firmware, hardware.)
9093 $ source authentication
9094 (D) ISDs SHOULD NOT use this term because it is ambiguous. If the
9095 intent is to authenticate the original creator or packager of data
9096 received, then say "data origin authentication". If the intent is
9097 to authenticate the identity of the sender of data, then say "peer
9098 entity authentication". (See: data origin authentication, peer
9099 entity authentication).
9102 (I) The degree of confidence that can be placed in information
9103 based on the trustworthiness of its sources. (See: integrity.)
9106 See: Security Protocol 3.
9109 See: Security Protocol 4.
9112 (I) (1.) Verb: To indiscriminately send unsolicited, unwanted,
9113 irrelevant, or inappropriate messages, especially commercial
9114 advertising in mass quantities. (2.) Noun: electronic "junk mail".
9117 (D) This term SHOULD NOT be written in upper-case letters, because
9118 SPAM(trademark) is a trademark of Hormel Foods Corporation. Hormel
9119 says, "We do not object to use of this slang term [spam] to
9120 describe [unsolicited commercial email (UCE)], although we do
9121 object to the use of our product image in association with that
9122 term. Also, if the term is to be used, it should be used in all
9123 lower-case letters to distinguish it from our trademark SPAM,
9124 which should be used with all uppercase letters."
9130 Shirey Informational [Page 163]
9132 RFC 2828 Internet Security Glossary May 2000
9135 (C) In sufficient volume, spam can cause denial of service. (See:
9136 flooding.) According to the SPAM Web site, the term was adopted as
9137 a result of the Monty Python skit in which a group of Vikings sang
9138 a chorus of 'SPAM, SPAM, SPAM . . .' in an increasing crescendo,
9139 drowning out other conversation. Hence, the analogy applied
9140 because UCE was drowning out normal discourse on the Internet.
9143 See: software publisher certificate.
9146 See: Security Parameters Index.
9149 (I) A cryptographic key that is divided into two or more separate
9150 data items that individually convey no knowledge of the whole key
9151 that results from combining the items. (See: dual control, split
9155 (I) A security technique in which two or more entities separately
9156 hold data items that individually convey no knowledge of the
9157 information that results from combining the items. (See: dual
9158 control, split key.)
9160 (O) "A condition under which two or more entities separately have
9161 key components which individually convey no knowledge of the
9162 plaintext key which will be produced when the key components are
9163 combined in the cryptographic module." [FP140]
9166 (I) A synonym for "masquerade attack".
9169 (I) A protocol for secure remote login and other secure network
9170 services over an insecure network.
9172 (C) Consists of three major components:
9174 - Transport layer protocol: Provides server authentication,
9175 confidentiality, and integrity. It may optionally also provide
9176 compression. The transport layer will typically be run over a
9177 TCP/IP connection, but might also be used on top of any other
9178 reliable data stream.
9180 - User authentication protocol: Authenticates the client-side
9181 user to the server. It runs over the transport layer protocol.
9186 Shirey Informational [Page 164]
9188 RFC 2828 Internet Security Glossary May 2000
9191 - Connection protocol: Multiplexes the encrypted tunnel into
9192 several logical channels. It runs over the user authentication
9196 See: Secure Sockets Layer, Standard Security Label.
9199 See: system security officer.
9202 (O) MISSI usage: One of two personal identification numbers that
9203 control access to the functions and stored data of a FORTEZZA PC
9204 card. Knowledge of the SSO PIN enables the card user to perform
9205 the FORTEZZA functions intended for use by an end user and also
9206 the functions intended for use by a MISSI certification authority.
9209 $ SSO-PIN ORA (SORA)
9210 (O) MISSI usage: A MISSI organizational RA that operates in a mode
9211 in which the ORA performs all card management functions and,
9212 therefore, requires knowledge of the SSO PIN for an end user's
9215 $ Standards for Interoperable LAN/MAN Security (SILS)
9216 (N) (1.) The IEEE 802.10 standards committee. (2.) A developing
9217 set of IEEE standards, which has eight parts: (a) Model, including
9218 security management, (b) Secure Data Exchange protocol, (c) Key
9219 Management, (d) [has been incorporated in (a)], (e) SDE Over
9220 Ethernet 2.0, (f) SDE Sublayer Management, (g) SDE Security
9221 Labels, and (h) SDE PICS Conformance. Parts b, e, f, g, and h are
9222 incorporated in IEEE Standard 802.10-1998.
9225 (I) (Written "*-property".) See: "confinement property" under
9226 Bell-LaPadula Model.
9229 (C) An attack that penetrates your system where no attack has ever
9233 (I) Methods of hiding the existence of a message or other data.
9234 This is different than cryptography, which hides the meaning of a
9235 message but does not hide the message itself. (See: cryptology.)
9237 (C) An example of a steganographic method is "invisible" ink.
9238 (See: digital watermark.)
9242 Shirey Informational [Page 165]
9244 RFC 2828 Internet Security Glossary May 2000
9248 See: (secondary definition under) covert channel.
9251 (I) An encryption algorithm that breaks plaintext into a stream of
9252 successive bits (or characters) and encrypts the n-th plaintext
9253 bit with the n-th element of a parallel key stream, thus
9254 converting the plaintext bit stream into a ciphertext bit stream.
9255 [Schn] (See: block cipher.)
9257 $ strong authentication
9258 (I) An authentication process that uses cryptography--particularly
9259 public-key certificates--to verify the identity claimed for an
9260 entity. (See: X.509.)
9262 (O) "Authentication by means of cryptographically derived
9263 credentials." [X509]
9266 1. (I) In a computer system: A system entity that causes
9267 information to flow among objects or changes the system state;
9268 technically, a process-domain pair. (See: Bell-LaPadula Model.)
9270 2. (I) Of a certificate: The entity name that is bound to the data
9271 items in a digital certificate, and particularly a name that is
9272 bound to a key value in a public-key certificate.
9275 (N) An OSI term for a system of packet relays and connecting links
9276 that implement the lower three protocol layers of the OSIRM to
9277 provide a communication service that interconnects attached end
9278 systems. Usually the relays operate at OSI layer 3 and are all of
9279 the same type (e.g., all X.25 packet switches, or all interface
9280 units in an IEEE 802.3 LAN). (See: gateway, internet, router.)
9282 $ subordinate certification authority (SCA)
9283 (I) A CA whose public-key certificate is issued by another
9284 (superior) CA. (See: certification hierarchy.)
9286 (O) MISSI usage: The fourth-highest (bottom) level of a MISSI
9287 certification hierarchy; a MISSI CA whose public-key certificate
9288 is signed by a MISSI CA rather than by a MISSI PCA. A MISSI SCA is
9289 the administrative authority for a subunit of an organization,
9290 established when it is desirable to organizationally distribute or
9291 decentralize the CA service. The term refers both to that
9292 authoritative office or role, and to the person who fills that
9298 Shirey Informational [Page 166]
9300 RFC 2828 Internet Security Glossary May 2000
9303 office. A MISSI SCA registers end users and issues their
9304 certificates and may also register ORAs, but may not register
9305 other CAs. An SCA periodically issues a CRL.
9307 $ subordinate distinguished name
9308 (I) An X.500 DN is subordinate to another X.500 DN if it begins
9309 with a set of attributes that is the same as the entire second DN
9310 except for the terminal attribute of the second DN (which is
9311 usually the name of a CA). For example, the DN <C=FooLand, O=Gov,
9312 OU=Treasurer, CN=DukePinchpenny> is subordinate to the DN
9313 <C=FooLand, O=Gov, CN=KingFooCA>.
9316 (I) An encryption operation for which the plaintext input to be
9317 transformed is the ciphertext output of a previous encryption
9321 (I) The ability of a system to remain in operation or existence
9322 despite adverse conditions, including both natural occurrences,
9323 accidental actions, and attacks on the system. (See: availability,
9326 $ symmetric cryptography
9327 (I) A branch of cryptography involving algorithms that use the
9328 same key for two different steps of the algorithm (such as
9329 encryption and decryption, or signature creation and signature
9330 verification). (See: asymmetric cryptography.)
9332 (C) Symmetric cryptography has been used for thousands of years
9333 [Kahn]. A modern example of a symmetric encryption algorithm is
9334 the U.S. Government's Data Encryption Algorithm. (See: DEA, DES.)
9336 (C) Symmetric cryptography is sometimes called "secret-key
9337 cryptography" (versus public-key cryptography) because the
9338 entities that share the key, such as the originator and the
9339 recipient of a message, need to keep the key secret. For example,
9340 when Alice wants to ensure confidentiality for data she sends to
9341 Bob, she encrypts the data with a secret key, and Bob uses the
9342 same key to decrypt. Keeping the shared key secret entails both
9343 cost and risk when the key is distributed to both Alice and Bob.
9344 Thus, symmetric cryptography has a key management disadvantage
9345 compared to asymmetric cryptography.
9348 (I) A cryptographic key that is used in a symmetric cryptographic
9354 Shirey Informational [Page 167]
9356 RFC 2828 Internet Security Glossary May 2000
9360 (I) A denial of service attack that sends a host more TCP SYN
9361 packets (request to synchronize sequence numbers, used when
9362 opening a connection) than the protocol implementation can handle.
9366 (C) In this Glossary, the term is mainly used as an abbreviation
9367 for "automated information system".
9370 (I) An active element of a system--e.g., an automated process, a
9371 subsystem, a person or group of persons--that incorporates a
9372 specific set of capabilities.
9375 (I) The highest security level supported by a system at a
9376 particular time or in a particular environment. (See: system high
9379 $ system high security mode
9380 (I) A mode of operation of an information system, wherein all
9381 users having access to the system possess a security clearance or
9382 authorization, but not necessarily a need-to-know, for all data
9383 handled by the system. (See: mode of operation.)
9385 (C) This mode is defined formally in U.S. Department of Defense
9386 policy regarding system accreditation [DOD2], but the term is
9387 widely used outside the Defense Department and outside the
9391 (I) "The quality that a system has when it can perform its
9392 intended function in a unimpaired manner, free from deliberate or
9393 inadvertent unauthorized manipulation." [NCS04] (See: system
9396 $ system integrity service
9397 (I) A security service that protects system resources in a
9398 verifiable manner against unauthorized or accidental change, loss,
9399 or destruction. (See: system integrity.)
9402 (I) The lowest security level supported by a system at a
9403 particular time or in a particular environment. (See: system
9410 Shirey Informational [Page 168]
9412 RFC 2828 Internet Security Glossary May 2000
9416 (I) Data contained in an information system; or a service provided
9417 by a system; or a system capability, such as processing power or
9418 communication bandwidth; or an item of system equipment (i.e., a
9419 system component--hardware, firmware, software, or documentation);
9420 or a facility that houses system operations and equipment.
9422 $ system security officer (SSO)
9423 (I) A person responsible for enforcement or administration of the
9424 security policy that applies to the system.
9426 $ system verification
9427 See: (secondary definition under) verification.
9431 See: Terminal Access Controller (TAC) Access Control System.
9434 (I) Make an unauthorized modification in a system that alters the
9435 system's functioning in a way that degrades the security services
9436 that the system was intended to provide.
9439 See: trusted computing base.
9442 See: Transmission Control Protocol.
9445 (I) A synonym for "Internet Protocol Suite", in which the
9446 Transmission Control Protocol (TCP) and the Internet Protocol (IP)
9447 are important parts.
9450 See: Trusted Computer System Evaluation Criteria.
9453 (I) A TCP-based, application-layer, Internet Standard protocol
9454 [R0854] for remote login from one host to another.
9457 (O) A nickname for specifications and standards for limiting the
9458 strength of electromagnetic emanations from electrical and
9459 electronic equipment and thus reducing vulnerability to
9460 eavesdropping. This term originated in the U.S. Department of
9461 Defense. [Army, Kuhn, Russ] (See: emanation security, soft
9466 Shirey Informational [Page 169]
9468 RFC 2828 Internet Security Glossary May 2000
9471 (D) ISDs SHOULD NOT use this term as a synonym for
9472 "electromagnetic emanations security".
9474 $ Terminal Access Controller (TAC) Access Control System (TACACS)
9475 (I) A UDP-based authentication and access control protocol [R1492]
9476 in which a network access server receives an identifier and
9477 password from a remote terminal and passes them to a separate
9478 authentication server for verification.
9480 (C) TACACS was developed for ARPANET and has evolved for use in
9481 commercial equipment. TACs were a type of network access server
9482 computer used to connect terminals to the early Internet, usually
9483 using dial-up modem connections. TACACS used centralized
9484 authentication servers and served not only network access servers
9485 like TACs but also routers and other networked computing devices.
9486 TACs are no longer in use, but TACACS+ is. [R1983]
9488 - "XTACACS": The name of Cisco Corporation's implementation,
9489 which enhances and extends the original TACACS.
9491 - "TACACS+": A TCP-based protocol that improves on TACACS and
9492 XTACACS by separating the functions of authentication,
9493 authorization, and accounting and by encrypting all traffic
9494 between the network access server and authentication server. It
9495 is extensible to allow any authentication mechanism to be used
9496 with TACACS+ clients.
9499 See: The Exponential Encryption System.
9501 $ The Exponential Encryption System (TESS)
9502 (I) A system of separate but cooperating cryptographic mechanisms
9503 and functions for the secure authenticated exchange of
9504 cryptographic keys, the generation of digital signatures, and the
9505 distribution of public keys. TESS employs asymmetric cryptography,
9506 based on discrete exponentiation, and a structure of self-
9507 certified public keys. [R1824]
9510 (I) A potential for violation of security, which exists when there
9511 is a circumstance, capability, action, or event that could breach
9512 security and cause harm. (See: attack, threat action, threat
9515 (C) That is, a threat is a possible danger that might exploit a
9516 vulnerability. A threat can be either "intentional" (i.e.,
9517 intelligent; e.g., an individual cracker or a criminal
9522 Shirey Informational [Page 170]
9524 RFC 2828 Internet Security Glossary May 2000
9527 organization) or "accidental" (e.g., the possibility of a computer
9528 malfunctioning, or the possibility of an "act of God" such as an
9529 earthquake, a fire, or a tornado).
9531 (C) In some contexts, such as the following, the term is used
9532 narrowly to refer only to intelligent threats:
9534 (N) U. S. Government usage: The technical and operational
9535 capability of a hostile entity to detect, exploit, or subvert
9536 friendly information systems and the demonstrated, presumed, or
9537 inferred intent of that entity to conduct such activity.
9540 (I) An assault on system security. (See: attack, threat, threat
9543 (C) A complete security architecture deals with both intentional
9544 acts (i.e. attacks) and accidental events [FIPS31]. Various kinds
9545 of threat actions are defined as subentries under "threat
9549 (I) An analysis of the probability of occurrences and consequences
9550 of damaging actions to a system.
9552 $ threat consequence
9553 (I) A security violation that results from a threat action.
9554 Includes disclosure, deception, disruption, and usurpation. (See:
9555 attack, threat, threat action.)
9557 (C) The following subentries describe four kinds of threat
9558 consequences, and also list and describe the kinds of threat
9559 actions that cause each consequence. Threat actions that are
9560 accidental events are marked by "*".
9562 1. "(Unauthorized) Disclosure" (a threat consequence): A
9563 circumstance or event whereby an entity gains access to data
9564 for which the entity is not authorized. (See: data
9565 confidentiality.) The following threat actions can cause
9566 unauthorized disclosure:
9568 A. "Exposure": A threat action whereby sensitive data is
9569 directly released to an unauthorized entity. This includes:
9571 a. "Deliberate Exposure": Intentional release of sensitive
9572 data to an unauthorized entity.
9578 Shirey Informational [Page 171]
9580 RFC 2828 Internet Security Glossary May 2000
9583 b. "Scavenging": Searching through data residue in a system
9584 to gain unauthorized knowledge of sensitive data.
9586 c* "Human error": Human action or inaction that
9587 unintentionally results in an entity gaining unauthorized
9588 knowledge of sensitive data.
9590 d* "Hardware/software error". System failure that results in
9591 an entity gaining unauthorized knowledge of sensitive
9594 B. "Interception": A threat action whereby an unauthorized
9595 entity directly accesses sensitive data traveling between
9596 authorized sources and destinations. This includes:
9598 a. "Theft": Gaining access to sensitive data by stealing a
9599 shipment of a physical medium, such as a magnetic tape or
9600 disk, that holds the data.
9602 b. "Wiretapping (passive)": Monitoring and recording data
9603 that is flowing between two points in a communication
9604 system. (See: wiretapping.)
9606 c. "Emanations analysis": Gaining direct knowledge of
9607 communicated data by monitoring and resolving a signal
9608 that is emitted by a system and that contains the data
9609 but is not intended to communicate the data. (See:
9612 C. "Inference": A threat action whereby an unauthorized entity
9613 indirectly accesses sensitive data (but not necessarily the
9614 data contained in the communication) by reasoning from
9615 characteristics or byproducts of communications. This
9618 a. Traffic analysis: Gaining knowledge of data by observing
9619 the characteristics of communications that carry the
9620 data. (See: (main Glossary entry for) traffic analysis.)
9622 b. "Signals analysis": Gaining indirect knowledge of
9623 communicated data by monitoring and analyzing a signal
9624 that is emitted by a system and that contains the data
9625 but is not intended to communicate the data. (See:
9628 D. "Intrusion": A threat action whereby an unauthorized entity
9629 gains access to sensitive data by circumventing a system's
9630 security protections. This includes:
9634 Shirey Informational [Page 172]
9636 RFC 2828 Internet Security Glossary May 2000
9639 a. "Trespass": Gaining unauthorized physical access to
9640 sensitive data by circumventing a system's protections.
9642 b. "Penetration": Gaining unauthorized logical access to
9643 sensitive data by circumventing a system's protections.
9645 c. "Reverse engineering": Acquiring sensitive data by
9646 disassembling and analyzing the design of a system
9649 d. Cryptanalysis: Transforming encrypted data into plaintext
9650 without having prior knowledge of encryption parameters
9651 or processes. (See: (main Glossary entry for)
9654 2. "Deception" (a threat consequence): A circumstance or event
9655 that may result in an authorized entity receiving false data
9656 and believing it to be true. The following threat actions can
9659 A. "Masquerade": A threat action whereby an unauthorized entity
9660 gains access to a system or performs a malicious act by
9661 posing as an authorized entity. (See: (main Glossary entry
9662 for) masquerade attack.)
9664 a. "Spoof": Attempt by an unauthorized entity to gain access
9665 to a system by posing as an authorized user.
9667 b. "Malicious logic": In context of masquerade, any
9668 hardware, firmware, or software (e.g., Trojan horse) that
9669 appears to perform a useful or desirable function, but
9670 actually gains unauthorized access to system resources or
9671 tricks a user into executing other malicious logic. (See:
9672 (main Glossary entry for) malicious logic.)
9674 B. "Falsification": A threat action whereby false data deceives
9675 an authorized entity. (See: active wiretapping.)
9677 a. "Substitution": Altering or replacing valid data with
9678 false data that serves to deceive an authorized entity.
9680 b. "Insertion": Introducing false data that serves to
9681 deceive an authorized entity.
9683 C. "Repudiation": A threat action whereby an entity deceives
9684 another by falsely denying responsibility for an act. (See:
9685 non-repudiation service, (main Glossary entry for)
9690 Shirey Informational [Page 173]
9692 RFC 2828 Internet Security Glossary May 2000
9695 a. "False denial of origin": Action whereby the originator
9696 of data denies responsibility for its generation.
9698 b. "False denial of receipt": Action whereby the recipient
9699 of data denies receiving and possessing the data.
9701 3. "Disruption" (a threat consequence): A circumstance or event
9702 that interrupts or prevents the correct operation of system
9703 services and functions. (See: denial of service.) The following
9704 threat actions can cause disruption:
9706 A. "Incapacitation": A threat action that prevents or
9707 interrupts system operation by disabling a system component.
9709 a. "Malicious logic": In context of incapacitation, any
9710 hardware, firmware, or software (e.g., logic bomb)
9711 intentionally introduced into a system to destroy system
9712 functions or resources. (See: (main Glossary entry for)
9715 b. "Physical destruction": Deliberate destruction of a
9716 system component to interrupt or prevent system
9719 c* "Human error": Action or inaction that unintentionally
9720 disables a system component.
9722 d* "Hardware or software error": Error that causes failure
9723 of a system component and leads to disruption of system
9726 e* "Natural disaster": Any "act of God" (e.g., fire, flood,
9727 earthquake, lightning, or wind) that disables a system
9728 component. [FP031 section 2]
9730 B. "Corruption": A threat action that undesirably alters system
9731 operation by adversely modifying system functions or data.
9733 a. "Tamper": In context of corruption, deliberate alteration
9734 of a system's logic, data, or control information to
9735 interrupt or prevent correct operation of system
9738 b. "Malicious logic": In context of corruption, any
9739 hardware, firmware, or software (e.g., a computer virus)
9740 intentionally introduced into a system to modify system
9741 functions or data. (See: (main Glossary entry for)
9746 Shirey Informational [Page 174]
9748 RFC 2828 Internet Security Glossary May 2000
9751 c* "Human error": Human action or inaction that
9752 unintentionally results in the alteration of system
9755 d* "Hardware or software error": Error that results in the
9756 alteration of system functions or data.
9758 e* "Natural disaster": Any "act of God" (e.g., power surge
9759 caused by lightning) that alters system functions or
9760 data. [FP031 section 2]
9762 C. "Obstruction": A threat action that interrupts delivery of
9763 system services by hindering system operations.
9765 a. "Interference": Disruption of system operations by
9766 blocking communications or user data or control
9769 b. "Overload": Hindrance of system operation by placing
9770 excess burden on the performance capabilities of a system
9771 component. (See: flooding.)
9773 4. "Usurpation" (a threat consequence): A circumstance or event
9774 that results in control of system services or functions by an
9775 unauthorized entity. The following threat actions can cause
9778 A. "Misappropriation": A threat action whereby an entity
9779 assumes unauthorized logical or physical control of a system
9782 a. "Theft of service": Unauthorized use of service by an
9785 b. "Theft of functionality": Unauthorized acquisition of
9786 actual hardware, software, or firmware of a system
9789 c. "Theft of data": Unauthorized acquisition and use of
9792 B. "Misuse": A threat action that causes a system component to
9793 perform a function or service that is detrimental to system
9796 a. "Tamper": In context of misuse, deliberate alteration of
9797 a system's logic, data, or control information to cause
9798 the system to perform unauthorized functions or services.
9802 Shirey Informational [Page 175]
9804 RFC 2828 Internet Security Glossary May 2000
9807 b. "Malicious logic": In context of misuse, any hardware,
9808 software, or firmware intentionally introduced into a
9809 system to perform or control execution of an unauthorized
9810 function or service.
9812 c. "Violation of permissions": Action by an entity that
9813 exceeds the entity's system privileges by executing an
9814 unauthorized function.
9817 (I) A pattern of curves formed by the ridges on the tip of a
9818 thumb. (See: biometric authentication, fingerprint.)
9820 (D) ISDs SHOULD NOT use this term as a synonym for "hash result"
9821 because that meaning mixes concepts in a potentially misleading
9825 (I) A synonym for "capability". (See: Kerberos.)
9827 (C) A ticket is usually granted by a centralized access control
9828 server (ticket-granting agent) to authorize access to a system
9829 resource for a limited time. Tickets have been implemented with
9830 symmetric cryptography, but can also be implemented as attribute
9831 certificates using asymmetric cryptography.
9834 See: (secondary definition under) covert channel.
9837 See: Transport Layer Security. (See: TLSP.)
9840 See: Transport Layer Security Protocol. (See: TLS.)
9843 1. (I) General usage: An object that is used to control access and
9844 is passed between cooperating entities in a protocol that
9845 synchronizes use of a shared resource. Usually, the entity that
9846 currently holds the token has exclusive access to the resource.
9848 2. (I) Authentication usage: A data object or a portable, user-
9849 controlled, physical device used to verify an identity in an
9850 authentication process. (See: authentication information, dongle.)
9852 3. (I) Cryptographic usage: See: cryptographic token.
9858 Shirey Informational [Page 176]
9860 RFC 2828 Internet Security Glossary May 2000
9863 4. (O) SET usage: "A portable device [e.g., smart card or PCMCIA
9864 card] specifically designed to store cryptographic information and
9865 possibly perform cryptographic functions in a secure manner."
9869 (I) A token management operation that stores sufficient
9870 information in a database (e.g., in a CAW) to recreate or restore
9871 a security token (e.g., a smart card) if it is lost or damaged.
9874 (I) A token management operation that copies all the personality
9875 information from one security token to another. However, unlike in
9876 a token restore operation, the second token is initialized with
9877 its own, different local security values such as PINs and storage
9881 (I) The process of initializing security tokens (e.g., see: smart
9882 card), loading data into the tokens, and controlling the tokens
9883 during their life cycle. May include performing key management and
9884 certificate management functions; generating and installing PINs;
9885 loading user personality data; performing card backup, card copy,
9886 and card restore operations; and updating firmware.
9889 (I) A token management operation that loads a security token with
9890 data for the purpose of recreating (duplicating) the contents
9891 previously held by that or another token.
9894 (I) A cryptography key used to protect data that is stored on a
9898 (I) A CA that is the highest level (i.e., is the most trusted CA)
9899 in a certification hierarchy. (See: root.)
9901 $ top-level specification
9902 (I) "A non-procedural description of system behavior at the most
9903 abstract level; typically a functional specification that omits
9904 all implementation details." [NCS04] (See: (discussion under)
9907 (C) A top-level specification may be descriptive or formal:
9914 Shirey Informational [Page 177]
9916 RFC 2828 Internet Security Glossary May 2000
9919 - "Descriptive top-level specification": One that is written in a
9920 natural language like English or an informal design notation.
9922 - "Formal top-level specification": One that is written in a
9923 formal mathematical language to enable theorems to be proven that
9924 show that the specification correctly implements a set of formal
9925 requirements or a formal security model. (See: correctness proof.)
9928 (I) Inference of information from observable characteristics of
9929 data flow(s), even when the data is encrypted or otherwise not
9930 directly available. Such characteristics include the identities
9931 and locations of the source(s) and destination(s), and the
9932 presence, amount, frequency, and duration of occurrence. (See:
9935 (O) "The inference of information from observation of traffic
9936 flows (presence, absence, amount, direction, and frequency)."
9939 $ traffic flow confidentiality
9940 (I) A data confidentiality service to protect against traffic
9943 (O) "A confidentiality service to protect against traffic
9944 analysis." [I7498 Part 2]
9947 (I) "The generation of spurious instances of communication,
9948 spurious data units, and/or spurious data within data units."
9951 $ tranquillity property
9952 See: (secondary definition under) Bell-LaPadula Model.
9954 $ Transmission Control Protocol (TCP)
9955 (I) An Internet Standard protocol [R0793] that reliably delivers a
9956 sequence of datagrams (discrete sets of bits) from one computer to
9957 another in a computer network. (See: TCP/IP.)
9959 (C) TCP is designed to fit into a layered hierarchy of protocols
9960 that support internetwork applications. TCP assumes it can obtain
9961 a simple, potentially unreliable datagram service (such as the
9962 Internet Protocol) from the lower-layer protocols.
9964 $ Transport Layer Security (TLS)
9965 (I) TLS Version 1.0 is an Internet protocol [R2246] based-on and
9966 very similar to SSL Version 3.0. (See: TLSP.)
9970 Shirey Informational [Page 178]
9972 RFC 2828 Internet Security Glossary May 2000
9975 (C) The TLS protocol is misnamed, because it operates well above
9976 the transport layer (OSI layer 4).
9978 $ Transport Layer Security Protocol (TLSP)
9979 (I) An end-to-end encryption protocol(ISO Standard 10736) that
9980 provides security services at the bottom of OSI layer 4, i.e.,
9981 directly above layer 3. (See: TLS.)
9983 (C) TLSP evolved directly from the SP4 protocol of SDNS.
9985 $ transport mode vs. tunnel mode
9986 (I) IPsec usage: Two ways to apply IPsec protocols (AH and ESP) to
9987 protect communications:
9989 - "Transport mode": The protection applies to (i.e., the IPsec
9990 protocol encapsulates) the packets of upper-layer protocols,
9991 the ones that are carried above IP.
9993 - "Tunnel mode": The protection applies to (i.e., the IPsec
9994 protocol encapsulates) IP packets.
9996 (C) A transport mode security association is always between two
9997 hosts. In a tunnel mode security association, each end may be
9998 either a host or a gateway. Whenever either end of an IPsec
9999 security association is a security gateway, the association is
10000 required to be in tunnel mode.
10003 (I) A hidden computer flaw known to an intruder, or a hidden
10004 computer mechanism (usually software) installed by an intruder,
10005 who can activate the trap door to gain access to the computer
10006 without being blocked by security services or mechanisms. (See:
10007 back door, Trojan horse.)
10010 (I) A block cipher, based on DES, that transforms each 64-bit
10011 plaintext block by applying the Data Encryption Algorithm three
10012 successive times, using either two or three different keys, for an
10013 effective key length of 112 or 168 bits. [A9052] (See: DES.)
10015 (C) IPsec usage: The algorithm variation proposed for ESP uses a
10016 168-bit key, consisting of three independent 56-bit quantities
10017 used by the Data Encryption Algorithm, and a 64-bit initialization
10018 value. Each datagram contains an IV to ensure that each received
10019 datagram can be decrypted even when other datagrams are dropped or
10020 a sequence of datagrams is reordered in transit. [R1851]
10026 Shirey Informational [Page 179]
10028 RFC 2828 Internet Security Glossary May 2000
10032 (I) S/MIME usage: Data that has been signed with a digital
10033 signature, and then encrypted, and then signed again. [R2634]
10036 (I) A computer program that appears to have a useful function, but
10037 also has a hidden and potentially malicious function that evades
10038 security mechanisms, sometimes by exploiting legitimate
10039 authorizations of a system entity that invokes the program.
10042 1. (I) Information system usage: The extent to which someone who
10043 relies on a system can have confidence that the system meets its
10044 specifications, i.e., that the system does what it claims to do
10045 and does not perform unwanted functions. (See: trust level.)
10047 (C) "trusted vs. trustworthy": In discussing a system or system
10048 process or object, this Glossary (and industry usage) prefers the
10049 term "trusted" to describe a system that operates as expected,
10050 according to design and policy. When the trust can also be
10051 guaranteed in some convincing way, such as through formal analysis
10052 or code review, the system is termed "trustworthy"; this differs
10053 from the ABA Guidelines definition (see: trustworthy system).
10055 2. (I) PKI usage: A relationship between a certificate user and a
10056 CA in which the user acts according to the assumption that the CA
10057 creates only valid digital certificates.
10059 (O) "Generally, an entity can be said to 'trust' a second entity
10060 when it (the first entity) makes the assumption that the second
10061 entity will behave exactly as the first entity expects. This trust
10062 may apply only for some specific function. The key role of trust
10063 in [X.509] is to describe the relationship between an entity and a
10064 [certification] authority; an entity shall be certain that it can
10065 trust the certification authority to create only valid and
10066 reliable certificates." [X509]
10069 (D) ISDs SHOULD NOT use this term as a synonym for "certification
10070 path" because it mixes concepts in a potentially misleading way.
10074 (I) A non-hierarchical PKI in which each certificate user has a
10075 local file (which is used by application software) of public-key
10076 certificates that the user trusts as starting points (i.e., roots)
10077 for certification paths. (See: hierarchical PKI, mesh PKI, root,
10082 Shirey Informational [Page 180]
10084 RFC 2828 Internet Security Glossary May 2000
10087 (C) For example, popular browsers are distributed with an initial
10088 file of trusted certificates, which often are self-signed
10089 certificates. Users can add certificates to the file or delete
10090 from it. The file may be directly managed by the user, or the
10091 user's organization may manage it from a centralized server.
10094 (D) ISDs SHOULD NOT use this term as a synonym for "certification
10095 hierarchy" because this term mixes concepts (see: trust) in a
10096 potentially misleading way and duplicates the meaning of another,
10097 standardized term. (See: trust, web of trust.)
10100 (I) A characterization of a standard of security protection to be
10101 met by a computer system.
10103 (C) The TCSEC defines eight trust levels. From the lowest to the
10104 highest, they are D, C1, C2, B1, B2, B3, and A1. A trust level is
10105 based not only on the presence of security mechanisms but also on
10106 the use of systems engineering discipline to properly structure
10107 the system and implementation analysis to ensure that the system
10108 provides an appropriate degree of trust.
10111 See: (discussion under) trust.
10113 $ trusted certificate
10114 (I) A certificate upon which a certificate user relies as being
10115 valid without the need for validation testing; especially a
10116 public-key certificate that is used to provide the first public
10117 key in a certification path. (See: certification path, root
10118 certificate, validation.)
10120 (C) A trusted public-key certificate might be (a) the root
10121 certificate in a hierarchical PKI, (b) the certificate of the CA
10122 that issued the user's own certificate in a mesh PKI, or (c)
10123 any certificate accepted by the user in a trust-file PKI.
10125 $ trusted computer system
10126 (I) Multilevel security usage: "A system that employs sufficient
10127 hardware and software assurance measures to allow its use for
10128 simultaneous processing of a range of sensitive or classified
10129 information." [NCS04] (See: (discussion under) trust.)
10131 $ Trusted Computer System Evaluation Criteria (TCSEC)
10132 (N) A standard for evaluating the security provided by operating
10133 systems [CSC001, DOD1]. Informally called the "Orange Book"
10138 Shirey Informational [Page 181]
10140 RFC 2828 Internet Security Glossary May 2000
10143 because of the color of its cover; first document in the Rainbow
10144 Series. (See: Common Criteria, (usage note under) Green Book,
10145 Orange Book, trust level.)
10147 $ trusted computing base (TCB)
10148 (I) "The totality of protection mechanisms within a computer
10149 system, including hardware, firmware, and software, the
10150 combination of which is responsible for enforcing a security
10151 policy." [NCS04] (See: (discussion of "trusted" under) trust.)
10153 $ trusted distribution
10154 (I) "A trusted method for distributing the TCB hardware, software,
10155 and firmware components, both originals and updates, that provides
10156 methods for protecting the TCB from modification during
10157 distribution and for detection of any changes to the TCB that may
10161 (I) A public key upon which a user relies; especially a public key
10162 that can be used as the first public key in a certification path.
10163 (See: certification path, root key, validation.)
10165 (C) A trusted public key might be (a) the root key in a
10166 hierarchical PKI, (b) the key of the CA that issued the user's own
10167 certificate in a mesh PKI, or (c) any key accepted by the user in
10171 (I) COMPUSEC usage: A mechanism by which a computer system user
10172 can communicate directly and reliably with the trusted computing
10173 base (TCB) and that can only be activated by the user or the TCB
10174 and cannot be imitated by untrusted software within the computer.
10177 (I) COMSEC usage: A mechanism by which a person or process can
10178 communicate directly with a cryptographic module and that can only
10179 be activated by the person, process, or module, and cannot be
10180 imitated by untrusted software within the module. [FP140]
10183 (I) A system process that has privileges that enable it to affect
10184 the state of system security and that can, therefore, through
10185 incorrect or malicious execution, violate the system's security
10186 policy. (See: privileged process, (discussion of "trusted" under)
10194 Shirey Informational [Page 182]
10196 RFC 2828 Internet Security Glossary May 2000
10199 $ trusted subnetwork
10200 (I) A subnetwork containing hosts and routers that trust each
10201 other not to engage in active or passive attacks. (There also is
10202 an assumption that the underlying communication channels--e.g.,
10203 telephone lines, or a LAN--are protected from attack by some
10207 See: (discussion under) trust, trusted computer system,
10208 trustworthy system.
10210 $ Trusted Systems Interoperability Group (TSIG)
10211 (N) A forum of computer vendors, system integrators, and users
10212 devoted to promoting interoperability of trusted computer systems.
10213 TSIG meetings are open to all persons who are working in the
10216 $ trustworthy system
10217 (O) ABA usage: "Computer hardware, software, and procedures that:
10218 (a) are reasonably secure from intrusion and misuse; (b) provide a
10219 reasonably reliable level of availability, reliability, and
10220 correct operation; (c) are reasonably suited to performing their
10221 intended functions; and (d) adhere to generally accepted security
10222 principles." [ABA] This differs somewhat from other industry
10223 usage. (See: (discussion of "trusted vs. trustworthy" under)
10227 See: Trusted System Interoperability Group.
10230 (I) A communication channel created in a computer network by
10231 encapsulating (carrying, layering) a communication protocol's data
10232 packets in (on top of) a second protocol that normally would be
10233 carried above, or at the same layer as, the first one. (See: L2TP,
10236 (C) Tunneling can involve almost any OSI or TCP/IP protocol
10237 layers; for example, a TCP connection between two hosts could
10238 conceivably be tunneled through email messages across the
10239 Internet. Most often, a tunnel is a logical point-to-point link--
10240 i.e., an OSI layer 2 connection--created by encapsulating the
10241 layer 2 protocol in a transport protocol (such as TCP), in a
10242 network or internetwork layer protocol (such as IP), or in another
10243 link layer protocol. Often, encapsulation is accomplished with an
10244 extra, intermediate protocol, i.e., a tunneling protocol (such as
10245 L2TP) that is layered between the tunneled layer 2 protocol and
10246 the encapsulating protocol.
10250 Shirey Informational [Page 183]
10252 RFC 2828 Internet Security Glossary May 2000
10255 (C) Tunneling can move data between computers that use a protocol
10256 not supported by the network connecting them. Tunneling also can
10257 enable a computer network to use the services of a second network
10258 as though the second network were a set of point-to-point links
10259 between the first network's nodes. (See: virtual private network.)
10261 (O) SET usage: The name of a SET private extension that indicates
10262 whether the CA or the payment gateway supports passing encrypted
10263 messages to the cardholder through the merchant. If so, the
10264 extension lists OIDs of symmetric encryption algorithms that are
10268 (I) IPsec usage: See: transport mode vs. tunnel mode.
10270 $ two-person control
10271 (I) The close surveillance and control of a system, process, or
10272 materials (especially with regard to cryptography) at all times by
10273 a minimum of two appropriately authorized persons, each capable of
10274 detecting incorrect and unauthorized procedures with respect to
10275 the tasks to be performed and each familiar with established
10276 security requirements. (See: dual control, no-lone zone.)
10278 $ Type I cryptography
10279 (O) A cryptographic algorithm or device approved by NSA for
10280 protecting classified information.
10282 $ Type II cryptography
10283 (O) A cryptographic algorithm or device approved by NSA for
10284 protecting sensitive unclassified information (as specified in
10285 section 2315 of Title 10 United States Code, or section 3502(2) of
10286 Title 44, United States Code.)
10288 $ Type III cryptography
10289 (O) A cryptographic algorithm or device approved as a Federal
10290 Information Processing Standard.
10293 See: User Datagram Protocol.
10296 (I) Not classified.
10306 Shirey Informational [Page 184]
10308 RFC 2828 Internet Security Glossary May 2000
10312 (I) Cryptographic usage: The property of a cryptographic data
10313 structure (i.e., a data structure that is defined using one or
10314 more cryptographic functions) that makes it computationally
10315 infeasible to construct (i.e., compute) an unauthorized but
10316 correct value of the structure without having knowledge of one of
10317 more keys. (E.g., see: digital certificate.)
10319 (C) This definition is narrower than general English usage, where
10320 "unforgeable" means unable to be fraudulently created or
10321 duplicated. In that broader sense, anyone can forge a digital
10322 certificate containing any set of data items whatsoever by
10323 generating the to-be-signed certificate and signing it with any
10324 private key whatsoever. But for PKI purposes, the forged data
10325 structure is invalid if it is not signed with the true private key
10326 of the claimed issuer; thus, the forgery will be detected when a
10327 certificate user uses the true public key of the claimed issuer to
10328 verify the signature.
10330 $ uniform resource identifier (URI)
10331 (I) A type of formatted identifier that encapsulates the name of
10332 an Internet object, and labels it with an identification of the
10333 name space, thus producing a member of the universal set of names
10334 in registered name spaces and of addresses referring to registered
10335 protocols or name spaces. [R1630]
10337 (C) URIs are used in HTML to identify the target of hyperlinks. In
10338 common practice, URIs include uniform resource locators [R2368]
10339 and relative URLs, and may be URNs. [R1808]
10341 $ uniform resource locator (URL)
10342 (I) A type of formatted identifier that describes the access
10343 method and location of an information resource object on the
10346 (C) A URL is a URI that provides explicit instructions on how to
10347 access the named object. For example,
10348 "ftp://bbnarchive.bbn.com/foo/bar/picture/cambridge.zip" is a URL.
10349 The part before the colon specifies the access scheme or protocol,
10350 and the part after the colon is interpreted according to that
10351 access method. Usually, two slashes after the colon indicate the
10352 host name of a server (written as a domain name). In an FTP or
10353 HTTP URL, the host name is followed by the path name of a file on
10354 the server. The last (optional) part of a URL may be either a
10355 fragment identifier that indicates a position in the file, or a
10362 Shirey Informational [Page 185]
10364 RFC 2828 Internet Security Glossary May 2000
10367 $ uniform resource name (URN)
10368 (I) A URI that has an institutional commitment to persistence and
10371 $ untrusted process
10372 (I) A system process that is not able to affect the state of
10373 system security through incorrect or malicious operation, usually
10374 because its operation is confined by a security kernel. (See:
10381 See: certificate update and key update.
10384 See: uniform resource identifier.
10387 See: uniform resource locator.
10390 See: uniform resource name.
10393 (I) A person, organization entity, or automated process that
10394 accesses a system, whether authorized to do so or not. (See:
10397 (C) Any ISD that uses this term SHOULD provide an explicit
10398 definition, because this term is used in many ways and can easily
10401 $ User Datagram Protocol (UDP)
10402 (I) An Internet Standard protocol [R0768] that provides a datagram
10403 mode of packet-switched computer communication in an internetwork.
10405 (C) UDP is a transport layer protocol, and it assumes that IP is
10406 the underlying protocol. UDP enables application programs to send
10407 transaction-oriented data to other programs with minimal protocol
10408 mechanism. UDP does not provide reliable delivery, flow control,
10409 sequencing, or other end-to-end services that TCP provides.
10412 (I) A character string or symbol that is used in a system to
10413 uniquely name a specific user or group of users.
10418 Shirey Informational [Page 186]
10420 RFC 2828 Internet Security Glossary May 2000
10423 (C) Often verified by a password in an authentication process.
10426 (O) MISSI usage: One of two personal identification numbers that
10427 control access to the functions and stored data of a FORTEZZA PC
10428 card. Knowledge of the user PIN enables the card user to perform
10429 the FORTEZZA functions that are intended for use by an end user.
10432 $ user-PIN ORA (UORA)
10433 (O) A MISSI organizational RA that operates in a mode in which the
10434 ORA performs only the subset of card management functions that are
10435 possible with knowledge of the user PIN for a FORTEZZA PC card.
10436 (See: no-PIN ORA, SSO-PIN ORA.)
10439 See: (secondary definition under) threat consequence.
10442 (N) The ASN.1 data type "UTCTime" contains a calendar date
10443 (YYMMDD) and a time to a precision of either one minute (HHMM) or
10444 one second (HHMMSS), where the time is either (a) Coordinated
10445 Universal Time or (b) the local time followed by an offset that
10446 enables Coordinated Universal Time to be calculated. Note: UTCTime
10447 has the Year 2000 problem. (See: Coordinated Universal Time,
10451 (C) Ambiguously refers to either an X.509 public-key certificate
10452 in its version 1 format, or an X.509 attribute certificate in its
10453 version 1 format. However, many people who use this term are not
10454 aware that X.509 specifies attribute certificates that do not
10455 contain a public key. Therefore, ISDs MAY use this term as an
10456 abbreviation for "version 1 X.509 public-key certificate", but
10457 only after using the full term at the first instance.
10459 (D) ISDs SHOULD NOT use this term as an abbreviation for "version
10460 1 X.509 attribute certificate".
10463 (I) An abbreviation for "X.509 CRL in version 1 format".
10465 (C) ISDs should use this abbreviation only after using the full
10466 term at its first occurrence and defining the abbreviation.
10469 (I) An abbreviation for "X.509 public-key certificate in version 2
10474 Shirey Informational [Page 187]
10476 RFC 2828 Internet Security Glossary May 2000
10479 (C) ISDs should use this abbreviation only after using the full
10480 term at its first occurrence and defining the abbreviation.
10483 (I) An abbreviation for "X.509 CRL in version 2 format".
10485 (C) ISDs should use this abbreviation only after using the full
10486 term at its first occurrence and defining the abbreviation.
10489 (I) An abbreviation for "X.509 public-key certificate in version 3
10492 (C) ISDs should use this abbreviation only after using the full
10493 term at its first occurrence and defining the abbreviation.
10495 $ valid certificate
10496 (I) A digital certificate for which the binding of the data items
10497 can be trusted; one that can be validated successfully. (See:
10498 validate vs. verify.)
10501 (D) ISDs SHOULD NOT use this term; instead, use "authentic
10502 signature". This Glossary recommends saying "validate the
10503 certificate" and "verify the signature"; therefore, it would be
10504 inconsistent to say that a signature is "valid". (See: validate
10507 $ validate vs. verify
10508 (C) The PKI community uses words inconsistently when describing
10509 what a certificate user does to make certain that a digital
10510 certificate can be trusted. Usually, we say "verify the signature"
10511 but say "validate the certificate"; i.e., we "verify" atomic
10512 truths but "validate" data structures, relationships, and systems
10513 that are composed of or depend on verified items. Too often,
10514 however, verify and validate are used interchangeably.
10516 ISDs SHOULD comply with the following two rules to ensure
10517 consistency and to align Internet security terminology with
10520 - Rule 1: Use "validate" when referring to a process intended to
10521 establish the soundness or correctness of a construct. (E.g.,
10522 see: certificate validation.)
10524 - Rule 2: Use "verify" when referring to a process intended to
10525 test or prove the truth or accuracy of a fact or value. (E.g.,
10526 see: authenticate.)
10530 Shirey Informational [Page 188]
10532 RFC 2828 Internet Security Glossary May 2000
10535 The rationale for Rule 1 is that "valid" derives from a word that
10536 means "strong" in Latin. Thus, to validate means to make sure that
10537 a construction is sound. A certificate user validates a public-key
10538 certificate to establish trust in the binding that the certificate
10539 asserts between an identity and a key. (To validate can also mean
10540 to officially approve something; e.g., NIST validates
10541 cryptographic modules for conformance with FIPS PUB 140-1.)
10543 The rationale for Rule 2 is that "verify" derives from a word that
10544 means "true" in Latin. Thus, to verify means to prove the truth of
10545 an assertion by examining evidence or performing tests. To verify
10546 an identity, an authentication process examines identification
10547 information that is presented or generated. To validate a
10548 certificate, a certificate user verifies the digital signature on
10549 the certificate by performing calculations; verifies that the
10550 current time is within the certificate's validity period; and may
10551 need to validate a certification path involving additional
10555 See: validate vs. verify.
10558 (I) A data item in a digital certificate that specifies the time
10559 period for which the binding between data items (especially
10560 between the subject name and the public key value in a public-key
10561 certificate) is valid, except if the certificate appears on a CRL
10562 or the key appears on a CKL.
10564 $ value-added network (VAN)
10565 (I) A computer network or subnetwork (which is usually a
10566 commercial enterprise) that transmits, receives, and stores EDI
10567 transactions on behalf of its customers.
10569 (C) A VAN may also provide additional services, ranging from EDI
10570 format translation, to EDI-to-FAX conversion, to integrated
10574 See: value-added network.
10577 1. System verification: The process of comparing two levels of
10578 system specification for proper correspondence, such as comparing
10579 a security policy with a top-level specification, a top-level
10580 specification with source code, or source code with object code.
10586 Shirey Informational [Page 189]
10588 RFC 2828 Internet Security Glossary May 2000
10591 2. Identification verification: Presenting information to
10592 establish the truth of a claimed identity.
10595 See: validate vs. verify.
10598 See: security violation.
10600 $ virtual private network (VPN)
10601 (I) A restricted-use, logical (i.e., artificial or simulated)
10602 computer network that is constructed from the system resources of
10603 a relatively public, physical (i.e., real) network (such as the
10604 Internet), often by using encryption (located at hosts or
10605 gateways), and often by tunneling links of the virtual network
10606 across the real network.
10608 (C) For example, if a corporation has LANs at several different
10609 sites, each connected to the Internet by a firewall, the
10610 corporation could create a VPN by (a) using encrypted tunnels to
10611 connect from firewall to firewall across the Internet and (b) not
10612 allowing any other traffic through the firewalls. A VPN is
10613 generally less expensive to build and operate than a dedicated
10614 real network, because the virtual network shares the cost of
10615 system resources with other users of the real network.
10618 (I) A hidden, self-replicating section of computer software,
10619 usually malicious logic, that propagates by infecting--i.e.,
10620 inserting a copy of itself into and becoming part of--another
10621 program. A virus cannot run by itself; it requires that its host
10622 program be run to make the virus active.
10625 See: virtual private network.
10628 (I) A flaw or weakness in a system's design, implementation, or
10629 operation and management that could be exploited to violate the
10630 system's security policy.
10632 (C) Most systems have vulnerabilities of some sort, but this does
10633 not mean that the systems are too flawed to use. Not every threat
10634 results in an attack, and not every attack succeeds. Success
10635 depends on the degree of vulnerability, the strength of attacks,
10636 and the effectiveness of any countermeasures in use. If the
10637 attacks needed to exploit a vulnerability are very difficult to
10638 carry out, then the vulnerability may be tolerable. If the
10642 Shirey Informational [Page 190]
10644 RFC 2828 Internet Security Glossary May 2000
10647 perceived benefit to an attacker is small, then even an easily
10648 exploited vulnerability may be tolerable. However, if the attacks
10649 are well understood and easily made, and if the vulnerable system
10650 is employed by a wide range of users, then it is likely that there
10651 will be enough benefit for someone to make an attack.
10654 See: World Wide Web.
10657 (I) A computer program that automatically dials a series of
10658 telephone numbers to find lines connected to computer systems, and
10659 catalogs those numbers so that a cracker can try to break into the
10662 $ Wassenaar Arrangement
10663 (N) The Wassenaar Arrangement on Export Controls for Conventional
10664 Arms and Dual-Use Goods and Technologies is a global, multilateral
10665 agreement approved by 33 countries in July 1996 to contribute to
10666 regional and international security and stability, by promoting
10667 information exchange concerning, and greater responsibility in,
10668 transfers of arms and dual-use items, thus preventing
10669 destabilizing accumulations. (See: International Traffic in Arms
10672 (C) The Arrangement began operations in September 1996. The
10673 participating countries are Argentina, Australia, Austria,
10674 Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland,
10675 France, Germany, Greece, Hungary, Ireland, Italy, Japan,
10676 Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal,
10677 Republic of Korea, Romania, Russian Federation, Slovak Republic,
10678 Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom, and
10679 United States. Participants meet on a regular basis in Vienna,
10680 where the Arrangement has its headquarters.
10682 Participating countries seek through their national policies to
10683 ensure that transfers do not contribute to the development or
10684 enhancement of military capabilities that undermine the goals of
10685 the arrangement, and are not diverted to support such
10686 capabilities. The countries maintain effective export controls for
10687 items on the agreed lists, which are reviewed periodically to
10688 account for technological developments and experience gained.
10689 Through transparency and exchange of views and information,
10690 suppliers of arms and dual-use items can develop common
10691 understandings of the risks associated with their transfer and
10692 assess the scope for coordinating national control policies to
10693 combat these risks. Members provide semi-annual notification of
10694 arms transfers, covering seven categories derived from the UN
10698 Shirey Informational [Page 191]
10700 RFC 2828 Internet Security Glossary May 2000
10703 Register of Conventional Arms. Members also report transfers or
10704 denials of transfers of certain controlled dual-use items.
10705 However, the decision to transfer or deny transfer of any item is
10706 the sole responsibility of each participating country. All
10707 measures undertaken with respect to the arrangement are in
10708 accordance with national legislation and policies and are
10709 implemented on the basis of national discretion.
10712 See: digital watermarking.
10715 (O) PGP usage: A trust-file PKI technique used in PGP for building
10716 a file of validated public keys by making personal judgments about
10717 being able to trust certain people to be holding properly
10718 certified keys of other people. (See: certification hierarchy,
10722 (I) A software process that runs on a host computer connected to
10723 the Internet to respond to HTTP requests for documents from client
10727 1. (I) Capitalized: ISDs SHOULD capitalize "Web" when using the
10728 term (as either a noun or an adjective) to refer specifically to
10729 the World Wide Web. (Similarly, see: internet vs. Internet.)
10731 2. (C) Not capitalized: ISDs SHOULD NOT capitalize "web" when
10732 using the term (usually as an adjective) to refer generically to
10733 technology--such as web browsers, web servers, HTTP, and HTML--
10734 that is used in the Web or similar networks.
10736 (C) IETF documents SHOULD spell out "World Wide Web" fully at the
10737 first instance of usage and SHOULD Use "Web" and "web" especially
10738 carefully where confusion with the PGP "web of trust" is possible.
10741 (I) An attack that intercepts and accesses data and other
10742 information contained in a flow in a communication system.
10744 (C) Although the term originally referred to making a mechanical
10745 connection to an electrical conductor that links two nodes, it is
10746 now used to refer to reading information from any sort of medium
10747 used for a link or even directly from a node, such as gateway or
10754 Shirey Informational [Page 192]
10756 RFC 2828 Internet Security Glossary May 2000
10759 (C) "Active wiretapping" attempts to alter the data or otherwise
10760 affect the flow; "passive wiretapping" only attempts to observe
10761 the flow and gain knowledge of information it contains. (See:
10762 active attack, end-to-end encryption, passive attack.)
10765 (I) General security usage: The estimated amount of effort or time
10766 that can be expected to be expended by a potential intruder to
10767 penetrate a system, or defeat a particular countermeasure, when
10768 using specified amounts of expertise and resources.
10770 (I) Cryptography usage: The estimated amount of computing time and
10771 power needed to break a cryptographic system.
10773 $ World Wide Web ("the Web", WWW, W3)
10774 (N) The global, hypermedia-based collection of information and
10775 services that is available on Internet servers and is accessed by
10776 browsers using Hypertext Transfer Protocol and other information
10777 retrieval mechanisms. (See: web vs. Web, [R2084].)
10780 (I) A computer program that can run independently, can propagate a
10781 complete working version of itself onto other hosts on a network,
10782 and may consume computer resources destructively. (See: Morris
10786 (O) To use cryptography to provide data confidentiality service
10787 for a data object. (See: encrypt, seal.)
10789 (D) ISDs SHOULD NOT use this term with this definition because it
10790 duplicates the meaning of other, standard terms. Instead, use
10791 "encrypt" or use a term that is specific with regard to the
10795 See: World Wide Web.
10798 (N) An ITU-T Recommendation [X400] that is one part of a joint
10799 ITU-T/ISO multi-part standard (X.400-X.421) that defines the
10800 Message Handling Systems. (The ISO equivalent is IS 10021, parts
10801 1-7.) (See: Message Handling Systems.)
10805 (N) An ITU-T Recommendation [X500] that is one part of a joint
10806 ITU-T/ISO multi-part standard (X.500-X.525) that defines the X.500
10810 Shirey Informational [Page 193]
10812 RFC 2828 Internet Security Glossary May 2000
10815 Directory, a conceptual collection of systems that provide
10816 distributed directory capabilities for OSI entities, processes,
10817 applications, and services. (The ISO equivalent is IS 9594-1 and
10818 related standards, IS 9594-x.) (See: directory vs. Directory,
10821 (C) The X.500 Directory is structured as a tree (the Directory
10822 Information Tree), and information is stored in directory entries.
10823 Each entry is a collection of information about one object, and
10824 each object has a DN. A directory entry is composed of attributes,
10825 each with a type and one or more values. For example, if a PKI
10826 uses the Directory to distribute certificates, then the X.509
10827 public-key certificate of an end user is normally stored as a
10828 value of an attribute of type "userCertificate" in the Directory
10829 entry that has the DN that is the subject of the certificate.
10832 (N) An ITU-T Recommendation [X509] that defines a framework to
10833 provide and support data origin authentication and peer entity
10834 authentication services, including formats for X.509 public-key
10835 certificates, X.509 attribute certificates, and X.509 CRLs. (The
10836 ISO equivalent is IS 9498-4.) (See: X.500.)
10838 (C) X.509 describes two levels of authentication: simple
10839 authentication based on a password, and strong authentication
10840 based on a public-key certificate.
10842 $ X.509 attribute certificate
10843 (N) An attribute certificate in the version 1 (v1) format defined
10844 by X.509. (The v1 designation for an X.509 attribute certificate
10845 is disjoint from the v1 designation for an X.509 public-key
10846 certificate, and from the v1 designation for an X.509 CRL.)
10848 (C) An X.509 attribute certificate has a subject field, but the
10849 attribute certificate is a separate data structure from that
10850 subject's public-key certificate. A subject may have multiple
10851 attribute certificates associated with each of its public-key
10852 certificates, and an attribute certificate may be issued by a
10853 different CA than the one that issued the associated public-key
10856 (C) An X.509 attribute certificate contains a sequence of data
10857 items and has a digital signature that is computed from that
10858 sequence. In addition to the signature, an attribute certificate
10859 contains items 1 through 9 listed below:
10866 Shirey Informational [Page 194]
10868 RFC 2828 Internet Security Glossary May 2000
10871 1. version Identifies v1.
10872 2. subject Is one of the following:
10873 2a. baseCertificateID - Issuer and serial number of an
10874 X.509 public-key certificate.
10875 2b. subjectName - DN of the subject.
10876 3. issuer DN of the issuer (the CA who signed).
10877 4. signature OID of algorithm that signed the cert.
10879 5. serialNumber Certificate serial number;
10880 an integer assigned by the issuer.
10881 6. attCertValidityPeriod Validity period; a pair of UTCTime
10882 values: "not before" and "not after".
10883 7. attributes Sequence of attributes describing the
10885 8. issuerUniqueId Optional, when a DN is not sufficient.
10886 9. extensions Optional.
10888 $ X.509 authority revocation list
10889 (N) An ARL in one of the formats defined by X.509--version 1 (v1)
10890 or version 2 (v2). A specialized kind of certificate revocation
10893 $ X.509 certificate
10894 (N) Either an X.509 public-key certificate or an X.509 attribute
10897 (C) This Glossary uses the term with the precise meaning
10898 recommended here. However, some who use the term may not be aware
10899 that X.509 specifies attribute certificates that do not contain a
10900 public key. Even among those who are aware, this term is commonly
10901 used as an abbreviation to mean "X.509 public-key certificate".
10902 ISDs MAY use the term as an abbreviation for "X.509 public-key
10903 certificate", but only after using the full term at the first
10906 (D) ISDs SHOULD NOT use this term as an abbreviation to mean
10907 "X.509 attribute certificate".
10909 $ X.509 certificate revocation list (CRL)
10910 (N) A CRL in one of the formats defined by X.509--version 1 (v1)
10911 or version 2 (v2). (The v1 and v2 designations for an X.509 CRL
10912 are disjoint from the v1 and v2 designations for an X.509 public-
10913 key certificate, and from the v1 designation for an X.509
10914 attribute certificate.) (See: certificate revocation.)
10916 (C) ISDs SHOULD NOT refer to an X.509 CRL as a digital
10917 certificate, but note that an X.509 CRL does meet this Glossary's
10918 definition of "digital certificate". Like a digital certificate,
10922 Shirey Informational [Page 195]
10924 RFC 2828 Internet Security Glossary May 2000
10927 an X.509 CRL makes an assertion and is signed by a CA. But instead
10928 of binding a key or other attributes to a subject, an X.509 CRL
10929 asserts that certain previously-issued X.509 certificates have
10932 (C) An X.509 CRL contains a sequence of data items and has a
10933 digital signature computed on that sequence. In addition to the
10934 signature, both v1 and v2 contain items 2 through 6b listed below.
10935 Version 2 contains item 1 and may optionally contain 6c and 7.
10937 1. version Optional. If present, identifies v2.
10938 2. signature OID of the algorithm that signed CRL.
10939 3. issuer DN of the issuer (the CA who signed).
10940 4. thisUpdate A UTCTime value.
10941 5. nextUpdate A UTCTime value.
10942 6. revokedCertificates 3-tuples of 6a, 6b, and (optional) 6c:
10943 6a. userCertificate A certificate's serial number.
10944 6b. revocationDate UTCTime value for the revocation date.
10945 6c. crlEntryExtensions Optional.
10946 7. crlExtensions Optional.
10948 $ X.509 public-key certificate
10949 (N) A public-key certificate in one of the formats defined by
10950 X.509--version 1 (v1), version 2 (v2), or version 3 (v3). (The v1
10951 and v2 designations for an X.509 public-key certificate are
10952 disjoint from the v1 and v2 designations for an X.509 CRL, and
10953 from the v1 designation for an X.509 attribute certificate.)
10955 (C) An X.509 public-key certificate contains a sequence of data
10956 items and has a digital signature computed on that sequence. In
10957 addition to the signature, all three versions contain items 1
10958 through 7 listed below. Only v2 and v3 certificates may also
10959 contain items 8 and 9, and only v3 may contain item 10.
10961 1. version Identifies v1, v2, or v3.
10962 2. serialNumber Certificate serial number;
10963 an integer assigned by the issuer.
10964 3. signature OID of algorithm that was used to
10965 sign the certificate.
10966 4. issuer DN of the issuer (the CA who signed).
10967 5. validity Validity period; a pair of UTCTime
10968 values: "not before" and "not after".
10969 6. subject DN of entity who owns the public key.
10970 7. subjectPublicKeyInfo Public key value and algorithm OID.
10971 8. issuerUniqueIdentifier Defined for v2, v3; optional.
10972 9. subjectUniqueIdentifier Defined for v2, v2; optional.
10973 10. extensions Defined only for v3; optional.
10978 Shirey Informational [Page 196]
10980 RFC 2828 Internet Security Glossary May 2000
10984 See: (secondary definition under) Terminal Access Controller (TAC)
10985 Access Control System.
10988 (D) ISDs SHOULD NOT use this term as a synonym for "Computer
10989 Security Requirements: Guidance for Applying the Department of
10990 Defense Trusted Computer System Evaluation Criteria in Specific
10991 Environments" [CSC3]. Instead, use the full proper name of the
10992 document or, in subsequent references, a conventional
10993 abbreviation. (See: (usage note under) Green Book, Rainbow
10997 (I) Use erasure or other means to render stored data unusable and
10998 unrecoverable, particularly a key stored in a cryptographic module
11001 (O) Erase electronically stored data by altering the contents of
11002 the data storage so as to prevent the recovery of the data.
11007 This Glossary focuses on the Internet Standards Process. Therefore,
11008 this set of references emphasizes international, governmental, and
11009 industry standards documents; only a few other texts are listed. RFCs
11010 are listed, but not Internet-Drafts, because the latter are not an
11011 archival document series and should not be cited or quoted in an RFC.
11013 [A3092] American National Standards Institute, "American National
11014 Standard Data Encryption Algorithm", ANSI X3.92-1981, 30 Dec
11017 [A9009] ---, "Financial Institution Message Authentication
11018 (Wholesale)", ANSI X9.9-1986, 15 Aug 1986.
11020 [A9017] ---, "Financial Institution Key Management (Wholesale)",
11021 X9.17, 4 Apr 1985. [Defines procedures for the manual and
11022 automated management of keying material and uses DES to
11023 provide key management for a variety of operational
11026 [A9042] ---, "Public key Cryptography for the Financial Service
11027 Industry: Agreement of Symmetric Keys Using Diffie-Hellman
11028 and MQV Algorithms", X9.42, 29 Jan 1999.
11034 Shirey Informational [Page 197]
11036 RFC 2828 Internet Security Glossary May 2000
11039 [A9052] ---, "Triple Data Encryption Algorithm Modes of Operation",
11040 X9.52-1998, ANSI approval 9 Nov 1998.
11042 [A9062] ---, "Public Key Cryptography for the Financial Services
11043 Industry: The Elliptic Curve Digital Signature Algorithm
11044 (ECDSA)", X9.62-1998, ANSI approval 7 Jan 1999.
11046 [ABA] American Bar Association, "Digital Signature Guidelines:
11047 Legal Infrastructure for Certification Authorities and
11048 Secure Electronic Commerce", Chicago, IL, 1 Aug 1996.
11050 [ACM] Association for Computing Machinery, "Communications of the
11051 ACM", Jul 1998 issue with: Minerva M. Yeung, "Digital
11052 Watermarking"; Nasir Memom and Ping Wah Wong, "Protecting
11053 Digital Media Content"; and Scott Craver, Boon-Lock Yeo, and
11054 Minerva Yeung, "Technical Trials and Legal Tribulations".
11056 [Army] U.S. Army Corps of Engineers, "Electromagnetic Pulse (EMP)
11057 and Tempest Protection for Facilities", EP 1110-3-2, 31 Dec
11060 [B7799] British Standards Institution, "Information Security
11061 Management, Part 1: Code of Practice for Information
11062 Security Management", BS 7799-1:1999, effective 15 May 1999.
11064 ---, ---, "Part 2: Specification for Information Security
11065 Management Systems", BS 7799-2:1999, effective 15 May 1999.
11067 [Bell] D. E. Bell and L. J. LaPadula, "Secure Computer Systems:
11068 Mathematical Foundations and Model", M74-244, The MITRE
11069 Corporation, Bedford, MA, May 1973. (Available as AD-771543,
11070 National Technical Information Service, Springfield, VA.)
11072 [CCIB] Common Criteria Implementation Board, "Common Criteria for
11073 Information Technology Security Evaluation, Part 1:
11074 Introduction and General Model", ver. 2.1, CCIB-99-01, Aug
11077 [CIPSO] Trusted Systems Interoperability Working Group, "Common IP
11078 Security Option", ver. 2.3, 9 Mar 1993. [A "work in
11079 progress" that is probably defunct.]
11081 [CSC1] U.S. Department of Defense Computer Security Center,
11082 "Department of Defense Trusted Computer System Evaluation
11083 Criteria", CSC-STD-001-83, 15 Aug 1983. (Superseded by
11090 Shirey Informational [Page 198]
11092 RFC 2828 Internet Security Glossary May 2000
11095 [CSC2] ---, "Department of Defense Password Management Guideline",
11096 CSC-STD-002-85, 12 Apr 1985.
11098 [CSC3] ---, "Computer Security Requirements: Guidance for Applying
11099 the Department of Defense Trusted Computer System Evaluation
11100 Criteria in Specific Environments", CSC-STD-003-85, 25 Jun
11103 [CSOR] U.S. Department of Commerce, "General Procedures for
11104 Registering Computer Security Objects", National Institute
11105 of Standards Interagency Report 5308, Dec 1993.
11107 [Denn] D. E. Denning, "A Lattice Model of Secure Information Flow",
11108 in "Communications of the ACM", vol. 19, no. 5, May 1976,
11111 [DH76] W. Diffie and M. H. Hellman, "New Directions in
11112 Cryptography" in "IEEE Transactions on Information Theory",
11113 vol. IT-22, no. 6, Nov 1976, pp. 644-654.
11115 [DOD1] U.S. Department of Defense, "Department of Defense Trusted
11116 Computer System Evaluation Criteria", DoD 5200.28-STD, 26
11117 Dec 1985. (Supersedes [CSC1].)
11119 [DOD2] ---, Directive 5200.28, "Security Requirements for Automated
11120 Information Systems (AISs)", 21 Mar 1988.
11122 [DOD3] ---, "X.509 Certificate Policy", ver. 2, Mar 1999.
11124 [DOD4] ---, "NSA Key Recovery Assessment Criteria", 8 Jun 1998.
11126 [ElGa] T. El Gamal, "A Public-Key Cryptosystem and a Signature
11127 Scheme Based on Discrete Logarithms" in "IEEE Transactions
11128 on Information Theory", vol. IT-31, no. 4, 1985, pp. 469-
11131 [EMV1] Europay International S.A., MasterCard International
11132 Incorporated, and Visa International Service Association,
11133 "EMV '96 Integrated Circuit Card Specification for Payment
11134 Systems", ver. 3.1.1, 31 May 1998.
11136 [EMV2] ---, "EMV '96 Integrated Circuit Card Terminal Specification
11137 for Payment Systems", ver. 3.1.1, 31 May 1998.
11139 [EMV3] ---, EMV '96 Integrated Circuit Card Application
11140 Specification for Payment Systems", ver. 3.1.1, 31 May 1998.
11146 Shirey Informational [Page 199]
11148 RFC 2828 Internet Security Glossary May 2000
11151 [For94] W. Ford, "Computer Communications Security: Principles,
11152 Standard Protocols and Techniques", ISBN 0-13-799453-2,
11155 [For97] W. Ford and M. Baum, "Secure Electronic Commerce: Building
11156 the Infrastructure for Digital Signatures and Encryption",
11157 ISBN 0-13-476342-4, 1994.
11159 [FP031] U.S. Department of Commerce, "Guidelines for Automatic Data
11160 Processing Physical Security and Risk Management", Federal
11161 Information Processing Standards Publication (FIPS PUB) 31,
11164 [FP039] ---, "Glossary for Computer Systems Security", FIPS PUB 39,
11167 [FP046] ---, "Data Encryption Standard (DES)", FIPS PUB 46-2, 30 Dec
11170 [FP081] ---, "DES Modes of Operation", FIPS PUB 81, 2 Dec 1980.
11172 [FP102] ---, "Guideline for Computer Security Certification and
11173 Accreditation", FIPS PUB 102, 27 Sep 1983.
11175 [FP113] ---, "Computer Data Authentication", FIPS PUB 113, 30 May
11178 [FP140] ---, "Security Requirements for Cryptographic Modules", FIPS
11179 PUB 140-1, 11 Jan 1994.
11181 [FP151] ---, "Portable Operating System Interface (POSIX)--System
11182 Application Program Interface [C Language]", FIPS PUB 151-2,
11185 [FP180] ---, "Secure Hash Standard", FIPS PUB 180-1, 17 Apr 1995.
11187 [FP185] ---, "Escrowed Encryption Standard", FIPS PUB 185, 9 Feb
11190 [FP186] ---, "Digital Signature Standard (DSS)", FIPS PUB 186, 19
11193 [FP188] ---, "Standard Security Label for Information Transfer",
11194 FIPS PUB 188, 6 Sep 1994.
11196 [FPDAM] Collaborative ITU and ISO/IEC meeting on the Directory,
11197 "Final Proposed Draft Amendment on Certificate Extensions",
11198 April 1999. (This draft proposes changes to [X.509].)
11202 Shirey Informational [Page 200]
11204 RFC 2828 Internet Security Glossary May 2000
11207 [FPKI] U.S. Department of Commerce, "Public Key Infrastructure
11208 (PKI) Technical Specifications: Part A--Technical Concept of
11209 Operations", National Institute of Standards, 4 Sep 1998.
11211 [I3166] International Standards Organization, "Codes for the
11212 Representation of Names of countries and Their Subdivisions
11213 --Part 1: Country Codes", ISO 3166-1:1997.
11215 ---, --- "Part 2: Country Subdivision Codes", ISO/DIS 3166-
11218 ---, --- "Part 3: Codes for Formerly Used Names of
11219 Countries", ISO/DIS 3166-3.
11221 [I7498] ---, "Information Processing Systems--Open Systems
11222 Interconnection Reference Model--[Part 1:] Basic Reference
11223 Model", ISO/IEC 7498-1. (Equivalent to ITU-T Recommendation
11226 ---, --- "Part 2: Security Architecture", ISO/IEC 7499-2.
11228 ---, --- "Part 4: Management Framework", ISO/IEC 7498-4.
11230 [I7812] ---, "Identification cards--Identification of Issuers--Part
11231 1: Numbering System", ISO/IEC 7812-1:1993
11233 ---, --- "Part 2: Application and Registration Procedures",
11234 ISO/IEC 7812-2:1993.
11236 [I9945] ---, "Portable Operating System Interface for Computer
11237 Environments", ISO/IEC 9945-1:1990.
11239 [I15408] ---, "Information Technology--Security Techniques--
11240 Evaluation criteria for IT Security--Part 1: Introduction
11241 and General Model", ISO/IEC 15408-1:1999.
11243 [ITSEC] "Information Technology Security Evaluation Criteria
11244 (ITSEC): Harmonised Criteria of France, Germany, the
11245 Netherlands, and the United Kingdom", ver. 1.2, U.K.
11246 Department of Trade and Industry, Jun 1991.
11248 [Kahn] David Kahn, "The Codebreakers: The Story of Secret Writing",
11249 The Macmillan Company, New York, 1967.
11251 [Knuth] D. E. Knuth, Chapter 3 ("Random Numbers") in Volume 2
11252 ("Seminumerical Algorithms") of "The Art of Computer
11253 Programming", Addison-Wesley, Reading, MA, 1969.
11258 Shirey Informational [Page 201]
11260 RFC 2828 Internet Security Glossary May 2000
11263 [Kuhn] Markus G. Kuhn and Ross J. Anderson, "Soft Tempest: Hidden
11264 Data Transmission Using Electromagnetic Emanations", in
11265 David Aucsmith, ed., "Information Hiding, Second
11266 International Workshop, IH'98", Portland, Oregon, USA, 15-17
11267 Apr 1998, LNCS 1525, Springer-Verlag, ISBN 3-540-65386-4,
11270 [MISPC] U.S. Department of Commerce, "Minimum Interoperability
11271 Specification for PKI Components (MISPC), Version 1",
11272 National Institute of Standards Special Publication 800-15,
11275 [NCS01] National Computer Security Center, "A Guide to Understanding
11276 Audit in Trusted Systems", NCSC-TG-001, 1 Jun 1988. (Part of
11277 the Rainbow Series.)
11279 [NCS04] ---, "Glossary of Computer Security Terms", NCSC-TG-004,
11280 ver. 1, 21 Oct 1988. (Part of the Rainbow Series.)
11282 [NCS05] ---, "Trusted Network Interpretation of the Trusted Computer
11283 System Evaluation Criteria", NCSC-TG-005, ver. 1, 31 Jul
11284 1987. (Part of the Rainbow Series.)
11286 [NCS25] ---, "A Guide to Understanding Data Remanence in Automated
11287 Information Systems", NCSC-TG-025, ver. 2, Sep 1991. (Part
11288 of the Rainbow Series.)
11290 [NIST] National Institute of Standards and Technology, "SKIPJACK
11291 and KEA Algorithm Specifications", ver. 2, 29 May 1998.
11292 (http://csrc.nist.gov/encryption/skipjack-kea.htm)
11294 [PGP] Simson Garfinkel, "PGP: Pretty Good Privacy", O'Reilly &
11295 Associates, Inc., Sebastopol, CA, 1995.
11297 [PKCS] Burton S. Kaliski, Jr., "An Overview of the PKCS Standards",
11298 RSA Data Security, Inc., 3 Jun 1991.
11300 [PKC07] RSA Laboratories, "PKCS #7: Cryptographic Message Syntax
11301 Standard", ver. 1.5, RSA Laboratories Technical Note, 1 Nov
11304 [PKC10] ---, "PKCS #10: Certification Request Syntax Standard", ver.
11305 1.0, RSA Laboratories Technical Note, 1 Nov 1993.
11307 [PKC11] ---, "PKCS #11: Cryptographic Token Interface Standard",
11308 ver. 1.0, 28 Apr 1995.
11314 Shirey Informational [Page 202]
11316 RFC 2828 Internet Security Glossary May 2000
11319 [R0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
11322 [R0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
11325 [R0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
11326 792, September 1981. [See: RFC 1885.]
11328 [R0793] Postel, J., ed., "Transmission Control Protocol", STD 7, RFC
11329 793, September 1981.
11331 [R0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
11334 [R0822] Crocker, D., "Standard for the Format of ARPA Internet Text
11335 Messages", STD 11, RFC 822, August 1982.
11337 [R0854] Postel, J. and J. Reynolds, "TELNET Protocol Specification",
11338 STD 8, RFC 854, May 1983.
11340 [R0959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
11341 STD 9, RFC 959, October 1985.
11343 [R1034] Mockapetris, P., "Domain Names--Concepts and Facilities",
11344 STD 13, RFC 1034, November 1987.
11346 [R1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
11347 Network Management Protocol (SNMP)" [version 1], STD 15, RFC
11350 [R1208] Jacobsen O. and D. Lynch, "A Glossary of Networking Terms",
11351 RFC 1208, March 1991.
11353 [R1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
11356 [R1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
11359 [R1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
11362 [R1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols",
11363 RFC 1334, October 1992.
11365 [R1413] St. Johns, M., "Identification Protocol", RFC 1413, February
11370 Shirey Informational [Page 203]
11372 RFC 2828 Internet Security Glossary May 2000
11375 [R1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail,
11376 Part I: Message Encryption and Authentication Procedures",
11377 RFC 1421, February 1993.
11379 [R1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail,
11380 Part II: Certificate-Based Key Management", RFC 1422,
11383 [R1455] Eastlake, D., "Physical Link Security Type of Service", RFC
11386 [R1457] Housley, R., "Security Label Framework for the Internet",
11387 RFC 1457, May 1993.
11389 [R1492] Finseth, C., "An Access Control Protocol, Sometimes Called
11390 TACACS", RFC 1492, July 1993.
11392 [R1507] Kaufman, C., "DASS: Distributed Authentication Security
11393 Service", RFC 1507, September 1993.
11395 [R1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
11396 Service (V5)", RFC 1510, September 1993.
11398 [R1591] Kohl, J. and C. Neuman, "Domain Name System Structure and
11399 Delegation", March 1994.
11401 [R1630] Berners-Lee, T., "Universal Resource Identifiers in WWW",
11402 RFC 1630, June 1994.
11404 [R1661] Simpson, W., ed., " The Point-to-Point Protocol (PPP)", STD
11405 51, RFC 1661, July 1994.
11407 [R1731] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
11410 [R1734] Myers, J., "POP3 AUTHentication Command", RFC 1734, December
11413 [R1738] Myers, J., Masinter, L. and M. McCahill, ed's., "Uniform
11414 Resource Locators (URL)", RFC 1738, December 1994.
11416 [R1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
11417 Recommendations for Security", RFC 1750, December 1994.
11419 [R1777] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory
11420 Access Protocol", RFC 1777, March 1995.
11426 Shirey Informational [Page 204]
11428 RFC 2828 Internet Security Glossary May 2000
11431 [R1808] Fielding, R., "Relative Uniform Resource Locators", RFC
11434 [R1824] Danisch, H., "The Exponential Security System TESS: An
11435 Identity-Based Cryptographic Protocol for Authenticated Key-
11436 Exchange (E.I.S.S.-Report 1995/4)", RFC 1824, August 1995.
11438 [R1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed
11439 MD5", RFC 1828, August 1995.
11441 [R1829] Karn, P., Metzger, P. and W. Simpson, "The ESP DES-CBC
11442 Transform", RFC 1829, August 1995.
11444 [R1848] Crocker, S., Freed, N., Galvin, J. and S. Murphy, "MIME
11445 Object Security Services", RFC 1848, October 1995.
11447 [R1851] Karn, P., Metzger, P. and W. Simpson, "The ESP Triple DES
11448 Transform", RFC 1851, September 1995.
11450 [R1866] Berners-Lee, T., "Hypertext Markup Language--2.0", RFC 1866,
11453 [R1885] Conta, A. and S. Deering, "Internet Control Message Protocol
11454 (ICMPv6) for the Internet Protocol Version 6 (IPv6)
11455 Specification", RFC 1885, December 1995.
11457 [R1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L.
11458 Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
11460 [R1938] Haller, N. and C. Metzion, "A One-Time Password System", RFC
11463 [R1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
11464 STD 53, RFC 1939, May 1996.
11466 [R1958] Carpenter, B., ed., "Architectural Principles of the
11467 Internet", RFC 1958, June 1996.
11469 [R1983] Malkin, G., ed., "Internet Users' Glossary", FYI 18, RFC
11472 [R1994] Simpson, W. "PPP Challenge Handshake Authentication Protocol
11473 (CHAP)", RFC 1994, August 1996.
11475 [R2023] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
11476 RFC 2023, October 1997.
11482 Shirey Informational [Page 205]
11484 RFC 2828 Internet Security Glossary May 2000
11487 [R2026] Bradner, S., "The Internet Standards Process--Revision 3",
11488 BCP 9, RFC 2026, March 1994.
11490 [R2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
11491 Extensions (MIME) Part One: Format of Internet Message
11492 Bodies", RFC 2045, November 1996.
11494 [R2060] Crispin, M., "Internet Message Access Protocol--Version 4
11495 Revision 1", RFC 2060, December 1996.
11497 [R2065] Eastlake, D., 3rd, "Domain Name System Security Extensions",
11498 RFC 2065, January 1997.
11500 [R2078] Linn, J., "Generic Security Service Application Program
11501 Interface, Version 2", RFC 2078, January 1997.
11503 [R2084] Bossert, G., Cooper, S. and W. Drummond, "Considerations for
11504 Web Transaction Security", RFC 2084, January 1997.
11506 [R2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
11507 Hashing for Message Authentication", RFC 2104, February
11510 [R2119] Bradner, S., "Key Words for Use in RFCs To Indicate
11511 Requirement Levels", BCP 14, RFC 2119, March 1997.
11513 [R2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
11514 Authentication Dial In User Service (RADIUS)", RFC 2138,
11517 [R2137] Eastlake, D., "Secure Domain Name System Dynamic Update",
11518 RFC 2137, April 1997.
11520 [R2179] Gwinn, A., "Network Security For Trade Shows", RFC 2179,
11523 [R2195] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize
11524 Extension for Simple Challenge/Response", RFC 2195, Sepember
11527 [R2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
11530 [R2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
11531 SHA-1", RFC 2202, Sepember 1997.
11538 Shirey Informational [Page 206]
11540 RFC 2828 Internet Security Glossary May 2000
11543 [R2222] Myers, J., "Simple Authentication and Security Layer
11544 (SASL)", RFC 2222, October 1997.
11546 [R2223] Postel, J., "Instructions to RFC Authors", RFC 2223, October
11549 [R2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0",
11550 RFC 2246, January 1999.
11552 [R2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
11553 Protocol (EAP)", RFC 2284, March 1998.
11555 [R2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax, Version
11556 1.5", RFC 2315, March 1998.
11558 [R2323] Ramos, A., "IETF Identification and Security Guidelines",
11559 RFC 2323, 1 April 1998. [Intended for humorous entertainment
11560 ("please laugh loud and hard"); does not contain serious
11561 security information.]
11563 [R2350] Brownlee, N. and E. Guttman, "Expectations for Computer
11564 Security Incident Response", RFC 2350, June 1998.
11566 [R2356] Montenegro, C. and V. Gupta, "Sun's SKIP Firewall Traversal
11567 for Mobile IP", RFC 2356, June 1998.
11569 [R2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
11570 Architecture", RFC 2373, July 2998.
11572 [R2401] Kent, S. and R. Atkinson, "Security Architecture for the
11573 Internet Protocol", RFC 2401, November 1998.
11575 [R2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
11576 2402, November 1998.
11578 [R2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP
11579 and AH", RFC 2403, November 1998.
11581 [R2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
11582 ESP and AH", RFC 2404, November 1998.
11584 [R2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
11585 Algorithm With Explicit IV", RFC 2405, November 1998.
11587 [R2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
11588 (ESP)", RFC 2406, November 1998.
11594 Shirey Informational [Page 207]
11596 RFC 2828 Internet Security Glossary May 2000
11599 [R2407] Piper, D., "The Internet IP Security Domain of
11600 Interpretation for ISAKMP", RFC 2407, November 1998.
11602 [R2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
11603 "Internet Security Association and Key Management Protocol
11604 (ISAKMP)", RFC 2408, November 1998.
11606 [R2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
11607 (IKE)", RFC 2409, November 1998.
11609 [R2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
11610 Its Use With IPsec", RFC 2410, November 1998.
11612 [R2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
11613 2412, November 1998.
11615 [R2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
11616 Algorithms", RFC 2451, November 1998.
11618 [R2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
11619 (IPv6) Specification", RFC 2460, December 1998.
11621 [R2504] Guttman, E., Leong, L. and G. Malkin, "Users' Security
11622 Handbook", RFC 2504, February 1999.
11624 [R2510] Adams, C. and S. Farrell, "Internet X.509 Public Key
11625 Infrastructure Certificate Management Protocols", RFC 2510,
11628 [R2527] Chokhani, S. and W. Ford, "Internet X.509 Public Key
11629 Infrastructure, Certificate Policy and Certification
11630 Practices Framework", RFC 2527, March 1999.
11632 [R2536] EastLake, D., "DSA KEYs and SIGs in the Domain Name System
11633 (DNS)", RFC 2536, March 1999.
11635 [R2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
11636 "Introduction to Version 3 of the Internet-Standard Network
11637 Management Framework", RFC 2570, April 1999.
11639 [R2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
11640 (USM) for Version 3 of the Simple Network Management
11641 Protocol (SNMPv3)", RFC 2574, April 1999.
11643 [R2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption
11644 Algorithm", RFC 2612, June 1999.
11650 Shirey Informational [Page 208]
11652 RFC 2828 Internet Security Glossary May 2000
11655 [R2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
11656 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
11657 Protocol-- HTTP/1.1", RFC 2616, June 1999.
11659 [R2628] Smyslov, V., "Simple Cryptographic Program Interface", RFC
11662 [R2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
11665 [R2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
11668 [R2633] Ramsdell, B., ed., "S/MIME Version 3 Message Specification",
11669 RFC 2633, June 1999.
11671 [R2634] Hoffman, P., ed., "Enhanced Security Services for S/MIME",
11672 RFC 2634, June 1999.
11674 [R2635] Hambridge, S. and A. Lunde, "Don't Spew: A Set of Guidelines
11675 for Mass Unsolicited Mailings and Postings", RFC 2635, June
11678 [Raym] E. S. Raymond, ed., "The On-Line Hacker Jargon File", ver.
11679 4.0.0, 24 Jul 1996. (Also available as "The New Hacker's
11680 Dictionary", 2nd edition, MIT Press, Sep 1993, ISBN 0-262-
11681 18154-1. See: http://www.tuxedo.org/jargon/ for the latest
11684 [Russ] D. Russell and G. T. Gangemi Sr., Chapter 10 ("TEMPEST") in
11685 "Computer Security Basics", ISBN 0-937175-71-4, 1991.
11687 [Schn] B. Schneier, "Applied Cryptography", John Wiley & Sons,
11688 Inc., New York, 1994.
11690 [SDNS3] U.S. Department of Defense, National Security Agency,
11691 "Secure Data Network Systems, Security Protocol 3 (SP3)",
11692 document SDN.301, Revision 1.5, 15 May 1989.
11694 [SDNS4] ---, ---, "Security Protocol 4 (SP4)", document SDN.401,
11695 Revision 1.2, 12 Jul 1988.
11697 [SDNS7] ---, ---, "Secure data Network System, Message Security
11698 Protocol (MSP)", document SDN.701, Revision 4.0, 7 Jun 1996,
11699 with Corrections to Message Security Protocol, SDN.701, Rev
11700 4.0", 96-06-07, 30 Aug, 1996.
11706 Shirey Informational [Page 209]
11708 RFC 2828 Internet Security Glossary May 2000
11711 [SET1] MasterCard and Visa, "SET Secure Electronic Transaction
11712 Specification, Book 1: Business Description", ver. 1.0, 31
11715 [SET2] ---, "SET Secure Electronic Transaction Specification, Book
11716 2: Programmer's Guide", ver. 1.0, 31 May 1997.
11718 [Stei] J. Steiner, C. Neuman, and J. Schiller, "Kerberos: An
11719 Authentication Service for Open Network Systems" in "Usenix
11720 Conference Proceedings", Feb 1988.
11722 [X400] International Telecommunications Union--Telecommunication
11723 Standardization Sector (formerly "CCITT"), Recommendation
11724 X.400, "Message Handling Services: Message Handling System
11725 and Service Overview".
11727 [X500] ---, Recommendation X.500, "Information Technology--Open
11728 Systems Interconnection--The Directory: Overview of
11729 Concepts, Models, and Services". (Equivalent to ISO 9594-1.)
11731 [X501] ---, Recommendation X.501, "Information Technology--Open
11732 Systems Interconnection--The Directory: Models".
11734 [X509] ---, Recommendation X.509, "Information Technology--Open
11735 Systems Interconnection--The Directory: Authentication
11736 Framework". (Equivalent to ISO 9594-8.)
11738 [X519] ---, Recommendation X.519, "Information Technology--Open
11739 Systems Interconnection--The Directory: Protocol
11742 [X520] ---, Recommendation X.520, "Information Technology--Open
11743 Systems Interconnection--The Directory: Selected Attribute
11746 [X680] ---, Recommendation X.680, "Information Technology--Abstract
11747 Syntax Notation One (ASN.1)--Specification of Basic
11748 Notation", 15 Nov 1994. (Equivalent to ISO/IEC 8824-1.)
11750 [X690] ---, Recommendation X.690, "Information Technology--ASN.1
11751 Encoding Rules--Specification of Basic Encoding Rules (BER),
11752 Canonical Encoding Rules (CER) and Distinguished Encoding
11753 Rules (DER)", 15 Nov 1994. (Equivalent to ISO/IEC 8825-1.)
11762 Shirey Informational [Page 210]
11764 RFC 2828 Internet Security Glossary May 2000
11767 5. Security Considerations
11769 This document only defines security terms and recommends how to use
11770 them. It does not describe in detail the vulnerabilities of, threats
11771 to, or mechanisms that protect specific Internet protocols.
11775 Pat Cain, Mike Kong, and Charles Lynn provided meticulous comments on
11778 7. Author's Address
11780 Please address all comments to:
11782 Robert W. Shirey GTE / BBN Technologies
11783 EMail: rshirey@bbn.com Suite 1200, Mail Stop 30/12B2
11784 Phone: +1 (703) 284-4641 1300 Seventeenth Street North
11785 Fax: +1 (703) 284-2766 Arlington, VA 22209-3801 USA
11818 Shirey Informational [Page 211]
11820 RFC 2828 Internet Security Glossary May 2000
11823 8. Full Copyright Statement
11825 Copyright (C) The Internet Society (2000). All Rights Reserved.
11827 This document and translations of it may be copied and furnished to
11828 others, and derivative works that comment on or otherwise explain it
11829 or assist in its implementation may be prepared, copied, published
11830 and distributed, in whole or in part, without restriction of any
11831 kind, provided that the above copyright notice and this paragraph are
11832 included on all such copies and derivative works. However, this
11833 document itself may not be modified in any way, such as by removing
11834 the copyright notice or references to the Internet Society or other
11835 Internet organizations, except as needed for the purpose of
11836 developing Internet standards in which case the procedures for
11837 copyrights defined in the Internet Standards process must be
11838 followed, or as required to translate it into languages other than
11841 The limited permissions granted above are perpetual and will not be
11842 revoked by the Internet Society or its successors or assigns.
11844 This document and the information contained herein is provided on an
11845 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
11846 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
11847 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
11848 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
11849 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11853 Funding for the RFC Editor function is currently provided by the
11874 Shirey Informational [Page 212]