]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc2828.txt
Misc updates
[openldap] / doc / rfc / rfc2828.txt
1
2
3
4
5
6
7 Network Working Group                                          R. Shirey
8 Request for Comments: 2828                        GTE / BBN Technologies
9 FYI: 36                                                         May 2000
10 Category: Informational
11
12
13                        Internet Security Glossary
14
15 Status of this Memo
16
17    This memo provides information for the Internet community.  It does
18    not specify an Internet standard of any kind.  Distribution of this
19    memo is unlimited.
20
21 Copyright Notice
22
23    Copyright (C) The Internet Society (2000).  All Rights Reserved.
24
25 Abstract
26
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.
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 Shirey                       Informational                      [Page 1]
59 \f
60 RFC 2828               Internet Security Glossary               May 2000
61
62
63 Table of Contents
64
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
78
79 1. Introduction
80
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].
90
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
94    for ISDs.
95
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
104    recommendations.
105
106
107
108
109
110
111
112
113
114 Shirey                       Informational                      [Page 2]
115 \f
116 RFC 2828               Internet Security Glossary               May 2000
117
118
119    This Glossary supports the goals of the Internet Standards Process:
120
121    o Clear, Concise, and Easily Understood Documentation
122
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.
133
134    o Technical Excellence
135
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
139       correctly.
140
141    o Prior Implementation and Testing
142
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.
153
154    o Openness, Fairness, and Timeliness
155
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.
162
163
164
165
166
167
168
169
170 Shirey                       Informational                      [Page 3]
171 \f
172 RFC 2828               Internet Security Glossary               May 2000
173
174
175 2. Explanation of Paragraph Markings
176
177    Section 3 marks terms and definitions as follows:
178
179    o Capitalization: Only terms that are proper nouns are capitalized.
180
181    o Paragraph Marking: Definitions and explanations are stated in
182       paragraphs that are marked as follows:
183
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
190         Internet documents.
191       - "C" identifies commentary or additional usage guidance.
192
193    The rest of Section 2 further explains these five markings.
194
195 2.1 Recommended Terms with an Internet Basis ("I")
196
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
204    that context
205
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).
211
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
215    found elsewhere.
216
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.
220
221
222
223
224
225
226 Shirey                       Informational                      [Page 4]
227 \f
228 RFC 2828               Internet Security Glossary               May 2000
229
230
231 2.2 Recommended Terms with a Non-Internet Basis ("N")
232
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).
237
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.
246
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.
251
252 2.3 Other Definitions ("O")
253
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
257    as non-Internet.
258
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.
263
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".
276
277
278
279
280
281
282 Shirey                       Informational                      [Page 5]
283 \f
284 RFC 2828               Internet Security Glossary               May 2000
285
286
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.
297
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.
304
305 2.4 Deprecated Terms, Definitions, and Uses ("D")
306
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.
311
312 2.5 Commentary and Additional Guidance ("C")
313
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.
319
320 3. Definitions
321
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.
326
327    $ 3DES
328       See: triple DES.
329
330    $ *-property
331       (N) (Pronounced "star property".) See: "confinement property"
332       under Bell-LaPadula Model.
333
334
335
336
337
338 Shirey                       Informational                      [Page 6]
339 \f
340 RFC 2828               Internet Security Glossary               May 2000
341
342
343    $ ABA Guidelines
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.
347
348    $ Abstract Syntax Notation One (ASN.1)
349       (N) A standard for describing data objects. [X680]
350
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.)
359
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".
364
365    $ ACC
366       See: access control center.
367
368    $ access
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
372       contains.
373
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
376       other." [NCS04]
377
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
385       security clearance.
386
387    $ access control
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
391
392
393
394 Shirey                       Informational                      [Page 7]
395 \f
396 RFC 2828               Internet Security Glossary               May 2000
397
398
399       (users, programs, processes, or other systems) according to that
400       policy. (See: access, access control service.)
401
402       (O) "The prevention of unauthorized use of a resource, including
403       the prevention of use of a resource in an unauthorized manner."
404       [I7498 Part 2]
405
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.
409
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.
413
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.)
418
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.)
426
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.
431
432    $ access mode
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.
436
437    $ accountability
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.)
442
443       (C) Accountability permits detection and subsequent investigation
444       of security breaches.
445
446
447
448
449
450 Shirey                       Informational                      [Page 8]
451 \f
452 RFC 2828               Internet Security Glossary               May 2000
453
454
455    $ accredit
456    $ accreditation
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.)
461
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
469       CAs.
470
471    $ ACL
472       See: access control list.
473
474    $ acquirer
475       (N) SET usage: "The financial institution that establishes an
476       account with a merchant and processes payment card authorizations
477       and payments." [SET1]
478
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]
482
483    $ active attack
484       See: (secondary definition under) attack.
485
486    $ active wiretapping
487       See: (secondary definition under) wiretapping.
488
489    $ add-on security
490       (I) "The retrofitting of protection mechanisms, implemented by
491       hardware or software, after the [automatic data processing] system
492       has become operational." [FP039]
493
494    $ administrative security
495       (I) Management procedures and constraints to prevent unauthorized
496       access to a system. (See: security architecture.)
497
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."
501       [FP039]
502
503
504
505
506 Shirey                       Informational                      [Page 9]
507 \f
508 RFC 2828               Internet Security Glossary               May 2000
509
510
511       (C) Examples include clear delineation and separation of duties,
512       and configuration control.
513
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.
518
519    $ adversary
520       (I) An entity that attacks, or is a threat to, a system.
521
522    $ aggregation
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.
526
527    $ AH
528       See: Authentication Header
529
530    $ algorithm
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.)
534
535    $ alias
536       (I) A name that an entity uses in place of its real name, usually
537       for the purpose of either anonymity or deception.
538
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
542       voluntary standards.
543
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
547       Commission (IEC).
548
549    $ anonymous
550       (I) The condition of having a name that is unknown or concealed.
551       (See: anonymous login.)
552
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
559
560
561
562 Shirey                       Informational                     [Page 10]
563 \f
564 RFC 2828               Internet Security Glossary               May 2000
565
566
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.
572
573    $ anonymous login
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).
580
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
591       character string.
592
593    $ APOP
594       See: POP3 APOP.
595
596    $ archive
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.)
602
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.
609
610    $ ARPANET
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.
615
616
617
618 Shirey                       Informational                     [Page 11]
619 \f
620 RFC 2828               Internet Security Glossary               May 2000
621
622
623    $ ASN.1
624       See: Abstract Syntax Notation One.
625
626    $ association
627       (I) A cooperative relationship between system entities, usually
628       for the purpose of transferring information between them. (See:
629       security association.)
630
631    $ assurance
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.
637
638    $ assurance level
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:
642       TCSEC.)
643
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.)
649
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.
657
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
662       decrypt the data.
663
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.
670
671
672
673
674 Shirey                       Informational                     [Page 12]
675 \f
676 RFC 2828               Internet Security Glossary               May 2000
677
678
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.
683
684    $ attack
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.)
690
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.)
695
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.
705
706       (C) The term "attack" relates to some other basic security terms
707       as shown in the following diagram:
708
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       + - - - - - - - - - - - - +  + - - - - +  + - - - - - - - - - - -+
720
721    $ attribute authority
722       (I) A CA that issues attribute certificates.
723
724       (O) "An authority, trusted by the verifier to delegate privilege,
725       which issues attribute certificates." [FPDAM]
726
727
728
729
730 Shirey                       Informational                     [Page 13]
731 \f
732 RFC 2828               Internet Security Glossary               May 2000
733
734
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
739       certificate. [X509]
740
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]
744
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]
750
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.
758
759       (C) An attribute certificate might be issued to a subject in the
760       following situations:
761
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.
766
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.)
772
773    $ audit service
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.)
777
778    $ audit trail
779       See: security audit trail.
780
781
782
783
784
785
786 Shirey                       Informational                     [Page 14]
787 \f
788 RFC 2828               Internet Security Glossary               May 2000
789
790
791    $ AUTH
792       See: POP3 AUTH.
793
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.)
797
798    $ authenticate
799       (I) Verify (i.e., establish the truth of) an identity claimed by
800       or for a system entity. (See: authentication.)
801
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.)
812
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.)
817
818    $ authentication
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.)
823
824       (C) An authentication process consists of two steps:
825
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.)
830
831       2. Verification step: Presenting or generating authentication
832          information that corroborates the binding between the entity
833          and the identifier. (See: verification.)
834
835       (C) See: ("relationship between data integrity service and
836       authentication services" under) data integrity service.
837
838
839
840
841
842 Shirey                       Informational                     [Page 15]
843 \f
844 RFC 2828               Internet Security Glossary               May 2000
845
846
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.)
855
856    $ authentication exchange
857       (I) A mechanism to verify the identity of an entity by means of
858       information exchange.
859
860       (O) "A mechanism intended to ensure the identity of an entity by
861       means of information exchange." [I7498 Part 2]
862
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.
868
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.
877
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.
887
888    $ authentication information
889       (I) Information used to verify an identity claimed by or for an
890       entity. (See: authentication, credential.)
891
892       (C) Authentication information may exist as, or be derived from,
893       one of the following:
894
895
896
897
898 Shirey                       Informational                     [Page 16]
899 \f
900 RFC 2828               Internet Security Glossary               May 2000
901
902
903        - Something the entity knows. (See: password).
904        - Something the entity possesses. (See: token.)
905        - Something the entity is. (See: biometric authentication.)
906
907    $ authentication service
908       (I) A security service that verifies an identity claimed by or for
909       an entity. (See: authentication.)
910
911       (C) In a network, there are two general forms of authentication
912       service: data origin authentication service and peer entity
913       authentication service.
914
915    $ authenticity
916       (I) The property of being genuine and able to be verified and be
917       trusted. (See: authenticate, authentication, validate vs. verify)
918
919    $ authority
920       (D) "An entity, responsible for the issuance of certificates."
921       [FPDAM]
922
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.
928
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).
934       (See: issue.)
935
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]
939       (See: authority.)
940
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
943       address.
944
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.)
950
951
952
953
954 Shirey                       Informational                     [Page 17]
955 \f
956 RFC 2828               Internet Security Glossary               May 2000
957
958
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]
962
963    $ authorization
964    $ authorize
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.
969       (See: privilege.)
970
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
979       process.)" [SET2]
980
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.
987
988    $ availability
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.)
995
996       (O) "The property of being accessible and usable upon demand by an
997       authorized entity." [I7498 Part 2]
998
999    $ availability service
1000       (I) A security service that protects a system to ensure its
1001       availability.
1002
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.
1007
1008
1009
1010 Shirey                       Informational                     [Page 18]
1011 \f
1012 RFC 2828               Internet Security Glossary               May 2000
1013
1014
1015    $ back door
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
1020       door.)
1021
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:
1027       trap door.)
1028
1029    $ back up vs. backup
1030       (I) Verb "back up": To store data for the purpose of creating a
1031       backup copy. (See: archive.)
1032
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.)
1038
1039    $ baggage
1040       (D) ISDs SHOULD NOT use this term to describe a data element
1041       except when stated as "SET(trademark) baggage" with the following
1042       meaning:
1043
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
1048       message." [SET2]
1049
1050    $ bandwidth
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.
1054
1055    $ bank identification number (BIN)
1056       (N) The digits of a credit card number that identify the issuing
1057       bank. (See: primary account number.)
1058
1059       (O) SET usage: The first six digits of a primary account number.
1060
1061
1062
1063
1064
1065
1066 Shirey                       Informational                     [Page 19]
1067 \f
1068 RFC 2828               Internet Security Glossary               May 2000
1069
1070
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.)
1074
1075    $ bastion host
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.
1080
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.
1092
1093    $ BCA
1094       See: brand certification authority.
1095
1096    $ BCI
1097       See: brand CRL identifier.
1098
1099    $ Bell-LaPadula Model
1100       (N) A formal, mathematical, state-transition model of security
1101       policy for multilevel-secure computer systems. [Bell]
1102
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.
1112
1113       (C) In this model, a multilevel-secure system satisfies several
1114       rules, including the following:
1115
1116
1117
1118
1119
1120
1121
1122 Shirey                       Informational                     [Page 20]
1123 \f
1124 RFC 2828               Internet Security Glossary               May 2000
1125
1126
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
1130          subject.
1131
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.
1135
1136        - "Tranquillity property": The classification of an object does
1137          not change while the object is being processed by the system.
1138
1139    $ BER
1140       See: Basic Encoding Rules.
1141
1142    $ beyond A1
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.
1148
1149    $ BIN
1150       See: bank identification number.
1151
1152    $ bind
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.
1156
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.
1162
1163    $ bit
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.
1167
1168    $ BLACK
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.)
1174
1175
1176
1177
1178 Shirey                       Informational                     [Page 21]
1179 \f
1180 RFC 2828               Internet Security Glossary               May 2000
1181
1182
1183    $ block cipher
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
1187       cipher.)
1188
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.
1193
1194    $ Blowfish
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]
1198
1199    $ brand
1200       (I) A distinctive mark or name that identifies a product or
1201       business entity.
1202
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
1209       merchants. [SET1]
1210
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
1214       hierarchy, SET.)
1215
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]
1220
1221    $ break
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.)
1228
1229
1230
1231
1232
1233
1234 Shirey                       Informational                     [Page 22]
1235 \f
1236 RFC 2828               Internet Security Glossary               May 2000
1237
1238
1239    $ bridge
1240       (I) A computer that is a gateway between two networks (usually two
1241       LANs) at OSI layer 2. (See: router.)
1242
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.
1251
1252    $ browser
1253       (I) An client computer program that can retrieve and display
1254       information from servers on the World Wide Web.
1255
1256       (C) For example, Netscape's Navigator and Communicator, and
1257       Microsoft's Explorer.
1258
1259    $ brute force
1260       (I) A cryptanalysis technique or other kind of attack method
1261       involving an exhaustive procedure that tries all possibilities,
1262       one-by-one.
1263
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
1267       key.
1268
1269    $ BS7799
1270       See: British Standard 7799.
1271
1272    $ byte
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.
1276       (See: octet.)
1277
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.
1281
1282    $ CA
1283       See: certification authority.
1284
1285
1286
1287
1288
1289
1290 Shirey                       Informational                     [Page 23]
1291 \f
1292 RFC 2828               Internet Security Glossary               May 2000
1293
1294
1295    $ CA certificate
1296       (I) "A [digital] certificate for one CA issued by another CA."
1297       [X509]
1298
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."
1304
1305    $ call back
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.
1310
1311    $ capability
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.)
1318
1319       (C) This concept can be implemented as a digital certificate.
1320       (See: attribute certificate.)
1321
1322    $ CAPI
1323       See: cryptographic application programming interface.
1324
1325    $ CAPSTONE chip
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.)
1331
1332    $ card
1333       See: cryptographic card, FORTEZZA card, payment card, PC card,
1334       smart card, token.
1335
1336    $ card backup
1337       See: token backup.
1338
1339    $ card copy
1340       See: token copy.
1341
1342
1343
1344
1345
1346 Shirey                       Informational                     [Page 24]
1347 \f
1348 RFC 2828               Internet Security Glossary               May 2000
1349
1350
1351    $ card restore
1352       See: token restore.
1353
1354    $ cardholder
1355       (I) An entity that has been issued a card.
1356
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]
1362
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.
1370       [SET1]
1371
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]
1380
1381    $ CAST
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]
1385
1386    $ category
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.)
1390
1391    $ CAW
1392       See: certification authority workstation.
1393
1394    $ CBC
1395       See: cipher block chaining.
1396
1397    $ CCA
1398       See: cardholder certification authority.
1399
1400
1401
1402 Shirey                       Informational                     [Page 25]
1403 \f
1404 RFC 2828               Internet Security Glossary               May 2000
1405
1406
1407    $ CCITT
1408       (N) Acronym for French translation of International Telephone and
1409       Telegraph Consultative Committee. Now renamed ITU-T.
1410
1411    $ CERT
1412       See: computer emergency response team.
1413
1414    $ certificate
1415       (I) General English usage: A document that attests to the truth of
1416       something or the ownership of something.
1417
1418       (C) Security usage: See: capability, digital certificate.
1419
1420       (C) PKI usage: See: attribute certificate, public-key certificate.
1421
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
1425       X.509.
1426
1427    $ certificate chain
1428       (D) ISDs SHOULD NOT use this term because it duplicates the
1429       meaning of a standardized term. Instead, use "certification path".
1430
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.
1436       verify.)
1437
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.)
1441
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.)
1446
1447    $ certificate extension
1448       See: extension.
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458 Shirey                       Informational                     [Page 26]
1459 \f
1460 RFC 2828               Internet Security Glossary               May 2000
1461
1462
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.)
1469
1470    $ certificate management
1471       (I) The functions that a CA may perform during the life cycle of a
1472       digital certificate, including the following:
1473
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.
1479
1480       (See: archive management, certificate management, key management,
1481       security architecture, token management.)
1482
1483    $ certificate owner
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.)
1489
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.)
1495
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]
1502
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.
1508
1509
1510
1511
1512
1513
1514 Shirey                       Informational                     [Page 27]
1515 \f
1516 RFC 2828               Internet Security Glossary               May 2000
1517
1518
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.)
1523
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.
1528
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.
1533
1534    $ certificate rekey
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.)
1539
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
1545       update".
1546
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.
1557
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
1562       update.)
1563
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
1567
1568
1569
1570 Shirey                       Informational                     [Page 28]
1571 \f
1572 RFC 2828               Internet Security Glossary               May 2000
1573
1574
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".
1579
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".
1584
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.
1589
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
1593       expiration.
1594
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.)
1600
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]
1610
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.)
1616
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.
1622
1623
1624
1625
1626 Shirey                       Informational                     [Page 29]
1627 \f
1628 RFC 2828               Internet Security Glossary               May 2000
1629
1630
1631       (O) "An integer value, unique within the issuing CA, which is
1632       unambiguously associated with a certificate issued by that CA."
1633       [X509]
1634
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.)
1640
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.)
1646
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".)
1652
1653    $ certificate user
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.)
1657
1658       (O) "An entity that needs to know, with certainty, the public key
1659       of another entity." [X509]
1660
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
1663       organization.
1664
1665       (D) ISDs SHOULD NOT use this term as a synonym for the "subject"
1666       of a certificate.
1667
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.)
1672
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]
1677
1678
1679
1680
1681
1682 Shirey                       Informational                     [Page 30]
1683 \f
1684 RFC 2828               Internet Security Glossary               May 2000
1685
1686
1687       (C) To validate a certificate, a certificate user checks that the
1688       certificate is properly formed and signed and currently in force:
1689
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.
1698
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.
1703
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.)
1710
1711    $ certification
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.)
1717
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.)
1721
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.)
1728
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]
1735
1736
1737
1738 Shirey                       Informational                     [Page 31]
1739 \f
1740 RFC 2828               Internet Security Glossary               May 2000
1741
1742
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
1746       in a certificate.
1747
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]
1751
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).
1761
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
1765       as required.
1766
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.)
1771
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.
1782
1783       (O) MISSI usage: A MISSI certification hierarchy has three or four
1784       levels of CAs:
1785
1786        - A CA at the highest level, the top CA, is a "policy approving
1787          authority".
1788        - A CA at the second-highest level is a "policy creation
1789          authority".
1790
1791
1792
1793
1794 Shirey                       Informational                     [Page 32]
1795 \f
1796 RFC 2828               Internet Security Glossary               May 2000
1797
1798
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".
1803
1804       (O) PEM usage: A PEM certification hierarchy has three levels of
1805       CAs [R1422]:
1806
1807        - The highest level is the "Internet Policy Registration
1808          Authority".
1809        - A CA at the second-highest level is a "policy certification
1810          authority".
1811        - A CA at the third-highest level is a "certification authority".
1812
1813       (O) SET usage: A SET certification hierarchy has three or four
1814       levels of CAs:
1815
1816        - The highest level is a "SET root CA".
1817        - A CA at the second-highest level is a "brand certification
1818          authority".
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".
1823
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.)
1832
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]
1837
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
1845       signed.
1846
1847
1848
1849
1850 Shirey                       Informational                     [Page 33]
1851 \f
1852 RFC 2828               Internet Security Glossary               May 2000
1853
1854
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.
1863
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.
1868
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
1872       policy.)
1873
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]
1883
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]
1891
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
1898       certificate.
1899
1900
1901
1902
1903
1904
1905
1906 Shirey                       Informational                     [Page 34]
1907 \f
1908 RFC 2828               Internet Security Glossary               May 2000
1909
1910
1911    $ certify
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:
1916       certification.)
1917
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.
1921
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.
1924
1925       (C) A description of the measures used for verification should be
1926       included in the CA's CPS.
1927
1928    $ CFB
1929       See: cipher feedback.
1930
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.)
1936
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.
1943
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.)
1948
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.
1954
1955    $ channel
1956       (I) An information transfer path within a system. (See: covert
1957       channel.)
1958
1959
1960
1961
1962 Shirey                       Informational                     [Page 35]
1963 \f
1964 RFC 2828               Internet Security Glossary               May 2000
1965
1966
1967    $ CHAP
1968       See: Challenge Handshake Authentication Protocol.
1969
1970    $ checksum
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.)
1976
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
1980       object.
1981
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,
1990       keyed hash).
1991
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.
1996
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.
2001
2002    $ CIAC
2003       See: Computer Incident Advisory Capability.
2004
2005    $ CIK
2006       See: cryptographic ignition key.
2007
2008    $ cipher
2009       (I) A cryptographic algorithm for encryption and decryption.
2010
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:
2014       [R1829], [R2451].)
2015
2016
2017
2018 Shirey                       Informational                     [Page 36]
2019 \f
2020 RFC 2828               Internet Security Glossary               May 2000
2021
2022
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.
2026
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]
2032
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
2038       ciphertext segment.
2039
2040    $ ciphertext
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.)
2044
2045       (O) "Data produced through the use of encipherment. The semantic
2046       content of the resulting data is not available." [I7498 Part 2]
2047
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
2054       plaintext words.)
2055
2056    $ CIPSO
2057       See: Common IP Security Option.
2058
2059    $ CKL
2060       See: compromised key list.
2061
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]:
2065
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.
2069
2070
2071
2072
2073
2074 Shirey                       Informational                     [Page 37]
2075 \f
2076 RFC 2828               Internet Security Glossary               May 2000
2077
2078
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
2082          an organization.
2083
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
2088          material.
2089
2090        - Class 5: For handling high-value information in a high-risk
2091          environment.
2092
2093    $ classification
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.)
2099
2100    $ classified
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.)
2106
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.
2115
2116    $ clean system
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.
2120
2121       (C) A clean system is not necessarily in a secure state.
2122
2123    $ clearance
2124       See: security clearance.
2125
2126
2127
2128
2129
2130 Shirey                       Informational                     [Page 38]
2131 \f
2132 RFC 2828               Internet Security Glossary               May 2000
2133
2134
2135    $ clearance level
2136       (I) The security level of information to which a security
2137       clearance authorizes a person to have access.
2138
2139    $ cleartext
2140       (I) Data in which the semantic information content (i.e., the
2141       meaning) is intelligible or is directly available. (See:
2142       plaintext.)
2143
2144       (O) "Intelligible data, the semantic content of which is
2145       available." [I7498 Part 2]
2146
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.)
2151
2152    $ client
2153       (I) A system entity that requests and uses a service provided by
2154       another system entity, called a "server". (See: server.)
2155
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.
2159
2160    $ CLIPPER chip
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.)
2165
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
2171       Department.
2172
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.)
2183
2184
2185
2186 Shirey                       Informational                     [Page 39]
2187 \f
2188 RFC 2828               Internet Security Glossary               May 2000
2189
2190
2191    $ code
2192       (I) noun: A system of symbols used to represent information, which
2193       might originally have some other representation. (See: encode.)
2194
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.
2199
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.
2205
2206    $ color change
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.
2210
2211    $ Common Criteria
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
2217       measures. [CCIB]
2218
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.)
2231
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
2239
2240
2241
2242 Shirey                       Informational                     [Page 40]
2243 \f
2244 RFC 2828               Internet Security Glossary               May 2000
2245
2246
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.
2252
2253    $ Common IP Security Option (CIPSO)
2254       See: (secondary definition under) Internet Protocol Security
2255       Option.
2256
2257    $ common name
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.)
2265
2266       (C) For example, "Dr. E. F. Moore", "The United Nations", or
2267       "12-th Floor Laser Printer".
2268
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.
2274
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.
2278
2279    $ community string
2280       (I) A community name in the form of an octet string that serves as
2281       a cleartext password in SNMP version 1. [R1157]
2282
2283    $ compartment
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.)
2287
2288       (C) The term is usually understood to include the special handling
2289       procedures to be used for the information.
2290
2291    $ compromise
2292       See: data compromise, security compromise.
2293
2294
2295
2296
2297
2298 Shirey                       Informational                     [Page 41]
2299 \f
2300 RFC 2828               Internet Security Glossary               May 2000
2301
2302
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:
2306       compromise.)
2307
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.
2311
2312    $ COMPUSEC
2313       See: computer security.
2314
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.)
2321
2322       (C) For example, the CERT Coordination Center at Carnegie-Mellon
2323       University (sometimes called "the" CERT) and the Computer Incident
2324       Advisory Capability.
2325
2326    $ Computer Incident Advisory Capability (CIAC)
2327       (N) A computer emergency response team in the U.S. Department of
2328       Energy.
2329
2330    $ computer network
2331       (I) A collection of host computers together with the subnetwork or
2332       internetwork through which they can exchange data.
2333
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
2337       another computer.
2338
2339    $ computer security (COMPUSEC)
2340       (I) Measures that implement and assure security services in a
2341       computer system, particularly those that assure access control
2342       service.
2343
2344       (C) Usually understood to include functions, features, and
2345       technical characteristics of computer hardware and software,
2346       especially operating systems.
2347
2348
2349
2350
2351
2352
2353
2354 Shirey                       Informational                     [Page 42]
2355 \f
2356 RFC 2828               Internet Security Glossary               May 2000
2357
2358
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.)
2363
2364       (C) To be considered a CSIRT, an organization must do as follows:
2365
2366        - Provide a (secure) channel for receiving reports about
2367          suspected security incidents.
2368        - Provide assistance to members of its constituency in handling
2369          the incidents.
2370        - Disseminate incident-related information to its constituency
2371          and other involved parties.
2372
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
2379       Register.)
2380
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.
2387
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)
2395       csor(3)}.
2396
2397    $ COMSEC
2398       See: communication security.
2399
2400    $ confidentiality
2401       See: data confidentiality.
2402
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.)
2407
2408
2409
2410 Shirey                       Informational                     [Page 43]
2411 \f
2412 RFC 2828               Internet Security Glossary               May 2000
2413
2414
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.)
2418
2419    $ confinement property
2420       See: (secondary definition under) Bell-LaPadula Model.
2421
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
2426       datagrams.
2427
2428       (C) A connection-oriented data integrity service would be able to
2429       detect lost or reordered datagrams within a stream of datagrams.
2430
2431    $ contingency plan
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.)
2436
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]
2442
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
2450       mode".
2451
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
2461       system.
2462
2463
2464
2465
2466 Shirey                       Informational                     [Page 44]
2467 \f
2468 RFC 2828               Internet Security Glossary               May 2000
2469
2470
2471    $ cookie
2472       (I) access control usage: A synonym for "capability" or "ticket"
2473       in an access control system.
2474
2475       (I) IPsec usage: Data exchanged by ISAKMP to prevent certain
2476       denial-of-service attacks during the establishment of a security
2477       association.
2478
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.
2482
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.
2493
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.)
2499
2500    $ copy
2501       See: card copy.
2502
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,
2507       source integrity.)
2508
2509    $ correctness proof
2510       (I) A mathematical proof of consistency between a specification
2511       for system security and the implementation of that specification.
2512       (See: formal specification.)
2513
2514    $ countermeasure
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.
2519
2520
2521
2522 Shirey                       Informational                     [Page 45]
2523 \f
2524 RFC 2828               Internet Security Glossary               May 2000
2525
2526
2527       (C) In an Internet protocol, a countermeasure may take the form of
2528       a protocol feature, an element function, or a usage constraint.
2529
2530    $ country code
2531       (I) An identifier that is defined for a nation by ISO. [I3166]
2532
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.
2537
2538    $ covert channel
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.)
2543
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]
2547
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:
2553
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.
2558
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.
2563
2564    $ CPS
2565       See: certification practice statement.
2566
2567    $ cracker
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.)
2571
2572    $ CRAM
2573       See: Challenge-Response Authentication Mechanism.
2574
2575
2576
2577
2578 Shirey                       Informational                     [Page 46]
2579 \f
2580 RFC 2828               Internet Security Glossary               May 2000
2581
2582
2583    $ CRC
2584       See: cyclic redundancy check.
2585
2586    $ credential(s)
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.)
2590
2591       (O) "Data that is transferred to establish the claimed identity of
2592       an entity." [I7498 Part 2]
2593
2594    $ critical
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.)
2600
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).
2610
2611    $ CRL
2612       See: certificate revocation list.
2613
2614    $ CRL distribution point
2615       See: distribution point.
2616
2617    $ CRL extension
2618       See: extension.
2619
2620    $ cross-certificate
2621       See: cross-certification.
2622
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.
2626
2627       (C) Cross-certification enables users to validate each other's
2628       certificate when the users are certified under different
2629       certification hierarchies.
2630
2631
2632
2633
2634 Shirey                       Informational                     [Page 47]
2635 \f
2636 RFC 2828               Internet Security Glossary               May 2000
2637
2638
2639    $ cryptanalysis
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.
2643       (See: cryptology.)
2644
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]
2648
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.
2660
2661    $ crypto
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
2665       "cryptographic".
2666
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.
2671
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].
2677
2678    $ cryptographic card
2679       (I) A cryptographic token in the form of a smart card or a PC
2680       card.
2681
2682    $ cryptographic component
2683       (I) A generic term for any system component that involves
2684       cryptography. (See: cryptographic module.)
2685
2686
2687
2688
2689
2690 Shirey                       Informational                     [Page 48]
2691 \f
2692 RFC 2828               Internet Security Glossary               May 2000
2693
2694
2695    $ cryptographic hash
2696       See: (secondary definition under) hash function.
2697
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".)
2702
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.
2707
2708    $ cryptographic key
2709       (I) Usually shortened to just "key". An input parameter that
2710       varies the transformation performed by a cryptographic algorithm.
2711
2712       (O) "A sequence of symbols that controls the operations of
2713       encipherment and decipherment." [I7498 Part 2]
2714
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.)
2719
2720    $ Cryptographic Message Syntax (CMS)
2721       (I) A encapsulation syntax for digital signatures, hashes, and
2722       encryption of arbitrary messages. [R2630]
2723
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.
2729
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
2736       module. [FP140]
2737
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.
2742
2743
2744
2745
2746 Shirey                       Informational                     [Page 49]
2747 \f
2748 RFC 2828               Internet Security Glossary               May 2000
2749
2750
2751       (C) This "I" definition covers a wider range of algorithms than
2752       the following "O" definition:
2753
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."
2759       [X509]
2760
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.)
2765
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.
2771
2772    $ cryptography
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.)
2779
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]
2785
2786    $ Cryptoki
2787       See: (secondary definition under) PKCS #11.
2788
2789    $ cryptology
2790       (I) The science that includes both cryptography and cryptanalysis,
2791       and sometimes is said to include steganography.
2792
2793    $ cryptonet
2794       (I) A group of system entities that share a secret cryptographic
2795       key for a symmetric algorithm.
2796
2797
2798
2799
2800
2801
2802 Shirey                       Informational                     [Page 50]
2803 \f
2804 RFC 2828               Internet Security Glossary               May 2000
2805
2806
2807    $ cryptoperiod
2808       (I) The time span during which a particular key is authorized to
2809       be used in a cryptographic system. (See: key management.)
2810
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.
2816
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.
2821
2822    $ cryptosystem
2823       (D) ISDs SHOULD NOT use this term as an abbreviation for
2824       cryptographic system. (For rationale, see: crypto.)
2825
2826    $ CSIRT
2827       See: computer security incident response team.
2828
2829    $ CSOR
2830       See: Computer Security Objects Register.
2831
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.
2837
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
2842       are expected.
2843
2844    $ DAC
2845       See: Data Authentication Code, discretionary access control.
2846
2847    $ DASS
2848       See: Distributed Authentication Security Service.
2849
2850    $ data
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.
2854
2855
2856
2857
2858 Shirey                       Informational                     [Page 51]
2859 \f
2860 RFC 2828               Internet Security Glossary               May 2000
2861
2862
2863    $ Data Authentication Algorithm
2864       (N) A keyed hash function equivalent to DES cipher block chaining
2865       with IV = 0. [A9009]
2866
2867       (D) ISDs SHOULD NOT use the uncapitalized form of this term as a
2868       synonym for other kinds of checksums.
2869
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].)
2875
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.
2882
2883    $ data compromise
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:
2887       compromise.)
2888
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.)
2894
2895       (D) ISDs SHOULD NOT use this term as a synonym for "privacy",
2896       which is a different concept.
2897
2898    $ data confidentiality service
2899       (I) A security service that protects data against unauthorized
2900       disclosure. (See: data confidentiality.)
2901
2902       (D) ISDs SHOULD NOT use this term as a synonym for "privacy",
2903       which is a different concept.
2904
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.)
2911
2912
2913
2914 Shirey                       Informational                     [Page 52]
2915 \f
2916 RFC 2828               Internet Security Glossary               May 2000
2917
2918
2919       (C) This algorithm is usually referred to as "DES". The algorithm
2920       has also been adopted in standards outside the Government (e.g.,
2921       [A3092]).
2922
2923    $ data encryption key (DEK)
2924       (I) A cryptographic key that is used to encipher application data.
2925       (See: key-encrypting key.)
2926
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.)
2931
2932    $ data integrity
2933       (I) The property that data has not been changed, destroyed, or
2934       lost in an unauthorized or accidental manner. (See: data integrity
2935       service.)
2936
2937       (O) "The property that information has not been modified or
2938       destroyed in an unauthorized manner." [I7498 Part 2]
2939
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).
2944
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.)
2950
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.
2956
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
2966
2967
2968
2969
2970 Shirey                       Informational                     [Page 53]
2971 \f
2972 RFC 2828               Internet Security Glossary               May 2000
2973
2974
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.
2978
2979    $ data origin authentication
2980       (I) "The corroboration that the source of data received is as
2981       claimed." [I7498 Part 2] (See: authentication.)
2982
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.)
2987
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.
2993
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.
2998
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.
3002
3003    $ data privacy
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.
3007
3008    $ data security
3009       (I) The protection of data from disclosure, alteration,
3010       destruction, or loss that either is accidental or is intentional
3011       but unauthorized.
3012
3013       (C) Both data confidentiality service and data integrity service
3014       are needed to achieve data security.
3015
3016    $ datagram
3017       (I) "A self-contained, independent entity of data carrying
3018       sufficient information to be routed from the source to the
3019       destination." [R1983]
3020
3021    $ DEA
3022       See: Data Encryption Algorithm.
3023
3024
3025
3026 Shirey                       Informational                     [Page 54]
3027 \f
3028 RFC 2828               Internet Security Glossary               May 2000
3029
3030
3031    $ deception
3032       See: (secondary definition under) threat consequence.
3033
3034    $ decipher
3035       (D) ISDs SHOULD NOT use this term as a synonym for "decrypt",
3036       except in special circumstances. (See: (usage discussion under)
3037       encryption.)
3038
3039    $ decipherment
3040       (D) ISDs SHOULD NOT use this term as a synonym for "decryption",
3041       except in special circumstances. (See: (usage discussion under)
3042       encryption.)
3043
3044    $ decode
3045       (I) Convert encoded data back to its original form of
3046       representation. (See: decrypt.)
3047
3048       (D) ISDs SHOULD NOT use this term as a synonym for "decrypt",
3049       because that would mix concepts in a potentially misleading way.
3050
3051    $ decrypt
3052       (I) Cryptographically restore ciphertext to the plaintext form it
3053       had before encryption.
3054
3055    $ decryption
3056       See: (secondary definition under) encryption.
3057
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]
3064
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.
3068
3069    $ default account
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.
3073
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.
3078
3079
3080
3081
3082 Shirey                       Informational                     [Page 55]
3083 \f
3084 RFC 2828               Internet Security Glossary               May 2000
3085
3086
3087    $ degauss
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.
3092
3093    $ degausser
3094       (N) An electrical device that can degauss magnetic storage media.
3095
3096    $ DEK
3097       See: data encryption key.
3098
3099    $ delta CRL
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.
3104
3105    $ denial of service
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.)
3109
3110    $ DES
3111       See: Data Encryption Standard.
3112
3113    $ dictionary attack
3114       (I) An attack that uses a brute-force technique of successively
3115       trying all the words in some large, exhaustive list.
3116
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
3121       obtained by lookup.
3122
3123    $ Diffie-Hellman
3124       (N) A key agreement algorithm published in 1976 by Whitfield
3125       Diffie and Martin Hellman [DH76, R2631].
3126
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.
3130
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
3135
3136
3137
3138 Shirey                       Informational                     [Page 56]
3139 \f
3140 RFC 2828               Internet Security Glossary               May 2000
3141
3142
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.
3153
3154    $ digest
3155       See: message digest.
3156
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.)
3162
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
3166       those meanings.
3167
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
3174       certified.
3175
3176    $ digital document
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
3180       type.
3181
3182    $ digital envelope
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.
3187
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.
3191
3192
3193
3194 Shirey                       Informational                     [Page 57]
3195 \f
3196 RFC 2828               Internet Security Glossary               May 2000
3197
3198
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.
3210
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.)
3221
3222    $ digital key
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.
3227
3228    $ digital notary
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:
3233       notarization.)
3234
3235    $ digital signature
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.)
3241
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]
3246
3247
3248
3249
3250 Shirey                       Informational                     [Page 58]
3251 \f
3252 RFC 2828               Internet Security Glossary               May 2000
3253
3254
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
3264       signer.
3265
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.
3277
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
3285       usage.
3286
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.)
3293
3294    $ Digital Signature Standard (DSS)
3295       (N) The U.S. Government standard [FP186] that specifies the
3296       Digital Signature Algorithm (DSA), which involves asymmetric
3297       cryptography.
3298
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.
3303
3304
3305
3306 Shirey                       Informational                     [Page 59]
3307 \f
3308 RFC 2828               Internet Security Glossary               May 2000
3309
3310
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
3317       rights. [ACM]
3318
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".
3325
3326    $ directory
3327    $ Directory
3328       See: directory vs. Directory.
3329
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.)
3334
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
3339       known.
3340
3341       2. (I) Capitalized: "Directory" refers specifically to the X.500
3342       Directory. (See: repository.)
3343
3344    $ disaster plan
3345       (D) A synonym for "contingency plan". In the interest of
3346       consistency, ISDs SHOULD use "contingency plan" instead of
3347       "disaster plan".
3348
3349    $ disclosure (i.e., unauthorized disclosure)
3350       See: (secondary definition under) threat consequence.
3351
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.)
3357
3358
3359
3360
3361
3362 Shirey                       Informational                     [Page 60]
3363 \f
3364 RFC 2828               Internet Security Glossary               May 2000
3365
3366
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.
3370
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]
3376
3377    $ disruption
3378       See: (secondary definition under) threat consequence.
3379
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].
3383
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.
3387
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.)
3391
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.
3397
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.
3402
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.
3407
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
3414
3415
3416
3417
3418 Shirey                       Informational                     [Page 61]
3419 \f
3420 RFC 2828               Internet Security Glossary               May 2000
3421
3422
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.
3426
3427    $ DN
3428       See: distinguished name.
3429
3430    $ DNS
3431       See: Domain Name System.
3432
3433    $ DOI
3434       See: Domain of Interpretation.
3435
3436    $ domain
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.)
3442
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.)
3448
3449       (O) MISSI usage: The domain of a MISSI CA is the set of MISSI
3450       users whose certificates are signed by the CA.
3451
3452       (O) OSI usage: An administrative partition of a complex
3453       distributed OSI system.
3454
3455    $ domain name
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,
3462       domain.)
3463
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
3471
3472
3473
3474 Shirey                       Informational                     [Page 62]
3475 \f
3476 RFC 2828               Internet Security Glossary               May 2000
3477
3478
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.)
3483
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]
3490
3491       (C) The DNS has three major components:
3492
3493        - Domain name space and resource records: Specifications for the
3494          tree-structured domain name space, and data associated with the
3495          names.
3496
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
3500          part of the tree.
3501
3502        - Resolvers: Programs that extract information from name servers
3503          in response to client requests; typically, system routines
3504          directly accessible to user programs.
3505
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.
3512
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
3517       and modes.
3518
3519       (C) For example, see [R2407]. The DOI concept is based on work by
3520       the TSIG's CIPSO Working Group.
3521
3522    $ dominate
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
3526       all of those of B.
3527
3528
3529
3530 Shirey                       Informational                     [Page 63]
3531 \f
3532 RFC 2828               Internet Security Glossary               May 2000
3533
3534
3535    $ dongle
3536       (I) A portable, physical, electronic device that is required to be
3537       attached to a computer to enable a particular software program to
3538       run. (See: token.)
3539
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
3547       personal computer.
3548
3549    $ downgrade
3550       (I) Reduce the classification level of information in an
3551       authorized manner.
3552
3553    $ draft RFC
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
3557       Standard).)
3558
3559    $ DSA
3560       See: Digital Signature Algorithm.
3561
3562    $ DSS
3563       See: Digital Signature Standard.
3564
3565    $ dual control
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.)
3570
3571    $ dual signature
3572       (D) ISDs SHOULD NOT use this term except when stated as
3573       "SET(trademark) dual signature" with the following meaning:
3574
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]
3578
3579
3580
3581
3582
3583
3584
3585
3586 Shirey                       Informational                     [Page 64]
3587 \f
3588 RFC 2828               Internet Security Glossary               May 2000
3589
3590
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.
3596
3597    $ EAP
3598       See: Extensible Authentication Protocol
3599
3600    $ eavesdropping
3601       (I) Passive wiretapping done secretly, i.e., without the knowledge
3602       of the originator or the intended recipients of the communication.
3603
3604    $ ECB
3605       See: electronic codebook.
3606
3607    $ ECDSA
3608       See: Elliptic Curve Digital Signature Algorithm.
3609
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.)
3616
3617    $ EDI
3618       See: electronic data interchange.
3619
3620    $ EDIFACT
3621       See: (secondary definition under) electronic data interchange.
3622
3623    $ EE
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.
3627
3628    $ EES
3629       See: Escrowed Encryption Standard.
3630
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]
3636
3637
3638
3639
3640
3641
3642 Shirey                       Informational                     [Page 65]
3643 \f
3644 RFC 2828               Internet Security Glossary               May 2000
3645
3646
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].
3651
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.
3657
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]
3661
3662    $ electronic data interchange (EDI)
3663       (I) Computer-to-computer exchange, between trading partners, of
3664       business data in standardized document formats.
3665
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.
3671
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.)
3675
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.
3679
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.)
3691
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.
3695
3696
3697
3698 Shirey                       Informational                     [Page 66]
3699 \f
3700 RFC 2828               Internet Security Glossary               May 2000
3701
3702
3703    $ emanation
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.)
3708
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.
3713
3714    $ emergency plan
3715       (D) A synonym for "contingency plan". In the interest of
3716       consistency, ISDs SHOULD use "contingency plan" instead of
3717       "emergency plan".
3718
3719    $ EMSEC
3720       See: emanations security.
3721
3722    $ EMV
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]
3726
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.)
3731
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.
3744
3745    $ encipher
3746       (D) ISDs SHOULD NOT use this term as a synonym for "encrypt".
3747       However, see the usage note under "encryption".
3748
3749
3750
3751
3752
3753
3754 Shirey                       Informational                     [Page 67]
3755 \f
3756 RFC 2828               Internet Security Glossary               May 2000
3757
3758
3759    $ encipherment
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".
3763
3764    $ encode
3765       (I) Use a system of symbols to represent information, which might
3766       originally have some other representation. (See: decode.)
3767
3768       (C) Examples include Morse code, ASCII, and BER.
3769
3770       (D) ISDs SHOULD NOT use this term as a synonym for "encrypt",
3771       because encoding is not usually intended to conceal meaning.
3772
3773    $ encrypt
3774       (I) Cryptographically transform data to produce ciphertext. (See:
3775       encryption.)
3776
3777    $ encryption
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.)
3784
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).
3791
3792       (O) "The cryptographic transformation of data (see: cryptography)
3793       to produce ciphertext." [I7498 Part 2]
3794
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:
3798       superencryption.)
3799
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
3805       algorithm.
3806
3807
3808
3809
3810 Shirey                       Informational                     [Page 68]
3811 \f
3812 RFC 2828               Internet Security Glossary               May 2000
3813
3814
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.
3819
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.
3823
3824    $ end entity
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.
3829
3830       (D) "A certificate subject which uses its public [sic] key for
3831       purposes other than signing certificates." [X509]
3832
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".
3844
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.
3852
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".
3859
3860
3861
3862
3863
3864
3865
3866 Shirey                       Informational                     [Page 69]
3867 \f
3868 RFC 2828               Internet Security Glossary               May 2000
3869
3870
3871    $ end system
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".)
3875
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,
3882       wiretapping.)
3883
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.
3889
3890    $ end user
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.
3894
3895       (I) PKI usage: A synonym for "end entity"; but the term "end
3896       entity" is preferred.
3897
3898    $ entity
3899       See: system entity.
3900
3901    $ entrapment
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.)
3905
3906    $ ephemeral key
3907       (I) A public key or a private key that is relatively short-lived.
3908       (See: session key.)
3909
3910    $ error detection code
3911       (I) A checksum designed to detect, but not correct, accidental
3912       (i.e., unintentional) changes in data.
3913
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
3917
3918
3919
3920
3921
3922 Shirey                       Informational                     [Page 70]
3923 \f
3924 RFC 2828               Internet Security Glossary               May 2000
3925
3926
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.
3930
3931       (C) Both SKIPJACK and the LEAF are to be implemented in equipment
3932       used to encrypt and decrypt unclassified, sensitive
3933       telecommunications data.
3934
3935    $ ESP
3936       See: Encapsulating Security Payload.
3937
3938    $ Estelle
3939       (N) A language (ISO 9074-1989) for formal specification of
3940       computer network protocols.
3941
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.
3946
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".
3953
3954    $ evaluated system
3955       (I) Refers to a system that has been evaluated against security
3956       criteria such as the TCSEC or the Common Criteria.
3957
3958    $ expire
3959       See: certificate expiration.
3960
3961    $ exposure
3962       See: (secondary definition under) threat consequence.
3963
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]
3968
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
3971       or dial-up lines.
3972
3973
3974
3975
3976
3977
3978 Shirey                       Informational                     [Page 71]
3979 \f
3980 RFC 2828               Internet Security Glossary               May 2000
3981
3982
3983    $ extension
3984       (I) A data item defined for optional inclusion in a v3 X.509
3985       public-key certificate or a v2 X.509 CRL.
3986
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:
3990
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.
3995
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.
4000
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
4004          extensions.)
4005
4006    $ extranet
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.)
4010
4011       (C) An extranet can be implemented securely, either on the
4012       Internet or using Internet technology, by constructing the
4013       extranet as a VPN.
4014
4015    $ fail safe
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.
4019
4020    $ fail soft
4021       (I) Selective termination of affected non-essential system
4022       functions and processes when a failure occurs or is detected in
4023       the system.
4024
4025    $ failure control
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]
4029
4030
4031
4032
4033
4034 Shirey                       Informational                     [Page 72]
4035 \f
4036 RFC 2828               Internet Security Glossary               May 2000
4037
4038
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]
4046
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.
4050
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]
4059
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.
4067
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.
4071
4072    $ filtering router
4073       (I) An internetwork router that selectively prevents the passage
4074       of data packets according to a security policy.
4075
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
4084       numbers). [R2179]
4085
4086
4087
4088
4089
4090 Shirey                       Informational                     [Page 73]
4091 \f
4092 RFC 2828               Internet Security Glossary               May 2000
4093
4094
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."
4099       [SET2]
4100
4101    $ fingerprint
4102       (I) A pattern of curves formed by the ridges on a fingertip. (See:
4103       biometric authentication, thumbprint.)
4104
4105       (D) ISDs SHOULD NOT use this term as a synonym for "hash result"
4106       because it mixes concepts in a potentially misleading way.
4107
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
4111       result":
4112
4113       (O) PGP usage: A hash result used to authenticate a public key
4114       (key fingerprint) or other data. [PGP]
4115
4116    $ FIPS
4117       See: Federal Information Processing Standards.
4118
4119    $ FIPS PUB 140-1
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.)
4124
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.
4134
4135    $ firewall
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
4141       gateway.)
4142
4143
4144
4145
4146 Shirey                       Informational                     [Page 74]
4147 \f
4148 RFC 2828               Internet Security Glossary               May 2000
4149
4150
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
4156       protected network.
4157
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.
4171
4172    $ firmware
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,
4177       software.)
4178
4179    $ FIRST
4180       See: Forum of Incident Response and Security Teams.
4181
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.
4190       [NCS04]
4191
4192    $ flooding
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.)
4197
4198
4199
4200
4201
4202 Shirey                       Informational                     [Page 75]
4203 \f
4204 RFC 2828               Internet Security Glossary               May 2000
4205
4206
4207    $ flow analysis
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.
4212
4213    $ flow control
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
4218       property.)
4219
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.
4225
4226    $ formulary
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.
4230
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.
4238
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.)
4243
4244       (C) FIRST was founded in 1990 and, as of September 1999, had
4245       nearly 70 members spanning the globe. Its mission includes:
4246
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.
4254
4255
4256
4257
4258 Shirey                       Informational                     [Page 76]
4259 \f
4260 RFC 2828               Internet Security Glossary               May 2000
4261
4262
4263    $ forward secrecy
4264       See: public-key forward secrecy.
4265
4266    $ FPKI
4267       See: Federal Public-Key Infrastructure.
4268
4269    $ FTP
4270       See: File Transfer Protocol.
4271
4272    $ gateway
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
4279       subnetwork.)
4280
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).
4287
4288    $ GCA
4289       See: geopolitical certificate authority.
4290
4291    $ GeneralizedTime
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,
4297       UTCTime.)
4298
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.
4306
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
4310
4311
4312
4313
4314 Shirey                       Informational                     [Page 77]
4315 \f
4316 RFC 2828               Internet Security Glossary               May 2000
4317
4318
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]
4323
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.
4331
4332    $ Green Book
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
4337       Series.)
4338
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:
4346
4347        - Each volume of 1992 ITU-T (at that time, CCITT) standards.
4348        - "PostScript Language Program Design", Adobe Systems, Addison-
4349          Wesley, 1988.
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.
4355
4356    $ GRIP
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.)
4361
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.
4367
4368
4369
4370 Shirey                       Informational                     [Page 78]
4371 \f
4372 RFC 2828               Internet Security Glossary               May 2000
4373
4374
4375    $ GSS-API
4376       See: Generic Security Service Application Program Interface.
4377
4378    $ guard
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.
4386       (See: firewall.)
4387
4388    $ guest login
4389       See: anonymous login.
4390
4391    $ GULS
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.
4396
4397    $ hacker
4398       (I) Someone with a strong interest in computers, who enjoys
4399       learning about them and experimenting with them. (See: cracker.)
4400
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.
4406
4407    $ handle
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.
4413
4414    $ hardware
4415       (I) The material physical components of a computer system. (See:
4416       firmware, software.)
4417
4418    $ hardware token
4419       See: token.
4420
4421
4422
4423
4424
4425
4426 Shirey                       Informational                     [Page 79]
4427 \f
4428 RFC 2828               Internet Security Glossary               May 2000
4429
4430
4431    $ hash code
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
4436       digest.)
4437
4438    $ hash function
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.)
4444
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]
4450
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.)
4458
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
4463       a data object.
4464
4465    $ hash result
4466       (I) The output of a hash function. (See: hash code, hash value.)
4467
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".)
4473
4474    $ hash value
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.)
4479
4480
4481
4482 Shirey                       Informational                     [Page 80]
4483 \f
4484 RFC 2828               Internet Security Glossary               May 2000
4485
4486
4487    $ hierarchical PKI
4488       (I) A PKI architecture based on a certification hierarchy. (See:
4489       mesh PKI, trust-file PKI.)
4490
4491    $ hierarchy management
4492       (I) The process of generating configuration data and issuing
4493       public-key certificates to build and operate a certification
4494       hierarchy.
4495
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.)
4501
4502    $ hijack attack
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.)
4506
4507    $ HMAC
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].)
4512
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)).
4520
4521       (C) The goals of HMAC are as follows:
4522
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.
4534
4535
4536
4537
4538 Shirey                       Informational                     [Page 81]
4539 \f
4540 RFC 2828               Internet Security Glossary               May 2000
4541
4542
4543    $ honey pot
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:
4547       entrapment.)
4548
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.)
4553
4554    $ host
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.)
4559
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.)
4563
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
4569       called hosts.
4570
4571    $ HTML
4572       See: Hypertext Markup Language.
4573
4574    $ HTTP
4575       See: Hypertext Transfer Protocol.
4576
4577    $ https
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.)
4582
4583    $ hybrid encryption
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.)
4587
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
4591
4592
4593
4594 Shirey                       Informational                     [Page 82]
4595 \f
4596 RFC 2828               Internet Security Glossary               May 2000
4597
4598
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:
4601       MSP, PEM, PGP.)
4602
4603    $ hyperlink
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).
4610
4611    $ hypermedia
4612       (I) A generalization of hypertext; any media that contain
4613       hyperlinks that point to material in the same or another data
4614       object.
4615
4616    $ hypertext
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.)
4621
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]
4628
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.)
4633
4634    $ IAB
4635       See: Internet Architecture Board.
4636
4637    $ IANA
4638       See: Internet Assigned Numbers Authority.
4639
4640    $ ICANN
4641       See: Internet Corporation for Assigned Names and Numbers.
4642
4643    $ ICMP
4644       See: Internet Control Message Protocol.
4645
4646
4647
4648
4649
4650 Shirey                       Informational                     [Page 83]
4651 \f
4652 RFC 2828               Internet Security Glossary               May 2000
4653
4654
4655    $ ICMP flood
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.)
4659
4660    $ ICRL
4661       See: indirect certificate revocation list.
4662
4663    $ IDEA
4664       See: International Data Encryption Algorithm.
4665
4666    $ identification
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.)
4670
4671    $ Identification Protocol
4672       (I) An client-server Internet protocol [R1413] for learning the
4673       identity of a user of a particular TCP connection.
4674
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.
4680
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.)
4686
4687    $ IEEE
4688       See: Institute of Electrical and Electronics Engineers, Inc.
4689
4690    $ IEEE 802.10
4691       (N) An IEEE committee developing security standards for local area
4692       networks. (See: SILS.)
4693
4694    $ IEEE P1363
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.
4700
4701    $ IESG
4702       See: Internet Engineering Steering Group.
4703
4704
4705
4706 Shirey                       Informational                     [Page 84]
4707 \f
4708 RFC 2828               Internet Security Glossary               May 2000
4709
4710
4711    $ IETF
4712       See: Internet Engineering Task Force.
4713
4714    $ IKE
4715       See: IPsec Key Exchange.
4716
4717    $ IMAP4
4718       See: Internet Message Access Protocol, version 4.
4719
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.)
4725
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
4731       in [R1731].
4732
4733    $ in the clear
4734       (I) Not encrypted. (See: cleartext.)
4735
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
4739       of the ICRL.
4740
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
4745       nonsense.
4746
4747       (C) Under certain conditions, this notion is equivalent to
4748       "semantic security".
4749
4750    $ information
4751       (I) Facts and ideas, which can be represented (encoded) as various
4752       forms of data.
4753
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]
4758
4759
4760
4761
4762 Shirey                       Informational                     [Page 85]
4763 \f
4764 RFC 2828               Internet Security Glossary               May 2000
4765
4766
4767    $ INFOSEC
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).
4771
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".)
4776
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]
4781
4782    $ initialization vector
4783       (D) For consistency, ISDs SHOULD NOT use this term as a synonym
4784       for "initialization value".
4785
4786    $ insider attack
4787       See: (secondary definition under) attack.
4788
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
4796       Security.)
4797
4798    $ integrity
4799       See: data integrity, correctness integrity, source integrity,
4800       system integrity.
4801
4802    $ integrity check
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.
4806
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.
4811       (See: threat.)
4812
4813
4814
4815
4816
4817
4818 Shirey                       Informational                     [Page 86]
4819 \f
4820 RFC 2828               Internet Security Glossary               May 2000
4821
4822
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.)
4826
4827    $ International Standard
4828       See: (secondary definition under) ISO.
4829
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.)
4836
4837    $ internet
4838    $ Internet
4839       See: internet vs. Internet.
4840
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]
4848
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.
4854
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.
4859
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.
4866
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
4871
4872
4873
4874 Shirey                       Informational                     [Page 87]
4875 \f
4876 RFC 2828               Internet Security Glossary               May 2000
4877
4878
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.
4883
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.
4891
4892    $ Internet Draft
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."
4901
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]
4910
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]
4920
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.)
4926
4927
4928
4929
4930 Shirey                       Informational                     [Page 88]
4931 \f
4932 RFC 2828               Internet Security Glossary               May 2000
4933
4934
4935       (C) IMAP4 has mechanisms for optionally authenticating a client to
4936       a server and providing other security services. (See: IMAP4
4937       AUTHENTICATE.)
4938
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.)
4943
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.)
4950
4951       (C) In the OSIRM, IP would be located at the top of layer 3.
4952
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.)
4960
4961       (C) Note that the letters "sec" are lower-case.
4962
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
4972       confidentiality.
4973
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.)
4978
4979       (D) ISDs SHOULD NOT use this term without a modifier to indicate
4980       which of the three types is meant.
4981
4982
4983
4984
4985
4986 Shirey                       Informational                     [Page 89]
4987 \f
4988 RFC 2828               Internet Security Glossary               May 2000
4989
4990
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]
4996
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.
5001       [R1108]
5002
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]
5007
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
5012       to RFC.
5013
5014    $ Internet Protocol Suite
5015       See: (secondary definition under) Internet.
5016
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.
5023
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.
5032
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
5037
5038
5039
5040
5041
5042 Shirey                       Informational                     [Page 90]
5043 \f
5044 RFC 2828               Internet Security Glossary               May 2000
5045
5046
5047       that result. The ISOC Board of Trustees approves appointments to
5048       the IAB from among nominees submitted by the IETF nominating
5049       committee. [R2026]
5050
5051    $ Internet Standard
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.)
5058
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.)
5066
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:
5073       Internet Standard.)
5074
5075    $ internet vs. Internet
5076       1. (I) Not capitalized: A popular abbreviation for "internetwork".
5077
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.
5082
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.
5088
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,
5094
5095
5096
5097
5098 Shirey                       Informational                     [Page 91]
5099 \f
5100 RFC 2828               Internet Security Glossary               May 2000
5101
5102
5103       and physical. In this Glossary, Internet layers are referred to by
5104       name to avoid confusing them with OSIRM layers, which are referred
5105       to by number.
5106
5107    $ internetwork
5108       (I) A system of interconnected networks; a network of networks.
5109       Usually shortened to "internet". (See: internet vs. Internet.)
5110
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.
5117       (See: router.)
5118
5119    $ intranet
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.)
5124
5125    $ intruder
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:
5128       cracker.)
5129
5130    $ intrusion
5131       See: security intrusion.
5132
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.
5138
5139    $ invalidity date
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].
5144
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
5149
5150
5151
5152
5153
5154 Shirey                       Informational                     [Page 92]
5155 \f
5156 RFC 2828               Internet Security Glossary               May 2000
5157
5158
5159       fraudulently repudiate a validly-generated signature, a private
5160       key holder may falsely claim that the key was compromised at some
5161       time in the past.
5162
5163    $ IP
5164       See: Internet Protocol.
5165
5166    $ IP address
5167       (I) A computer's internetwork address that is assigned for use by
5168       the Internet Protocol and other protocols.
5169
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.
5173
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.
5178
5179    $ IP Security Option
5180       See: Internet Protocol Security Option.
5181
5182    $ IPRA
5183       See: Internet Policy Registration Authority.
5184
5185    $ IPsec
5186       See: Internet Protocol security.
5187
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.
5193
5194    $ IPSO
5195       See: Internet Protocol Security Option.
5196
5197    $ ISAKMP
5198       See: Internet Security Association and Key Management Protocol.
5199
5200    $ ISD
5201       See: Internet Standards document.
5202
5203    $ ISO
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
5207
5208
5209
5210 Shirey                       Informational                     [Page 93]
5211 \f
5212 RFC 2828               Internet Security Glossary               May 2000
5213
5214
5215       participating nations and non-voting observer organizations. (See:
5216       ANSI, ITU-T.)
5217
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.)
5227
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.
5236
5237    $ ISOC
5238       See: Internet Society.
5239
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.)
5244
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.
5251
5252    $ issuer
5253       1. (I) "Issuer" of a certificate or CRL: The CA that signs the
5254       digital certificate or CRL.
5255
5256       (C) An X.509 certificate always includes the issuer's name. The
5257       name may include a common name value.
5258
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]
5262
5263
5264
5265
5266 Shirey                       Informational                     [Page 94]
5267 \f
5268 RFC 2828               Internet Security Glossary               May 2000
5269
5270
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]
5275
5276    $ ITAR
5277       See: International Traffic in Arms Regulations.
5278
5279    $ ITSEC
5280       See: Information Technology System Evaluation Criteria.
5281
5282    $ ITU-T
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.)
5288
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.
5294
5295    $ IV
5296       See: initialization value.
5297
5298    $ KDC
5299       See: Key Distribution Center.
5300
5301    $ KEA
5302       See: Key Exchange Algorithm.
5303
5304    $ KEK
5305       See: key-encrypting key.
5306
5307    $ Kerberos
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]
5313
5314       (C) Kerberos was developed by Project Athena and is named for the
5315       three-headed dog guarding Hades.
5316
5317    $ key
5318       See: cryptographic key.
5319
5320
5321
5322 Shirey                       Informational                     [Page 95]
5323 \f
5324 RFC 2828               Internet Security Glossary               May 2000
5325
5326
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.)
5335
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]
5339
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]
5345
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
5350       message.
5351
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]
5356
5357    $ key center
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.
5362
5363       (C) An ANSI standard [A9017] defines two types of key center: key
5364       distribution center and key translation center.
5365
5366    $ key confirmation
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]
5370
5371    $ key distribution
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.)
5375
5376
5377
5378 Shirey                       Informational                     [Page 96]
5379 \f
5380 RFC 2828               Internet Security Glossary               May 2000
5381
5382
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.)
5388
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]).
5400
5401    $ key encapsulation
5402       See: (secondary definition under) key recovery.
5403
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
5407       data.
5408
5409    $ key escrow
5410       See: (secondary definition under) key recovery.
5411
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.)
5416
5417       (O) "The procedure to share a symmetric key among different
5418       parties by either key agreement or key transport." [A9042]
5419
5420       (C) Key establishment involves either key agreement or key
5421       transport:
5422
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.)
5427
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.,
5431
5432
5433
5434 Shirey                       Informational                     [Page 97]
5435 \f
5436 RFC 2828               Internet Security Glossary               May 2000
5437
5438
5439          each can independently generate the same value, but that value
5440          cannot be computed by other entities.
5441
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.)
5447
5448       (C) On 23 June 1998, the NSA announced that KEA had been
5449       declassified.
5450
5451    $ key generation
5452       (I) A process that creates the sequence of symbols that comprise a
5453       cryptographic key. (See: key management.)
5454
5455    $ key generator
5456       1. (I) An algorithm that uses mathematical rules to
5457       deterministically produce a pseudo-random sequence of
5458       cryptographic key values.
5459
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
5463       ciphertext.
5464
5465    $ key length
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:
5468       key space.)
5469
5470    $ key lifetime
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.)
5475
5476    $ key management
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.)
5483
5484       (O) "The generation, storage, distribution, deletion, archiving
5485       and application of keys in accordance with a security policy."
5486       [I7498 Part 2]
5487
5488
5489
5490 Shirey                       Informational                     [Page 98]
5491 \f
5492 RFC 2828               Internet Security Glossary               May 2000
5493
5494
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
5499       archiving." [FP140]
5500
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.)
5505
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
5509       certificate.
5510
5511    $ key pair
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).
5517
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.
5525
5526    $ key recovery
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.)
5530
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]
5534
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:
5539
5540
5541
5542
5543
5544
5545
5546 Shirey                       Informational                     [Page 99]
5547 \f
5548 RFC 2828               Internet Security Glossary               May 2000
5549
5550
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.
5555
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.
5565
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.
5571
5572          Key encapsulation typically allows direct retrieval of the
5573          secret key used to provide data confidentiality.
5574
5575    $ key space
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.)
5579
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.)
5585
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
5597       [A9017]).
5598
5599
5600
5601
5602 Shirey                       Informational                    [Page 100]
5603 \f
5604 RFC 2828               Internet Security Glossary               May 2000
5605
5606
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.)
5611
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]
5616
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.
5620
5621    $ key update
5622       (I) Derive a new key from an existing key. (See: certificate
5623       rekey.)
5624
5625    $ key validation
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]
5629
5630    $ keyed hash
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.)
5634
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:
5640
5641        - A function based on a keyed encryption algorithm. (E.g., see:
5642          Data Authentication Code.)
5643
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.)
5648
5649    $ keying material
5650       (I) Data (such as keys, key pairs, and initialization values)
5651       needed to establish and maintain a cryptographic security
5652       association.
5653
5654
5655
5656
5657
5658 Shirey                       Informational                    [Page 101]
5659 \f
5660 RFC 2828               Internet Security Glossary               May 2000
5661
5662
5663    $ KMID
5664       See: key material identifier.
5665
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).
5671
5672    $ L2F
5673       See: Layer 2 Forwarding Protocol.
5674
5675    $ L2TP
5676       See: Layer 2 Tunneling Protocol.
5677
5678    $ label
5679       See: security label.
5680
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
5684       occur.
5685
5686    $ lattice model
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.)
5691
5692       (C) The model describes the semantic structure formed by a finite
5693       set of security levels, such as those used in military
5694       organizations.
5695
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.
5704       (See: dominate.)
5705
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.
5710
5711
5712
5713
5714 Shirey                       Informational                    [Page 102]
5715 \f
5716 RFC 2828               Internet Security Glossary               May 2000
5717
5718
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:
5724       L2TP.)
5725
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
5730       network.)
5731
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.
5735
5736    $ LDAP
5737       See: Lightweight Directory Access Protocol.
5738
5739    $ least privilege
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.)
5744
5745       (C) This principle tends to limit damage that can be caused by an
5746       accident, error, or unauthorized act.
5747
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).
5752       [R1777]
5753
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.
5758
5759    $ link
5760       (I) World Wide Web usage: See: hyperlink.
5761
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
5765       encryption.)
5766
5767
5768
5769
5770 Shirey                       Informational                    [Page 103]
5771 \f
5772 RFC 2828               Internet Security Glossary               May 2000
5773
5774
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.
5780
5781    $ link-by-link encryption
5782    $ 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.)
5789
5790    $ logic bomb
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.)
5794
5795    $ login
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.
5800
5801       (C) Derives from "log" file", a security audit trail that records
5802       security events, such as the beginning of sessions, and who
5803       initiates them.
5804
5805    $ LOTOS
5806       See: Language of Temporal Ordering Specification.
5807
5808    $ MAC
5809       See: mandatory access control, Message Authentication Code.
5810
5811    $ malicious logic
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.)
5815
5816    $ malware
5817       (I) A contraction of "malicious software". (See: malicious logic.)
5818
5819       (D) ISDs SHOULD NOT use this term because it is not listed in most
5820       dictionaries and could confuse international readers.
5821
5822
5823
5824
5825
5826 Shirey                       Informational                    [Page 104]
5827 \f
5828 RFC 2828               Internet Security Glossary               May 2000
5829
5830
5831    $ man-in-the-middle
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.)
5836
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.
5846
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
5853       security policy.)
5854
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.
5858
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."
5863       [DOD1]
5864
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.
5873
5874    $ masquerade attack
5875       (I) A type of attack in which one system entity illegitimately
5876       poses as (assumes the identity of) another entity. (See: spoofing
5877       attack.)
5878
5879
5880
5881
5882 Shirey                       Informational                    [Page 105]
5883 \f
5884 RFC 2828               Internet Security Glossary               May 2000
5885
5886
5887    $ MCA
5888       See: merchant certificate authority.
5889
5890    $ MD2
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.)
5894
5895    $ MD4
5896       (N) A cryptographic hash [R1320] that produces a 128-bit hash
5897       result and was designed by Ron Rivest. (See: message digest and
5898       SHA-1.)
5899
5900    $ MD5
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
5903       MD4.
5904
5905    $ merchant
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]
5913
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.
5918
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
5926       gateway CAs. [SET2]
5927
5928    $ mesh PKI
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
5934
5935
5936
5937
5938 Shirey                       Informational                    [Page 106]
5939 \f
5940 RFC 2828               Internet Security Glossary               May 2000
5941
5942
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.)
5946
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])
5952
5953       (C) The ANSI standard MAC algorithm is equivalent to cipher block
5954       chaining with IV = 0.
5955
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.)
5962
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.
5971
5972    $ message digest
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.)
5977
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.)
5984
5985    $ message indicator
5986       (D) ISDs SHOULD NOT use this term as a synonym for "initialization
5987       value" because it mixes concepts in a potentially misleading way.
5988
5989
5990
5991
5992
5993
5994 Shirey                       Informational                    [Page 107]
5995 \f
5996 RFC 2828               Internet Security Glossary               May 2000
5997
5998
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
6009       on what is meant.
6010
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.
6015
6016    $ MHS
6017       See: message handling system.
6018
6019    $ MIME
6020       See: Multipurpose Internet Mail Extensions.
6021
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.)
6028
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]
6034
6035    $ MISPC
6036       See: Minimum Interoperability Specification for PKI Components.
6037
6038    $ MISSI
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.)
6043
6044
6045
6046
6047
6048
6049
6050 Shirey                       Informational                    [Page 108]
6051 \f
6052 RFC 2828               Internet Security Glossary               May 2000
6053
6054
6055    $ MISSI user
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.)
6059
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.
6066
6067    $ mode
6068    $ mode of operation
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.)
6074
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.)
6081
6082    $ modulus
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.)
6086
6087    $ Morris Worm
6088       (I) A worm program written by Robert T. Morris, Jr. that flooded
6089       the ARPANET in November, 1988, causing problems for thousands of
6090       hosts. (See: worm.)
6091
6092    $ MOSS
6093       See: MIME Object Security Services.
6094
6095    $ MSP
6096       See: Message Security Protocol.
6097
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
6102
6103
6104
6105
6106 Shirey                       Informational                    [Page 109]
6107 \f
6108 RFC 2828               Internet Security Glossary               May 2000
6109
6110
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.
6114
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
6120       the system.
6121
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.
6125
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:
6131       S/MIME.)
6132
6133    $ mutual suspicion
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.
6137
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.)
6145
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.
6151
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:
6155
6156        - Developing tests, test methods, and other tools that developers
6157          and testing laboratories may use to improve and evaluate
6158          security products.
6159
6160
6161
6162 Shirey                       Informational                    [Page 110]
6163 \f
6164 RFC 2828               Internet Security Glossary               May 2000
6165
6166
6167        - Collaborating with industry and others on research and testing
6168          programs.
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.
6177
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,
6184       NSA.)
6185
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,
6191       NIST, SKIPJACK.)
6192
6193    $ need-to-know
6194       (I) The necessity for access to, knowledge of, or possession of
6195       specific information required to carry out official duties.
6196
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.
6201
6202    $ network
6203       See: computer network.
6204
6205    $ NIAP
6206       See: National Information Assurance Partnership.
6207
6208    $ NIST
6209       See: National Institute of Standards and Technology.
6210
6211    $ NLSP
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.
6215
6216
6217
6218 Shirey                       Informational                    [Page 111]
6219 \f
6220 RFC 2828               Internet Security Glossary               May 2000
6221
6222
6223    $ no-lone zone
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:
6227       dual control.)
6228
6229    $ nonce
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.
6233
6234    $ non-critical
6235       See: critical (extension of certificate).
6236
6237    $ non-repudiation service
6238       (I) A security service that provide protection against false
6239       denial of involvement in a communication. (See: repudiation.)
6240
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:
6247
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
6254          third party.
6255
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.
6260
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:
6264
6265
6266
6267
6268
6269
6270
6271
6272
6273
6274 Shirey                       Informational                    [Page 112]
6275 \f
6276 RFC 2828               Internet Security Glossary               May 2000
6277
6278
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       --------   --------   --------   --------   --------   . --------
6284
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                             +-------------------+
6293
6294       Phase / Explanation
6295       -------------------
6296       1. Before the critical action, the service requester asks, either
6297          implicitly or explicitly, to have evidence of the action be
6298          generated.
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.
6310
6311    $ no-PIN ORA (NORA)
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.
6316
6317    $ NORA
6318       See: no-PIN ORA.
6319
6320    $ notarization
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:
6325       digital notary.)
6326
6327
6328
6329
6330 Shirey                       Informational                    [Page 113]
6331 \f
6332 RFC 2828               Internet Security Glossary               May 2000
6333
6334
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).
6342
6343    $ OAKLEY
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]
6347
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-
6356       Hellman.
6357
6358    $ object
6359       (I) Trusted computer system modeling usage: A system element that
6360       contains or receives information. (See: Bell-LaPadula Model,
6361       trusted computer system.)
6362
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
6368       protocol.
6369
6370       (O) "A value (distinguishable from all other such values) which is
6371       associated with an object." [X680]
6372
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
6378       object.
6379
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
6383
6384
6385
6386 Shirey                       Informational                    [Page 114]
6387 \f
6388 RFC 2828               Internet Security Glossary               May 2000
6389
6390
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}.
6398
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}.
6409
6410    $ object reuse
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."
6416       [NCS04]
6417
6418    $ OCSP
6419       See: On-line Certificate Status Protocol.
6420
6421    $ octet
6422       (I) A data unit of eight bits. (See: byte.)
6423
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.
6427
6428    $ OFB
6429       See: output feedback.
6430
6431    $ ohnosecond
6432       (C) That minuscule fraction of time in which you realize that your
6433       private key has been compromised.
6434
6435    $ OID
6436       See: object identifier.
6437
6438
6439
6440
6441
6442 Shirey                       Informational                    [Page 115]
6443 \f
6444 RFC 2828               Internet Security Glossary               May 2000
6445
6446
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
6450       certificate.
6451
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.
6461
6462    $ one-time pad
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
6467       decryption.
6468
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.
6475
6476    $ one-time password
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.
6483
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.
6489
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.)
6495
6496
6497
6498 Shirey                       Informational                    [Page 116]
6499 \f
6500 RFC 2828               Internet Security Glossary               May 2000
6501
6502
6503    $ one-way function
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]
6509
6510       (D) ISDs SHOULD NOT use this term as a synonym for "cryptographic
6511       hash".
6512
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.)
6523
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.
6528
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
6532       Internet.
6533
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.
6539
6540       (C) Some unknown person described how the OSI layers correspond to
6541       the seven deadly sins:
6542
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
6546          itself.
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.)
6551
6552
6553
6554 Shirey                       Informational                    [Page 117]
6555 \f
6556 RFC 2828               Internet Security Glossary               May 2000
6557
6558
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
6563          neglected.)
6564       1. Pride: Physical has managed to avoid much of the controversy,
6565          and nearly all of the embarrassment, suffered by the others.
6566
6567       (C) John G. Fletcher described how the OSI layers also correspond
6568       to Snow White's dwarf friends:
6569
6570       7. Doc: Application acts as if it is in charge, but sometimes
6571          muddles its syntax.
6572       6. Sleepy: Presentation is indolent, being guilty of the sin of
6573          Sloth.
6574       5. Dopey: Session is confused because its charter is not very
6575          clear.
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
6579          irritated.
6580       2. Sneezy: Data Link makes loud noises in the hope of attracting
6581          attention.
6582       1. Bashful: Physical quietly does its work, unnoticed by the
6583          others.
6584
6585    $ operational integrity
6586       (I) A synonym for "system integrity"; emphasizes the actual
6587       performance of system functions rather than just the ability to
6588       perform them.
6589
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.
6595
6596    $ OPSEC
6597       See: operations security.
6598
6599    $ ORA
6600       See: organizational registration authority.
6601
6602    $ Orange Book
6603       (D) ISDs SHOULD NOT use this term as a synonym for "Trusted
6604       Computer System Evaluation Criteria" [CSC001, DOD1]. Instead, use
6605
6606
6607
6608
6609
6610 Shirey                       Informational                    [Page 118]
6611 \f
6612 RFC 2828               Internet Security Glossary               May 2000
6613
6614
6615       the full, proper name of the document or, in subsequent
6616       references, the abbreviation "TCSEC". (See: (usage note under)
6617       Green Book.)
6618
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.
6623
6624    $ organizational registration authority (ORA)
6625       (I) General usage: An RA for an organization.
6626
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-
6635       PIN ORA.)
6636
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.
6643
6644    $ OSI
6645    $ OSIRM
6646       See: Open Systems Interconnection Reference Model.
6647
6648    $ OTP
6649       See: One-Time Password.
6650
6651    $ out of band
6652       (I) Transfer of information using a channel that is outside (i.e.,
6653       separate from) the channel that is normally used. (See: covert
6654       channel.)
6655
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.)
6661
6662
6663
6664
6665
6666 Shirey                       Informational                    [Page 119]
6667 \f
6668 RFC 2828               Internet Security Glossary               May 2000
6669
6670
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.
6675
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
6681       segment.
6682
6683    $ outside attack
6684    $ outsider attack
6685       See: (secondary definition under) attack.
6686
6687    $ P1363
6688       See: IEEE P1363.
6689
6690    $ PAA
6691       See: policy approving authority.
6692
6693    $ packet filter
6694       See: (secondary definition under) filtering router.
6695
6696    $ pagejacking
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.
6703
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
6707       Book.)
6708
6709    $ PAN
6710       See: primary account number.
6711
6712    $ PAP
6713       See: Password Authentication Protocol.
6714
6715
6716
6717
6718
6719
6720
6721
6722 Shirey                       Informational                    [Page 120]
6723 \f
6724 RFC 2828               Internet Security Glossary               May 2000
6725
6726
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]
6733
6734    $ passive attack
6735       See: (secondary definition under) attack.
6736
6737    $ passive wiretapping
6738       See: (secondary definition under) wiretapping.
6739
6740    $ password
6741       (I) A secret data value, usually a character string, that is used
6742       as authentication information. (See: challenge-response.)
6743
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.
6747
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
6754       authentication.)
6755
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]
6759       (See: CHAP.)
6760
6761    $ password sniffing
6762       (I) Passive wiretapping, usually on a local area network, to gain
6763       knowledge of passwords. (See: (usage note under) sniffing.)
6764
6765    $ path discovery
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.
6769
6770    $ path validation
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.)
6775
6776
6777
6778 Shirey                       Informational                    [Page 121]
6779 \f
6780 RFC 2828               Internet Security Glossary               May 2000
6781
6782
6783    $ payment card
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]
6788
6789    $ payment gateway
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]
6796
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]
6802       (See: PCA.)
6803
6804    $ PC card
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.)
6809
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.
6817
6818    $ PCA
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.)
6823
6824    $ PCMCIA
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.)
6830
6831
6832
6833
6834 Shirey                       Informational                    [Page 122]
6835 \f
6836 RFC 2828               Internet Security Glossary               May 2000
6837
6838
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.)
6842
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.)
6847
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.
6855
6856       (C) See: "relationship between data integrity service and
6857       authentication services" under data integrity service.
6858
6859    $ PEM
6860       See: Privacy Enhanced Mail.
6861
6862    $ penetration
6863       (I) Successful, repeatable, unauthorized access to a protected
6864       system resource. (See: attack, violation.)
6865
6866    $ penetration test
6867       (I) A system test, often part of system certification, in which
6868       evaluators attempt to circumvent the security features of the
6869       system. [NCS04]
6870
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.
6877
6878    $ perfect forward secrecy
6879       See: (discussion under) public-key forward secrecy.
6880
6881    $ perimeter
6882       See: security perimeter.
6883
6884
6885
6886
6887
6888
6889
6890 Shirey                       Informational                    [Page 123]
6891 \f
6892 RFC 2828               Internet Security Glossary               May 2000
6893
6894
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.)
6900
6901    $ permission
6902       (I) A synonym for "authorization", but "authorization" is
6903       preferred in the PKI context. (See: privilege.)
6904
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.)
6908
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)".
6913
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.
6916
6917    $ personality
6918    $ personality label
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.
6923
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
6935       authorizations.
6936
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.
6941
6942
6943
6944
6945
6946 Shirey                       Informational                    [Page 124]
6947 \f
6948 RFC 2828               Internet Security Glossary               May 2000
6949
6950
6951    $ PGP(trademark)
6952       See: Pretty Good Privacy.
6953
6954    $ Photuris
6955       (I) A UDP-based, key establishment protocol for session keys,
6956       designed for use with the IPsec protocols AH and ESP. Superseded
6957       by IKE.
6958
6959    $ phreaking
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]
6963
6964       (D) ISDs SHOULD NOT use this term because it is not listed in most
6965       dictionaries and could confuse international readers.
6966
6967    $ physical security
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,
6971       R1455]
6972
6973    $ piggyback attack
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.)
6978
6979    $ PIN
6980       See: personal identification number.
6981
6982    $ ping of death
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.
6986
6987    $ ping sweep
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.
6991
6992    $ PKCS
6993       See: Public-Key Cryptography Standards.
6994
6995    $ PKCS #7
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.
6999
7000
7001
7002 Shirey                       Informational                    [Page 125]
7003 \f
7004 RFC 2828               Internet Security Glossary               May 2000
7005
7006
7007    $ PKCS #10
7008       (N) A standard [PKC10] from the PKCS series; defines a syntax for
7009       requests for public-key certificates. (See: certification
7010       request.)
7011
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.
7017
7018    $ PKCS #11
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.
7023
7024    $ PKI
7025       See: public-key infrastructure.
7026
7027    $ PKIX
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
7032       protocols.
7033
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
7047       rest of PKIX.
7048
7049    $ PKIX private extension
7050       (I) PKIX defines a private extension to identify an on-line
7051       verification service supporting the issuing CA.
7052
7053
7054
7055
7056
7057
7058 Shirey                       Informational                    [Page 126]
7059 \f
7060 RFC 2828               Internet Security Glossary               May 2000
7061
7062
7063    $ plaintext
7064       (I) Data that is input to and transformed by an encryption
7065       process, or that is output by a decryption process.
7066
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.)
7070
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.)
7079
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.)
7085
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
7095       host).
7096
7097    $ policy
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.
7102
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.)
7108
7109
7110
7111
7112
7113
7114 Shirey                       Informational                    [Page 127]
7115 \f
7116 RFC 2828               Internet Security Glossary               May 2000
7117
7118
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.
7122
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.)
7130
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.)
7137
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.
7144
7145    $ Policy Management Authority
7146       (N) Canadian usage: An organization responsible for PKI oversight
7147       and policy management in the Government of Canada.
7148
7149    $ policy mapping
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]
7155
7156    $ POP3
7157       See: Post Office Protocol, version 3.
7158
7159    $ POP3 APOP
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
7165       AUTHENTICATE.)
7166
7167
7168
7169
7170 Shirey                       Informational                    [Page 128]
7171 \f
7172 RFC 2828               Internet Security Glossary               May 2000
7173
7174
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.
7183
7184    $ POP3 AUTH
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.)
7190
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
7195       used by IMAP4.
7196
7197    $ port scan
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.
7201
7202    $ POSIX
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
7208       implementers.
7209
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.
7217
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.)
7223
7224
7225
7226 Shirey                       Informational                    [Page 129]
7227 \f
7228 RFC 2828               Internet Security Glossary               May 2000
7229
7230
7231       (C) POP3 has mechanisms for optionally authenticating a client to
7232       a server and providing other security services. (See: POP3 APOP,
7233       POP3 AUTH.)
7234
7235    $ PPP
7236       See: Point-to-Point Protocol.
7237
7238    $ PPTP
7239       See: Point-to-Point Tunneling Protocol.
7240
7241    $ pre-authorization
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.
7245
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.)
7251
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
7256       Enhanced Mail.)
7257
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.)
7264
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.
7271
7272    $ privacy
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.)
7277
7278
7279
7280
7281
7282 Shirey                       Informational                    [Page 130]
7283 \f
7284 RFC 2828               Internet Security Glossary               May 2000
7285
7286
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
7290       2]
7291
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.
7300
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.)
7305
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.)
7312
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.
7317
7318    $ private component
7319       (I) A synonym for "private key".
7320
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."
7325
7326    $ private extension
7327       See: (secondary definition under) extension.
7328
7329    $ private key
7330       (I) The secret component of a pair of cryptographic keys used for
7331       asymmetric cryptography. (See: key pair, public key.)
7332
7333       (O) "(In a public key cryptosystem) that key of a user's key pair
7334       which is known only by that user." [X509]
7335
7336
7337
7338 Shirey                       Informational                    [Page 131]
7339 \f
7340 RFC 2828               Internet Security Glossary               May 2000
7341
7342
7343    $ privilege
7344       (I) An authorization or set of authorizations to perform security-
7345       relevant functions, especially in the context of a computer
7346       operating system.
7347
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.)
7352
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
7355       definition.
7356
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.)
7361
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.)
7369
7370    $ proprietary
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
7373       that entity.
7374
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.
7380
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.
7385
7386    $ protection authority
7387       See: (secondary definition under) Internet Protocol Security
7388       Option.
7389
7390
7391
7392
7393
7394 Shirey                       Informational                    [Page 132]
7395 \f
7396 RFC 2828               Internet Security Glossary               May 2000
7397
7398
7399    $ protection ring
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.
7403
7404    $ protocol
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.)
7408
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]
7412
7413    $ protocol suite
7414       (I) A complementary collection of communication protocols used in
7415       a computer network. (See: Internet, OSI.)
7416
7417    $ proxy server
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.)
7422
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.
7434
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.
7444
7445
7446
7447
7448
7449
7450 Shirey                       Informational                    [Page 133]
7451 \f
7452 RFC 2828               Internet Security Glossary               May 2000
7453
7454
7455    $ pseudo-random
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.)
7459
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.
7464
7465       (C) Pseudo-random number generators are usually implemented in
7466       software.
7467
7468    $ public component
7469       (I) A synonym for "public key".
7470
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."
7475
7476    $ public key
7477       (I) The publicly-disclosable component of a pair of cryptographic
7478       keys used for asymmetric cryptography. (See: key pair, private
7479       key.)
7480
7481       (O) "(In a public key cryptosystem) that key of a user's key pair
7482       which is publicly known." [X509]
7483
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.)
7489
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.
7494
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]
7498
7499    $ public-key cryptography
7500       (I) The popular synonym for "asymmetric cryptography".
7501
7502
7503
7504
7505
7506 Shirey                       Informational                    [Page 134]
7507 \f
7508 RFC 2828               Internet Security Glossary               May 2000
7509
7510
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.)
7515
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.
7522
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.
7528
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.
7539
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:
7545
7546       (C) Involvement of session keys vs. long-term keys: Experts
7547       disagree about the basic ideas involved.
7548
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
7553       keys.
7554
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.
7558
7559
7560
7561
7562 Shirey                       Informational                    [Page 135]
7563 \f
7564 RFC 2828               Internet Security Glossary               May 2000
7565
7566
7567        - The "I" definition presented above involves a third concept of
7568       "forward secrecy" that refers to the effect of the compromise of
7569       long-term keys.
7570
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.
7578
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.
7587
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.
7596
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
7604       compromised.
7605
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.
7609
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
7614
7615
7616
7617
7618 Shirey                       Informational                    [Page 136]
7619 \f
7620 RFC 2828               Internet Security Glossary               May 2000
7621
7622
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.)
7626
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.
7630
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
7641       operate.
7642
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.
7651
7652    $ RA
7653       See: registration authority.
7654
7655    $ RA domains
7656       (I) A capability of a CAW that allows a CA to divide the
7657       responsibility for certification requests among multiple RAs.
7658
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.
7665
7666    $ RADIUS
7667       See: Remote Authentication Dial-In User Service.
7668
7669
7670
7671
7672
7673
7674 Shirey                       Informational                    [Page 137]
7675 \f
7676 RFC 2828               Internet Security Glossary               May 2000
7677
7678
7679    $ Rainbow Series
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.)
7684
7685    $ random
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.)
7693
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]
7704
7705    $ random number generator
7706       (I) A process used to generate an unpredictable, uniformly
7707       distributed series of numbers (usually integers). (See: pseudo-
7708       random, random.)
7709
7710       (C) True random number generators are hardware-based devices that
7711       depend on the output of a "noisy diode" or other physical
7712       phenomena. [R1750]
7713
7714    $ RBAC
7715       See: Role-Based Access Control.
7716
7717    $ RC2
7718    $ RC4
7719       See: Rivest Cipher #2, Rivest Cipher #4.
7720
7721    $ realm
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
7725       application servers
7726
7727
7728
7729
7730 Shirey                       Informational                    [Page 138]
7731 \f
7732 RFC 2828               Internet Security Glossary               May 2000
7733
7734
7735    $ RED
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.)
7741
7742    $ Red Book
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)
7748       Green Book.)
7749
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.)
7756
7757    $ reference monitor
7758       (I) "An access control concept that refers to an abstract machine
7759       that mediates all accesses to objects by subjects." [NCS04] (See:
7760       security kernel.)
7761
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).
7766
7767    $ reflection attack
7768       (I) A type of replay attack in which transmitted data is sent back
7769       to its originator.
7770
7771    $ register
7772    $ registration
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.)
7777
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
7783
7784
7785
7786 Shirey                       Informational                    [Page 139]
7787 \f
7788 RFC 2828               Internet Security Glossary               May 2000
7789
7790
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
7796       with the CA's CPS.
7797
7798       (C) Among the registration issues that a CPS may address are the
7799       following [R2527]:
7800
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
7806          within what domain.
7807        - How naming disputes are resolved, including the role of
7808          trademarks.
7809        - Whether certificates are issued to entities that are not
7810          persons.
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.
7815
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,
7823       registration.)
7824
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:
7837
7838
7839
7840
7841
7842 Shirey                       Informational                    [Page 140]
7843 \f
7844 RFC 2828               Internet Security Glossary               May 2000
7845
7846
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.)
7858
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]
7864
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]
7869
7870    $ regrade
7871       (I) Deliberately change the classification level of information in
7872       an authorized manner.
7873
7874    $ rekey
7875       (I) Change the value of a cryptographic key that is being used in
7876       an application of a cryptographic system. (See: certificate
7877       rekey.)
7878
7879       (C) For example, rekey is required at the end of a cryptoperiod or
7880       key lifetime.
7881
7882    $ reliability
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.)
7886
7887    $ relying party
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.)
7891
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
7895
7896
7897
7898 Shirey                       Informational                    [Page 141]
7899 \f
7900 RFC 2828               Internet Security Glossary               May 2000
7901
7902
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.)
7906
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.
7914
7915    $ renew
7916       See: certificate renewal.
7917
7918    $ replay attack
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.)
7923
7924    $ repository
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.)
7928
7929       (O) "A trustworthy system for storing and retrieving certificates
7930       or other information relevant to certificates." [ABA]
7931
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
7938       anonymous login.
7939
7940    $ repudiation
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.)
7945
7946       (O) "Denial by one of the entities involved in a communication of
7947       having participated in all or part of the communication." [I7498
7948       Part 2]
7949
7950
7951
7952
7953
7954 Shirey                       Informational                    [Page 142]
7955 \f
7956 RFC 2828               Internet Security Glossary               May 2000
7957
7958
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
7964       Standard.)
7965
7966       (C) This term is *not* a synonym for "Internet Standard".
7967
7968    $ residual risk
7969       (I) The risk that remains after countermeasures have been applied.
7970
7971    $ restore
7972       See: card restore.
7973
7974    $ revocation
7975       See: certificate revocation.
7976
7977    $ revocation date
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.)
7981
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.
7990
7991    $ revocation list
7992       See: certificate revocation list.
7993
7994    $ revoke
7995       See: certificate revocation.
7996
7997    $ RFC
7998       See: Request for Comment.
7999
8000    $ risk
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.
8004
8005
8006
8007
8008
8009
8010 Shirey                       Informational                    [Page 143]
8011 \f
8012 RFC 2828               Internet Security Glossary               May 2000
8013
8014
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]
8018
8019    $ risk analysis
8020    $ risk assessment
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
8026       exposure.
8027
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,
8033       R2196]
8034
8035    $ risk management
8036       (I) The process of identifying, controlling, and eliminating or
8037       minimizing uncertain events that may affect system resources.
8038       (See: risk analysis.)
8039
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.).
8044
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.).
8049
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].
8053
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.
8058
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
8063
8064
8065
8066 Shirey                       Informational                    [Page 144]
8067 \f
8068 RFC 2828               Internet Security Glossary               May 2000
8069
8070
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
8073       set (n,d).
8074
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.)
8082
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.
8087
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.
8093
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.
8103
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.
8108
8109    $ root
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.
8112
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
8116       CA.)
8117
8118
8119
8120
8121
8122 Shirey                       Informational                    [Page 145]
8123 \f
8124 RFC 2828               Internet Security Glossary               May 2000
8125
8126
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
8139       certification path.
8140
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
8145       authority.
8146
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.
8150
8151    $ root certificate
8152       (I) A certificate for which the subject is a root.
8153
8154       (I) Hierarchical PKI usage: The self-signed public-key certificate
8155       at the top of a certification hierarchy.
8156
8157    $ root key
8158       (I) A public key for which the matching private key is held by a
8159       root.
8160
8161    $ root registry
8162       (O) MISSI usage: A name previously used for a MISSI policy
8163       approving authority.
8164
8165    $ router
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.)
8170
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.)
8174
8175
8176
8177
8178 Shirey                       Informational                    [Page 146]
8179 \f
8180 RFC 2828               Internet Security Glossary               May 2000
8181
8182
8183    $ RSA
8184       See: Rivest-Shamir-Adleman.
8185
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
8192       policy.)
8193
8194    $ safety
8195       (I) The property of a system being free from risk of causing harm
8196       to system entities and outside entities.
8197
8198    $ SAID
8199       See: security association identifier.
8200
8201    $ salt
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.)
8206
8207       (C) Salt protects a password-based access control system against a
8208       dictionary attack.
8209
8210    $ sanitize
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
8213       level.
8214
8215    $ SASL
8216       See: Simple Authentication and Security Layer.
8217
8218    $ SCA
8219       See: subordinate certification authority.
8220
8221    $ scavenging
8222       See: (secondary definition under) threat consequence.
8223
8224    $ screening router
8225       (I) A synonym for "filtering router".
8226
8227    $ SDE
8228       See: Secure Data Exchange.
8229
8230
8231
8232
8233
8234 Shirey                       Informational                    [Page 147]
8235 \f
8236 RFC 2828               Internet Security Glossary               May 2000
8237
8238
8239    $ SDNS
8240       See: Secure Data Network System.
8241
8242    $ seal
8243       (O) To use cryptography to provide data integrity service for a
8244       data object. (See: sign, wrap.)
8245
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.
8249
8250    $ secret
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
8254       protected thusly.
8255
8256       (C) This term applies to symmetric keys, private keys, and
8257       passwords.
8258
8259    $ secret-key cryptography
8260       (I) A synonym for "symmetric cryptography".
8261
8262    $ Secure Data Exchange (SDE)
8263       (N) A local area network security protocol defined by the IEEE
8264       802.10 standard.
8265
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).
8270
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.
8276
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.)
8280
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
8287
8288
8289
8290 Shirey                       Informational                    [Page 148]
8291 \f
8292 RFC 2828               Internet Security Glossary               May 2000
8293
8294
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.
8300
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.
8305
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
8313       Layer Security.)
8314
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.
8320
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.
8332
8333    $ secure state
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.)
8337
8338    $ security
8339       (I) (1.) Measures taken to protect a system. (2.) The condition of
8340       a system that results from the establishment and maintenance of
8341
8342
8343
8344
8345
8346 Shirey                       Informational                    [Page 149]
8347 \f
8348 RFC 2828               Internet Security Glossary               May 2000
8349
8350
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.
8354
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)
8361       security policy.)
8362
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.
8370
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.)
8376
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.
8381
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
8390       Index.
8391
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
8397       Parameter Index.)
8398
8399
8400
8401
8402 Shirey                       Informational                    [Page 150]
8403 \f
8404 RFC 2828               Internet Security Glossary               May 2000
8405
8406
8407    $ security audit
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]
8413
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.
8419
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.)
8426
8427    $ security class
8428       (D) A synonym for "security level". For consistency, ISDs SHOULD
8429       use "security level" instead of "security class".
8430
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
8435       level.)
8436
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.)
8441
8442    $ security domain
8443       See: domain.
8444
8445    $ security environment
8446       (I) The set of external entities, procedures, and conditions that
8447       affect secure development, operation, and maintenance of a system.
8448
8449    $ security event
8450       (I) A occurrence in a system that is relevant to the security of
8451       the system. (See: security incident.)
8452
8453
8454
8455
8456
8457
8458 Shirey                       Informational                    [Page 151]
8459 \f
8460 RFC 2828               Internet Security Glossary               May 2000
8461
8462
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:
8466
8467        - Performing a cryptographic operation, e.g., signing a digital
8468          certificate or CRL.
8469        - Performing a cryptographic card operation: creation, insertion,
8470          removal, or backup.
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
8477          module.
8478        - Logging the operator in or out.
8479        - Failing a built-in hardware self-test or a software system
8480          integrity check.
8481
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.
8486
8487    $ security gateway
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
8491       guard.)
8492
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.
8498
8499    $ security incident
8500       (I) A security event that involves a security violation. (See:
8501       CERT, GRIP, security event, security intrusion, security
8502       violation.)
8503
8504       (C) In other words, a security-relevant system event in which the
8505       system's security policy is disobeyed or otherwise breached.
8506
8507       (O) "Any adverse event which compromises some aspect of computer
8508       or network security." [R2350]
8509
8510
8511
8512
8513
8514 Shirey                       Informational                    [Page 152]
8515 \f
8516 RFC 2828               Internet Security Glossary               May 2000
8517
8518
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.
8523
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.
8529
8530    $ security kernel
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.)
8535
8536       (C) That is, a security kernel is an implementation of a reference
8537       monitor for a given hardware base.
8538
8539    $ security label
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]
8543
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]
8548
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]
8554
8555    $ security level
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.)
8560
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]:
8566
8567
8568
8569
8570 Shirey                       Informational                    [Page 153]
8571 \f
8572 RFC 2828               Internet Security Glossary               May 2000
8573
8574
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
8579       attacks.
8580
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.
8585
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.)
8589
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)
8594       security policy.)
8595
8596       (C) Some examples of security mechanisms are authentication
8597       exchange, checksum, digital signature, encryption, and traffic
8598       padding.
8599
8600    $ security model
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.)
8604
8605       (C) An example is the Bell-LaPadula Model.
8606
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.
8615
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.
8620
8621
8622
8623
8624
8625
8626 Shirey                       Informational                    [Page 154]
8627 \f
8628 RFC 2828               Internet Security Glossary               May 2000
8629
8630
8631    $ security policy
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.)
8637
8638       (O) "The set of rules laid down by the security authority
8639       governing the use and provision of security services and
8640       facilities." [X509]
8641
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
8646       implemented.
8647
8648          What Security Services Should Be Provided?
8649           ^
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           | + - - - - - - - - - - - +
8659           v
8660          How Are Security Services Implemented?
8661
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.)
8665
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.)
8670
8671    $ security-relevant event
8672       See: security event.
8673
8674    $ security service
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,
8678
8679
8680
8681
8682 Shirey                       Informational                    [Page 155]
8683 \f
8684 RFC 2828               Internet Security Glossary               May 2000
8685
8686
8687       data confidentiality service, data integrity service, data origin
8688       authentication service, non-repudiation service, peer entity
8689       authentication service, system integrity service.)
8690
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]
8694
8695       (C) Security services implement security policies, and are
8696       implemented by security mechanisms.
8697
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.
8704
8705    $ security token
8706       See: token.
8707
8708    $ security violation
8709       (I) An act or event that disobeys or otherwise breaches security
8710       policy. (See: compromise, penetration, security incident.)
8711
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.)
8717
8718       (C) In a self-signed X.509 public-key certificate, the issuer's DN
8719       is the same as the subject's DN.
8720
8721    $ semantic security
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.)
8728
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.)
8733
8734
8735
8736
8737
8738 Shirey                       Informational                    [Page 156]
8739 \f
8740 RFC 2828               Internet Security Glossary               May 2000
8741
8742
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
8747       security.)
8748
8749    $ serial number
8750       See: certificate serial number.
8751
8752    $ server
8753       (I) A system entity that provides a service in response to
8754       requests from other system entities called clients.
8755
8756    $ session key
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.)
8760
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.
8766
8767    $ SET
8768       See: SET Secure Electronic Transaction(trademark).
8769
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.
8776
8777    $ SET qualifier
8778       (O) A certificate policy qualifier that provides information about
8779       the location and content of a SET certificate policy.
8780
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
8786       qualifiers:
8787
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
8790          may be found.
8791
8792
8793
8794 Shirey                       Informational                    [Page 157]
8795 \f
8796 RFC 2828               Internet Security Glossary               May 2000
8797
8798
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.
8803
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.)
8812
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.
8819
8820    $ SETCo
8821       See: (secondary definition under) SET Secure Electronic
8822       Transaction.
8823
8824    $ SHA-1
8825       See: Secure Hash Standard.
8826
8827    $ shared secret
8828       (I) A synonym for "keying material" or "cryptographic key".
8829
8830    $ S-HTTP
8831       See: Secure HTTP.
8832
8833    $ sign
8834       (I) Create a digital signature for a data object.
8835
8836    $ signature
8837       See: digital signature, electronic signature.
8838
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.
8843
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.
8847
8848
8849
8850 Shirey                       Informational                    [Page 158]
8851 \f
8852 RFC 2828               Internet Security Glossary               May 2000
8853
8854
8855    $ signer
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]
8858
8859    $ SILS
8860       See: Standards for Interoperable LAN/MAN Security.
8861
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.)
8866
8867       (O) "Authentication by means of simple password arrangements."
8868       [X509]
8869
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.
8878
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.)
8883
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.
8892
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
8896       another.
8897
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.
8902
8903
8904
8905
8906 Shirey                       Informational                    [Page 159]
8907 \f
8908 RFC 2828               Internet Security Glossary               May 2000
8909
8910
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.
8917
8918    $ simple security property
8919       See: (secondary definition under) Bell-LaPadula Model.
8920
8921    $ single sign-on
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:
8925       Kerberos.)
8926
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.
8934
8935    $ situation
8936       See: security situation.
8937
8938    $ S/Key
8939       (I) A security mechanism that uses a cryptographic hash function
8940       to generate a sequence of 64-bit, one-time passwords for remote
8941       user login. [R1760]
8942
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
8951       password.
8952
8953    $ SKIP
8954       See: Simple Key-management for IP.
8955
8956
8957
8958
8959
8960
8961
8962 Shirey                       Informational                    [Page 160]
8963 \f
8964 RFC 2828               Internet Security Glossary               May 2000
8965
8966
8967    $ SKIPJACK
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.)
8972
8973       (C) On 23 June 1998, NSA announced that SKIPJACK had been
8974       declassified.
8975
8976    $ slot
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
8980       private key.
8981
8982    $ smart card
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.)
8986
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
8992       cards.
8993
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.
8998
8999    $ smart token
9000       See: (secondary definition under) smart card.
9001
9002    $ SMI
9003       See: security management infrastructure.
9004
9005    $ S/MIME
9006       See: Secure/MIME.
9007
9008    $ SMTP
9009       See: Simple Mail Transfer Protocol.
9010
9011    $ smurf
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.)
9015
9016
9017
9018 Shirey                       Informational                    [Page 161]
9019 \f
9020 RFC 2828               Internet Security Glossary               May 2000
9021
9022
9023       (D) ISDs SHOULD NOT use this term because it is not listed in most
9024       dictionaries and could confuse international readers.
9025
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.
9034
9035    $ sniffing
9036       (C) A synonym for "passive wiretapping". (See: password sniffing.)
9037
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.
9041
9042    $ SNMP
9043       See: Simple Network Management Protocol.
9044
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.)
9049
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.
9052
9053    $ SOCKS
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
9057       of a firewall.
9058
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.
9068
9069
9070
9071
9072
9073
9074 Shirey                       Informational                    [Page 162]
9075 \f
9076 RFC 2828               Internet Security Glossary               May 2000
9077
9078
9079    $ soft TEMPEST
9080       (O) The use of software techniques to reduce the radio frequency
9081       information leakage from computer displays and keyboards. [Kuhn]
9082       (See: TEMPEST.)
9083
9084    $ software
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.)
9089
9090    $ SORA
9091       See: SSO-PIN ORA.
9092
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).
9100
9101    $ source integrity
9102       (I) The degree of confidence that can be placed in information
9103       based on the trustworthiness of its sources. (See: integrity.)
9104
9105    $ SP3
9106       See: Security Protocol 3.
9107
9108    $ SP4
9109       See: Security Protocol 4.
9110
9111    $ spam
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".
9115       [R2635]
9116
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."
9125
9126
9127
9128
9129
9130 Shirey                       Informational                    [Page 163]
9131 \f
9132 RFC 2828               Internet Security Glossary               May 2000
9133
9134
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.
9141
9142    $ SPC
9143       See: software publisher certificate.
9144
9145    $ SPI
9146       See: Security Parameters Index.
9147
9148    $ split key
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
9152       knowledge.)
9153
9154    $ split knowledge
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.)
9159
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]
9164
9165    $ spoofing attack
9166       (I) A synonym for "masquerade attack".
9167
9168    $ SSH
9169       (I) A protocol for secure remote login and other secure network
9170       services over an insecure network.
9171
9172       (C) Consists of three major components:
9173
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.
9179
9180        - User authentication protocol: Authenticates the client-side
9181          user to the server. It runs over the transport layer protocol.
9182
9183
9184
9185
9186 Shirey                       Informational                    [Page 164]
9187 \f
9188 RFC 2828               Internet Security Glossary               May 2000
9189
9190
9191        - Connection protocol: Multiplexes the encrypted tunnel into
9192          several logical channels. It runs over the user authentication
9193          protocol.
9194
9195    $ SSL
9196       See: Secure Sockets Layer, Standard Security Label.
9197
9198    $ SSO
9199       See: system security officer.
9200
9201    $ SSO PIN
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.
9207       (See: user PIN.)
9208
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
9213       FORTEZZA PC card.
9214
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.
9223
9224    $ star property
9225       (I) (Written "*-property".) See: "confinement property" under
9226       Bell-LaPadula Model.
9227
9228    $ Star Trek attack
9229       (C) An attack that penetrates your system where no attack has ever
9230       gone before.
9231
9232    $ steganography
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.)
9236
9237       (C) An example of a steganographic method is "invisible" ink.
9238       (See: digital watermark.)
9239
9240
9241
9242 Shirey                       Informational                    [Page 165]
9243 \f
9244 RFC 2828               Internet Security Glossary               May 2000
9245
9246
9247    $ storage channel
9248       See: (secondary definition under) covert channel.
9249
9250    $ stream cipher
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.)
9256
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.)
9261
9262       (O) "Authentication by means of cryptographically derived
9263       credentials." [X509]
9264
9265    $ subject
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.)
9269
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.
9273
9274    $ subnetwork
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.)
9281
9282    $ subordinate certification authority (SCA)
9283       (I) A CA whose public-key certificate is issued by another
9284       (superior) CA. (See: certification hierarchy.)
9285
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
9293
9294
9295
9296
9297
9298 Shirey                       Informational                    [Page 166]
9299 \f
9300 RFC 2828               Internet Security Glossary               May 2000
9301
9302
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.
9306
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>.
9314
9315    $ superencryption
9316       (I) An encryption operation for which the plaintext input to be
9317       transformed is the ciphertext output of a previous encryption
9318       operation.
9319
9320    $ survivability
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,
9324       reliability.)
9325
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.)
9331
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.)
9335
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.
9346
9347    $ symmetric key
9348       (I) A cryptographic key that is used in a symmetric cryptographic
9349       algorithm.
9350
9351
9352
9353
9354 Shirey                       Informational                    [Page 167]
9355 \f
9356 RFC 2828               Internet Security Glossary               May 2000
9357
9358
9359    $ SYN flood
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.
9363       (See: flooding.)
9364
9365    $ system
9366       (C) In this Glossary, the term is mainly used as an abbreviation
9367       for "automated information system".
9368
9369    $ system entity
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.
9373
9374    $ system high
9375       (I) The highest security level supported by a system at a
9376       particular time or in a particular environment. (See: system high
9377       security mode.)
9378
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.)
9384
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
9388       Government.
9389
9390    $ system integrity
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
9394       integrity service.)
9395
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.)
9400
9401    $ system low
9402       (I) The lowest security level supported by a system at a
9403       particular time or in a particular environment. (See: system
9404       high.)
9405
9406
9407
9408
9409
9410 Shirey                       Informational                    [Page 168]
9411 \f
9412 RFC 2828               Internet Security Glossary               May 2000
9413
9414
9415    $ system resource
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.
9421
9422    $ system security officer (SSO)
9423       (I) A person responsible for enforcement or administration of the
9424       security policy that applies to the system.
9425
9426    $ system verification
9427       See: (secondary definition under) verification.
9428
9429    $ TACACS
9430    $ TACACS+
9431       See: Terminal Access Controller (TAC) Access Control System.
9432
9433    $ tamper
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.
9437
9438    $ TCB
9439       See: trusted computing base.
9440
9441    $ TCP
9442       See: Transmission Control Protocol.
9443
9444    $ TCP/IP
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.
9448
9449    $ TCSEC
9450       See: Trusted Computer System Evaluation Criteria.
9451
9452    $ TELNET
9453       (I) A TCP-based, application-layer, Internet Standard protocol
9454       [R0854] for remote login from one host to another.
9455
9456    $ TEMPEST
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
9462       tempest.)
9463
9464
9465
9466 Shirey                       Informational                    [Page 169]
9467 \f
9468 RFC 2828               Internet Security Glossary               May 2000
9469
9470
9471       (D) ISDs SHOULD NOT use this term as a synonym for
9472       "electromagnetic emanations security".
9473
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.
9479
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]
9487
9488        - "XTACACS": The name of Cisco Corporation's implementation,
9489          which enhances and extends the original TACACS.
9490
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.
9497
9498    $ TESS
9499       See: The Exponential Encryption System.
9500
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]
9508
9509    $ threat
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
9513       consequence.)
9514
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
9518
9519
9520
9521
9522 Shirey                       Informational                    [Page 170]
9523 \f
9524 RFC 2828               Internet Security Glossary               May 2000
9525
9526
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).
9530
9531       (C) In some contexts, such as the following, the term is used
9532       narrowly to refer only to intelligent threats:
9533
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.
9538
9539    $ threat action
9540       (I) An assault on system security. (See: attack, threat, threat
9541       consequence.)
9542
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
9546       consequence".
9547
9548    $ threat analysis
9549       (I) An analysis of the probability of occurrences and consequences
9550       of damaging actions to a system.
9551
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.)
9556
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 "*".
9561
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:
9567
9568          A. "Exposure": A threat action whereby sensitive data is
9569             directly released to an unauthorized entity. This includes:
9570
9571             a. "Deliberate Exposure": Intentional release of sensitive
9572                data to an unauthorized entity.
9573
9574
9575
9576
9577
9578 Shirey                       Informational                    [Page 171]
9579 \f
9580 RFC 2828               Internet Security Glossary               May 2000
9581
9582
9583             b. "Scavenging": Searching through data residue in a system
9584                to gain unauthorized knowledge of sensitive data.
9585
9586             c* "Human error": Human action or inaction that
9587                unintentionally results in an entity gaining unauthorized
9588                knowledge of sensitive data.
9589
9590             d* "Hardware/software error". System failure that results in
9591                an entity gaining unauthorized knowledge of sensitive
9592                data.
9593
9594          B. "Interception": A threat action whereby an unauthorized
9595             entity directly accesses sensitive data traveling between
9596             authorized sources and destinations. This includes:
9597
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.
9601
9602             b. "Wiretapping (passive)": Monitoring and recording data
9603                that is flowing between two points in a communication
9604                system. (See: wiretapping.)
9605
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:
9610                emanation.)
9611
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
9616             includes:
9617
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.)
9621
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:
9626                emanation.)
9627
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:
9631
9632
9633
9634 Shirey                       Informational                    [Page 172]
9635 \f
9636 RFC 2828               Internet Security Glossary               May 2000
9637
9638
9639             a. "Trespass": Gaining unauthorized physical access to
9640                sensitive data by circumventing a system's protections.
9641
9642             b. "Penetration": Gaining unauthorized logical access to
9643                sensitive data by circumventing a system's protections.
9644
9645             c. "Reverse engineering": Acquiring sensitive data by
9646                disassembling and analyzing the design of a system
9647                component.
9648
9649             d. Cryptanalysis: Transforming encrypted data into plaintext
9650                without having prior knowledge of encryption parameters
9651                or processes. (See: (main Glossary entry for)
9652                cryptanalysis.)
9653
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
9657          cause deception:
9658
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.)
9663
9664             a. "Spoof": Attempt by an unauthorized entity to gain access
9665                to a system by posing as an authorized user.
9666
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.)
9673
9674          B. "Falsification": A threat action whereby false data deceives
9675             an authorized entity. (See: active wiretapping.)
9676
9677             a. "Substitution": Altering or replacing valid data with
9678                false data that serves to deceive an authorized entity.
9679
9680             b. "Insertion": Introducing false data that serves to
9681                deceive an authorized entity.
9682
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)
9686             repudiation.)
9687
9688
9689
9690 Shirey                       Informational                    [Page 173]
9691 \f
9692 RFC 2828               Internet Security Glossary               May 2000
9693
9694
9695             a. "False denial of origin": Action whereby the originator
9696                of data denies responsibility for its generation.
9697
9698             b. "False denial of receipt": Action whereby the recipient
9699                of data denies receiving and possessing the data.
9700
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:
9705
9706          A. "Incapacitation": A threat action that prevents or
9707             interrupts system operation by disabling a system component.
9708
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)
9713                malicious logic.)
9714
9715             b. "Physical destruction": Deliberate destruction of a
9716                system component to interrupt or prevent system
9717                operation.
9718
9719             c* "Human error": Action or inaction that unintentionally
9720                disables a system component.
9721
9722             d* "Hardware or software error": Error that causes failure
9723                of a system component and leads to disruption of system
9724                operation.
9725
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]
9729
9730          B. "Corruption": A threat action that undesirably alters system
9731             operation by adversely modifying system functions or data.
9732
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
9736                functions.
9737
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)
9742                malicious logic.)
9743
9744
9745
9746 Shirey                       Informational                    [Page 174]
9747 \f
9748 RFC 2828               Internet Security Glossary               May 2000
9749
9750
9751             c* "Human error": Human action or inaction that
9752                unintentionally results in the alteration of system
9753                functions or data.
9754
9755             d* "Hardware or software error": Error that results in the
9756                alteration of system functions or data.
9757
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]
9761
9762          C. "Obstruction": A threat action that interrupts delivery of
9763             system services by hindering system operations.
9764
9765             a. "Interference": Disruption of system operations by
9766                blocking communications or user data or control
9767                information.
9768
9769             b. "Overload": Hindrance of system operation by placing
9770                excess burden on the performance capabilities of a system
9771                component. (See: flooding.)
9772
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
9776          usurpation:
9777
9778          A. "Misappropriation": A threat action whereby an entity
9779             assumes unauthorized logical or physical control of a system
9780             resource.
9781
9782             a. "Theft of service": Unauthorized use of service by an
9783                entity.
9784
9785             b. "Theft of functionality": Unauthorized acquisition of
9786                actual hardware, software, or firmware of a system
9787                component.
9788
9789             c. "Theft of data": Unauthorized acquisition and use of
9790                data.
9791
9792          B. "Misuse": A threat action that causes a system component to
9793             perform a function or service that is detrimental to system
9794             security.
9795
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.
9799
9800
9801
9802 Shirey                       Informational                    [Page 175]
9803 \f
9804 RFC 2828               Internet Security Glossary               May 2000
9805
9806
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.
9811
9812             c. "Violation of permissions": Action by an entity that
9813                exceeds the entity's system privileges by executing an
9814                unauthorized function.
9815
9816    $ thumbprint
9817       (I) A pattern of curves formed by the ridges on the tip of a
9818       thumb. (See: biometric authentication, fingerprint.)
9819
9820       (D) ISDs SHOULD NOT use this term as a synonym for "hash result"
9821       because that meaning mixes concepts in a potentially misleading
9822       way.
9823
9824    $ ticket
9825       (I) A synonym for "capability". (See: Kerberos.)
9826
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.
9832
9833    $ timing channel
9834       See: (secondary definition under) covert channel.
9835
9836    $ TLS
9837       See: Transport Layer Security. (See: TLSP.)
9838
9839    $ TLSP
9840       See: Transport Layer Security Protocol. (See: TLS.)
9841
9842    $ token
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.
9847
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.)
9851
9852       3. (I) Cryptographic usage: See: cryptographic token.
9853
9854
9855
9856
9857
9858 Shirey                       Informational                    [Page 176]
9859 \f
9860 RFC 2828               Internet Security Glossary               May 2000
9861
9862
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."
9866       [SET2]
9867
9868    $ token backup
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.
9872
9873    $ token copy
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
9878       keys.
9879
9880    $ token management
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.
9887
9888    $ token restore
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.
9892
9893    $ token storage key
9894       (I) A cryptography key used to protect data that is stored on a
9895       security token.
9896
9897    $ top CA
9898       (I) A CA that is the highest level (i.e., is the most trusted CA)
9899       in a certification hierarchy. (See: root.)
9900
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)
9905       security policy.)
9906
9907       (C) A top-level specification may be descriptive or formal:
9908
9909
9910
9911
9912
9913
9914 Shirey                       Informational                    [Page 177]
9915 \f
9916 RFC 2828               Internet Security Glossary               May 2000
9917
9918
9919        - "Descriptive top-level specification": One that is written in a
9920       natural language like English or an informal design notation.
9921
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.)
9926
9927    $ traffic analysis
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:
9933       wiretapping.)
9934
9935       (O) "The inference of information from observation of traffic
9936       flows (presence, absence, amount, direction, and frequency)."
9937       [I7498 Part 2]
9938
9939    $ traffic flow confidentiality
9940       (I) A data confidentiality service to protect against traffic
9941       analysis.
9942
9943       (O) "A confidentiality service to protect against traffic
9944       analysis." [I7498 Part 2]
9945
9946    $ traffic padding
9947       (I) "The generation of spurious instances of communication,
9948       spurious data units, and/or spurious data within data units."
9949       [I7498 Part 2]
9950
9951    $ tranquillity property
9952       See: (secondary definition under) Bell-LaPadula Model.
9953
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.)
9958
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.
9963
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.)
9967
9968
9969
9970 Shirey                       Informational                    [Page 178]
9971 \f
9972 RFC 2828               Internet Security Glossary               May 2000
9973
9974
9975       (C) The TLS protocol is misnamed, because it operates well above
9976       the transport layer (OSI layer 4).
9977
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.)
9982
9983       (C) TLSP evolved directly from the SP4 protocol of SDNS.
9984
9985    $ transport mode vs. tunnel mode
9986       (I) IPsec usage: Two ways to apply IPsec protocols (AH and ESP) to
9987       protect communications:
9988
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.
9992
9993        - "Tunnel mode": The protection applies to (i.e., the IPsec
9994          protocol encapsulates) IP packets.
9995
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.
10001
10002    $ trap door
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.)
10008
10009    $ triple DES
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.)
10014
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]
10021
10022
10023
10024
10025
10026 Shirey                       Informational                    [Page 179]
10027 \f
10028 RFC 2828               Internet Security Glossary               May 2000
10029
10030
10031    $ triple-wrapped
10032       (I) S/MIME usage: Data that has been signed with a digital
10033       signature, and then encrypted, and then signed again. [R2634]
10034
10035    $ Trojan horse
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.
10040
10041    $ trust
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.)
10046
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).
10054
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.
10058
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]
10067
10068    $ trust chain
10069       (D) ISDs SHOULD NOT use this term as a synonym for "certification
10070       path" because it mixes concepts in a potentially misleading way.
10071       (See: trust.)
10072
10073    $ trust-file PKI
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,
10078       web of trust.)
10079
10080
10081
10082 Shirey                       Informational                    [Page 180]
10083 \f
10084 RFC 2828               Internet Security Glossary               May 2000
10085
10086
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.
10092
10093    $ trust hierarchy
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.)
10098
10099    $ trust level
10100       (I) A characterization of a standard of security protection to be
10101       met by a computer system.
10102
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.
10109
10110    $ trusted
10111       See: (discussion under) trust.
10112
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.)
10119
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.
10124
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.)
10130
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"
10134
10135
10136
10137
10138 Shirey                       Informational                    [Page 181]
10139 \f
10140 RFC 2828               Internet Security Glossary               May 2000
10141
10142
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.)
10146
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.)
10152
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
10158       occur." [NCS04]
10159
10160    $ trusted key
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.)
10164
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
10168       a trust-file PKI.
10169
10170    $ trusted path
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.
10175       [NCS04]
10176
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]
10181
10182    $ trusted process
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)
10187       trust.)
10188
10189
10190
10191
10192
10193
10194 Shirey                       Informational                    [Page 182]
10195 \f
10196 RFC 2828               Internet Security Glossary               May 2000
10197
10198
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
10204       means.)
10205
10206    $ trusted system
10207       See: (discussion under) trust, trusted computer system,
10208       trustworthy system.
10209
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
10214       INFOSEC area.
10215
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)
10224       trust.)
10225
10226    $ TSIG
10227       See: Trusted System Interoperability Group.
10228
10229    $ tunnel
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,
10234       VPN.)
10235
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.
10247
10248
10249
10250 Shirey                       Informational                    [Page 183]
10251 \f
10252 RFC 2828               Internet Security Glossary               May 2000
10253
10254
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.)
10260
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
10265       supported.
10266
10267    $ tunnel mode
10268       (I) IPsec usage: See: transport mode vs. tunnel mode.
10269
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.)
10277
10278    $ Type I cryptography
10279       (O) A cryptographic algorithm or device approved by NSA for
10280       protecting classified information.
10281
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.)
10287
10288    $ Type III cryptography
10289       (O) A cryptographic algorithm or device approved as a Federal
10290       Information Processing Standard.
10291
10292    $ UDP
10293       See: User Datagram Protocol.
10294
10295    $ unclassified
10296       (I) Not classified.
10297
10298    $ unencrypted
10299       (I) Not encrypted.
10300
10301
10302
10303
10304
10305
10306 Shirey                       Informational                    [Page 184]
10307 \f
10308 RFC 2828               Internet Security Glossary               May 2000
10309
10310
10311    $ unforgeable
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.)
10318
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.
10329
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]
10336
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]
10340
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
10344       Internet. [R1738]
10345
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
10356       query string.
10357
10358
10359
10360
10361
10362 Shirey                       Informational                    [Page 185]
10363 \f
10364 RFC 2828               Internet Security Glossary               May 2000
10365
10366
10367    $ uniform resource name (URN)
10368       (I) A URI that has an institutional commitment to persistence and
10369       availability.
10370
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:
10375       trusted process.)
10376
10377    $ UORA
10378       See: user-PIN ORA.
10379
10380    $ update
10381       See: certificate update and key update.
10382
10383    $ URI
10384       See: uniform resource identifier.
10385
10386    $ URL
10387       See: uniform resource locator.
10388
10389    $ URN
10390       See: uniform resource name.
10391
10392    $ user
10393       (I) A person, organization entity, or automated process that
10394       accesses a system, whether authorized to do so or not. (See:
10395       [R2504].)
10396
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
10399       be misunderstood.
10400
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.
10404
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.
10410
10411    $ user identifier
10412       (I) A character string or symbol that is used in a system to
10413       uniquely name a specific user or group of users.
10414
10415
10416
10417
10418 Shirey                       Informational                    [Page 186]
10419 \f
10420 RFC 2828               Internet Security Glossary               May 2000
10421
10422
10423       (C) Often verified by a password in an authentication process.
10424
10425    $ user PIN
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.
10430       (See: SSO PIN.)
10431
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.)
10437
10438    $ usurpation
10439       See: (secondary definition under) threat consequence.
10440
10441    $ UTCTime
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,
10448       GeneralizedTime.)
10449
10450    $ v1 certificate
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.
10458
10459       (D) ISDs SHOULD NOT use this term as an abbreviation for "version
10460       1 X.509 attribute certificate".
10461
10462    $ v1 CRL
10463       (I) An abbreviation for "X.509 CRL in version 1 format".
10464
10465       (C) ISDs should use this abbreviation only after using the full
10466       term at its first occurrence and defining the abbreviation.
10467
10468    $ v2 certificate
10469       (I) An abbreviation for "X.509 public-key certificate in version 2
10470       format".
10471
10472
10473
10474 Shirey                       Informational                    [Page 187]
10475 \f
10476 RFC 2828               Internet Security Glossary               May 2000
10477
10478
10479       (C) ISDs should use this abbreviation only after using the full
10480       term at its first occurrence and defining the abbreviation.
10481
10482    $ v2 CRL
10483       (I) An abbreviation for "X.509 CRL in version 2 format".
10484
10485       (C) ISDs should use this abbreviation only after using the full
10486       term at its first occurrence and defining the abbreviation.
10487
10488    $ v3 certificate
10489       (I) An abbreviation for "X.509 public-key certificate in version 3
10490       format".
10491
10492       (C) ISDs should use this abbreviation only after using the full
10493       term at its first occurrence and defining the abbreviation.
10494
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.)
10499
10500    $ valid signature
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
10505       vs. verify.)
10506
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.
10515
10516       ISDs SHOULD comply with the following two rules to ensure
10517       consistency and to align Internet security terminology with
10518       ordinary English:
10519
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.)
10523
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.)
10527
10528
10529
10530 Shirey                       Informational                    [Page 188]
10531 \f
10532 RFC 2828               Internet Security Glossary               May 2000
10533
10534
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.)
10542
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
10552       certificates.
10553
10554    $ validation
10555       See: validate vs. verify.
10556
10557    $ validity period
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.
10563
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.
10568
10569       (C) A VAN may also provide additional services, ranging from EDI
10570       format translation, to EDI-to-FAX conversion, to integrated
10571       business systems.
10572
10573    $ VAN
10574       See: value-added network.
10575
10576    $ verification
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.
10581       [NCS04]
10582
10583
10584
10585
10586 Shirey                       Informational                    [Page 189]
10587 \f
10588 RFC 2828               Internet Security Glossary               May 2000
10589
10590
10591       2. Identification verification: Presenting information to
10592       establish the truth of a claimed identity.
10593
10594    $ verify
10595       See: validate vs. verify.
10596
10597    $ violation
10598       See: security violation.
10599
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.
10607
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.
10616
10617    $ virus
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.
10623
10624    $ VPN
10625       See: virtual private network.
10626
10627    $ vulnerability
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.
10631
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
10639
10640
10641
10642 Shirey                       Informational                    [Page 190]
10643 \f
10644 RFC 2828               Internet Security Glossary               May 2000
10645
10646
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.
10652
10653    $ W3
10654       See: World Wide Web.
10655
10656    $ war dialer
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
10660       systems.
10661
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
10670       Regulations.)
10671
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.
10681
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
10695
10696
10697
10698 Shirey                       Informational                    [Page 191]
10699 \f
10700 RFC 2828               Internet Security Glossary               May 2000
10701
10702
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.
10710
10711    $ watermarking
10712       See: digital watermarking.
10713
10714    $ web of trust
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,
10719       mesh PKI.)
10720
10721    $ web server
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
10724       web browsers.
10725
10726    $ web vs. Web
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.)
10730
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.
10735
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.
10739
10740    $ wiretapping
10741       (I) An attack that intercepts and accesses data and other
10742       information contained in a flow in a communication system.
10743
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
10748       subnetwork switch.
10749
10750
10751
10752
10753
10754 Shirey                       Informational                    [Page 192]
10755 \f
10756 RFC 2828               Internet Security Glossary               May 2000
10757
10758
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.)
10763
10764    $ work factor
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.
10769
10770       (I) Cryptography usage: The estimated amount of computing time and
10771       power needed to break a cryptographic system.
10772
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].)
10778
10779    $ worm
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
10783       Worm, virus.)
10784
10785    $ wrap
10786       (O) To use cryptography to provide data confidentiality service
10787       for a data object. (See: encrypt, seal.)
10788
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
10792       mechanism used.
10793
10794    $ WWW
10795       See: World Wide Web.
10796
10797    $ X.400
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.)
10802
10803    $ X.500
10804    $ X.500 Directory
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
10807
10808
10809
10810 Shirey                       Informational                    [Page 193]
10811 \f
10812 RFC 2828               Internet Security Glossary               May 2000
10813
10814
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,
10819       X.509.)
10820
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.
10830
10831    $ X.509
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.)
10837
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.
10841
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.)
10847
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
10854       certificate.
10855
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:
10860
10861
10862
10863
10864
10865
10866 Shirey                       Informational                    [Page 194]
10867 \f
10868 RFC 2828               Internet Security Glossary               May 2000
10869
10870
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.
10878
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
10884                                 subject.
10885       8. issuerUniqueId         Optional, when a DN is not sufficient.
10886       9. extensions             Optional.
10887
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
10891       list.
10892
10893    $ X.509 certificate
10894       (N) Either an X.509 public-key certificate or an X.509 attribute
10895       certificate.
10896
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
10904       instance.
10905
10906       (D) ISDs SHOULD NOT use this term as an abbreviation to mean
10907       "X.509 attribute certificate".
10908
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.)
10915
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,
10919
10920
10921
10922 Shirey                       Informational                    [Page 195]
10923 \f
10924 RFC 2828               Internet Security Glossary               May 2000
10925
10926
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
10930       been revoked.
10931
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.
10936
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.
10947
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.)
10954
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.
10960
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.
10974
10975
10976
10977
10978 Shirey                       Informational                    [Page 196]
10979 \f
10980 RFC 2828               Internet Security Glossary               May 2000
10981
10982
10983    $ XTACACS
10984       See: (secondary definition under) Terminal Access Controller (TAC)
10985       Access Control System.
10986
10987    $ Yellow Book
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
10994       Series.)
10995
10996    $ zeroize
10997       (I) Use erasure or other means to render stored data unusable and
10998       unrecoverable, particularly a key stored in a cryptographic module
10999       or other device.
11000
11001       (O) Erase electronically stored data by altering the contents of
11002       the data storage so as to prevent the recovery of the data.
11003       [FP140]
11004
11005 4. References
11006
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.
11012
11013    [A3092]  American National Standards Institute, "American National
11014             Standard Data Encryption Algorithm", ANSI X3.92-1981, 30 Dec
11015             1980.
11016
11017    [A9009]  ---, "Financial Institution Message Authentication
11018             (Wholesale)", ANSI X9.9-1986, 15 Aug 1986.
11019
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
11024             environments.]
11025
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.
11029
11030
11031
11032
11033
11034 Shirey                       Informational                    [Page 197]
11035 \f
11036 RFC 2828               Internet Security Glossary               May 2000
11037
11038
11039    [A9052]  ---, "Triple Data Encryption Algorithm Modes of Operation",
11040             X9.52-1998, ANSI approval 9 Nov 1998.
11041
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.
11045
11046    [ABA]    American Bar Association, "Digital Signature Guidelines:
11047             Legal Infrastructure for Certification Authorities and
11048             Secure Electronic Commerce", Chicago, IL, 1 Aug 1996.
11049
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".
11055
11056    [Army]   U.S. Army Corps of Engineers, "Electromagnetic Pulse (EMP)
11057             and Tempest Protection for Facilities", EP 1110-3-2, 31 Dec
11058             1990.
11059
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.
11063
11064             ---, ---, "Part 2: Specification for Information Security
11065             Management Systems", BS 7799-2:1999, effective 15 May 1999.
11066
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.)
11071
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
11075             1999.
11076
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.]
11080
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
11084             [DOD1].)
11085
11086
11087
11088
11089
11090 Shirey                       Informational                    [Page 198]
11091 \f
11092 RFC 2828               Internet Security Glossary               May 2000
11093
11094
11095    [CSC2]   ---, "Department of Defense Password Management Guideline",
11096             CSC-STD-002-85, 12 Apr 1985.
11097
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
11101             1985.
11102
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.
11106
11107    [Denn]   D. E. Denning, "A Lattice Model of Secure Information Flow",
11108             in "Communications of the ACM", vol. 19, no. 5, May 1976,
11109             pp. 236-243.
11110
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.
11114
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].)
11118
11119    [DOD2]   ---, Directive 5200.28, "Security Requirements for Automated
11120             Information Systems (AISs)", 21 Mar 1988.
11121
11122    [DOD3]   ---, "X.509 Certificate Policy", ver. 2, Mar 1999.
11123
11124    [DOD4]   ---, "NSA Key Recovery Assessment Criteria", 8 Jun 1998.
11125
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-
11129             472.
11130
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.
11135
11136    [EMV2]   ---, "EMV '96 Integrated Circuit Card Terminal Specification
11137             for Payment Systems", ver. 3.1.1, 31 May 1998.
11138
11139    [EMV3]   ---, EMV '96 Integrated Circuit Card Application
11140             Specification for Payment Systems", ver. 3.1.1, 31 May 1998.
11141
11142
11143
11144
11145
11146 Shirey                       Informational                    [Page 199]
11147 \f
11148 RFC 2828               Internet Security Glossary               May 2000
11149
11150
11151    [For94]  W. Ford, "Computer Communications Security: Principles,
11152             Standard Protocols and Techniques", ISBN 0-13-799453-2,
11153             1994.
11154
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.
11158
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,
11162             Jun 1974.
11163
11164    [FP039]  ---, "Glossary for Computer Systems Security", FIPS PUB 39,
11165             15 Feb 1976.
11166
11167    [FP046]  ---, "Data Encryption Standard (DES)", FIPS PUB 46-2, 30 Dec
11168             1993.
11169
11170    [FP081]  ---, "DES Modes of Operation", FIPS PUB 81, 2 Dec 1980.
11171
11172    [FP102]  ---, "Guideline for Computer Security Certification and
11173             Accreditation", FIPS PUB 102, 27 Sep 1983.
11174
11175    [FP113]  ---, "Computer Data Authentication", FIPS PUB 113, 30 May
11176             1985.
11177
11178    [FP140]  ---, "Security Requirements for Cryptographic Modules", FIPS
11179             PUB 140-1, 11 Jan 1994.
11180
11181    [FP151]  ---, "Portable Operating System Interface (POSIX)--System
11182             Application Program Interface [C Language]", FIPS PUB 151-2,
11183             12 May 1993
11184
11185    [FP180]  ---, "Secure Hash Standard", FIPS PUB 180-1, 17 Apr 1995.
11186
11187    [FP185]  ---, "Escrowed Encryption Standard", FIPS PUB 185, 9 Feb
11188             1994.
11189
11190    [FP186]  ---, "Digital Signature Standard (DSS)", FIPS PUB 186, 19
11191             May 1994.
11192
11193    [FP188]  ---, "Standard Security Label for Information Transfer",
11194             FIPS PUB 188, 6 Sep 1994.
11195
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].)
11199
11200
11201
11202 Shirey                       Informational                    [Page 200]
11203 \f
11204 RFC 2828               Internet Security Glossary               May 2000
11205
11206
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.
11210
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.
11214
11215             ---, --- "Part 2: Country Subdivision Codes", ISO/DIS 3166-
11216             2.
11217
11218             ---, --- "Part 3: Codes for Formerly Used Names of
11219             Countries", ISO/DIS 3166-3.
11220
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
11224             X.200.)
11225
11226             ---, --- "Part 2: Security Architecture", ISO/IEC 7499-2.
11227
11228             ---, --- "Part 4: Management Framework", ISO/IEC 7498-4.
11229
11230    [I7812]  ---, "Identification cards--Identification of Issuers--Part
11231             1: Numbering System", ISO/IEC 7812-1:1993
11232
11233             ---, --- "Part 2: Application and Registration Procedures",
11234             ISO/IEC 7812-2:1993.
11235
11236    [I9945]  ---, "Portable Operating System Interface for Computer
11237             Environments", ISO/IEC 9945-1:1990.
11238
11239    [I15408] ---, "Information Technology--Security Techniques--
11240             Evaluation criteria for IT Security--Part 1: Introduction
11241             and General Model", ISO/IEC 15408-1:1999.
11242
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.
11247
11248    [Kahn]   David Kahn, "The Codebreakers: The Story of Secret Writing",
11249             The Macmillan Company, New York, 1967.
11250
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.
11254
11255
11256
11257
11258 Shirey                       Informational                    [Page 201]
11259 \f
11260 RFC 2828               Internet Security Glossary               May 2000
11261
11262
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,
11268             pp. 124-142.
11269
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,
11273             Sep 1997.
11274
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.)
11278
11279    [NCS04]  ---, "Glossary of Computer Security Terms", NCSC-TG-004,
11280             ver. 1, 21 Oct 1988. (Part of the Rainbow Series.)
11281
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.)
11285
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.)
11289
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)
11293
11294    [PGP]    Simson Garfinkel, "PGP: Pretty Good Privacy", O'Reilly &
11295             Associates, Inc., Sebastopol, CA, 1995.
11296
11297    [PKCS]   Burton S. Kaliski, Jr., "An Overview of the PKCS Standards",
11298             RSA Data Security, Inc., 3 Jun 1991.
11299
11300    [PKC07]  RSA Laboratories, "PKCS #7: Cryptographic Message Syntax
11301             Standard", ver. 1.5, RSA Laboratories Technical Note, 1 Nov
11302             1993.
11303
11304    [PKC10]  ---, "PKCS #10: Certification Request Syntax Standard", ver.
11305             1.0, RSA Laboratories Technical Note, 1 Nov 1993.
11306
11307    [PKC11]  ---, "PKCS #11: Cryptographic Token Interface Standard",
11308             ver. 1.0, 28 Apr 1995.
11309
11310
11311
11312
11313
11314 Shirey                       Informational                    [Page 202]
11315 \f
11316 RFC 2828               Internet Security Glossary               May 2000
11317
11318
11319    [R0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
11320             1980.
11321
11322    [R0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
11323             1981.
11324
11325    [R0792]  Postel, J., "Internet Control Message Protocol", STD 5, RFC
11326             792, September 1981. [See: RFC 1885.]
11327
11328    [R0793]  Postel, J., ed., "Transmission Control Protocol", STD 7, RFC
11329             793, September 1981.
11330
11331    [R0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
11332             821, August 1982.
11333
11334    [R0822]  Crocker, D., "Standard for the Format of ARPA Internet Text
11335             Messages", STD 11, RFC 822, August 1982.
11336
11337    [R0854]  Postel, J. and J. Reynolds, "TELNET Protocol Specification",
11338             STD 8, RFC 854, May 1983.
11339
11340    [R0959]  Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
11341             STD 9, RFC 959, October 1985.
11342
11343    [R1034]  Mockapetris, P., "Domain Names--Concepts and Facilities",
11344             STD 13, RFC 1034, November 1987.
11345
11346    [R1157]  Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
11347             Network Management Protocol (SNMP)" [version 1], STD 15, RFC
11348             1157, May 1990.
11349
11350    [R1208]  Jacobsen O. and D. Lynch, "A Glossary of Networking Terms",
11351             RFC 1208, March 1991.
11352
11353    [R1319]  Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
11354             April 1992.
11355
11356    [R1320]  Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320,
11357             April 1992.
11358
11359    [R1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
11360             April 1992.
11361
11362    [R1334]  Lloyd, B. and W. Simpson, "PPP Authentication Protocols",
11363             RFC 1334, October 1992.
11364
11365    [R1413]  St. Johns, M., "Identification Protocol", RFC 1413, February
11366             1993.
11367
11368
11369
11370 Shirey                       Informational                    [Page 203]
11371 \f
11372 RFC 2828               Internet Security Glossary               May 2000
11373
11374
11375    [R1421]  Linn, J., "Privacy Enhancement for Internet Electronic Mail,
11376             Part I: Message Encryption and Authentication Procedures",
11377             RFC 1421, February 1993.
11378
11379    [R1422]  Kent, S., "Privacy Enhancement for Internet Electronic Mail,
11380             Part II: Certificate-Based Key Management", RFC 1422,
11381             February 1993.
11382
11383    [R1455]  Eastlake, D., "Physical Link Security Type of Service", RFC
11384             1455, May 1993.
11385
11386    [R1457]  Housley, R., "Security Label Framework for the Internet",
11387             RFC 1457, May 1993.
11388
11389    [R1492]  Finseth, C., "An Access Control Protocol, Sometimes Called
11390             TACACS", RFC 1492, July 1993.
11391
11392    [R1507]  Kaufman, C., "DASS: Distributed Authentication Security
11393             Service", RFC 1507, September 1993.
11394
11395    [R1510]  Kohl, J. and C. Neuman, "The Kerberos Network Authentication
11396             Service (V5)", RFC 1510, September 1993.
11397
11398    [R1591]  Kohl, J. and C. Neuman, "Domain Name System Structure and
11399             Delegation", March 1994.
11400
11401    [R1630]  Berners-Lee, T., "Universal Resource Identifiers in WWW",
11402             RFC 1630, June 1994.
11403
11404    [R1661]  Simpson, W., ed., " The Point-to-Point Protocol (PPP)", STD
11405             51, RFC 1661, July 1994.
11406
11407    [R1731]  Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
11408             December 1994.
11409
11410    [R1734]  Myers, J., "POP3 AUTHentication Command", RFC 1734, December
11411             1994.
11412
11413    [R1738]  Myers, J., Masinter, L. and M. McCahill, ed's., "Uniform
11414             Resource Locators (URL)", RFC 1738, December 1994.
11415
11416    [R1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
11417             Recommendations for Security", RFC 1750, December 1994.
11418
11419    [R1777]  Yeong, W., Howes, T. and S. Kille, "Lightweight Directory
11420             Access Protocol", RFC 1777, March 1995.
11421
11422
11423
11424
11425
11426 Shirey                       Informational                    [Page 204]
11427 \f
11428 RFC 2828               Internet Security Glossary               May 2000
11429
11430
11431    [R1808]  Fielding, R., "Relative Uniform Resource Locators", RFC
11432             1808, June 1995.
11433
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.
11437
11438    [R1828]  Metzger, P. and W. Simpson, "IP Authentication using Keyed
11439             MD5", RFC 1828, August 1995.
11440
11441    [R1829]  Karn, P., Metzger, P. and W. Simpson, "The ESP DES-CBC
11442             Transform", RFC 1829, August 1995.
11443
11444    [R1848]  Crocker, S., Freed, N., Galvin, J. and S. Murphy, "MIME
11445             Object Security Services", RFC 1848, October 1995.
11446
11447    [R1851]  Karn, P., Metzger, P. and W. Simpson, "The ESP Triple DES
11448             Transform", RFC 1851, September 1995.
11449
11450    [R1866]  Berners-Lee, T., "Hypertext Markup Language--2.0", RFC 1866,
11451             November 1995.
11452
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.
11456
11457    [R1928]  Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L.
11458             Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
11459
11460    [R1938]  Haller, N. and C. Metzion, "A One-Time Password System", RFC
11461             1938, May 1996.
11462
11463    [R1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
11464             STD 53, RFC 1939, May 1996.
11465
11466    [R1958]  Carpenter, B., ed., "Architectural Principles of the
11467             Internet", RFC 1958, June 1996.
11468
11469    [R1983]  Malkin, G., ed., "Internet Users' Glossary", FYI 18, RFC
11470             1983, August 1996.
11471
11472    [R1994]  Simpson, W. "PPP Challenge Handshake Authentication Protocol
11473             (CHAP)", RFC 1994, August 1996.
11474
11475    [R2023]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
11476             RFC 2023, October 1997.
11477
11478
11479
11480
11481
11482 Shirey                       Informational                    [Page 205]
11483 \f
11484 RFC 2828               Internet Security Glossary               May 2000
11485
11486
11487    [R2026]  Bradner, S., "The Internet Standards Process--Revision 3",
11488             BCP 9, RFC 2026, March 1994.
11489
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.
11493
11494    [R2060]  Crispin, M., "Internet Message Access Protocol--Version 4
11495             Revision 1", RFC 2060, December 1996.
11496
11497    [R2065]  Eastlake, D., 3rd, "Domain Name System Security Extensions",
11498             RFC 2065, January 1997.
11499
11500    [R2078]  Linn, J., "Generic Security Service Application Program
11501             Interface, Version 2", RFC 2078, January 1997.
11502
11503    [R2084]  Bossert, G., Cooper, S. and W. Drummond, "Considerations for
11504             Web Transaction Security", RFC 2084, January 1997.
11505
11506    [R2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
11507             Hashing for Message Authentication", RFC 2104, February
11508             1997.
11509
11510    [R2119]  Bradner, S., "Key Words for Use in RFCs To Indicate
11511             Requirement Levels", BCP 14, RFC 2119, March 1997.
11512
11513    [R2138]  Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
11514             Authentication Dial In User Service (RADIUS)", RFC 2138,
11515             April 1997.
11516
11517    [R2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
11518             RFC 2137, April 1997.
11519
11520    [R2179]  Gwinn, A., "Network Security For Trade Shows", RFC 2179,
11521             July 1997.
11522
11523    [R2195]  Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize
11524             Extension for Simple Challenge/Response", RFC 2195, Sepember
11525             1997.
11526
11527    [R2196]  Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
11528             Sepember 1997.
11529
11530    [R2202]  Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
11531             SHA-1", RFC 2202, Sepember 1997.
11532
11533
11534
11535
11536
11537
11538 Shirey                       Informational                    [Page 206]
11539 \f
11540 RFC 2828               Internet Security Glossary               May 2000
11541
11542
11543    [R2222]  Myers, J., "Simple Authentication and Security Layer
11544             (SASL)", RFC 2222, October 1997.
11545
11546    [R2223]  Postel, J., "Instructions to RFC Authors", RFC 2223, October
11547             1997.
11548
11549    [R2246]  Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0",
11550             RFC 2246, January 1999.
11551
11552    [R2284]  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
11553             Protocol (EAP)", RFC 2284, March 1998.
11554
11555    [R2315]  Kaliski, B., "PKCS #7: Cryptographic Message Syntax, Version
11556             1.5", RFC 2315, March 1998.
11557
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.]
11562
11563    [R2350]  Brownlee, N. and E. Guttman, "Expectations for Computer
11564             Security Incident Response", RFC 2350, June 1998.
11565
11566    [R2356]  Montenegro, C. and V. Gupta, "Sun's SKIP Firewall Traversal
11567             for Mobile IP", RFC 2356, June 1998.
11568
11569    [R2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
11570             Architecture", RFC 2373, July 2998.
11571
11572    [R2401]  Kent, S. and R. Atkinson, "Security Architecture for the
11573             Internet Protocol", RFC 2401, November 1998.
11574
11575    [R2402]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC
11576             2402, November 1998.
11577
11578    [R2403]  Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP
11579             and AH", RFC 2403, November 1998.
11580
11581    [R2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
11582             ESP and AH", RFC 2404, November 1998.
11583
11584    [R2405]  Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
11585             Algorithm With Explicit IV", RFC 2405, November 1998.
11586
11587    [R2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
11588             (ESP)", RFC 2406, November 1998.
11589
11590
11591
11592
11593
11594 Shirey                       Informational                    [Page 207]
11595 \f
11596 RFC 2828               Internet Security Glossary               May 2000
11597
11598
11599    [R2407]  Piper, D., "The Internet IP Security Domain of
11600             Interpretation for ISAKMP", RFC 2407, November 1998.
11601
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.
11605
11606    [R2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
11607             (IKE)", RFC 2409, November 1998.
11608
11609    [R2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
11610             Its Use With IPsec", RFC 2410, November 1998.
11611
11612    [R2412]  Orman, H., "The OAKLEY Key Determination Protocol", RFC
11613             2412, November 1998.
11614
11615    [R2451]  Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
11616             Algorithms", RFC 2451, November 1998.
11617
11618    [R2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
11619             (IPv6) Specification", RFC 2460, December 1998.
11620
11621    [R2504]  Guttman, E., Leong, L. and G. Malkin, "Users' Security
11622             Handbook", RFC 2504, February 1999.
11623
11624    [R2510]  Adams, C. and S. Farrell, "Internet X.509 Public Key
11625             Infrastructure Certificate Management Protocols", RFC 2510,
11626             March 1999.
11627
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.
11631
11632    [R2536]  EastLake, D., "DSA KEYs and SIGs in the Domain Name System
11633             (DNS)", RFC 2536, March 1999.
11634
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.
11638
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.
11642
11643    [R2612]  Adams, C. and J. Gilchrist, "The CAST-256 Encryption
11644             Algorithm", RFC 2612, June 1999.
11645
11646
11647
11648
11649
11650 Shirey                       Informational                    [Page 208]
11651 \f
11652 RFC 2828               Internet Security Glossary               May 2000
11653
11654
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.
11658
11659    [R2628]  Smyslov, V., "Simple Cryptographic Program Interface", RFC
11660             2628, June 1999.
11661
11662    [R2630]  Housley, R., "Cryptographic Message Syntax", RFC 2630, June
11663             1999.
11664
11665    [R2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
11666             2631, June 1999.
11667
11668    [R2633]  Ramsdell, B., ed., "S/MIME Version 3 Message Specification",
11669             RFC 2633, June 1999.
11670
11671    [R2634]  Hoffman, P., ed., "Enhanced Security Services for S/MIME",
11672             RFC 2634, June 1999.
11673
11674    [R2635]  Hambridge, S. and A. Lunde, "Don't Spew: A Set of Guidelines
11675             for Mass Unsolicited Mailings and Postings", RFC 2635, June
11676             1999.
11677
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
11682             version.)
11683
11684    [Russ]   D. Russell and G. T. Gangemi Sr., Chapter 10 ("TEMPEST") in
11685             "Computer Security Basics", ISBN 0-937175-71-4, 1991.
11686
11687    [Schn]   B. Schneier, "Applied Cryptography", John Wiley & Sons,
11688             Inc., New York, 1994.
11689
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.
11693
11694    [SDNS4]  ---, ---, "Security Protocol 4 (SP4)", document SDN.401,
11695             Revision 1.2, 12 Jul 1988.
11696
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.
11701
11702
11703
11704
11705
11706 Shirey                       Informational                    [Page 209]
11707 \f
11708 RFC 2828               Internet Security Glossary               May 2000
11709
11710
11711    [SET1]   MasterCard and Visa, "SET Secure Electronic Transaction
11712             Specification, Book 1: Business Description", ver. 1.0, 31
11713             May 1997.
11714
11715    [SET2]   ---, "SET Secure Electronic Transaction Specification, Book
11716             2: Programmer's Guide", ver. 1.0, 31 May 1997.
11717
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.
11721
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".
11726
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.)
11730
11731    [X501]   ---, Recommendation X.501, "Information Technology--Open
11732             Systems Interconnection--The Directory: Models".
11733
11734    [X509]   ---, Recommendation X.509, "Information Technology--Open
11735             Systems Interconnection--The Directory: Authentication
11736             Framework". (Equivalent to ISO 9594-8.)
11737
11738    [X519]   ---, Recommendation X.519, "Information Technology--Open
11739             Systems Interconnection--The Directory: Protocol
11740             Specifications".
11741
11742    [X520]   ---, Recommendation X.520, "Information Technology--Open
11743             Systems Interconnection--The Directory: Selected Attribute
11744             Types".
11745
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.)
11749
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.)
11754
11755
11756
11757
11758
11759
11760
11761
11762 Shirey                       Informational                    [Page 210]
11763 \f
11764 RFC 2828               Internet Security Glossary               May 2000
11765
11766
11767 5. Security Considerations
11768
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.
11772
11773 6. Acknowledgments
11774
11775    Pat Cain, Mike Kong, and Charles Lynn provided meticulous comments on
11776    an early draft.
11777
11778 7. Author's Address
11779
11780    Please address all comments to:
11781
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
11786
11787
11788
11789
11790
11791
11792
11793
11794
11795
11796
11797
11798
11799
11800
11801
11802
11803
11804
11805
11806
11807
11808
11809
11810
11811
11812
11813
11814
11815
11816
11817
11818 Shirey                       Informational                    [Page 211]
11819 \f
11820 RFC 2828               Internet Security Glossary               May 2000
11821
11822
11823 8. Full Copyright Statement
11824
11825    Copyright (C) The Internet Society (2000).  All Rights Reserved.
11826
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
11839    English.
11840
11841    The limited permissions granted above are perpetual and will not be
11842    revoked by the Internet Society or its successors or assigns.
11843
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.
11850
11851 Acknowledgement
11852
11853    Funding for the RFC Editor function is currently provided by the
11854    Internet Society.
11855
11856
11857
11858
11859
11860
11861
11862
11863
11864
11865
11866
11867
11868
11869
11870
11871
11872
11873
11874 Shirey                       Informational                    [Page 212]
11875 \f