idnits 2.17.00 (12 Aug 2021) /tmp/idnits15999/draft-shirey-secgloss-v2-06.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 17728), 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 == The page length should not exceed 58 lines per page, but there was 332 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 333 pages 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 87: '...endations -- especially for the SHOULD...' RFC 2119 keyword, line 176: '... that are RECOMMENDED for use in ...' RFC 2119 keyword, line 206: '... - "I" for a RECOMMENDED term or d...' RFC 2119 keyword, line 207: '... - "N" if RECOMMENDED but not of...' RFC 2119 keyword, line 211: '...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 12450 has weird spacing: '...dentity v ...' == Line 15164 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 (29 August 2006) is 5743 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 986, but not defined == Missing Reference: 'DGSA' is mentioned on line 13007, but not defined == Missing Reference: 'CORBA' is mentioned on line 5346, but not defined == Missing Reference: 'R2246' is mentioned on line 6807, but not defined == Missing Reference: 'RFC 2323' is mentioned on line 7751, but not defined == Missing Reference: 'SP-28' is mentioned on line 9451, but not defined == Missing Reference: 'CSC001' is mentioned on line 15620, but not defined == Missing Reference: 'IS7498-2' is mentioned on line 10294, but not defined == Missing Reference: 'IS9945-1' is mentioned on line 11235, but not defined == Missing Reference: 'IS7812' is mentioned on line 11323, but not defined == Missing Reference: 'C4008' is mentioned on line 11550, but not defined == Missing Reference: 'EU-ESDIR' is mentioned on line 11854, but not defined == Missing Reference: 'RSA78' is mentioned on line 12366, but not defined == Missing Reference: 'Constraints' is mentioned on line 12453, but not defined == Missing Reference: 'PKCS12' is mentioned on line 13778, but not defined == Missing Reference: 'R3776' is mentioned on line 14339, but not defined == Missing Reference: 'DoDAF1' is mentioned on line 14567, but not defined == Missing Reference: 'FIPS31' is mentioned on line 14960, but not defined == Missing Reference: 'CA' is mentioned on line 15476, but not defined == Missing Reference: 'NIST' is mentioned on line 15859, but not defined == Missing Reference: 'FIPS' is mentioned on line 15860, but not defined == Unused Reference: 'Army' is defined on line 16775, but no explicit reference was found in the text == Unused Reference: 'DoD6' is defined on line 16890, but no explicit reference was found in the text == Unused Reference: 'DoDGSA' is defined on line 16900, but no explicit reference was found in the text == Unused Reference: 'ElGa' is defined on line 16911, but no explicit reference was found in the text == Unused Reference: 'FP041' is defined on line 16951, but no explicit reference was found in the text == Unused Reference: 'FP191' is defined on line 16993, but no explicit reference was found in the text == Unused Reference: 'I7812' is defined on line 17041, but no explicit reference was found in the text == Unused Reference: 'I9945' is defined on line 17069, but no explicit reference was found in the text == Unused Reference: 'IDSSC' is defined on line 17078, but no explicit reference was found in the text == Unused Reference: 'IDSSE' is defined on line 17081, but no explicit reference was found in the text == Unused Reference: 'IDSSY' is defined on line 17084, but no explicit reference was found in the text == Unused Reference: 'Knut' is defined on line 17107, but no explicit reference was found in the text == Unused Reference: 'N4006' is defined on line 17143, but no explicit reference was found in the text == Unused Reference: 'NCS03' is defined on line 17155, but no explicit reference was found in the text == Unused Reference: 'PKCS' is defined on line 17196, but no explicit reference was found in the text == Unused Reference: 'PKC12' is defined on line 17213, but no explicit reference was found in the text == Unused Reference: 'R1750' is defined on line 17270, but no explicit reference was found in the text == Unused Reference: 'R2323' is defined on line 17340, but no explicit reference was found in the text == Unused Reference: 'R2356' is defined on line 17348, but no explicit reference was found in the text == Unused Reference: 'R2801' is defined on line 17417, but no explicit reference was found in the text == Unused Reference: 'R3766' is defined on line 17463, but no explicit reference was found in the text == Unused Reference: 'R3820' is defined on line 17467, but no explicit reference was found in the text == Unused Reference: 'SP27' is defined on line 17587, 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 2078 (Obsoleted by RFC 2743) -- 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 (~~), 53 warnings (==), 23 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: 29 February 2007 29 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 305 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 QQQQ 54 Table of Contents 56 Section Page 57 ------- ---- 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Format of Entries . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1 Order of Entries . . . . . . . . . . . . . . . . . . . . . 4 61 2.2 Capitalization and Abbreviation . . . . . . . . . . . . . 4 62 2.3 Support for Automated Searching . . . . . . . . . . . . . 5 63 2.4 Definition Type and Context . . . . . . . . . . . . . . . 5 64 2.5 Explanatory Notes . . . . . . . . . . . . . . . . . . . . 5 65 2.6 Cross-References . . . . . . . . . . . . . . . . . . . . . 5 66 2.7 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.8 The New Punctuation . . . . . . . . . . . . . . . . . . . 6 68 3. Types of Entries . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1 Type "I": Recommended Definitions of Internet Origin . . . 7 70 3.2 Type "N": Recommended Definitions of Non-Internet Origin . 7 71 3.3 Type "O": Other Terms and Definitions to be Noted . . . . 7 72 3.4 Type "D": Deprecated Terms and Definitions . . . . . . . . 8 73 3.5 Definition Substitutions . . . . . . . . . . . . . . . . . 8 74 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5. Informative References . . . . . . . . . . . . . . . . . . . . 314 76 6. Security Considerations and IANA Considerations . . . . . . . 333 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 333 78 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 333 79 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 333 81 QQQQ 83 1. Introduction 85 This Glossary is *not* an Internet Standard, and its recommendations 86 represent only the opinions of its author. However, this Glossary 87 provides reasons for its recommendations -- especially for the SHOULD 88 NOTs -- so that readers can judge for themselves what to do. 90 This Glossary provides an internally consistent and self-contained 91 set of terms, abbreviations, and definitions -- supported by 92 explanations, recommendations, and references -- for terminology that 93 concerns information system security. The intent of this Glossary is 94 to improve the comprehensibility of Internet Standards documents 95 (ISDs) -- i.e., RFCs, Internet-Drafts, and other material produced as 96 part of the Internet Standards Process (RFC 2026) -- and other 97 Internet-related discourse. A few non-security, networking terms are 98 included to make the Glossary self-contained, but more complete 99 glossaries of such terms are available elsewhere [A1523, F1037, 100 R1208, R1983]. 102 This Glossary supports the goals of the Internet Standards Process: 104 o Clear, Concise, Easily Understood Documentation 106 This Glossary seeks to improve comprehensibility of security- 107 related content of ISDs. That requires wording to be clear and 108 understandable, and requires the set of security-related terms and 109 definitions to be consistent and self-supporting. Also, 110 terminology needs to be uniform across all ISDs; i.e., the same 111 term or definition needs to be used whenever and wherever the same 112 concept is mentioned. Harmonization of existing ISDs need not be 113 done immediately, but it is desirable to correct and standardize 114 terminology when new versions are issued in the normal course of 115 standards development and evolution. 117 o Technical Excellence 119 Just as Internet Standard (STD) protocols should operate 120 effectively, ISDs should use terminology accurately, precisely, 121 and unambiguously to enable standards to be implemented correctly. 123 o Prior Implementation and Testing 125 Just as STD protocols require demonstrated experience and 126 stability before adoption, ISDs need to use well-established 127 language; and the robustness principle for protocols -- "be 128 liberal in what you accept, and conservative in what you send" -- 129 is also applicable to the language used in ISDs that describe 130 protocols. Using terms in their plainest, dictionary sense (when 131 appropriate) helps to ensure international understanding. ISDs 132 need to avoid using private, newly invented terms in place of 133 generally accepted terms from open publications. ISDs need to 134 avoid substituting new definitions that conflict with established 136 QQQQ 137 ones. ISDs need to avoid using "cute" synonyms (e.g., "Green 138 Book"), because no matter how popular a nickname may be in one 139 community, it is likely to cause confusion in another. 141 o Openness, Fairness, and Timeliness 143 ISDs need to avoid using proprietary and trademarked terms for 144 purposes other than referring to those particular systems. ISDs 145 also need to avoid terms that either favor a particular vendor or 146 favor a particular security technology or mechanism over other, 147 competing techniques that already exist or might be developed in 148 the future. The set of terminology used across the set of ISDs 149 needs to be flexible and adaptable as the state of Internet 150 security art evolves. 152 In support of those goals, this Glossary provides guidance by marking 153 terms and definitions as being either endorsed or deprecated for use 154 in ISDs. The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 155 and "OPTIONAL" are intended to be interpreted the same way as in an 156 Internet Standard (i.e., as specified in RFC 2119). Other glossaries 157 (e.g., [Raym]) list additional terms that deal with Internet security 158 but have not been included in this Glossary because they are not 159 appropriate for ISDs. 161 2. Format of Entries 163 Section 4 presents Glossary entries in the following manner: 165 2.1 Order of Entries 167 Entries are sorted in lexicographic order, without regard to 168 capitalization. Numeric digits are treated as preceding alphabetic 169 characters, and special characters are treated as preceding 170 digits. Blanks are treated as preceding non-blank characters, 171 except that a hyphen or slash between the parts of a multiword 172 entry (e.g., "RED/BLACK separation") is treated like a blank. 174 If an entry has multiple definitions (e.g., "domain"), they are 175 numbered beginning with "1", and any of those multiple definitions 176 that are RECOMMENDED for use in ISDs are presented before other 177 definitions for that entry. If definitions are closely related 178 (e.g., "threat"), they are denoted by adding letters to a number, 179 such as "1a" and "1b". 181 2.2 Capitalization and Abbreviations 183 Entries that are proper nouns are capitalized (e.g., "Data 184 Encryption Algorithm"), as are other words derived from proper 185 nouns (e.g., "Caesar cipher"). All other entries are not 186 capitalized (e.g., "certification authority"). Each acronym or 187 other abbreviation that appears in this Glossary, either as an 188 entry or in a definition or explanation, is defined in this 190 QQQQ 191 Glossary, except items of common English usage, such as "a.k.a.", 192 "e.g.", "etc.", "i.e.", "vol.", "pp.", and "U.S.". 194 2.3 Support for Automated Searching 196 Each entry is preceded by a dollar sign ($) and a space. This 197 makes it possible to find the defining entry for an item "X" by 198 searching for the character string "$ X", without stopping at 199 entries in which "X" is used in explanations. 201 2.4 Definition Type and Context 203 Each entry is preceded by a character -- I, N, O, or D -- enclosed 204 in parentheses, to indicate the type of definition (as is 205 explained further in Section 3): 206 - "I" for a RECOMMENDED term or definition of Internet origin. 207 - "N" if RECOMMENDED but not of Internet origin. 208 - "O" for a term or definition that is NOT recommended for use in 209 ISDs but is something that authors of Internet documents should 210 know about. 211 - "D" for a term or definition that is deprecated and SHOULD NOT 212 be used in Internet documents. 214 If a definition is valid only in a specific context (e.g., 215 "baggage"), that context is shown immediately following the 216 definition type and is enclosed by a pair of slash symbols (/). If 217 the definition is valid only for specific parts of speech, that is 218 shown in the same way (e.g., "archive"). 220 2.5 Explanatory Notes 222 Some entries have explanatory text that is introduced by one or 223 more of the following keywords: 224 - Deprecated Abbreviation (e.g., "EE", "H field", "W3") 225 - Deprecated Definition (e.g., "digital certification") 226 - Deprecated Usage (e.g., "authenticate") 227 - Deprecated Term (e.g., "certificate authority") 228 - Pronunciation (e.g., "*-property") 229 - Derivation (e.g., "discretionary access control") 230 - Tutorial (e.g., "accreditation") 231 - Example (e.g., "back door") 232 - Usage (e.g., "access") 234 Explanatory text in this Glossary MAY be reused in other ISDs. 235 However, such text is not intended to authoritatively supersede 236 text of an ISD in which the Glossary entry is already used. 238 2.6 Cross-References 240 Some entries contain a parenthetical remark of the form "(See: 241 X.)", where X is a list of other, related terms. Some entries 242 contain a remark of the form "(Compare: X)", where X is a list of 244 QQQQ 245 terms that either are antonyms of the entry or differ in some 246 other manner worth noting. 248 2.7 Trademarks 250 All servicemarks and trademarks that appear in this Glossary are 251 used in an editorial fashion and to the benefit of the mark owner, 252 without any intention of infringement. 254 2.8 The New Punctuation 256 This Glossary uses the "new" or "logical" punctuation style 257 favored by computer programmers, as described by Raymond [Raym]: 258 Programmers use pairs of quotation marks the same way they use 259 pairs of parentheses, i.e., as balanced delimiters. For example, 260 if "Alice sends" is a phrase, and so are "Bill receives" and "Eve 261 listens", then a programmer would write the following sentence: 263 "Alice sends", "Bill receives", and "Eve listens". 265 According to standard American usage, the punctuation in that 266 sentence is incorrect; the continuation commas and the final 267 period should go inside the string quotes, like this: 269 "Alice sends," "Bill receives," and "Eve listens." 271 However, a programmer would not include a character in a literal 272 string if the character did not belong there, because that could 273 cause an error. For example, suppose a sentence in a draft of a 274 tutorial on the vi editing language looked like this: 276 Then delete one line from the file by typing "dd". 278 A book editor following standard usage might change the sentence 279 to look like this: 281 Then delete one line from the file by typing "dd." 283 However, in the vi language, the dot character repeats the last 284 command accepted. So, if a reader entered "dd.", two lines would 285 be deleted instead of one. 287 Similarly, use of standard American punctuation might cause 288 misunderstanding in entries in this Glossary. Thus, the new 289 punctuation is used here, and we recommend it for ISDs. 291 3. Types of Entries 293 Each entry in this Glossary is marked as type I, N, O, or D: 295 QQQQ 296 3.1 Type "I": Recommended Definitions of Internet Origin 298 The marking "I" indicates two things: 299 - Origin: "I" (as opposed to "N") means either that the Internet 300 Standards Process or Internet community is authoritative for 301 the definition *or* that the term is sufficiently generic that 302 this Glossary can freely state a definition without 303 contradicting a non-Internet authority (e.g., "attack"). 304 - Recommendation: "I" (as opposed to "O") means that the term and 305 definition are RECOMMENDED for use in ISDs. However, some "I" 306 entries may be accompanied by a "Usage" note that states a 307 limitation (e.g., "certification"), and ISDs SHOULD NOT use the 308 defined term outside that limited context. 310 Many "I" entries are proper nouns (e.g., "Internet Protocol") for 311 which the definition is intended only to provide basic 312 information; i.e., the authoritative definition of such terms is 313 found elsewhere. For a proper noun described as an "Internet 314 protocol", please refer to the current edition of "Internet 315 Official Protocol Standards" (Standard 1) for the standardization 316 status of the protocol. 318 3.2 Type "N": Recommended Definitions of Non-Internet Origin 320 The marking "N" indicates two things: 321 - Origin: "N" (as opposed to "I") means that the entry has a non- 322 Internet basis or origin. 323 - Recommendation: "N" (as opposed to "O") means that the term and 324 definition are RECOMMENDED for use in ISDs, if they are needed 325 at all in ISDs. Many of these entries are accompanied by a 326 label that states a context (e.g., "package") or a note that 327 states a limitation (e.g., "data integrity"), and ISDs SHOULD 328 NOT use the defined term outside that context or limit. Some of 329 the contexts are rarely if ever expected to occur in an ISD 330 (e.g., "baggage"). In those cases, the listing exists to make 331 Internet authors aware of the non-Internet usage so that they 332 can avoid conflicts with non-Internet documents. 334 3.3 Type "O": Other Terms and Definitions To Be Noted 336 The marking "O" means that the definition is of non-Internet 337 origin and SHOULD NOT be used in ISDs *except* in cases where the 338 term is specifically identified as non-Internet. 340 For example, an ISD might mention "BCA" (see: brand certification 341 authority) or "baggage" as an example of some concept; in that 342 case, the document should specifically say "SET(trademark) BCA" or 343 "SET(trademark) baggage" and include the definition of the term. 345 QQQQ 347 3.4 Type "D": Deprecated Terms and Definitions 349 If this Glossary recommends that a term or definition SHOULD NOT 350 be used in ISDs, then the entry is marked as type "D", and an 351 explanatory note -- "Deprecated Term", "Deprecated Abbreviation", 352 "Deprecated Definition", or "Deprecated Usage" -- is provided. 354 3.5 Definition Substitutions 356 Some terms have a definition published by a non-Internet authority 357 -- a government (e.g., "object reuse"), an industry (e.g., "Secure 358 Data Exchange"), a national authority (e.g., "Data Encryption 359 Standard"), or an international body (e.g., "data 360 confidentiality") -- that is suitable for use in ISDs. In those 361 cases, this Glossary marks the definition "N", recommending its 362 use in Internet documents. 364 Other such terms have definitions that are inadequate or 365 inappropriate for ISDs. For example, a definition might be 366 outdated or too narrow, or it might need clarification by 367 substituting more careful wording (e.g., "authentication 368 exchange") or explanations, using other terms that are defined in 369 this Glossary. In those cases, this Glossary marks the entry "O", 370 and provides an "I" or "N" entry that precedes, and is intended to 371 supersede, the "O" entry. 373 In some cases where this Glossary provides a definition to 374 supersede an "O" definition, the substitute is intended to subsume 375 the meaning of the "O" entry and not conflict with it. For the 376 term "security service", for example, the "O" definition deals 377 narrowly with only communication services provided by layers in 378 the OSIRM and is inadequate for the full range of ISD usage, while 379 the new "I" definition provided by this Glossary can be used in 380 more situations and for more kinds of service. However, the "O" 381 definition is also listed so that ISD authors will be aware of the 382 context in which the term is used more narrowly. 384 When making substitutions, this Glossary attempts to avoid 385 contradicting any non-Internet authority. Still, terminology 386 differs between authorities such as the American Bar Association, 387 OSI, SET, the U.S. DoD, and other authorities; and this Glossary 388 probably is not exactly aligned with any of them. 390 QQQQ 392 4. Definitions 394 $ *-property 395 (N) Synonym for "confinement property" in the context of the Bell- 396 LaPadula model. Pronunciation: star property. 398 $ 3DES 399 (N) See: Triple Data Encryption Algorithm. 401 $ A1 computer system 402 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 403 Evaluation Criteria". (Compare: beyond A1.) 405 $ AA 406 (D) See: "Deprecated Abbreviation" under "attribute authority". 408 $ ABA Guidelines 409 (N) "American Bar Association (ABA) Digital Signature Guidelines" 410 [DSG], a framework of legal principles for using digital 411 signatures and digital certificates in electronic commerce. 413 $ Abstract Syntax Notation One (ASN.1) 414 (N) A standard for describing data objects. [Larm, X680] (See: 415 CMS.) 417 Usage: ISDs SHOULD use the term "ASN.1" narrowly to 418 describe the notation or language called "Abstract 419 Syntax Notation One". ISDs MAY use the term more broadly 420 to encompass the notation, its associated encoding rules 421 (see: BER), and software tools that assist in its use, 422 when the context makes this meaning clear. 424 Tutorial: OSIRM defines computer network functionality in layers. 425 Protocols and data objects at higher layers are abstractly defined 426 to be implemented using protocols and data objects from lower 427 layers. A higher layer may define transfers of abstract objects 428 between computers, and a lower layer may define those transfers 429 concretely as strings of bits. Syntax is needed to specify data 430 formats of abstract objects, and encoding rules are needed to 431 transform abstract objects into bit strings at lower layers. OSI 432 standards use ASN.1 for those specifications and use various 433 encoding rules for those transformations. (See: BER.) 435 In ASN.1, formal names are written without spaces, and separate 436 words in a name are indicated by capitalizing the first letter of 437 each word except the first word. For example, the name of a CRL is 438 "certificateRevocationList". 440 $ ACC 441 (I) See: access control center. 443 QQQQ 445 $ acceptable risk 446 (I) A risk that is understood and tolerated by a system's user, 447 operator, owner, or accreditor, usually because the cost or 448 difficulty of implementing an effective countermeasure for the 449 associated vulnerability exceeds the expectation of loss. (See: 450 adequate security, risk, "second law" under "Courtney's laws".) 452 $ access 453 1a. (I) The ability and means to communicate with or otherwise 454 interact with a system to use system resources either to handle 455 information or to gain knowledge of the information the system 456 contains. (Compare: handle.) 458 Usage: The definition is intended to include all types of 459 communication with a system, including one-way communication in 460 either direction. In actual practice, however, passive users might 461 be treated as not having "access" and, therefore, be exempt from 462 most requirements of the system's security policy. (See: "passive 463 user" under "user".) 465 1a. (O) "Opportunity to make use of an information system (IS) 466 resource." [C4009] 468 2. (O) /formal model/ "A specific type of interaction between a 469 subject and an object that results in the flow of information from 470 one to the other." [NCS04] 472 $ Access Certificate for Electronic Services (ACES) 473 (O) A PKI operated by the U.S. Government's General Services 474 Administration in cooperation with industry partners. (See: CAM.) 476 $ access control 477 1. (I) Protection of system resources against unauthorized access. 479 2. (I) A process by which use of system resources is regulated 480 according to a security policy and is permitted only by authorized 481 entities (users, programs, processes, or other systems) according 482 to that policy. (See: access, access control service, computer 483 security, discretionary access control, mandatory access control, 484 role-based access control.) 486 3. (I) /formal model/ Limitations on interactions between subjects 487 and objects in an information system. 489 4. (O) "The prevention of unauthorized use of a resource, 490 including the prevention of use of a resource in an unauthorized 491 manner." [I7498-2] 493 5. (O) /U.S. Government/ A system using physical, electronic, or 494 human controls to identify or admit personnel with properly 495 authorized access to a SCIF. 497 QQQQ 499 $ access control center (ACC) 500 (I) A computer that maintains a database (possibly in the form of 501 an access control matrix) defining the security policy for an 502 access control service, and that acts as a server for clients 503 requesting access control decisions. 505 Tutorial: An ACC is sometimes used in conjunction with a key 506 center to implement access control in a key-distribution system 507 for symmetric cryptography. (See: BLACKER, Kerberos.) 509 $ access control list (ACL) 510 (I) /information system/ A mechanism that implements access 511 control for a system resource by enumerating the system entities 512 that are permitted to access the resource and stating, either 513 implicitly or explicitly, the access modes granted to each entity. 514 (Compare: access control matrix, access list, access profile, 515 capability list.) 517 $ access control matrix 518 (I) A rectangular array of cells, with one row per subject and one 519 column per object. The entry in a cell -- that is, the entry for a 520 particular subject-object pair -- indicates the access mode that 521 the subject is permitted to exercise on the object. Each column is 522 equivalent to an "access control list" for the object; and each 523 row is equivalent to an "access profile" for the subject. 525 $ access control service 526 (I) A security service that protects against a system entity using 527 a system resource in a way not authorized by the system's security 528 policy. (See: access control, discretionary access control, 529 identity-based security policy, mandatory access control, rule- 530 based security policy.) 532 Tutorial: This service includes protecting against use of a 533 resource in an unauthorized manner by an entity (i.e., a 534 principal) that is authorized to use the resource in some other 535 manner. (See: insider.) The two basic mechanisms for implementing 536 this service are ACLs and tickets. 538 $ access level 539 1. (D) Synonym for the hierarchical "classification level" in a 540 security level. [C4009] (See: security level.) 542 2. (D) Synonym for "clearance level". 544 Deprecated Definitions: ISDs SHOULD NOT use this term with these 545 definitions because they duplicate the meaning of more specific 546 terms. Any ISD that uses this term SHOULD provide a specific 547 definition for it because access control may be based on many 548 attributes other than classification level and clearance level. 550 QQQQ 552 $ access list 553 (I) /physical security/ Roster of persons who are authorized to 554 enter a controlled area. (Compare: access control list.) 556 $ access mode 557 (I) A distinct type of data processing operation (e.g., read, 558 write, append, or execute, or a combination of operations) that a 559 subject can potentially perform on an object in an information 560 system. [Huff] (See: read, write.) 562 $ access policy 563 (I) A kind of "security policy". (See: access, access control.) 565 $ access profile 566 (O) Synonym for "capability list". 568 Usage: ISDs that use this term SHOULD state a definition for it 569 because the definition is not widely known. 571 $ access right 572 (I) Synonym for "authorization"; emphasizes the possession of the 573 authorization by a system entity. 575 $ accountability 576 (I) The property of a system or system resource that ensures that 577 the actions of a system entity may be traced uniquely to that 578 entity, which can then be held responsible for its actions. [Huff] 579 (See: audit service.) 581 Tutorial: Accountability (a.k.a. individual accountability) 582 typically requires a system ability to positively associate the 583 identity of a user with the time, method, and mode of the user's 584 access to the system. This ability supports detection and 585 subsequent investigation of security breaches. Individual persons 586 who are system users are held accountable for their actions after 587 being notified of the rules of behavior for using the system and 588 the penalties associated with violating those rules. 590 $ accounting 591 See: COMSEC accounting. 593 $ accounting legend code (ALC) 594 (O) /U.S. Government/ Numeric system used to indicate the minimum 595 accounting controls required for items of COMSEC material within 596 the CMCS. [C4009] (See: COMSEC accounting.) 598 $ accreditation 599 (N) An administrative action by which a designated authority 600 declares that an information system is approved to operate in a 601 particular security configuration with a prescribed set of 602 safeguards. [FP102, SP37] (See: certification.) 604 QQQQ 605 Tutorial: An accreditation is usually based on a technical 606 certification of the system's security mechanisms. To accredit a 607 system, the approving authority must determine that any residual 608 risk is an acceptable risk. Although the terms "certification" and 609 "accreditation" are used more in the U.S. DoD and other government 610 agencies than in commercial organizations, the concepts apply any 611 place where managers are required to deal with and accept 612 responsibility for security risks. For example, the American Bar 613 Association is developing accreditation criteria for CAs. 615 $ accreditation boundary 616 (O) Synonym for "security perimeter". [C4009] 618 $ accreditor 619 (N) A management official who has been designated to have the 620 formal authority to "accredit" an information system, i.e., to 621 authorize the operation of, and the processing of sensitive data 622 in, the system and to accept the residual risk associated with the 623 system. (See: accreditation, residual risk.) 625 $ ACES 626 (O) See: Access Certificate for Electronic Services. 628 $ ACL 629 (I) See: access control list. 631 $ acquirer 632 1. (O) /SET/ "The financial institution that establishes an 633 account with a merchant and processes payment card authorizations 634 and payments." [SET1] 636 2. (O) /SET/ "The institution (or its agent) that acquires from 637 the card acceptor the financial data relating to the transaction 638 and initiates that data into an interchange system." [SET2] 640 $ activation data 641 (N) Secret data, other than keys, that is required to access a 642 cryptographic module. (See: CIK. Compare: initialization value.) 644 $ active attack 645 (I) See: secondary definition under "attack". 647 $ active content 648 1a. (I) Executable software that is bound to a document or other 649 data file and that executes automatically when a user accesses the 650 file, without explicit initiation by the user. (Compare: mobile 651 code.) 653 Tutorial: Active content can be mobile code when its associated 654 file is transferred across a network. 656 1b. (O) "Electronic documents that can carry out or trigger 658 QQQQ 659 actions automatically on a computer platform without the 660 intervention of a user. [This technology enables] mobile code 661 associated with a document to execute as the document is 662 rendered." [SP28] 664 $ active user 665 (I) See: secondary definition under "attack". 667 $ active wiretapping 668 (I) A wiretapping attack that attempts to alter data being 669 communicated or otherwise affect data flow. (See: wiretapping. 670 Compare: active attack, passive wiretapping.) 672 $ add-on security 673 (N) The retrofitting of protection mechanisms, implemented by 674 hardware or software, in an information system after the system 675 has become operational. [FP039] (Compare: baked-in security.) 677 $ adequate security 678 (O) /U.S. DoD/ "Security commensurate with the risk and magnitude 679 of harm resulting from the loss, misuse, or unauthorized access to 680 or modification of information." (See: acceptable risk, residual 681 risk.) 683 $ administrative security 684 1. (I) Management procedures and constraints to prevent 685 unauthorized access to a system. (See: "third law" under 686 "Courtney's laws", operational security, procedural security, 687 security architecture. Compare: technical security.) 689 Examples: Clear delineation and separation of duties; 690 configuration control. 692 Usage: Administrative security is usually understood to consist of 693 methods and mechanisms that are implemented and executed primarily 694 by people, rather than by automated systems. 696 2. (O) "The management constraints, operational procedures, 697 accountability procedures, and supplemental controls established 698 to provide an acceptable level of protection for sensitive data." 699 [FP039] 701 $ administrator 702 1. (O) /Common Criteria/ A person that is responsible for 703 configuring, maintaining, and administering the TOE in a correct 704 manner for maximum security. (See: administrative security.) 706 2. (O) /ITSEC/ A person in contact with the TOE, who is 707 responsible for maintaining its operational capability. 709 $ Advanced Encryption Standard (AES) 710 (N) A U.S. Government standard [FP197] (the successor to DES) that 712 QQQQ 713 (a) specifies "the AES algorithm", which is a symmetric block 714 cipher that is based on Rijndael and uses key sizes of 128, 192, 715 or 256 bits to operate on a 128-bit block, and (b) states policy 716 for using that algorithm to protect unclassified, sensitive data. 718 Tutorial: Rijndael was designed to handle additional block sizes 719 and key lengths that were not adopted in the AES. Rijndael was 720 selected by NIST through a public competition that was held to 721 find a successor to the DEA; the other finalists were MARS, RC6, 722 Serpent, and Twofish. 724 $ adversary 725 1. (I) An entity that attacks a system. (Compare: cracker, 726 intruder, hacker.) 728 2. (I) An entity that is a threat to a system. 730 $ AES 731 (N) See: Advanced Encryption Standard. 733 $ Affirm 734 (O) A formal methodology, language, and integrated set of software 735 tools developed at the University of Southern California's 736 Information Sciences Institute for specifying, coding, and 737 verifying software to produce correct and reliable programs. 738 [Cheh] 740 $ aggregation 741 (I) A circumstance in which a collection of information items is 742 required to be classified at a higher security level than any of 743 the items is classified individually. (See: classification.) 745 $ AH 746 (I) See: Authentication Header 748 $ air gap 749 (I) An interface between two systems at which (a) they are not 750 connected physically and (b) any logical connection is not 751 automated (i.e., data is transferred through the interface only 752 manually, under human control). (See: sneaker net. Compare: 753 gateway.) 755 Example: Computer A and computer B are on opposite sides of a 756 room. To move data from A to B, a person carries a floppy disk 757 across the room. If A and B operate in different security domains, 758 than moving data across the air gap may involve an upgrade or 759 downgrade operation. 761 $ ALC 762 (O) See: accounting legend code. 764 QQQQ 766 $ algorithm 767 (I) A finite set of step-by-step instructions for a problem- 768 solving or computation procedure, especially one that can be 769 implemented by a computer. (See: cryptographic algorithm.) 771 $ alias 772 (I) A name that an entity uses in place of its real name, usually 773 for the purpose of either anonymity or masquerade. 775 $ Alice and Bob 776 (I) The parties that are most often called upon to illustrate the 777 operation of bipartite security protocols. These and other 778 dramatis personae are listed by Schneier [Schn]. 780 $ American National Standards Institute (ANSI) 781 (N) A private, not-for-profit association that administers U.S. 782 private sector voluntary standards. 784 Tutorial: ANSI has approximately 1,000 member organizations, 785 including equipment users, manufacturers, and others. These 786 include commercial firms, government agencies, and other 787 institutions and international entities. 789 ANSI is the sole U.S. representative to (a) ISO and (b) (via the 790 U.S. National Committee) the International Electrotechnical 791 Commission (IEC), which are the two major, non-treaty, 792 international standards organizations. 794 ANSI provides a forum for ANSI-accredited standards development 795 groups. Among those groups, the following are especially relevant 796 to Internet security: 797 - International Committee for Information Technology 798 Standardization (INCITS) (formerly X3): Primary U.S. focus of 799 standardization in information and communications technologies, 800 encompassing storage, processing, transfer, display, 801 management, organization, and retrieval of information. 802 Example: [A3092]. 803 - Accredited Standards Committee X9: Develops, establishes, 804 maintains, and promotes standards for the financial services 805 industry. Example: [A9009]. 806 - Alliance for Telecommunications Industry Solutions (ATIS): 807 Develops standards, specifications, guidelines, requirements, 808 technical reports, industry processes, and verification tests 809 for interoperability and reliability of telecommunications 810 networks, equipment, and software. Example: [A1523]. 812 $ American Standard Code for Information Interchange (ASCII) 813 (N) A scheme that encodes 128 specified characters -- the numbers 814 0-9, the letters a-z and A-Z, some basic punctuation symbols, some 815 control codes that originated with Teletype machines, and a blank 816 space -- into the 7-bit binary integers. Forms the basis of the 817 character set representations used in most computers and many 819 QQQQ 820 Internet standards. [FP001] (See: code.) 822 $ Anderson report 823 (O) A 1972 study of computer security that was written by James P. 824 Anderson for the U.S. Air Force [Ande]. 826 Tutorial: Anderson collaborated with a panel of experts to study 827 Air Force requirements for multilevel security. The study 828 recommended research and development that was urgently needed to 829 provide secure information processing for command and control 830 systems and support systems. The report introduced the reference 831 monitor concept and provided development impetus for computer and 832 network security technology. However, many of the security 833 problems that the 1972 report called "current" still plague 834 information systems today. 836 $ anomaly detection 837 (I) A intrusion detection method that searches for activity that 838 is different from the normal behavior of system entities and 839 system resources. (See: IDS. Compare: misuse detection.) 841 $ anonymity 842 (I) The condition of an identity being unknown or concealed. (See: 843 alias, anonymizer, anonymous credential, anonymous login, 844 identity, onion routing, persona certificate. Compare: privacy.) 846 Tutorial: An application may require security services that 847 maintain anonymity of users or other system entities, perhaps to 848 preserve their privacy or hide them from attack. To hide an 849 entity's real name, an alias may be used; for example, a financial 850 institution may assign account numbers. Parties to transactions 851 can thus remain relatively anonymous, but can also accept the 852 transactions as legitimate. Real names of the parties cannot be 853 easily determined by observers of the transactions, but an 854 authorized third party may be able to map an alias to a real name, 855 such as by presenting the institution with a court order. In other 856 applications, anonymous entities may be completely untraceable. 858 $ anonymizer 859 (I) A internetwork service, usually provided via a proxy server, 860 that provides anonymity and privacy for clients. That is, the 861 service enables a client to access servers (a) without allowing 862 anyone to gather information about which servers the client 863 accesses and (b) without allowing the accessed servers to gather 864 information about the client, such as its IP address. 866 $ anonymous credential 867 (D) /U.S. Government/ A credential that (a) can be used to 868 authenticate a person as having a specific attribute or being a 869 member of a specific group (e.g., military veterans or U.S. 870 citizens) but (b) does not reveal the individual identity of the 871 person that presents the credential. [M0404] (See: anonymity.) 873 QQQQ 874 Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts 875 in a potentially misleading way. For example, when the credential 876 is an X.509 certificate, the term could be misunderstood to mean 877 that the certificate was signed by a CA that has a persona 878 certificate. Instead, use "attribute certificate", "organizational 879 certificate", or "persona certificate" depending on what is meant, 880 and provide additional explanations as needed. 882 $ anonymous login 883 (I) An access control feature (actually, an access control 884 vulnerability) in many Internet hosts that enables users to gain 885 access to general-purpose or public services and resources of a 886 host (such as allowing any user to transfer data using FTP) 887 without having a pre-established, identity-specific account (i.e., 888 user name and password). (See: anonymity.) 890 Tutorial: This feature exposes a system to more threats than when 891 all the users are known, pre-registered entities that are 892 individually accountable for their actions. A user logs in using a 893 special, publicly known user name (e.g., "anonymous", "guest", or 894 "ftp"). To use the public login name, the user is not required to 895 know a secret password and may not be required to input anything 896 at all except the name. In other cases, to complete the normal 897 sequence of steps in a login protocol, the system may require the 898 user to input a matching, publicly known password (such as 899 "anonymous") or may ask the user for an e-mail address or some 900 other arbitrary character string. 902 $ ANSI 903 (N) See: American National Standards Institute. 905 $ anti-jam 906 (N) "Measures ensuring that transmitted information can be 907 received despite deliberate jamming attempts." [C4009] (See: 908 electronic security, frequency hopping, jam, spread spectrum.) 910 $ apex trust anchor 911 (N) The trust anchor that is superior to all other trust anchors 912 in a particular system or context. (See: trust anchor, top CA.) 914 $ API 915 (I) See: application programming interface. 917 $ APOP 918 (I) See: POP3 APOP. 920 $ Application Layer 921 See: Internet Protocol Suite, OSIRM. 923 $ application program 924 (I) A computer program that performs a specific function directly 926 QQQQ 927 for a user (as opposed to a program that is part of a computer 928 operating system and exists to perform functions in support of 929 application programs). 931 $ architecture 932 (I) See: security architecture, system architecture. 934 $ archive 935 1a. (I) /noun/ A collection of data that is stored for a 936 relatively long period of time for historical and other purposes, 937 such as to support audit service, availability service, or system 938 integrity service. (Compare: backup, repository.) 940 1b. (I) /verb/ To store data in such a way as to create an 941 archive. (Compare: back up.) 943 Tutorial: A digital signature may need to be verified many years 944 after the signing occurs. The CA -- the one that issued the 945 certificate containing the public key needed to verify that 946 signature -- may not stay in operation that long. So every CA 947 needs to provide for long-term storage of the information needed 948 to verify the signatures of those to whom it issues certificates. 950 $ ARPANET 951 (I) Advanced Research Projects Agency (ARPA) Network, a pioneer 952 packet-switched network that (a) was designed, implemented, 953 operated, and maintained by BBN from January 1969 until July 1975 954 under contract to the U.S. Government; (b) led to the development 955 of today's Internet; and (c) was decommissioned in June 1990. 956 [B4799, Hafn] 958 $ ASCII 959 (N) See: American Standard Code for Information Interchange. 961 $ ASN.1 962 (N) See: Abstract Syntax Notation One. 964 $ asset 965 (I) A system resource that is (a) required to be protected by an 966 information system's security policy, (b) intended to be protected 967 by a countermeasure, or (c) required for a system's mission. 969 $ association 970 (I) A cooperative relationship between system entities, usually 971 for the purpose of transferring information between them. (See: 972 security association.) 974 $ assurance 975 See: security assurance. 977 $ assurance level 978 (N) A rank on a hierarchical scale that judges the confidence 980 QQQQ 981 someone can have that a TOE adequately fulfills stated security 982 requirements. (See: assurance, certificate policy, EAL, TCSEC.) 984 Example: U.S. Government guidance [M0404] describes four assurance 985 levels for identity authentication, where each level "describes 986 the [Government] agency's degree of certainty that the user has 987 presented [a credential] that refers to [the user's] identity." In 988 that guidance, "assurance is defined as (a) "the degree of 989 confidence in the vetting process used to establish the identity 990 of the individual to whom the credential was issued" and (b) "the 991 degree of confidence that the individual who uses the credential 992 is the individual to whom the credential was issued." 994 The four levels are described as follows: 995 - Level 1: Little or no confidence in the asserted identity. 996 - Level 2: Some confidence in the asserted identity. 997 - Level 3: High confidence in the asserted identity. 998 - Level 4: Very high confidence in the asserted identity. 1000 Standards for determining these levels are provided in a NIST 1001 publication [SP12]. However, as noted there, an assurance level is 1002 "a degree of confidence, not a true measure of how secure the 1003 system actually is. This distinction is necessary because it is 1004 extremely difficult -- and in many cases virtually impossible -- 1005 to know exactly how secure a system is." 1007 $ asymmetric cryptography 1008 (I) A modern branch of cryptography (popularly known as "public- 1009 key cryptography") in which the algorithms use a pair of keys (a 1010 public key and a private key) and use a different component of the 1011 pair for each of two counterpart cryptographic operations (e.g., 1012 encryption and decryption, or signature creation and signature 1013 verification). (See: key pair, symmetric cryptography.) 1015 Tutorial: Asymmetric algorithms have key management advantages 1016 over equivalently strong symmetric ones. First, one key of the 1017 pair need not be known by anyone but its owner; so it can more 1018 easily be kept secret. Second, although the other key is shared by 1019 all entities that use the algorithm, that key need not be kept 1020 secret from other, non-using entities; thus, the key-distribution 1021 part of key management can be done more easily. 1023 Asymmetric cryptography can be used to create algorithms for 1024 encryption, digital signature, and key agreement: 1025 - In an asymmetric encryption algorithm (e.g., "RSA"), when Alice 1026 wants to ensure confidentiality for data she sends to Bob, she 1027 encrypts the data with a public key provided by Bob. Only Bob 1028 has the matching private key that is needed to decrypt the 1029 data. (Compare: seal.) 1030 - In an asymmetric digital signature algorithm (e.g., "DSA"), 1031 when Alice wants to ensure data integrity or provide 1032 authentication for data she sends to Bob, she uses her private 1034 QQQQ 1035 key to sign the data (i.e., create a digital signature based on 1036 the data). To verify the signature, Bob uses the matching 1037 public key that Alice has provided. 1038 - In an asymmetric key-agreement algorithm (e.g., "Diffie- 1039 Hellman-Merkle"), Alice and Bob each send their own public key 1040 to the other party. Then each uses their own private key and 1041 the other's public key to compute the new key value. 1043 $ asymmetric key 1044 (I) A cryptographic key that is used in an asymmetric 1045 cryptographic algorithm. (See: asymmetric cryptography, private 1046 key, public key.) 1048 $ ATIS 1049 (N) See: "Alliance for Telecommunications Industry Solutions" 1050 under "ANSI". 1052 $ attack 1053 1. (I) An intentional act by which an entity attempts to evade 1054 security services and violate the security policy of a system. 1055 That is, an actual assault on system security that derives from an 1056 intelligent threat. (See: penetration, violation, vulnerability.) 1058 2. (I) A method or technique used in an assault (e.g., 1059 masquerade). (See: blind attack, distributed attack.) 1061 Tutorial: Attacks can be characterized according to intent: 1062 - An "active attack" attempts to alter system resources or affect 1063 their operation. 1064 - A "passive attack" attempts to learn or make use of information 1065 from a system but does not affect system resources of that 1066 system. (See: wiretapping.) 1068 The object of a passive attack might be to obtain data that is 1069 needed for an off-line attack. 1070 - An "off-line attack" is one in which the attacker obtains data 1071 from the target system and then analyzes the data on a 1072 different system of the attacker's own choosing, possibly in 1073 preparation for a second stage of attack on the target. 1075 Attacks can be characterized according to point of initiation: 1076 - An "inside attack" is one that is initiated by an entity inside 1077 the security perimeter (an "insider"), i.e., an entity that is 1078 authorized to access system resources but uses them in a way 1079 not approved by the party that granted the authorization. 1080 - An "outside attack" is initiated from outside the security 1081 perimeter, by an unauthorized or illegitimate user of the 1082 system (an "outsider"). In the Internet, potential outside 1083 attackers range from amateur pranksters to organized criminals, 1084 international terrorists, and hostile governments. 1085 Attacks can be characterized according to method of delivery: 1086 - In a "direct attack", the attacker addresses attacking packets 1088 QQQQ 1089 to the intended victim(s). 1090 - In an "indirect attack", the attacker addresses packets to a 1091 third party, and the packets either have the address(es) of the 1092 intended victim(s) as their source address(es) or indicate the 1093 intended victim(s) in some other way. The third party responds 1094 by sending one or more attacking packets to the intended 1095 victims. The attacker can use third parties as attack 1096 amplifiers by providing a broadcast address as the victim 1097 address (e.g., "smurf attack"). (See: reflector attack. 1098 Compare: reflection attack, replay attack.) 1100 The term "attack" relates to some other basic security terms as 1101 shown in the following diagram: 1103 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 1104 | An Attack: | |Counter- | | A System Resource: | 1105 | i.e., A Threat Action | | measure | | Target of the Attack | 1106 | +----------+ | | | | +-----------------+ | 1107 | | Attacker |<==================||<========= | | 1108 | | i.e., | Passive | | | | | Vulnerability | | 1109 | | A Threat |<=================>||<========> | | 1110 | | Agent | or Active | | | | +-------|||-------+ | 1111 | +----------+ Attack | | | | VVV | 1112 | | | | | Threat Consequences | 1113 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 1115 $ attack potential 1116 (I) The perceived likelihood of success should an attack be 1117 launched, expressed in terms of the attacker's ability (i.e., 1118 expertise and resources) and motivation. (Compare: threat, risk.) 1120 $ attack sensing, warning, and response 1121 (I) A set of security services that cooperate with audit service 1122 to detect and react to indications of threat actions, including 1123 both inside and outside attacks. (See: indicator.) 1125 $ attack tree 1126 (I) A branching, hierarchical data structure that represents a set 1127 of potential approaches to achieving an event in which system 1128 security is penetrated or compromised in a specified way. [Moor] 1130 Tutorial: Attack trees are special cases of fault trees. The 1131 security incident that is the goal of the attack is represented as 1132 the root node of the tree, and the ways that an attacker could 1133 reach that goal are iteratively and incrementally represented as 1134 branches and subnodes of the tree. Each subnode defines a subgoal, 1135 and each subgoal may have its own set of further subgoals, etc. 1136 The final nodes on the paths outward from the root, i.e., the leaf 1137 nodes, represent different ways to initiate an attack. Each node 1138 other than a leaf is either an AND-node or an OR-node. To achieve 1139 the goal represented by an AND-node, the subgoals represented by 1140 all of that node's subnodes must be achieved; and for an OR-node, 1142 QQQQ 1143 at least one of the subgoals must be achieved. Branches can be 1144 labeled with values representing difficulty, cost, or other attack 1145 attributes, so that alternative attacks can be compared. 1147 $ attribute 1148 1. (N) Information of a particular type concerning an identifiable 1149 system entity or object. An "attribute type" is the component of 1150 an attribute that indicates the class of information given by the 1151 attribute; and an "attribute value" is a particular instance of 1152 the class of information indicated by an attribute type. (See: 1153 attribute certificate.) 1155 $ attribute authority (AA) 1156 1. (N) A CA that issues attribute certificates. 1158 2. (O) "An authority [that] assigns privileges by issuing 1159 attribute certificates." [X509] 1161 Deprecated Usage: The abbreviation "AA" SHOULD NOT be used in an 1162 ISD unless it is first defined in the ISD. 1164 $ attribute certificate 1165 1. (I) A digital certificate that binds a set of descriptive data 1166 items, other than a public key, either directly to a subject name 1167 or to the identifier of another certificate that is a public-key 1168 certificate. (See: capability token.) 1170 2. (O) "A data structure, digitally signed by an [a]ttribute 1171 [a]uthority, that binds some attribute values with identification 1172 information about its holder." [X509] 1174 Tutorial: A public-key certificate binds a subject name to a 1175 public key value, along with information needed to perform certain 1176 cryptographic functions using that key. Other attributes of a 1177 subject, such as a security clearance, may be certified in a 1178 separate kind of digital certificate, called an attribute 1179 certificate. A subject may have multiple attribute certificates 1180 associated with its name or with each of its public-key 1181 certificates. 1183 An attribute certificate might be issued to a subject in the 1184 following situations: 1185 - Different lifetimes: When the lifetime of an attribute binding 1186 is shorter than that of the related public-key certificate, or 1187 when it is desirable not to need to revoke a subject's public 1188 key just to revoke an attribute. 1189 - Different authorities: When the authority responsible for the 1190 attributes is different than the one that issues the public-key 1191 certificate for the subject. (There is no requirement that an 1192 attribute certificate be issued by the same CA that issued the 1193 associated public-key certificate.) 1195 QQQQ 1197 $ audit 1198 See: security audit. 1200 $ audit log 1201 (I) Synonym for "security audit trail". 1203 $ audit service 1204 (I) A security service that records information needed to 1205 establish accountability for system events and for the actions of 1206 system entities that cause them. (See: security audit.) 1208 $ audit trail 1209 (I) See: security audit trail. 1211 $ AUTH 1212 (I) See: POP3 AUTH. 1214 $ authenticate 1215 (I) Verify (i.e., establish the truth of) an attribute value 1216 claimed by or for a system entity or system resource. (See: 1217 authentication, validate vs. verify, "relationship between data 1218 integrity service and authentication services" under "data 1219 integrity service".) 1221 Deprecated Usage: In general English usage, this term is used with 1222 the meaning "to prove genuine" (e.g., an art expert authenticates 1223 a Michelangelo painting); but ISDs should restrict usage as 1224 follows: 1225 - ISDs SHOULD NOT use this term to refer to proving or checking 1226 that data has not been changed, destroyed or lost in an 1227 unauthorized or accidental manner. Instead use "verify". 1228 - ISDs SHOULD NOT use this term to refer to proving the truth or 1229 accuracy of a fact or value such as a digital signature. 1230 Instead, use "verify". 1231 - ISDs SHOULD NOT use this term to refer to establishing the 1232 soundness or correctness of a construct, such as a digital 1233 certificate. Instead, use "validate". 1235 $ authentication 1236 (I) The process of verifying a claim that a system entity or 1237 system resource has a certain attribute value. (See: attribute, 1238 authenticate, authentication exchange, authentication information, 1239 credential, data origin authentication, peer entity 1240 authentication, "relationship between data integrity service and 1241 authentication services" under "data integrity service", simple 1242 authentication, strong authentication, verification, X.509.) 1244 Tutorial: Security services frequently depend on authentication of 1245 the identity of users, but authentication may involve any type of 1246 attribute that is recognized by a system. A claim may be made by a 1247 subject about itself (e.g., at login, a user typically asserts its 1248 identity) or a claim may be made on behalf of a subject or object 1250 QQQQ 1251 by some other system entity (e.g., a user may claim that a data 1252 object originates from a specific source, or that a data object is 1253 classified at a specific security level). 1255 An authentication process consists of two basic steps: 1256 - Identification step: Presenting the claimed attribute value 1257 (e.g., a user identifier) to the authentication subsystem. 1258 - Verification step: Presenting or generating authentication 1259 information (e.g., a value signed with a private key) that acts 1260 as evidence to prove the binding between the attribute and that 1261 for which it is claimed. (See: verification.) 1263 $ authentication code 1264 (D) Synonym for a checksum based on cryptography. (Compare: Data 1265 Authentication Code, Message Authentication Code.) 1267 Deprecated Term: ISDs SHOULD NOT use this uncapitalized term as a 1268 synonym for any kind of checksum, regardless of whether or not the 1269 checksum is cryptographic. Instead, use "checksum", "Data 1270 Authentication Code", "error detection code", "hash", "keyed 1271 hash", "Message Authentication Code", "protected checksum", or 1272 some other recommended term, depending on what is meant. 1274 The term mixes concepts in a potentially misleading way. The word 1275 "authentication" is misleading because the checksum may be used to 1276 perform a data integrity function rather than a data origin 1277 authentication function. 1279 $ authentication exchange 1280 1. (I) A mechanism to verify the identity of an entity by means of 1281 information exchange. 1283 2. (O) "A mechanism intended to ensure the identity of an entity 1284 by means of information exchange." [I7498-2] 1286 $ Authentication Header (AH) 1287 (I) An Internet protocol [R2402] designed to provide 1288 connectionless data integrity service and connectionless data 1289 origin authentication service for IP datagrams, and (optionally) 1290 to provide partial sequence integrity and protection against 1291 replay attacks. (See: IPsec. Compare: ESP.) 1293 Tutorial: Replay protection may be selected by the receiver when a 1294 security association is established. AH authenticates the upper- 1295 layer PDU that is carried as an IP SDU, and also authenticates as 1296 much of the IP PCI (i.e., the IP header) as possible. However, 1297 some IP header fields may change in transit, and the value of 1298 these fields, when the packet arrives at the receiver, may not be 1299 predictable by the sender. Thus, the values of such fields cannot 1300 be protected end-to-end by AH; protection of the IP header by AH 1301 is only partial when such fields are present. 1303 QQQQ 1304 AH may be used alone, or in combination with the ESP, or in a 1305 nested fashion with tunneling. Security services can be provided 1306 between a pair of communicating hosts, between a pair of 1307 communicating security gateways, or between a host and a gateway. 1308 ESP can provide nearly the same security services as AH, and ESP 1309 can also provide data confidentiality service. The main difference 1310 between authentication services provided by ESP and AH is the 1311 extent of the coverage; ESP does not protect IP header fields 1312 unless they are encapsulated by AH. 1314 $ authentication information 1315 (I) Information used to verify an identity claimed by or for an 1316 entity. (See: authentication, credential, user. Compare: 1317 identification information.) 1319 Tutorial: Authentication information may exist as, or be derived 1320 from, one of the following: (a) Something the entity knows (see: 1321 password); (b) something the entity possesses (see: token); (c) 1322 something the entity is (see: biometric authentication). 1324 $ authentication service 1325 (I) A security service that verifies an identity claimed by or for 1326 an entity. (See: authentication.) 1328 Tutorial: In a network, there are two general forms of 1329 authentication service: data origin authentication service and 1330 peer entity authentication service. 1332 $ authenticity 1333 (I) The property of being genuine and able to be verified and be 1334 trusted. (See: authenticate, authentication, validate vs. verify.) 1336 $ authority 1337 (D) "An entity, responsible for the issuance of certificates." 1338 [X509] 1340 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 1341 attribute authority, certification authority, registration 1342 authority, or similar terms; the shortened form may cause 1343 confusion. Instead, use the full term at the first instance of 1344 usage and then, if it is necessary to shorten text, use AA, CA, 1345 RA, and other abbreviations defined in this Glossary. 1347 $ authority certificate 1348 (D) "A certificate issued to an authority (e.g. either to a 1349 certification authority or to an attribute authority)." [X509] 1350 (See: authority.) 1352 Deprecated Term: ISDs SHOULD NOT use this term because it is 1353 ambiguous. Instead, use the full term "certification authority 1354 certificate", "attribute authority certificate", "registration 1355 authority certificate", etc. at the first instance of usage and 1357 QQQQ 1358 then, if it is necessary to shorten text, use AA, CA, RA, and 1359 other abbreviations defined in this Glossary. 1361 $ Authority Information Access extension 1362 (I) The private extension defined by PKIX for X.509 certificates 1363 to indicate "how to access CA information and services for the 1364 issuer of the certificate in which the extension appears. 1365 Information and services may include on-line validation services 1366 and CA policy data." [R3280] (See: private extension.) 1368 $ authorization 1369 1a. (I) An approval that is granted to a system entity to access a 1370 system resource. (Compare: permission, privilege.) 1372 Usage: Some synonyms are "permission" and "privilege". Specific 1373 terms are preferred in certain contexts: 1374 - /PKI/ "Authorization" SHOULD be used, to align with 1375 "certification authority" in the standard [X509]. 1376 - /role-based access control/ "Permission" SHOULD be used, to 1377 align with the standard [ANSI]. 1378 - /computer operating systems/ "Privilege" SHOULD be used, to 1379 align with the literature. (See: privileged process, privileged 1380 user.) 1382 Tutorial: The semantics and granularity of authorizations depend 1383 on the application and implementation (see: "first law" under 1384 "Courtney's laws"). An authorization may specify a particular 1385 access mode -- such as read, write, or execute -- for one or more 1386 system resources. 1388 1b. (I) A process for granting approval to a system entity to 1389 access a system resource. 1391 2. (O) /SET/ "The process by which a properly appointed person or 1392 persons grants permission to perform some action on behalf of an 1393 organization. This process assesses transaction risk, confirms 1394 that a given transaction does not raise the account holder's debt 1395 above the account's credit limit, and reserves the specified 1396 amount of credit. (When a merchant obtains authorization, payment 1397 for the authorized amount is guaranteed -- provided, of course, 1398 that the merchant followed the rules associated with the 1399 authorization process.)" [SET2] 1401 $ authorization credential 1402 (I) See: /access control/ under "credential". 1404 $ authorize 1405 (I) Grant an authorization to a system entity. 1407 $ authorized user 1408 (I) /access control/ A system entity that accesses a system 1409 resource for which the entity has received an authorization. 1411 QQQQ 1412 (Compare: insider, outsider, unauthorized user.) 1414 Deprecated Usage: ISDs that use this term SHOULD state a 1415 definition for it because the term is used in many ways and could 1416 easily be misunderstood. 1418 $ automated information system 1419 See: information system. 1421 $ availability 1422 1. (I) The property of a system or a system resource being 1423 accessible, or usable or operational upon demand, by an authorized 1424 system entity, according to performance specifications for the 1425 system; i.e., a system is available if it provides services 1426 according to the system design whenever users request them. (See: 1427 critical, denial of service. Compare: precedence, reliability, 1428 survivability.) 1430 2. (O) "The property of being accessible and usable upon demand by 1431 an authorized entity." [I7498-2] 1433 3. (D) "Timely, reliable access to data and information services 1434 for authorized users." [C4009] 1436 Deprecated Definition: ISDs SHOULD NOT use the term with 1437 definition 3; the definition mixes "availability" with 1438 "reliability", which is a different property. (See: reliability.) 1440 Tutorial: Availability requirements can be specified by 1441 quantitative metrics, but sometimes are stated qualitatively, such 1442 as in the following: 1443 - "Flexible tolerance for delay" may mean that brief system 1444 outages do not endanger mission accomplishment, but extended 1445 outages may endanger the mission. 1446 - "Minimum tolerance for delay" may mean that mission 1447 accomplishment requires the system to provide requested 1448 services in a short time. 1450 $ availability service 1451 (I) A security service that protects a system to ensure its 1452 availability. 1454 Tutorial: This service addresses the security concerns raised by 1455 denial-of-service attacks. It depends on proper management and 1456 control of system resources, and thus depends on access control 1457 service and other security services. 1459 $ avoidance 1460 (I) See: secondary definition under "security". 1462 $ B1, B2, or B3 computer system 1463 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 1465 QQQQ 1466 Evaluation Criteria". 1468 $ back door 1469 1. (I) /COMPUSEC/ A computer system feature -- which may be (a) an 1470 unintentional flaw, (b) a mechanism deliberately installed by the 1471 system's creator, or (c) a mechanism surreptitiously installed by 1472 an intruder -- that provides access to a system resource by other 1473 than the usual procedure and usually is hidden or otherwise not 1474 well-known. (See: maintenance hook. Compare: Trojan Horse.) 1476 Example: A way to access a computer other than through a normal 1477 login. Such an access path is not necessarily designed with 1478 malicious intent; operating systems sometimes are shipped by the 1479 manufacturer with hidden accounts intended for use by field 1480 service technicians or the vendor's maintenance programmers. 1482 2. (I) /cryptography/ A feature of a cryptographic system that 1483 makes it easily possible to break or circumvent the protection 1484 that the system is designed to provided. 1486 Example: A feature that makes it possible to decrypt cipher text 1487 much more quickly than by brute force cryptanalysis, without 1488 having prior knowledge of the decryption key. 1490 $ back up 1491 (I) /verb/ Create a reserve copy of data or, more generally, 1492 provide alternate means to perform system functions despite loss 1493 of system resources. (See: contingency plan. Compare: archive.) 1495 $ backup 1496 (I) /noun or adjective/ Refers to alternate means of performing 1497 system functions despite loss of system resources. (See: 1498 contingency plan). 1500 Example: A reserve copy of data, preferably one that is stored 1501 separately from the original, for use if the original becomes lost 1502 or damaged. (Compare: archive.) 1504 $ bagbiter 1505 (D) /slang/ "An entity, such as a program or a computer, that 1506 fails to work or that works in a remarkably clumsy manner. A 1507 person who has caused some trouble, inadvertently or otherwise, 1508 typically by failing to program the computer properly." [NCSSG] 1509 (See: flaw.) 1511 Deprecated Term: It is likely that other cultures use different 1512 metaphors for these concepts. Therefore, to avoid international 1513 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 1514 Usage under "Green Book.") 1516 $ baggage 1517 (O) /SET/ An "opaque encrypted tuple, which is included in a SET 1519 QQQQ 1520 message but appended as external data to the PKCS encapsulated 1521 data. This avoids superencryption of the previously encrypted 1522 tuple, but guarantees linkage with the PKCS portion of the 1523 message." [SET2] 1525 Deprecated Usage: ISDs SHOULD NOT use this term to describe a data 1526 element, except in the form "SET(trademark) baggage" with the 1527 meaning given above. 1529 $ baked-in security 1530 (D) The inclusion of security mechanisms in an information system 1531 beginning at an early point in the system's life cycle, i.e., 1532 during the design phase, or at least early in the implementation 1533 phase. (Compare: add-on security.) 1535 Deprecated Term: It is likely that other cultures use different 1536 metaphors for this concept. Therefore, to avoid international 1537 misunderstanding, ISDs SHOULD NOT use this term (unless they also 1538 provide a definition like this one). (See: Deprecated Usage under 1539 "Green Book".) 1541 $ bandwidth 1542 (I) The total width of the frequency band that is available to or 1543 used by a communication channel; usually expressed in Hertz (Hz). 1544 (RFC 3753) (Compare: channel capacity.) 1546 $ bank identification number (BIN) 1547 1. (O) The digits of a credit card number that identify the 1548 issuing bank. (See: primary account number.) 1550 2. (O) /SET/ The first six digits of a primary account number. 1552 $ Basic Encoding Rules (BER) 1553 (I) A standard for representing ASN.1 data types as strings of 1554 octets. [X690] (See: Distinguished Encoding Rules.) 1556 Deprecated Usage: Sometimes incorrectly treated as part of ASN.1. 1557 However, ASN.1 properly refers only to a syntax description 1558 language, and not to the encoding rules for the language. 1560 $ Basic Security Option 1561 (I) See: secondary definition under "IPSO". 1563 $ bastion host 1564 (I) A strongly protected computer that is in a network protected 1565 by a firewall (or is part of a firewall) and is the only host (or 1566 one of only a few) in the network that can be directly accessed 1567 from networks on the other side of the firewall. (See: firewall.) 1569 Tutorial: Filtering routers in a firewall typically restrict 1570 traffic from the outside network to reaching just one host, the 1571 bastion host, which usually is part of the firewall. Since only 1573 QQQQ 1574 this one host can be directly attacked, only this one host needs 1575 to be very strongly protected, so security can be maintained more 1576 easily and less expensively. However, to allow legitimate internal 1577 and external users to access application resources through the 1578 firewall, higher layer protocols and services need to be relayed 1579 and forwarded by the bastion host. Some services (e.g., DNS and 1580 SMTP) have forwarding built in; other services (e.g., TELNET and 1581 FTP) require a proxy server on the bastion host. 1583 $ BBN Technologies 1584 (O) The research-and-development company (originally called Bolt 1585 Baranek and Newman, Inc.) that built the ARPANET. 1587 $ BCA 1588 (O) See: brand certification authority. 1590 $ BCR 1591 (O) See: BLACK/Crypto/RED. 1593 $ BCI 1594 (O) See: brand CRL identifier. 1596 $ Bell-LaPadula model 1597 (N) A formal, mathematical, state-transition model of 1598 confidentiality policy for multilevel-secure computer systems 1599 [Bell]. (Compare: Biba model, Brewer-Nash model.) 1601 Tutorial: The model, devised by David Bell and Leonard LaPadula at 1602 The MITRE Corporation in 1973, characterizes computer system 1603 elements as subjects and objects. To determine whether or not a 1604 subject is authorized for a particular access mode on an object, 1605 the clearance of the subject is compared to the classification of 1606 the object. The model defines the notion of a "secure state", in 1607 which the only permitted access modes of subjects to objects are 1608 in accordance with a specified security policy. It is proven that 1609 each state transition preserves security by moving from secure 1610 state to secure state, thereby proving that the system is secure. 1611 In this model, a multilevel-secure system satisfies several rules, 1612 including the "confinement property" (a.k.a. the "*-property"), 1613 the "simple security property", and the "tranquility property". 1615 $ benign 1616 1. (N) /COMSEC/ "Condition of cryptographic data [such] that [it] 1617 cannot be compromised by human access [to the data]." [C4009] 1619 2. (O) /COMPUSEC/ See: secondary definition under "trust". 1621 $ benign fill 1622 (N) Process by which keying material is generated, distributed, 1623 and placed into an ECU without exposure to any human or other 1624 system entity, except the cryptographic module that consumes and 1625 uses the material. (See: benign.) 1627 QQQQ 1629 $ BER 1630 (I) See: Basic Encoding Rules. 1632 $ beyond A1 1633 1. (O) /formal/ A level of security assurance that is beyond the 1634 highest level (level A1) of criteria specified by the TCSEC. (See: 1635 Tutorial under "Trusted Computer System Evaluation Criteria".) 1637 2. (O) /informal/ A level of trust so high that it is beyond 1638 state-of-the-art technology; i.e., it cannot be provided or 1639 verified by currently available assurance methods, and especially 1640 not by currently available formal methods. 1642 $ Biba integrity 1643 (N) Synonym for "source integrity". 1645 $ Biba model 1646 (N) A formal, mathematical, state-transition model of integrity 1647 policy for multilevel-secure computer systems [Biba]. (See: source 1648 integrity. Compare: Bell-LaPadula model.) 1650 Tutorial: This model for integrity control is analogous to the 1651 Bell-LaPadula model for confidentiality control. Each subject and 1652 object is assigned an integrity level and, to determine whether or 1653 not a subject is authorized for a particular access mode on an 1654 object, the integrity level of the subject is compared to that of 1655 the object. The model prohibits the changing of information in an 1656 object by a subject with a lesser or incomparable level. The rules 1657 of the Biba model are duals of the corresponding rules in the 1658 Bell-LaPadula model. 1660 $ billet 1661 (N) A personnel position or assignment that can be filled by one 1662 system entity at a time. [JCSP1] (Compare: principal, role, user.) 1664 Tutorial: In an organization, a "billet" is a populational 1665 position, of which there is exactly one instance; but a "role" is 1666 functional position, of which there can be multiple instances. 1667 System entities are in one-to-one relationships with their 1668 billets, but may be in many-to-one and one-to-many relationships 1669 with their roles. 1671 $ BIN 1672 (O) See: bank identification number. 1674 $ bind 1675 (I) To inseparably associate by applying some security mechanism. 1677 Example: A CA creates a public-key certificate by using a digital 1678 signature to bind together (a) a subject name, (b) a public key, 1679 and usually (c) some additional data items (e.g., "X.509 public- 1681 QQQQ 1682 key certificate"). 1684 $ biometric authentication 1685 (I) A method of generating authentication information for a person 1686 by digitizing measurements of a physical or behavioral 1687 characteristic, such as a fingerprint, hand shape, retina pattern, 1688 voiceprint, handwriting style, or face. 1690 $ birthday attack 1691 (I) A class of attacks against cryptographic functions, including 1692 both encryption functions and hash functions. The attacks take 1693 advantage of a statistical property: Given a cryptographic 1694 function having an N-bit output, the probability is greater than 1695 1/2 that for 2**(N/2) randomly chosen inputs, the function will 1696 produce at least two outputs that are identical. (See: Tutorial 1697 under "hash function".) 1699 Derivation: From the somewhat surprising fact (often called the 1700 "birthday paradox") that although there are 365 days in a year, 1701 the probability is greater than 1/2 that two of more people share 1702 the same birthday in any randomly chosen group of 23 people. 1704 Birthday attacks enable an adversary to find two inputs for which 1705 a cryptographic function produces the same cipher text (or find 1706 two inputs for which a hash functions produces the same hash 1707 result) much faster than a brute force attack can; and a clever 1708 adversary can use such a capability to create considerable 1709 mischief. However, no birthday attack can enable an adversary to 1710 decrypt a given cipher text (or find a hash input that results in 1711 a given hash result) any faster than a brute force attack can. 1713 $ bit 1714 (I) A contraction of the term "binary digit"; the smallest unit of 1715 information storage, which has two possible states or values. The 1716 values usually are represented by the symbols "0" (zero) and "1" 1717 (one). (See: block, byte, nibble, word.) 1719 $ bit string 1720 (I) A sequence of bits, each of which is either "0" or "1". 1722 $ BLACK 1723 1. (N) Designation for data that consists only of cipher text, and 1724 for information system equipment items or facilities that handle 1725 only cipher text. Example: "BLACK key".(See: color change, 1726 RED/BLACK separation. Compare: RED.) 1728 2. (O) /U.S. Government/ "Designation applied to information 1729 systems, and to associated areas, circuits, components, and 1730 equipment, in which national security information is encrypted or 1731 is not processed." [C4009] 1733 3. (D) Any data that can be disclosed without harm. 1735 QQQQ 1736 Deprecated Definition: ISDs SHOULD NOT use the term with 1737 definition 3 because the definition is ambiguous with regard to 1738 whether the data is protected or not. 1740 $ BLACK/Crypto/RED (BCR) 1741 (N) An experimental, end-to-end, network packet encryption system 1742 developed in a working prototype form by BBN and the Collins Radio 1743 division of Rockwell Corporation in the 1975-1980 time frame for 1744 the U.S. DoD. BCR was the first network security system to support 1745 TCP/IP traffic, and it incorporated the first DES chips that were 1746 validated by the U.S. National Bureau of Standards (now called 1747 NIST). BCR also was the first to use a KDC and an ACC to manage 1748 connections. 1750 $ BLACK key 1751 (N) A key that is protected with a key-encrypting key and that 1752 must be decrypted before use. (See: BLACK. Compare: RED key.) 1754 $ BLACKER 1755 (O) An end-to-end encryption system for computer data networks 1756 that was developed by the U.S. DoD in the 1980s to provide host- 1757 to-host data confidentiality service for datagrams at OSIRM Layer 1758 3. [Weis] (Compare: CANEWARE, IPsec.) 1760 Tutorial: Each user host connects to its own bump-in-the-wire 1761 encryption device called a BLACKER Front End (BFE, TSEC/KI-111), 1762 through which the host connects to the subnetwork. The system also 1763 includes two types of centralized devices: one or more KDCs 1764 connect to the subnetwork and communicate with assigned sets of 1765 BFEs, and one or more ACCs connect to the subnetwork and 1766 communicate with assigned KDCs. BLACKER uses only symmetric 1767 encryption. A KDC distributes session keys to BFE pairs as 1768 authorized by an ACC. Each ACC maintains a database for a set of 1769 BFEs, and the database determines which pairs from that set (i.e., 1770 which pairs of user hosts behind the BFEs) are authorized to 1771 communicate and at what security levels. 1773 The BLACKER system is MLS in three ways: (a) The BFEs form a 1774 security perimeter around a subnetwork, separating user hosts from 1775 the subnetwork, so that the subnetwork can operate at a different 1776 security level (possibly a lower, less expensive level) than the 1777 hosts. (b) The BLACKER components are trusted to separate 1778 datagrams of different security levels, so that each datagram of a 1779 given security level can be received only by a host that is 1780 authorized for that security level; and thus BLACKER can separate 1781 host communities that operate at different security levels. (c) 1782 The host side of a BFE is itself MLS and can recognize a security 1783 label on each packet, so that an MLS user host can be authorized 1784 to successively transmit datagrams that are labeled with different 1785 security levels. 1787 QQQQ 1789 $ blind attack 1790 (I) A type of network-based attack method that does not require 1791 the attacking entity to receive data traffic from the attacked 1792 entity; i.e., the attacker does not need to "see" data packets 1793 sent by the victim. Example: SYN flood. 1795 Tutorial: If an attack method is blind, the attacker's packets can 1796 carry (a) a false IP source address (making it difficult for the 1797 victim to find the attacker) and (b) a different address on every 1798 packet (making it difficult for the victim to block the attack). 1799 If the attacker needs to receive traffic from the victim, the 1800 attacker must either (c) reveal its own IP address to the victim 1801 (which enables the victim to find the attacker or block the attack 1802 by filtering) or (d) provide a false address and also subvert 1803 network routing mechanisms to divert the returning packets to the 1804 attacker (which makes the attack more complex, more difficult, or 1805 more expensive). [R3552] 1807 $ block 1808 (I) A bit string or bit vector of finite length. (See: bit, block 1809 cipher. Compare: byte, word.) 1811 Usage: An "N-bit block" contains N bits, which usually are 1812 numbered from left to right as 1, 2, 3, ..., N. 1814 $ block cipher 1815 (I) An encryption algorithm that breaks plain text into fixed-size 1816 segments and uses the same key to transform each plaintext segment 1817 into a fixed-size segment of cipher text. Examples: AES, Blowfish, 1818 DEA, IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream 1819 cipher.) 1821 Tutorial: A block cipher can be adapted to have a different 1822 external interface, such as that of a stream cipher, by using a 1823 mode of cryptographic operation to package the basic algorithm. 1824 (See: CBC, CCM, CFB, CMAC, CTR, DEA, ECB, OFB.) 1826 $ Blowfish 1827 (N) A symmetric block cipher with variable-length key (32 to 448 1828 bits) designed in 1993 by Bruce Schneier as an unpatented, 1829 license-free, royalty-free replacement for DES or IDEA. [Schn] 1830 (See: Twofish.) 1832 $ brain-damaged 1833 (D) /slang/ "Obviously wrong: extremely poorly designed. Calling 1834 something brain-damaged is very extreme. The word implies that the 1835 thing is completely unusable, and that its failure to work is due 1836 to poor design, not accident." [NCSSG] (See: flaw.) 1838 Deprecated Term: It is likely that other cultures use different 1839 metaphors for this concept. Therefore, to avoid international 1840 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 1842 QQQQ 1843 Usage under "Green Book.") 1845 $ brand 1846 1. (I) A distinctive mark or name that identifies a product or 1847 business entity. 1849 2. (O) /SET/ The name of a payment card. (See: BCA.) 1851 Tutorial: Financial institutions and other companies have founded 1852 payment card brands, protect and advertise the brands, establish 1853 and enforce rules for use and acceptance of their payment cards, 1854 and provide networks to interconnect the financial institutions. 1855 These brands combine the roles of issuer and acquirer in 1856 interactions with cardholders and merchants. [SET1] 1858 $ brand certification authority (BCA) 1859 (O) /SET/ A CA owned by a payment card brand, such as MasterCard, 1860 Visa, or American Express. [SET2] (See: certification hierarchy, 1861 SET.) 1863 $ brand CRL identifier (BCI) 1864 (O) /SET/ A digitally signed list, issued by a BCA, of the names 1865 of CAs for which CRLs need to be processed when verifying 1866 signatures in SET messages. [SET2] 1868 $ break 1869 (I) /cryptography/ To successfully perform cryptanalysis and thus 1870 succeed in decrypting data or performing some other cryptographic 1871 function, without initially having knowledge of the key that the 1872 function requires. (See: penetrate, strength, work factor.) 1874 Usage: This term applies to encrypted data or, more generally, to 1875 a cryptographic algorithm or cryptographic system. Also, while the 1876 most common use is to refer to completely breaking an algorithm, 1877 the term is also used when a method is found that substantially 1878 reduces the work factor. 1880 $ Brewer-Nash model 1881 (N) A security model [BN89] to enforce the Chinese wall policy. 1882 (Compare: Bell-LaPadula model, Clark-Wilson model.) 1884 Tutorial: All proprietary information in the set of commercial 1885 firms F(1), F(2), ..., F(N) is categorized into mutually exclusive 1886 conflict-of-interest classes I(1), I(2), ..., I(M) that apply 1887 across all firms. Each firm belongs to exactly one class. The 1888 Brewer-Nash model has the following mandatory rules: 1889 - Brewer-Nash Read Rule: Subject S can read information object O 1890 from firm F(i) only if either (a) O is from the same firm as 1891 some object previously read by S *or* (b) O belongs to a class 1892 I(i) from which S has not previously read any object. (See: 1893 object, subject.) 1894 - Brewer-Nash Write Rule: Subject S can write information object 1896 QQQQ 1897 O to firm F(i) only if (a) S can read O by the Brewer-Nash Read 1898 Rule *and* (b) no object can be read by S from a different firm 1899 F(j), no matter whether F(j) belongs to the same class as F(i) 1900 or to a different class. 1902 $ bridge 1903 (I) A gateway for traffic flowing at OSIRM Layer 2 between two 1904 networks (usually two LANs). (Compare: bridge CA, router.) 1906 $ bridge CA 1907 (I) A PKI consisting of only a CA that cross-certifies with CAs of 1908 some other PKIs. (See: cross-certification. Compare: bridge.) 1910 Tutorial: A bridge CA functions as a hub that enables a 1911 certificate user in any of the PKIs that attach to the bridge, to 1912 validate certificates issued in the other attached PKIs. 1914 For example, a bridge CA (BCA) CA1 1915 could cross-certify with four ^ 1916 PKIs that have the roots CA1, | 1917 CA2, CA3, and CA4. The cross- v 1918 certificates that the roots CA2 <-> BCA <-> CA3 1919 exchange with the BCA enable an ^ 1920 end entity EE1 certified under | 1921 under CA1 in PK1 to construct v 1922 a certification path needed to CA4 1923 validate the certificate of 1924 end entity EE2 under CA2, CA1 -> BCA -> CA2 -> EE2 1925 or vice versa. CA2 -> BCA -> CA1 -> EE1 1927 $ British Standard 7799 1928 (N) Part 1 of the standard is a code of practice for how to secure 1929 an information system. Part 2 specifies the management framework, 1930 objectives, and control requirements for information security 1931 management systems. [BS7799] (See: ISO 17799.) 1933 $ browser 1934 (I) An client computer program that can retrieve and display 1935 information from servers on the World Wide Web. Examples: 1936 Netscape's Navigator and Microsoft's Internet Explorer. 1938 $ brute force 1939 (I) A cryptanalysis technique or other kind of attack method 1940 involving an exhaustive procedure that tries a large number of 1941 possible solutions to the problem. (See: impossible, strength, 1942 work factor.) 1944 Tutorial: In some cases, brute force involves trying all of the 1945 possibilities. For example, for cipher text where the analyst 1946 already knows the decryption algorithm, a brute force technique 1947 for finding matching plain text is to decrypt the message with 1948 every possible key. In other cases, brute force involves trying a 1950 QQQQ 1951 large number of possibilities but substantially fewer than all of 1952 them. For example, given a hash function that produces a N-bit 1953 hash result, the probability is greater than 1/2 that the analyst 1954 will find two inputs that have the same hash result after trying 1955 only 2**(N/2) random chosen inputs. (See: birthday attack.) 1957 $ BS7799 1958 (N) See: British Standard 7799. 1960 $ buffer overflow 1961 (I) Any attack technique that exploits a vulnerability resulting 1962 from computer software or hardware that does not check for 1963 exceeding the bounds of a storage area when data is written into a 1964 sequence of storage locations beginning in that area. 1966 Tutorial: By causing a normal system operation to write data 1967 beyond the bounds of a storage area, the attacker seeks to either 1968 disrupt system operation or cause the system to execute malicious 1969 software inserted by the attacker. 1971 $ buffer zone 1972 (I) A neutral internetwork segment used to connect other segments 1973 that each operate under a different security policy. 1975 Tutorial: To connect a private network to the Internet or some 1976 other relatively public network, one could construct a small, 1977 separate, isolated LAN and connect it to both the private network 1978 and the public network; one or both of the connections would 1979 implement a firewall to limit the traffic that could pass through 1980 the buffer zone. 1982 $ bulk encryption 1983 1. (I) Encryption of multiple channels by aggregating them into a 1984 single transfer path and then encrypting that path. (See: 1985 channel.) 1987 2. (O) "Simultaneous encryption of all channels of a multichannel 1988 telecommunications link." [C4009] (Compare: bulk keying material.) 1990 Usage: The use of "simultaneous" in definition 2 could be 1991 interpreted to mean that multiple channels are encrypted 1992 separately but at the same time. However, the common meaning of 1993 the term is that multiple data flows are combined into a single 1994 stream and then that stream is encrypted as a whole. 1996 $ bulk key 1997 (D) In a few published descriptions of hybrid encryption for SSH, 1998 Windows 2000, and other applications, this term refers to a 1999 symmetric key that (a) is used to encrypt a relatively large 2000 amount of data and (b) is itself encrypted with a public key. 2001 (Compare: bulk keying material.) 2003 QQQQ 2004 Example: To send a large file to Bob, Alice (a) generates a 2005 symmetric key and uses it to encrypt the file (i.e., encrypt the 2006 bulk of the information that is to be sent) and then (b) encrypts 2007 that symmetric key (the "bulk key") with Bob's public key. 2009 Deprecated Term: ISDs SHOULD NOT use this term or definition; they 2010 are not well-established and could be confused with the 2011 established term "bulk keying material". Instead, use "symmetric 2012 key" and carefully explain how the key is applied. 2014 $ bulk keying material 2015 (N) Refers to handling keying material in large quantities, e.g., 2016 as a dataset that contains many items of keying material. (See: 2017 type 0. Compare: bulk key, bulk encryption.) 2019 $ bump-in-the-stack 2020 (I) An implementation approach that places a network security 2021 mechanism inside the system that is to be protected. (Compare: 2022 bump-in-the-wire.) 2024 Example: IPsec can be implemented inboard, in the protocol stack 2025 of an existing system or existing system design, by placing a new 2026 layer between the existing IP layer and the OSIRM Layer 3 drivers. 2027 Source code access for the existing stack is not required, but the 2028 system that contains the stack does need to be modified [R2401]. 2030 $ bump-in-the-wire 2031 (I) An implementation approach that places a network security 2032 mechanism outside of the system that is to be protected. (Compare: 2033 bump-in-the-stack.) 2035 Example: IPsec can be implemented outboard, in a physically 2036 separate device, so that the system that receives the IPsec 2037 protection does not need to be modified at all [R2401]. Military- 2038 grade link encryption has mainly been implemented as bump-in-the- 2039 wire devices. 2041 $ business-case analysis 2042 (N) An extended form of cost-benefit analysis that considers 2043 factors beyond financial metrics, including security factors such 2044 as the requirement for security services, their technical and 2045 programmatic feasibility, their qualitative benefits, and 2046 associated risks. (See: risk analysis.) 2048 $ byte 2049 (I) A fundamental unit of computer storage; the smallest 2050 addressable unit in a computer's architecture. Usually holds one 2051 character of information and, today, usually means eight bits. 2052 (Compare: octet.) 2054 Usage: Understood to be larger than a "bit", but smaller than a 2055 "word". Although "byte" almost always means "octet" today, some 2057 QQQQ 2058 computer architectures have had bytes in other sizes (e.g., six 2059 bits, nine bits). Therefore, an STD SHOULD state the number of 2060 bits in a byte where the term is first used in the STD. 2062 $ C field 2063 (D) See: Compartments field. 2065 $ C1 or C2 computer system 2066 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 2067 Evaluation Criteria". 2069 $ CA 2070 (I) See: certification authority. 2072 $ CA certificate 2073 (D) "A [digital] certificate for one CA issued by another CA." 2074 [X509] 2076 Deprecated Definition: ISDs SHOULD NOT use the term with this 2077 definition; the definition is ambiguous with regard to how the 2078 certificate is constructed and how it is intended to be used. ISDs 2079 that use this term SHOULD provide a technical definition for it. 2080 (See: certificate profile.) 2082 Tutorial: There is no single, obvious choice for a technical 2083 definition of this term. Different PKIs can use different 2084 certificate profiles, and X.509 provides several choices of how to 2085 issue certificates to CAs. For example, one possible definition is 2086 the following: A v3 X.509 public-key certificate that has a 2087 "basicConstraints" extension containing a "cA" value of "TRUE". 2088 That would specifically indicate that "the certified public key 2089 may be used to verify certificate signatures", i.e., that the 2090 private key may be used by a CA. 2092 However, there also are other ways to indicate such usage. The 2093 certificate may have a "key Usage" extension that indicates the 2094 purposes for which the public key may be used, and one of the 2095 values that X.509 defines for that extension is "keyCertSign", to 2096 indicate that the certificate may be used for verifying a CA's 2097 signature on certificates. If "keyCertSign" is present in a 2098 certificate that also has a "basicConstraints" extension, than 2099 "cA" is set to "TRUE" in that extension. Alternatively, a CA could 2100 be issued a certificate in which "keyCertSign" is asserted without 2101 "basicConstraints" being present; and an entity that acts as a CA 2102 could be issued a certificate with "keyUsage" set to other values, 2103 either with or without "keyCertSign". 2105 $ CA domain 2106 (N) /PKI/ A security policy domain that "consists of a CA and its 2107 subjects [i.e., the entities named in the certificates issued by 2108 the CA]. Sometimes referred to as a PKI domain." [PAG] (See: 2109 domain.) 2111 QQQQ 2113 $ Caesar cipher 2114 (I) A cipher that is defined for an alphabet of N characters, 2115 A(1), A(2), ..., A(N), and creates cipher text by replacing each 2116 plaintext character A(i) by A(i+K, mod N) for some 0