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