idnits 2.17.00 (12 Aug 2021) /tmp/idnits27304/draft-shirey-secgloss-v2-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 17097), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 83: '...endations -- especially for the SHOULD...' RFC 2119 keyword, line 170: '... that are RECOMMENDED for use in ...' RFC 2119 keyword, line 198: '... - "I" for a RECOMMENDED term or d...' RFC 2119 keyword, line 199: '... - "N" if RECOMMENDED but not of...' RFC 2119 keyword, line 203: '...tion that is deprecated and SHOULD NOT...' (254 more instances...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2828, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 12007 has weird spacing: '...dentity v ...' == Line 14629 has weird spacing: '...ication may b...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 August 2006) is 5750 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Government' is mentioned on line 949, but not defined == Missing Reference: 'DGSA' is mentioned on line 12546, but not defined == Missing Reference: 'CORBA' is mentioned on line 5156, but not defined == Missing Reference: 'R2246' is mentioned on line 6568, but not defined == Missing Reference: 'RFC 2323' is mentioned on line 7477, but not defined == Missing Reference: 'SP-28' is mentioned on line 9117, but not defined == Missing Reference: 'CSC001' is mentioned on line 15067, but not defined == Missing Reference: 'IS7498-2' is mentioned on line 9929, but not defined == Missing Reference: 'IS9945-1' is mentioned on line 10836, but not defined == Missing Reference: 'IS7812' is mentioned on line 10920, but not defined == Missing Reference: 'C4008' is mentioned on line 11139, but not defined == Missing Reference: 'EU-ESDIR' is mentioned on line 11432, but not defined == Missing Reference: 'RSA78' is mentioned on line 11926, but not defined == Missing Reference: 'Constraints' is mentioned on line 12010, but not defined == Missing Reference: 'PKCS12' is mentioned on line 13289, but not defined == Missing Reference: 'R3776' is mentioned on line 13832, but not defined == Missing Reference: 'DoDAF1' is mentioned on line 14052, but not defined == Missing Reference: 'FIPS31' is mentioned on line 14430, but not defined == Missing Reference: 'CA' is mentioned on line 14929, but not defined == Missing Reference: 'NIST' is mentioned on line 15299, but not defined == Missing Reference: 'FIPS' is mentioned on line 15300, but not defined == Unused Reference: 'Army' is defined on line 16180, but no explicit reference was found in the text == Unused Reference: 'DoD6' is defined on line 16291, but no explicit reference was found in the text == Unused Reference: 'DoDGSA' is defined on line 16301, but no explicit reference was found in the text == Unused Reference: 'ElGa' is defined on line 16312, but no explicit reference was found in the text == Unused Reference: 'FP041' is defined on line 16350, but no explicit reference was found in the text == Unused Reference: 'FP191' is defined on line 16390, but no explicit reference was found in the text == Unused Reference: 'I7812' is defined on line 16436, but no explicit reference was found in the text == Unused Reference: 'I9945' is defined on line 16464, but no explicit reference was found in the text == Unused Reference: 'IDSSC' is defined on line 16473, but no explicit reference was found in the text == Unused Reference: 'IDSSE' is defined on line 16476, but no explicit reference was found in the text == Unused Reference: 'IDSSY' is defined on line 16479, but no explicit reference was found in the text == Unused Reference: 'Knut' is defined on line 16500, but no explicit reference was found in the text == Unused Reference: 'N4006' is defined on line 16536, but no explicit reference was found in the text == Unused Reference: 'NCS03' is defined on line 16546, but no explicit reference was found in the text == Unused Reference: 'PKCS' is defined on line 16587, but no explicit reference was found in the text == Unused Reference: 'PKC12' is defined on line 16602, but no explicit reference was found in the text == Unused Reference: 'R1750' is defined on line 16657, but no explicit reference was found in the text == Unused Reference: 'R2323' is defined on line 16725, but no explicit reference was found in the text == Unused Reference: 'R2356' is defined on line 16733, but no explicit reference was found in the text == Unused Reference: 'R2801' is defined on line 16798, but no explicit reference was found in the text == Unused Reference: 'R3766' is defined on line 16844, but no explicit reference was found in the text == Unused Reference: 'R3820' is defined on line 16848, but no explicit reference was found in the text == Unused Reference: 'SP27' is defined on line 16962, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2898 (ref. 'PKC05') (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 1319 (Obsoleted by RFC 6149) -- Obsolete informational reference (is this intentional?): RFC 1320 (Obsoleted by RFC 6150) -- Obsolete informational reference (is this intentional?): RFC 1334 (Obsoleted by RFC 1994) -- Obsolete informational reference (is this intentional?): RFC 1455 (Obsoleted by RFC 2474) -- Obsolete informational reference (is this intentional?): RFC 1734 (Obsoleted by RFC 5034) -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 10 errors (**), 0 flaws (~~), 51 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. W. Shirey 2 Obsoletes: RFC 2828, FYI 36 BBN Technologies Corp. 3 Expiration Date: 22 February 2007 22 August 2006 5 Internet Security Glossary, Version 2 6 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 This document may not be modified, and derivative works of it may 16 not be created, except to publish it as an RFC and to translate it 17 into languages other than English. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than a "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). All Rights Reserved. 38 Abstract 40 This Glossary provides definitions, abbreviations, and explanations 41 of terminology for information system security. The 297 pages of 42 entries offer recommendations to improve the clarity of Internet 43 Standards documents (ISDs) and to make them more easily understood by 44 international readers. The recommendations follow the principles that 45 ISDs should (a) use the same term or definition whenever the same 46 concept is mentioned; (b) use terms in their plainest, dictionary 47 sense; (c) use terms that are already well-established in open 48 publications; and (d) avoid terms that either favor a particular 49 vendor or favor a particular technology or mechanism over other, 50 competing techniques that already exist or could be developed. 52 Table of Contents 54 Section Page 55 ------- ---- 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Format of Entries . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1 Order of Entries . . . . . . . . . . . . . . . . . . . . . 4 59 2.2 Capitalization and Abbreviation . . . . . . . . . . . . . 4 60 2.3 Support for Automated Searching . . . . . . . . . . . . . 5 61 2.4 Definition Type and Context . . . . . . . . . . . . . . . 5 62 2.5 Explanatory Notes . . . . . . . . . . . . . . . . . . . . 5 63 2.6 Cross-References . . . . . . . . . . . . . . . . . . . . . 5 64 2.7 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.8 The New Punctuation . . . . . . . . . . . . . . . . . . . 6 66 3. Types of Entries . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1 Type "I": Recommended Definitions of Internet Origin . . . 7 68 3.2 Type "N": Recommended Definitions of Non-Internet Origin . 7 69 3.3 Type "O": Other Terms and Definitions to be Noted . . . . 7 70 3.4 Type "D": Deprecated Terms and Definitions . . . . . . . . 8 71 3.5 Definition Substitutions . . . . . . . . . . . . . . . . . 8 72 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. Informative References . . . . . . . . . . . . . . . . . . . . 314 74 6. Security Considerations and IANA Considerations . . . . . . . 333 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 333 76 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 333 77 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 333 79 1. Introduction 81 This Glossary is *not* an Internet Standard, and its recommendations 82 represent only the opinions of its author. However, this Glossary 83 provides reasons for its recommendations -- especially for the SHOULD 84 NOTs -- so that readers can judge for themselves what to do. 86 This Glossary provides an internally consistent and self-contained 87 set of terms, abbreviations, and definitions -- supported by 88 explanations, recommendations, and references -- for terminology that 89 concerns information system security. The intent of this Glossary is 90 to improve the comprehensibility of Internet Standards documents 91 (ISDs) -- i.e., RFCs, Internet-Drafts, and other material produced as 92 part of the Internet Standards Process (RFC 2026) -- and other 93 Internet-related discourse. A few non-security, networking terms are 94 included to make the Glossary self-contained, but more complete 95 glossaries of such terms are available elsewhere [A1523, F1037, 96 R1208, R1983]. 98 This Glossary supports the goals of the Internet Standards Process: 100 o Clear, Concise, Easily Understood Documentation 102 This Glossary seeks to improve comprehensibility of security- 103 related content of ISDs. That requires wording to be clear and 104 understandable, and requires the set of security-related terms and 105 definitions to be consistent and self-supporting. Also, 106 terminology needs to be uniform across all ISDs; i.e., the same 107 term or definition needs to be used whenever and wherever the same 108 concept is mentioned. Harmonization of existing ISDs need not be 109 done immediately, but it is desirable to correct and standardize 110 terminology when new versions are issued in the normal course of 111 standards development and evolution. 113 o Technical Excellence 115 Just as Internet Standard (STD) protocols should operate 116 effectively, ISDs should use terminology accurately, precisely, 117 and unambiguously to enable standards to be implemented correctly. 119 o Prior Implementation and Testing 121 Just as STD protocols require demonstrated experience and 122 stability before adoption, ISDs need to use well-established 123 language; and the robustness principle for protocols -- "be 124 liberal in what you accept, and conservative in what you send" -- 125 is also applicable to the language used in ISDs that describe 126 protocols. Using terms in their plainest, dictionary sense (when 127 appropriate) helps to ensure international understanding. ISDs 128 need to avoid using private, newly invented terms in place of 129 generally accepted terms from open publications. ISDs need to 130 avoid substituting new definitions that conflict with established 131 ones. ISDs need to avoid using "cute" synonyms (e.g., "Green 132 Book"), because no matter how popular a nickname may be in one 133 community, it is likely to cause confusion in another. 135 o Openness, Fairness, and Timeliness 137 ISDs need to avoid using proprietary and trademarked terms for 138 purposes other than referring to those particular systems. ISDs 139 also need to avoid terms that either favor a particular vendor or 140 favor a particular security technology or mechanism over other, 141 competing techniques that already exist or might be developed in 142 the future. The set of terminology used across the set of ISDs 143 needs to be flexible and adaptable as the state of Internet 144 security art evolves. 146 In support of those goals, this Glossary provides guidance by marking 147 terms and definitions as being either endorsed or deprecated for use 148 in ISDs. The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 149 and "OPTIONAL" are intended to be interpreted the same way as in an 150 Internet Standard (i.e., as specified in RFC 2119). Other glossaries 151 (e.g., [Raym]) list additional terms that deal with Internet security 152 but have not been included in this Glossary because they are not 153 appropriate for ISDs. 155 2. Format of Entries 157 Section 4 presents Glossary entries in the following manner: 159 2.1 Order of Entries 161 Entries are sorted in lexicographic order, without regard to 162 capitalization. Numeric digits are treated as preceding alphabetic 163 characters, and special characters are treated as preceding 164 digits. Blanks are treated as preceding non-blank characters, 165 except that a hyphen or slash between the parts of a multiword 166 entry (e.g., "RED/BLACK separation") is treated like a blank. 168 If an entry has multiple definitions (e.g., "domain"), they are 169 numbered beginning with "1", and any of those multiple definitions 170 that are RECOMMENDED for use in ISDs are presented before other 171 definitions for that entry. If definitions are closely related 172 (e.g., "threat"), they are denoted by adding letters to a number, 173 such as "1a" and "1b". 175 2.2 Capitalization and Abbreviations 177 Entries that are proper nouns are capitalized (e.g., "Data 178 Encryption Algorithm"), as are other words derived from proper 179 nouns (e.g., "Caesar cipher"). All other entries are not 180 capitalized (e.g., "certification authority"). Each acronym or 181 other abbreviation that appears in this Glossary, either as an 182 entry or in a definition or explanation, is defined in this 183 Glossary, except items of common English usage, such as "a.k.a.", 184 "e.g.", "etc.", "i.e.", "vol.", "pp.", and "U.S.". 186 2.3 Support for Automated Searching 188 Each entry is preceded by a dollar sign ($) and a space. This 189 makes it possible to find the defining entry for an item "X" by 190 searching for the character string "$ X", without stopping at 191 entries in which "X" is used in explanations. 193 2.4 Definition Type and Context 195 Each entry is preceded by a character -- I, N, O, or D -- enclosed 196 in parentheses, to indicate the type of definition (as is 197 explained further in Section 3): 198 - "I" for a RECOMMENDED term or definition of Internet origin. 199 - "N" if RECOMMENDED but not of Internet origin. 200 - "O" for a term or definition that is NOT recommended for use in 201 ISDs but is something that authors of Internet documents should 202 know about. 203 - "D" for a term or definition that is deprecated and SHOULD NOT 204 be used in Internet documents. 206 If a definition is valid only in a specific context (e.g., 207 "baggage"), that context is shown immediately following the 208 definition type and is enclosed by a pair of slash symbols (/). If 209 the definition is valid only for specific parts of speech, that is 210 shown in the same way (e.g., "archive"). 212 2.5 Explanatory Notes 214 Some entries have explanatory text that is introduced by one or 215 more of the following keywords: 216 - Deprecated Abbreviation (e.g., "EE", "H field", "W3") 217 - Deprecated Definition (e.g., "digital certification") 218 - Deprecated Usage (e.g., "authenticate") 219 - Deprecated Term (e.g., "certificate authority") 220 - Pronunciation (e.g., "*-property") 221 - Derivation (e.g., "discretionary access control") 222 - Tutorial (e.g., "accreditation") 223 - Example (e.g., "back door") 224 - Usage (e.g., "access") 226 Explanatory text in this Glossary MAY be reused in other ISDs. 227 However, such text is not intended to authoritatively supersede 228 text of an ISD in which the Glossary entry is already used. 230 2.6 Cross-References 232 Some entries contain a parenthetical remark of the form "(See: 233 X.)", where X is a list of other, related terms. Some entries 234 contain a remark of the form "(Compare: X)", where X is a list of 235 terms that either are antonyms of the entry or differ in some 236 other manner worth noting. 238 2.7 Trademarks 240 All servicemarks and trademarks that appear in this Glossary are 241 used in an editorial fashion and to the benefit of the mark owner, 242 without any intention of infringement. 244 2.8 The New Punctuation 246 This Glossary uses the "new" or "logical" punctuation style 247 favored by computer programmers, as described by Raymond [Raym]: 248 Programmers use pairs of quotation marks the same way they use 249 pairs of parentheses, i.e., as balanced delimiters. For example, 250 if "Alice sends" is a phrase, and so are "Bill receives" and "Eve 251 listens", then a programmer would write the following sentence: 253 "Alice sends", "Bill receives", and "Eve listens". 255 According to standard American usage, the punctuation in that 256 sentence is incorrect; the continuation commas and the final 257 period should go inside the string quotes, like this: 259 "Alice sends," "Bill receives," and "Eve listens." 261 However, a programmer would not include a character in a literal 262 string if the character did not belong there, because that could 263 cause an error. For example, suppose a sentence in a draft of a 264 tutorial on the vi editing language looked like this: 266 Then delete one line from the file by typing "dd". 268 A book editor following standard usage might change the sentence 269 to look like this: 271 Then delete one line from the file by typing "dd." 273 However, in the vi language, the dot character repeats the last 274 command accepted. So, if a reader entered "dd.", two lines would 275 be deleted instead of one. 277 Similarly, use of standard American punctuation might cause 278 misunderstanding in entries in this Glossary. Thus, the new 279 punctuation is used here, and we recommend it for ISDs. 281 3. Types of Entries 283 Each entry in this Glossary is marked as type I, N, O, or D: 285 3.1 Type "I": Recommended Definitions of Internet Origin 287 The marking "I" indicates two things: 288 - Origin: "I" (as opposed to "N") means either that the Internet 289 Standards Process or Internet community is authoritative for 290 the definition *or* that the term is sufficiently generic that 291 this Glossary can freely state a definition without 292 contradicting a non-Internet authority (e.g., "attack"). 293 - Recommendation: "I" (as opposed to "O") means that the term and 294 definition are RECOMMENDED for use in ISDs. However, some "I" 295 entries may be accompanied by a "Usage" note that states a 296 limitation (e.g., "certification"), and ISDs SHOULD NOT use the 297 defined term outside that limited context. 299 Many "I" entries are proper nouns (e.g., "Internet Protocol") for 300 which the definition is intended only to provide basic 301 information; i.e., the authoritative definition of such terms is 302 found elsewhere. For a proper noun described as an "Internet 303 protocol", please refer to the current edition of "Internet 304 Official Protocol Standards" (Standard 1) for the standardization 305 status of the protocol. 307 3.2 Type "N": Recommended Definitions of Non-Internet Origin 309 The marking "N" indicates two things: 310 - Origin: "N" (as opposed to "I") means that the entry has a non- 311 Internet basis or origin. 312 - Recommendation: "N" (as opposed to "O") means that the term and 313 definition are RECOMMENDED for use in ISDs, if they are needed 314 at all in ISDs. Many of these entries are accompanied by a 315 label that states a context (e.g., "package") or a note that 316 states a limitation (e.g., "data integrity"), and ISDs SHOULD 317 NOT use the defined term outside that context or limit. Some of 318 the contexts are rarely if ever expected to occur in an ISD 319 (e.g., "baggage"). In those cases, the listing exists to make 320 Internet authors aware of the non-Internet usage so that they 321 can avoid conflicts with non-Internet documents. 323 3.3 Type "O": Other Terms and Definitions To Be Noted 325 The marking "O" means that the definition is of non-Internet 326 origin and SHOULD NOT be used in ISDs *except* in cases where the 327 term is specifically identified as non-Internet. 329 For example, an ISD might mention "BCA" (see: brand certification 330 authority) or "baggage" as an example of some concept; in that 331 case, the document should specifically say "SET(trademark) BCA" or 332 "SET(trademark) baggage" and include the definition of the term. 334 3.4 Type "D": Deprecated Terms and Definitions 336 If this Glossary recommends that a term or definition SHOULD NOT 337 be used in ISDs, then the entry is marked as type "D", and an 338 explanatory note -- "Deprecated Term", "Deprecated Abbreviation", 339 "Deprecated Definition", or "Deprecated Usage" -- is provided. 341 3.5 Definition Substitutions 343 Some terms have a definition published by a non-Internet authority 344 -- a government (e.g., "object reuse"), an industry (e.g., "Secure 345 Data Exchange"), a national authority (e.g., "Data Encryption 346 Standard"), or an international body (e.g., "data 347 confidentiality") -- that is suitable for use in ISDs. In those 348 cases, this Glossary marks the definition "N", recommending its 349 use in Internet documents. 351 Other such terms have definitions that are inadequate or 352 inappropriate for ISDs. For example, a definition might be 353 outdated or too narrow, or it might need clarification by 354 substituting more careful wording (e.g., "authentication 355 exchange") or explanations, using other terms that are defined in 356 this Glossary. In those cases, this Glossary marks the entry "O", 357 and provides an "I" or "N" entry that precedes, and is intended to 358 supersede, the "O" entry. 360 In some cases where this Glossary provides a definition to 361 supersede an "O" definition, the substitute is intended to subsume 362 the meaning of the "O" entry and not conflict with it. For the 363 term "security service", for example, the "O" definition deals 364 narrowly with only communication services provided by layers in 365 the OSIRM and is inadequate for the full range of ISD usage, while 366 the new "I" definition provided by this Glossary can be used in 367 more situations and for more kinds of service. However, the "O" 368 definition is also listed so that ISD authors will be aware of the 369 context in which the term is used more narrowly. 371 When making substitutions, this Glossary attempts to avoid 372 contradicting any non-Internet authority. Still, terminology 373 differs between authorities such as the American Bar Association, 374 OSI, SET, the U.S. DoD, and other authorities; and this Glossary 375 probably is not exactly aligned with any of them. 377 4. Definitions 379 $ *-property 380 (N) Synonym for "confinement property" in the context of the Bell- 381 LaPadula model. Pronunciation: star property. 383 $ 3DES 384 (N) See: Triple Data Encryption Algorithm. 386 $ A1 computer system 387 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 388 Evaluation Criteria". (Compare: beyond A1.) 390 $ AA 391 (D) See: "Deprecated Abbreviation" under "attribute authority". 393 $ ABA Guidelines 394 (N) "American Bar Association (ABA) Digital Signature Guidelines" 395 [DSG], a framework of legal principles for using digital 396 signatures and digital certificates in electronic commerce. 398 $ Abstract Syntax Notation One (ASN.1) 399 (N) A standard for describing data objects. [Larm, X680] (See: 400 CMS.) 402 Usage: ISDs SHOULD use the term "ASN.1" narrowly to 403 describe the notation or language called "Abstract 404 Syntax Notation One". ISDs MAY use the term more broadly 405 to encompass the notation, its associated encoding rules 406 (see: BER), and software tools that assist in its use, 407 when the context makes this meaning clear. 409 Tutorial: OSIRM defines computer network functionality in layers. 410 Protocols and data objects at higher layers are abstractly defined 411 to be implemented using protocols and data objects from lower 412 layers. A higher layer may define transfers of abstract objects 413 between computers, and a lower layer may define those transfers 414 concretely as strings of bits. Syntax is needed to specify data 415 formats of abstract objects, and encoding rules are needed to 416 transform abstract objects into bit strings at lower layers. OSI 417 standards use ASN.1 for those specifications and use various 418 encoding rules for those transformations. (See: BER.) 420 In ASN.1, formal names are written without spaces, and separate 421 words in a name are indicated by capitalizing the first letter of 422 each word except the first word. For example, the name of a CRL is 423 "certificateRevocationList". 425 $ ACC 426 (I) See: access control center. 428 $ acceptable risk 429 (I) A risk that is understood and tolerated by a system's user, 430 operator, owner, or accreditor, usually because the cost or 431 difficulty of implementing an effective countermeasure for the 432 associated vulnerability exceeds the expectation of loss. (See: 433 adequate security, risk, "second law" under "Courtney's laws".) 435 $ access 436 1a. (I) The ability and means to communicate with or otherwise 437 interact with a system to use system resources either to handle 438 information or to gain knowledge of the information the system 439 contains. (Compare: handle.) 441 Usage: The definition is intended to include all types of 442 communication with a system, including one-way communication in 443 either direction. In actual practice, however, passive users might 444 be treated as not having "access" and, therefore, be exempt from 445 most requirements of the system's security policy. (See: "passive 446 user" under "user".) 448 1a. (O) "Opportunity to make use of an information system (IS) 449 resource." [C4009] 451 2. (O) /formal model/ "A specific type of interaction between a 452 subject and an object that results in the flow of information from 453 one to the other." [NCS04] 455 $ Access Certificate for Electronic Services (ACES) 456 (O) A PKI operated by the U.S. Government's General Services 457 Administration in cooperation with industry partners. (See: CAM.) 459 $ access control 460 1. (I) Protection of system resources against unauthorized access. 462 2. (I) A process by which use of system resources is regulated 463 according to a security policy and is permitted only by authorized 464 entities (users, programs, processes, or other systems) according 465 to that policy. (See: access, access control service, computer 466 security, discretionary access control, mandatory access control, 467 role-based access control.) 469 3. (I) /formal model/ Limitations on interactions between subjects 470 and objects in an information system. 472 4. (O) "The prevention of unauthorized use of a resource, 473 including the prevention of use of a resource in an unauthorized 474 manner." [I7498-2] 476 5. (O) /U.S. Government/ A system using physical, electronic, or 477 human controls to identify or admit personnel with properly 478 authorized access to a SCIF. 480 $ access control center (ACC) 481 (I) A computer that maintains a database (possibly in the form of 482 an access control matrix) defining the security policy for an 483 access control service, and that acts as a server for clients 484 requesting access control decisions. 486 Tutorial: An ACC is sometimes used in conjunction with a key 487 center to implement access control in a key-distribution system 488 for symmetric cryptography. (See: BLACKER, Kerberos.) 490 $ access control list (ACL) 491 (I) /information system/ A mechanism that implements access 492 control for a system resource by enumerating the system entities 493 that are permitted to access the resource and stating, either 494 implicitly or explicitly, the access modes granted to each entity. 495 (Compare: access control matrix, access list, access profile, 496 capability list.) 498 $ access control matrix 499 (I) A rectangular array of cells, with one row per subject and one 500 column per object. The entry in a cell -- that is, the entry for a 501 particular subject-object pair -- indicates the access mode that 502 the subject is permitted to exercise on the object. Each column is 503 equivalent to an "access control list" for the object; and each 504 row is equivalent to an "access profile" for the subject. 506 $ access control service 507 (I) A security service that protects against a system entity using 508 a system resource in a way not authorized by the system's security 509 policy. (See: access control, discretionary access control, 510 identity-based security policy, mandatory access control, rule- 511 based security policy.) 513 Tutorial: This service includes protecting against use of a 514 resource in an unauthorized manner by an entity (i.e., a 515 principal) that is authorized to use the resource in some other 516 manner. (See: insider.) The two basic mechanisms for implementing 517 this service are ACLs and tickets. 519 $ access level 520 1. (D) Synonym for the hierarchical "classification level" in a 521 security level. [C4009] (See: security level.) 523 2. (D) Synonym for "clearance level". 525 Deprecated Definitions: ISDs SHOULD NOT use this term with these 526 definitions because they duplicate the meaning of more specific 527 terms. Any ISD that uses this term SHOULD provide a specific 528 definition for it because access control may be based on many 529 attributes other than classification level and clearance level. 531 $ access list 532 (I) /physical security/ Roster of persons who are authorized to 533 enter a controlled area. (Compare: access control list.) 535 $ access mode 536 (I) A distinct type of data processing operation (e.g., read, 537 write, append, or execute, or a combination of operations) that a 538 subject can potentially perform on an object in an information 539 system. [Huff] (See: read, write.) 541 $ access policy 542 (I) A kind of "security policy". (See: access, access control.) 544 $ access profile 545 (O) Synonym for "capability list". 547 Usage: ISDs that use this term SHOULD state a definition for it 548 because the definition is not widely known. 550 $ access right 551 (I) Synonym for "authorization"; emphasizes the possession of the 552 authorization by a system entity. 554 $ accountability 555 (I) The property of a system or system resource that ensures that 556 the actions of a system entity may be traced uniquely to that 557 entity, which can then be held responsible for its actions. [Huff] 558 (See: audit service.) 560 Tutorial: Accountability (a.k.a. individual accountability) 561 typically requires a system ability to positively associate the 562 identity of a user with the time, method, and mode of the user's 563 access to the system. This ability supports detection and 564 subsequent investigation of security breaches. Individual persons 565 who are system users are held accountable for their actions after 566 being notified of the rules of behavior for using the system and 567 the penalties associated with violating those rules. 569 $ accounting 570 See: COMSEC accounting. 572 $ accounting legend code (ALC) 573 (O) /U.S. Government/ Numeric system used to indicate the minimum 574 accounting controls required for items of COMSEC material within 575 the CMCS. [C4009] (See: COMSEC accounting.) 577 $ accreditation 578 (N) An administrative action by which a designated authority 579 declares that an information system is approved to operate in a 580 particular security configuration with a prescribed set of 581 safeguards. [FP102, SP37] (See: certification.) 582 Tutorial: An accreditation is usually based on a technical 583 certification of the system's security mechanisms. To accredit a 584 system, the approving authority must determine that any residual 585 risk is an acceptable risk. Although the terms "certification" and 586 "accreditation" are used more in the U.S. DoD and other government 587 agencies than in commercial organizations, the concepts apply any 588 place where managers are required to deal with and accept 589 responsibility for security risks. For example, the American Bar 590 Association is developing accreditation criteria for CAs. 592 $ accreditation boundary 593 (O) Synonym for "security perimeter". [C4009] 595 $ accreditor 596 (N) A management official who has been designated to have the 597 formal authority to "accredit" an information system, i.e., to 598 authorize the operation of, and the processing of sensitive data 599 in, the system and to accept the residual risk associated with the 600 system. (See: accreditation, residual risk.) 602 $ ACES 603 (O) See: Access Certificate for Electronic Services. 605 $ ACL 606 (I) See: access control list. 608 $ acquirer 609 1. (O) /SET/ "The financial institution that establishes an 610 account with a merchant and processes payment card authorizations 611 and payments." [SET1] 613 2. (O) /SET/ "The institution (or its agent) that acquires from 614 the card acceptor the financial data relating to the transaction 615 and initiates that data into an interchange system." [SET2] 617 $ activation data 618 (N) Secret data, other than keys, that is required to access a 619 cryptographic module. (See: CIK. Compare: initialization value.) 621 $ active attack 622 (I) See: secondary definition under "attack". 624 $ active content 625 1a. (I) Executable software that is bound to a document or other 626 data file and that executes automatically when a user accesses the 627 file, without explicit initiation by the user. (Compare: mobile 628 code.) 630 Tutorial: Active content can be mobile code when its associated 631 file is transferred across a network. 633 1b. (O) "Electronic documents that can carry out or trigger 634 actions automatically on a computer platform without the 635 intervention of a user. [This technology enables] mobile code 636 associated with a document to execute as the document is 637 rendered." [SP28] 639 $ active user 640 (I) See: secondary definition under "attack". 642 $ active wiretapping 643 (I) A wiretapping attack that attempts to alter data being 644 communicated or otherwise affect data flow. (See: wiretapping. 645 Compare: active attack, passive wiretapping.) 647 $ add-on security 648 (N) The retrofitting of protection mechanisms, implemented by 649 hardware or software, in an information system after the system 650 has become operational. [FP039] (Compare: baked-in security.) 652 $ adequate security 653 (O) /U.S. DoD/ "Security commensurate with the risk and magnitude 654 of harm resulting from the loss, misuse, or unauthorized access to 655 or modification of information." (See: acceptable risk, residual 656 risk.) 658 $ administrative security 659 1. (I) Management procedures and constraints to prevent 660 unauthorized access to a system. (See: "third law" under 661 "Courtney's laws", operational security, procedural security, 662 security architecture. Compare: technical security.) 664 Examples: Clear delineation and separation of duties; 665 configuration control. 667 Usage: Administrative security is usually understood to consist of 668 methods and mechanisms that are implemented and executed primarily 669 by people, rather than by automated systems. 671 2. (O) "The management constraints, operational procedures, 672 accountability procedures, and supplemental controls established 673 to provide an acceptable level of protection for sensitive data." 674 [FP039] 676 $ administrator 677 1. (O) /Common Criteria/ A person that is responsible for 678 configuring, maintaining, and administering the TOE in a correct 679 manner for maximum security. (See: administrative security.) 681 2. (O) /ITSEC/ A person in contact with the TOE, who is 682 responsible for maintaining its operational capability. 684 $ Advanced Encryption Standard (AES) 685 (N) A U.S. Government standard [FP197] (the successor to DES) that 686 (a) specifies "the AES algorithm", which is a symmetric block 687 cipher that is based on Rijndael and uses key sizes of 128, 192, 688 or 256 bits to operate on a 128-bit block, and (b) states policy 689 for using that algorithm to protect unclassified, sensitive data. 691 Tutorial: Rijndael was designed to handle additional block sizes 692 and key lengths that were not adopted in the AES. Rijndael was 693 selected by NIST through a public competition that was held to 694 find a successor to the DEA; the other finalists were MARS, RC6, 695 Serpent, and Twofish. 697 $ adversary 698 1. (I) An entity that attacks a system. (Compare: cracker, 699 intruder, hacker.) 701 2. (I) An entity that is a threat to a system. 703 $ AES 704 (N) See: Advanced Encryption Standard. 706 $ Affirm 707 (O) A formal methodology, language, and integrated set of software 708 tools developed at the University of Southern California's 709 Information Sciences Institute for specifying, coding, and 710 verifying software to produce correct and reliable programs. 711 [Cheh] 713 $ aggregation 714 (I) A circumstance in which a collection of information items is 715 required to be classified at a higher security level than any of 716 the items is classified individually. (See: classification.) 718 $ AH 719 (I) See: Authentication Header 721 $ air gap 722 (I) An interface between two systems at which (a) they are not 723 connected physically and (b) any logical connection is not 724 automated (i.e., data is transferred through the interface only 725 manually, under human control). (See: sneaker net. Compare: 726 gateway.) 728 Example: Computer A and computer B are on opposite sides of a 729 room. To move data from A to B, a person carries a floppy disk 730 across the room. If A and B operate in different security domains, 731 than moving data across the air gap may involve an upgrade or 732 downgrade operation. 734 $ ALC 735 (O) See: accounting legend code. 737 $ algorithm 738 (I) A finite set of step-by-step instructions for a problem- 739 solving or computation procedure, especially one that can be 740 implemented by a computer. (See: cryptographic algorithm.) 742 $ alias 743 (I) A name that an entity uses in place of its real name, usually 744 for the purpose of either anonymity or masquerade. 746 $ Alice and Bob 747 (I) The parties that are most often called upon to illustrate the 748 operation of bipartite security protocols. These and other 749 dramatis personae are listed by Schneier [Schn]. 751 $ American National Standards Institute (ANSI) 752 (N) A private, not-for-profit association that administers U.S. 753 private sector voluntary standards. 755 Tutorial: ANSI has approximately 1,000 member organizations, 756 including equipment users, manufacturers, and others. These 757 include commercial firms, government agencies, and other 758 institutions and international entities. 760 ANSI is the sole U.S. representative to (a) ISO and (b) (via the 761 U.S. National Committee) the International Electrotechnical 762 Commission (IEC), which are the two major, non-treaty, 763 international standards organizations. 765 ANSI provides a forum for ANSI-accredited standards development 766 groups. Among those groups, the following are especially relevant 767 to Internet security: 768 - International Committee for Information Technology 769 Standardization (INCITS) (formerly X3): Primary U.S. focus of 770 standardization in information and communications technologies, 771 encompassing storage, processing, transfer, display, 772 management, organization, and retrieval of information. 773 Example: [A3092]. 774 - Accredited Standards Committee X9: Develops, establishes, 775 maintains, and promotes standards for the financial services 776 industry. Example: [A9009]. 777 - Alliance for Telecommunications Industry Solutions (ATIS): 778 Develops standards, specifications, guidelines, requirements, 779 technical reports, industry processes, and verification tests 780 for interoperability and reliability of telecommunications 781 networks, equipment, and software. Example: [A1523]. 783 $ American Standard Code for Information Interchange (ASCII) 784 (N) A scheme that encodes 128 specified characters -- the numbers 785 0-9, the letters a-z and A-Z, some basic punctuation symbols, some 786 control codes that originated with Teletype machines, and a blank 787 space -- into the 7-bit binary integers. Forms the basis of the 788 character set representations used in most computers and many 789 Internet standards. [FP001] (See: code.) 791 $ Anderson report 792 (O) A 1972 study of computer security that was written by James P. 793 Anderson for the U.S. Air Force [Ande]. 795 Tutorial: Anderson collaborated with a panel of experts to study 796 Air Force requirements for multilevel security. The study 797 recommended research and development that was urgently needed to 798 provide secure information processing for command and control 799 systems and support systems. The report introduced the reference 800 monitor concept and provided development impetus for computer and 801 network security technology. However, many of the security 802 problems that the 1972 report called "current" still plague 803 information systems today. 805 $ anomaly detection 806 (I) A intrusion detection method that searches for activity that 807 is different from the normal behavior of system entities and 808 system resources. (See: IDS. Compare: misuse detection.) 810 $ anonymity 811 (I) The condition of an identity being unknown or concealed. (See: 812 alias, anonymizer, anonymous credential, anonymous login, 813 identity, onion routing, persona certificate. Compare: privacy.) 815 Tutorial: An application may require security services that 816 maintain anonymity of users or other system entities, perhaps to 817 preserve their privacy or hide them from attack. To hide an 818 entity's real name, an alias may be used; for example, a financial 819 institution may assign account numbers. Parties to transactions 820 can thus remain relatively anonymous, but can also accept the 821 transactions as legitimate. Real names of the parties cannot be 822 easily determined by observers of the transactions, but an 823 authorized third party may be able to map an alias to a real name, 824 such as by presenting the institution with a court order. In other 825 applications, anonymous entities may be completely untraceable. 827 $ anonymizer 828 (I) A internetwork service, usually provided via a proxy server, 829 that provides anonymity and privacy for clients. That is, the 830 service enables a client to access servers (a) without allowing 831 anyone to gather information about which servers the client 832 accesses and (b) without allowing the accessed servers to gather 833 information about the client, such as its IP address. 835 $ anonymous credential 836 (D) /U.S. Government/ A credential that (a) can be used to 837 authenticate a person as having a specific attribute or being a 838 member of a specific group (e.g., military veterans or U.S. 839 citizens) but (b) does not reveal the individual identity of the 840 person that presents the credential. [M0404] (See: anonymity.) 841 Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts 842 in a potentially misleading way. For example, when the credential 843 is an X.509 certificate, the term could be misunderstood to mean 844 that the certificate was signed by a CA that has a persona 845 certificate. Instead, use "attribute certificate", "organizational 846 certificate", or "persona certificate" depending on what is meant, 847 and provide additional explanations as needed. 849 $ anonymous login 850 (I) An access control feature (actually, an access control 851 vulnerability) in many Internet hosts that enables users to gain 852 access to general-purpose or public services and resources of a 853 host (such as allowing any user to transfer data using FTP) 854 without having a pre-established, identity-specific account (i.e., 855 user name and password). (See: anonymity.) 857 Tutorial: This feature exposes a system to more threats than when 858 all the users are known, pre-registered entities that are 859 individually accountable for their actions. A user logs in using a 860 special, publicly known user name (e.g., "anonymous", "guest", or 861 "ftp"). To use the public login name, the user is not required to 862 know a secret password and may not be required to input anything 863 at all except the name. In other cases, to complete the normal 864 sequence of steps in a login protocol, the system may require the 865 user to input a matching, publicly known password (such as 866 "anonymous") or may ask the user for an e-mail address or some 867 other arbitrary character string. 869 $ ANSI 870 (N) See: American National Standards Institute. 872 $ anti-jam 873 (N) "Measures ensuring that transmitted information can be 874 received despite deliberate jamming attempts." [C4009] (See: 875 electronic security, frequency hopping, jam, spread spectrum.) 877 $ apex trust anchor 878 (N) The trust anchor that is superior to all other trust anchors 879 in a particular system or context. (See: trust anchor, top CA.) 881 $ API 882 (I) See: application programming interface. 884 $ APOP 885 (I) See: POP3 APOP. 887 $ Application Layer 888 See: Internet Protocol Suite, OSIRM. 890 $ application program 891 (I) A computer program that performs a specific function directly 892 for a user (as opposed to a program that is part of a computer 893 operating system and exists to perform functions in support of 894 application programs). 896 $ architecture 897 (I) See: security architecture, system architecture. 899 $ archive 900 1a. (I) /noun/ A collection of data that is stored for a 901 relatively long period of time for historical and other purposes, 902 such as to support audit service, availability service, or system 903 integrity service. (Compare: backup, repository.) 905 1b. (I) /verb/ To store data in such a way as to create an 906 archive. (Compare: back up.) 908 Tutorial: A digital signature may need to be verified many years 909 after the signing occurs. The CA -- the one that issued the 910 certificate containing the public key needed to verify that 911 signature -- may not stay in operation that long. So every CA 912 needs to provide for long-term storage of the information needed 913 to verify the signatures of those to whom it issues certificates. 915 $ ARPANET 916 (I) Advanced Research Projects Agency (ARPA) Network, a pioneer 917 packet-switched network that (a) was designed, implemented, 918 operated, and maintained by BBN from January 1969 until July 1975 919 under contract to the U.S. Government; (b) led to the development 920 of today's Internet; and (c) was decommissioned in June 1990. 921 [B4799, Hafn] 923 $ ASCII 924 (N) See: American Standard Code for Information Interchange. 926 $ ASN.1 927 (N) See: Abstract Syntax Notation One. 929 $ asset 930 (I) A system resource that is (a) required to be protected by an 931 information system's security policy, (b) intended to be protected 932 by a countermeasure, or (c) required for a system's mission. 934 $ association 935 (I) A cooperative relationship between system entities, usually 936 for the purpose of transferring information between them. (See: 937 security association.) 939 $ assurance 940 See: security assurance. 942 $ assurance level 943 (N) A rank on a hierarchical scale that judges the confidence 944 someone can have that a TOE adequately fulfills stated security 945 requirements. (See: assurance, certificate policy, EAL, TCSEC.) 947 Example: U.S. Government guidance [M0404] describes four assurance 948 levels for identity authentication, where each level "describes 949 the [Government] agency's degree of certainty that the user has 950 presented [a credential] that refers to [the user's] identity." In 951 that guidance, "assurance is defined as (a) "the degree of 952 confidence in the vetting process used to establish the identity 953 of the individual to whom the credential was issued" and (b) "the 954 degree of confidence that the individual who uses the credential 955 is the individual to whom the credential was issued." 957 The four levels are described as follows: 958 - Level 1: Little or no confidence in the asserted identity. 959 - Level 2: Some confidence in the asserted identity. 960 - Level 3: High confidence in the asserted identity. 961 - Level 4: Very high confidence in the asserted identity. 963 Standards for determining these levels are provided in a NIST 964 publication [SP12]. However, as noted there, an assurance level is 965 "a degree of confidence, not a true measure of how secure the 966 system actually is. This distinction is necessary because it is 967 extremely difficult -- and in many cases virtually impossible -- 968 to know exactly how secure a system is." 970 $ asymmetric cryptography 971 (I) A modern branch of cryptography (popularly known as "public- 972 key cryptography") in which the algorithms use a pair of keys (a 973 public key and a private key) and use a different component of the 974 pair for each of two counterpart cryptographic operations (e.g., 975 encryption and decryption, or signature creation and signature 976 verification). (See: key pair, symmetric cryptography.) 978 Tutorial: Asymmetric algorithms have key management advantages 979 over equivalently strong symmetric ones. First, one key of the 980 pair need not be known by anyone but its owner; so it can more 981 easily be kept secret. Second, although the other key is shared by 982 all entities that use the algorithm, that key need not be kept 983 secret from other, non-using entities; thus, the key-distribution 984 part of key management can be done more easily. 986 Asymmetric cryptography can be used to create algorithms for 987 encryption, digital signature, and key agreement: 988 - In an asymmetric encryption algorithm (e.g., "RSA"), when Alice 989 wants to ensure confidentiality for data she sends to Bob, she 990 encrypts the data with a public key provided by Bob. Only Bob 991 has the matching private key that is needed to decrypt the 992 data. (Compare: seal.) 993 - In an asymmetric digital signature algorithm (e.g., "DSA"), 994 when Alice wants to ensure data integrity or provide 995 authentication for data she sends to Bob, she uses her private 996 key to sign the data (i.e., create a digital signature based on 997 the data). To verify the signature, Bob uses the matching 998 public key that Alice has provided. 999 - In an asymmetric key-agreement algorithm (e.g., "Diffie- 1000 Hellman-Merkle"), Alice and Bob each send their own public key 1001 to the other party. Then each uses their own private key and 1002 the other's public key to compute the new key value. 1004 $ asymmetric key 1005 (I) A cryptographic key that is used in an asymmetric 1006 cryptographic algorithm. (See: asymmetric cryptography, private 1007 key, public key.) 1009 $ ATIS 1010 (N) See: "Alliance for Telecommunications Industry Solutions" 1011 under "ANSI". 1013 $ attack 1014 1. (I) An intentional act by which an entity attempts to evade 1015 security services and violate the security policy of a system. 1016 That is, an actual assault on system security that derives from an 1017 intelligent threat. (See: penetration, violation, vulnerability.) 1019 2. (I) A method or technique used in an assault (e.g., 1020 masquerade). (See: blind attack, distributed attack.) 1022 Tutorial: Attacks can be characterized according to intent: 1023 - An "active attack" attempts to alter system resources or affect 1024 their operation. 1025 - A "passive attack" attempts to learn or make use of information 1026 from a system but does not affect system resources of that 1027 system. (See: wiretapping.) 1029 The object of a passive attack might be to obtain data that is 1030 needed for an off-line attack. 1031 - An "off-line attack" is one in which the attacker obtains data 1032 from the target system and then analyzes the data on a 1033 different system of the attacker's own choosing, possibly in 1034 preparation for a second stage of attack on the target. 1036 Attacks can be characterized according to point of initiation: 1037 - An "inside attack" is one that is initiated by an entity inside 1038 the security perimeter (an "insider"), i.e., an entity that is 1039 authorized to access system resources but uses them in a way 1040 not approved by the party that granted the authorization. 1041 - An "outside attack" is initiated from outside the security 1042 perimeter, by an unauthorized or illegitimate user of the 1043 system (an "outsider"). In the Internet, potential outside 1044 attackers range from amateur pranksters to organized criminals, 1045 international terrorists, and hostile governments. 1046 Attacks can be characterized according to method of delivery: 1047 - In a "direct attack", the attacker addresses attacking packets 1048 to the intended victim(s). 1049 - In an "indirect attack", the attacker addresses packets to a 1050 third party, and the packets either have the address(es) of the 1051 intended victim(s) as their source address(es) or indicate the 1052 intended victim(s) in some other way. The third party responds 1053 by sending one or more attacking packets to the intended 1054 victims. The attacker can use third parties as attack 1055 amplifiers by providing a broadcast address as the victim 1056 address (e.g., "smurf attack"). (See: reflector attack. 1057 Compare: reflection attack, replay attack.) 1059 The term "attack" relates to some other basic security terms as 1060 shown in the following diagram: 1062 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 1063 | An Attack: | |Counter- | | A System Resource: | 1064 | i.e., A Threat Action | | measure | | Target of the Attack | 1065 | +----------+ | | | | +-----------------+ | 1066 | | Attacker |<==================||<========= | | 1067 | | i.e., | Passive | | | | | Vulnerability | | 1068 | | A Threat |<=================>||<========> | | 1069 | | Agent | or Active | | | | +-------|||-------+ | 1070 | +----------+ Attack | | | | VVV | 1071 | | | | | Threat Consequences | 1072 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 1074 $ attack potential 1075 (I) The perceived likelihood of success should an attack be 1076 launched, expressed in terms of the attacker's ability (i.e., 1077 expertise and resources) and motivation. (Compare: threat, risk.) 1079 $ attack sensing, warning, and response 1080 (I) A set of security services that cooperate with audit service 1081 to detect and react to indications of threat actions, including 1082 both inside and outside attacks. (See: indicator.) 1084 $ attack tree 1085 (I) A branching, hierarchical data structure that represents a set 1086 of potential approaches to achieving an event in which system 1087 security is penetrated or compromised in a specified way. [Moor] 1089 Tutorial: Attack trees are special cases of fault trees. The 1090 security incident that is the goal of the attack is represented as 1091 the root node of the tree, and the ways that an attacker could 1092 reach that goal are iteratively and incrementally represented as 1093 branches and subnodes of the tree. Each subnode defines a subgoal, 1094 and each subgoal may have its own set of further subgoals, etc. 1095 The final nodes on the paths outward from the root, i.e., the leaf 1096 nodes, represent different ways to initiate an attack. Each node 1097 other than a leaf is either an AND-node or an OR-node. To achieve 1098 the goal represented by an AND-node, the subgoals represented by 1099 all of that node's subnodes must be achieved; and for an OR-node, 1100 at least one of the subgoals must be achieved. Branches can be 1101 labeled with values representing difficulty, cost, or other attack 1102 attributes, so that alternative attacks can be compared. 1104 $ attribute 1105 1. (N) Information of a particular type concerning an identifiable 1106 system entity or object. An "attribute type" is the component of 1107 an attribute that indicates the class of information given by the 1108 attribute; and an "attribute value" is a particular instance of 1109 the class of information indicated by an attribute type. (See: 1110 attribute certificate.) 1112 $ attribute authority (AA) 1113 1. (N) A CA that issues attribute certificates. 1115 2. (O) "An authority [that] assigns privileges by issuing 1116 attribute certificates." [X509] 1118 Deprecated Usage: The abbreviation "AA" SHOULD NOT be used in an 1119 ISD unless it is first defined in the ISD. 1121 $ attribute certificate 1122 1. (I) A digital certificate that binds a set of descriptive data 1123 items, other than a public key, either directly to a subject name 1124 or to the identifier of another certificate that is a public-key 1125 certificate. (See: capability token.) 1127 2. (O) "A data structure, digitally signed by an [a]ttribute 1128 [a]uthority, that binds some attribute values with identification 1129 information about its holder." [X509] 1131 Tutorial: A public-key certificate binds a subject name to a 1132 public key value, along with information needed to perform certain 1133 cryptographic functions using that key. Other attributes of a 1134 subject, such as a security clearance, may be certified in a 1135 separate kind of digital certificate, called an attribute 1136 certificate. A subject may have multiple attribute certificates 1137 associated with its name or with each of its public-key 1138 certificates. 1140 An attribute certificate might be issued to a subject in the 1141 following situations: 1142 - Different lifetimes: When the lifetime of an attribute binding 1143 is shorter than that of the related public-key certificate, or 1144 when it is desirable not to need to revoke a subject's public 1145 key just to revoke an attribute. 1146 - Different authorities: When the authority responsible for the 1147 attributes is different than the one that issues the public-key 1148 certificate for the subject. (There is no requirement that an 1149 attribute certificate be issued by the same CA that issued the 1150 associated public-key certificate.) 1152 $ audit 1153 See: security audit. 1155 $ audit log 1156 (I) Synonym for "security audit trail". 1158 $ audit service 1159 (I) A security service that records information needed to 1160 establish accountability for system events and for the actions of 1161 system entities that cause them. (See: security audit.) 1163 $ audit trail 1164 (I) See: security audit trail. 1166 $ AUTH 1167 (I) See: POP3 AUTH. 1169 $ authenticate 1170 (I) Verify (i.e., establish the truth of) an attribute value 1171 claimed by or for a system entity or system resource. (See: 1172 authentication, validate vs. verify, "relationship between data 1173 integrity service and authentication services" under "data 1174 integrity service".) 1176 Deprecated Usage: In general English usage, this term is used with 1177 the meaning "to prove genuine" (e.g., an art expert authenticates 1178 a Michelangelo painting); but ISDs should restrict usage as 1179 follows: 1180 - ISDs SHOULD NOT use this term to refer to proving or checking 1181 that data has not been changed, destroyed or lost in an 1182 unauthorized or accidental manner. Instead use "verify". 1183 - ISDs SHOULD NOT use this term to refer to proving the truth or 1184 accuracy of a fact or value such as a digital signature. 1185 Instead, use "verify". 1186 - ISDs SHOULD NOT use this term to refer to establishing the 1187 soundness or correctness of a construct, such as a digital 1188 certificate. Instead, use "validate". 1190 $ authentication 1191 (I) The process of verifying a claim that a system entity or 1192 system resource has a certain attribute value. (See: attribute, 1193 authenticate, authentication exchange, authentication information, 1194 credential, data origin authentication, peer entity 1195 authentication, "relationship between data integrity service and 1196 authentication services" under "data integrity service", simple 1197 authentication, strong authentication, verification, X.509.) 1199 Tutorial: Security services frequently depend on authentication of 1200 the identity of users, but authentication may involve any type of 1201 attribute that is recognized by a system. A claim may be made by a 1202 subject about itself (e.g., at login, a user typically asserts its 1203 identity) or a claim may be made on behalf of a subject or object 1204 by some other system entity (e.g., a user may claim that a data 1205 object originates from a specific source, or that a data object is 1206 classified at a specific security level). 1208 An authentication process consists of two basic steps: 1209 - Identification step: Presenting the claimed attribute value 1210 (e.g., a user identifier) to the authentication subsystem. 1211 - Verification step: Presenting or generating authentication 1212 information (e.g., a value signed with a private key) that acts 1213 as evidence to prove the binding between the attribute and that 1214 for which it is claimed. (See: verification.) 1216 $ authentication code 1217 (D) Synonym for a checksum based on cryptography. (Compare: Data 1218 Authentication Code, Message Authentication Code.) 1220 Deprecated Term: ISDs SHOULD NOT use this uncapitalized term as a 1221 synonym for any kind of checksum, regardless of whether or not the 1222 checksum is cryptographic. Instead, use "checksum", "Data 1223 Authentication Code", "error detection code", "hash", "keyed 1224 hash", "Message Authentication Code", "protected checksum", or 1225 some other recommended term, depending on what is meant. 1227 The term mixes concepts in a potentially misleading way. The word 1228 "authentication" is misleading because the checksum may be used to 1229 perform a data integrity function rather than a data origin 1230 authentication function. 1232 $ authentication exchange 1233 1. (I) A mechanism to verify the identity of an entity by means of 1234 information exchange. 1236 2. (O) "A mechanism intended to ensure the identity of an entity 1237 by means of information exchange." [I7498-2] 1239 $ Authentication Header (AH) 1240 (I) An Internet protocol [R2402] designed to provide 1241 connectionless data integrity service and connectionless data 1242 origin authentication service for IP datagrams, and (optionally) 1243 to provide partial sequence integrity and protection against 1244 replay attacks. (See: IPsec. Compare: ESP.) 1246 Tutorial: Replay protection may be selected by the receiver when a 1247 security association is established. AH authenticates the upper- 1248 layer PDU that is carried as an IP SDU, and also authenticates as 1249 much of the IP PCI (i.e., the IP header) as possible. However, 1250 some IP header fields may change in transit, and the value of 1251 these fields, when the packet arrives at the receiver, may not be 1252 predictable by the sender. Thus, the values of such fields cannot 1253 be protected end-to-end by AH; protection of the IP header by AH 1254 is only partial when such fields are present. 1256 AH may be used alone, or in combination with the ESP, or in a 1257 nested fashion with tunneling. Security services can be provided 1258 between a pair of communicating hosts, between a pair of 1259 communicating security gateways, or between a host and a gateway. 1260 ESP can provide nearly the same security services as AH, and ESP 1261 can also provide data confidentiality service. The main difference 1262 between authentication services provided by ESP and AH is the 1263 extent of the coverage; ESP does not protect IP header fields 1264 unless they are encapsulated by AH. 1266 $ authentication information 1267 (I) Information used to verify an identity claimed by or for an 1268 entity. (See: authentication, credential, user. Compare: 1269 identification information.) 1271 Tutorial: Authentication information may exist as, or be derived 1272 from, one of the following: (a) Something the entity knows (see: 1273 password); (b) something the entity possesses (see: token); (c) 1274 something the entity is (see: biometric authentication). 1276 $ authentication service 1277 (I) A security service that verifies an identity claimed by or for 1278 an entity. (See: authentication.) 1280 Tutorial: In a network, there are two general forms of 1281 authentication service: data origin authentication service and 1282 peer entity authentication service. 1284 $ authenticity 1285 (I) The property of being genuine and able to be verified and be 1286 trusted. (See: authenticate, authentication, validate vs. verify.) 1288 $ authority 1289 (D) "An entity, responsible for the issuance of certificates." 1290 [X509] 1292 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 1293 attribute authority, certification authority, registration 1294 authority, or similar terms; the shortened form may cause 1295 confusion. Instead, use the full term at the first instance of 1296 usage and then, if it is necessary to shorten text, use AA, CA, 1297 RA, and other abbreviations defined in this Glossary. 1299 $ authority certificate 1300 (D) "A certificate issued to an authority (e.g. either to a 1301 certification authority or to an attribute authority)." [X509] 1302 (See: authority.) 1304 Deprecated Term: ISDs SHOULD NOT use this term because it is 1305 ambiguous. Instead, use the full term "certification authority 1306 certificate", "attribute authority certificate", "registration 1307 authority certificate", etc. at the first instance of usage and 1308 then, if it is necessary to shorten text, use AA, CA, RA, and 1309 other abbreviations defined in this Glossary. 1311 $ Authority Information Access extension 1312 (I) The private extension defined by PKIX for X.509 certificates 1313 to indicate "how to access CA information and services for the 1314 issuer of the certificate in which the extension appears. 1315 Information and services may include on-line validation services 1316 and CA policy data." [R3280] (See: private extension.) 1318 $ authorization 1319 1a. (I) An approval that is granted to a system entity to access a 1320 system resource. (Compare: permission, privilege.) 1322 Usage: Some synonyms are "permission" and "privilege". Specific 1323 terms are preferred in certain contexts: 1324 - /PKI/ "Authorization" SHOULD be used, to align with 1325 "certification authority" in the standard [X509]. 1326 - /role-based access control/ "Permission" SHOULD be used, to 1327 align with the standard [ANSI]. 1328 - /computer operating systems/ "Privilege" SHOULD be used, to 1329 align with the literature. (See: privileged process, privileged 1330 user.) 1332 Tutorial: The semantics and granularity of authorizations depend 1333 on the application and implementation (see: "first law" under 1334 "Courtney's laws"). An authorization may specify a particular 1335 access mode -- such as read, write, or execute -- for one or more 1336 system resources. 1338 1b. (I) A process for granting approval to a system entity to 1339 access a system resource. 1341 2. (O) /SET/ "The process by which a properly appointed person or 1342 persons grants permission to perform some action on behalf of an 1343 organization. This process assesses transaction risk, confirms 1344 that a given transaction does not raise the account holder's debt 1345 above the account's credit limit, and reserves the specified 1346 amount of credit. (When a merchant obtains authorization, payment 1347 for the authorized amount is guaranteed -- provided, of course, 1348 that the merchant followed the rules associated with the 1349 authorization process.)" [SET2] 1351 $ authorization credential 1352 (I) See: /access control/ under "credential". 1354 $ authorize 1355 (I) Grant an authorization to a system entity. 1357 $ authorized user 1358 (I) /access control/ A system entity that accesses a system 1359 resource for which the entity has received an authorization. 1361 (Compare: insider, outsider, unauthorized user.) 1363 Deprecated Usage: ISDs that use this term SHOULD state a 1364 definition for it because the term is used in many ways and could 1365 easily be misunderstood. 1367 $ automated information system 1368 See: information system. 1370 $ availability 1371 1. (I) The property of a system or a system resource being 1372 accessible, or usable or operational upon demand, by an authorized 1373 system entity, according to performance specifications for the 1374 system; i.e., a system is available if it provides services 1375 according to the system design whenever users request them. (See: 1376 critical, denial of service. Compare: precedence, reliability, 1377 survivability.) 1379 2. (O) "The property of being accessible and usable upon demand by 1380 an authorized entity." [I7498-2] 1382 3. (D) "Timely, reliable access to data and information services 1383 for authorized users." [C4009] 1385 Deprecated Definition: ISDs SHOULD NOT use the term with 1386 definition 3; the definition mixes "availability" with 1387 "reliability", which is a different property. (See: reliability.) 1389 Tutorial: Availability requirements can be specified by 1390 quantitative metrics, but sometimes are stated qualitatively, such 1391 as in the following: 1392 - "Flexible tolerance for delay" may mean that brief system 1393 outages do not endanger mission accomplishment, but extended 1394 outages may endanger the mission. 1395 - "Minimum tolerance for delay" may mean that mission 1396 accomplishment requires the system to provide requested 1397 services in a short time. 1399 $ availability service 1400 (I) A security service that protects a system to ensure its 1401 availability. 1403 Tutorial: This service addresses the security concerns raised by 1404 denial-of-service attacks. It depends on proper management and 1405 control of system resources, and thus depends on access control 1406 service and other security services. 1408 $ avoidance 1409 (I) See: secondary definition under "security". 1411 $ B1, B2, or B3 computer system 1412 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 1413 Evaluation Criteria". 1415 $ back door 1416 1. (I) /COMPUSEC/ A computer system feature -- which may be (a) an 1417 unintentional flaw, (b) a mechanism deliberately installed by the 1418 system's creator, or (c) a mechanism surreptitiously installed by 1419 an intruder -- that provides access to a system resource by other 1420 than the usual procedure and usually is hidden or otherwise not 1421 well-known. (See: maintenance hook. Compare: Trojan Horse.) 1423 Example: A way to access a computer other than through a normal 1424 login. Such an access path is not necessarily designed with 1425 malicious intent; operating systems sometimes are shipped by the 1426 manufacturer with hidden accounts intended for use by field 1427 service technicians or the vendor's maintenance programmers. 1429 2. (I) /cryptography/ A feature of a cryptographic system that 1430 makes it easily possible to break or circumvent the protection 1431 that the system is designed to provided. 1433 Example: A feature that makes it possible to decrypt cipher text 1434 much more quickly than by brute force cryptanalysis, without 1435 having prior knowledge of the decryption key. 1437 $ back up 1438 (I) /verb/ Create a reserve copy of data or, more generally, 1439 provide alternate means to perform system functions despite loss 1440 of system resources. (See: contingency plan. Compare: archive.) 1442 $ backup 1443 (I) /noun or adjective/ Refers to alternate means of performing 1444 system functions despite loss of system resources. (See: 1445 contingency plan). 1447 Example: A reserve copy of data, preferably one that is stored 1448 separately from the original, for use if the original becomes lost 1449 or damaged. (Compare: archive.) 1451 $ bagbiter 1452 (D) /slang/ "An entity, such as a program or a computer, that 1453 fails to work or that works in a remarkably clumsy manner. A 1454 person who has caused some trouble, inadvertently or otherwise, 1455 typically by failing to program the computer properly." [NCSSG] 1456 (See: flaw.) 1458 Deprecated Term: It is likely that other cultures use different 1459 metaphors for these concepts. Therefore, to avoid international 1460 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 1461 Usage under "Green Book.") 1463 $ baggage 1464 (O) /SET/ An "opaque encrypted tuple, which is included in a SET 1465 message but appended as external data to the PKCS encapsulated 1466 data. This avoids superencryption of the previously encrypted 1467 tuple, but guarantees linkage with the PKCS portion of the 1468 message." [SET2] 1470 Deprecated Usage: ISDs SHOULD NOT use this term to describe a data 1471 element, except in the form "SET(trademark) baggage" with the 1472 meaning given above. 1474 $ baked-in security 1475 (D) The inclusion of security mechanisms in an information system 1476 beginning at an early point in the system's life cycle, i.e., 1477 during the design phase, or at least early in the implementation 1478 phase. (Compare: add-on security.) 1480 Deprecated Term: It is likely that other cultures use different 1481 metaphors for this concept. Therefore, to avoid international 1482 misunderstanding, ISDs SHOULD NOT use this term (unless they also 1483 provide a definition like this one). (See: Deprecated Usage under 1484 "Green Book".) 1486 $ bandwidth 1487 (I) The total width of the frequency band that is available to or 1488 used by a communication channel; usually expressed in Hertz (Hz). 1489 (RFC 3753) (Compare: channel capacity.) 1491 $ bank identification number (BIN) 1492 1. (O) The digits of a credit card number that identify the 1493 issuing bank. (See: primary account number.) 1495 2. (O) /SET/ The first six digits of a primary account number. 1497 $ Basic Encoding Rules (BER) 1498 (I) A standard for representing ASN.1 data types as strings of 1499 octets. [X690] (See: Distinguished Encoding Rules.) 1501 Deprecated Usage: Sometimes incorrectly treated as part of ASN.1. 1502 However, ASN.1 properly refers only to a syntax description 1503 language, and not to the encoding rules for the language. 1505 $ Basic Security Option 1506 (I) See: secondary definition under "IPSO". 1508 $ bastion host 1509 (I) A strongly protected computer that is in a network protected 1510 by a firewall (or is part of a firewall) and is the only host (or 1511 one of only a few) in the network that can be directly accessed 1512 from networks on the other side of the firewall. (See: firewall.) 1514 Tutorial: Filtering routers in a firewall typically restrict 1515 traffic from the outside network to reaching just one host, the 1516 bastion host, which usually is part of the firewall. Since only 1517 this one host can be directly attacked, only this one host needs 1518 to be very strongly protected, so security can be maintained more 1519 easily and less expensively. However, to allow legitimate internal 1520 and external users to access application resources through the 1521 firewall, higher layer protocols and services need to be relayed 1522 and forwarded by the bastion host. Some services (e.g., DNS and 1523 SMTP) have forwarding built in; other services (e.g., TELNET and 1524 FTP) require a proxy server on the bastion host. 1526 $ BBN Technologies 1527 (O) The research-and-development company (originally called Bolt 1528 Baranek and Newman, Inc.) that built the ARPANET. 1530 $ BCA 1531 (O) See: brand certification authority. 1533 $ BCR 1534 (O) See: BLACK/Crypto/RED. 1536 $ BCI 1537 (O) See: brand CRL identifier. 1539 $ Bell-LaPadula model 1540 (N) A formal, mathematical, state-transition model of 1541 confidentiality policy for multilevel-secure computer systems 1542 [Bell]. (Compare: Biba model, Brewer-Nash model.) 1544 Tutorial: The model, devised by David Bell and Leonard LaPadula at 1545 The MITRE Corporation in 1973, characterizes computer system 1546 elements as subjects and objects. To determine whether or not a 1547 subject is authorized for a particular access mode on an object, 1548 the clearance of the subject is compared to the classification of 1549 the object. The model defines the notion of a "secure state", in 1550 which the only permitted access modes of subjects to objects are 1551 in accordance with a specified security policy. It is proven that 1552 each state transition preserves security by moving from secure 1553 state to secure state, thereby proving that the system is secure. 1554 In this model, a multilevel-secure system satisfies several rules, 1555 including the "confinement property" (a.k.a. the "*-property"), 1556 the "simple security property", and the "tranquility property". 1558 $ benign 1559 1. (N) /COMSEC/ "Condition of cryptographic data [such] that [it] 1560 cannot be compromised by human access [to the data]." [C4009] 1562 2. (O) /COMPUSEC/ See: secondary definition under "trust". 1564 $ benign fill 1565 (N) Process by which keying material is generated, distributed, 1566 and placed into an ECU without exposure to any human or other 1567 system entity, except the cryptographic module that consumes and 1568 uses the material. (See: benign.) 1570 $ BER 1571 (I) See: Basic Encoding Rules. 1573 $ beyond A1 1574 1. (O) /formal/ A level of security assurance that is beyond the 1575 highest level (level A1) of criteria specified by the TCSEC. (See: 1576 Tutorial under "Trusted Computer System Evaluation Criteria".) 1578 2. (O) /informal/ A level of trust so high that it is beyond 1579 state-of-the-art technology; i.e., it cannot be provided or 1580 verified by currently available assurance methods, and especially 1581 not by currently available formal methods. 1583 $ Biba integrity 1584 (N) Synonym for "source integrity". 1586 $ Biba model 1587 (N) A formal, mathematical, state-transition model of integrity 1588 policy for multilevel-secure computer systems [Biba]. (See: source 1589 integrity. Compare: Bell-LaPadula model.) 1591 Tutorial: This model for integrity control is analogous to the 1592 Bell-LaPadula model for confidentiality control. Each subject and 1593 object is assigned an integrity level and, to determine whether or 1594 not a subject is authorized for a particular access mode on an 1595 object, the integrity level of the subject is compared to that of 1596 the object. The model prohibits the changing of information in an 1597 object by a subject with a lesser or incomparable level. The rules 1598 of the Biba model are duals of the corresponding rules in the 1599 Bell-LaPadula model. 1601 $ billet 1602 (N) A personnel position or assignment that can be filled by one 1603 system entity at a time. [JCSP1] (Compare: principal, role, user.) 1605 Tutorial: In an organization, a "billet" is a populational 1606 position, of which there is exactly one instance; but a "role" is 1607 functional position, of which there can be multiple instances. 1608 System entities are in one-to-one relationships with their 1609 billets, but may be in many-to-one and one-to-many relationships 1610 with their roles. 1612 $ BIN 1613 (O) See: bank identification number. 1615 $ bind 1616 (I) To inseparably associate by applying some security mechanism. 1618 Example: A CA creates a public-key certificate by using a digital 1619 signature to bind together (a) a subject name, (b) a public key, 1620 and usually (c) some additional data items (e.g., "X.509 public- 1621 key certificate"). 1623 $ biometric authentication 1624 (I) A method of generating authentication information for a person 1625 by digitizing measurements of a physical or behavioral 1626 characteristic, such as a fingerprint, hand shape, retina pattern, 1627 voiceprint, handwriting style, or face. 1629 $ birthday attack 1630 (I) A class of attacks against cryptographic functions, including 1631 both encryption functions and hash functions. The attacks take 1632 advantage of a statistical property: Given a cryptographic 1633 function having an N-bit output, the probability is greater than 1634 1/2 that for 2**(N/2) randomly chosen inputs, the function will 1635 produce at least two outputs that are identical. (See: Tutorial 1636 under "hash function".) 1638 Derivation: From the somewhat surprising fact (often called the 1639 "birthday paradox") that although there are 365 days in a year, 1640 the probability is greater than 1/2 that two of more people share 1641 the same birthday in any randomly chosen group of 23 people. 1643 Birthday attacks enable an adversary to find two inputs for which 1644 a cryptographic function produces the same cipher text (or find 1645 two inputs for which a hash functions produces the same hash 1646 result) much faster than a brute force attack can; and a clever 1647 adversary can use such a capability to create considerable 1648 mischief. However, no birthday attack can enable an adversary to 1649 decrypt a given cipher text (or find a hash input that results in 1650 a given hash result) any faster than a brute force attack can. 1652 $ bit 1653 (I) A contraction of the term "binary digit"; the smallest unit of 1654 information storage, which has two possible states or values. The 1655 values usually are represented by the symbols "0" (zero) and "1" 1656 (one). (See: block, byte, nibble, word.) 1658 $ bit string 1659 (I) A sequence of bits, each of which is either "0" or "1". 1661 $ BLACK 1662 1. (N) Designation for data that consists only of cipher text, and 1663 for information system equipment items or facilities that handle 1664 only cipher text. Example: "BLACK key".(See: color change, 1665 RED/BLACK separation. Compare: RED.) 1667 2. (O) /U.S. Government/ "Designation applied to information 1668 systems, and to associated areas, circuits, components, and 1669 equipment, in which national security information is encrypted or 1670 is not processed." [C4009] 1672 3. (D) Any data that can be disclosed without harm. 1674 Deprecated Definition: ISDs SHOULD NOT use the term with 1675 definition 3 because the definition is ambiguous with regard to 1676 whether the data is protected or not. 1678 $ BLACK/Crypto/RED (BCR) 1679 (N) An experimental, end-to-end, network packet encryption system 1680 developed in a working prototype form by BBN and the Collins Radio 1681 division of Rockwell Corporation in the 1975-1980 time frame for 1682 the U.S. DoD. BCR was the first network security system to support 1683 TCP/IP traffic, and it incorporated the first DES chips that were 1684 validated by the U.S. National Bureau of Standards (now called 1685 NIST). BCR also was the first to use a KDC and an ACC to manage 1686 connections. 1688 $ BLACK key 1689 (N) A key that is protected with a key-encrypting key and that 1690 must be decrypted before use. (See: BLACK. Compare: RED key.) 1692 $ BLACKER 1693 (O) An end-to-end encryption system for computer data networks 1694 that was developed by the U.S. DoD in the 1980s to provide host- 1695 to-host data confidentiality service for datagrams at OSIRM Layer 1696 3. [Weis] (Compare: CANEWARE, IPsec.) 1698 Tutorial: Each user host connects to its own bump-in-the-wire 1699 encryption device called a BLACKER Front End (BFE, TSEC/KI-111), 1700 through which the host connects to the subnetwork. The system also 1701 includes two types of centralized devices: one or more KDCs 1702 connect to the subnetwork and communicate with assigned sets of 1703 BFEs, and one or more ACCs connect to the subnetwork and 1704 communicate with assigned KDCs. BLACKER uses only symmetric 1705 encryption. A KDC distributes session keys to BFE pairs as 1706 authorized by an ACC. Each ACC maintains a database for a set of 1707 BFEs, and the database determines which pairs from that set (i.e., 1708 which pairs of user hosts behind the BFEs) are authorized to 1709 communicate and at what security levels. 1711 The BLACKER system is MLS in three ways: (a) The BFEs form a 1712 security perimeter around a subnetwork, separating user hosts from 1713 the subnetwork, so that the subnetwork can operate at a different 1714 security level (possibly a lower, less expensive level) than the 1715 hosts. (b) The BLACKER components are trusted to separate 1716 datagrams of different security levels, so that each datagram of a 1717 given security level can be received only by a host that is 1718 authorized for that security level; and thus BLACKER can separate 1719 host communities that operate at different security levels. (c) 1720 The host side of a BFE is itself MLS and can recognize a security 1721 label on each packet, so that an MLS user host can be authorized 1722 to successively transmit datagrams that are labeled with different 1723 security levels. 1725 $ blind attack 1726 (I) A type of network-based attack method that does not require 1727 the attacking entity to receive data traffic from the attacked 1728 entity; i.e., the attacker does not need to "see" data packets 1729 sent by the victim. Example: SYN flood. 1731 Tutorial: If an attack method is blind, the attacker's packets can 1732 carry (a) a false IP source address (making it difficult for the 1733 victim to find the attacker) and (b) a different address on every 1734 packet (making it difficult for the victim to block the attack). 1735 If the attacker needs to receive traffic from the victim, the 1736 attacker must either (c) reveal its own IP address to the victim 1737 (which enables the victim to find the attacker or block the attack 1738 by filtering) or (d) provide a false address and also subvert 1739 network routing mechanisms to divert the returning packets to the 1740 attacker (which makes the attack more complex, more difficult, or 1741 more expensive). [R3552] 1743 $ block 1744 (I) A bit string or bit vector of finite length. (See: bit, block 1745 cipher. Compare: byte, word.) 1747 Usage: An "N-bit block" contains N bits, which usually are 1748 numbered from left to right as 1, 2, 3, ..., N. 1750 $ block cipher 1751 (I) An encryption algorithm that breaks plain text into fixed-size 1752 segments and uses the same key to transform each plaintext segment 1753 into a fixed-size segment of cipher text. Examples: AES, Blowfish, 1754 DEA, IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream 1755 cipher.) 1757 Tutorial: A block cipher can be adapted to have a different 1758 external interface, such as that of a stream cipher, by using a 1759 mode of cryptographic operation to package the basic algorithm. 1760 (See: CBC, CCM, CFB, CMAC, CTR, DEA, ECB, OFB.) 1762 $ Blowfish 1763 (N) A symmetric block cipher with variable-length key (32 to 448 1764 bits) designed in 1993 by Bruce Schneier as an unpatented, 1765 license-free, royalty-free replacement for DES or IDEA. [Schn] 1766 (See: Twofish.) 1768 $ brain-damaged 1769 (D) /slang/ "Obviously wrong: extremely poorly designed. Calling 1770 something brain-damaged is very extreme. The word implies that the 1771 thing is completely unusable, and that its failure to work is due 1772 to poor design, not accident." [NCSSG] (See: flaw.) 1774 Deprecated Term: It is likely that other cultures use different 1775 metaphors for this concept. Therefore, to avoid international 1776 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 1777 Usage under "Green Book.") 1779 $ brand 1780 1. (I) A distinctive mark or name that identifies a product or 1781 business entity. 1783 2. (O) /SET/ The name of a payment card. (See: BCA.) 1785 Tutorial: Financial institutions and other companies have founded 1786 payment card brands, protect and advertise the brands, establish 1787 and enforce rules for use and acceptance of their payment cards, 1788 and provide networks to interconnect the financial institutions. 1789 These brands combine the roles of issuer and acquirer in 1790 interactions with cardholders and merchants. [SET1] 1792 $ brand certification authority (BCA) 1793 (O) /SET/ A CA owned by a payment card brand, such as MasterCard, 1794 Visa, or American Express. [SET2] (See: certification hierarchy, 1795 SET.) 1797 $ brand CRL identifier (BCI) 1798 (O) /SET/ A digitally signed list, issued by a BCA, of the names 1799 of CAs for which CRLs need to be processed when verifying 1800 signatures in SET messages. [SET2] 1802 $ break 1803 (I) /cryptography/ To successfully perform cryptanalysis and thus 1804 succeed in decrypting data or performing some other cryptographic 1805 function, without initially having knowledge of the key that the 1806 function requires. (See: penetrate, strength, work factor.) 1808 Usage: This term applies to encrypted data or, more generally, to 1809 a cryptographic algorithm or cryptographic system. Also, while the 1810 most common use is to refer to completely breaking an algorithm, 1811 the term is also used when a method is found that substantially 1812 reduces the work factor. 1814 $ Brewer-Nash model 1815 (N) A security model [BN89] to enforce the Chinese wall policy. 1816 (Compare: Bell-LaPadula model, Clark-Wilson model.) 1818 Tutorial: All proprietary information in the set of commercial 1819 firms F(1), F(2), ..., F(N) is categorized into mutually exclusive 1820 conflict-of-interest classes I(1), I(2), ..., I(M) that apply 1821 across all firms. Each firm belongs to exactly one class. The 1822 Brewer-Nash model has the following mandatory rules: 1823 - Brewer-Nash Read Rule: Subject S can read information object O 1824 from firm F(i) only if either (a) O is from the same firm as 1825 some object previously read by S *or* (b) O belongs to a class 1826 I(i) from which S has not previously read any object. (See: 1827 object, subject.) 1828 - Brewer-Nash Write Rule: Subject S can write information object 1829 O to firm F(i) only if (a) S can read O by the Brewer-Nash Read 1830 Rule *and* (b) no object can be read by S from a different firm 1831 F(j), no matter whether F(j) belongs to the same class as F(i) 1832 or to a different class. 1834 $ bridge 1835 (I) A gateway for traffic flowing at OSIRM Layer 2 between two 1836 networks (usually two LANs). (Compare: bridge CA, router.) 1838 $ bridge CA 1839 (I) A PKI consisting of only a CA that cross-certifies with CAs of 1840 some other PKIs. (See: cross-certification. Compare: bridge.) 1842 Tutorial: A bridge CA functions as a hub that enables a 1843 certificate user in any of the PKIs that attach to the bridge, to 1844 validate certificates issued in the other attached PKIs. 1846 For example, a bridge CA (BCA) CA1 1847 could cross-certify with four ^ 1848 PKIs that have the roots CA1, | 1849 CA2, CA3, and CA4. The cross- v 1850 certificates that the roots CA2 <-> BCA <-> CA3 1851 exchange with the BCA enable an ^ 1852 end entity EE1 certified under | 1853 under CA1 in PK1 to construct v 1854 a certification path needed to CA4 1855 validate the certificate of 1856 end entity EE2 under CA2, CA1 -> BCA -> CA2 -> EE2 1857 or vice versa. CA2 -> BCA -> CA1 -> EE1 1859 $ British Standard 7799 1860 (N) Part 1 of the standard is a code of practice for how to secure 1861 an information system. Part 2 specifies the management framework, 1862 objectives, and control requirements for information security 1863 management systems. [BS7799] (See: ISO 17799.) 1865 $ browser 1866 (I) An client computer program that can retrieve and display 1867 information from servers on the World Wide Web. Examples: 1868 Netscape's Navigator and Microsoft's Internet Explorer. 1870 $ brute force 1871 (I) A cryptanalysis technique or other kind of attack method 1872 involving an exhaustive procedure that tries a large number of 1873 possible solutions to the problem. (See: impossible, strength, 1874 work factor.) 1876 Tutorial: In some cases, brute force involves trying all of the 1877 possibilities. For example, for cipher text where the analyst 1878 already knows the decryption algorithm, a brute force technique 1879 for finding matching plain text is to decrypt the message with 1880 every possible key. In other cases, brute force involves trying a 1881 large number of possibilities but substantially fewer than all of 1882 them. For example, given a hash function that produces a N-bit 1883 hash result, the probability is greater than 1/2 that the analyst 1884 will find two inputs that have the same hash result after trying 1885 only 2**(N/2) random chosen inputs. (See: birthday attack.) 1887 $ BS7799 1888 (N) See: British Standard 7799. 1890 $ buffer overflow 1891 (I) Any attack technique that exploits a vulnerability resulting 1892 from computer software or hardware that does not check for 1893 exceeding the bounds of a storage area when data is written into a 1894 sequence of storage locations beginning in that area. 1896 Tutorial: By causing a normal system operation to write data 1897 beyond the bounds of a storage area, the attacker seeks to either 1898 disrupt system operation or cause the system to execute malicious 1899 software inserted by the attacker. 1901 $ buffer zone 1902 (I) A neutral internetwork segment used to connect other segments 1903 that each operate under a different security policy. 1905 Tutorial: To connect a private network to the Internet or some 1906 other relatively public network, one could construct a small, 1907 separate, isolated LAN and connect it to both the private network 1908 and the public network; one or both of the connections would 1909 implement a firewall to limit the traffic that could pass through 1910 the buffer zone. 1912 $ bulk encryption 1913 1. (I) Encryption of multiple channels by aggregating them into a 1914 single transfer path and then encrypting that path. (See: 1915 channel.) 1917 2. (O) "Simultaneous encryption of all channels of a multichannel 1918 telecommunications link." [C4009] (Compare: bulk keying material.) 1920 Usage: The use of "simultaneous" in definition 2 could be 1921 interpreted to mean that multiple channels are encrypted 1922 separately but at the same time. However, the common meaning of 1923 the term is that multiple data flows are combined into a single 1924 stream and then that stream is encrypted as a whole. 1926 $ bulk key 1927 (D) In a few published descriptions of hybrid encryption for SSH, 1928 Windows 2000, and other applications, this term refers to a 1929 symmetric key that (a) is used to encrypt a relatively large 1930 amount of data and (b) is itself encrypted with a public key. 1931 (Compare: bulk keying material.) 1932 Example: To send a large file to Bob, Alice (a) generates a 1933 symmetric key and uses it to encrypt the file (i.e., encrypt the 1934 bulk of the information that is to be sent) and then (b) encrypts 1935 that symmetric key (the "bulk key") with Bob's public key. 1937 Deprecated Term: ISDs SHOULD NOT use this term or definition; they 1938 are not well-established and could be confused with the 1939 established term "bulk keying material". Instead, use "symmetric 1940 key" and carefully explain how the key is applied. 1942 $ bulk keying material 1943 (N) Refers to handling keying material in large quantities, e.g., 1944 as a dataset that contains many items of keying material. (See: 1945 type 0. Compare: bulk key, bulk encryption.) 1947 $ bump-in-the-stack 1948 (I) An implementation approach that places a network security 1949 mechanism inside the system that is to be protected. (Compare: 1950 bump-in-the-wire.) 1952 Example: IPsec can be implemented inboard, in the protocol stack 1953 of an existing system or existing system design, by placing a new 1954 layer between the existing IP layer and the OSIRM Layer 3 drivers. 1955 Source code access for the existing stack is not required, but the 1956 system that contains the stack does need to be modified [R2401]. 1958 $ bump-in-the-wire 1959 (I) An implementation approach that places a network security 1960 mechanism outside of the system that is to be protected. (Compare: 1961 bump-in-the-stack.) 1963 Example: IPsec can be implemented outboard, in a physically 1964 separate device, so that the system that receives the IPsec 1965 protection does not need to be modified at all [R2401]. Military- 1966 grade link encryption has mainly been implemented as bump-in-the- 1967 wire devices. 1969 $ business-case analysis 1970 (N) An extended form of cost-benefit analysis that considers 1971 factors beyond financial metrics, including security factors such 1972 as the requirement for security services, their technical and 1973 programmatic feasibility, their qualitative benefits, and 1974 associated risks. (See: risk analysis.) 1976 $ byte 1977 (I) A fundamental unit of computer storage; the smallest 1978 addressable unit in a computer's architecture. Usually holds one 1979 character of information and, today, usually means eight bits. 1980 (Compare: octet.) 1982 Usage: Understood to be larger than a "bit", but smaller than a 1983 "word". Although "byte" almost always means "octet" today, some 1984 computer architectures have had bytes in other sizes (e.g., six 1985 bits, nine bits). Therefore, an STD SHOULD state the number of 1986 bits in a byte where the term is first used in the STD. 1988 $ C field 1989 (D) See: Compartments field. 1991 $ C1 or C2 computer system 1992 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 1993 Evaluation Criteria". 1995 $ CA 1996 (I) See: certification authority. 1998 $ CA certificate 1999 (D) "A [digital] certificate for one CA issued by another CA." 2000 [X509] 2002 Deprecated Definition: ISDs SHOULD NOT use the term with this 2003 definition; the definition is ambiguous with regard to how the 2004 certificate is constructed and how it is intended to be used. ISDs 2005 that use this term SHOULD provide a technical definition for it. 2006 (See: certificate profile.) 2008 Tutorial: There is no single, obvious choice for a technical 2009 definition of this term. Different PKIs can use different 2010 certificate profiles, and X.509 provides several choices of how to 2011 issue certificates to CAs. For example, one possible definition is 2012 the following: A v3 X.509 public-key certificate that has a 2013 "basicConstraints" extension containing a "cA" value of "TRUE". 2014 That would specifically indicate that "the certified public key 2015 may be used to verify certificate signatures", i.e., that the 2016 private key may be used by a CA. 2018 However, there also are other ways to indicate such usage. The 2019 certificate may have a "key Usage" extension that indicates the 2020 purposes for which the public key may be used, and one of the 2021 values that X.509 defines for that extension is "keyCertSign", to 2022 indicate that the certificate may be used for verifying a CA's 2023 signature on certificates. If "keyCertSign" is present in a 2024 certificate that also has a "basicConstraints" extension, than 2025 "cA" is set to "TRUE" in that extension. Alternatively, a CA could 2026 be issued a certificate in which "keyCertSign" is asserted without 2027 "basicConstraints" being present; and an entity that acts as a CA 2028 could be issued a certificate with "keyUsage" set to other values, 2029 either with or without "keyCertSign". 2031 $ CA domain 2032 (N) /PKI/ A security policy domain that "consists of a CA and its 2033 subjects [i.e., the entities named in the certificates issued by 2034 the CA]. Sometimes referred to as a PKI domain." [PAG] (See: 2035 domain.) 2037 $ Caesar cipher 2038 (I) A cipher that is defined for an alphabet of N characters, 2039 A(1), A(2), ..., A(N), and creates cipher text by replacing each 2040 plaintext character A(i) by A(i+K, mod N) for some 0