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