idnits 2.17.00 (12 Aug 2021) /tmp/idnits37614/draft-shirey-secgloss-v2-02.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 16435), 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? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 157: '... the SHOULD NOTs -- so that readers ...' RFC 2119 keyword, line 174: '... that are RECOMMENDED for use in ...' RFC 2119 keyword, line 202: '... - "I" for a RECOMMENDED term or d...' RFC 2119 keyword, line 203: '... - "N" if RECOMMENDED but not of...' RFC 2119 keyword, line 207: '...tion that is deprecated and SHOULD NOT...' (231 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 2576 has weird spacing: '...ificate or...' == Line 11495 has weird spacing: '...dentity v ...' == Line 13017 has weird spacing: '...ng over eithe...' == Line 14006 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 (10 November 2005) is 6035 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 941, but not defined == Missing Reference: 'DGSA' is mentioned on line 12013, but not defined == Missing Reference: 'CORBA' is mentioned on line 4962, but not defined == Missing Reference: 'RFC 2323' is mentioned on line 7132, but not defined == Missing Reference: 'SP-28' is mentioned on line 8717, but not defined == Missing Reference: 'CSC001' is mentioned on line 14437, but not defined == Missing Reference: 'IS7498-2' is mentioned on line 9505, but not defined == Missing Reference: 'IS9945-1' is mentioned on line 10308, but not defined == Missing Reference: 'IS7812' is mentioned on line 10385, but not defined == Missing Reference: 'C4008' is mentioned on line 10577, but not defined == Missing Reference: 'EU-ESDIR' is mentioned on line 10931, but not defined == Missing Reference: 'RSA78' is mentioned on line 11413, but not defined == Missing Reference: 'Constraints' is mentioned on line 11498, but not defined == Missing Reference: 'PKCS12' is mentioned on line 12746, but not defined == Missing Reference: 'R3776' is mentioned on line 13268, but not defined == Missing Reference: 'DoDAF1' is mentioned on line 13484, but not defined == Missing Reference: 'FIPS31' is mentioned on line 13807, but not defined == Missing Reference: 'CA' is mentioned on line 14300, but not defined == Missing Reference: 'NIST' is mentioned on line 14652, but not defined == Missing Reference: 'FIPS' is mentioned on line 14653, but not defined == Unused Reference: 'Army' is defined on line 15520, but no explicit reference was found in the text == Unused Reference: 'DoD6' is defined on line 15630, but no explicit reference was found in the text == Unused Reference: 'ElGa' is defined on line 15645, but no explicit reference was found in the text == Unused Reference: 'FP041' is defined on line 15683, but no explicit reference was found in the text == Unused Reference: 'FP191' is defined on line 15723, but no explicit reference was found in the text == Unused Reference: 'I7812' is defined on line 15769, but no explicit reference was found in the text == Unused Reference: 'I9945' is defined on line 15797, but no explicit reference was found in the text == Unused Reference: 'Knut' is defined on line 15833, but no explicit reference was found in the text == Unused Reference: 'N4006' is defined on line 15869, but no explicit reference was found in the text == Unused Reference: 'NCS03' is defined on line 15880, but no explicit reference was found in the text == Unused Reference: 'PKCS' is defined on line 15921, but no explicit reference was found in the text == Unused Reference: 'PKC12' is defined on line 15936, but no explicit reference was found in the text == Unused Reference: 'R1750' is defined on line 15995, but no explicit reference was found in the text == Unused Reference: 'R2323' is defined on line 16069, but no explicit reference was found in the text == Unused Reference: 'R2356' is defined on line 16077, but no explicit reference was found in the text == Unused Reference: 'R2801' is defined on line 16149, but no explicit reference was found in the text == Unused Reference: 'R3766' is defined on line 16207, but no explicit reference was found in the text == Unused Reference: 'R3820' is defined on line 16211, but no explicit reference was found in the text == Unused Reference: 'SP27' is defined on line 16311, 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: 11 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: 10 May 2006 10 November 2005 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 (2005). All Rights Reserved. 46 Abstract 48 This Glossary provides definitions, abbreviations, and explanations 49 of terminology for information system security. The 291 pages of 50 listings 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 . . . . . . . . . . . . . . . . . . . . 300 83 6. Security Considerations and IANA Considertions . . . . . . . . 319 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 319 85 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 319 86 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 319 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 networking 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, made-up terms in place of generally 130 accepted terms from open publications. ISDs need to avoid 131 substituting new definitions that conflict with established ones. 132 ISDs need to avoid using "cute" synonyms (e.g., see: Green Book), 133 because no matter how popular a nickname may be in one community, 134 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; special characters are treated as preceding digits; 169 blanks are treated as preceding all other characters; and a hyphen 170 or slash between two parts of an entry is treated like a blank. 172 If an entry has multiple definitions (e.g., "domain"), they are 173 numbered beginning with "1", and any of those multiple definitions 174 that are RECOMMENDED for use in ISDs are presented before other 175 definitions for that entry. If definitions are closely related 176 (e.g., "threat"), they are denoted by adding letters to a number, 177 such as "1a" and "1b". 179 2.2 Capitalization and Abbreviations 181 Entries that are proper nouns are capitalized (e.g., "Data 182 Encryption Algorithm"), as are other words derived from proper 183 nouns (e.g., "Caesar cipher"). All other entries are not 184 capitalized (e.g., "certification authority"). Each acronym or 185 other abbreviation that appears in this Glossary, either as an 186 entry or in a definition or explanation, is defined in this 187 Glossary, except items of common English usage, such as "e.g.", 188 "etc.", "i.e.", "vol.", "pp.", and "U.S.". 190 2.3 Support for Automated Searching 192 Each entry is preceded by a dollar sign ($) and a space. This 193 makes it possible to find the defining entry for an item "X" by 194 searching for the character string "$ X", without stopping at 195 entries in which "X" is used in explanations. 197 2.4 Definition Type and Context 199 Each entry is preceded by a character -- I, N, O, or D -- enclosed 200 in parentheses, to indicate the type of definition (as is 201 explained further in Section 3): 202 - "I" for a RECOMMENDED term or definition of Internet origin. 203 - "N" if RECOMMENDED but not of Internet origin. 204 - "O" for a term or definition that is NOT recommended for use in 205 ISDs but is something that authors of Internet documents should 206 know about. 207 - "D" for a term or definition that is deprecated and SHOULD NOT 208 be used in Internet documents. 210 If a definition is valid only in a specific context (e.g., 211 "baggage"), that context is shown immediately following the 212 definition type and is enclosed by a pair of slash symbols (/). If 213 the definition is valid only for specific parts of speech, that is 214 shown in the same way (e.g., "archive). 216 2.5 Explanatory Notes 218 Some entries have explanatory text that is introduced by one or 219 more of the following keywords: 220 - Deprecated Abbreviation (e.g., "EE", "H field", "W3") 221 - Deprecated Definition (e.g., "digital certification") 222 - Deprecated Usage (e.g., "authenticate") 223 - Deprecated Term (e.g., "certificate authority") 224 - Pronunciation (e.g., "*-property") 225 - Derivation (e.g., "discretionary access control") 226 - Tutorial (e.g., "accreditation") 227 - Example (e.g., "back door") 228 - Usage (e.g., "access") 230 Explanatory text in this Glossary MAY be reused in other ISDs. 231 However, such text is not intended to authoritatively supersede 232 text of an ISD in which the Glossary entry is already used. 234 2.6 Cross-References 236 Some entries contain a parenthetical remark of the form "(See: 237 X.)", where X is a list one of more related Glossary entries. Some 238 entries contain a remark of the form "(Compare: X)", where X is a 239 list of other entries that either are antonyms or differ in some 240 other manner worth noting. 242 2.7 Trademarks 244 All servicemarks and trademarks that appear in this Glossary are 245 used in an editorial fashion and to the benefit of the mark owner, 246 without any intention of infringement. 248 2.8 The New Punctuation 250 This Glossary uses the "new" or "logical" punctuation style 251 favored by computer programmers, as described by Raymond [Raym]: 252 Programmers use pairs of quotation marks the same way they use 253 pairs of parentheses, i.e., as balanced delimiters. For example, 254 if "Alice sends" is a phrase, and so are "Bill receives" and "Eve 255 listens", then a programmer would write the following sentence: 257 "Alice sends", "Bill receives", and "Eve listens". 259 According to standard American usage, the punctuation in that 260 sentence is incorrect; the continuation commas and the final 261 period should go inside the string quotes, like this: 263 "Alice sends," "Bill receives," and "Eve listens." 265 However, a programmer would not include a character in a literal 266 string if the character did not belong there, because that could 267 cause an error. For example, suppose a sentence in a draft of a 268 tutorial on the vi editing language looked like this: 270 Then delete one line from the file by typing "dd". 272 A book editor following standard usage might change the sentence 273 to look like this: 275 Then delete one line from the file by typing "dd." 277 However, in the vi language, the dot character repeats the last 278 command accepted. So, if a reader entered "dd.", two lines would 279 be deleted instead of one. 281 Similarly, use of standard American punctuation might cause 282 misunderstanding in entries in this Glossary. Thus, the new 283 punctuation is used here, and we recommend it for ISDs. 285 3. Types of Entries 287 Each entry in this Glossary is marked as type I, N, O, or D: 289 3.1 Type "I": Recommended Definitions of Internet Origin 291 The marking "I" indicates two things: 292 - Origin: "I" (as opposed to "N") means either that the Internet 293 Standards Process or Internet community is authoritative for 294 the definition *or* that the term is sufficiently generic that 295 this Glossary can freely state a definition without 296 contradicting a non-Internet authority (e.g., "attack"). 297 - Recommendation: "I" (as opposed to "O") means that the term and 298 definition are RECOMMENDED for use in ISDs. However, some "I" 299 entries may be accompanied by a "Usage" note that states a 300 limitation (e.g., "certification"), and ISDs SHOULD NOT use the 301 defined term outside that limited context. 303 Many "I" entries are proper nouns (e.g., "Internet Protocol") for 304 which the definition is intended only to provide basic 305 information; i.e., the authoritative definition of such terms is 306 found elsewhere. For a proper noun described as an "Internet 307 protocol", please refer to the current edition of "Internet 308 Official Protocol Standards" (Standard 1) for the standardization 309 status of the protocol. 311 3.2 Type "N": Recommended Definitions of Non-Internet Origin 313 The marking "N" indicates two things: 314 - Origin: "N" (as opposed to "I") means that the entry has a non- 315 Internet basis or origin. 316 - Recommendation: "N" (as opposed to "O") means that the term and 317 definition are RECOMMENDED for use in ISDs, if they are needed 318 at all in ISDs. Many of these entries are accompanied by a 319 label that states a context (e.g., "package") or a note that 320 states a limitation (e.g., "data integrity"), and ISDs SHOULD 321 NOT use the defined term outside that context or limit. Some of 322 the contexts are rarely if ever expected to occur in an ISD 323 (e.g., see: baggage). In those cases, the listing exists to 324 make Internet authors aware of the non-Internet usage so that 325 they can avoid conflicts with non-Internet documents. 327 3.3 Type "O": Other Terms and Definitions To Be Noted 329 The marking "O" means that the definition is of non-Internet 330 origin and SHOULD NOT be used in ISDs *except* in cases where the 331 term is specifically identified as non-Internet. 333 For example, an ISD might mention "BCA" (see: brand certification 334 authority) or "baggage" as an example of some concept; in that 335 case, the document should specifically say "SET(trademark) BCA" or 336 "SET(trademark) baggage" and include the definition of the term. 338 3.4 Type "D": Deprecated Terms and Definitions 340 If this Glossary recommends that a term or definition SHOULD NOT 341 be used in ISDs, then the entry is marked as type "D", and a 342 "Deprecated Term", "Deprecated Definition", or "Deprecated Usage" 343 explanatory note is provided. 345 3.5 Definition Substitutions 347 Some terms have a definition published by a non-Internet authority 348 -- government (e.g., "object reuse"), industry (e.g., "Secure Data 349 Exchange"), national authority (e.g., "Data Encryption Standard"), 350 or international body (e.g., "data confidentiality") -- that is 351 suitable for use in ISDs. In those cases, this Glossary marks the 352 definition "N", recommending its use in Internet documents. 354 Other such terms have definitions that are inadequate or 355 inappropriate for ISDs. For example, a definition might be 356 outdated or too narrow, or it might need clarification by 357 substituting more careful wording (e.g., "authentication 358 exchange") or explanations, using other terms that are defined in 359 this Glossary. In those cases, this Glossary marks the entry "O", 360 and provides an "I" or "N" entry that precedes, and is intended to 361 supersede, the "O" entry. 363 In some cases where this Glossary provides a definition to 364 supersede an "O" definition, the substitute is intended to subsume 365 the meaning of the "O" entry and not conflict with it. For the 366 term "security service", for example, the "O" definition deals 367 narrowly with only communication services provided by layers in 368 the OSIRM and is inadequate for the full range of ISD usage, while 369 the new "I" definition provided by this Glossary can be used in 370 more situations and for more kinds of service. However, the "O" 371 definition is also listed so that ISD authors will be aware of the 372 context in which the term is used more narrowly. 374 When making substitutions, this Glossary attempts to avoid 375 contradicting any non-Internet authority. Still, terminology 376 differs between authorities such as the American Bar Association, 377 OSI, SET, the U.S. DoD, and other authorities; and this Glossary 378 probably is not exactly aligned with any of them. 380 4. Definitions 382 $ *-property 383 (N) Synonym for "confinement property" in the context of the Bell- 384 LaPadula model. Pronunciation: star property. 386 $ 3DES 387 (N) See: Triple Data Encryption Algorithm. 389 $ A1 computer system 390 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 391 Evaluation Criteria". (Compare: beyond A1.) 393 $ AA 394 (D) See: "Deprecated Abbreviation" under "attribute authority". 396 $ ABA Guidelines 397 (N) "American Bar Association (ABA) Digital Signature Guidelines" 398 [DSG], a framework of legal principles for using digital 399 signatures and digital certificates in electronic commerce. 401 $ Abstract Syntax Notation One (ASN.1) 402 (N) A standard for describing data objects. [Larm, X680] (See: 403 CMS.) 405 Deprecated Usage: The term "ASN.1" can be used narrowly to 406 describe the notation or language called "Abstract 407 Syntax Notation One", or can be used more broadly to 408 encompass the notation, its associated encoding rules 409 (see: BER), and software tools that assist in its use. 411 Tutorial: OSIRM defines computer network functionality in layers. 412 Protocols and data objects at higher layers are abstractly defined 413 to be implemented using protocols and data objects from lower 414 layers. A higher layer may define transfers of abstract objects 415 between computers, and a lower layer may define those transfers 416 concretely as strings of bits. Syntax is needed to specify data 417 formats of abstract objects, and encoding rules are needed to 418 transform abstract objects into bit strings at lower layers. OSI 419 standards use ASN.1 for those specifications and use various 420 encoding rules for those transformations. (See: BER.) 422 In ASN.1, formal names are written without spaces, and separate 423 words in a name are indicated by capitalizing the first letter of 424 each word except the first word. For example, the name of a CRL is 425 "certificateRevocationList". 427 $ ACC 428 (I) See: access control center. 430 $ acceptable risk 431 (I) A risk that is understood and tolerated by a system's user, 432 operator, owner, or accreditor, usually because the cost or 433 difficulty of implementing an effective countermeasure for the 434 associated vulnerability exceeds the expectation of loss. (See: 435 adequate security, risk, "second law" under "Courtney's laws".) 437 $ access 438 1. (I) The ability and means to communicate with or otherwise 439 interact with a system to use system resources either to handle 440 information or to gain knowledge of the information the system 441 contains. (Compare: handle.) 443 Usage: The definition is intended to include all types of 444 communication with a system, including one-way communication in 445 either direction. In actual practice, however, passive users might 446 be treated as not having "access" and, therefore, be exempt from 447 most requirements of the system's security policy. (See: "passive 448 user" under "user".) 450 2. (O) /formal model/ "A specific type of interaction between a 451 subject and an object that results in the flow of information from 452 one to the other." [NCS04] 454 $ Access Certificate for Electronic Services (ACES) 455 (O) A PKI operated by the U.S. Government's General Services 456 Administration in cooperation with industry partners. (See: CAM.) 458 $ access control 459 1. (I) Protection of system resources against unauthorized access. 461 2. (I) A process by which use of system resources is regulated 462 according to a security policy and is permitted only by authorized 463 entities (users, programs, processes, or other systems) according 464 to that policy. (See: access, access control service, computer 465 security, discretionary access control, mandatory access control, 466 role-based access control.) 468 3. (I) /formal model/ Limitations on interactions between subjects 469 and objects in an information system. 471 4. (O) "The prevention of unauthorized use of a resource, 472 including the prevention of use of a resource in an unauthorized 473 manner." [I7498-2] 475 5. (O) /U.S. Government/ A system using physical, electronic, or 476 human controls to identify or admit personnel with properly 477 authorized access to a SCIF. 479 $ access control center (ACC) 480 (I) A computer that maintains a database (possibly in the form of 481 an access control matrix) defining the security policy for an 482 access control service, and that acts as a server for clients 483 requesting access control decisions. 485 Tutorial: An ACC is sometimes used in conjunction with a key 486 center to implement access control in a key-distribution system 487 for symmetric cryptography. (See: BLACKER, Kerberos.) 489 $ access control list (ACL) 490 (I) /information system/ A mechanism that implements access 491 control for a system resource by enumerating the system entities 492 that are permitted to access the resource and stating, either 493 implicitly or explicitly, the access modes granted to each entity. 494 (Compare: access control matrix, access list, access profile, 495 capability list.) 497 $ access control matrix 498 (I) A rectangular array of cells, with one row per subject and one 499 column per object. The entry in a cell -- that is, the entry for a 500 particular subject-object pair -- indicates the access mode that 501 the subject is permitted to exercise on the object. Each column is 502 equivalent to an "access control list" for the object; and each 503 row is equivalent to an "access profile" for the subject. 505 $ access control service 506 (I) A security service that protects against a system entity using 507 a system resource in a way not authorized by the system's security 508 policy. (See: access control, discretionary access control, 509 identity-based security policy, mandatory access control, rule- 510 based security policy.) 512 Tutorial: This service includes protecting against use of a 513 resource in an unauthorized manner by an entity (i.e., a 514 principal) that is authorized to use the resource in some other 515 manner. (See: insider.) The two basic mechanisms for implementing 516 this service are ACLs and tickets. 518 $ access level 519 (D) Synonym for the hierarchical "classification level" in a 520 security level. [C4009] (See: security level.) 522 Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts 523 in a potentially misleading way. Access control may be based on 524 attributes other than classification level. 526 $ access list 527 (I) /physical security/ Roster of persons who are authorized to 528 enter a controlled area. (Compare: access control list.) 530 $ access mode 531 (I) A distinct type of data processing operation -- e.g., read, 532 write, append, or execute, or a combination of operations -- that 533 a subject can potentially perform on an object in an information 534 system. [Huff] 536 $ access policy 537 (I) A kind of "security policy". (See: access, access control.) 539 $ access profile 540 (O) A synonym for "capability list". 542 Usage: ISDs that use this term SHOULD state a definition for it 543 because the definition is not widely known. 545 $ access right 546 (I) Synonym for "authorization"; emphasizes the possession of the 547 authorization by a system entity. 549 $ accountability 550 (I) The property of a system or system resource that ensures that 551 the actions of a system entity may be traced uniquely to that 552 entity, which can then be held responsible for its actions. [Huff] 553 (See: audit service.) 555 Tutorial: Accountability (a.k.a. "individual accountability") 556 typically requires a system ability to positively associate the 557 identity of a user with the time, method, and mode of the user's 558 access to the system. This ability supports detection and 559 subsequent investigation of security breaches. Individual persons 560 who are system users are held accountable for their actions after 561 being notified of the rules of behavior for using the system and 562 the penalties associated with violating those rules. 564 $ accounting 565 See: COMSEC accounting. 567 $ accounting legend code (ALC) 568 (O) /U.S. Government/ Numeric system used to indicate the minimum 569 accounting controls required for items of COMSEC material within 570 the CMCS. [C4009] (See: COMSEC accounting.) 572 $ accreditation 573 (N) An administrative action by which a designated authority 574 declares that an information system is approved to operate in a 575 particular security configuration with a prescribed set of 576 safeguards. [FP102, SP37] (See: certification.) 578 Tutorial: An accreditation is usually based on a technical 579 certification of the system's security mechanisms. To accredit a 580 system, the approving authority must determine that any residual 581 risk is an acceptable risk. Although the terms "certification" and 582 "accreditation" are used more in the U.S. DoD and other government 583 agencies than in commercial organizations, the concepts apply any 584 place where managers are required to deal with and accept 585 responsibility for security risks. For example, the American Bar 586 Association is developing accreditation criteria for CAs. 588 $ accreditation boundary 589 (O) Synonym for "security perimeter". [C4009] 591 $ accreditor 592 (N) A management official who has been designated to have the 593 formal authority to "accredit" an information system, i.e., to 594 authorize the operation of, and the processing of sensitive data 595 in, the system and to accept the residual risk associated with the 596 system. (See: accreditation, residual risk.) 598 $ ACES 599 (O) See: Access Certificate for Electronic Services. 601 $ ACL 602 (I) See: access control list. 604 $ acquirer 605 1. (O) /SET/ "The financial institution that establishes an 606 account with a merchant and processes payment card authorizations 607 and payments." [SET1] 609 2. (O) /SET/ "The institution (or its agent) that acquires from 610 the card acceptor the financial data relating to the transaction 611 and initiates that data into an interchange system." [SET2] 613 $ activation data 614 (N) Secret data, other than keys, that is required to access a 615 cryptographic module. (See: CIK. Compare: initialization value.) 617 $ active attack 618 (I) See: secondary definition under "attack". 620 $ active content 621 1a. (I) Executable software that is bound to a document or other 622 data file and that executes automatically when a user accesses the 623 file, without explicit initiation by the user. (Compare: mobile 624 code.) 626 Tutorial: Active content can be mobile code when its associated 627 file is transferred across a network. 629 1b. (O) "Electronic documents that can carry out or trigger 630 actions automatically on a computer platform without the 631 intervention of a user. [This technology enables] mobile code 632 associated with a document to execute as the document is 633 rendered." [SP28] 635 $ active user 636 (I) See: secondary definition under "attack". 638 $ active wiretapping 639 (I) A wiretapping attack that attempts to alter data being 640 communicated or otherwise affect data flow. (See: wiretapping. 641 Compare: active attack, passive wiretapping.) 643 $ add-on security 644 (N) The retrofitting of protection mechanisms, implemented by 645 hardware or software, in an information system after the system 646 has become operational. [FP039] (Compare: baked-in security.) 648 $ adequate security 649 (O) /U.S. DoD/ "Security commensurate with the risk and magnitude 650 of harm resulting from the loss, misuse, or unauthorized access to 651 or modification of information." (See: acceptable risk, residual 652 risk.) 654 $ administrative security 655 1. (I) Management procedures and constraints to prevent 656 unauthorized access to a system. (See: "third law" under 657 "Courtney's laws", operational security, procedural security, 658 security architecture. Compare: technical security.) 660 Examples: Clear delineation and separation of duties; 661 configuration control. 663 Usage: Administrative security is usually understood to consist of 664 methods and mechanisms that are implemented and executed primarily 665 by people, rather than by automated systems. 667 2. (O) "The management constraints, operational procedures, 668 accountability procedures, and supplemental controls established 669 to provide an acceptable level of protection for sensitive data." 670 [FP039] 672 $ administrator 673 1. (O) /Common Criteria/ A person that is responsible for 674 configuring, maintaining, and administering the TOE in a correct 675 manner for maximum security. (See: administrative security.) 677 2. (O) /ITSEC/ A person in contact with the TOE, who is 678 responsible for maintaining its operational capability. 680 $ Advanced Encryption Standard (AES) 681 (N) A U.S. Government standard [FP197] (the successor to DES) that 682 (a) specifies "the AES algorithm", which is a symmetric block 683 cipher that is based on Rijndael and uses key sizes of 128, 192, 684 or 256 bits to operate on a 128-bit block, and (b) states policy 685 for using that algorithm to protect unclassified, sensitive data. 687 Tutorial: Rijndael was designed to handle additional block sizes 688 and key lengths that were not adopted in the AES. Rijndael was 689 selected by NIST through a public competition that was held to 690 find a successor to the DEA; the other finalists were MARS, RC6, 691 Serpent, and Twofish. 693 $ adversary 694 1. (I) An entity that attacks a system. (Compare: intruder.) 696 2. (I) An entity that is a threat to a system. 698 $ AES 699 (N) See: Advanced Encryption Standard. 701 $ Affirm 702 (O) A formal methodology, language, and integrated set of software 703 tools developed at the University of Southern California's 704 Information Sciences Institute for specifying, coding, and 705 verifying software to produce correct and reliable programs. 706 [Cheh] 708 $ aggregation 709 (I) A circumstance in which a collection of information items is 710 required to be classified at a higher security level than any of 711 the items is classified individually. (See: classification.) 713 $ AH 714 (I) See: Authentication Header 716 $ air gap 717 (I) An interface between two systems at which (a) they are not 718 connected physically and (b) any logical connection is not 719 automated (i.e., data is transferred through the interface only 720 manually, under human control). (See: sneaker net. Compare: 721 gateway.) 723 Example: Computer A and computer B are on opposite sides of a 724 room. To move data from A to B, a person carries a floppy disk 725 across the room. If A and B operate in different security domains, 726 than moving data across the air gap may involve an upgrade or 727 downgrade operation. 729 $ ALC 730 (O) See: accounting legend code. 732 $ algorithm 733 (I) A finite set of step-by-step instructions for a problem- 734 solving or computation procedure, especially one that can be 735 implemented by a computer. (See: cryptographic algorithm.) 737 $ alias 738 (I) A name that an entity uses in place of its real name, usually 739 for the purpose of either anonymity or masquerade. 741 $ Alice and Bob 742 (I) The parties that are most often called upon to illustrate the 743 operation of bipartite security protocols. These and other 744 dramatis personae are listed by Schneier [Schn]. 746 $ American National Standards Institute (ANSI) 747 (N) A private, not-for-profit association that administers U.S. 748 private sector voluntary standards. 750 Tutorial: ANSI has approximately 1,000 member organizations, 751 including equipment users, manufacturers, and others. These 752 include commercial firms, government agencies, and other 753 institutions and international entities. 755 ANSI is the sole U.S. representative to (a) ISO and (b) (via the 756 U.S. National Committee) the International Electrotechnical 757 Commission (IEC), which are the two major, non-treaty, 758 international standards organizations. 760 ANSI provides a forum for ANSI-accredited standards development 761 groups. Among those groups, the following are especially relevant 762 to Internet security: 763 - International Committee for Information Technology 764 Standardization (INCITS) (formerly X3): Primary U.S. focus of 765 standardization in information and communications technologies, 766 encompassing storage, processing, transfer, display, 767 management, organization, and retrieval of information. 768 Example: [A3092]. 769 - Accredited Standards Committee X9: Develops, establishes, 770 maintains, and promotes standards for the financial services 771 industry. Example: [A9009]. 772 - Alliance for Telecommunications Industry Solutions (ATIS): 773 Develops standards, specifications, guidelines, requirements, 774 technical reports, industry processes, and verification tests 775 for interoperability and reliability of telecommunications 776 networks, equipment, and software. Example: [A1523]. 778 $ American Standard Code for Information Interchange (ASCII) 779 (N) A scheme that encodes 128 specified characters -- the numbers 780 0-9, the letters a-z and A-Z, some basic punctuation symbols, some 781 control codes that originated with Teletype machines, and a blank 782 space -- into the 7-bit binary integers. Forms the basis of the 783 character set representations used in most computers and many 784 Internet standards. [FP001] (See: code.) 786 $ Anderson report 787 (O) A 1972 study of computer security that was written by James P. 788 Anderson for the U.S. Air Force [Ande]. 790 Tutorial: Anderson collaborated with a panel of experts to study 791 Air Force requirements for multilevel security. The study 792 recommended research and development that was urgently needed to 793 provide secure information processing for command and control 794 systems and support systems. The report introduced the reference 795 monitor concept and provided development impetus for computer and 796 network security technology. However, many of the security 797 problems that the 1972 report called "current" still plague 798 information systems today. 800 $ anomaly detection 801 (I) A intrusion detection method that searches for activity that 802 is different from the normal behavior of system entities and 803 system resources. (See: IDS. Compare: misuse detection.) 805 $ anonymity 806 (I) The condition of having a name that is unknown or concealed. 807 (See: alias, anonymizer, anonymous credential, anonymous login, 808 onion routing, persona certificate. Compare: privacy.) 810 Tutorial: An application may require security services that 811 maintain anonymity of users or other system entities, perhaps to 812 preserve their privacy or hide them from attack. To hide an 813 entity's real name, an alias may be used. For example, a financial 814 institution may assign an account number. Parties to a transaction 815 can thus remain relatively anonymous, but can also accept the 816 transaction as legitimate. Real names of the parties cannot be 817 easily determined by observers of the transaction, but an 818 authorized third party may be able to map an alias to a real name, 819 such as by presenting the institution with a court order. In other 820 applications, anonymous entities may be completely untraceable. 822 $ anonymizer 823 (I) A internetwork service, usually provided via a proxy server, 824 that provides anonymity and privacy for clients. That is, the 825 service enables a client to access servers (a) without allowing 826 anyone to gather information about which servers the client 827 accesses and (b) without allowing the accessed servers to gather 828 information about the client, such as its IP address. 830 $ anonymous credential 831 (D) /U.S. Government/ A credential that (a) can be used to 832 authenticate a person as having a specific attribute or being a 833 member of a specific group (e.g., military veterans or U.S. 834 citizens) but (b) does not reveal the individual identity of the 835 person that presents the credential. [M0404] (See: anonymity.) 837 Deprecated term: ISDs SHOULD NOT use this term; it mixes concepts 838 in a potentially misleading way. For example, when the credential 839 is an X.509 certificate, the term could be misunderstood to mean 840 that the certificate was signed by a CA that has a persona 841 certificate. Instead, use "attribute certificate", "organizational 842 certificate", or "persona certificate" depending on what is meant, 843 and provide additional explanations as needed. 845 $ anonymous login 846 (I) An access control feature (actually, an access control 847 vulnerability) in many Internet hosts that enables users to gain 848 access to general-purpose or public services and resources of a 849 host (such as allowing any user to transfer data using FTP) 850 without having a pre-established, identity-specific account (i.e., 851 user name and password). (See: anonymity.) 853 Tutorial: This feature exposes a system to more threats than when 854 all the users are known, pre-registered entities that are 855 individually accountable for their actions. A user logs in using a 856 special, publicly known user name (e.g., "anonymous", "guest", or 857 "ftp"). To use the public login name, the user is not required to 858 know a secret password and may not be required to input anything 859 at all except the name. In other cases, to complete the normal 860 sequence of steps in a login protocol, the system may require the 861 user to input a matching, publicly known password (such as 862 "anonymous") or may ask the user for an e-mail address or some 863 other arbitrary character string. 865 $ ANSI 866 (N) See: American National Standards Institute. 868 $ anti-jam 869 (N) "Measures ensuring that transmitted information can be 870 received despite deliberate jamming attempts." [C4009] (See: 871 electronic security, frequency hopping, jam, spread spectrum.) 873 $ apex trust anchor 874 (N) The trust anchor that is superior to all other trust anchors 875 in a particular system or context. (See: trust anchor, top CA.) 877 $ API 878 (I) See: application programming interface. 880 $ APOP 881 (I) See: POP3 APOP. 883 $ Application Layer 884 See: Internet Protocol Suite, OSIRM. 886 $ application program 887 (I) A computer program that performs a specific function directly 888 for a user (as opposed to a program that is part of a computer 889 operating system and exists to perform functions in support of 890 application programs). 892 $ archive 893 1a. (I) /noun/ A collection of data that is stored for a 894 relatively long period of time for historical and other purposes, 895 such as to support audit service, availability service, or system 896 integrity service. (Compare: backup, repository.) 898 1b. (I) /verb/ To store data in such a way as to create an 899 archive. (Compare: back up.) 900 Tutorial: A digital signature may need to be verified many years 901 after the signing occurs. The CA -- the one that issued the 902 certificate containing the public key needed to verify that 903 signature -- may not stay in operation that long. So every CA 904 needs to provide for long-term storage of the information needed 905 to verify the signatures of those to whom it issues certificates. 907 $ ARPANET 908 (I) Advanced Research Projects Agency (ARPA) Network, a pioneer 909 packet-switched network that (a) was designed, implemented, 910 operated, and maintained by BBN from January 1969 until July 1975 911 under contract to the U.S. Government; (b) led to the development 912 of today's Internet; and (c) was decommissioned in June 1990. 913 [B4799, Hafn] 915 $ ASCII 916 (N) See: American Standard Code for Information Interchange. 918 $ ASN.1 919 (N) See: Abstract Syntax Notation One. 921 $ asset 922 (I) A system resource that is (a) required to be protected by an 923 information system's security policy, (b) intended to be protected 924 by a countermeasure, or (c) required for a system's mission. 926 $ association 927 (I) A cooperative relationship between system entities, usually 928 for the purpose of transferring information between them. (See: 929 security association.) 931 $ assurance 932 See: security assurance. 934 $ assurance level 935 (N) A rank on a hierarchical scale that judges the confidence 936 someone can have that a TOE adequately fulfills stated security 937 requirements. (See: assurance, certificate policy, EAL, TCSEC.) 939 Example: U.S. Government guidance [M0404] describes four assurance 940 levels for identity authentication, where each level "describes 941 the [Government] agency's degree of certainty that the user has 942 presented [a credential] that refers to [the user's] identity." In 943 that guidance, "assurance is defined as (a) "the degree of 944 confidence in the vetting process used to establish the identity 945 of the individual to whom the credential was issued" and (b) "the 946 degree of confidence that the individual who uses the credential 947 is the individual to whom the credential was issued." 949 The four levels are described as follows: 950 - Level 1: Little or no confidence in the asserted identity. 952 - Level 2: Some confidence in the asserted identity. 953 - Level 3: High confidence in the asserted identity. 954 - Level 4: Very high confidence in the asserted identity. 956 Standards for determining these levels are provided in a NIST 957 publication [SP12]. However, as noted there, an assurance level is 958 "a degree of confidence, not a true measure of how secure the 959 system actually is. This distinction is necessary because it is 960 extremely difficult -- and in many cases virtually impossible -- 961 to know exactly how secure a system is." 963 $ asymmetric cryptography 964 (I) A modern branch of cryptography (popularly known as "public- 965 key cryptography") in which the algorithms use a pair of keys (a 966 public key and a private key) and use a different component of the 967 pair for each of two counterpart cryptographic operations (e.g., 968 encryption and decryption, or signature creation and signature 969 verification). (See: key pair, symmetric cryptography.) 971 Tutorial: Asymmetric algorithms have key management advantages 972 over equivalently strong symmetric ones. First, one key of the 973 pair need not be known by anyone but its owner; so it can more 974 easily be kept secret. Second, although the other key is shared by 975 all entities that use the algorithm, that key need not be kept 976 secret from other, non-using entities; thus, the key-distribution 977 part of key management can be done more easily. 979 Asymmetric cryptography can be used to create algorithms for 980 encryption, digital signature, and key agreement: 981 - In an asymmetric encryption algorithm (e.g., see: RSA), when 982 Alice wants to ensure confidentiality for data she sends to 983 Bob, she encrypts the data with a public key provided by Bob. 984 Only Bob has the matching private key that is needed to decrypt 985 the data. (Compare: seal.) 986 - In an asymmetric digital signature algorithm (e.g., see: DSA), 987 when Alice wants to ensure data integrity or provide 988 authentication for data she sends to Bob, she uses her private 989 key to sign the data (i.e., create a digital signature based on 990 the data). To verify the signature, Bob uses the matching 991 public key that Alice has provided. 992 - In an asymmetric key-agreement algorithm (e.g., see: Diffie- 993 Hellman), Alice and Bob each send their own public key to the 994 other party. Then each uses their own private key and the 995 other's public key to compute the new key value. 997 $ asymmetric key 998 (I) A cryptographic key that is used in an asymmetric 999 cryptographic algorithm. (See: asymmetric cryptography, private 1000 key, public key.) 1002 $ ATIS 1003 (N) See: "Alliance for Telecommunications Industry Solutions" 1004 under "ANSI". 1006 $ attack 1007 1. (I) An intentional act by which an entity attempts to evade 1008 security services and violate the security policy of a system. 1009 That is, an actual assault on system security that derives from an 1010 intelligent threat. (See: penetration, violation, vulnerability.) 1012 2. (I) A method or technique used in an assault (e.g., 1013 masquerade). (See: blind attack, distributed attack.) 1015 Tutorial: Attacks can be characterized according to intent: 1016 - An "active attack" attempts to alter system resources or affect 1017 their operation. 1018 - A "passive attack" attempts to learn or make use of information 1019 from the system but does not affect system resources. (E.g., 1020 see: wiretapping.) 1022 The object of a passive attack might be to obtain data that is 1023 needed for an off-line attack. 1024 - An "off-line attack" is one in which the attacker obtains data 1025 from the target system and then analyzes the data on a 1026 different system of the attacker's own choosing, possibly in 1027 preparation for a second stage of attack on the target. 1029 Attacks can be characterized according to point of initiation: 1030 - An "inside attack" is one that is initiated by an entity inside 1031 the security perimeter (an "insider"), i.e., an entity that is 1032 authorized to access system resources but uses them in a way 1033 not approved by those who granted the authorization. 1034 - An "outside attack" is initiated from outside the perimeter, by 1035 an unauthorized or illegitimate user of the system (an 1036 "outsider"). In the Internet, potential outside attackers range 1037 from amateur pranksters to organized criminals, international 1038 terrorists, and hostile governments. 1040 The term "attack" relates to some other basic security terms as 1041 shown in the following diagram: 1043 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 1044 | An Attack: | |Counter- | | A System Resource: | 1045 | i.e., A Threat Action | | measure | | Target of the Attack | 1046 | +----------+ | | | | +-----------------+ | 1047 | | Attacker |<==================||<========= | | 1048 | | i.e., | Passive | | | | | Vulnerability | | 1049 | | A Threat |<=================>||<========> | | 1050 | | Agent | or Active | | | | +-------|||-------+ | 1051 | +----------+ Attack | | | | VVV | 1052 | | | | | Threat Consequences | 1053 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 1055 $ attack potential 1056 (I) The perceived likelihood of success should an attack be 1057 launched, expressed in terms of the attacker's ability (i.e., 1058 expertise and resources) and motivation. (Compare: threat, risk.) 1060 $ attack sensing, warning, and response 1061 (I) A set of security services that cooperate with audit service 1062 to detect and react to indications of threat actions, including 1063 both inside and outside attacks. (See: indicator.) 1065 $ attack tree 1066 (I) A branching, hierarchical data structure that represents a set 1067 of potential approaches to achieving an event in which system 1068 security is penetrated or compromised in a specified way. [Moor] 1070 Tutorial: Attack trees are special cases of fault trees. The 1071 security incident that is the goal of the attack is represented as 1072 the root node of the tree, and the ways that an attacker could 1073 reach that goal are iteratively and incrementally represented as 1074 branches and subnodes of the tree. Each subnode defines a subgoal, 1075 and each subgoal may have its own set of further subgoals, etc. 1076 The final nodes on the paths outward from the root, i.e., the leaf 1077 nodes, represent different ways to initiate an attack. Each node 1078 other than a leaf is either an AND-node or an OR-node. To achieve 1079 the goal represented by an AND-node, the subgoals represented by 1080 all of that node's subnodes must be achieved; and for an OR-node, 1081 at least one of the subgoals must be achieved. Branches can be 1082 labeled with values representing difficulty, cost, or other attack 1083 attributes, so that alternative attacks can be compared. 1085 $ attribute 1086 1. (N) The information of a particular type concerning an 1087 identifiable system entity or object. An "attribute type" is the 1088 component of an attribute that indicates the class of information 1089 given by the attribute; and an "attribute value" is a particular 1090 instance of the class of information indicated by an attribute 1091 type. (See: attribute certificate.) 1093 $ attribute authority (AA) 1094 1. (N) A CA that issues attribute certificates. 1096 2. (O) "An authority [that] assigns privileges by issuing 1097 attribute certificates." [X509] 1099 Deprecated Abbreviation: The abbreviation "AA" SHOULD NOT be used 1100 in an ISD unless it is first defined in the ISD. 1102 $ attribute certificate 1103 1. (I) A digital certificate that binds a set of descriptive data 1104 items, other than a public key, either directly to a subject name 1105 or to the identifier of another certificate that is a public-key 1106 certificate. (See: capability token.) 1107 2. (O) "A data structure, digitally signed by an [a]ttribute 1108 [a]uthority, that binds some attribute values with identification 1109 information about its holder." [X509] 1111 Tutorial: A public-key certificate binds a subject name to a 1112 public key value, along with information needed to perform certain 1113 cryptographic functions using that key. Other attributes of a 1114 subject, such as a security clearance, may be certified in a 1115 separate kind of digital certificate, called an attribute 1116 certificate. A subject may have multiple attribute certificates 1117 associated with its name or with each of its public-key 1118 certificates. 1120 An attribute certificate might be issued to a subject in the 1121 following situations: 1122 - Different lifetimes: When the lifetime of an attribute binding 1123 is shorter than that of the related public-key certificate, or 1124 when it is desirable not to need to revoke a subject's public 1125 key just to revoke an attribute. 1126 - Different authorities: When the authority responsible for the 1127 attributes is different than the one that issues the public-key 1128 certificate for the subject. (There is no requirement that an 1129 attribute certificate be issued by the same CA that issued the 1130 associated public-key certificate.) 1132 $ audit 1133 See: security audit. 1135 $ audit log 1136 (I) Synonym for "security audit trail". 1138 $ audit service 1139 (I) A security service that records information needed to 1140 establish accountability for system events and for the actions of 1141 system entities that cause them. (See: security audit.) 1143 $ audit trail 1144 (I) See: security audit trail. 1146 $ AUTH 1147 (I) See: POP3 AUTH. 1149 $ authentic signature 1150 (I) A signature (especially a digital signature) that can be 1151 trusted because it can be verified. (See: validate vs. verify.) 1153 $ authenticate 1154 (I) Verify (i.e., establish the truth of) an identity claimed by 1155 or for a system entity. (See: authentication, validate vs. verify, 1156 "relationship between data integrity service and authentication 1157 services" under "data integrity service".) 1158 Deprecated Usage: In general English usage, this term is used with 1159 the meaning "to prove genuine" (e.g., an art expert authenticates 1160 a Michelangelo painting); but this Internet definition restricts 1161 usage as follows: 1162 - ISDs SHOULD NOT use this term to refer to proving or checking 1163 that data has not been changed, destroyed or lost in an 1164 unauthorized or accidental manner. Instead use "verify". 1165 - ISDs SHOULD NOT use this term to refer to proving the truth or 1166 accuracy of a fact or value such as a digital signature. 1167 Instead, use "verify". 1168 - ISDs SHOULD NOT use this term to refer to establishing the 1169 soundness or correctness of a construct, such as a digital 1170 certificate. Instead, use "validate". 1172 $ authentication 1173 (I) The process of verifying an identity claimed by or for a 1174 system entity. (See: authenticate, authentication exchange, 1175 authentication information, credential, data origin 1176 authentication, peer entity authentication, "relationship between 1177 data integrity service and authentication services" under "data 1178 integrity service", simple authentication, strong authentication, 1179 X.509.) 1181 Tutorial: An authentication process consists of two steps: 1182 - Identification step: Presenting an identifier to the security 1183 system. (Identifiers should be assigned carefully, because 1184 authenticated identities are the basis for other security 1185 services, such as access control service.) 1186 - Verification step: Presenting or generating authentication 1187 information that acts as evidence to prove the binding between 1188 the claimant and the identifier. (See: verification.) 1190 $ authentication code 1191 (D) Synonym for a checksum based on cryptography. (Compare: Data 1192 Authentication Code, Message Authentication Code.) 1194 Deprecated Term: ISDs SHOULD NOT use this uncapitalized term as a 1195 synonym for any kind of checksum, regardless of whether or not the 1196 checksum is cryptographic. Instead, use "checksum", "Data 1197 Authentication Code", "error detection code", "hash", "keyed 1198 hash", "Message Authentication Code", "protected checksum", or 1199 some other recomended term, depending on what is meant. 1201 The term mixes concepts in a potentially misleading way. The word 1202 "authentication" is misleading because the checksum may be used to 1203 perform a data integrity function rather than a data origin 1204 authentication function. 1206 $ authentication exchange 1207 1. (I) A mechanism to verify the identity of an entity by means of 1208 information exchange. 1210 2. (O) "A mechanism intended to ensure the identity of an entity 1211 by means of information exchange." [I7498-2] 1213 $ Authentication Header (AH) 1214 (I) An Internet protocol [R2402] designed to provide 1215 connectionless data integrity service and connectionless data 1216 origin authentication service for IP datagrams, and (optionally) 1217 to provide partial sequence integrity and protection against 1218 replay attacks. (See: IPsec. Compare: ESP.) 1220 Tutorial: Replay protection may be selected by the receiver when a 1221 security association is established. AH authenticates the upper- 1222 layer PDU that is carried as an IP SDU, and also authenticates as 1223 much of the IP PCI (i.e., the IP header) as possible. However, 1224 some IP header fields may change in transit, and the value of 1225 these fields, when the packet arrives at the receiver, may not be 1226 predictable by the sender. Thus, the values of such fields cannot 1227 be protected end-to-end by AH; protection of the IP header by AH 1228 is only partial when such fields are present. 1230 AH may be used alone, or in combination with the ESP, or in a 1231 nested fashion with tunneling. Security services can be provided 1232 between a pair of communicating hosts, between a pair of 1233 communicating security gateways, or between a host and a gateway. 1234 ESP can provide nearly the same security services as AH, and ESP 1235 can also provide data confidentiality service. The main difference 1236 between authentication services provided by ESP and AH is the 1237 extent of the coverage; ESP does not protect IP header fields 1238 unless they are encapsulated by AH. 1240 $ authentication information 1241 (I) Information used to verify an identity claimed by or for an 1242 entity. (See: authentication, credential, user. Compare: 1243 identification information.) 1245 Tutorial: Authentication information may exist as, or be derived 1246 from, one of the following: (a) Something the entity knows (see: 1247 password); (b) something the entity possesses (see: token); (c) 1248 something the entity is (see: biometric authentication). 1250 $ authentication service 1251 (I) A security service that verifies an identity claimed by or for 1252 an entity. (See: authentication.) 1254 Tutorial: In a network, there are two general forms of 1255 authentication service: data origin authentication service and 1256 peer entity authentication service. 1258 $ authenticity 1259 (I) The property of being genuine and able to be verified and be 1260 trusted. (See: authenticate, authentication, validate vs. verify.) 1262 $ authority 1263 (D) "An entity, responsible for the issuance of certificates." 1264 [X509] 1266 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 1267 attribute authority, certification authority, registration 1268 authority, or similar terms; the shortened form may cause 1269 confusion. Instead, use the full term at the first instance of 1270 usage and then, if it is necessary to shorten text, use AA, CA, 1271 RA, and other abbreviations defined in this Glossary. 1273 $ authority certificate 1274 (D) "A certificate issued to an authority (e.g. either to a 1275 certification authority or to an attribute authority)." [X509] 1276 (See: authority.) 1278 Deprecated Term: ISDs SHOULD NOT use this term as defined here; it 1279 is ambiguous. Instead, use the full term "certification authority 1280 certificate", "attribute authority certificate", "registration 1281 authority certificate", etc. at the first instance of usage and 1282 then, if it is necessary to shorten text, use AA, CA, RA, and 1283 other abbreviations defined in this Glossary. 1285 $ Authority Information Access extension 1286 (I) The private extension defined by PKIX for X.509 certificates 1287 to indicate "how to access CA information and services for the 1288 issuer of the certificate in which the extension appears. 1289 Information and services may include on-line validation services 1290 and CA policy data." [R3280] (See: private extension.) 1292 $ authorization 1293 1a. (I) An approval that is granted to a system entity to access a 1294 system resource. (Compare: permission, privilege.) 1296 Usage: Some synonyms are "permission" and "privilege". Specific 1297 terms are preferred in certain contexts: 1298 - /PKI/ "Authorization" SHOULD be used, to align with 1299 "certification authority" in the standard [X509]. 1300 - /role-based access control/ "Permission" SHOULD be used, to 1301 align with the standard [ANSI]. 1302 - /computer operating systems/ "Privilege" SHOULD be used, to 1303 align with the literature. (See: privileged process, privileged 1304 user.) 1306 Tutorial: The semantics and granularity of authorizations depend 1307 on the application and implementation (see: "first law" under 1308 "Courtney's laws"). An authorization may specify a particular 1309 access mode -- such as read, write, or execute -- for one or more 1310 system resources. 1312 1b. (I) A process for granting approval to a system entity to 1313 access a system resource. 1315 2. (O) /SET/ "The process by which a properly appointed person or 1316 persons grants permission to perform some action on behalf of an 1317 organization. This process assesses transaction risk, confirms 1318 that a given transaction does not raise the account holder's debt 1319 above the account's credit limit, and reserves the specified 1320 amount of credit. (When a merchant obtains authorization, payment 1321 for the authorized amount is guaranteed -- provided, of course, 1322 that the merchant followed the rules associated with the 1323 authorization process.)" [SET2] 1325 $ authorization credential 1326 (I) See: /access control/ under "credential". 1328 $ authorize 1329 (I) Grant an authorization to a system entity. 1331 $ authorized user 1332 (I) /access control/ A system entity that accesses a system 1333 resource for which the entity has received an authorization. 1334 (Compare: insider, outsider, unauthorized user.) 1336 Deprecated Usage: ISDs that use this term SHOULD state a 1337 definition for it because the term is used in many ways and could 1338 easily be misunderstood. 1340 $ automated information system 1341 See: information system. 1343 $ availability 1344 1. (I) The property of a system or a system resource being 1345 accessible, or usable or operational upon demand, by an authorized 1346 system entity, according to performance specifications for the 1347 system; i.e., a system is available if it provides services 1348 according to the system design whenever users request them. (See: 1349 critical, denial of service. Compare: precedence, reliability, 1350 survivability.) 1352 2. (O) "The property of being accessible and usable upon demand by 1353 an authorized entity." [I7498-2] 1355 Tutorial: Availability requirements can be specified by 1356 quantitative metrics, but sometimes are stated qualitatively, such 1357 as in the following: 1358 - "Flexible tolerance for delay" may mean that brief system 1359 outages do not endanger mission accomplishment, but extended 1360 outages may endanger the mission. 1361 - "Minimum tolerance for delay" may mean that mission 1362 accomplishment requires the system to provide requested 1363 services in a short time. 1365 $ availability service 1366 (I) A security service that protects a system to ensure its 1367 availability. 1369 Tutorial: This service addresses the security concerns raised by 1370 denial-of-service attacks. It depends on proper management and 1371 control of system resources, and thus depends on access control 1372 service and other security services. 1374 $ avoidance 1375 (I) See: secondary definition under "security". 1377 $ B1, B2, or B3 computer system 1378 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 1379 Evaluation Criteria". 1381 $ back door 1382 1. (I) /COMPUSEC/ A computer system feature -- which may be (a) an 1383 unintentional flaw, (b) a mechanism deliberately installed by the 1384 system's creator, or (c) a mechanism surreptitiously installed by 1385 an intruder -- that provides access to a system resource by other 1386 than the usual procedure and usually is hidden or otherwise not 1387 well-known. (See: maintenance hook. Compare: Trojan Horse.) 1389 Example: A way to access a computer other than through a normal 1390 login. Such an access path is not necessarily designed with 1391 malicious intent; operating systems sometimes are shipped by the 1392 manufacturer with hidden accounts intended for use by field 1393 service technicians or the vendor's maintenance programmers. 1395 2. (I) /cryptography/ A feature of a cryptographic system that 1396 makes it easily possible to break or circumvent the protection 1397 that the system is designed to provided. 1399 Example: A feature that makes it possible to decrypt cipher text 1400 much more quickly than by brute force cryptanalysis, without 1401 having prior knowledge of the decryption key. 1403 $ back up 1404 (I) /verb/ Create a reserve copy of data or, more generally, 1405 provide alternate means to perform system functions despite loss 1406 of system resources. (See: contingency plan. Compare: archive.) 1408 $ backup 1409 (I) /noun or adjective/ Refers to alternate means of performing 1410 system functions despite loss of system resources. (See: 1411 contingency plan). 1413 Example: A reserve copy of data, preferably one that is stored 1414 separately from the original, for use if the original becomes lost 1415 or damaged. (Compare: archive.) 1417 $ baggage 1418 (O) /SET/ An "opaque encrypted tuple, which is included in a SET 1419 message but appended as external data to the PKCS encapsulated 1420 data. This avoids superencryption of the previously encrypted 1421 tuple, but guarantees linkage with the PKCS portion of the 1422 message." [SET2] 1424 Deprecated Usage: ISDs SHOULD NOT use this term to describe a data 1425 element, except in the form "SET(trademark) baggage" with the 1426 meaning given above. 1428 $ baked-in security 1429 (I) The inclusion of security mechanisms in an information system 1430 beginning at an early point in the system's life cycle, i.e., 1431 during the design phase, or at least early in the implementation 1432 phase. (Compare: add-on security.) 1434 Deprecated Term: It is likely that other cultures use different 1435 metaphors for this concept. Therefore, to avoid international 1436 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 1437 Usage under "Green Book".) 1439 $ bandwidth 1440 (I) The total width of the frequency band that is available to or 1441 used by a communication channel; usually expressed in Hertz (Hz). 1442 (RFC 3753) (Compare: channel capacity.) 1444 $ bank identification number (BIN) 1445 1. (O) The digits of a credit card number that identify the 1446 issuing bank. (See: primary account number.) 1448 2. (O) /SET/ The first six digits of a primary account number. 1450 $ Basic Encoding Rules (BER) 1451 (I) A standard for representing ASN.1 data types as strings of 1452 octets. [X690] (See: Distinguished Encoding Rules.) 1454 Deprecated Usage: Sometimes incorrectly treated as part of ASN.1. 1455 However, ASN.1 properly refers only to a syntax description 1456 language, and not to the encoding rules for the language. 1458 $ Basic Security Option 1459 (I) See: secondary definition under "IPSO". 1461 $ bastion host 1462 (I) A strongly protected computer that is in a network protected 1463 by a firewall (or is part of a firewall) and is the only host (or 1464 one of only a few) in the network that can be directly accessed 1465 from networks on the other side of the firewall. (See: firewall.) 1467 Tutorial: Filtering routers in a firewall typically restrict 1468 traffic from the outside network to reaching just one host, the 1469 bastion host, which usually is part of the firewall. Since only 1470 this one host can be directly attacked, only this one host needs 1471 to be very strongly protected, so security can be maintained more 1472 easily and less expensively. However, to allow legitimate internal 1473 and external users to access application resources through the 1474 firewall, higher layer protocols and services need to be relayed 1475 and forwarded by the bastion host. Some services (e.g., DNS and 1476 SMTP) have forwarding built in; other services (e.g., TELNET and 1477 FTP) require a proxy server on the bastion host. 1479 $ BBN Technologies 1480 (O) The research-and-development company (originally called Bolt 1481 Baranek and Newman, Inc.) that built the ARPANET. 1483 $ BCA 1484 (O) See: brand certification authority. 1486 $ BCR 1487 (O) See: BLACK/Crypto/RED. 1489 $ BCI 1490 (O) See: brand CRL identifier. 1492 $ Bell-LaPadula model 1493 (N) A formal, mathematical, state-transition model of 1494 confidentiality policy for multilevel-secure computer systems 1495 [Bell]. (Compare: Biba model, Brewer-Nash model.) 1497 Tutorial: The model, devised by David Bell and Leonard LaPadula at 1498 The MITRE Corporation in 1973, characterizes computer system 1499 elements as subjects and objects. To determine whether or not a 1500 subject is authorized for a particular access mode on an object, 1501 the clearance of the subject is compared to the classification of 1502 the object. The model defines the notion of a "secure state", in 1503 which the only permitted access modes of subjects to objects are 1504 in accordance with a specified security policy. It is proven that 1505 each state transition preserves security by moving from secure 1506 state to secure state, thereby proving that the system is secure. 1507 In this model, a multilevel-secure system satisfies several rules, 1508 including the "confinement property" (a.k.a. the "*-property"), 1509 the "simple security property", and the "tranquillity property". 1511 $ benign 1512 1. (N) /COMSEC/ "Condition of cryptographic data [such] that [it] 1513 cannot be compromised by human access [to the data]." [C4009] 1515 2. (O) /COMPUSEC/ See: secondary definition under "trust". 1517 $ benign fill 1518 (N) Process by which keying material is generated, distributed, 1519 and placed into an ECU without exposure to any human or other 1520 system entity, except the cryptographic module that consumes and 1521 uses the material. (See: benign.) 1523 $ BER 1524 (I) See: Basic Encoding Rules. 1526 $ beyond A1 1527 1. (O) /formal/ A level of security assurance that is beyond the 1528 highest level (level A1) of criteria specified by the TCSEC. (See: 1529 Tutorial under "Trusted Computer System Evaluation Criteria".) 1531 2. (O) /informal/ A level of trust so high that it is beyond 1532 state-of-the-art technology; i.e., it cannot be provided or 1533 verified by currently available assurance methods, and especially 1534 not by currently available formal methods. 1536 $ Biba integrity 1537 (N) Synonym for "source integrity". 1539 $ Biba model 1540 (N) A formal, mathematical, state-transition model of integrity 1541 policy for multilevel-secure computer systems [Biba]. (See: source 1542 integrity. Compare: Bell-LaPadula model.) 1544 Tutorial: This model for integrity control is analogous to the 1545 Bell-LaPadula model for confidentiality control. Each subject and 1546 object is assigned an integrity level and, to determine whether or 1547 not a subject is authorized for a particular access mode on an 1548 object, the integrity level of the subject is compared to that of 1549 the object. The model prohibits the changing of information in an 1550 object by a subject with a lesser or incomparable level. The rules 1551 of the Biba model are duals of the corresponding rules in the 1552 Bell-LaPadula model. 1554 $ billet 1555 (N) A position or assignment that can be filled by one system 1556 entity at a time. [JCSP1] (Compare: principal, role, user.) 1558 Tutorial: In an organization, a "billet" is a populational 1559 position, of which there is exactly one instance; but a "role" is 1560 functional position, of which there can be multiple instances. 1561 System entities are in one-to-one relationships with their 1562 billets, but may be in many-to-one and one-to-many relationships 1563 with their roles. 1565 $ BIN 1566 (O) See: bank identification number. 1568 $ bind 1569 (I) To inseparably associate by applying some security mechanism. 1571 Example: A CA creates a public-key certificate by using a digital 1572 signature to bind together (a) a subject name, (b) a public key, 1573 and usually (c) some additional data items (e.g., see "X.509 1574 public-key certificate"). 1576 $ biometric authentication 1577 (I) A method of generating authentication information for a person 1578 by digitizing measurements of a physical or behavioral 1579 characteristic, such as a fingerprint, hand shape, retina pattern, 1580 voiceprint, handwriting style, or face. 1582 $ birthday attack 1583 (I) A class of attacks against cryptographic functions, including 1584 both encryption functions and hash functions. The attacks take 1585 advantage of a statistical property: Given a cryptographic 1586 function having an N-bit output, the probability is greater than 1587 1/2 that for 2**(N/2) randomly chosen inputs, the function will 1588 produce at least two outputs that are identical. (See: Tutorial 1589 under "hash function".) 1591 Derivation: From the somewhat surprising fact (often called the 1592 "birthday paradox") that although there are 365 days in a year, 1593 the probability is greater than 1/2 that two of more people share 1594 the same birthday in any randomly chosen group of 23 people. 1596 Birthday attacks enable an adversary to find two inputs for which 1597 a cryptographic function produces the same cipher text (or find 1598 two inputs for which a hash functions produces the same hash 1599 result) much faster than a brute force attack can; and a clever 1600 adversary can use such a capability to create considerable 1601 mischief. However, no birthday attack can enable an adversary to 1602 decrypt a given cipher text (or find a hash input that results in 1603 a given hash result) any faster than a brute force attack can. 1605 $ bit 1606 (I) A contraction of the term "binary digit"; the smallest unit of 1607 information storage, which has two possible states or values. The 1608 values usually are represented by the symbols "0" (zero) and "1" 1609 (one). (See: block, byte, word.) 1611 $ bit string 1612 (I) A sequence of bits, each of which is either "0" or "1". 1614 $ BLACK 1615 1. (I) Designation for data that consists only of cipher text, and 1616 for information system equipment items or facilities that handle 1617 only cipher text. Example: "BLACK key".(See: color change, 1618 RED/BLACK separation. Compare: RED.) 1620 2. (O) /U.S. Government/ "Designation applied to information 1621 systems, and to associated areas, circuits, components, and 1622 equipment, in which national security information is encrypted or 1623 is not processed." [C4009] 1625 $ BLACK/Crypto/RED (BCR) 1626 (N) An experimental, end-to-end, network packet encryption system 1627 developed in a working prototype form by BBN and the Collins Radio 1628 division of Rockwell Corporation in the 1975-1980 time frame for 1629 the U.S. DoD. BCR was the first network security system to support 1630 TCP/IP traffic, and it incorporated the first DES chips that were 1631 validated by the U.S. National Bureau of Standards (now called 1632 NIST). BCR also was the first to use a KDC and an ACC to manage 1633 connections. 1635 $ BLACK key 1636 (I) A key that is protected with a key-encrypting key and that 1637 must be decrypted before use. (See: BLACK. Compare: RED key.) 1639 $ BLACKER 1640 (O) An end-to-end encryption system for computer data networks 1641 that was developed by the U.S. DoD in the 1980s to provide host- 1642 to-host data confidentiality service for datagrams at OSIRM Layer 1643 3. [Weis] (Compare: Caneware, IPsec.) 1645 Tutorial: Each user host connects to its own bump-in-the-wire 1646 encryption device called a BLACKER Front End (BFE, TSEC/KI-111), 1647 through which the host connects to the subnetwork. The system also 1648 includes two types of centralized devices: one or more KDCs 1649 connect to the subnetwork and communicate with assigned sets of 1650 BFEs, and one or more ACCs connect to the subnetwork and 1651 communicate with assigned KDCs. BLACKER uses only symmetric 1652 encryption. A KDC distributes session keys to BFE pairs as 1653 authorized by an ACC. Each ACC maintains a database for a set of 1654 BFEs, and the database determines which pairs from that set (i.e., 1655 which pairs of user hosts behind the BFEs) are authorized to 1656 communicate and at what security levels. 1658 The BLACKER system is MLS in three ways: (a) The BFEs form a 1659 security perimeter around a subnetwork, separating user hosts from 1660 the subnetwork, so that the subnetwork can operate at a different 1661 security level (possibly a lower, less expensive level) than the 1662 hosts. (b) The BLACKER components are trusted to separate 1663 datagrams of different security levels, so that each datagram of a 1664 given security level can be received only by a host that is 1665 authorized for that security level; and thus BLACKER can separate 1666 host communities that operate at different security levels. (c) 1667 The host side of a BFE is itself MLS and can recognize a security 1668 label on each packet, so that an MLS user host can be authorized 1669 to successively transmit datagrams that are labeled with different 1670 security levels. 1672 $ blind attack 1673 (I) A type of network-based attack method that does not require 1674 the attacking entity to receive data traffic from the attacked 1675 entity; i.e., the attacker does not need to "see" data packets 1676 sent by the victim. Example: SYN flood. 1678 Tutorial: If an attack method is blind, the attacker's packets can 1679 carry (a) a false IP source address (making it difficult for the 1680 victim to find the attacker) and (b) a different address on every 1681 packet (making it difficult for the victim to block the attack). 1682 If the attacker needs to receive traffic from the victim, the 1683 attacker must either (c) reveal its own IP address to the victim 1684 (which enables the victim to find the attacker or block the attack 1685 by filtering) or (d) provide a false address and also subvert 1686 network routing mechanisms to divert the returning packets to the 1687 attacker (which makes the attack more complex, more difficult, or 1688 more expensive). [R3552] 1690 $ block 1691 (I) A bit string or bit vector of finite length. (See: bit, block 1692 cipher. Compare: byte, word.) 1694 Usage: An "N-bit block" contains N bits, which usually are 1695 numbered from left to right as 1, 2, 3, ..., N. 1697 $ block cipher 1698 (I) An encryption algorithm that breaks plain text into fixed-size 1699 segments and uses the same key to transform each plaintext segment 1700 into a fixed-size segment of cipher text. Examples: AES, Blowfish, 1701 DEA, IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream 1702 cipher.) 1704 Tutorial: A block cipher can be adapted to have a different 1705 external interface, such as that of a stream cipher, by using a 1706 mode of cryptographic operation to package the basic algorithm. 1707 (See: CBC, CFB, DEA, ECB, OFB.) 1709 $ Blowfish 1710 (N) A symmetric block cipher with variable-length key (32 to 448 1711 bits) designed in 1993 by Bruce Schneier as an unpatented, 1712 license-free, royalty-free replacement for DES or IDEA. [Schn] 1713 (See: Twofish.) 1715 $ brand 1716 1. (I) A distinctive mark or name that identifies a product or 1717 business entity. 1719 2. (O) /SET/ The name of a payment card. (See: BCA.) 1721 Tutorial: Financial institutions and other companies have founded 1722 payment card brands, protect and advertise the brands, establish 1723 and enforce rules for use and acceptance of their payment cards, 1724 and provide networks to interconnect the financial institutions. 1725 These brands combine the roles of issuer and acquirer in 1726 interactions with cardholders and merchants. [SET1] 1728 $ brand certification authority (BCA) 1729 (O) /SET/ A CA owned by a payment card brand, such as MasterCard, 1730 Visa, or American Express. [SET2] (See: certification hierarchy, 1731 SET.) 1733 $ brand CRL identifier (BCI) 1734 (O) /SET/ A digitally signed list, issued by a BCA, of the names 1735 of CAs for which CRLs need to be processed when verifying 1736 signatures in SET messages. [SET2] 1738 $ break 1739 (I) /cryptography/ To successfully perform cryptanalysis and thus 1740 succeed in decrypting data or performing some other cryptographic 1741 function, without initially having knowledge of the key that the 1742 function requires. (See: penetrate, strength.) 1744 Usage: This term applies to encrypted data or, more generally, to 1745 a cryptographic algorithm or cryptographic system. 1747 $ Brewer-Nash model 1748 (N) A security model [BN89] to enforce the Chinese wall policy. 1749 (Compare: Bell-LaPadula model, Clark-Wilson model.) 1751 Tutorial: All proprietary information in the set of commercial 1752 firms F(1), F(2), ..., F(N) is categorized into mutually exclusive 1753 conflict-of-interest classes I(1), I(2), ..., I(M) that apply 1754 across all firms. Each firm belongs to exactly one class. The 1755 Brewer-Nash model has the following mandatory rules: 1756 - Brewer-Nash Read Rule: Subject S can read information object O 1757 from firm F(i) only if either (a) O is from the same firm as 1758 some object previously read by S *or* (b) O belongs to a class 1759 I(i) from which S has not previously read any object. (See: 1760 object, subject.) 1761 - Brewer-Nash Write Rule: Subject S can write information object 1762 O to firm F(i) only if (a) S can read O by the Brewer-Nash Read 1763 Rule *and* (b) no object can be read by S from a different firm 1764 F(j), no matter whether F(j) belongs to the same class as F(i) 1765 or to a different class. 1767 $ bridge 1768 (I) A gateway for traffic flowing at OSIRM Layer 2 between two 1769 networks (usually two LANs). (Compare: bridge CA, router.) 1771 $ bridge CA 1772 (I) A PKI consisting of only a CA that cross-certifies with CAs of 1773 some other PKIs. (See: cross-certification. Compare: bridge.) 1775 Tutorial: A bridge CA functions as a hub that enables a 1776 certificate user in any of the PKIs that attach to the bridge, to 1777 validate certificates issued in the other attached PKIs. 1779 For example, a bridge CA (BCA) CA1 1780 could cross-certify with four ^ 1781 PKIs that have the roots CA1, | 1782 CA2, CA3, and CA4. The cross- v 1783 certificates that the roots CA2 <-> BCA <-> CA3 1784 exchange with the BCA enable an ^ 1785 end entity EE1 certified under | 1786 under CA1 in PK1 to construct v 1787 a certification path needed to CA4 1788 validate the certificate of 1789 end entity EE2 under CA2, CA1 -> BCA -> CA2 -> EE2 1790 or vice versa. CA2 -> BCA -> CA1 -> EE1 1792 $ British Standard 7799 1793 (N) Part 1 of the standard is a code of practice for how to secure 1794 an information system. Part 2 specifies the management framework, 1795 objectives, and control requirements for information security 1796 management systems. [BS7799] (See: ISO 17799.) 1798 $ browser 1799 (I) An client computer program that can retrieve and display 1800 information from servers on the World Wide Web. Examples: 1801 Netscape's Navigator and Microsoft's Internet Explorer. 1803 $ brute force 1804 (I) A cryptanalysis technique or other kind of attack method 1805 involving an exhaustive procedure that tries a large number of 1806 possible solutions to the problem, one-by-one. (See: impossible, 1807 strength, work factor.) 1809 Tutorial: In some cases, brute force involves trying all of the 1810 possibilities. For example, for cipher text where the analyst 1811 already knows the decryption algorithm, a brute force technique 1812 for finding matching plain text is to decrypt the message with 1813 every possible key. In other cases, brute force involves trying a 1814 large number of possibilities but substantially fewer than all of 1815 them. For example, given a hash function that produces a N-bit 1816 hash result, the probability is greater than 1/2 that the analyst 1817 will find two inputs that have the same hash result after trying 1818 only 2**(N/2) random chosen inputs. (See: birthday attack.) 1820 $ BS7799 1821 (N) See: British Standard 7799. 1823 $ buffer overflow 1824 (I) Any attack technique that exploits a vulnerability resulting 1825 from computer software or hardware that does not check for 1826 exceeding the bounds of a storage area when data is written into a 1827 sequence of storage locations beginning in that area. 1829 Tutorial: By causing a normal system operation to write data 1830 beyond the bounds of a storage area, the attacker seeks to either 1831 disrupt system operation or cause the system to execute malicious 1832 software inserted by the attacker. 1834 $ buffer zone 1835 (I) A neutral internetwork segment used to connect other segments 1836 that each operate under a different security policy. 1838 Tutorial: To connect a private network to the Internet or some 1839 other relatively public network, one could construct a small, 1840 separate, isolated LAN and connect it to both the private network 1841 and the public network; one or both of the connections would 1842 implement a firewall to limit the traffic that could pass through 1843 the buffer zone. 1845 $ bulk encryption 1846 (N) "Simultaneous encryption of all channels of a multichannel 1847 telecommunications link." [C4009] (Compare: bulk keying material.) 1849 $ bulk key 1850 (D) In a few published descriptions of hybrid encryption for SSH, 1851 Windows 2000, and other applications, this term refers to a 1852 symmetric key that (a) is used to encrypt a relatively large 1853 amount of data and (b) is itself encrypted with a public key. 1854 (Compare: bulk keying material.) 1856 Example: To send a large file to Bob, Alice (a) generates a 1857 symmetric key and uses it to encrypt the file (i.e., encrypt the 1858 bulk of the information that is to be sent) and then (b) encrypts 1859 that symmetric key (the "bulk key") with Bob's public key. 1861 Deprecated Term: ISDs SHOULD NOT use this term or definition; they 1862 are not well-established and could be confused with the 1863 established term "bulk keying material". Instead, use "symmetric 1864 key" and carefully explain how the key is applied. 1866 $ bulk keying material 1867 (N) Refers to handling keying material in large quantities, e.g., 1868 as a dataset that contains many items of keying material. (See: 1869 type 0. Compare: bulk key, bulk encryption.) 1871 $ bump-in-the-stack 1872 (I) An implementation approach that places a network security 1873 mechanism inside the system that is to be protected. (Compare: 1874 bump-in-the-wire.) 1876 Example: IPsec can be implemented inboard, in the protocol stack 1877 of an existing system or existing system design, by placing a new 1878 layer between the existing IP layer and the OSIRM Layer 3 drivers. 1879 Source code access for the existing stack is not required, but the 1880 system that contains the stack does need to be modified [R2401]. 1882 $ bump-in-the-wire 1883 (I) An implementation approach that places a network security 1884 mechanism outside of the system that is to be protected. (Compare: 1885 bump-in-the-stack.) 1887 Example: IPsec can be implemented outboard, in a physically 1888 separate device, so that the system that receives the IPsec 1889 protection does not need to be modified at all [R2401]. Military- 1890 grade link encryption has mainly been implemented as bump-in-the- 1891 wire devices. 1893 $ business-case analysis 1894 (N) An extended form of cost-benefit analysis that considers 1895 factors beyond financial metrics, including security factors such 1896 as the requirement for security services, their technical and 1897 programmatic feasibility, their qualitative benefits, and 1898 associated risks. (See: risk analysis.) 1900 $ byte 1901 (I) A fundamental unit of computer storage; the smallest 1902 addressable unit in a computer's architecture. Usually holds one 1903 character of information and, today, usually means eight bits. 1904 (Compare: octet.) 1906 Usage: Understood to be larger than a "bit", but smaller than a 1907 "word". Although "byte" almost always means "octet" today, some 1908 computer architectures have had bytes in other sizes (e.g., six 1909 bits, nine bits). Therefore, an STD SHOULD state the number of 1910 bits in a byte where the term is first used in the STD. 1912 $ C field 1913 (D) See: Compartments field. 1915 $ C1 or C2 computer system 1916 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 1917 Evaluation Criteria". 1919 $ CA 1920 (I) See: certification authority. 1922 $ CA certificate 1923 (D) "A [digital] certificate for one CA issued by another CA." 1924 [X509] 1926 Deprecated Definition: ISDs SHOULD NOT use the term with this 1927 definition; the definition is ambiguous with regard to how the 1928 certificate is constructed and how it is intended to be used. ISDs 1929 that use this term SHOULD provide a technical definition for it. 1930 (See: certificate profile.) 1932 Tutorial: There is no single, obvious choice for a technical 1933 definition of this term. Different PKIs can use different 1934 certificate profiles, and X.509 provides several choices of how to 1935 issue certificates to CAs. For example, one possible definition is 1936 the following: A v3 X.509 public-key certificate that has a 1937 "basicConstraints" extension containing a "cA" value of "TRUE". 1938 That would specifically indicate that "the certified public key 1939 may be used to verify certificate signatures", i.e., that the 1940 private key may be used by a CA. 1942 However, there also are other ways to indicate such usage. The 1943 certificate may have a "key Usage" extension that indicates the 1944 purposes for which the public key may be used, and one of the 1945 values that X.509 defines for that extension is "keyCertSign", to 1946 indicate that the certificate may be used for verifying a CA's 1947 signature on certificates. If "keyCertSign" is present in a 1948 certificate that also has a "basicConstraints" extension, than 1949 "cA" is set to "TRUE" in that extension. Alternatively, a CA could 1950 be issued a certificate in which "keyCertSign" is asserted without 1951 "basicConstraints" being present; and an entity that acts as a CA 1952 could be issued a certificate with "keyUsage" set to other values, 1953 either with or without "keyCertSign". 1955 $ CA domain 1956 (N) /PKI/ A security policy domain that "consists of a CA and its 1957 subjects [i.e., the entities named in the certificates issued by 1958 the CA]. Sometimes referred to as a PKI domain." [PAG] (See: 1959 domain.) 1961 $ Caesar cipher 1962 (I) A cipher that, given an alphabet of N characters, A(1), A(2), 1963 character A(i) by A(i+K, mod N) for some 0 one-to-many, <=> many-to-many. 6621 +- - - - - - - - - - - - - - - - - - - - - - - - - - + 6622 | PKI System | 6623 + - - - - + | +------------------+ +-------------------------+ | 6624 | User, | | |Subscriber, i.e., | | Identity of Subscriber | | 6625 |i.e., one| | | Registered User, | | is system-unique | | 6626 | of the | | | is system-unique | | +---------------------+ | | 6627 |following| | | +--------------+ | | | Subscriber | | | 6628 | | | | | User's core | | | | Identity's | | | 6629 | +-----+ |===| | Registration | |==>| | Registration data | | | 6630 | |human| | | | | data, i.e., | | | |+-------------------+| | | 6631 | |being| | | | | an entity's | | | || same core data || | | 6632 | +-----+ | | | |distinguishing|========|for all Identities || | | 6633 | or | | | | attribute | | | || of the same User || | | 6634 | +-----+ | | | | values | | +===|+-------------------+| | | 6635 | |auto-| | | | +--------------+ | | | +---------------------+ | | 6636 | |mated| | | +------------------+ | +------------|------------+ | 6637 | |pro- | | | | +=======+ | | 6638 | |cess | | | +-------v----|----------------------|------------+ | 6639 | +-----+ | | | +----------v---+ +------------v----------+ | | 6640 | or | | | |Authentication|<===>|Identifier of Identity | | | 6641 |+-------+| | | | Information | | is system-unique | | | 6642 || a set || | | +--------------+ +-----------------------+ | | 6643 || of || | | Identifier Credential that associates unit of | | 6644 || either|| | | Authentication Information with the Identifier | | 6645 |+-------+| | +------------------------------------------------+ | 6646 + - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - -+ 6648 $ identity-based security policy 6649 (I) "A security policy based on the identities and/or attributes 6650 of users, a group of users, or entities acting on behalf of the 6651 users and the resources/objects being accessed." [I7498-2] (See: 6652 rule-based security policy.) 6654 $ identity proofing 6655 (I) A process that vets and verifies the information that is used 6656 to establish the identity of a system entity. (See: registration.) 6658 $ IDS 6659 (I) See: intrusion detection system. 6661 $ IEEE 6662 (N) See: Institute of Electrical and Electronics Engineers, Inc. 6664 $ IEEE 802.10 6665 (N) An IEEE committee developing security standards for local area 6666 networks. (See: SILS.) 6668 $ IEEE P1363 6669 (N) An IEEE working group, Standard for Public-Key Cryptography, 6670 engaged in developing a comprehensive reference standard for 6671 asymmetric cryptography. Covers discrete logarithm (e.g., DSA), 6672 elliptic curve, and integer factorization (e.g., RSA); and covers 6673 key agreement, digital signature, and encryption. 6675 $ IESG 6676 (I) See: Internet Engineering Steering Group. 6678 $ IETF 6679 (I) See: Internet Engineering Task Force. 6681 $ IKE 6682 (I) See: IPsec Key Exchange. 6684 $ IMAP4 6685 (I) See: Internet Message Access Protocol, version 4. 6687 $ IMAP4 AUTHENTICATE 6688 (I) A IMAP4 command (better described as a transaction type, or 6689 subprotocol) by which an IMAP4 client optionally proposes a 6690 mechanism to an IMAP4 server to authenticate the client to the 6691 server and provide other security services. (See: POP3.) 6693 Tutorial: If the server accepts the proposal, the command is 6694 followed by performing a challenge-response authentication 6695 protocol and, optionally, negotiating a protection mechanism for 6696 subsequent POP3 interactions. The security mechanisms that are 6697 used by IMAP4 AUTHENTICATE -- including Kerberos, GSSAPI, and 6698 S/Key -- are described in [R1731]. 6700 $ impossible 6701 (O) Cannot be done in any reasonable amount of time. (See: break, 6702 brute force, strength, work factor.) 6704 $ in the clear 6705 (I) Not encrypted. (See: clear text.) 6707 $ Ina Jo 6708 (O) A methodology, language, and integrated set of software tools 6709 developed at the System Development Corporation for specifying, 6710 coding, and verifying software to produce correct and reliable 6711 programs. Usage: a.k.a. the Formal Development Methodology. [Cheh] 6713 $ incapacitation 6714 (I) A type of threat action that prevents or interrupts system 6715 operation by disabling a system component. (See: disruption.) 6717 Usage: This type includes the following subtypes: 6718 - "Malicious logic": In context of incapacitation, any hardware, 6719 firmware, or software (e.g., logic bomb) intentionally 6720 introduced into a system to destroy system functions or 6721 resources. (See: corruption, main entry for "malicious logic", 6722 masquerade, misuse.) 6723 - "Physical destruction": Deliberate destruction of a system 6724 component to interrupt or prevent system operation. 6725 - "Human error": In context of incapacitation, action or inaction 6726 that unintentionally disables a system component. (See: 6727 corruption, exposure.) 6728 - "Hardware or software error": In context of incapacitation, 6729 error that unintentionally causes failure of a system component 6730 and leads to disruption of system operation. (See: corruption, 6731 exposure.) 6732 - "Natural disaster": In context of incapacitation, any "act of 6733 God" (e.g., fire, flood, earthquake, lightning, or wind) that 6734 disables a system component. [FP031 section 2] 6736 $ incident 6737 See: security incident. 6739 $ INCITS 6740 (N) See: "International Committee for Information Technology 6741 Standardization" under "ANSI". 6743 $ indicator 6744 (N) An action -- either specific, generalized, or theoretical -- 6745 that an adversary might be expected to take in preparation for an 6746 attack. [C4009] (See: attack sensing, warning, and response.) 6748 $ indirect certificate revocation list (ICRL) 6749 (N) In X.509, a CRL that may contain certificate revocation 6750 notifications for certificates issued by CAs other than the issuer 6751 (i.e., signer) of the ICRL. 6753 $ indistinguishability 6754 (I) An attribute of an encryption algorithm that is a 6755 formalization of the notion that the encryption of some string is 6756 indistinguishable from the encryption of an equal-length string of 6757 nonsense. (Compare: semantic security.) 6759 $ inference 6760 1. (I) A type of threat action that reasons from characteristics 6761 or byproducts of communication and thereby indirectly accesses 6762 sensitive data, but not necessarily the data contained in the 6763 communication. (See: traffic analysis, signal analysis.) 6765 2. (I) A type of threat action that indirectly gains unauthorized 6766 access to sensitive information in a database management system by 6767 correlating query responses with information that is already 6768 known. 6770 $ inference control 6771 (I) Protection of data confidentiality against inference attack. 6772 (See: traffic-flow confidentiality.) 6774 Tutorial: A database management system containing N records about 6775 individuals may be required to provide statistical summaries about 6776 subsets of the population, while not revealing sensitive 6777 information about a single individual. An attacker may try to 6778 obtain sensitive information about an individual by isolating a 6779 desired record at the intersection of a set of overlapping 6780 queries. A system can attempt to prevent this by restricting the 6781 size and overlap of query sets, distorting responses by rounding 6782 or otherwise perturbing database values, and limiting queries to 6783 random samples. However, these techniques may be impractical to 6784 implement or use, and no technique is totally effective. For 6785 example, restricting the minimum size of a query set -- that is, 6786 not responding to queries for which there are fewer than K or more 6787 than N-K records that satisfy the query -- usually cannot prevent 6788 unauthorized disclosure. An attacker can pad small query sets with 6789 extra records, and then remove the effect of the extra records. 6790 The formula for identifying the extra records is called the 6791 "tracker". [Denns] 6793 $ INFOCON 6794 (O) See: information operations condition 6796 $ informal 6797 (N) Expressed in natural language. [CCIB] (Compare: formal, 6798 semiformal.) 6800 $ information 6801 (I) Facts and ideas, which can be represented (encoded) as various 6802 forms of data. 6804 $ information assurance 6805 (N) /U.S. Government/ "Measures that protect and defend 6806 information and information systems by ensuring their availability 6807 integrity, authentication, confidentiality, and non-repudiation. 6808 These measures include providing for restoration of information 6809 systems by incorporating protection, detection, and reaction 6810 capabilities." [C4009] 6812 $ Information Assurance Technical Framework (IATF) 6813 (O) A publicly available document [IATF], developed through a 6814 collaborative effort by organizations in the U.S. Government and 6815 industry, and issued by NSA. Intended for security managers and 6816 system security engineers as a tutorial and reference document 6817 about security problems in information systems and networks, to 6818 improve awareness of tradeoffs among available technology 6819 solutions and of desired characteristics of security approaches 6820 for particular problems. (See: ISO 17799, [SP14].) 6822 $ information domain 6823 (O) See: secondary definition under "domain". 6825 $ information domain security policy 6826 (O) See: secondary definition under "domain". 6828 $ information flow policy 6829 (N) /formal model/ A triple consisting of a set of security 6830 levels (or their equivalent security labels), a binary operator 6831 that maps each pair of security levels into a security level, and 6832 a binary relation on the set that selects a set of pairs of levels 6833 such that information is permitted to flow from an object of the 6834 first level to an object of the second level. (See: flow control, 6835 lattice model.) 6837 $ information operations condition (INFOCON) 6838 (O) /U.S. DoD/ A comprehensive defense posture and response based 6839 on the status of information systems, military operations, and 6840 intelligence assessments of adversary capabilities and intent. 6841 (See: threat) 6843 Derivation: From DEFCON, i.e., defense condition. 6845 Tutorial: The U.S. DoD defines five INFOCON levels: NORMAL (normal 6846 activity), ALPHA (increased risk of attack), BRAVO (specific risk 6847 of attack), CHARLIE (limited attack), and DELTA (general attack). 6849 $ information security (INFOSEC) 6850 (N) Measures that implement and assure security services in 6851 information systems, including in computer systems (see: COMPUSEC) 6852 and in communication systems (see: COMSEC). 6854 $ information system 6855 (I) An organized assembly of computing and communication resources 6856 and procedures -- i.e., equipment and services, together with 6857 their supporting infrastructure, facilities, and personnel -- that 6858 collect, record, process, store, transport, retrieve, display, 6859 disseminate, or dispose of information to accomplish a specified 6860 set of functions. (See: system entity, system resource.) 6862 $ Information Technology Security Evaluation Criteria (ITSEC) 6863 (N) A Standard [ITSEC] jointly developed by France, Germany, the 6864 Netherlands, and the United Kingdom for use in the European Union; 6865 accommodates a wider range of security assurance and functionality 6866 combinations than the TCSEC. Superseded by the Common Criteria. 6868 $ INFOSEC 6869 (I) See: information security. 6871 $ ingress filtering 6872 (I) A method [R2827] for countering attacks that use packets with 6873 false IP source addresses, by blocking such packets at the 6874 boundary between connected networks. 6876 Tutorial: Suppose network A of an internet service provider (ISP) 6877 includes a filtering router that is connected to customer network 6878 B, and an attacker in B at IP source address "foo" attempts to 6879 send packets with false source address "bar" into A. The false 6880 address may be either fixed or randomly changing, and it may 6881 either be unreachable or be a forged address that legitimately 6882 exists within either B or some other network C. In ingress 6883 filtering, the ISP's router blocks all inbound packet that arrive 6884 from B with a source address that is not within the range of 6885 legitimately advertised addresses for B. This method does not 6886 prevent all attacks that can originate from B, but the actual 6887 source of such attacks can be more easily traced because the 6888 originating network is known. 6890 $ initialization value (IV) 6891 (I) /cryptography/ An input parameter that sets the starting state 6892 of a cryptographic algorithm or mode. (Compare: activation data.) 6894 Usage: Sometimes called "initialization vector" or "message 6895 indicator", but ISDs SHOULD NOT use these synonyms because they 6896 mix concepts in potentially confusing ways. 6898 Tutorial: An IV can be used to synchronize one cryptographic 6899 process with another; e.g., CBC, CFB, and OFB use IVs. An IV also 6900 can be used to introduce cryptographic variance (see: salt) in 6901 addition to that provided by a key. 6903 $ initialization vector 6904 (D) /cryptographic function/ Synonym for "initialization value". 6906 Deprecated Term: For consistency, ISDs SHOULD NOT use this term in 6907 the context of cryptographic functions. 6909 $ insertion 6910 (I) /packet/ See: secondary definition under "stream integrity 6911 service". 6913 $ inside attack 6914 (I) See: secondary definition under "attack". Compare: insider. 6916 $ insider 6917 1. (I) A user (usually a person) that accesses a system from a 6918 position that is inside the system's security perimeter. (Compare: 6919 authorized user, outsider, unauthorized user.) 6921 Tutorial: An insider has been assigned a role that has more 6922 privileges to access system resources than do some other types of 6923 users, or can access those resources without being constrained by 6924 some access controls that are applied to outside users. For 6925 example, a salesclerk is an insider who has access to the cash 6926 register, but a store customer is an outsider. 6928 The actions performed by an insider in accessing the system may be 6929 either authorized or unauthorized; i.e., an insider may act either 6930 as an authorized user or as an unauthorized user. 6932 2. (O) A person with authorized physical access to the system. 6933 Example: In this sense, an office janitor is an insider, but a 6934 burglar or casual visitor is not. [NRC98] 6936 3. (O) A person with an organizational status that causes the 6937 system or members of the organization to view access requests as 6938 being authorized. Example: In this sense, a purchasing agent is an 6939 insider but a vendor is not. [NRC98] 6941 $ inspectable space 6942 (O) /EMSEC/ "Three-dimensional space surrounding equipment that 6943 process classified and/or sensitive information within which 6944 TEMPEST exploitation is not considered practical or where legal 6945 authority to identify and/or remove a potential TEMPEST 6946 exploitation exists." [C4009] 6948 $ Institute of Electrical and Electronics Engineers, Inc. (IEEE) 6949 (N) The IEEE is a not-for-profit association of approximately 6950 300,000 individual members in 150 countries. The IEEE produces 6951 nearly one third of the world's published literature in electrical 6952 engineering, computers, and control technology; holds hundreds of 6953 major, annual conferences; and maintains more than 800 active 6954 standards, with many more under development. (See: SILS.) 6956 $ integrity 6957 See: data integrity, datagram integrity service, correctness 6958 integrity, source integrity, stream integrity service, system 6959 integrity. 6961 $ integrity check 6962 (D) A computation that is part of a mechanism to provide data 6963 integrity service or data origin authentication service. (Compare: 6964 checksum.) 6965 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 6966 "cryptographic hash" or "protected checksum. This term 6967 unnecessarily duplicates the meaning of other, well-established 6968 terms; this term only mentions integrity, even though the intended 6969 service may be data origin authentication; and not every checksum 6970 is cryptographically protected. 6972 $ integrity label 6973 (I) A security label that tells the degree of confidence that may 6974 be placed in the data, and may also tell what countermeasures are 6975 required to be applied to protect the data against from alteration 6976 and destruction. (See: integrity. Compare: classification label.) 6978 $ intelligent threat 6979 (I) A circumstance in which an adversary has the technical and 6980 operational ability to detect and exploit a vulnerability and also 6981 has the demonstrated, presumed, or inferred intent to do so. (See: 6982 threat.) 6984 $ interception 6985 (I) A type of threat action whereby an unauthorized entity 6986 directly accesses sensitive data while the data is traveling 6987 between authorized sources and destinations. (See: unauthorized 6988 disclosure.) 6990 Usage: This type includes the following subtypes: 6991 - "Theft": Gaining access to sensitive data by stealing a 6992 shipment of a physical medium, such as a magnetic tape or disk, 6993 that holds the data. 6994 - "Wiretapping (passive)": Monitoring and recording data that is 6995 flowing between two points in a communication system. (See: 6996 wiretapping.) 6997 - "Emanations analysis": Gaining direct knowledge of communicated 6998 data by monitoring and resolving a signal that is emitted by a 6999 system and that contains the data but was not intended to 7000 communicate the data. (See: emanation.) 7002 $ interference 7003 (I) /threat action/ See: secondary definition under "obstruction". 7005 $ intermediate CA 7006 (D) The CA that issues a cross-certificate to another CA. [X509] 7007 (See: cross-certification.) 7009 Deprecated Term: ISDs SHOULD NOT use this term because it is not 7010 widely known and mixes concepts in a potentially misleading way. 7011 For example, suppose that end entity 1 ("EE1) is in one PKI 7012 ("PKI1"), end entity 2 ("EE2) is in another PKI ("PKI2"), and the 7013 root in PKI1 ("CA1") cross-certifies the root CA in PKI2 ("CA2"). 7014 Then if EE1 constructs the certification path CA1-to-CA2-to-EE2 to 7015 validate a certificate of EE2, conventional English usage would 7016 describe CA2 as being in the "intermediate" position in that path, 7017 not CA1. 7019 $ internal controls 7020 (I) /COMPUSEC/ Functions, features, and technical characteristics 7021 of computer hardware and software, especially of operating 7022 systems. Includes mechanisms to regulate the operation of a 7023 computer system with regard to access control, flow control, and 7024 inference control. (Compare: external controls.) 7026 $ International Data Encryption Algorithm (IDEA) 7027 (N) A patented, symmetric block cipher that uses a 128-bit key and 7028 operates on 64-bit blocks. [Schn] (See: symmetric cryptography.) 7030 $ International Standard 7031 (N) See: secondary definition under "ISO". 7033 $ International Traffic in Arms Regulations (ITAR) 7034 (O) Rules issued by the U.S. State Department, by authority of the 7035 Arms Export Control Act (22 U.S.C. 2778), to control export and 7036 import of defense articles and defense services, including 7037 information security systems, such as cryptographic systems, and 7038 TEMPEST suppression technology. (See: type 1 product, Wassenaar 7039 Arrangement.) 7041 $ internet, Internet 7042 1. (I) /not capitalized/ Abbreviation of "internetwork". 7044 2. (I) /capitalized/ The Internet is the single, interconnected, 7045 worldwide system of commercial, government, educational, and other 7046 computer networks that share (a) the protocol suite specified by 7047 the IAB (RFC 2026) and (b) the name and address spaces managed by 7048 the ICANN. (See: Internet Layer, Internet Protocol Suite.) 7050 Usage: Use with definite article "the" when using as a noun. E.g., 7051 say "My LAN is small, but the Internet is large." Don't say "My 7052 LAN is small, but Internet is large." 7054 $ Internet Architecture Board (IAB) 7055 (I) A technical advisory group of the ISOC, chartered by the ISOC 7056 Trustees to provide oversight of Internet architecture and 7057 protocols and, in the context of Internet Standards, a body to 7058 which decisions of the IESG may be appealed. Responsible for 7059 approving appointments to the IESG from among nominees submitted 7060 by the IETF nominating committee. (RFC 2026) 7062 $ Internet Assigned Numbers Authority (IANA) 7063 (I) From the early days of the Internet, the IANA was chartered by 7064 the ISOC and the U.S. Government's Federal Network Council to be 7065 the central coordination, allocation, and registration body for 7066 parameters for Internet protocols. Superseded by ICANN. 7068 $ Internet Control Message Protocol (ICMP) 7069 (I) An Internet Standard protocol (RFC 792) that is used to report 7070 error conditions during IP datagram processing and to exchange 7071 other information concerning the state of the IP network. 7073 $ Internet Corporation for Assigned Names and Numbers (ICANN) 7074 (I) The non-profit, private corporation that has assumed 7075 responsibility for the IP address space allocation, protocol 7076 parameter assignment, DNS management, and root server system 7077 management functions formerly performed under U.S. Government 7078 contract by IANA and other entities. 7080 Tutorial: The IPS, as defined by the IETF and the IESG, contains 7081 numerous parameters, such as internet addresses, domain names, 7082 autonomous system numbers, protocol numbers, port numbers, 7083 management information base OIDs, including private enterprise 7084 numbers, and many others. The Internet community requires that the 7085 values used in these parameter fields be assigned uniquely. ICANN 7086 makes those assignments as requested and maintains a registry of 7087 the current values. 7089 ICANN was formed in October 1998, by a coalition of the Internet's 7090 business, technical, and academic communities. The U.S. Government 7091 designated ICANN to serve as the global consensus entity with 7092 responsibility for coordinating four key functions for the 7093 Internet: allocation of IP address space, assignment of protocol 7094 parameters, management of the DNS, and management of the DNS root 7095 server system. 7097 $ Internet-Draft 7098 (I) A working document of the IETF, its areas, and its working 7099 groups. (RFC 2026) 7101 Usage: The term is customarily hyphenated when used either as a 7102 adjective or a noun, even though the latter is not standard 7103 English punctuation. 7105 Tutorial: An Internet-Draft is not an archival document like an 7106 RFC is. Instead, an Internet-Draft is a preliminary or working 7107 document that is valid for a maximum of six months and may be 7108 updated, replaced, or made obsolete by other documents at any 7109 time. It is inappropriate to use an Internet Draft as reference 7110 material or to cite it other than as "work in progress". Although 7111 most of the Internet-Drafts are produced by the IETF, any 7112 interested organization may request to have its working documents 7113 published as Internet-Drafts. 7115 $ Internet Engineering Steering Group (IESG) 7116 (I) The part of the ISOC responsible for technical management of 7117 IETF activities and administration of the Internet Standards 7118 Process according to procedures approved by the ISOC Trustees. 7119 Directly responsible for actions along the "standards track", 7120 including final approval of specifications as Internet Standards. 7121 Composed of IETF Area Directors and the IETF chairperson, who also 7122 chairs the IESG. (RFC 2026) 7124 $ Internet Engineering Task Force (IETF) 7125 (I) A self-organized group of people who make contributions to the 7126 development of Internet technology. The principal body engaged in 7127 developing Internet Standards, although not itself a part of the 7128 ISOC. Composed of Working Groups, which are arranged into Areas 7129 (such as the Security Area), each coordinated by one or more Area 7130 Directors. Nominations to the IAB and the IESG are made by a 7131 committee selected at random from regular IETF meeting attendees 7132 who have volunteered. (RFC 2026) [RFC 2323] 7134 $ Internet Layer 7135 (I) See: Internet Protocol Suite. 7137 $ Internet Message Access Protocol, version 4 (IMAP4) 7138 (I) An Internet protocol (RFC 2060) by which a client workstation 7139 can dynamically access a mailbox on a server host to manipulate 7140 and retrieve mail messages that the server has received and is 7141 holding for the client. (See: POP3.) 7143 Tutorial: IMAP4 has mechanisms for optionally authenticating a 7144 client to a server and providing other security services. (See: 7145 IMAP4 AUTHENTICATE.) 7147 $ Internet Open Trading Protocol (IOTP) 7148 (I) An Internet protocol (RFC 2801) proposed as a general 7149 framework for Internet commerce, able to encapsulate transactions 7150 of various proprietary payment systems (e.g., GeldKarte, Mondex, 7151 SET, VisaCash). Provides optional security services by 7152 incorporating various Internet security mechanisms (e.g., MD5) and 7153 protocols (e.g., TLS). 7155 $ Internet Policy Registration Authority (IPRA) 7156 (I) An X.509-compliant CA that is the top CA of the Internet 7157 certification hierarchy operated under the auspices of the ISOC 7158 [R1422]. (See: /PEM/ under "certification hierarchy".) 7160 $ Internet Private Line Interface (IPLI) 7161 (O) A successor to the PLI, updated to use TCP/IP and newer 7162 military-grade COMSEC equipment (TSEC/KG-84). The IPLI was a 7163 portable, modular system that was developed for use in tactical, 7164 packet-radio networks. 7166 $ Internet Protocol (IP) 7167 (I) A Internet Standard, Internet-Layer protocol that moves 7168 datagrams (discrete sets of bits) from one computer to another 7169 across an internetwork but does not provide reliable delivery, 7170 flow control, sequencing, or other end-to-end services that TCP 7171 provides. IP version 4 (IPv4) is specified in RFC 791, and IP 7172 version 6 (IPv6) is specified in RFC 2460. (See: IP address, 7173 TCP/IP.) 7175 Tutorial: If IP were used in an OSIRM stack, IP would be placed at 7176 the top of Layer 3, above other Layer 3 protocols in the stack. 7178 In any IPS stack, IP is always present in the Internet Layer and 7179 is always placed at the top of that layer, on top of any other 7180 protocols that are used in that layer. In some sense, IP is the 7181 only protocol specified for the IPS Internet Layer; other 7182 protocols used there, such as AH and ESP, are just IP variations. 7184 $ Internet Protocol security 7185 See: IP Security Protocol. 7187 $ Internet Protocol Security Option (IPSO) 7188 (I) Refers to one of three types of IP security options, which are 7189 fields that may be added to an IP datagram for the purpose of 7190 carrying security information about the datagram. (Compare: 7191 IPsec.) 7193 Deprecated Usage: ISDs SHOULD NOT use this term without a modifier 7194 to indicate which of the following three types is meant: 7195 - "DoD Basic Security Option" (IP option type 130): Defined for 7196 use on U.S. DoD common-use data networks. Identifies the DoD 7197 classification level at which the datagram is to be protected 7198 and the protection authorities whose rules apply to the 7199 datagram. (A "protection authority" is a National Access 7200 Program (e.g., GENSER, SIOP-ESI, SCI, NSA, Department of 7201 Energy) or Special Access Program that specifies protection 7202 rules for transmission and processing of the information 7203 contained in the datagram.) [R1108] 7204 - "DoD Extended Security Option" (IP option type 133): Permits 7205 additional security labeling information, beyond that present 7206 in the Basic Security Option, to be supplied in the datagram to 7207 meet the needs of registered authorities. [R1108] 7208 - "Common IP Security Option" (CIPSO) (IP option type 134): 7209 Designed by TSIG to carry hierarchic and non-hierarchic 7210 security labels. (Formerly called "Commercial IP Security 7211 Option"; a version 2.3 draft was published 9 March 1993 as an 7212 Internet-Draft but did not advance to RFC form.) [CIPSO] 7214 $ Internet Protocol Suite (IPS) 7215 (I) The set of network communication protocols that are specified 7216 by the IETF, and approved as Internet Standards by the IESG, 7217 within the oversight of the IAB. (See: OSIRM Security 7218 Architecture. Compare: OSIRM.) 7220 Usage: This set of protocols is popularly known as "TCP/IP" 7221 because TCP and IP are its most basic and important components. 7223 For clarity, this Glossary refers to IPS protocol layers by name 7224 and capitalizes those names, and refers to OSIRM protocol layers 7225 by number. 7227 Tutorial: The IPS does have architectural principles [R1958], but 7228 there is no Internet Standard that defines a layered IPS reference 7229 model like the OSIRM. Still, Internet community literature has 7230 referred (inconsistently) to IPS layers since early in the 7231 Internet's development [Padl]. 7233 This Glossary treats the IPS as having five protocol layers -- 7234 Application, Transport, Internet, Network Interface, and Network 7235 Hardware (or Network Substrate) -- which are illustrated in the 7236 following diagram: 7238 OSIRM Layers Examples IPS Layers Examples 7239 ------------------ --------------- --------------- -------------- 7240 Message Format: P2 [X420] Message Format: ARPA (RFC 822) 7241 +----------------+ +-------------+ 7242 |7.Application | P1 [X419] | Application | SMTP (RFC 821) 7243 +----------------+ - - - - - - | | 7244 |6.Presentatation| [I8823] | | 7245 +----------------+ - - - - - - | | 7246 |5.Session | [I8327] +-------------+ 7247 +----------------+ - - - - - - | Transport | TCP (RFC 793) 7248 |4.Transport | TP4 [I8073] | | 7249 +----------------+ - - - - - - +-------------+ 7250 |3.Network | CLNP [I8473] | Internet | IP (RFC 791) 7251 | | +-------------+ 7252 | | | Network | IP over IEEE 7253 +----------------+ - - - - - - | Interface | 802 (RFC 1042) 7254 |2.Data Link | +-------------+ 7255 | | LLC [I8802-2] - Network - The IPS does 7256 | | MAC [I8802-3] - Hardware - not include 7257 +----------------+ - (or Network - standards for 7258 |1.Physical | Baseband - Substrate) - this layer. 7259 +----------------+ Signaling [Stal] + - - - - - - + 7261 The diagram approximates how the five IPS layers align with the 7262 seven OSIRM layers, and it offers examples of protocol stacks that 7263 provide roughly equivalent electronic mail service over a private 7264 local area network that uses baseband signaling. 7266 - IPS Application Layer: The user runs an application program. 7267 The program selects the data transport service it needs -- 7268 either a sequence of data messages or a continuous stream of 7269 data -- and hands application data to the Transport Layer for 7270 delivery. 7272 - IPS Transport Layer: This layer divides application data into 7273 packets, adds a destination address to each, and communicates 7274 them end-to-end -- from one application program to another -- 7275 optionally regulating the flow and ensuring reliable (error- 7276 free and sequenced) delivery. 7278 - IPS Internet Layer: This layer carries transport packets in IP 7279 datagrams. It moves each datagram independently, from its 7280 source computer to its addressed destination computer, routing 7281 the datagram through a sequence of networks and relays and 7282 selecting appropriate network interfaces en route. 7284 - IPS Network Interface Layer: This layer accepts datagrams for 7285 transmission over a specific network. This layer specifies 7286 interface conventions for carrying IP over OSIRM Layer 3 7287 protocols and over Media Access Control sublayer protocols of 7288 OSIRM Layer 2. An example is IP over IEEE 802 (RFD 1042). 7290 - IPS Network Hardware Layer: This layer consists of specific, 7291 physical communication media. However, the IPS does not specify 7292 its own peer-to-peer protocols in this layer. Instead, the 7293 layering conventions specified by the Network Interface Layer 7294 use Layer 2 and Layer 3 protocols that are specified by bodies 7295 other than the IETF. That it, the IPS addresses *inter*-network 7296 functions and does not address *intra*-network functions. 7298 The two models are most dissimilar in the upper layers, where the 7299 IPS model does not include Session and Presentation layers. 7300 However, this omission causes fewer functional differences between 7301 the models than might be imagined, and the differences have 7302 relatively few security implications: 7304 - Formal separation of OSIRM Layers 5, 6, and 7 is not needed in 7305 implementations; the functions of these layers sometimes are 7306 mixed in a single software unit, even in protocols in the OSI 7307 suite. 7309 - Some OSIRM Layer 5 services -- for example, connection 7310 termination -- are built into TCP, and the remaining Layer 5 7311 and 6 functions are built into IPS Application-Layer protocols 7312 where needed. 7314 - The OSIRM does not place any security services in Layer 5 (see: 7315 OSIRM Security Architecture). 7317 - The lack of an explicit Presentation Layer in the IPS sometimes 7318 makes it simpler to implement security in IPS applications. For 7319 example, a primary function of Layer 6 is to convert data 7320 between internal and external forms, using a transfer syntax to 7321 unambiguously encode data for transmission. If an OSIRM 7322 application encrypts data to protect against disclosure during 7323 transmission, the transfer encoding must be done before the 7324 encryption. If an application does encryption, as is done in 7325 OSI message handling and directory service protocols, then 7326 Layer 6 functions must be replicated in Layer 7. [X400, X500]. 7328 The two models are most alike at the top of OSIRM Layer 3, where 7329 the OSI Connectionless Network Layer Protocol (CLNP) and the IPS 7330 IP are quite similar. Connection-oriented security services 7331 offered in OSIRM Layer 3 are inapplicable in the IPS, because the 7332 IPS Internet Layer lacks the explicit, connection-oriented service 7333 offered in the OSIRM. 7335 $ Internet Security Association and Key Management Protocol (ISAKMP) 7336 (I) An Internet IPsec protocol [R2408] to negotiate, establish, 7337 modify, and delete security associations, and to exchange key 7338 generation and authentication data, independent of the details of 7339 any specific key generation technique, key establishment protocol, 7340 encryption algorithm, or authentication mechanism. 7342 Tutorial: ISAKMP supports negotiation of security associations for 7343 protocols at all IPS layers. By centralizing management of 7344 security associations, ISAKMP reduces duplicated functionality 7345 within each protocol. ISAKMP can also reduce connection setup 7346 time, by negotiating a whole stack of services at once. Strong 7347 authentication is required on ISAKMP exchanges, and a digital 7348 signature algorithm based on asymmetric cryptography is used 7349 within ISAKMP's authentication component. 7351 ISAKMP negotiations are conducted in two "phases": 7352 - "Phase 1 negotiation". A phase 1 negotiation establishes a 7353 security association to be used by ISAKMP to protect its own 7354 protocol operations. 7355 - "Phase 2 negotiation". A phase 2 negotiation (which is 7356 protected by a security association that was established by a 7357 phase 1 negotiation) establishes a security association to be 7358 used to protect the operations of a protocol other than ISAKMP, 7359 such as ESP. 7361 $ Internet Society (ISOC) 7362 (I) A professional society concerned with Internet development 7363 (including technical Internet Standards); with how the Internet is 7364 and can be used; and with social, political, and technical issues 7365 that result. The ISOC Board of Trustees approves appointments to 7366 the IAB from among nominees submitted by the IETF nominating 7367 committee. (RFC 2026) 7369 $ Internet Standard 7370 (I) A specification, approved by the IESG and published as an RFC, 7371 that is stable and well-understood, is technically competent, has 7372 multiple, independent, and interoperable implementations with 7373 substantial operational experience, enjoys significant public 7374 support, and is recognizably useful in some or all parts of the 7375 Internet. (RFC 2026) (Compare: RFC.) 7377 Tutorial: The "Internet Standards Process" is an activity of the 7378 ISOC and is organized and managed by the IAB and the IESG. The 7379 process is concerned with all protocols, procedures, and 7380 conventions used in or by the Internet, whether or not they are 7381 part of the IPS. The "Internet Standards Track" has three levels 7382 of increasing maturity: Proposed Standard, Draft Standard, and 7383 Standard. (Compare: ISO, W3C.) 7385 $ Internet Standards document (ISD) 7386 (I) An RFC or an Internet-Draft that is produced as part of the 7387 Internet Standards Process (RFC 2026). (See: Internet Standard.) 7389 Deprecated Usage: ISDs that use this term SHOULD state a 7390 definition for it because neither the term nor the abbreviation is 7391 widely accepted. 7393 $ internetwork 7394 (I) A system of interconnected networks; a network of networks. 7395 Usually shortened to "internet". (See: internet, Internet.) 7397 Tutorial: An internet can be built using OSIRM Layer 3 gateways to 7398 implement connections between a set of similar subnetworks. With 7399 dissimilar subnetworks, i.e., subnetworks that differ in the Layer 7400 3 protocol service they offer, an internet can be built by 7401 implementing a uniform internetwork protocol (e.g., IP) that 7402 operates at the top of Layer 3 and hides the underlying 7403 subnetworks' heterogeneity from hosts that use communication 7404 services provided by the internet. (See: router.) 7406 $ intranet 7407 (I) A computer network, especially one based on Internet 7408 technology, that an organization uses for its own internal (and 7409 usually private) purposes and that is closed to outsiders. (See: 7410 extranet, virtual private network.) 7412 $ intruder 7413 (I) An entity that gains or attempts to gain access to a system or 7414 system resource without having authorization to do so. (See: 7415 intrusion. Compare: adversary, cracker.) 7417 $ intrusion 7418 1. (I) A security event, or a combination of multiple security 7419 events, that constitutes a security incident in which an intruder 7420 gains, or attempts to gain, access to a system or system resource 7421 without having authorization to do so. (See: IDS.) 7423 2. (I) A type of threat action whereby an unauthorized entity 7424 gains access to sensitive data by circumventing a system's 7425 security protections. (See: unauthorized disclosure.) 7427 Usage: This type includes the following subtypes: 7428 - "Trespass": Gaining physical access to sensitive data by 7429 circumventing a system's protections. 7430 - "Penetration": Gaining logical access to sensitive data by 7431 circumventing a system's protections. 7433 - "Reverse engineering": Acquiring sensitive data by 7434 disassembling and analyzing the design of a system component. 7435 - "Cryptanalysis": Transforming encrypted data into plain text 7436 without having prior knowledge of encryption parameters or 7437 processes. (See: main entry for "cryptanalysis".) 7439 $ intrusion detection 7440 (I) Sensing and analyzing system events for the purpose of 7441 noticing (i.e., becoming aware of) attempts to access system 7442 resources in an unauthorized manner. (See: anomaly detection, IDS, 7443 misuse detection.) [IDSAN, IDSSC, IDSSE, IDSSY] 7445 Usage: This includes the following subtypes: 7446 - "Active detection": Real-time or near-real-time analysis of 7447 system event data to detect current intrusions, which result in 7448 an immediate protective response. 7449 - "Passive detection": Off-line analysis of audit data to detect 7450 past intrusions, which are reported to the system security 7451 officer for corrective action. (Compare: security audit.) 7453 $ intrusion detection system (IDS) 7454 1. (N) A process or subsystem, implemented in software or 7455 hardware, that automates the tasks of (a) monitoring events that 7456 occur in a computer network and (b) analyzing them for signs of 7457 security problems. [SP31] (See: intrusion detection.) 7459 2. (N) A security alarm system to detect unauthorized entry. 7460 [DC6/9]. 7462 Tutorial: Active intrusion detection processes can be either host- 7463 based or network-based: 7464 - "Host-based": Intrusion detection components -- traffic sensors 7465 and analyzers -- run directly on the hosts that they are 7466 intended to protect. 7467 - "Network-based": Sensors are placed on subnetwork components, 7468 and analysis components run either on subnetwork components or 7469 hosts. 7471 $ invalidity date 7472 (N) An X.509 CRL entry extension that "indicates the date at which 7473 it is known or suspected that the [revoked certificate's private 7474 key] was compromised or that the certificate should otherwise be 7475 considered invalid." [X509]. 7477 Tutorial: This date may be earlier than the revocation date in the 7478 CRL entry, and may even be earlier than the date of issue of 7479 earlier CRLs. However, the invalidity date is not, by itself, 7480 sufficient for purposes of non-repudiation service. For example, 7481 to fraudulently repudiate a validly generated signature, a private 7482 key holder may falsely claim that the key was compromised at some 7483 time in the past. 7485 $ IOTP 7486 (I) See: Internet Open Trading Protocol. 7488 $ IP 7489 (I) See: Internet Protocol. 7491 $ IP address 7492 (I) A computer's internetwork address that is assigned for use by 7493 IP and other protocols. 7495 Tutorial: An IP version 4 address (RFC 791) has four 8-bit parts 7496 and is written as a series of four decimal numbers separated by 7497 periods. Example: The address of the host named "rosslyn.bbn.com" 7498 is 192.1.7.10. 7500 An IP version 6 address (RFC 2373) has eight 16-bit parts and is 7501 written as eight hexadecimal numbers separated by colons. 7502 Examples: 1080:0:0:0:8:800:200C:417A and 7503 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210. 7505 $ IP Security Option 7506 (I) See: Internet Protocol Security Option. 7508 $ IP Security Protocol (IPsec) 7509 1a. (I) The name of the IETF working group that is specifying an 7510 architecture [R2401] and set of protocols to provide security 7511 services for IP traffic. (See: AH, ESP, IKE, SAD, SPD. Compare: 7512 IPSO.) 7514 1b. (I) A collective name for the IP security architecture [R2401] 7515 and associated set of protocols (primarily AH, ESP, and IKE). 7517 Usage: In ISDs that use the abbreviation "IPsec", the letters "IP" 7518 SHOULD be in upper case, and the letters "sec" SHOULD NOT. 7520 Tutorial: The security services provided by IPsec include access 7521 control service, connectionless data integrity service, data 7522 origin authentication service, protection against replays 7523 (detection of the arrival of duplicate datagrams, within a 7524 constrained window), data confidentiality service, and limited 7525 traffic-flow confidentiality. IPsec specifies (a) security 7526 protocols (AH and ESP), (b) security associations (what they are, 7527 how they work, how they are managed, and associated processing), 7528 (c) key management (IKE), and (d) algorithms for authentication 7529 and encryption. Implementation of IPsec is optional for IP version 7530 4, but mandatory for IP version 6. 7532 $ IPLI 7533 (I) See: Internet Private Line Interface. 7535 $ IPRA 7536 (I) See: Internet Policy Registration Authority. 7538 $ IPS 7539 (I) See: Internet Protocol Suite. 7541 $ IPsec 7542 (I) See: IP Security Protocol. 7544 $ IPsec Key Exchange (IKE) 7545 (I) An Internet, IPsec, key-establishment protocol [R2409] for 7546 putting in place authenticated keying material (a) for use with 7547 ISAKMP and (b) for other security associations, such as in AH and 7548 ESP. 7550 Tutorial: IKE is based on three earlier protocol designs: ISAKMP, 7551 OAKLEY, and SKEME. 7553 $ IPSO 7554 (I) See: Internet Protocol Security Option. 7556 $ ISAKMP 7557 (I) See: Internet Security Association and Key Management 7558 Protocol. 7560 $ ISD 7561 (I) See: Internet Standards document. 7563 $ ISO 7564 (I) International Organization for Standardization, a voluntary, 7565 non-treaty, non-government organization, established in 1947, with 7566 voting members that are designated standards bodies of 7567 participating nations and non-voting observer organizations. 7568 (Compare: ANSI, IETF, ITU-T, W3C.) 7570 Tutorial: Legally, ISO is a Swiss, non-profit, private 7571 organization. ISO and the IEC (the International Electrotechnical 7572 Commission) form the specialized system for worldwide 7573 standardization. National bodies that are members of ISO or IEC 7574 participate in developing international standards through ISO and 7575 IEC technical committees that deal with particular fields of 7576 activity. Other international governmental and non-governmental 7577 organizations, in liaison with ISO and IEC, also take part. (ANSI 7578 is the U.S. voting member of ISO. ISO is a class D member of 7579 ITU-T.) 7581 The ISO standards development process has four levels of 7582 increasing maturity: Working Draft (WD), Committee Draft (CD), 7583 Draft International Standard (DIS), and International Standard 7584 (IS). (Compare: "Internet Standards Track" under "Internet 7585 Standard".) In information technology, ISO and IEC have a joint 7586 technical committee, ISO/IEC JTC 1. DISs adopted by JTC 1 are 7587 circulated to national bodies for voting, and publication as an IS 7588 requires approval by at least 75% of the national bodies casting a 7589 vote. 7591 $ ISO 17799 7592 (N) An International Standard that is a code of practice, derived 7593 from Part 1 of British Standard 7799, for managing the security of 7594 information systems in an organization. This standard does not 7595 provide definitive or specific material on any security topic. It 7596 provides general guidance on a wide variety of topics, but 7597 typically does not go into depth. (See: IATF, [SP14].) 7599 $ ISOC 7600 (I) See: Internet Society. 7602 $ issue 7603 (I) /PKI/ Generate and sign a digital certificate (or a CRL) and, 7604 usually, distribute it and make it available to potential 7605 certificate users (or CRL users). (See: certificate creation.) 7607 Usage: The term "issuing" is usually understood to refer not only 7608 to creating a digital certificate (or a CRL) but also to making it 7609 available to potential users, such as by storing it in a 7610 repository or other directory or otherwise publishing it. However, 7611 the ABA [DSG] explicitly limits this term to the creation process 7612 and excludes any related publishing or distribution process. 7614 $ issuer 7615 1. (I) /certificate, CRL/ The CA that signs a digital certificate 7616 or CRL. 7618 Tutorial: An X.509 certificate always includes the issuer's name. 7619 The name may include a common name value. 7621 2. (O) /payment card, SET/ "The financial institution or its agent 7622 that issues the unique primary account number to the cardholder 7623 for the payment card brand." [SET2] 7625 Tutorial: The institution that establishes the account for a 7626 cardholder and issues the payment card also guarantees payment for 7627 authorized transactions that use the card in accordance with card 7628 brand regulations and local legislation. [SET1] 7630 $ ITAR 7631 (O) See: International Traffic in Arms Regulations. 7633 $ ITSEC 7634 (N) See: Information Technology System Evaluation Criteria. 7636 $ ITU-T 7637 (N) International Telecommunications Union, Telecommunication 7638 Standardization Sector (formerly "CCITT"), a United Nations treaty 7639 organization that is composed mainly of postal, telephone, and 7640 telegraph authorities of the member countries and that publishes 7641 standards called "Recommendations". (See: X.400, X.500.) 7643 Tutorial: The Department of State represents the United States. 7644 ITU-T works on many kinds of communication systems. ITU-T 7645 cooperates with ISO on communication protocol standards, and many 7646 Recommendations in that area are also published as an ISO standard 7647 with an ISO name and number. 7649 $ IV 7650 (I) See: initialization value. 7652 $ jamming 7653 (I) An attack that attempts to interfere with the reception of 7654 broadcast communications. (See: anti-jam, denial of service. 7655 Compare: flooding.) 7657 Tutorial: Jamming uses "interference" as a type of "obstruction" 7658 intended to cause "disruption". Jamming a broadcast signal is 7659 typically done by broadcasting a second signal that receivers 7660 cannot separate from the first one. Jamming is mainly thought of 7661 in the context of wireless communication, but also can be done in 7662 some wired technologies, such as LANs that use contention 7663 techniques to share a broadcast medium. 7665 $ KAK 7666 (D) See: key-auto-key. (Compare: KEK.) 7668 $ KDC 7669 (I) See: Key Distribution Center. 7671 $ KEA 7672 (N) See: Key Exchange Algorithm. 7674 $ KEK 7675 (I) See: key-encrypting key. (Compare: KAK.) 7677 $ Kerberos 7678 (N) A system developed at the Massachusetts Institute of 7679 Technology that depends on passwords and symmetric cryptography 7680 (DES) to implement ticket-based, peer entity authentication 7681 service and access control service distributed in a client-server 7682 network environment. [R1510, Stei] 7684 Tutorial: Kerberos was developed by Project Athena and is named 7685 for the mythical three-headed dog that guards Hades. The system 7686 architecture includes servers that function as an ACC and a KDC. 7688 $ kernel 7689 (I) A small, trusted part of a system that provides services on 7690 which the other parts of the system depend. (See: security 7691 kernel.) 7693 $ Kernelized Secure Operating System (KSOS) 7694 (O) An MLS computer operating system, designed to be a provably 7695 secure replacement for UNIX Version 6, and consisting of a 7696 security kernel, non-kernel security-related utility programs, and 7697 optional UNIX application development and support environments. 7698 [Perr] 7700 Tutorial: KSOS-6 was the implementation on a SCOMP. KSOS-11 was 7701 the implementation by Ford Aerospace and Communications 7702 Corporation on the DEC PDP-11/45 and PDP-111/70 computers. 7704 $ key 7705 1a. (I) /cryptography/ An input parameter used to vary a 7706 transformation function performed by a cryptographic algorithm. 7707 (See: private key, public key, storage key, symmetric key, traffic 7708 key. Compare: initialization value.) 7710 1b. (O) /cryptography/ Used in singular form as a collective noun 7711 referring to keys or keying material. Example: A fill device can 7712 be used transfer key between two cryptographic devices. 7714 2. (I) /anti-jam/ An input parameter used to vary a process that 7715 determines patterns for an anti-jam measure. (See: frequency 7716 hopping, spread spectrum.) 7718 Tutorial: A key is usually specified as a sequence of bits or 7719 other symbols. If a key value needs to be kept secret, the 7720 sequence of symbols that comprise it should be random, or at least 7721 pseudorandom, because that makes the key harder for an adversary 7722 to guess. (See: brute force attack, cryptanalysis, strength.) 7724 $ key agreement (algorithm or protocol) 7725 1. (I) A key establishment method (especially one involving 7726 asymmetric cryptography) by which two or more entities, without 7727 prior arrangement except a public exchange of data (such as public 7728 keys), each can generate the same key value. That is, the method 7729 does not send a secret from one entity to the other; instead, both 7730 entities, without prior arrangement except a public exchange of 7731 data, can compute the same secret value, but that value cannot be 7732 computed by other, unauthorized entities. (See: Diffie-Hellman, 7733 key establishment, KEA, MQV. Compare: key transport.) 7735 2. (O) "A method for negotiating a key value on line without 7736 transferring the key, even in an encrypted form, e.g., the Diffie- 7737 Hellman technique." [X509] 7739 3. (O) "The procedure whereby two different parties generate 7740 shared symmetric keys such that any of the shared symmetric keys 7741 is a function of the information contributed by all legitimate 7742 participants, so that no party [alone] can predetermine the value 7743 of the key." [A9042] 7744 Example: A message originator and the intended recipient can each 7745 use their own private key and the other's public key with the 7746 Diffie-Hellman algorithm to first compute a shared secret value 7747 and, from that value, derive a session key to encrypt the message. 7749 $ key authentication 7750 (N) "The assurance of the legitimate participants in a key 7751 agreement [i.e., in a key-agreement protocol] that no non- 7752 legitimate party possesses the shared symmetric key." [A9042] 7754 $ key-auto-key (KAK) 7755 (D) "Cryptographic logic [i.e., a mode of operation] using 7756 previous key to produce key." [C4009, A1523] (See: CTAK, 7757 /cryptographic operation/ under "mode".) 7759 Deprecated Term: IDS SHOULD NOT use this term; it is neither well- 7760 known nor precisely defined. Instead, use terms associated with 7761 modes that are defined in standards, such as CBC, CFB, and OFB. 7763 $ key center 7764 (I) A centralized, key-distribution process (used in symmetric 7765 cryptography), usually a separate computer system, that uses 7766 master keys (i.e., KEKs) to encrypt and distribute session keys 7767 needed by a community of users. 7769 Tutorial: An ANSI standard [A9017] defines two types of key 7770 center: "key distribution center" and "key translation center". 7772 $ key confirmation 7773 (N) "The assurance [provided to] the legitimate participants in a 7774 key establishment protocol that the [parties that are intended to 7775 share] the symmetric key actually possess the shared symmetric 7776 key." [A9042] 7778 $ key distribution 7779 (I) A process that delivers a cryptographic key from the location 7780 where it is generated to the locations where it is used in a 7781 cryptographic algorithm. (See: key establishment, key management.) 7783 $ key distribution center (KDC) 7784 1. (I) A type of key center (used in symmetric cryptography) that 7785 implements a key-distribution protocol to provide keys (usually, 7786 session keys) to two (or more) entities that wish to communicate 7787 securely. (Compare: key translation center.) 7789 2. (N) "COMSEC facility generating and distributing key in 7790 electrical form." [C4009] 7792 Tutorial: A KDC distributes keys to Alice and Bob, who (a) wish to 7793 communicate with each other but do not currently share keys, (b) 7794 each share a KEK with the KDC, and (c) may not be able to generate 7795 or acquire keys by themselves. Alice requests the keys from the 7796 KDC. The KDC generates or acquires the keys and makes two 7797 identical sets. The KDC encrypts one set in the KEK it shares with 7798 Alice, and sends that encrypted set to Alice. The KDC encrypts the 7799 second set in the KEK it shares with Bob, and either (a) sends 7800 that encrypted set to Alice for her to forward to Bob or (b) sends 7801 it directly to Bob (although the latter option is not supported in 7802 the ANSI standard [A9017]). 7804 $ key encapsulation 7805 (N) A key recovery technique for storing knowledge of a 7806 cryptographic key by encrypting it with another key and ensuring 7807 that that only certain third parties called "recovery agents" can 7808 perform the decryption operation to retrieve the stored key. Key 7809 encapsulation typically permits direct retrieval of a secret key 7810 used to provide data confidentiality. (Compare: key escrow.) 7812 $ key-encrypting key (KEK) 7813 (I) A cryptographic key that (a) is used to encrypt other keys 7814 (either DEKs or other TEKs) for transmission or storage but (b) 7815 usually is not used to encrypt application data. Usage: Sometimes 7816 called "key-encryption key". 7818 $ key escrow 7819 (N) A key recovery technique for storing knowledge of a 7820 cryptographic key or parts thereof in the custody of one or more 7821 third parties called "escrow agents", so that the key can be 7822 recovered and used in specified circumstances. (Compare: key 7823 encapsulation.) 7825 Tutorial: Key escrow is typically implemented with split knowledge 7826 techniques. For example, the Escrowed Encryption Standard [FP185] 7827 entrusts two components of a device-unique split key to separate 7828 escrow agents. The agents provide the components only to someone 7829 legally authorized to conduct electronic surveillance of 7830 telecommunications encrypted by that specific device. The 7831 components are used to reconstruct the device-unique key, and it 7832 is used to obtain the session key needed to decrypt 7833 communications. 7835 $ key establishment (algorithm or protocol) 7836 1. (I) A procedure that combines the key generation and key- 7837 distribution steps needed to set up or install a secure 7838 communication association. 7840 2. (I) A procedure that results in keying material being shared 7841 among two or more system entities. [A9042, SP56] 7843 Tutorial: The two basic techniques for key establishment are "key 7844 agreement" and "key transport". 7846 $ Key Exchange Algorithm (KEA) 7847 (N) A key-agreement method [SKIP, R2773] that is based on the 7848 Diffie-Hellman algorithm and uses 1024-bit asymmetric keys. (See: 7849 CAPSTONE, CLIPPER, FORTEZZA, SKIPJACK.) 7851 Tutorial: KEA was developed by NSA and formerly classified at the 7852 U.S. DoD "Secret" level. On 23 June 1998, the NSA announced that 7853 KEA had been declassified. 7855 $ key generation 7856 (I) A process that creates the sequence of symbols that comprise a 7857 cryptographic key. (See: key management.) 7859 $ key generator 7860 1. (I) An algorithm that uses mathematical rules to 7861 deterministically produce a pseudorandom sequence of cryptographic 7862 key values. 7864 2. (I) An encryption device that incorporates a key generation 7865 mechanism and applies the key to plain text to produce cipher text 7866 (e.g., by exclusive OR-ing (a) a bit string representation of the 7867 key with (b) a bit string representation of the plaintext). 7869 $ key length 7870 (I) The number of symbols (usually stated as a number of bits) 7871 needed to be able to represent any of the possible values of a 7872 cryptographic key. (See: key space.) 7874 $ key lifetime 7875 1. (D) Synonym for "cryptoperiod". 7877 Deprecated Definition: ISDs SHOULD NOT use this term with 7878 definition 1 because a key's cryptoperiod may be only a part of 7879 the key's lifetime. A key could be generated at some time prior to 7880 when its cryptoperiod begins and might not be destroyed (i.e., 7881 zeroized) until some time after its cryptoperiod ends. 7883 2. (O) /MISSI/ An attribute of a MISSI key pair that specifies a 7884 time span that bounds the validity period of any MISSI X.509 7885 public-key certificate that contains the public component of the 7886 pair. (See: cryptoperiod.) 7888 $ key loader 7889 (N) Synonym for "fill device". 7891 $ key loading and initialization facility (KLIF) 7892 (N) A place where ECU hardware is activated after being 7893 fabricated. (Compare: CLEF.) 7895 Tutorial: Before going to its KLIF, an ECU is not ready to be 7896 fielded, usually because it is not yet able to receive DEKs. The 7897 KLIF employs trusted processes to complete the ECU by installing 7898 needed data such as KEKs, seed values, and, in some cases, 7899 cryptographic software. After KLIF processing, the ECU is ready 7900 for deployment. 7902 $ key management 7903 1a. (I) The process of handling keying material during its life 7904 cycle in a cryptographic system; and the supervision and control 7905 of that process. (See: key distribution, key escrow, keying 7906 material, public-key infrastructure.) 7908 Usage: Usually understood to include ordering, generating, 7909 storing, archiving, escrowing, distributing, loading, destroying, 7910 auditing, and accounting for the material. 7912 1b. (O) /NIST/ "The activities involving the handling of 7913 cryptographic keys and other related security parameters (e.g., 7914 IVs, counters) during the entire life cycle of the keys, including 7915 their generation, storage, distribution, entry and use, deletion 7916 or destruction, and archiving." [FP140, SP57] 7918 2. (O) /OSIRM/ "The generation, storage, distribution, deletion, 7919 archiving and application of keys in accordance with a security 7920 policy." [I7498-2] 7922 $ Key Management Protocol (KMP) 7923 (N) A protocol to establish a shared symmetric key between a pair 7924 (or a group) of users. (One version of KMP was developed by SDNS, 7925 and another by SILS.) Superseded by ISAKMP and IKE. 7927 $ key material 7928 (D) A synonym for "keying material". 7930 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 7931 "keying material". 7933 $ key pair 7934 (I) A set of mathematically related keys -- a public key and a 7935 private key -- that are used for asymmetric cryptography and are 7936 generated in a way that makes it computationally infeasible to 7937 derive the private key from knowledge of the public key. (See: 7938 Diffie-Hellman, RSA.) 7940 Tutorial: A key pair's owner discloses the public key to other 7941 system entities so they can use the key to (a) encrypt data, (b) 7942 verify a digital signature, or (c) generate a key with a key- 7943 agreement algorithm. The matching private key is kept secret by 7944 the owner, who uses it to (a') decrypt data, (b') generate a 7945 digital signature, or (c') generate a key with a key-agreement 7946 algorithm. 7948 $ key recovery 7949 1. (I) /cryptanalysis/ A process for learning the value of a 7950 cryptographic key that was previously used to perform some 7951 cryptographic operation. (See: cryptanalysis, recovery.) 7952 2. (I) /backup/ Techniques that provide an intentional, alternate, 7953 means to access the key used for data confidentiality service in 7954 an encrypted association. [DoD4] (Compare: recovery.) 7956 Tutorial: It is assumed that the cryptographic system includes a 7957 primary means of obtaining the key through a key establishment 7958 algorithm or protocol. For the secondary means, there are two 7959 classes of key recovery techniques: key encapsulation and key 7960 escrow. 7962 $ key space 7963 (I) The range of possible values of a cryptographic key; or the 7964 number of distinct transformations supported by a particular 7965 cryptographic algorithm. (See: key length.) 7967 $ key translation center 7968 (I) A type of key center that implements a key-distribution 7969 protocol (based on symmetric cryptography) to convey keys between 7970 two (or more) parties who wish to communicate securely. (Compare: 7971 key distribution center.) 7973 Tutorial: A key translation center transfers keys for future 7974 communication between Bob and Alice, who (a) wish to communicate 7975 with each other but do not currently share keys, (b) each share a 7976 KEK with the center, and (c) have the ability to generate or 7977 acquire keys by themselves. Alice generates or acquires a set of 7978 keys for communication with Bob. Alice encrypts the set in the KEK 7979 she shares with the center and sends the encrypted set to the 7980 center. The center decrypts the set, reencrypts the set in the KEK 7981 it shares with Bob, and either (a) sends that reencrypted set to 7982 Alice for her to forward to Bob or (b) sends it directly to Bob 7983 (although direct distribution is not supported in the ANSI 7984 standard [A9017]). 7986 $ key transport (algorithm or protocol) 7987 1. (I) A key establishment method by which a secret key is 7988 generated by a system entity in a communication association and 7989 securely sent to another entity in the association. (Compare: key 7990 agreement.) 7992 Tutorial: Either (a) one entity generates a secret key and 7993 securely sends it to the other entity, or (b) each entity 7994 generates a secret value and securely sends it to the other 7995 entity, where the two values are combined to form a secret key. 7996 For example, a message originator can generate a random session 7997 key and then use the RSA algorithm to encrypt that key with the 7998 public key of the intended recipient. 8000 2. (O) "The procedure to send a symmetric key from one party to 8001 other parties. As a result, all legitimate participants share a 8002 common symmetric key in such a way that the symmetric key is 8003 determined entirely by one party." [A9042] 8005 $ key update 8006 1. (I) Derive a new key from an existing key. (Compare: rekey.) 8008 2. (O) Irreversible cryptographic process that modifies a key to 8009 produce a new key. [C4009] 8011 $ key validation 8012 1. (I) "The procedure for the receiver of a public key to check 8013 that the key conforms to the arithmetic requirements for such a 8014 key in order to thwart certain types of attacks." [A9042] (See: 8015 weak key) 8017 2. (D) A synonym for "certificate validation". 8019 Deprecated Usage: ISDs SHOULD NOT use the term as a synonym for 8020 "certificate validation"; that would unnecessarily duplicate the 8021 meaning of the latter term and mix concepts in a potentially 8022 misleading way. In validating an X.509 public-key certificate, the 8023 public key contained in the certificate is normally treated as an 8024 opaque data object. 8026 $ keyed hash 8027 (I) A cryptographic hash (e.g., [R1828]) in which the mapping to a 8028 hash result is varied by a second input parameter that is a 8029 cryptographic key. (See: checksum.) 8031 Tutorial: If the input data object is changed, a new, 8032 corresponding hash result cannot be correctly computed without 8033 knowledge of the secret key. Thus, the secret key protects the 8034 hash result so it can be used as a checksum even when there is a 8035 threat of an active attack on the data. There are two basic types 8036 of keyed hash: 8037 - A function based on a keyed encryption algorithm. Example: Data 8038 Authentication Code. 8039 - A function based on a keyless hash that is enhanced by 8040 combining (e.g., by concatenating) the input data object 8041 parameter with a key parameter before mapping to the hash 8042 result. Example: HMAC. 8044 $ keying material 8045 (I) Data that is needed to establish and maintain a cryptographic 8046 security association, such as keys, key pairs, and IVs. 8048 (O) "Key, code, or authentication information in physical or 8049 magnetic form." [C4009] (Compare: COMSEC material.) 8051 $ keying material identifier (KMID) 8052 1. (I) An identifier assigned to an item of keying material. 8054 2. (O) /MISSI/ A 64-bit identifier that is assigned to a key pair 8055 when the public key is bound in a MISSI X.509 public-key 8056 certificate. 8058 $ Khafre 8059 (N) A patented, symmetric block cipher designed by Ralph C. Merkle 8060 as a plug-in replacement for DES. [Schn] 8062 Tutorial: Khafre was designed for efficient encryption of small 8063 amounts of data. However, because Khafre does not precompute 8064 tables used for encryption, it is slower than Khufu for large 8065 amounts of data. 8067 $ Khufu 8068 (N) A patented, symmetric block cipher designed by Ralph C. Merkle 8069 as a plug-in replacement for DES. [Schn] 8071 Tutorial: Khufu was designed for fast encryption of large amounts 8072 of data. However, because Khufu precomputes tables used in 8073 encryption, it is less efficient that Khafre for small amounts of 8074 data. 8076 $ KLIF 8077 (N) See: key loading and initialization facility. 8079 $ KMID 8080 (I) See: keying material identifier. 8082 $ known-plaintext attack 8083 (I) A cryptanalysis technique in which the analyst tries to 8084 determine the key from knowledge of some plaintext-ciphertext 8085 pairs (although the analyst may also have other clues, such as 8086 knowing the cryptographic algorithm). 8088 $ KSOS, KSOS-6, KSOS-11 8089 (O) See: Kernelized Secure Operating System. 8091 $ L2F 8092 (N) See: Layer 2 Forwarding Protocol. 8094 $ L2TP 8095 (N) See: Layer 2 Tunneling Protocol. 8097 $ label 8098 See: time stamp, security label. 8100 $ laboratory attack 8101 (O) "Use of sophisticated signal recovery equipment in a 8102 laboratory environment to recover information from data storage 8103 media." [C4009] 8105 $ LAN 8106 (I) local area network. 8108 $ land attack 8109 (I) A denial-of-service attack that sends an IP packet that (a) 8110 has the same address in both the Source Address and Destination 8111 Address fields and (b) contains a TCP SYN packet that has the same 8112 port number in both the Source Port and Destination Port fields. 8114 Derivation: This single-packet attack was named for "land", the 8115 program originally published by the cracker who invented this 8116 exploit. Perhaps that name was chosen because the inventor thought 8117 of multi-packet (i.e., flooding) attacks as arriving by "sea". 8119 $ Language of Temporal Ordering Specification (LOTOS) 8120 (N) A language (ISO 8807-1990) for formal specification of 8121 computer network protocols; describes the order in which events 8122 occur. 8124 $ lattice 8125 (I) A finite set together with a partial ordering on its elements 8126 such that for every pair of elements there is a least upper bound 8127 and a greatest lower bound. 8129 Example: A lattice is formed by a finite set S of security levels 8130 -- i.e., a set S of all ordered pairs (x,c), where x is one of a 8131 finite set X of hierarchically ordered classification levels X(1), 8132 non-hierarchical categories C(1), ..., C(M) -- together with the 8133 "dominate" relation. Security level (x,c) is said to "dominate" 8134 (x',c') if and only if (a) x is greater (higher) than or equal to 8135 x' and (b) c includes at least all of the elements of c'. (See: 8136 dominate, lattice model.) 8138 $ lattice model 8139 1. (I) A description of the semantic structure formed by a finite 8140 set of security levels, such as those used in military 8141 organizations. (See: dominate, lattice, security model.) 8143 2. (I) /formal model/ A model for flow control in a system, based 8144 on the lattice that is formed by the finite security levels in a 8145 system and their partial ordering. [Denn] 8147 $ Law Enforcement Access Field (LEAF) 8148 (N) A data item that is automatically embedded in data encrypted 8149 by devices (e.g., CLIPPER chip) that implement the Escrowed 8150 Encryption Standard. 8152 $ Layer 1, 2, 3, 4, 5, 6, 7 8153 (N) See: OSIRM. 8155 $ Layer 2 Forwarding Protocol (L2F) 8156 (N) An Internet protocol (originally developed by Cisco 8157 Corporation) that uses tunneling of PPP over IP to create a 8158 virtual extension of a dial-up link across a network, initiated by 8159 the dial-up server and transparent to the dial-up user. (See: 8160 L2TP.) 8162 $ Layer 2 Tunneling Protocol (L2TP) 8163 (N) An Internet client-server protocol that combines aspects of 8164 PPTP and L2F and supports tunneling of PPP over an IP network or 8165 over frame relay or other switched network. (See: virtual private 8166 network.) 8168 Tutorial: PPP can in turn encapsulate any OSIRM Layer 3 protocol. 8169 Thus, L2TP does not specify security services; it depends on 8170 protocols layered above and below it to provide any needed 8171 security. 8173 $ LDAP 8174 (I) See: Lightweight Directory Access Protocol. 8176 $ least common mechanism 8177 (I) The principle that a security architecture should minimize 8178 reliance on mechanisms that are shared by many users. 8180 Tutorial: Shared mechanisms may include cross-talk paths that 8181 permit a breach of data security, and it is difficult to make a 8182 single mechanism operate in a correct and trusted manner to the 8183 satisfaction of a wide range of users. 8185 $ least privilege 8186 (I) The principle that a security architecture should be designed 8187 so that each system entity is granted the minimum system resources 8188 and authorizations that the entity needs to do its work. (Compare: 8189 economy of mechanism, least trust.) 8191 Tutorial: This principle tends to limit damage that can be caused 8192 by an accident, error, or unauthorized act. This principle also 8193 tends to reduce complexity and promote modularity, which can make 8194 certification easier and more effective. This principle is similar 8195 to the principle of protocol layering, wherein each layer provides 8196 specific, limited communication services, and the functions in one 8197 layer are independent of those in other layers. 8199 $ least trust 8200 (I) The principle that a security architecture should be designed 8201 in a way that minimizes (a) the number of components that require 8202 trust and (b) the extent to which each component is trusted. 8203 (Compare: least privilege, trust level.) 8205 $ legacy system 8206 (I) A system that is in operation but will not be improved or 8207 expanded while a new system is being developed to supersede it. 8209 $ legal non-repudiation 8210 (I) See: secondary definition under "non-repudiation". 8212 $ level of concern 8213 (N) /U.S. DoD/ A rating assigned to an information system that 8214 indicates the extent to which protective measures, techniques, and 8215 procedures must be applied. (See: critical, sensitive, level of 8216 robustness.) 8218 $ level of robustness 8219 (N) /U.S. DoD/ A characterization of (a) the strength of a 8220 security function, mechanism, service, or solution and (b) the 8221 assurance (or confidence) that it is implemented and functioning. 8222 [Cons, IATF] (See: level of concern.) 8224 $ Lightweight Directory Access Protocol (LDAP) 8225 (I) An Internet client-server protocol (RFC 3377) that supports 8226 basic use of the X.500 Directory (or other directory servers) 8227 without incurring the resource requirements of the full Directory 8228 Access Protocol (DAP). 8230 Tutorial: Designed for simple management and browser applications 8231 that provide simple read/write interactive directory service. 8232 Supports both simple authentication and strong authentication of 8233 the client to the directory server. 8235 $ link 8236 1a. (I) A communication facility or physical medium that can 8237 sustain data communications between multiple network nodes, in the 8238 protocol layer immediately below IP. (RFC 3753) 8240 1b. (I) /subnetwork/ A communication channel connecting subnetwork 8241 relays (especially one between two packet switches) that is 8242 implemented at OSIRM Layer 2. (See: link encryption.) 8244 Tutorial: The relay computers assume that links are logically 8245 passive. If a computer at one end of a link sends a sequence of 8246 bits, the sequence simply arrives at the other end after a finite 8247 time, although some bits may have been changed either accidentally 8248 (errors) or by active wiretapping. 8250 2. (I) /World Wide Web/ See: hyperlink. 8252 $ link encryption 8253 (I) Stepwise (link-by-link) protection of data that flows between 8254 two points in a network, provided by encrypting data separately on 8255 each network link, i.e., by encrypting data when it leaves a host 8256 or subnetwork relay and decrypting when it arrives at the next 8257 host or relay. Each link may use a different key or even a 8258 different algorithm. [R1455] (Compare: end-to-end encryption.) 8260 $ liveness 8261 (I) A property of a communication association or a feature of a 8262 communication protocol that provides assurance to the recipient of 8263 data that the data is being freshly transmitted by its originator, 8264 i.e., that the data is not being replayed, by either the 8265 originator or a third party, from a previous transmission. (See: 8266 fresh, nonce, replay attack.) 8268 $ logic bomb 8269 (I) Malicious logic that activates when specified conditions are 8270 met. Usually intended to cause denial of service or otherwise 8271 damage system resources. (See: Trojan horse, virus, worm.) 8273 $ login 8274 (I) The act by which a system entity establishes a session in 8275 which the entity can use system resources. (See: principal, 8276 session.) 8278 Usage: Usually understood to be accomplished by providing a user 8279 name and password to an access control system that authenticates 8280 the user, but sometimes refers to establishing a connection with a 8281 server when no authentication or specific authorization is 8282 involved. 8284 Derivation: Refers to "log" file", a security audit trail that 8285 records (a) security events, such as the beginning of a session, 8286 and (b) the names of the system entities that initiate events. 8288 $ long title 8289 (O) /U.S. Government/ "Descriptive title of [an item of COMSEC 8290 material]." [C4009] (Compare: short title.) 8292 $ low probability of detection 8293 (I) Result of TRANSEC measures used to hide or disguise a 8294 communication. 8296 $ low probability of intercept 8297 (I) Result of TRANSEC measures used to prevent interception of a 8298 communication. 8300 $ LOTOS 8301 (N) See: Language of Temporal Ordering Specification. 8303 $ MAC 8304 (N) See: mandatory access control, Message Authentication Code. 8306 Deprecated Usage: ISDs that use this term SHOULD state a 8307 definition for it because this abbreviation is ambiguous. 8309 $ magnetic remanence 8310 (N) Magnetic representation of residual information remaining on a 8311 magnetic medium after the medium has been cleared. [NCS25] (See: 8312 clear, degauss, purge.) 8314 $ main mode 8315 (I) See: /IKE/ under "mode". 8317 $ maintenance hook 8318 (N) "Special instructions (trapdoors) in software allowing easy 8319 maintenance and additional feature development. Since maintenance 8320 hooks frequently allow entry into the code without the usual 8321 checks, they are a serious security risk if they are not removed 8322 prior to live implementation." [C4009] (See: back door.) 8324 $ malicious logic 8325 (I) Hardware, firmware, or software that is intentionally included 8326 or inserted in a system for a harmful purpose. (See: logic bomb, 8327 Trojan horse, spyware, virus, worm. Compare: secondary definitions 8328 under "corruption", "incapacitation", "masquerade", and "misuse".) 8330 $ malware 8331 (D) A contraction of "malicious software". (See: malicious logic.) 8333 Deprecated Term: ISDs SHOULD NOT use this term; it is not listed 8334 in most dictionaries and could confuse international readers. 8336 $ MAN 8337 (I) metropolitan area network. 8339 $ man-in-the-middle attack 8340 (I) A form of active wiretapping attack in which the attacker 8341 intercepts and selectively modifies communicated data in order to 8342 masquerade as one or more of the entities involved in a 8343 communication association. (See: hijack attack, piggyback attack.) 8345 Tutorial: For example, suppose Alice and Bob try to establish a 8346 session key by using the Diffie-Hellman algorithm without data 8347 origin authentication service. A "man in the middle" could (a) 8348 block direct communication between Alice and Bob and then (b) 8349 masquerade as Alice sending data to Bob, (c) masquerade as Bob 8350 sending data to Alice, (d) establish separate session keys with 8351 each of them, and (e) function as a clandestine proxy server 8352 between them in order to capture or modify sensitive information 8353 that Alice and Bob think they are sending only to each other. 8355 $ manager 8356 (I) A person who controls the service configuration of a system or 8357 the functional privileges of operators and other users. 8359 $ mandatory access control 8360 1. (I) An access control service that enforces a security policy 8361 based on comparing (a) security labels, which indicate how 8362 sensitive or critical system resources are, with (b) security 8363 clearances, which indicate that system entities are eligible to 8364 access certain resources. (See: discretionary access control, MAC, 8365 rule-based security policy.) 8366 Derivation: This kind of access control is called "mandatory" 8367 because an entity that has clearance to access a resource is not 8368 permitted, just by its own volition, to enable another entity to 8369 access that resource. 8371 2. (O) "A means of restricting access to objects based on the 8372 sensitivity (as represented by a label) of the information 8373 contained in the objects and the formal authorization (i.e., 8374 clearance) of subjects to access information of such sensitivity." 8375 [DoD1] 8377 $ manipulation detection code 8378 (D) Synonym for "checksum". 8380 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 8381 "checksum"; the word "manipulation" implies protection against 8382 active attacks, which an ordinary checksum might not provide. 8383 Instead, if such protection is intended, use "protected checksum" 8384 or some particular type thereof, depending on which is meant. If 8385 such protection is not intended, use "error detection code" or 8386 some specific type of checksum that is not protected. 8388 $ marking 8389 See: time stamp, security marking. 8391 $ MARS 8392 (O) A symmetric, 128-bit block cipher with variable key length 8393 (128 to 448 bits), developed by IBM as a candidate for the AES. 8395 $ Martian 8396 (D) /slang/ A packet that arrives unexpectedly at the wrong 8397 address or on the wrong network because of incorrect routing or 8398 because it has a non-registered or ill-formed IP address. [R1208] 8400 Deprecated Term: It is likely that other cultures use different 8401 metaphors for this concept. Therefore, to avoid international 8402 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 8403 Usage under "Green Book".) 8405 $ masquerade 8406 (I) A type of threat action whereby an unauthorized entity gains 8407 access to a system or performs a malicious act by illegitimately 8408 posing as an authorized entity. (See: deception.) 8410 Usage: This type includes the following subtypes: 8411 - "Spoof": Attempt by an unauthorized entity to gain access to a 8412 system by posing as an authorized user. 8413 - "Malicious logic": In context of masquerade, any hardware, 8414 firmware, or software (e.g., Trojan horse) that appears to 8415 perform a useful or desirable function, but actually gains 8416 unauthorized access to system resources or tricks a user into 8417 executing other malicious logic. (See: corruption, 8418 incapacitation, main entry for "malicious logic", misuse.) 8420 $ MCA 8421 (O) See: merchant certification authority. 8423 $ MD2 8424 (N) A cryptographic hash [R1319] that produces a 128-bit hash 8425 result, was designed by Ron Rivest, and is similar to MD4 and MD5 8426 but slower. 8428 Derivation: Apparently an abbreviation of "message digest", but 8429 that term is deprecated by this Glossary. 8431 $ MD4 8432 (N) A cryptographic hash [R1320] that produces a 128-bit hash 8433 result and was designed by Ron Rivest. (See: Derivation under 8434 "MD2", SHA-1.) 8436 $ MD5 8437 (N) A cryptographic hash [R1321] that produces a 128-bit hash 8438 result and was designed by Ron Rivest to be an improved version of 8439 MD4. (See: Derivation under "MD2".) 8441 $ merchant 8442 (O) /SET/ "A seller of goods, services, and/or other information 8443 who accepts payment for these items electronically." [SET2] A 8444 merchant may also provide electronic selling services and/or 8445 electronic delivery of items for sale. With SET, the merchant can 8446 offer its cardholders secure electronic interactions, but a 8447 merchant that accepts payment cards is required to have a 8448 relationship with an acquirer. [SET1, SET2] 8450 $ merchant certificate 8451 (O) /SET/ A public-key certificate issued to a merchant. Sometimes 8452 used to refer to a pair of such certificates where one is for 8453 digital signature use and the other is for encryption. 8455 $ merchant certification authority (MCA) 8456 (O) /SET/ A CA that issues digital certificates to merchants and 8457 is operated on behalf of a payment card brand, an acquirer, or 8458 another party according to brand rules. Acquirers verify and 8459 approve requests for merchant certificates prior to issuance by 8460 the MCA. An MCA does not issue a CRL, but does distribute CRLs 8461 issued by root CAs, brand CAs, geopolitical CAs, and payment 8462 gateway CAs. [SET2] 8464 $ mesh PKI 8465 (I) A non-hierarchical PKI architecture in which there are several 8466 trusted CAs rather than a single root. Each certificate user bases 8467 path validations on the public key of one of the trusted CAs, 8468 usually the one that issued that user's own public-key 8469 certificate. Rather than having superior-to-subordinate 8470 relationships between CAs, the relationships are peer-to-peer, and 8471 CAs issue cross-certificates to each other. (Compare: hierarchical 8472 PKI, trust-file PKI.) 8474 $ Message Authentication Code, message authentication code 8475 (N) /capitalized/ A specific ANSI standard for a checksum that is 8476 computed with a keyed hash that is based on DES. [A9009] Usage: 8477 a.k.a. Data Authentication Code, which is a U.S. Government 8478 standard. [FP113] (See: MAC.) 8480 (D) /not capitalized/ Synonym for "error detection code". 8482 Deprecated Term: ISDs SHOULD NOT use the uncapitalized form 8483 "message authentication code". Instead, use "checksum", "error 8484 detection code", "hash", "keyed hash", "Message Authentication 8485 Code", or "protected checksum", depending on what is meant. (See: 8486 authentication code.) 8488 The uncapitalized form mixes concepts in a potentially misleading 8489 way. The word "message" is misleading because it implies that the 8490 mechanism is particularly suitable for or limited to electronic 8491 mail (see: Message Handling Systems). The word "authentication" is 8492 misleading because the mechanism primarily serves a data integrity 8493 function rather than an authentication function. The word "code" 8494 is misleading because it implies that either encoding or 8495 encryption is involved or that the term refers to computer 8496 software. 8498 $ message digest 8499 (D) Synonym for "hash result". (See: cryptographic hash.) 8501 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 8502 "hash result"; the term unnecessarily duplicates the meaning of 8503 the other, more general term and mixes concepts in a potentially 8504 misleading way. The word "message" is misleading because it 8505 implies that the mechanism is particularly suitable for or limited 8506 to electronic mail (see: Message Handling Systems). 8508 $ message handling system 8509 (D) A synonym for the Internet electronic mail system. 8511 Deprecated Term: ISDs SHOULD NOT use this term, because it could 8512 be confused with Message Handling System. Instead, use "Internet 8513 electronic mail" or some other, more specific term. 8515 $ Message Handling System 8516 (O) A ITU-T system concept that encompasses the notion of 8517 electronic mail but defines more comprehensive OSI systems and 8518 services that enable users to exchange messages on a store-and- 8519 forward basis. (The ISO equivalent is "Message Oriented Text 8520 Interchange System".) (See: X.400.) 8522 $ message indicator 8523 1. (D) /cryptographic function/ Synonym for "initialization 8524 value". 8526 2. (D) "Sequence of bits transmitted over a communications system 8527 for synchronizing cryptographic equipment." [C4009] 8529 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 8530 "initialization value"; the term mixes concepts in a potentially 8531 misleading way. The word "message" is misleading because it 8532 suggests that the mechanism is limited to electronic mail. (See: 8533 Message Handling System.) 8535 $ message integrity check 8536 $ message integrity code (MIC) 8537 (D) Synonyms for some form of "checksum". 8539 Deprecated Term: ISDs SHOULD NOT use these terms for any form of 8540 checksum. Instead, use "checksum", "error detection code", "hash", 8541 "keyed hash", "Message Authentication Code", or "protected 8542 checksum", depending on what is meant. 8544 These two terms mix concepts in potentially misleading ways. The 8545 word "message" is misleading because it suggests that the 8546 mechanism is particularly suitable for or limited to electronic 8547 mail. The word "integrity" is misleading because the checksum may 8548 be used to perform a data origin authentication function rather 8549 than an integrity function. The word "code" is misleading because 8550 it suggests either that either encoding or encryption is involved 8551 or that the term refers to computer software. 8553 $ Message Security Protocol (MSP) 8554 (N) A secure message handling protocol [SDNS7] for use with X.400 8555 and Internet mail protocols. Developed by NSA's SDNS program and 8556 used in the U.S. DoD's Defense Message System. 8558 $ meta-data 8559 (I) Descriptive information about a data object; i.e., data about 8560 data, or data labels that describe other data. (See: security 8561 label. Compare: metadata) 8563 Tutorial: Meta-data can serve various management purposes: 8564 - System management: File name, type, size, creation date. 8565 - Application management: Document title, version, author. 8566 - Usage management: Data categories, keywords, classifications. 8568 Meta-data can be associated with a data object in two basic ways: 8569 - Explicitly: Be part of the data object (e.g., a header field of 8570 a data file or packet) or be linked to the object. 8571 - Implicitly: Be associated with the data object because of some 8572 other, explicit attribute of the object. 8574 $ metadata, Metadata(trademark), METADATA(trademark) 8575 (D) Proprietary variants of "meta-data". (See: SPAM(trademark).) 8577 Deprecated Terms: ISDs SHOULD NOT use these unhypenated forms; 8578 ISDs SHOULD use only the uncapitalized, hyphenated "meta-data". 8579 The terms "Metadata" and "METADATA" are claimed as registered 8580 trademarks (numbers 1,409,260 and 2,185,504) owned by The Metadata 8581 Company, originally known as Metadata Information Partners, a 8582 company founded by Jack Myers. The status of "metadata" is 8583 unclear. 8585 $ MHS 8586 (N) See: message handling system. 8588 $ MIC 8589 (D) See: message integrity code. 8591 $ MIME 8592 (I) See: Multipurpose Internet Mail Extensions. 8594 $ MIME Object Security Services (MOSS) 8595 (I) An Internet protocol [R1848] that applies end-to-end 8596 encryption and digital signature to MIME message content, using 8597 symmetric cryptography for encryption and asymmetric cryptography 8598 for key distribution and signature. MOSS is based on features and 8599 specifications of PEM. (See: S/MIME.) 8601 $ Minimum Interoperability Specification for PKI Components (MISPC) 8602 (N) A technical description to provide a basis for interoperation 8603 between PKI components from different vendors; consists primarily 8604 of a profile of certificate and CRL extensions and a set of 8605 transactions for PKI operation. [SP15] 8607 $ misappropriation 8608 (I) A type of threat action whereby an entity assumes unauthorized 8609 logical or physical control of a system resource. (See: 8610 usurpation.) 8612 Usage: This type includes the following subtypes: 8613 - Theft of data: Unauthorized acquisition and use of data 8614 contained in a system. 8615 - Theft of service: Unauthorized use of a system service. 8616 - Theft of functionality: Unauthorized acquisition of actual 8617 hardware, firmware, or software of a system component. 8619 $ MISPC 8620 (N) See: Minimum Interoperability Specification for PKI 8621 Components. 8623 $ MISSI 8624 (O) Multilevel Information System Security Initiative, an NSA 8625 program to encourage development of interoperable, modular 8626 products for constructing secure network information systems in 8627 support of a wide variety of Government missions. (See: MSP, SP3, 8628 SP4.) 8630 $ MISSI user 8631 (O) /MISSI/ A system entity that is the subject of one or more 8632 MISSI X.509 public-key certificates issued under a MISSI 8633 certification hierarchy. (See: personality.) 8635 Tutorial: MISSI users include both end users and the authorities 8636 that issue certificates. A MISSI user is usually a person but may 8637 be a machine or other automated process. Machines that are 8638 required to operate non-stop may be issued their own certificates 8639 to avoid downtime needed to exchange the FORTEZZA cards of machine 8640 operators at shift changes. 8642 $ mission 8643 (I) A statement of a (relatively long-term) duty or (relatively 8644 short-term) task that is assigned to an organization or system, 8645 indicates the purpose and objectives of the duty or task, and may 8646 indicate the actions to be taken to achieve it. 8648 $ mission critical 8649 (I) A condition of a system service or other system resource such 8650 that denial of access to, or lack of availability of, the resource 8651 would jeopardize a system user's ability to perform a primary 8652 mission function or would result in other serious consequences. 8653 (See: Critical. Compare: mission essential.) 8655 $ mission essential 8656 (O) /U.S. DoD/ Refers to materiel that is authorized and available 8657 to combat, combat support, combat service support, and combat 8658 readiness training forces to accomplish their assigned missions. 8659 [JCSP1] (Compare: mission critical.) 8661 $ misuse 8662 1. (I) The intentional use (by authorized users) of system 8663 resources for other than authorized purposes. Example: An 8664 authorized system administrator creates an unauthorized account 8665 for a friend. 8667 2. (I) A type of threat action that causes a system component to 8668 perform a function or service that is detrimental to system 8669 security. (See: usurpation.) 8671 Usage: This type includes the following subtypes: 8672 - "Tampering": In context of misuse, deliberately altering a 8673 system's logic, data, or control information to cause the 8674 system to perform unauthorized functions or services. (See: 8675 corruption, main entry for "tampering".) 8676 - "Malicious logic": In context of misuse, any hardware, 8677 firmware, or software intentionally introduced into a system to 8678 perform or control execution of an unauthorized function or 8679 service. (See: corruption, incapacitation, main entry for 8680 "malicious logic", masquerade.) 8681 - "Violation of authorizations": Action by an entity that exceeds 8682 the entity's system privileges by executing an unauthorized 8683 function. (See: authorization.) 8685 $ misuse detection 8686 (I) An intrusion detection method that is based on rules that 8687 specify system events, sequences of events, or observable 8688 properties of a system that are believed to be symptomatic of 8689 security incidents. (See: IDS. Compare: anomaly detection.) 8691 $ MLS 8692 (I) See: multilevel secure 8694 $ mobile code 8695 1a. (I) Software that originates from a remote server, is 8696 transmitted across a network, and is loaded onto and executed on a 8697 local client system without explicit initiation by the client's 8698 user and, in some cases, without that user's knowledge. (Compare: 8699 active content.) 8701 Tutorial: One form of mobile code is active content in a file that 8702 is transferred across a network. 8704 1b. (O) /U.S. DoD/ "Software obtained from remote systems outside 8705 the enclave boundary, transferred across a network, and then 8706 downloaded and executed on a local system without explicit 8707 installation or execution by the recipient." 8709 2a. (O) /U.S. DoD/ "Technology that enables the creation of 8710 executable information that can be delivered to an information 8711 system and directly executed on any hardware/software architecture 8712 that has an appropriate host execution environment." 8714 2b. (O) "Programs (e.g., script, macro, or other portable 8715 instruction) that can be shipped unchanged to a heterogeneous 8716 collection of platforms and executed with identical semantics" 8717 [SP-28]. (See: active content.) 8719 Tutorial: Mobile code might be malicious. Using techniques such as 8720 "code signing" and a "sandbox" can reduce the risks of receiving 8721 and executing mobile code. 8723 $ mode 8724 $ mode of operation 8725 1. (I) /cryptographic operation/ A technique for enhancing the 8726 effect of a cryptographic algorithm or adapting the algorithm for 8727 an application, such as applying a block cipher to a sequence of 8728 data blocks or a data stream. (See: ECB, CBC, CFB, OFB.) 8729 2. (I) /system operation/ A type of security policy that states 8730 the range of classification levels of information that a system is 8731 permitted to handle and the range of clearances and authorizations 8732 of users who are permitted to access the system. (See: 8733 compartmented security mode, controlled security mode, dedicated 8734 security mode, multilevel security mode, partitioned security 8735 mode, system-high security mode. Compare: protection level.) 8737 3. (I) /IKE/ IKE refers to its various types of ISAKMP-scripted 8738 exchanges of messages as "modes". Among these are the following: 8739 - "Main mode": One of IKE's two phase 1 modes. (See: ISAKMP.) 8740 - "Quick mode": IKE's only phase 2 mode. (See: ISAKMP.) 8742 $ modulus 8743 (I) The defining constant in modular arithmetic, and usually a 8744 part of the public key in asymmetric cryptography that is based on 8745 modular arithmetic. (See: Diffie-Hellman, RSA.) 8747 $ Mondex 8748 (O) A smartcard-based electronic money system that incorporates 8749 cryptography and can be used to make payments via the Internet. 8750 (See: IOTP.) 8752 $ Morris Worm 8753 (I) A worm program that flooded the ARPANET in November, 1988, 8754 causing problems for thousands of hosts. [R1135] (See: community 8755 risk, worm) 8757 $ MOSS 8758 (I) See: MIME Object Security Services. 8760 $ MQV 8761 (N) A key-agreement protocol [Mene] that was proposed by A.J. 8762 Menezes, M. Qu, and S.A. Vanstone in 1995 and is based on the 8763 Diffie-Hellman algorithm. 8765 $ MSP 8766 (N) See: Message Security Protocol. 8768 $ multicast security 8769 See: secure multicast 8771 $ Multics 8772 (N) MULTiplexed Information and Computing Service, an MLS computer 8773 timesharing system designed and implemented during 1965-69 by a 8774 consortium including Massachusetts Institute of Technology, 8775 General Electric, and Bell Laboratories, and later offered 8776 commercially by Honeywell. 8778 Tutorial: Multics was one of the first large, general-purpose, 8779 operating systems to include security as a primary goal from the 8780 inception of the design and development and was rated in TCSEC 8781 Class B2. Its many innovative hardware and software security 8782 mechanisms (e.g., protection ring) were adopted by later systems. 8784 $ multilevel secure (MLS) 8785 (I) Describes an information system that is trusted to contain, 8786 and maintain separation between, resources (particularly stored 8787 data) of different security levels. (Examples: BLACKER, CANEWARE, 8788 KSOS, Multics, SCOMP.) 8790 Usage: Usually understood to mean that the system permits 8791 concurrent access by users who differ in their access 8792 authorizations, while denying users access to resources for which 8793 they lack authorization. 8795 $ multilevel security mode 8796 1. (N) A mode of system operation wherein (a) two or more security 8797 levels of information are allowed to be to be handled concurrently 8798 within the same system when some users having access to the system 8799 have neither a security clearance nor need-to-know for some of the 8800 data handled by the system and (b) separation of the users and the 8801 classified material on the basis, respectively, of clearance and 8802 classification level are dependent on operating system control. 8803 (See: /system operation/ under "mode", need to know, protection 8804 level, security clearance. Compare: controlled mode.) 8806 Usage: Usually abbreviated as "multilevel mode". This term was 8807 defined in Government policy regarding system accreditation, but 8808 the term is also used outside the Government. 8810 2. (O) A mode of system operation in which all three of the 8811 following statements are true: (a) Some authorized users do not 8812 have a security clearance for all the information handled in the 8813 system. (b) All authorized users have the proper security 8814 clearance and appropriate specific access approval for the 8815 information to which they have access. (c) All authorized users 8816 have a need-to-know only for information to which they have 8817 access. [C4009] (See: formal access approval, protection level.) 8819 $ Multipurpose Internet Mail Extensions (MIME) 8820 (I) An Internet protocol (RFC 2045) that enhances the basic format 8821 of Internet electronic mail messages (RFC 822) (a) to enable 8822 character sets other than U.S. ASCII to be used for textual 8823 headers and content and (b) to carry non-textual and multi-part 8824 content. (See: S/MIME.) 8826 $ mutual suspicion 8827 (I) The state that exists between two interacting system entities 8828 in which neither entity can trust the other to function correctly 8829 with regard to some security requirement. 8831 $ name 8832 (I) Synonym for "identifier". 8834 $ naming authority 8835 (O) /U.S. DoD/ An organizational entity responsible for assigning 8836 DNs and for assuring that each DN is meaningful and unique within 8837 its domain. [DoD9] 8839 $ National Computer Security Center (NCSC) 8840 (O) A U.S. DoD organization, housed in NSA, that has 8841 responsibility for encouraging widespread availability of trusted 8842 computer systems throughout the Federal Government. It has 8843 established criteria for, and performed evaluations of, computer 8844 and network systems that have a TCB. (See: Evaluated Products 8845 List, Rainbow Series, TCSEC.) 8847 $ National Information Assurance Partnership (NIAP) 8848 (N) An joint initiative of NIST and NSA to enhance the quality of 8849 commercial products for information security and increase consumer 8850 confidence in those products through objective evaluation and 8851 testing methods. 8853 Tutorial: NIAP is registered, through the U.S. DoD, as a National 8854 Performance Review Reinvention Laboratory. NIAP functions include 8855 the following: 8856 - Developing tests, test methods, and other tools that developers 8857 and testing laboratories may use to improve and evaluate 8858 security products. 8859 - Collaborating with industry and others on research and testing 8860 programs. 8861 - Using the Common Criteria to develop protection profiles and 8862 associated test sets for security products and systems. 8863 - Cooperating with the NIST National Voluntary Laboratory 8864 Accreditation Program to develop a program to accredit private- 8865 sector laboratories for the testing of information security 8866 products using the Common Criteria. 8867 - Working to establish a formal, international mutual recognition 8868 scheme for a Common Criteria-based evaluation. 8870 $ National Institute of Standards and Technology (NIST) 8871 (N) A U.S. Department of Commerce organization that promotes U.S. 8872 economic growth by working with industry to develop and apply 8873 technology, measurements, and standards. Has primary Government 8874 responsibility for INFOSEC standards for sensitive unclassified 8875 information. (See: ANSI, DES, DSA, DSS, FIPS, NIAP, NSA.) 8877 $ National Security Agency (NSA) 8878 (N) A U.S. DoD organization that has primary Government 8879 responsibility for INFOSEC standards for classified information 8880 and for sensitive unclassified information handled by national 8881 security systems. (See: FORTEZZA, KEA, MISSI, national security 8882 system, NIAP, NIST, SKIPJACK.) 8884 $ national security information 8885 (O) /U.S. Government/ Information that has been determined, 8886 pursuant to Executive Order 12958 or any predecessor order, to 8887 require protection against unauthorized disclosure. [C4009] 8889 $ national security system 8890 (O) /U.S. Government/ Any Government-operated information system 8891 for which the function, operation, or use (a) involves 8892 intelligence activities; (b) involves cryptologic activities 8893 related to national security; (c) involves command and control of 8894 military forces; (d) involves equipment that is an integral part 8895 of a weapon or weapon system; or (e) is critical to the direct 8896 fulfillment of military or intelligence missions and does not 8897 include a system that is to be used for routine administrative and 8898 business applications (including payroll, finance, logistics, and 8899 personnel management applications). [Title 40 U.S.C. Section 1552, 8900 Information Technology Management Reform Act of 1996.] (See: type 8901 2 product.) 8903 $ NCSC 8904 (O) See: National Computer Security Center. 8906 $ need to know, need-to-know 8907 (I) The necessity for access to, knowledge of, or possession of 8908 specific information required to carry out official duties. 8910 Usage: The compound "need-to-know" is used as both an adjective 8911 and a noun. 8913 Tutorial: The need-to-know criterion is used in security 8914 procedures that require a custodian of sensitive information, 8915 prior to disclosing the information to someone else, to establish 8916 that the intended recipient has proper authorization to access the 8917 information. 8919 $ network 8920 (I) An information system comprised of a collection of 8921 interconnected nodes. (See: computer network.) 8923 $ Network Hardware Layer 8924 (I) See: Internet Protocol Suite. 8926 $ Network Interface Layer 8927 (I) See: Internet Protocol Suite. 8929 $ Network Layer Security Protocol (NLSP). 8930 (N) An OSI protocol (IS0 11577) for end-to-end encryption services 8931 at the top of OSIRM Layer 3. NLSP is derived from SP3 but is more 8932 complex. (Compare: IPsec.) 8934 $ Network Substrate Layer 8935 (I) Synonym for "Network Hardware Layer". 8937 $ network weaving 8938 (I) A penetration technique in which an intruder avoids detection 8939 and traceback by using multiple linked communication networks to 8940 access and attack a system. [C4009] 8942 $ NIAP 8943 (N) See: National Information Assurance Partnership. 8945 $ nibble 8946 (D) Half of a byte (i.e., usually, 4 bits). 8948 Deprecated Term: To avoid international misunderstanding, ISDs 8949 SHOULD NOT use this term; instead, state the size of the block 8950 explicitly (e.g., "4-bit block"). (See: Deprecated Usage under 8951 "Green Book".) 8953 $ NIPRNET 8954 (O) The U.S. DoD's common-use Non-Classified Internet Protocol 8955 Router Network; the part of the Internet that is wholly controlled 8956 by the U.S. DoD and is used for official DoD business. 8958 $ NIST 8959 (N) See: National Institute of Standards and Technology. 8961 $ NLSP 8962 (N) See: Network Layer Security Protocol 8964 $ no-lone zone 8965 (I) A room or other space or area to which no person may have 8966 unaccompanied access and that, when occupied, is required to be 8967 occupied by two or more appropriately authorized persons. [C4009] 8968 (See: dual control.) 8970 $ no-PIN ORA (NORA) 8971 (O) /MISSI/ An organizational RA that operates in a mode in which 8972 the ORA performs no card management functions and, therefore, does 8973 not require knowledge of either the SSO PIN or user PIN for an end 8974 user's FORTEZZA PC card. 8976 $ node 8977 (I) A collection of related subsystems located on one or more 8978 computer platforms at a single system site. 8980 $ nonce 8981 (I) A random or non-repeating value that is included in data 8982 exchanged by a protocol, usually for the purpose of guaranteeing 8983 liveness and thus detecting and protecting against replay attacks. 8984 (See: fresh.) 8986 $ non-critical 8987 See: critical. 8989 $ non-repudiation service 8990 1. (I) A security service that provide protection against false 8991 denial of involvement in an association (especially a 8992 communication association that transfers data). (See: repudiation, 8993 time stamp.) 8995 Tutorial: Two separate types of denial are possible -- an entity 8996 can deny that it sent a data object, or it can deny that it 8997 received a data object -- and, therefore, two separate types of 8998 non-repudiation service are possible. (See: non-repudiation with 8999 proof of origin, non-repudiation with proof of receipt.) 9001 2. (D) "Assurance [that] the sender of data is provided with proof 9002 of delivery and the recipient is provided with proof of the 9003 sender's identity, so neither can later deny having processed the 9004 data." [C4009] 9006 Deprecated Definition: ISDs SHOULD NOT use definition 2 because it 9007 bundles two security services -- non-repudiation with proof of 9008 origin, and non-repudiation with proof of receipt -- that can be 9009 provided independently of each other. 9011 Usage: ISDs SHOULD distinguish between the technical aspects and 9012 the legal aspects of a non-repudiation service: 9013 - "Technical non-repudiation": Refers to the assurance a relying 9014 party has that if a public key is used to validate a digital 9015 signature, then that signature had to have been made by the 9016 corresponding private signature key. [SP32] 9017 - "Legal non-repudiation": Refers to how well possession or 9018 control of the private signature key can be established. [SP32] 9020 Tutorial: Non-repudiation service does not prevent an entity from 9021 repudiating a communication. Instead, the service provides 9022 evidence that can be stored and later presented to a third party 9023 to resolve disputes that arise if and when a communication is 9024 repudiated by one of the entities involved. 9026 Ford describes the six phases of a complete non-repudiation 9027 service and uses "critical action" to refer to the act of 9028 communication that is the subject of the service [For94, For97]: 9030 -------- -------- -------- -------- -------- . -------- 9031 Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6: 9032 Request Generate Transfer Verify Retain . Resolve 9033 Service Evidence Evidence Evidence Evidence . Dispute 9034 -------- -------- -------- -------- -------- . -------- 9036 Service Critical Evidence Evidence Archive . Evidence 9037 Request => Action => Stored => Is => Evidence . Is 9038 Is Made Occurs For Later Tested In Case . Verified 9039 and Use | ^ Critical . ^ 9040 Evidence v | Action Is . | 9041 Is +-------------------+ Repudiated . | 9042 Generated |Verifiable Evidence|------> ... . ----+ 9043 +-------------------+ 9045 Phase / Explanation 9046 ------------------- 9047 1. Request service: Before the critical action, the service 9048 requester asks, either implicitly or explicitly, to have 9049 evidence of the action be generated. 9050 2. Generate evidence: When the critical action occurs, evidence is 9051 generated by a process involving the potential repudiator and 9052 possibly also a trusted third party. 9053 3. Transfer evidence: The evidence is transferred to the requester 9054 or stored by a third party, for later use (if needed.) 9055 4. Verify evidence: The entity that holds the evidence tests it to 9056 be sure that it will suffice if a dispute arises. 9057 5. Retain evidence: The evidence is retained for possible future 9058 retrieval and use. 9059 6. Resolve dispute: In this phase, which occurs only if the 9060 critical action is repudiated, the evidence is retrieved from 9061 storage, presented, and verified to resolve the dispute. 9063 $ non-repudiation with proof of origin 9064 (I) A security service that provides the recipient of data with 9065 evidence that proves the origin of the data, and thus protects the 9066 recipient against an attempt by the originator to falsely deny 9067 sending the data. (See: non-repudiation service.) 9069 Tutorial: This service is a strong version of data origin 9070 authentication service. This service can not only verify the 9071 identity of a system entity that is the original source of 9072 received data; it can also provide proof of that identity to a 9073 third party. 9075 $ non-repudiation with proof of receipt 9076 (I) A security service that provides the originator of data with 9077 evidence that proves the data was received as addressed, and thus 9078 protects the originator against an attempt by the recipient to 9079 falsely deny receiving the data. (See: non-repudiation service.) 9081 $ non-volatile media 9082 (I) Storage media that, once written into, provide stable storage 9083 of information without an external power supply. (Compare: 9084 permanent storage, volatile media.) 9086 $ NORA 9087 (O) See: no-PIN ORA. 9089 $ notarization 9090 (I) Registration of data under the authority or in the care of a 9091 trusted third party, thus making it possible to provide subsequent 9092 assurance of the accuracy of characteristics claimed for the data, 9093 such as content, origin, time of existence, and delivery. [I7498- 9094 2] (See: digital notary.) 9096 $ NSA 9097 (N) See: National Security Agency 9099 $ null 9100 (N) /encryption/ "Dummy letter, letter symbol, or code group 9101 inserted into an encrypted message to delay or prevent its 9102 decryption or to complete encrypted groups for transmission or 9103 transmission security purposes." [C4009] 9105 $ NULL encryption algorithm 9106 (I) An algorithm [R2410] that is specified as doing nothing to 9107 transform plaintext data; i.e., a no-op. It originated because ESP 9108 always specifies the use of an encryption algorithm for 9109 confidentiality. The NULL encryption algorithm is a convenient way 9110 to represent the option of not applying encryption in ESP (or in 9111 any other context where a no-op is needed). (Compare: null.) 9113 $ OAKLEY 9114 (I) A key establishment protocol (proposed for IPsec but 9115 superseded by IKE) based on the Diffie-Hellman algorithm and 9116 designed to be a compatible component of ISAKMP. [R2412] 9118 Tutorial: OAKLEY establishes a shared key with an assigned 9119 identifier and associated authenticated identities for parties; 9120 i.e., OAKLEY provides authentication service to ensure the 9121 entities of each other's identity, even if the Diffie-Hellman 9122 exchange is threatened by active wiretapping. Also, it provides 9123 public-key forward secrecy for the shared key and supports key 9124 updates, incorporation of keys distributed by out-of-band 9125 mechanisms, and user-defined abstract group structures for use 9126 with Diffie-Hellman. 9128 $ object 9129 (I) /formal model/ Trusted computer system modeling usage: A 9130 system component that contains or receives information. (See: 9131 Bell-LaPadula model, trusted computer system.) 9133 $ object identifier (OID) 9134 1. (N) An official, globally unique name for a thing, written as a 9135 sequence of integers (which are formed and assigned as defined in 9136 the ASN.1 standard) and used to reference the thing in abstract 9137 specifications and during negotiation of security services in a 9138 protocol. 9140 2. (O) "A value (distinguishable from all other such values) which 9141 is associated with an object." [X680] 9143 Tutorial: Objects named by OIDs are leaves of the object 9144 identifier tree (which is similar to but different from the X.500 9145 Directory Information Tree). Each arc (i.e., each branch of the 9146 tree) is labeled with a non-negative integer. An OID is the 9147 sequence of integers on the path leading from the root of the tree 9148 to a named object. 9150 The OID tree has three arcs immediately below the root: {0} for 9151 use by ITU-T, {1} for use by ISO, and {2} for use by both jointly. 9152 Below ITU-T are four arcs, where {0 0} is for ITU-T 9153 recommendations. Below {0 0} are 26 arcs, one for each series of 9154 recommendations starting with the letters A to Z, and below these 9155 are arcs for each recommendation. Thus, the OID for ITU-T 9156 Recommendation X.509 is {0 0 24 509}. Below ISO are four arcs, 9157 where {1 0 }is for ISO standards, and below these are arcs for 9158 each ISO standard. Thus, the OID for ISO/IEC 9594-8 (the ISO 9159 number for X.509) is {1 0 9594 8}. 9161 ANSI registers organization names below the branch {joint-iso- 9162 ccitt(2) country(16) US(840) organization(1) gov(101) csor(3)}. 9163 The NIST CSOR records PKI objects below the branch {joint-iso-itu- 9164 t(2) country(16) us(840) organization (1) gov(101) csor(3)}. The 9165 U.S. DoD registers INFOSEC objects below the branch {joint-iso- 9166 itu-t(2) country(16) us(840) organization(1) gov(101) dod(2) 9167 infosec(1)}. 9169 The IETF's Public-Key Infrastructure (pkix) Working Group 9170 registers PKI objects below the branch {iso(1) identified- 9171 organization(3) dod(6) internet(1) security(5) mechanisms(5) 9172 pkix(7)}. [R3280] 9174 $ object reuse 9175 (N) /COMPUSEC/ Reassignment and reuse of an area of a storage 9176 medium (e.g., random-access memory, floppy disk, magnetic tape) 9177 that once contained sensitive data objects. Before being 9178 reassigned for use by a new subject, the area needs to be erased 9179 or, in some cases, purged. [NCS04] 9181 $ obstruction 9182 (I) A type of threat action that interrupts delivery of system 9183 services by hindering system operations. (See: disruption.) 9184 Tutorial: This type includes the following subtypes: 9185 - "Interference": Disruption of system operations by blocking 9186 communication of user data or control information. (See: 9187 jamming.) 9188 - "Overload": Hindrance of system operation by placing excess 9189 burden on the performance capabilities of a system component. 9190 (See: flooding.) 9192 $ OCSP 9193 (I) See: On-line Certificate Status Protocol. 9195 $ octet 9196 (I) A data unit of eight bits. (Compare: byte.) 9198 Usage: This term is used in networking (especially in OSI 9199 standards) in preference to "byte", because some systems use 9200 "byte" for data storage units of a size other than eight bits. 9202 $ OFB 9203 (N) See: output feedback. 9205 $ off-line attack 9206 (I) See: secondary definition under "attack". 9208 $ ohnosecond 9209 (D) That minuscule fraction of time in which you realize that your 9210 private key has been compromised. 9212 Deprecated Usage: This is a joke for English speakers. (See: 9213 Deprecated Usage under "Green Book".) 9215 $ OID 9216 (N) See: object identifier. 9218 $ On-line Certificate Status Protocol (OCSP) 9219 (I) An Internet protocol [R2560] used by a client to obtain from a 9220 server the validity status and other information about a digital 9221 certificate. 9223 Tutorial: In some applications, such as those involving high-value 9224 commercial transactions, it may be necessary either (a) to obtain 9225 certificate revocation status that is more timely than is possible 9226 with CRLs or (b) to obtain other kinds of status information. OCSP 9227 may be used to determine the current revocation status of a 9228 digital certificate, in lieu of or as a supplement to checking 9229 against a periodic CRL. An OCSP client issues a status request to 9230 an OCSP server and suspends acceptance of the certificate in 9231 question until the server provides a response. 9233 $ one-time pad 9234 1. (N) A manual encryption system in the form of a paper pad for 9235 one-time use. 9237 2. (I) An encryption algorithm in which the key is a random 9238 sequence of symbols and each symbol is used for encryption only 9239 one time -- i.e., used to encrypt only one plaintext symbol and 9240 thus produce only one ciphertext symbol -- and a copy of the key 9241 is used similarly for decryption. 9243 Tutorial: To ensure one-time use, the copy of the key used for 9244 encryption is destroyed after use, as is the copy used for 9245 decryption. This is the only encryption algorithm that is truly 9246 unbreakable, even given unlimited resources for cryptanalysis 9247 [Schn], but key management costs and synchronization problems make 9248 it impractical except in special situations. 9250 $ one-time password, One-Time Password (OTP) 9251 1. (I) /not capitalized/ A "one-time password" is a simple 9252 authentication technique in which each password is used only once 9253 as authentication information that verifies an identity. This 9254 technique counters the threat of a replay attack that uses 9255 passwords captured by wiretapping. 9257 2. (I) /capitalized/ "One-Time Password" is an Internet protocol 9258 [R1938] that is based on S/KEY and uses a cryptographic hash 9259 function to generate one-time passwords for use as authentication 9260 information in system login and in other processes that need 9261 protection against replay attacks. 9263 $ one-way encryption 9264 (I) Irreversible transformation of plain text to cipher text, such 9265 that the plain text cannot be recovered from the cipher text by 9266 other than exhaustive procedures even if the cryptographic key is 9267 known. (See: brute force, encryption.) 9269 $ one-way function 9270 (I) "A (mathematical) function, f, which is easy to compute, but 9271 which for a general value y in the range, it is computationally 9272 difficult to find a value x in the domain such that f(x) = y. 9273 There may be a few values of y for which finding x is not 9274 computationally difficult." [X509] 9276 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 9277 "cryptographic hash". 9279 $ onion routing 9280 (I) A system that can be used to provide both (a) data 9281 confidentiality and (b) traffic-flow confidentiality for network 9282 packets, and also provide (c) anonymity for the source of the 9283 packets. 9285 Tutorial: The source, instead of sending a packet directly to the 9286 intended destination, sends it to an "onion routing proxy" that 9287 builds an anonymous connection through several other "onion 9288 routers" to the destination. The proxy defines a route through the 9289 "onion routing network" by encapsulating the original payload in a 9290 layered data packet called an "onion", in which each layer defines 9291 the next hop in the route and each layer is also encrypted. Along 9292 the route, each onion router that receives the onion peels off one 9293 layer; decrypts that layer and reads from it the address of the 9294 next onion router on the route; pads the remaining onion to some 9295 constant size; and sends the padded onion to that next router. 9297 $ open security environment 9298 (O) /U.S. DoD/ A system environment that meets at least one of the 9299 following two conditions: (a) Application developers (including 9300 maintainers) do not have sufficient clearance or authorization to 9301 provide an acceptable presumption that they have not introduced 9302 malicious logic. (b) Configuration control does not provide 9303 sufficient assurance that applications and the equipment are 9304 protected against the introduction of malicious logic prior to and 9305 during the operation of system applications. [NCS04] (See: "first 9306 law" under "Courtney's laws". Compare: closed security 9307 environment.) 9309 $ open storage 9310 (N) /U.S. Government/ "Storage of classified information within an 9311 accredited facility, but not in General Services Administration 9312 approved secure containers, while the facility is unoccupied by 9313 authorized personnel." [C4009] 9315 $ Open Systems Interconnection (OSI) Reference Model (OSIRM) 9316 (N) A joint ISO/ITU-T standard [I7498-1] for a seven-layer, 9317 architectural communication framework for interconnection of 9318 computers in networks. (See: OSIRM Security Architecture. Compare: 9319 Internet Protocol Suite.) 9321 Tutorial: OSIRM-based standards include communication protocols 9322 that are mostly incompatible with the IPS, but also include 9323 security models, such as X.509, that are used in the Internet. 9325 The OSIRM layers, from highest to lowest, are (7) Application, (6) 9326 Presentation, (5) Session, (4) Transport, (3) Network, (2) Data 9327 Link, and (1) Physical. 9329 Usage: This Glossary refers to OSIRM layers by number to avoid 9330 confusing them with IPS layers, which are referred to by name. 9332 Some unknown person described how the OSIRM layers correspond to 9333 the seven deadly sins: 9335 7. Wrath: Application is always angry at the mess it sees below 9336 itself. (Hey! Who is it to be pointing fingers?) 9337 6. Sloth: Presentation is too lazy to do anything productive by 9338 itself. 9339 5. Lust: Session is always craving and demanding what truly 9340 belongs to Application's functionality. 9341 4. Avarice: Transport wants all of the end-to-end functionality. 9342 (Of course, it deserves it, but life isn't fair.) 9343 3. Gluttony: (Connection-Oriented) Network is overweight and 9344 overbearing after trying too often to eat Transport's lunch. 9345 2. Envy: Poor Data Link is always starved for attention. (With 9346 Asynchronous Transfer Mode, maybe now it is feeling less 9347 neglected.) 9348 1. Pride: Physical has managed to avoid much of the controversy, 9349 and nearly all of the embarrassment, suffered by the others. 9351 John G. Fletcher described how the OSIRM layers correspond to Snow 9352 White's dwarf friends: 9354 7. Doc: Application acts as if it is in charge, but sometimes 9355 muddles its syntax. 9356 6. Sleepy: Presentation is indolent, being guilty of the sin of 9357 Sloth. 9358 5. Dopey: Session is confused because its charter is not very 9359 clear. 9360 4. Grumpy: Transport is irritated because Network has encroached 9361 on Transport's turf. 9362 3. Happy: Network smiles for the same reason that Transport is 9363 irritated. 9364 2. Sneezy: Data Link makes loud noises in the hope of attracting 9365 attention. 9366 1. Bashful: Physical quietly does its work, unnoticed by the 9367 others. 9369 $ operational integrity 9370 (I) Synonym for "system integrity"; this synonym emphasizes the 9371 actual performance of system functions rather than just the 9372 ability to perform them. 9374 $ operational security 9375 1. (I) System capabilities, or performance of system functions, 9376 that are needed either (a) to securely manage a system or (b) to 9377 manage security features of a system. (Compare: operations 9378 security (OPSEC).) 9380 Usage: ISDs that use this term SHOULD state a definition because 9381 (a) the definition provide here is general and vauge and (b) the 9382 term could easily be confused with "operations security", which is 9383 a different concept. 9385 Tutorial: For example, in the context of an Internet service 9386 provider, the term could refer to capabilities to manage network 9387 devices in the event of attacks, simplify troubleshooting, keep 9388 track of events that affect system integrity, help analyze sources 9389 of attacks, and provide administrators with control over network 9390 addresses and protocols to help mitigate the most common attacks 9391 and exploits. [R3871] 9392 2. (D) Synonym for "administrative security". 9394 Deprecated Definition: ISDs SHOULD NOT use this term as a synonym 9395 for "administrative security". Any type of security may affect 9396 system operations; therefore, the term may be misleading. Instead, 9397 use "administrative security", "communication security", "computer 9398 security", "emanations security", "personnel security", "physical 9399 security", or whatever specific type is meant. (See: security 9400 architecture. Compare: operational integrity, OPSEC.) 9402 $ operations security (OPSEC) 9403 (I) A process to identify, control, and protect evidence of the 9404 planning and execution of sensitive activities and operations, and 9405 thereby prevent potential adversaries from gaining knowledge of 9406 capabilities and intentions. (See: communications cover. Compare: 9407 operational security.) 9409 $ operator 9410 (I) A person who has been authorized to direct selected functions 9411 of a system. (Compare: manager.) 9413 Usage: ISDs that use this term SHOULD state a definition for it 9414 because a system operator may or may not be treated as a "user". 9416 $ OPSEC 9417 1. (I) Abbreviation for "operations security". 9419 2. (D) Abbreviation for "operational security". 9421 Deprecated Usage: ISDs SHOULD NOT use this abbreviation for 9422 "operational security" (as defined in this Glossary), because its 9423 use for "operations security" has been well established for many 9424 years, particular in the military community. 9426 $ ORA 9427 See: organizational registration authority. 9429 $ Orange Book 9430 (D) /slang/ Synonym for "Trusted Computer System Evaluation 9431 Criteria" [CSC001, DoD1]. 9433 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 9434 "Trusted Computer System Evaluation Criteria" [CSC001, DoD1]. 9435 Instead, use the full, proper name of the document or, in 9436 subsequent references, the abbreviation "TCSEC". (See: Deprecated 9437 Usage under "Green Book".) 9439 $ organizational certificate 9440 (I) An X.509 certificate in which the "subject" field contains the 9441 name of an institution or set (e.g., a business, government, 9442 school, labor union, club, ethnic group, nationality, system, or 9443 group of individuals playing the same role), rather than the name 9444 of an individual person or device. (Compare: persona certificate, 9445 role certificate.) 9447 Tutorial: Such a certificate might be issued for one of the 9448 following purposes: 9449 - To enable an individual to prove membership in the 9450 organization. 9451 - To enable an individual to represent the organization, i.e., to 9452 act in its name and with it powers or permissions. 9454 (O) /MISSI/ A type of MISSI X.509 public-key certificate that is 9455 issued to support organizational message handling for the U.S. 9456 DoD's Defense Message System. 9458 $ organizational registration authority (ORA) 9459 1. (I) /PKI/ An RA for an organization. 9461 2. (O) /MISSI/ An end entity that (a) assists a PCA, CA, or SCA to 9462 register other end entities, by gathering, verifying, and entering 9463 data and forwarding it to the signing authority and (b) may also 9464 assist with card management functions. An ORA is a local 9465 administrative authority, and the term refers both to the role and 9466 to the person who plays that role. An ORA does not sign 9467 certificates, CRLs, or CKLs. (See: no-PIN ORA, SSO-PIN ORA, user- 9468 PIN ORA.) 9470 $ origin authentication 9471 (D) Synonym for "data origin authentication". (See: 9472 authentication, data origin authentication.) 9474 Deprecated Term: ISDs SHOULD NOT use this term; it suggests 9475 careless use of the internationally standardized term "data origin 9476 authentication" and also could be confused with "peer entity 9477 authentication." 9479 $ origin authenticity 9480 (D) Synonym for "data origin authentication". (See: authenticity, 9481 data origin authentication.) 9483 Deprecated Term: ISDs SHOULD NOT use this term; it suggests 9484 careless use of the internationally standardized term "data origin 9485 authentication" and mixes concepts in a potentially misleading 9486 way. 9488 $ OSI, OSIRM 9489 (N) See: Open Systems Interconnection Reference Model. 9491 $ OSIRM Security Architecture 9492 (N) The part of the OSIRM [I7498-2] that specifies the security 9493 services and security mechanisms that can be applied to protect 9494 communications between two systems. (See: security architecture.) 9495 Tutorial: This part of the OSIRM includes an allocation of 9496 security services to protocol layers. The following table show 9497 which security services (see definitions in this Glossary) are 9498 permitted by the OSIRM in each of its layer. (Also, an application 9499 process that operates above the Application Layer may itself 9500 provide security services.) Similarly, the table suggests which 9501 services are suitable for each IPS layer. However, explaining and 9502 justifying these allocations is beyond the scope of this Glossary. 9504 Legend for Table Entries: 9505 O = Yes, [IS7498-2] permits the service in this OSIRM layer. 9506 I = Yes, the service can be incorporated in this IPS layer. 9507 * = This layer subsumed by Application Layer in IPS. 9509 IPS Protocol Layers +-----------------------------------------+ 9510 |Network| Net |In-| Trans | Application | 9511 | H/W |Inter|ter| -port | | 9512 | |-face|net| | | 9513 OSIRM Protocol Layers +-----------------------------------------+ 9514 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 9515 Confidentiality +-----------------------------------------+ 9516 - Datagram | O I | O I | O I | O I | | O * | O I | 9517 - Selective Field | | | I | | | O * | O I | 9518 - Traffic Flow | O | | O | | | | O | 9519 -- Full | I | | | | | | | 9520 -- Partial | | I | I | | | | I | 9521 Integrity +-----------------------------------------+ 9522 - Datagram | I | I | O I | O I | | | O I | 9523 - Selective Field | | | I | | | | O I | 9524 - Stream | | | O I | O I | | | O I | 9525 Authentication +-----------------------------------------+ 9526 - Peer Entity | | I | O I | O I | | | O I | 9527 - Data Origin | | I | O I | O I | | | O I | 9528 Access Control +-----------------------------------------+ 9529 - type as appropriate | | I | O I | O I | | | O I | 9530 Non-Repudiation +-----------------------------------------+ 9531 - of Origin | | | | | | | O I | 9532 - of Receipt | | | | | | | O I | 9533 +-----------------------------------------+ 9535 $ OTAR 9536 (N) See: over-the-air rekeying. 9538 $ OTP 9539 (I) See: One-Time Password. 9541 $ out-of-band 9542 (I) /adjective, adverb/ Information transfer using a channel or 9543 method that is outside (i.e., separate from or different from) the 9544 main channel or normal method. 9546 Tutorial: Out-of-band mechanisms are often used to distribute 9547 shared secrets (e.g., a symmetric key) or other sensitive 9548 information items (e.g., a root key) that are needed to initialize 9549 or otherwise enable the operation of cryptography or other 9550 security mechanisms. Example: Using postal mail to distribute 9551 printed or magnetic media containing symmetric cryptographic keys 9552 for use in Internet encryption devices. (See: key distribution.) 9554 $ output feedback (OFB) 9555 (N) A block cipher mode [FP081] that modifies ECB mode to operate 9556 on plaintext segments of variable length less than or equal to the 9557 block length. 9559 Tutorial: This mode operates by directly using the algorithm's 9560 previously generated output block as the algorithm's next input 9561 block (i.e., by "feeding back" the output block) and combining 9562 (exclusive OR-ing) the output block with the next plaintext 9563 segment (of block length or less) to form the next ciphertext 9564 segment. 9566 $ outside attack 9567 (I) See: secondary definition under "attack". Compare: outsider.) 9569 $ outsider 9570 (I) A user (usually a person) that accesses a system from a 9571 position that is outside the system's security perimeter. 9572 (Compare: authorized user, insider, unauthorized user.) 9574 Tutorial: The actions performed by an outsider in accessing the 9575 system may be either authorized or unauthorized; i.e., an outsider 9576 may act either as an authorized user or as an unauthorized user. 9578 $ over-the-air rekeying (OTAR) 9579 (N) Changing a key in a remote cryptographic device by sending a 9580 new key directly to the device via a channel that the device is 9581 protecting. [C4009] 9583 $ overload 9584 (I) /threat action/ See: secondary definition under "obstruction". 9586 $ P1363 9587 (N) See: IEEE P1363. 9589 $ PAA 9590 (O) See: policy approving authority. 9592 $ package 9593 (N) /Common Criteria/ A reusable set of either functional or 9594 assurance components (e.g. an EAL), combined in a single unit to 9595 satisfy a set of identified security objectives. Example: The 9596 seven EALs defined in Part 3 of the Common Criteria are predefined 9597 assurance packages. (Compare: protection profile.) 9598 Tutorial: A package is a combination of security requirement 9599 components and is intended to be reusable in the construction of 9600 either more complex packages or protection profiles and security 9601 targets. A package expresses a set of either functional or 9602 assurance requirements that meet some particular need, expressed 9603 as a set of security objectives. 9605 $ packet 9606 (I) A block of data that is carried from a source to a destination 9607 through a communication channel or, more generally, across a 9608 network. (Compare: datagram, PDU.) 9610 $ packet filter 9611 (I) See: secondary definition under "filtering router". 9613 $ packet monkey 9614 (D) /slang/ Someone who floods a system with packets, creating a 9615 denial-of-service condition for the system's users. (See: 9616 cracker.) 9618 Deprecated Term: To avoid international misunderstanding, ISDs 9619 SHOULD NOT use this term. (See: Deprecated Usage under "Green 9620 Book".) 9622 $ pagejacking 9623 (D) /slang/ A contraction of "Web page hijacking". A masquerade 9624 attack in which the attacker copies (steals) a home page or other 9625 material from the target server, rehosts the page on a server the 9626 attacker controls, and causes the rehosted page to be indexed by 9627 the major Web search services, thereby diverting browsers from the 9628 target server to the attacker's server. 9630 Deprecated Term: ISDs SHOULD NOT use this contraction. The term is 9631 not listed in most dictionaries and could confuse international 9632 readers. (See: Deprecated Usage under "Green Book".) 9634 $ PAN 9635 (O) See: primary account number. 9637 $ PAP 9638 (I) See: Password Authentication Protocol. 9640 $ parity bit 9641 (I) A checksum that is computed on a block of bits by computing 9642 the binary sum of the individual bits in the block and then 9643 discarding all but the low-order bit of the sum. (See: checksum.) 9645 $ partitioned security mode 9646 (N) A mode of system operation wherein all users having access to 9647 the system have the necessary security clearances for all data 9648 handled by the system, but some users might not have either formal 9649 access approval or need-to-know for all the data. (See: /system 9650 operation/ under "mode", formal access approval, need to know, 9651 protection level, security clearance.) 9653 Usage: Usually abbreviated as "partitioned mode". This term was 9654 defined in U.S. Government policy on system accreditation. 9656 $ PASS 9657 (N) See: personnel authentication system string. 9659 $ passive attack 9660 (I) See: secondary definition under "attack". 9662 $ passive user 9663 (I) See: secondary definition under "user". 9665 $ passive wiretapping 9666 (I) A wiretapping attack that attempts only to observe a 9667 communication flow and gain knowledge of the data it contains, but 9668 does not alter or otherwise affect that flow. (See: wiretapping. 9669 Compare: passive attack, active wiretapping.) 9671 $ password 9672 (I) A secret data value, usually a character string, that is 9673 presented to a system by a user to authenticate the user's 9674 identity. (See: authentication information, challenge-response, 9675 PIN, simple authentication.) 9677 (O) "A character string used to authenticate an identity." [CSC2] 9679 (O) "A string of characters (letters, numbers, and other symbols) 9680 used to authenticate an identity or to verify access 9681 authorization." [FP140] 9683 (O) "A secret that a claimant memorizes and uses to authenticate 9684 his or her identity. Passwords are typically character strings." 9685 [SP63] 9687 Tutorial: A password is usually paired with a user identifier that 9688 is explicit in the authentication process, although in some cases 9689 the identifier may be implicit. A password is usually verified by 9690 matching it to a stored value held by the access control system 9691 for that identifier. 9693 Using a password as authentication information is based on 9694 assuming that the password is known only by the system entity for 9695 which the identity is being authenticated. Therefore, in a network 9696 environment where wiretapping is possible, simple authentication 9697 that relies on transmission of static (i.e., repetitively used) 9698 passwords in cleartext form is inadequate. (See: one-time 9699 password, strong authentication.) 9701 $ Password Authentication Protocol (PAP) 9702 (I) A simple authentication mechanism in PPP. In PAP, a user 9703 identifier and password are transmitted in cleartext form. [R1334] 9704 (See: CHAP.) 9706 $ password sniffing 9707 (D) /slang/ Passive wiretapping to gain knowledge of passwords. 9708 (See: Deprecated Usage under "sniffing".) 9710 $ path discovery 9711 (I) For a digital certificate, the process of finding a set of 9712 public-key certificates that comprise a certification path from a 9713 trusted key to that specific certificate. 9715 $ path validation 9716 (I) The process of validating (a) all of the digital certificates 9717 in a certification path and (b) the required relationships between 9718 those certificates, thus validating the contents of the last 9719 certificate on the path. (See: certificate validation.) 9721 Tutorial: To promote interoperable PKI applications in the 9722 Internet, RFC 3280 specifies a detailed algorithm for validation 9723 of a certification path. 9725 $ payment card 9726 (N) /SET/ Collectively refers "to credit cards, debit cards, 9727 charge cards, and bank cards issued by a financial institution and 9728 which reflects a relationship between the cardholder and the 9729 financial institution." [SET2] 9731 $ payment gateway 9732 (O) /SET/ A system operated by an acquirer, or a third party 9733 designated by an acquirer, for the purpose of providing electronic 9734 commerce services to the merchants in support of the acquirer, and 9735 which interfaces to the acquirer to support the authorization, 9736 capture, and processing of merchant payment messages, including 9737 payment instructions from cardholders. [SET1, SET2] 9739 $ payment gateway certification authority (SET PCA) 9740 (O) /SET/ A CA that issues digital certificates to payment 9741 gateways and is operated on behalf of a payment card brand, an 9742 acquirer, or another party according to brand rules. A SET PCA 9743 issues a CRL for compromised payment gateway certificates. [SET2] 9744 (See: PCA.) 9746 $ PC card 9747 (N) A type of credit card-sized, plug-in peripheral device that 9748 was originally developed to provide memory expansion for portable 9749 computers, but is also used for other kinds of functional 9750 expansion. (See: FORTEZZA, PCMCIA.) 9752 Tutorial: The international PC Card Standard defines a non- 9753 proprietary form factor in three sizes -- Types I, II and III -- 9754 each of which have a 68-pin interface between the card and the 9755 socket into which it plugs. All three types have the same length 9756 and width, roughly the size of a credit card, but differ in their 9757 thickness from 3.3 to 10.5 mm. Examples include storage modules, 9758 modems, device interface adapters, and cryptographic modules. 9760 $ PCA 9761 (D) Abbreviation of various kinds of "certification authority". 9762 (See: Internet policy certification authority, (MISSI) policy 9763 creation authority, (SET) payment gateway certification 9764 authority.) 9766 Deprecated Abbreviation: An ISD that uses this abbreviation SHOULD 9767 define it at the point of first use. 9769 $ PCI 9770 (N) See: "protocol control information" under "protocol data 9771 unit". 9773 $ PCMCIA 9774 (N) Personal Computer Memory Card International Association, a 9775 group of manufacturers, developers, and vendors, founded in 1989 9776 to standardize plug-in peripheral memory cards for personal 9777 computers and now extended to deal with any technology that works 9778 in the PC Card form factor. (See: PC card.) 9780 $ PDS 9781 (N) See: protective distribution system. 9783 $ PDU 9784 (N) See: protocol data unit. 9786 $ peer entity authentication 9787 (I) "The corroboration that a peer entity in an association is the 9788 one claimed." [I7498-2] (See: authentication.) 9790 $ peer entity authentication service 9791 (I) A security service that verifies an identity claimed by or for 9792 a system entity in an association. (See: authentication, 9793 authentication service.) 9795 Tutorial: This service is used at the establishment of, or at 9796 times during, an association to confirm the identity of one entity 9797 to another, thus protecting against a masquerade by the first 9798 entity. However, unlike data origin authentication service, this 9799 service requires an association to exist between the two entities, 9800 and the corroboration provided by the service is valid only at the 9801 current time that the service is provided. (See: "relationship 9802 between data integrity service and authentication services" under 9803 "data integrity service"). 9805 $ PEM 9806 (I) See: Privacy Enhanced Mail. 9808 $ penetrate 9809 1a. Circumvent a system's security protections. (See: attack, 9810 break, violation.) 9812 1b. (I) Successfully and repeatedly gain unauthorized access to a 9813 protected system resource. [Huff] 9815 $ penetration test 9816 (I) A system test, often part of system certification, in which 9817 evaluators attempt to circumvent the security features of a 9818 system. [NCS04, SP42] (See: tiger team.) 9820 Tutorial: Penetration testing evaluates the relative vulnerability 9821 of a system to attacks and identifies methods of gaining access to 9822 a system by using tools and techniques that are available to 9823 adversaries. Testing may be performed under various constraints 9824 and conditions, including a specified level of knowledge of the 9825 system design and implementation. For a TCSEC evaluation, testers 9826 are assumed to have all system design and implementation 9827 documentation, including source code, manuals, and circuit 9828 diagrams, and to work under no greater constraints than those 9829 applied to ordinary users. 9831 $ perfect forward secrecy 9832 (I) See: Usage under "public-key forward secrecy". 9834 $ perimeter 9835 See: security perimeter. 9837 $ periods processing 9838 (I) A mode of system operation in which information of different 9839 sensitivities is processed at distinctly different times by the 9840 same system, with the system being properly purged or sanitized 9841 between periods. (See: color change.) 9843 Tutorial: The security mode of operation and maximum 9844 classification of data handled by the system is established for an 9845 interval of time and then is changed for the following interval of 9846 time. A period extends from the secure initialization of the 9847 system to the completion of any purging of sensitive data handled 9848 by the system during the period. 9850 $ permanent storage 9851 (I) Non-volatile media that, once written into, can never be 9852 completely erased. 9854 $ permission 9855 1a. (I) A synonym for "authorization". (Compare: privilege.) 9856 1b. (N) An authorization or set of authorizations to perform 9857 security-relevant functions in the context of role-based access 9858 control. [ANSI] 9860 Tutorial: A permission is a positively stated authorization for 9861 access that (a) can be associated with one or more roles and (b) 9862 enables a user in a role to access a specified set of system 9863 resources by causing a specific set of system actions to be 9864 performed on the resources. 9866 $ persona certificate 9867 (I) An X.509 certificate issued to a system entity that wishes to 9868 use a persona to conceal its true identity when using PEM or other 9869 Internet services that depend on PKI support. (See: anonymity.) 9870 [R1422] 9872 Tutorial: PEM designers intended that (a) a CA issuing persona 9873 certificates would explicitly not be vouching for the identity of 9874 the system entity to whom the certificate is issued, (b) such 9875 certificates would be issued only by CAs subordinate to a policy 9876 CA having a policy stating that purpose (i.e., that would warn 9877 relying parties that the "subject" field DN represented only a 9878 persona and not a true, vetted user identity), and (c) the CA 9879 would not need to maintain records binding the true identity of 9880 the subject to the certificate. 9882 However, the PEM designers also intended that a CA issuing persona 9883 certificates would establish procedures (d) to enable "the holder 9884 of a PERSONA certificate to request that his certificate be 9885 revoked" and (e) to ensure that it did not issue the same subject 9886 DN to multiple users. The latter condition implies that a persona 9887 certificate is not an organizational certificate unless the 9888 organization has just one member or representative. 9890 $ personal identification number (PIN) 9891 1a. (I) A character string used as a password to gain access to a 9892 system resource. (See: authentication information.) 9894 1b. (O) An alphanumeric code or password used to authenticate an 9895 identity. 9897 Tutorial: Despite the words "identification" and "number", a PIN 9898 seldom serves as a user identifier, and a PIN's characters are not 9899 necessarily all numeric. Retail banking applications use 4-digit 9900 numeric user PINs, but the FORTEZZA PC card uses 12-character 9901 alphanumeric SSO PINs. 9903 Thus, a better name for this concept would have been "personnel 9904 authentication system string" (PASS), in which case an 9905 alphanumeric character string for this purpose would have been 9906 called, obviously, a "PASSword". 9908 $ personal information 9909 (I) Information about a particular person, especially information 9910 of an intimate or critical nature, that could cause harm or pain 9911 to that person if disclosed to unauthorized parties. Examples: 9912 medical record, arrest record, credit report, academic transcript, 9913 training report, job application, credit card number, Social 9914 Security number. (See: privacy.) 9916 $ personality 9917 1. (I) Synonym for "principal". 9919 2. (O) /MISSI/ A set of MISSI X.509 public-key certificates that 9920 have the same subject DN, together with their associated private 9921 keys and usage specifications, that is stored on a FORTEZZA PC 9922 card to support a role played by the card's user. 9924 Tutorial: When a card's user selects a personality to use in a 9925 FORTEZZA-aware application, the data determines behavior traits 9926 (the personality) of the application. A card's user may have 9927 multiple personalities on the card. Each has a "personality 9928 label", a user-friendly character string that applications can 9929 display to the user for selecting or changing the personality to 9930 be used. For example, a military user's card might contain three 9931 personalities: GENERAL HALFTRACK, COMMANDER FORT SWAMPY, and NEW 9932 YEAR'S EVE PARTY CHAIRMAN. Each personality includes one or more 9933 certificates of different types (such as DSA versus RSA), for 9934 different purposes (such as digital signature versus encryption), 9935 or with different authorizations. 9937 $ personnel authentication system string (PASS) 9938 (N) See: Tutorial under "personal identification number". 9940 $ personnel security 9941 (I) Procedures to ensure that persons who access a system have 9942 proper clearance, authorization, and need-to-know as required by 9943 the system's security policy. 9945 $ PGP(trademark) 9946 (O) See: Pretty Good Privacy(trademark). 9948 $ phase 1 negotiation 9949 $ phase 2 negotiation 9950 (I) /ISAKMP/ See: secondary definition under "Internet Security 9951 Association and Key Management Protocol". 9953 $ phishing 9954 (D) /slang/ A technique for attempting to acquire sensitive data, 9955 such as bank account numbers, through a fraudulent solicitation in 9956 email or on a Web site, in which the perpetrator masquerades as a 9957 legitimate business or reputable person. (See: social 9958 engineering.) 9959 Derivation: Possibly from "phony fishing"; the solicitation 9960 usually involves some kind of lure or bait to hook unwary 9961 recipients. 9963 Deprecated Term: ISDs SHOULD NOT use this term; it is not listed 9964 in most dictionaries and could confuse international readers. 9966 $ Photuris 9967 (I) A UDP-based, key establishment protocol for session keys, 9968 designed for use with the IPsec protocols AH and ESP. Superseded 9969 by IKE. 9971 $ phreaking 9972 (D) A contraction of "telephone breaking". An attack on or 9973 penetration of a telephone system or, by extension, any other 9974 communication or information system. [Raym] 9976 Deprecated Term: ISDs SHOULD NOT use this contraction; it is not 9977 listed in most dictionaries and could confuse international 9978 readers. 9980 $ physical security 9981 (I) Tangible means of preventing unauthorized physical access to a 9982 system. Examples: Fences, walls, and other barriers; locks, safes, 9983 and vaults; dogs and armed guards; sensors and alarm bells. 9984 [FP031, R1455] 9986 $ piggyback attack 9987 (I) A form of active wiretapping in which the attacker gains 9988 access to a system via intervals of inactivity in another user's 9989 legitimate communication connection. Sometimes called a "between- 9990 the-lines" attack. (See: hijack attack, man-in-the-middle attack.) 9992 Deprecated Usage: ISDs that use this term SHOULD state a 9993 definition for it because the term could confuse international 9994 readers. 9996 $ PIN 9997 (I) See: personal identification number. 9999 $ ping of death 10000 (D) A denial-of-service attack that sends an improperly large ICMP 10001 echo request packet (a "ping") with the intent of causing the 10002 destination system to fail. (See: ping sweep, teardrop.) 10004 Deprecated Term: ISDs SHOULD NOT use this term; instead, use "ping 10005 packet overflow attack" or some other term that is specific with 10006 regard to the attack mechanism. 10008 Tutorial: This attack seeks to exploit an implementation 10009 vulnerability. The IP specification requires hosts to be prepared 10010 to accept datagrams of up to 576 octets, but also permits IP 10011 datagrams to be up to 65,535 octets long. If an IP implementation 10012 does not properly handle very long IP packets, the ping packet may 10013 overflow the input buffer and cause a fatal system error. 10015 $ ping sweep 10016 (I) An attack that sends ICMP echo requests ("pings") to a range 10017 of IP addresses, with the goal of finding hosts that can be probed 10018 for vulnerabilities. (See: ping of death. Compare: port scan.) 10020 $ PKCS 10021 (N) See: Public-Key Cryptography Standards. 10023 $ PKCS #5 10024 (N) A standard [PKC05, R2898] from the PKCS series; defines a 10025 method for encrypting an octet string with a secret key derived 10026 from a password. 10028 Tutorial: Although the method can be used for arbitrary octet 10029 strings, its intended primary application in public-key 10030 cryptography is for encrypting private keys when transferring them 10031 from one computer system to another, as described in PKCS #8. 10033 $ PKCS #7 10034 (N) A standard [PKC07, R2315] from the PKCS series; defines a 10035 syntax for data that may have cryptography applied to it, such as 10036 for digital signatures and digital envelopes. (See: CMS.) 10038 $ PKCS #10 10039 (N) A standard [PKC10] from the PKCS series; defines a syntax for 10040 requests for public-key certificates. (See: certification 10041 request.) 10043 Tutorial: A PKCS #10 request contains a DN and a public key, and 10044 may contain other attributes, and is signed by the entity making 10045 the request. The request is sent to a CA, who converts it to an 10046 X.509 public-key certificate (or some other form), and returns it, 10047 possibly in PKCS #7 format. 10049 $ PKCS #11 10050 (N) A standard [PKC11] from the PKCS series; defines CAPI called 10051 "Cryptoki" for devices that hold cryptographic information and 10052 perform cryptographic functions. 10054 $ PKI 10055 (I) See: public-key infrastructure. 10057 $ PKIX 10058 1a. (I) A contraction of "Public-Key Infrastructure (X.509)", the 10059 name of the IETF working group that is specifying an architecture 10060 [R3280] and set of protocols [R2510] to provide X.509-based PKI 10061 services for the Internet. 10063 1b. (I) A collective name for that Internet PKI architecture and 10064 associated set of protocols. 10066 Tutorial: The goal of PKIX is to facilitate the use of X.509 10067 public-key certificates in multiple Internet applications and to 10068 promote interoperability between different implementations that 10069 use those certificates. The resulting PKI is intended to provide a 10070 framework that supports a range of trust and hierarchy 10071 environments and a range of usage environments. PKIX specifies (a) 10072 profiles of the v3 X.509 public-key certificate standards and the 10073 v2 X.509 CRL standards for the Internet, (b) operational protocols 10074 used by relying parties to obtain information such as certificates 10075 or certificate status, (c) management protocols used by system 10076 entities to exchange information needed for proper management of 10077 the PKI, and (d) information about certificate policies and CPSs, 10078 covering the areas of PKI security not directly addressed in the 10079 rest of PKIX. 10081 $ plain text 10082 (I) /noun/ Data that is input to and transformed by an encryption 10083 process, or that is output from a decryption process. (See: 10084 plaintext. Compare: cipher text, clear text.) 10086 Tutorial: Usually, the plain text that is the input to an 10087 encryption operation is clear text, but the input could be cipher 10088 text that was output from another encryption operation. (See: 10089 superencryption.) 10091 $ plaintext 10092 1. (I) /adjective/ Referring to plain text. (See: plain text. 10093 Compare: ciphertext, cleartext.) 10095 2. (D) /noun/ A synonym for plain text. 10097 Deprecated Usage: ISDs should not use this term as a synonym for 10098 "plain text". ISDs SHOULD distinguish between the adjective 10099 "plaintext" and the noun phrase "plain text". 10101 $ PLI 10102 (I) See: Private Line Interface. 10104 $ PMA 10105 (N) See: policy management authority. 10107 $ Point-to-Point Protocol (PPP) 10108 (I) An Internet Standard protocol (RFC 1661) for encapsulation and 10109 full-duplex transportation of protocol data packets in OSIRM Layer 10110 3 over an OSIRM Layer 2 link between two peers, and for 10111 multiplexing different Layer 3 protocols over the same link. 10112 Includes optional negotiation to select and use a peer entity 10113 authentication protocol to authenticate the peers to each other 10114 before they exchange Layer 3 data. (See: CHAP, EAP, PAP.) 10116 $ Point-to-Point Tunneling Protocol (PPTP) 10117 (I) An Internet client-server protocol (RFC 2637) (originally 10118 developed by Ascend and Microsoft) that enables a dial-up user to 10119 create a virtual extension of the dial-up link across a network by 10120 tunneling PPP over IP. (See: L2TP.) 10122 Tutorial: PPP can encapsulate any IPS Network Interface Layer 10123 protocol or OSIRM Layer 3 protocol. Therefore, PPTP does not 10124 specify security services; it depends on protocols above and below 10125 it to provide any needed security. PPTP makes it possible to 10126 divorce the location of the initial dial-up server (i.e., the PPTP 10127 Access Concentrator, the client, which runs on a special-purpose 10128 host) from the location at which the dial-up protocol (PPP) 10129 connection is terminated and access to the network is provided 10130 (i.e., at the PPTP Network Server, which runs on a general-purpose 10131 host). 10133 $ policy 10134 1a. (I) A plan or course of action that is stated for a system or 10135 organization and is intended to affect and direct the decisions 10136 and deeds of that entity's components or members. (See: security 10137 policy.) 10139 1b. (O) A definite goal, course, or method of action to guide and 10140 determine present and future decisions, that is implemented or 10141 executed within a particular context, such as within a business 10142 unit. [R3198] 10144 Deprecated Abbreviation: ISDs SHOULD NOT use "policy" as an 10145 abbreviation of either "security policy" or "certificate policy". 10146 Instead, to avoid misunderstanding, use a fully qualified term, at 10147 least at the point of first usage. 10149 Tutorial: The introduction of new technology to replace 10150 traditional systems can result in new systems being deployed 10151 without adequate policy definition and before the implications of 10152 the new technology are fully understand. In some cases, it can be 10153 difficult to establish policies for new technology before the 10154 technology has been operationally tested and evaluated. Thus, 10155 policy changes tend to lag behind technological changes, such that 10156 either old policies impede the technical innovation, or the new 10157 technology is deployed without adequate policies to govern its 10158 use. 10160 When new technology changes the ways that things are done, new 10161 "procedures" must be defined to establish operational guidelines 10162 for using the technology and achieving satisfactory results, and 10163 new "practices" must be established for managing new systems and 10164 monitoring results. Practices and procedures are more directly 10165 coupled to actual systems and business operations than are 10166 polices, which tend to be more abstract. 10168 - "Practices" define how a system is to be managed and what 10169 controls are in place to monitor the system and detect abnormal 10170 behavior or quality problems. Practices are established to 10171 ensure that a system is managed in compliance with stated 10172 policies. System audits are primarily concerned with whether or 10173 not practices are being followed. Auditors evaluate the 10174 controls to make sure they conform to accepted industry 10175 standards, and then confirm that controls are in place and that 10176 control measurements are being gathered. Audit trails are 10177 examples of control measurements that are recorded as part of 10178 system operations. 10179 - "Procedures" define how a system is operated, and relate 10180 closely to issues of what technology is used, who the operators 10181 are, and how the system is deployed physically. Procedures 10182 define both normal and abnormal operating circumstances. 10183 - For every control defined by a practice statement, there should 10184 be corresponding procedures to implement the control and 10185 provide ongoing measurement of the control parameters. 10186 Conversely, procedures require management practices to insure 10187 consistent and correct operational behavior. 10189 $ policy approval authority 10190 (D) /PKI/ Synonym for "policy management authority". [PAG] 10192 Deprecated Term: IDSs SHOULD NOT use this term as synonym for 10193 "policy management authority". The term suggests a limited, 10194 passive role that is not typical of PMAs. 10196 $ policy approving authority (PAA) 10197 (O) /MISSI/ The top-level signing authority of a MISSI 10198 certification hierarchy. The term refers both to that 10199 authoritative office or role and to the person who plays that 10200 role. (See: policy management authority, root registry.) 10202 Tutorial: A MISSI PAA (a) registers MISSI PCAs and signs their 10203 X.509 public-key certificates, (b) issues CRLs but does not issue 10204 a CKL, and (c) may issue cross-certificates to other PAAs. 10206 $ policy authority 10207 (D) /PKI/ Synonym for "policy management authority". [PAG] 10209 Deprecated Term: IDSs SHOULD NOT use this term as synonym for 10210 "policy management authority". The term is unnecessarily vague and 10211 thus may be confused with other PKI entities, such as CAs and RAs, 10212 that enforce of apply various aspects of PKI policy. 10214 $ policy certification authority (Internet PCA) 10215 (I) An X.509-compliant CA at the second level of the Internet 10216 certification hierarchy, under the IPRA. Each PCA operates in 10217 accordance with its published security policy (see: certificate 10218 policy, CPS) and within constraints established by the IPRA for 10219 all PCAs. [R1422]. (See: policy creation authority.) 10221 $ policy creation authority (MISSI PCA) 10222 (O) /MISSI/ The second level of a MISSI certification hierarchy; 10223 the administrative root of a security policy domain of MISSI users 10224 and other, subsidiary authorities. The term refers both to that 10225 authoritative office or role and to the person who fills that 10226 office. (See: policy certification authority.) 10228 Tutorial: A MISSI PCA's certificate is issued by a PAA. The PCA 10229 registers the CAs in its domain, defines their configurations, and 10230 issues their X.509 public-key certificates. (The PCA may also 10231 issue certificates for SCAs, ORAs, and other end entities, but a 10232 PCA does not usually do this.) The PCA periodically issues CRLs 10233 and CKLs for its domain. 10235 $ policy management authority (PMA) 10236 (I) /PKI/ A person, role, or organization within a PKI that is 10237 responsible for (a) creating or approving the content of the 10238 certificate policies and CPSs that are used in the PKI; (b) 10239 ensuring the administration of those policies; and (c) approving 10240 any cross-certification or interoperability agreements with CAs 10241 external to the PKI and any related policy mappings. The PMA may 10242 also be the accreditor for the PKI as a whole or for some of its 10243 components or applications. [DoD9, PAG] (See: policy approving 10244 authority.) 10246 Example: In the U.S. Department of Defense, an organization called 10247 the Policy Management Authority is responsible for DoD PKI [DoD9]. 10249 $ policy mapping 10250 (I) "Recognizing that, when a CA in one domain certifies a CA in 10251 another domain, a particular certificate policy in the second 10252 domain may be considered by the authority of the first domain to 10253 be equivalent (but not necessarily identical in all respects) to a 10254 particular certificate policy in the first domain." [X509] 10256 $ policy rule 10257 (I) A building block of a security policy; it (a) defines a set of 10258 system conditions and (b) specifies a set of system actions that 10259 are to be performed if those conditions occur. [R3198] 10261 $ POP3 10262 (I) See: Post Office Protocol, version 3. 10264 $ POP3 APOP 10265 (I) A POP3 command (better described as a transaction type, or 10266 subprotocol) by which a POP3 client optionally uses a keyed hash 10267 (based on MD5) to authenticate itself to a POP3 server and, 10268 depending on the server implementation, to protect against replay 10269 attacks. (See: CRAM, POP3 AUTH, IMAP4 AUTHENTICATE.) 10271 Tutorial: The server includes a unique timestamp in its greeting 10272 to the client. The subsequent APOP command sent by the client to 10273 the server contains the client's name and the hash result of 10274 applying MD5 to a string formed from both the timestamp and a 10275 shared secret value that is known only to the client and the 10276 server. APOP was designed to provide an alternative to using 10277 POP3's USER and PASS (i.e., password) command pair, in which the 10278 client sends a cleartext password to the server. 10280 $ POP3 AUTH 10281 (I) A POP3 command [R1734] (better described as a transaction 10282 type, or subprotocol) by which a POP3 client optionally proposes a 10283 mechanism to a POP3 server to authenticate the client to the 10284 server and provide other security services. (See: POP3 APOP, IMAP4 10285 AUTHENTICATE.) 10287 Tutorial: If the server accepts the proposal, the command is 10288 followed by performing a challenge-response authentication 10289 protocol and, optionally, negotiating a protection mechanism for 10290 subsequent POP3 interactions. The security mechanisms used by POP3 10291 AUTH are those used by IMAP4. 10293 $ port scan 10294 (I) An attack that sends client requests to a range of server port 10295 addresses on a host, with the goal of finding an active port and 10296 exploiting a known vulnerability of that service. (Compare: ping 10297 sweep.) 10299 $ positive authorization 10300 (I) The principle that a security architecture should be designed 10301 so that access to system resources is permitted only when 10302 explicitly granted; i.e., in the absence of an explicit 10303 authorization that grants access, the default action shall be to 10304 refuse access. (See: authorization, access.) 10306 $ POSIX 10307 (N) Portable Operating System Interface for Computer Environments, 10308 a standard [FP151, IS9945-1] (originally IEEE Standard P1003.1) 10309 that defines an operating system interface and environment to 10310 support application portability at the source code level. It is 10311 intended to be used by both application developers and system 10312 implementers. 10314 Tutorial: P1003.1 supports security functionality like that on 10315 most UNIX systems, including discretionary access control and 10316 privileges. IEEE Draft Standard P1003.6 specifies additional 10317 functionality not provided in the base standard, including (a) 10318 discretionary access control, (b) audit trail mechanisms, (c) 10319 privilege mechanisms, (d) mandatory access control, and (e) 10320 information label mechanisms. 10322 $ Post Office Protocol, version 3 (POP3) 10323 (I) An Internet Standard protocol (RFC 1939) by which a client 10324 workstation can dynamically access a mailbox on a server host to 10325 retrieve mail messages that the server has received and is holding 10326 for the client. (See: IMAP4.) 10328 Tutorial: POP3 has mechanisms for optionally authenticating a 10329 client to a server and providing other security services. (See: 10330 POP3 APOP, POP3 AUTH.) 10332 $ PPP 10333 (I) See: Point-to-Point Protocol. 10335 $ PPTP 10336 (I) See: Point-to-Point Tunneling Protocol. 10338 $ preauthorization 10339 (N) /PKI/ A CAW feature that enables certification requests to be 10340 automatically validated against data provided in advance to the CA 10341 by an authorizing entity. 10343 $ precedence 10344 (N) A designation assigned to a communication (i.e., packet, 10345 message, data stream, connection, etc.) by the originator to state 10346 the importance or urgency of that communication versus other 10347 communications, and thus indicate to the transmission system the 10348 relative order of handling, and indicate to the receiver the order 10349 in which the communication is to be noted. [F1037] (See: 10350 availability, critical, preemption.) 10352 Example: The "Precedence" subfield of the "Type of Service" field 10353 of the IPv4 header supports the following designations (in 10354 descending order of importance): 111 Network Control, 110 10355 Internetwork Control, 101 CRITIC/ECP (Critical Intelligence 10356 Communication/Emergency Command Precedence), 100 Flash Override, 10357 011 Flash, 010 Immediate, 001 Priority, and 000 Routine. These 10358 designations were adopted from U.S. DoD systems that existed 10359 before ARPANET. 10361 $ preemption 10362 (N) The seizure, usually automatic, of system resources that are 10363 being used to serve a lower precedence communication, in order to 10364 serve immediately a higher precedence communication. [F1037] 10366 $ Pretty Good Privacy(trademark) (PGP(trademark)) 10367 (O) Trademarks of Network Associates, Inc., referring to a 10368 computer program (and related protocols) that uses cryptography to 10369 provide data security for electronic mail and other applications 10370 on the Internet. (Compare: MOSS, MSP, PEM, S/MIME.) 10372 Tutorial: PGP encrypts messages with IDEA in CFB mode, distributes 10373 the IDEA keys by encrypting them with RSA, and creates digital 10374 signatures on messages with MD5 and RSA. To establish ownership of 10375 public keys, PGP depends on the web of trust. 10377 $ prevention 10378 (I) See: secondary definition under "security". 10380 $ primary account number (PAN) 10381 (O) /SET/ "The assigned number that identifies the card issuer and 10382 cardholder. This account number is composed of an issuer 10383 identification number, an individual account number 10384 identification, and an accompanying check digit as defined by ISO 10385 7812-1985." [SET2, IS7812] (See: bank identification number.) 10387 Tutorial: The PAN is embossed, encoded, or both on a magnetic- 10388 strip-based credit card. The PAN identifies the issuer to which a 10389 transaction is to be routed and the account to which it is to be 10390 applied unless specific instructions indicate otherwise. The 10391 authority that assigns the BIN part of the PAN is the American 10392 Bankers Association. 10394 $ principal 10395 (I) A specific identity claimed by a user when accessing a system. 10397 Usage: Usually understood to be an identity that is registered in 10398 and authenticated by the system; equivalent to the notion of login 10399 account identifier. Each principal is normally assigned to a 10400 single user, but a single user may be assigned (or attempt to use) 10401 more than one principal. Each principal can spawn one or more 10402 subjects, but each subject is associated with only one principal. 10403 (Compare: role, subject, user.) 10405 (N) /Kerberos/ A uniquely named client or server instance that 10406 participates in a network communication. 10408 $ privacy 10409 1. (I) The right of an entity (normally a person), acting in its 10410 own behalf, to determine the degree to which it will interact with 10411 its environment, including the degree to which the entity is 10412 willing to share its personal information with others. (See: 10413 HIPAA, personal information, Privacy Act of 1974. Compare: 10414 anonymity, data confidentiality.) 10416 2. (O) "The right of individuals to control or influence what 10417 information related to them may be collected and stored and by 10418 whom and to whom that information may be disclosed." [I7498-2] 10420 3. (D) Synonym for "data confidentiality". 10422 Deprecated Definition: ISDs SHOULD NOT use this term as a synonym 10423 for "data confidentiality" or "data confidentiality service", 10424 which are different concepts. Privacy is a reason for security 10425 rather than a kind of security. For example, a system that stores 10426 personal data needs to protect the data to prevent harm, 10427 embarrassment, inconvenience, or unfairness to any person about 10428 whom data is maintained, and to protect the person's privacy. For 10429 that reason, the system may need to provide data confidentiality 10430 service. 10432 $ Privacy Act of 1974 10433 (O) A U.S. Federal law (Section 552a of Title 5, United States 10434 Code) that seeks to balance the U.S. Government's need to maintain 10435 data about individuals with the rights of individuals to be 10436 protected against unwarranted invasions of their privacy stemming 10437 from federal agencies' collection, maintenance, use, and 10438 disclosure of personal data. (See: privacy.) 10440 Tutorial: In 1974, the U.S. Congress was concerned with the 10441 potential for abuses that could arise from the Government's 10442 increasing use of computers to store and retrieve personal data. 10443 Therefore, the Act has four basic policy objectives: 10444 - To restrict disclosure of personally identifiable records 10445 maintained by Federal agencies. 10446 - To grant individuals increased rights of access to Federal 10447 agency records maintained on themselves. 10448 - To grant individuals the right to seek amendment of agency 10449 records maintained on themselves upon a showing that the 10450 records are not accurate, relevant, timely, or complete. 10451 - To establish a code of "fair information practices" that 10452 requires agencies to comply with statutory norms for 10453 collection, maintenance, and dissemination of records. 10455 $ Privacy Enhanced Mail (PEM) 10456 (I) An Internet protocol to provide data confidentiality, data 10457 integrity, and data origin authentication for electronic mail. 10458 [R1421, R1422]. (Compare: MOSS, MSP, PGP, S/MIME.) 10460 Tutorial: PEM encrypts messages with DES in CBC mode, provides 10461 distribution for DES keys by encrypting them with RSA, and signs 10462 messages with RSA over either MD2 or MD5. To establish ownership 10463 of public keys, PEM uses a certification hierarchy, with X.509 10464 public-key certificates and X.509 CRLs that are signed with RSA 10465 and MD2. 10467 PEM is designed to be compatible with a wide range of key 10468 management methods, but is limited to specifying security services 10469 only for text messages and, like MOSS, has not been widely 10470 implemented in the Internet. 10472 $ private component 10473 (I) Synonym for "private key". 10475 Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; 10476 instead, to avoid confusing readers, use "private key". However, 10477 the term MAY be used when discussing a key pair; e.g., "A key pair 10478 has a public component and a private component." 10480 $ private extension 10481 (I) See: secondary definition under "extension". 10483 $ private key 10484 1. (I) The secret component of a pair of cryptographic keys used 10485 for asymmetric cryptography. (See: key pair, public key, secret 10486 key.) 10488 2. (O) In a public key cryptosystem, "that key of a user's key 10489 pair which is known only by that user." [X509] 10491 $ Private Line Interface (PLI) 10492 (I) The first end-to-end packet encryption system for a computer 10493 network, developed by BBN starting in 1975 for the U.S. DoD, 10494 incorporating Government-furnished, military-grade COMSEC 10495 equipment (TSEC/KG-34). [B1822] (Compare: IPLI.) 10497 $ privilege 10498 1a. (I) /access control/ A synonym for "authorization". (See 10499 authorization. Compare: permission.) 10501 1b. (I) /computer platform/ An authorization to perform a 10502 security-relevant function in the context of a computer's 10503 operating system. 10505 $ privilege management infrastructure 10506 (O) "The infrastructure able to support the management of 10507 privileges in support of a comprehensive authorization service and 10508 in relationship with a" PKI; i.e., processes concerned with 10509 attribute certificates. [X509] 10511 Deprecated Usage: ISDs SHOULD NOT use this term with this 10512 definition. This definition is vague, and there is no consensus on 10513 a more specific one. 10515 $ privileged process 10516 (I) An computer process that is authorized (and, therefore, 10517 trusted) to perform some security-relevant functions that ordinary 10518 processes are not. (See: privilege, trusted process.) 10520 $ privileged user 10521 (I) An user that has access to system control, monitoring, or 10522 administration functions. (See: privilege, /UNIX/ under "root", 10523 superuser, user.) 10525 Tutorial: Privileged users include the following types: 10526 - Users with near or complete control of a system, who are 10527 authorized to set up and administer user accounts, identifiers, 10528 and authentication information, or are authorized to assign or 10529 change other users' access to system resources. 10530 - Users that are authorized to change control parameters (e.g., 10531 network addresses, routing tables, processing priorities) on 10532 routers, multiplexers, and other important equipment. 10533 - Users that are authorized to monitor or perform troubleshooting 10534 for a system's security functions, typically using special 10535 tools and features that are not available to ordinary users. 10537 $ probe 10538 (I) /verb/ To access an information system in an attempt to gather 10539 information about the system for the purpose of circumventing the 10540 system's security measures. 10542 $ procedural security 10543 (D) Synonym for "administrative security". 10545 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 10546 "administrative security". The term may be misleading because any 10547 type of security may involve procedures, and procedures may be 10548 either external to the system or internal. Instead, use 10549 "administrative security", "communication security", "computer 10550 security", "emanations security", "personnel security", "physical 10551 security", or whatever specific type is meant. (See: security 10552 architecture.) 10554 $ profile 10555 See: certificate profile, protection profile. 10557 $ proof-of-possession protocol 10558 (I) A protocol whereby a system entity proves to another that it 10559 possesses and controls a cryptographic key or other secret 10560 information. (See: zero-knowledge proof.) 10562 $ proprietary 10563 (I) Refers to information (or other property) that is owned by an 10564 individual or organization and for which the use is restricted by 10565 that entity. 10567 $ protected checksum 10568 (I) A checksum that is computed for a data object by means that 10569 protect against active attacks that would attempt to change the 10570 checksum to make it match changes made to the data object. (See: 10571 digital signature, keyed hash, Tutorial under "checksum".) 10573 $ protective packaging 10574 (N) Packaging techniques for COMSEC material that discourage 10575 penetration, reveal a penetration has occurred or was attempted, 10576 or inhibit viewing or copying of keying material prior to the time 10577 it is exposed for use. [C4008] (See: tamper-evident, tamper- 10578 resistant. Compare: QUADRANT.) 10580 $ protection authority 10581 (I) See: secondary definition under "Internet Protocol Security 10582 Option". 10584 $ protection level 10585 (N) /U.S. Government/ An indication of the trust that is needed in 10586 a system's technical ability to enforce security policy for 10587 confidentiality. (Compare: /system operation/ under "mode of 10588 operation".) 10590 Tutorial: An organization's security policy could define 10591 protection levels that are based on (a) the sensitivity of 10592 information handled by a system compared to (b) the authorizations 10593 of users that receive information from the system without manual 10594 intervention and reliable human review. For each level, the policy 10595 could specify security features and assurances that must be 10596 included in any system that was intended to operate at that level. 10598 Example: Given some set of data objects that are classified at one 10599 or more hierarchical levels and in one or more non-hierarchical 10600 categories, the following table defines five protection levels for 10601 systems that would handle that data. Beginning with PL1 and 10602 evolving to PL5, each successive level would require stronger 10603 features and assurances to handle the dataset. (See: clearance, 10604 formal access approval, and need-to-know.) 10606 Lowest Clearance Formal Access Need-To-Know 10607 Among All Users Approval of Users of Users 10608 +-------------------+-------------------+-------------------+ 10609 PL5 | Some user has no | [Does not matter.]| [Does not matter.]| 10610 High | clearance at all. | | | 10611 +-------------------+-------------------+-------------------+ 10612 PL4 | All are cleared | [Does not matter.]| [Does not matter.]| 10613 | for some data. | | | 10614 +-------------------+-------------------+-------------------+ 10615 PL3 | All are cleared | Some not approved | [Does not matter.]| 10616 | for all data. | for all data. | | 10617 +-------------------+-------------------+-------------------+ 10618 PL2 | All are cleared | All are approved | Some don't need to| 10619 | for all data. | for all data. | to know all data. | 10620 +-------------------+-------------------+-------------------+ 10621 PL1 | All are cleared | All are approved | All have a need | 10622 Low | for all data. | for all data. | to know all data.| 10623 +-------------------+-------------------+-------------------+ 10625 Each of these protection levels can be viewed as being equivalent 10626 to one or more modes of system operation defined in this Glossary: 10627 - PL5 is equivalent to multilevel security mode. 10628 - PL4 is equivalent to either multilevel or compartmented 10629 security mode, depending on the details of users' clearances. 10630 - PL3 is equivalent to partitioned security mode. 10631 - PL2 is equivalent to system-high security mode. 10632 - PL1 is equivalent to dedicated security mode. 10634 $ protection profile 10635 (N) /Common Criteria/ An implementation-independent set of 10636 security requirements for a category of targets of evaluation that 10637 meet specific consumer needs. [CCIB] Example: [IDSAN]. (See: 10638 target of evaluation. Compare: certificate profile, package.) 10640 Tutorial: A protection profile (PP) is the kind of document used 10641 by consumers to specify functional requirements they want in a 10642 product, and a target of evaluation (TOE) is the kind of document 10643 used by vendors to make functional claims about a product. 10645 A PP is intended to be a reusable statement of product security 10646 needs, which are known to be useful and effective, for a set of 10647 information technology security products that could be built. A PP 10648 contains a set of security requirements, preferably taken from the 10649 catalogs in Parts 2 and 3 of the Common Criteria, and should 10650 include an EAL. A PP could be developed by user communities, 10651 product developers, or any other parties interested in defining a 10652 common set of requirements. 10654 $ protection ring 10655 (I) One of a hierarchy of privileged operation modes of a system 10656 that gives certain access rights to processes authorized to 10657 operate in that mode. (See: Multics.) 10659 $ protective distribution system (PDS) 10660 (N) A wireline or fiber-optic communication system used to 10661 transmit cleartext classified information through an area of 10662 lesser classification or control. [N7003] 10664 $ protocol 10665 1a. (I) A set of rules (i.e., formats and procedures) to implement 10666 and control some type of association (e.g., communication) between 10667 systems. Example: Internet Protocol. 10669 1b. (I) A series of ordered computing and communication steps that 10670 are performed by two or more system entities to achieve a joint 10671 objective. [A9042] 10673 $ protocol control information (PCI) 10674 (N) See: secondary definition under "protocol data unit". 10676 $ protocol data unit (PDU) 10677 (N) A data packet that is defined for peer-to-peer transfers in a 10678 protocol layer. 10680 Tutorial: A PDU consists of two disjoint subsets of data: the SDU 10681 and the PCI. (Although these terms -- PDU, SDU, and PCI -- 10682 originated in the OSIRM, they are also useful and permissible in 10683 an IPS context.) 10684 - The "service data unit" (SDU) in a packet is data that the 10685 protocol transfers between peer protocol entities on behalf of 10686 the users of that layer's services. For Layers 1 through 6, the 10687 layer's users are peer protocol entities at a higher layer; for 10688 Layer 7, the users are application entities outside the scope 10689 of the OSIRM. 10690 - The "protocol control information" (PCI) in a packet is data 10691 that peer protocol entities exchange between themselves to 10692 control their joint operation of the layer. 10694 $ protocol suite 10695 (I) A complementary collection of communication protocols used in 10696 a computer network. (See: IPS, OSI.) 10698 $ proxy 10699 1. (I) A computer process that acts on behalf of a user or client. 10701 2. (I) A computer process -- often used as, or as part of, a 10702 firewall -- that relays a protocol between client and server 10703 computer systems, by appearing to the client to be the server and 10704 appearing to the server to be the client. (See: SOCKS.) 10706 Tutorial: In a firewall, a proxy server usually runs on a bastion 10707 host, which may support proxies for several protocols (e.g., FTP, 10708 HTTP, and TELNET). Instead of a client in the protected enclave 10709 connecting directly to an external server, the internal client 10710 connects to the proxy server which in turn connects to the 10711 external server. The proxy server waits for a request from inside 10712 the firewall, forwards the request to the server outside the 10713 firewall, gets the response, then sends the response back to the 10714 client. The proxy may be transparent to the clients, or they may 10715 need to connect first to the proxy server, and then use that 10716 association to also initiate a connection to the real server. 10718 Proxies are generally preferred over SOCKS for their ability to 10719 perform caching, high-level logging, and access control. A proxy 10720 can provide security service beyond that which is normally part of 10721 the relayed protocol, such as access control based on peer entity 10722 authentication of clients, or peer entity authentication of 10723 servers when clients do not have that ability. A proxy at OSIRM 10724 Layer 7 can also provide finer-grained security service than can a 10725 filtering router at Layer 3. For example, an FTP proxy could 10726 permit transfers out of, but not into, a protected network. 10728 $ proxy certificate 10729 (I) An X.509 public-key certificate derived from a end-entity 10730 certificate, or from another proxy certificate, for the purpose of 10731 establishing proxies and delegating authorizations in the context 10732 of a PKI-based authentication system. [R3280] 10734 Tutorial: A proxy certificate has the following properties: 10735 - It contains an critical extension that (a) identifies it as a 10736 proxy certificate and (b) may contain a certification path 10737 length constraint and policy constraints. 10738 - It contains the public component of a key pair that is distinct 10739 from that associated with any other certificate. 10741 - It is signed by the private component of a key pair that is 10742 associated with an end-entity certificate or another proxy 10743 certificate. 10744 - Its associated private key can be used to sign only other proxy 10745 certificates (not end-entity certificates). 10746 - Its "subject" DN is derived from its "issuer" DN and is unique. 10747 - Its "issuer" DN is the "subject" DN of an end-entity 10748 certificate or another proxy certificate. 10750 $ pseudorandom 10751 (I) A sequence of values that appears to be random (i.e., 10752 unpredictable) but is actually generated by a deterministic 10753 algorithm. (See: compression, random, random number generator.) 10755 $ pseudorandom number generator 10756 (I) See: secondary definition under "random number generator". 10758 $ public component 10759 (I) Synonym for "public key". 10761 Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; to 10762 avoid confusing readers, use "private key" instead. However, the 10763 term MAY be used when discussing a key pair; e.g., "A key pair has 10764 a public component and a private component." 10766 $ public key 10767 1. (I) The publicly disclosable component of a pair of 10768 cryptographic keys used for asymmetric cryptography. (See: key 10769 pair. Compare: private key.) 10771 2. (O) In a public key cryptosystem, "that key of a user's key 10772 pair which is publicly known." [X509] 10774 $ public-key certificate 10775 1. (I) A digital certificate that binds a system entity's 10776 identifier to a public key value, and possibly to additional, 10777 secondary data items; i.e., a digitally signed data structure that 10778 attests to the ownership of a public key. (See: X.509 public-key 10779 certificate.) 10781 2. (O) "The public key of a user, together with some other 10782 information, rendered unforgeable by encipherment with the private 10783 key of the certification authority which issued it." [X509] 10785 Tutorial: The digital signature on a public-key certificate is 10786 unforgeable. Thus, the certificate can be published, such as by 10787 posting it in a directory, without the directory having to protect 10788 the certificate's data integrity. 10790 $ public-key cryptography 10791 (I) Synonym for "asymmetric cryptography". 10793 $ Public-Key Cryptography Standards (PKCS) 10794 (N) A series of specifications published by RSA Laboratories for 10795 data structures and algorithms used in basic applications of 10796 asymmetric cryptography. (See: PKCS #5 through PKCS #11.) 10798 Tutorial: The PKCS were begun in 1991 in cooperation with industry 10799 and academia, originally including Apple, Digital, Lotus, 10800 Microsoft, Northern Telecom, Sun, and MIT. Today, the 10801 specifications are widely used, but they are not sanctioned by an 10802 official standards organization, such as ANSI, ITU-T, or IETF. RSA 10803 Laboratories retains sole decision-making authority over the PKCS. 10805 $ public-key forward secrecy (PFS) 10806 (I) For a key-agreement protocol based on asymmetric cryptography, 10807 the property that ensures that a session key derived from a set of 10808 long-term public and private keys will not be compromised if one 10809 of the private keys is compromised in the future. 10811 Usage: Some existing RFCs use the term "perfect forward secrecy" 10812 but either do not define it or do not define it precisely. While 10813 preparing this Glossary, we tried to find a good definition for 10814 that term, but found this to be a muddled area. Experts did not 10815 agree. For all practical purposes, the literature defines "perfect 10816 forward secrecy" by stating the Diffie-Hellman algorithm. The term 10817 "public-key forward secrecy" (suggested by Hilarie Orman) and the 10818 "I" definition stated for it here were crafted to be compatible 10819 with current Internet documents, yet be narrow and leave room for 10820 improved terminology. 10822 Challenge to the Internet security community: We need a taxonomy 10823 of terms and definitions to cover the basic properties discussed 10824 here for the full range of cryptographic algorithms and protocols 10825 used in Internet Standards: 10827 Involvement of session keys vs. long-term keys: Experts disagree 10828 about the basic ideas involved: 10829 - One concept of "forward secrecy" is that, given observations of 10830 the operation of a key establishment protocol up to time t, and 10831 given some of the session keys derived from those protocol 10832 runs, you cannot derive unknown past session keys or future 10833 session keys. 10834 - A related property is that, given observations of the protocol 10835 and knowledge of the derived session keys, you cannot derive 10836 one or more of the long-term private keys. 10837 - The "I" definition presented above involves a third concept of 10838 "forward secrecy" that refers to the effect of the compromise 10839 of long-term keys. 10840 - All three concepts involve the idea that a compromise of "this" 10841 encryption key is not supposed to compromise the "next" one. 10842 There also is the idea that compromise of a single key will 10843 compromise only the data protected by the single key. In 10844 Internet literature, the focus has been on protection against 10845 decryption of back traffic in the event of a compromise of 10846 secret key material held by one or both parties to a 10847 communication. 10849 Forward vs. backward: Experts are unhappy with the word "forward", 10850 because compromise of "this" encryption key also is not supposed 10851 to compromise the "previous" one, which is "backward" rather than 10852 forward. In S/KEY, if the key used at time t is compromised, then 10853 all keys used prior to that are compromised. If the "long-term" 10854 key (i.e., the base of the hashing scheme) is compromised, then 10855 all keys past and future are compromised; thus, you could say that 10856 S/KEY has neither forward nor backward secrecy. 10858 Asymmetric cryptography vs. symmetric: Experts disagree about 10859 forward secrecy in the context of symmetric cryptographic systems. 10860 In the absence of asymmetric cryptography, compromise of any long- 10861 term key seems to compromise any session key derived from the 10862 long-term key. For example, Kerberos isn't forward secret, because 10863 compromising a client's password (thus compromising the key shared 10864 by the client and the authentication server) compromises future 10865 session keys shared by the client and the ticket-granting server. 10867 Ordinary forward secrecy vs. "perfect" forward secret: Experts 10868 disagree about the difference between these two. Some say there is 10869 no difference, and some say that the initial naming was 10870 unfortunate and suggest dropping the word "perfect". Some suggest 10871 using "forward secrecy" for the case where one long-term private 10872 key is compromised, and adding "perfect" for when both private 10873 keys (or, when the protocol is multi-party, all private keys) are 10874 compromised. 10876 Acknowledgements: Bill Burr, Burt Kaliski, Steve Kent, Paul Van 10877 Oorschot, Michael Wiener, and, especially, Hilarie Orman 10878 contributed ideas to this discussion. 10880 $ public-key infrastructure (PKI) 10881 1. (I) A system of CAs (and, optionally, RAs and other supporting 10882 servers and agents) that perform some set of certificate 10883 management, archive management, key management, and token 10884 management functions for a community of users in an application of 10885 asymmetric cryptography. (See: hierarchical PKI, mesh PKI, 10886 security management infrastructure, trust-file PKI.) 10888 2. (I) /PKIX/ The set of hardware, software, people, policies, and 10889 procedures needed to create, manage, store, distribute, and revoke 10890 digital certificates based on asymmetric cryptography. 10892 Tutorial: The core PKI functions are (a) to register users and 10893 issue their public-key certificates, (b) to revoke certificates 10894 when required, and (c) to archive data needed to validate 10895 certificates at a much later time. Key pairs for data 10896 confidentiality may be generated (and perhaps escrowed) by CAs or 10897 RAs, but requiring a PKI client to generate its own digital 10898 signature key pair helps maintain system integrity of the 10899 cryptographic system, because then only the client ever possesses 10900 the private key it uses. Also, an authority may be established to 10901 approve or coordinate CPSs, which are security policies under 10902 which components of a PKI operate. 10904 A number of other servers and agents may support the core PKI, and 10905 PKI clients may obtain services from them. The full range of such 10906 services is not yet fully understood and is evolving, but 10907 supporting roles may include archive agent, certified delivery 10908 agent, confirmation agent, digital notary, directory, key escrow 10909 agent, key generation agent, naming agent who ensures that issuers 10910 and subjects have unique identifiers within the PKI, repository, 10911 ticket-granting agent, and time-stamp agent. 10913 $ purge 10914 (I) Use degaussing or other means to render (magnetically) stored 10915 data unusable and unrecoverable by any means, including laboratory 10916 methods. [C4009] (See: zeroize. Compare: erase, sanitize.) 10918 $ QUADRANT 10919 (O) /U.S. Government/ Short name for technology and methods that 10920 protect cryptographic equipment by making the equipment tamper- 10921 resistant. [C4009] (Compare: protective packaging, TEMPEST.) 10923 Tutorial: Equipment cannot be made completely tamper-proof, but it 10924 can be made tamper-resistant or tamper-evident. 10926 $ qualified certificate 10927 (I) A public-key certificate that has the primary purpose of 10928 identifying a person with a high level of assurance, where the 10929 certificate meets some qualification requirements defined by an 10930 applicable legal framework, such as the European Directive on 10931 Electronic Signature [EU-ESDIR]. [R3739]. 10933 $ quick mode 10934 (I) See: /IKE/ under "mode". 10936 $ RA 10937 (I) See: registration authority. 10939 $ RA domains 10940 (I) A feature of a CAW that allows a CA to divide the 10941 responsibility for certificate requests among multiple RAs. 10943 Tutorial: This ability might be used to restrict access to private 10944 authorization data that is provided with a certificate request, 10945 and to distribute the responsibility to review and approve 10946 certificate requests in high volume environments. RA domains might 10947 segregate certificate requests according to an attribute of the 10948 certificate's subject, such as an organizational unit. 10950 $ RADIUS 10951 (I) See: Remote Authentication Dial-In User Service. 10953 $ Rainbow Series 10954 (O) /COMPUSEC/ A set of more than 30 technical and policy 10955 documents with colored covers, issued by the NCSC, that discuss in 10956 detail the TCSEC and provide guidance for meeting and applying the 10957 criteria. (See: Green Book, Orange Book, Red Book, Yellow Book.) 10959 $ random 10960 (I) In essence, "random" means "unpredictable". [SP22, Knut, 10961 R1750] (See: cryptographic key, pseudorandom.) 10962 - "Random sequence": A sequence in which each successive value is 10963 obtained merely by chance and does not depend on the preceding 10964 values of the sequence. In a random sequence of bits, each bit 10965 is unpredictable; i.e., (a) the probability of each bit being a 10966 "0" or "1" is 1/2, and (b) the value of each bit is independent 10967 of any other bit in the sequence. 10968 - "Random value": A individual value that is unpredictable; i.e., 10969 each value in the total population of possibilities has equal 10970 probability of being selected. 10972 $ random number generator 10973 (I) A process that is invoked to generate a random sequence of 10974 values (usually a sequence of bits) or an individual random value. 10976 Tutorial: There are two basic types of generators. [SP22] 10977 - "(True) random number generator": It uses one or more non- 10978 deterministic bit sources (e.g., electrical circuit noise, 10979 timing of human processes such as key strokes or mouse 10980 movements, semiconductor quantum effects, and other physical 10981 phenomena) and a processing function that formats the bits, and 10982 it outputs a sequence of values that is unpredictable and 10983 uniformly distributed. 10984 - "Pseudorandom number generator": It uses a deterministic 10985 computational process (usually implemented by software) that 10986 has one or more inputs called "seeds", and it outputs a 10987 sequence of values that appears to be random according to 10988 specified statistical tests. 10990 $ RBAC 10991 (N) See: role-based access control, rule-based access control. 10993 Deprecated Usage: ISDs that use this term SHOULD state a 10994 definition for it because the abbreviation is ambiguous. 10996 $ RC2, RC4, RC6 10997 (N) See: Rivest Cipher #2, #4, #6. 10999 $ read 11000 (I) A fundamental operation in an information system that results 11001 only in the flow of information from an object to a subject. (See: 11002 access mode.) 11004 $ realm 11005 (O) /Kerberos/ The domain of authority of a Kerberos server 11006 (consisting of an authentication server and a ticket-granting 11007 server), including the Kerberized clients and the Kerberized 11008 application servers. (See: domain.) 11010 $ recovery 11011 1. (I) /cryptography/ The process of learning or obtaining 11012 cryptographic data or plain text through cryptanalysis. (See: key 11013 recovery, data recovery.) 11015 2a. (I) /system integrity/ The process of restoring a secure state 11016 in a system after there has been an accidental failure or a 11017 successful attack. (See: secondary definition under "security", 11018 system integrity.) 11020 2b. (I) /system integrity/ The process of restoring an information 11021 system's assets and operation following damage or destruction. 11022 (See: contingency plan.) 11024 $ RED 11025 1. (I) Designation for data that consists only of clear text, and 11026 for information system equipment items and facilities that handle 11027 clear text. Example: "RED key". (See: color change, RED/BLACK 11028 separation. Compare: BLACK.) 11030 Derivation: From the practice of marking equipment with colors to 11031 prevent operational errors. 11033 2. (O) /U.S. Government/ Designation applied to information 11034 systems, and to associated areas, circuits, components, and 11035 equipment, "in which unencrypted national security information is 11036 being processed." [C4009] 11038 $ RED/BLACK separation 11039 (I) An architectural concept for cryptographic systems that 11040 strictly separates the parts of a system that handle plain text 11041 (i.e., RED information) from the parts that handle cipher text 11042 (i.e., BLACK information). (See: BLACK, RED.) 11044 $ Red Book 11045 (D) /slang/ Synonym for "Trusted Network Interpretation of the 11046 Trusted Computer System Evaluation Criteria" [NCS05]. 11048 Deprecated Term: ISDs SHOULD NOT use this term. Instead, use the 11049 full proper name of the document or, in subsequent references, a 11050 more conventional abbreviation, e.g., TNI-TCSEC. (See: TCSEC, 11051 Rainbow Series, Deprecated Usage under "Green Book".) 11053 $ RED key 11054 (I) A cleartext key, which is usable in its present form (i.e., it 11055 does not need to be decrypted before being used). (See: RED. 11056 Compare: BLACK key.) 11058 $ reference monitor 11059 (I) "An access control concept that refers to an abstract machine 11060 that mediates all accesses to objects by subjects." [NCS04] (See: 11061 security kernel.) 11063 Tutorial: This concept was described in the Anderson report. A 11064 reference monitor should be (a) complete (i.e., it mediates every 11065 access), (b) isolated (i.e., it cannot be modified by other system 11066 entities), and (c) verifiable (i.e., small enough to be subjected 11067 to analysis and tests to ensure that it is correct). 11069 $ reflection attack 11070 (I) An attack in which a valid data transmission is maliciously or 11071 fraudulently retransmitted, either by an adversary who intercepts 11072 the data or by its originator. (Compare: replay attack.) 11074 $ registered user 11075 (I) A system entity that is authorized to receive a system's 11076 products and services or otherwise access system resources. (See: 11077 registration, user.) 11079 $ registration 11080 1. (I) /information system/ A system process that (a) initializes 11081 an identity (of a system entity) in the system, (b) establishes an 11082 identifier for that identity, (c) may associate authentication 11083 information with that identifier, and (d) may issue an identifier 11084 credential (depending on the type of authentication mechanism 11085 being used). (See: authentication information, credential, 11086 identifier, identity, identity proofing.) 11088 2. (I) /PKI/ An administrative act or process whereby an entity's 11089 name and other attributes are established for the first time at a 11090 CA, prior to the CA issuing a digital certificate that has the 11091 entity's name as the subject. (See: registration authority.) 11093 Tutorial: Registration may be accomplished either directly, by the 11094 CA, or indirectly, by a separate RA. An entity is presented to the 11095 CA or RA, and the authority either records the name(s) claimed for 11096 the entity or assigns the entity's name(s). The authority also 11097 determines and records other attributes of the entity that are to 11098 be bound in a certificate (such as a public key or authorizations) 11099 or maintained in the authority's database (such as street address 11100 and telephone number). The authority is responsible, possibly 11101 assisted by an RA, for verifying the entity's identity and vetting 11102 the other attributes, in accordance with the CA's CPS. 11104 Among the registration issues that a CPS may address are the 11105 following [R3647]: 11106 - How a claimed identity and other attributes are verified. 11107 - How organization affiliation or representation is verified. 11108 - What forms of names are permitted, such as X.500 DN, domain 11109 name, or IP address. 11110 - Whether names are required to be meaningful or unique, and 11111 within what domain. 11112 - How naming disputes are resolved, including the role of 11113 trademarks. 11114 - Whether certificates are issued to entities that are not 11115 persons. 11116 - Whether a person is required to appear before the CA or RA, or 11117 can instead be represented by an agent. 11118 - Whether and how an entity proves possession of the private key 11119 matching a public key. 11121 $ registration authority (RA) 11122 1. (I) An optional PKI entity (separate from the CAs) that does 11123 not sign either digital certificates or CRLs but has 11124 responsibility for recording or verifying some or all of the 11125 information (particularly the identities of subjects) needed by a 11126 CA to issue certificates and CRLs and to perform other certificate 11127 management functions. (See: ORA, registration.) 11129 2. (I) /PKIX/ An optional PKI component, separate from the CA(s). 11130 The functions that the RA performs will vary from case to case but 11131 may include identity authentication and name assignment, key 11132 generation and archiving of key pairs, token distribution, and 11133 revocation reporting. [R2510] 11135 Tutorial: Sometimes, a CA may perform all certificate management 11136 functions for all end users for which the CA signs certificates. 11137 Other times, such as in a large or geographically dispersed 11138 community, it may be necessary or desirable to offload secondary 11139 CA functions and delegate them to an assistant, while the CA 11140 retains the primary functions (signing certificates and CRLs). The 11141 tasks that are delegated to an RA by a CA may include personal 11142 authentication, name assignment, token distribution, revocation 11143 reporting, key generation, and archiving. 11145 An RA is an optional PKI entity, separate from the CA, that is 11146 assigned secondary functions. The duties assigned to RAs vary from 11147 case to case but may include the following: 11148 - Verifying a subject's identity, i.e., performing personal 11149 authentication functions. 11150 - Assigning a name to a subject. (See: distinguished name.) 11151 - Verifying that a subject is entitled to have the attributes 11152 requested for a certificate. 11153 - Verifying that a subject possesses the private key that matches 11154 the public key requested for a certificate. 11155 - Performing functions beyond mere registration, such as 11156 generating key pairs, distributing tokens, handling revocation 11157 reports, and archiving data. (Such functions may be assigned to 11158 a PKI component that is separate from both the CA and the RA.) 11160 3. (O) /SET/ "An independent third-party organization that 11161 processes payment card applications for multiple payment card 11162 brands and forwards applications to the appropriate financial 11163 institutions." [SET2] 11165 $ regrade 11166 (I) Deliberately change the security level (especially the 11167 hierarchical classification level) of information in an authorized 11168 manner. (See: downgrade, upgrade.) 11170 $ rekey 11171 (I) Change the value of a cryptographic key that is being used in 11172 an application of a cryptographic system. (See: certificate 11173 rekey.) 11175 Tutorial: Rekey is required at the end of a cryptoperiod or key 11176 lifetime. 11178 $ reliability 11179 (I) The ability of a system to perform a required function under 11180 stated conditions for a specified period of time. (Compare: 11181 availability, survivability.) 11183 $ reliable human review 11184 (I) Any manual, automated, or hybrid process or procedure for 11185 opening and reviewing a digital object, such as text or an image, 11186 to determine whether the object may be permitted, according to 11187 some security policy, to be transferred across a controlled 11188 interface. (See: guard.) 11190 $ relying party 11191 (I) Synonym for "certificate user". 11193 Usage: Used in a legal context to mean a recipient of a 11194 certificate who acts in reliance on that certificate. (See: ABA 11195 Guidelines.) 11197 $ remanence 11198 (I) Residual information that can be recovered from a storage 11199 medium after clearing. (See: clear, magnetic remanence, purge.) 11201 $ Remote Authentication Dial-In User Service (RADIUS) 11202 (I) An Internet protocol [R2865] for carrying dial-in users' 11203 authentication information and configuration information between a 11204 shared, centralized authentication server (the RADIUS server) and 11205 a network access server (the RADIUS client) that needs to 11206 authenticate the users of its network access ports. (See: TACACS.) 11208 Tutorial: A user of the RADIUS client presents authentication 11209 information to the client, and the client passes that information 11210 to the RADIUS server. The server authenticates the client using a 11211 shared secret value, then checks the user's authentication 11212 information, and finally returns to the client all authorization 11213 and configuration information needed by the client to deliver 11214 service to the user. 11216 $ renew 11217 See: certificate renewal. 11219 $ replay attack 11220 (I) An attack in which a valid data transmission is maliciously or 11221 fraudulently repeated, either by the originator or by an adversary 11222 who intercepts the data and retransmits it, possibly as part of a 11223 masquerade attack. (See: active wiretapping, fresh, liveness, 11224 nonce. Compare: reflection attack.) 11226 $ reordering 11227 (I) /packet/ See: secondary definition under "stream integrity 11228 service". 11230 $ repository 11231 1. (I) A system for storing and distributing digital certificates 11232 and related information (including CRLs, CPSs, and certificate 11233 policies) to certificate users. (Compare: archive, directory.) 11235 2. (O) "A trustworthy system for storing and retrieving 11236 certificates or other information relevant to certificates." [DSG] 11238 Tutorial: A certificate is published to those who might need it by 11239 putting it in a repository. The repository usually is a publicly 11240 accessible, on-line server. In the FPKI, for example, the expected 11241 repository is a directory that uses LDAP, but also may be an X.500 11242 Directory that uses DAP, or an HTTP server, or an FTP server that 11243 permits anonymous login. 11245 $ repudiation 11246 1. (I) Denial by a system entity that was involved in an 11247 association (especially a communication association that transfers 11248 data) of having participated in the relationship. (See: 11249 accountability, non-repudiation service.) 11251 2. (I) A type of threat action whereby an entity deceives another 11252 by falsely denying responsibility for an act. (See: deception.) 11254 Usage: This type of threat action includes the following subtypes: 11255 - False denial of origin: Action whereby an originator denies 11256 responsibility for sending data. 11257 - False denial of receipt: Action whereby a recipient denies 11258 receiving and possessing data. 11260 3. (O) /OSIRM/ "Denial by one of the entities involved in a 11261 communication of having participated in all or part of the 11262 communication." [I7498-2] 11264 $ Request for Comment (RFC) 11265 1. (I) One of the documents in the archival series that is the 11266 official channel for ISDs and other publications of the Internet 11267 Engineering Steering Group, the Internet Architecture Board, and 11268 the Internet community in general. (RFC 2026, 2223) (See: Internet 11269 Standard.) 11271 2. (D) A popularly misused synonym for a document on the Internet 11272 Standards Track, i.e., an Internet Standard, Draft Standard, or 11273 Proposed Standard. (See: Internet Standard.) 11275 Deprecated Definition: This term SHOULD NOT be used as a synonym 11276 for a document on the Internet Standards Track because many other 11277 types of documents also are published as RFCs. 11279 $ residual risk 11280 (I) The portion of an original risk or set of risks that remains 11281 after countermeasures have been applied. (Compare: acceptable 11282 risk, risk analysis.) 11284 $ restore 11285 See: card restore. 11287 $ revocation 11288 See: certificate revocation. 11290 $ revocation date 11291 (N) /X.509/ In a CRL entry, a date-time field that states when the 11292 certificate revocation occurred, i.e., when the CA declared the 11293 digital certificate to be invalid. (See: invalidity date.) 11295 Tutorial: The revocation date may not resolve some disputes 11296 because, in the worst case, all signatures made during the 11297 validity period of the certificate may have to be considered 11298 invalid. However, it may be desirable to treat a digital signature 11299 as valid even though the private key used to sign was compromised 11300 after the signing. If more is known about when the compromise 11301 actually occurred, a second date-time, an "invalidity date", can 11302 be included in an extension of the CRL entry. 11304 $ revocation list 11305 See: certificate revocation list. 11307 $ revoke 11308 (I) See: certificate revocation. 11310 $ RFC 11311 (I) See: Request for Comment. 11313 $ Rijndael 11314 (N) A symmetric, block cipher that was designed by Joan Daemen and 11315 Vincent Rijmen as a candidate for the AES, and that won that 11316 competition. [Daem] (See: Advanced Encryption Standard.) 11318 $ risk 11319 1. (I) An expectation of loss expressed as the probability that a 11320 particular threat will exploit a particular vulnerability with a 11321 particular harmful result. (See: residual risk.) 11323 2. (O) /SET/ "The possibility of loss because of one or more 11324 threats to information (not to be confused with financial or 11325 business risk)." [SET2] 11327 Tutorial: There are four basic ways to deal with a risk [SP30]: 11328 - "Risk avoidance": Eliminate the risk by either countering the 11329 threat or removing the vulnerability. (Compare: "avoidance" 11330 under "security".) 11331 - "Risk transference": Shift the risk to another system or 11332 entity; e.g., buy insurance to compensate for potential loss. 11333 - "Risk limitation": Limit the risk by implementing controls that 11334 minimize resulting loss. 11335 - "Risk assumption": Accept the potential for loss and continue 11336 operating the system. 11338 $ risk analysis 11339 (I) An assessment process that systematically (a) identifies 11340 valuable system resources and threats to those resources, (b) 11341 quantifies loss exposures (i.e., loss potential) based on 11342 estimated frequencies and costs of occurrence, and (c) 11343 (optionally) recommends how to allocate available resources to 11344 countermeasures so as to minimize total exposure. (See: risk 11345 management, business-case analysis. Compare: threat analysis.) 11347 Tutorial: Usually, it is financially and technically infeasible to 11348 avoid or transfer all risks (see: "first corollary" of "second 11349 law" under "Courtney's laws"), and some residual risks will 11350 remain, even after all available countermeasures have been 11351 deployed (see: "second corollary" of "second law" under 11352 "Courtney's laws"). Thus, a risk analysis typically lists risks in 11353 order of cost and criticality, thereby determining where 11354 countermeasures should be applied first. [FP031, R2196] 11356 In some contexts, it is infeasible or inadvisable to attempt a 11357 complete or quantitative risk analysis because needed data, time, 11358 and expertise are not available. Instead, basic answers to 11359 questions about threats and risks may be already built into 11360 institutional security policies. For example, U.S. DoD policies 11361 for data confidentiality "do not explicitly itemize the range of 11362 expected threats" but instead "reflect an operational approach ... 11363 by stating the particular management controls that must be used to 11364 achieve [confidentiality] ... Thus, they avoid listing threats, 11365 which would represent a severe risk in itself, and avoid the risk 11366 of poor security design implicit in taking a fresh approach to 11367 each new problem". [NRC91] 11369 $ risk assumption 11370 (I) See: secondary definition under "risk". 11372 $ risk avoidance 11373 (I) See: secondary definition under "risk". 11375 $ risk limitation 11376 (I) See: secondary definition under "risk". 11378 $ risk management 11379 1. (I) The process of identifying, measuring, and controlling 11380 (i.e., mitigating) risks in information systems so as to reduce 11381 the risks to a level commensurate with the value of the assets 11382 protected. (See: risk analysis.) 11384 2. (I) The process of controlling uncertain events that may affect 11385 information system resources. 11387 3. (O) "The total process of identifying, controlling, and 11388 mitigating information system- Drelated risks. It includes risk 11389 assessment; cost-benefit analysis; and the selection, 11390 implementation, test, and security evaluation of safeguards. This 11391 overall system security review considers both effectiveness and 11392 efficiency, including impact on the mission and constraints due to 11393 policy, regulations, and laws." [SP30] 11395 $ risk transference 11396 (I) See: secondary definition under "risk". 11398 $ Rivest Cipher #2 (RC2) 11399 (N) A proprietary, variable-key-length block cipher invented by 11400 Ron Rivest for RSA Data Security, Inc. 11402 $ Rivest Cipher #4 (RC4) 11403 (N) A proprietary, variable-key-length stream cipher invented by 11404 Ron Rivest for RSA Data Security, Inc. 11406 $ Rivest Cipher #6 (RC6) 11407 (N) A symmetric, block cipher with 128-bit or longer key length, 11408 developed by Ron Rivest for RSA Data Security, Inc. as a candidate 11409 for the AES. 11411 $ Rivest-Shamir-Adleman (RSA) 11412 (N) An algorithm for asymmetric cryptography, invented in 1977 by 11413 Ron Rivest, Adi Shamir, and Leonard Adleman [RSA78]. 11415 Tutorial: RSA uses exponentiation modulo the product of two large 11416 prime numbers. The difficulty of breaking RSA is believed to be 11417 equivalent to the difficulty of factoring integers that are the 11418 product of two large prime numbers of approximately equal size. 11420 To create an RSA key pair, randomly choose two large prime 11421 numbers, p and q, and compute the modulus, n = pq. Randomly choose 11422 a number e, the public exponent, that is less than n and 11423 relatively prime to (p-1)(q-1). Choose another number d, the 11424 private exponent, such that ed-1 evenly divides (p-1)(q-1). The 11425 public key is the set of numbers (n,e), and the private key is the 11426 set (n,d). 11428 It is assumed to be difficult to compute the private key (n,d) 11429 from the public key (n,e). However, if n can be factored into p 11430 and q, then the private key d can be computed easily. Thus, RSA 11431 security depends on the assumption that it is computationally 11432 difficult to factor a number that is the product of two large 11433 prime numbers. (Of course, p and q are treated as part of the 11434 private key, or else are destroyed after computing n.) 11436 For encryption of a message, m, to be sent to Bob, Alice uses 11437 Bob's public key (n,e) to compute m**e (mod n) = c. She sends c to 11438 Bob. Bob computes c**d (mod n) = m. Only Bob knows d, so only Bob 11439 can compute c**d (mod n) to recover m. 11441 To provide data origin authentication of a message, m, to be sent 11442 to Bob, Alice computes m**d (mod n) = s, where (d,n) is Alice's 11443 private key. She sends m and s to Bob. To recover the message that 11444 only Alice could have sent, Bob computes s**e (mod n) = m, where 11445 (e,n) is Alice's public key. 11447 To ensure data integrity in addition to data origin authentication 11448 requires extra computation steps in which Alice and Bob use a 11449 cryptographic hash function h (see: digital signature). Alice 11450 computes the hash value h(m) = v, and then encrypts v with her 11451 private key to get s. She sends m and s. Bob receives m' and s', 11452 either of which might have been changed from the m and s that 11453 Alice sent. To test this, he decrypts s' with Alice's public key 11454 to get v'. He then computes h(m') = v". If v' equals v", Bob is 11455 assured that m' is the same m that Alice sent. 11457 $ robustness 11458 (N) See: level of robustness. 11460 $ role 11461 1. (I) A job function (or a job title that implies a function) to 11462 which people or other system entities may be assigned in a system. 11463 (See: role-based access control. Compare: duty, billet, principal, 11464 user.) 11466 2. (O) /Common Criteria/ A pre-defined set of rules establishing 11467 the allowed interactions between a user and the TOE. 11469 $ role-based access control 11470 (I) A form of identity-based access control wherein the system 11471 entities that are identified and controlled are functional 11472 positions in an organization or process. [Sand] (See: 11473 authorization, constraint, identity, principal, role.) 11475 Tutorial: Administrators assign permissions to roles as needed to 11476 perform functions in the system. Administrators separately assign 11477 user identities to roles. When a user accesses the system in an 11478 identity (for which the user has been registered) and initiates a 11479 session using a role (to which the user has been assigned), then 11480 the permissions that have been assigned to the role are available 11481 to be exercised by the user. 11483 The following diagram shows that role-based access control 11484 involves five different relationships: (a) administrators assign 11485 identities to roles, (b) administrators assign permissions to 11486 roles, (c) administrators assign roles to roles, (d) users select 11487 identities in sessions, and (e) users select roles in sessions. 11488 Security policies may define constraints on these assignments and 11489 selections. 11491 (c) Permission Inheritance Assignments (i.e., Role Hierarchy) 11492 [Constraints] 11493 +=====+ 11494 | | 11495 (a) Identity v v (b) Permission 11496 +----------+ Assignments +-------+ Assignments +----------+ 11497 |Identities|<=============>| Roles |<=============>|Permissions| 11498 +----------+ [Constraints] +-------+ [Constraints] +----------+ 11499 | | ^ ^ 11500 | | +-----------+ | | +---------------------+ 11501 | | | +-------+ | | | | Legend | 11502 | +====>|Session|=====+ | | | 11503 | | +-------+ | | | One-to-One | 11504 | | ... | | | =================== | 11505 | | +-------+ | | | | 11506 +========>|Session|=========+ | One-to-Many | 11507 (d) Identity | +-------+ | (e) Role | ==================> | 11508 Selections | | Selections | | 11509 [Constraints]| Access |[Constraints] | Many-to-Many | 11510 | Sessions | | <=================> | 11511 +-----------+ +---------------------+ 11513 $ role certificate 11514 (I) An organizational certificate that is issued to a system 11515 entity that is a member of the set of users that have identities 11516 that are assigned to the same role. (See: role-based access 11517 control.) 11519 $ root, root CA 11520 1. (I) /PKI/ A CA that is directly trusted by an end entity. (See: 11522 trust anchor, trusted CA.) 11524 2. (I) /hierarchical PKI/ The CA that is the highest level (most 11525 trusted) CA in a certification hierarchy; i.e., the authority upon 11526 whose public key all certificate users base their validation of 11527 certificates, CRLs, certification paths, and other constructs. 11528 (See: top CA.) 11530 Tutorial: The root CA in a certification hierarchy issues public- 11531 key certificates to one or more additional CAs that form the 11532 second highest level. Each of these CAs may issue certificates to 11533 more CAs at the third highest level, and so on. To initialize 11534 operation of a hierarchical PKI, the root's initial public key is 11535 securely distributed to all certificate users in a way that does 11536 not depend on the PKI's certification relationships, i.e., by an 11537 out-of-band procedure. The root's public key may be distributed 11538 simply as a numerical value, but typically is distributed in a 11539 self-signed certificate in which the root is the subject. The 11540 root's certificate is signed by the root itself because there is 11541 no higher authority in a certification hierarchy. The root's 11542 certificate is then the first certificate in every certification 11543 path. 11545 3. (I) /DNS/ The base of the tree structure that defines the name 11546 space for the Internet DNS. (See: domain name.) 11548 4. (O) /MISSI/ A name previously used for a MISSI policy creation 11549 authority, which is not a root as defined above for general usage, 11550 but is a CA at the second level of the MISSI hierarchy, 11551 immediately subordinate to a MISSI policy approving authority. 11553 5. (O) /UNIX/ A user account (also called "superuser") that has 11554 all privileges (including all security-related privileges) and 11555 thus can manage the system and its other user accounts. 11557 $ root certificate 11558 1. (I) /PKI/ A certificate for which the subject is a root. (See: 11559 trust anchor certificate, trusted certificate.) 11561 2. (I) /hierarchical PKI/ The self-signed public-key certificate 11562 at the top of a certification hierarchy. 11564 $ root key 11565 (I) /PKI/ A public key for which the matching private key is held 11566 by a root. (See: trust anchor key, trusted key.) 11568 $ root registry 11569 (O) /MISSI/ A name previously used for a MISSI PAA. 11571 $ ROT13 11572 (I) See: secondary definition under "Caesar cipher". 11574 $ router 11575 1a. (I) /IP/ A networked computer that forwards IP packets that 11576 are not addressed to the computer itself. (Compare: host.) 11578 1b. (I) /IPS/ A gateway that operates in the IPS Internet Layer to 11579 connect two or more subnetworks. 11581 1c. (N) /OSIRM/ A computer that is a gateway between two networks 11582 at OSIRM Layer 3 and that relays and directs data packets through 11583 that internetwork. (Compare: bridge, proxy.) 11585 $ RSA 11586 (N) See: Rivest-Shamir-Adleman. 11588 $ rule 11589 See: policy rule. 11591 $ rule-based security policy 11592 (I) "A security policy based on global rules [i.e., policy rules] 11593 imposed for all users. These rules usually rely on comparison of 11594 the sensitivity of the resource being accessed and the possession 11595 of corresponding attributes of users, a group of users, or 11596 entities acting on behalf of users." [I7498-2] (Compare: identity- 11597 based security policy, policy rule, RBAC.) 11599 $ rules of behavior 11600 (I) A body of security policy that has been established and 11601 implemented concerning the responsibilities and expected behavior 11602 of entities that have access to a system. (Compare: [R1281].) 11604 Tutorial: For persons employed by a corporation or government, the 11605 rules might cover such matters as working at home, remote access, 11606 use of the Internet, use of copyrighted works, use of system 11607 resources for unofficial purpose, assignment and limitation of 11608 system privileges, and individual accountability. 11610 $ S field 11611 (D) See: Security Level field. 11613 $ S-BGP 11614 (I) See: Secure BGP. 11616 $ S-HTTP 11617 (I) See: Secure Hypertext Transfer Protocol. 11619 $ S/Key 11620 (I) A security mechanism that uses a cryptographic hash function 11621 to generate a sequence of 64-bit, one-time passwords for remote 11622 user login. [R1760] 11624 Tutorial: The client generates a one-time password by applying the 11625 MD4 cryptographic hash function multiple times to the user's 11626 secret key. For each successive authentication of the user, the 11627 number of hash applications is reduced by one. (Thus, an intruder 11628 using wiretapping cannot compute a valid password from knowledge 11629 of one previously used.) The server verifies a password by hashing 11630 the currently presented password (or initialization value) one 11631 time and comparing the hash result with the previously presented 11632 password. 11634 $ S/MIME 11635 (I) See: Secure/MIME. 11637 $ SAD 11638 (I) See: Security Association Database. 11640 $ safety 11641 (I) The property of a system being free from risk of causing harm 11642 (especially physical harm) to its system entities. (Compare: 11643 security.) 11645 $ SAID 11646 (I) See: security association identifier. 11648 $ salt 11649 (I) A data value used to vary the results of a computation in a 11650 security mechanism, so that an exposed computational result from 11651 one instance of applying the mechanism cannot be reused by an 11652 attacker in another instance. (Compare: initialization value.) 11654 Example: A password-based access control mechanism might protect 11655 against capture or accidental disclosure of its password file by 11656 applying a one-way encryption algorithm to passwords before 11657 storing them in the file. To increase the difficulty of off-line, 11658 dictionary attacks that match encrypted values of potential 11659 passwords against a copy of the password file, the mechanism can 11660 concatenate each password with its own random salt value before 11661 applying the one-way function. 11663 $ SAML 11664 (N) See: Security Assertion Markup Language (SAML). 11666 $ sandbox 11667 (I) A restricted, controlled execution environment that prevents 11668 potentially malicious software, such as mobile code, from 11669 accessing any system resources except those for which the software 11670 is authorized. 11672 $ sanitize 11673 1. (I) Delete sensitive data from a file, device, or system. 11675 2. (I) Modify data so as to be able either (a) to completely 11676 declassify it or (b) to downgrade it to a lower security level. 11678 $ SAP 11679 (O) See: special access program. 11681 $ SASL 11682 (I) See: Simple Authentication and Security Layer. 11684 $ SCA 11685 (I) See: subordinate certification authority. 11687 $ scavenging 11688 (I) See: secondary definition under "threat consequence". 11690 $ SCI 11691 (O) See: sensitive compartmented information. 11693 $ SCIF 11694 (O) See: sensitive compartmented information facility. 11696 $ SCOMP 11697 (N) Secure COMmunications Processor; an enhanced, MLS version of 11698 the Honeywell Level 6 minicomputer. It was the first system to be 11699 rated in TCSEC Class A1. (See: KSOS.) 11701 $ screen room 11702 (D) /slang/ Synonym for "shielded enclosure" in the context of 11703 electromagnetic emanations. (See: EMSEC, TEMPEST.) 11705 Deprecated Term: To avoid international misunderstanding, ISDs 11706 SHOULD NOT use this term. 11708 $ screening router 11709 (I) Synonym for "filtering router". 11711 $ script kiddy 11712 (D) /slang/ A cracker who is able to use existing attack 11713 techniques (i.e., to read scripts) and execute existing attack 11714 software, but is unable to invent new exploits or manufacture the 11715 tools to perform them; pejoratively, an immature or novice 11716 cracker. 11718 Deprecated Term: It is likely that other cultures use different 11719 metaphors for this concept. Therefore, to avoid international 11720 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 11721 Usage under "Green Book".) 11723 $ SDE 11724 (N) See: Secure Data Exchange. 11726 $ SDNS 11727 (O) See: Secure Data Network System. 11729 $ SDU 11730 (N) See: "service data unit" under "protocol data unit". 11732 $ seal 11733 1. (I) To use asymmetric cryptography to encrypt plain text with a 11734 public key in such a way that only the holder of the matching 11735 private key can learn what was the plain text. [Chau] (Compare: 11736 shroud, wrap.) 11738 Deprecated Term: ISDs SHOULD NOT use this term as defined here; 11739 the definition duplicates the meaning of other, standard terms. 11740 Instead, use "encrypt" or another term that is specific with 11741 regard to the mechanism being used. 11743 Tutorial: The definition does *not* say "only the holder of the 11744 matching private key can decrypt the ciphertext to learn what was 11745 the plaintext"; sealing is stronger than that. If Alice simply 11746 encrypts a plaintext P with a public key K to produce ciphertext C 11747 = K(P), then if Bob guesses that P = X, Bob could verify the guess 11748 by checking whether K(P) = K(X). To "seal" P and block Bob's 11749 guessing attack, Alice could attach a long string R of random bits 11750 to P before encrypting to produce C = K(P,R); if Bob guesses that 11751 P = X, Bob can only test the guess by also guessing R. 11753 2. (D) To use cryptography to provide data integrity service for a 11754 data object. (See: sign.) 11756 Deprecated Definition: ISDs SHOULD NOT use this term with 11757 definition 2. Instead, use a term that is more specific with 11758 regard to the mechanism used to provide the data integrity 11759 service; e.g., use "sign" when the mechanism is digital signature. 11761 $ secret 11762 1a. (I) /adjective/ The condition of information being protected 11763 from being known by any system entities except those that are 11764 intended to know it. 11766 1b. (I) /noun/ An item of information that is protected thusly. 11768 Usage: This term applies to symmetric keys, private keys, and 11769 passwords. 11771 $ secret key 11772 (D) A key that is kept secret or needs to be kept secret. 11774 Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts 11775 in a potentially misleading way. In the context of asymmetric 11776 cryptography, ISDs SHOULD use "private key". In the context of 11777 symmetric cryptography, the adjective "secret" is unnecessary 11778 because all keys must be kept secret. 11780 $ secret-key cryptography 11781 (D) Synonym for "symmetric cryptography". 11783 Deprecated Term: ISDs SHOULD NOT use this term; it could be 11784 confused with asymmetric cryptography, in which the private key is 11785 kept secret. 11787 Derivation: Symmetric cryptography is sometimes called "secret-key 11788 cryptography" because entities that share the key, such as the 11789 originator and the recipient of a message, need to keep the key 11790 secret from other entities. 11792 $ Secure BGP (S-BGP) 11793 (I) A project of BBN Technologies, sponsored by the U.S. DoD's 11794 Defense Advanced Research Projects Agency, to design and 11795 demonstrate an architecture to secure the Border Gateway Protocol 11796 (RFC 1771) and to promote deployment of that architecture in the 11797 Internet. 11799 Tutorial: S-BGP incorporates three security mechanisms: 11800 - A PKI supports authentication of ownership of IP address 11801 blocks, autonomous system (AS) numbers, an AS's identity, and a 11802 BGP router's identity and its authorization to represent an AS. 11803 This PKI parallels and takes advantage of the Internet's 11804 existing IP address and AS number assignment system. 11805 - A new, optional, BGP transitive path attribute carries digital 11806 signatures (in "attestations") covering the routing information 11807 in a BGP UPDATE. These signatures along with certificates from 11808 the S-BGP PKI enable the receiver of a BGP routing UPDATE to 11809 validate the attribute and gain trust in the address prefixes 11810 and path information that it contains. 11811 - IPsec provides data and partial sequence integrity, and enables 11812 BGP routers to authenticate each other for exchanges of BGP 11813 control traffic. 11815 $ Secure Data Exchange (SDE) 11816 (N) A LAN security protocol defined by the IEEE 802.10 standard. 11818 $ Secure Data Network System (SDNS) 11819 (O) An NSA program that developed security protocols for 11820 electronic mail (see: MSP), OSIRM Layer 3 (see: SP3), OSIRM Layer 11821 4 (see: SP4), and key establishment (see: KMP). 11823 $ secure distribution 11824 (I) See: trusted distribution. 11826 $ Secure Hash Algorithm (SHA) 11827 (N) A cryptographic hash function (specified in SHS) that produces 11828 a 160-bit output (hash result) for input data of any length < 11829 2**64 bits. 11831 $ Secure Hash Standard (SHS) 11832 (N) The U.S. Government standard [FP180] that specifies SHA. 11834 $ Secure Hypertext Transfer Protocol (S-HTTP) 11835 (I) A Internet protocol [R2660] for providing client-server 11836 security services for HTTP communications. (Compare: https.) 11838 Tutorial: S-HTTP was originally specified by CommerceNet, a 11839 coalition of businesses interested in developing the Internet for 11840 commercial uses. Several message formats may be incorporated into 11841 S-HTTP clients and servers, particularly CMS and MOSS. S-HTTP 11842 supports choice of security policies, key management mechanisms, 11843 and cryptographic algorithms through option negotiation between 11844 parties for each transaction. S-HTTP supports modes of operation 11845 for both asymmetric and symmetric cryptography. S-HTTP attempts to 11846 avoid presuming a particular trust model, but it attempts to 11847 facilitate multiply rooted, hierarchical trust and anticipates 11848 that principals may have many public-key certificates. 11850 $ Secure/MIME (S/MIME) 11851 (I) Secure/Multipurpose Internet Mail Extensions, an Internet 11852 protocol [R3851] to provide encryption and digital signatures for 11853 Internet mail messages. 11855 $ secure multicast 11856 (I) Refers generally to providing security services for multicast 11857 groups of various types (e.g., 1-to-N and M-to-N) and to classes 11858 of protocols used to protect multicast packets. 11860 Tutorial: Multicast applications include video broadcast and 11861 multicast file transfer, and many of these applications require 11862 network security services. The Multicast Security Reference 11863 Framework [R3740] covers three functional areas: 11864 - Multicast data handling: Security-related treatment of 11865 multicast data by the sender and the receiver. 11866 - Group key management: Secure distribution and refreshment of 11867 keying material. (See: Group Domain of Interpretation.) 11868 - Multicast security policy: Policy translation and 11869 interpretation across the multiple administrative domains that 11870 typically are spanned by a multicast application. 11872 $ Secure Shell(trademark) (SSH(trademark)) 11873 (N) Trademarks of SSH Communications Security Corp. that refer to 11874 a protocol for secure remote login and other secure network 11875 services. 11877 Tutorial: SSH has three main parts: 11878 - Transport layer protocol: Provides server authentication, 11879 confidentiality, and integrity; and can optionally provide 11880 compression. This layer typically runs over a TCP connection, 11881 but might also run on top of any other reliable data stream. 11882 - User authentication protocol: Authenticates the client-side 11883 user to the server. It runs over the transport layer protocol. 11884 - Connection protocol: Multiplexes the encrypted tunnel into 11885 several logical channels. It runs over the user authentication 11886 protocol. 11888 $ Secure Sockets Layer (SSL) 11889 (N) An Internet protocol (originally developed by Netscape 11890 Communications, Inc.) that uses connection-oriented end-to-end 11891 encryption to provide data confidentiality service and data 11892 integrity service for traffic between a client (often a web 11893 browser) and a server, and that can optionally provide peer entity 11894 authentication between the client and the server. (See: Transport 11895 Layer Security.) 11897 Tutorial: SSL has two layers; SSL's lower layer, the SSL Record 11898 Protocol, is layered on top of an IPS Transport-Layer protocol and 11899 encapsulates protocols that run in the upper layer. The upper 11900 layer protocols are the three SSL management protocols -- SSL 11901 Handshake Protocol, SSL Change Cipher Spec Protocol, or SSL Alert 11902 Protocol -- and some Application-Layer protocol (e.g., HTTP). 11904 The SSL management protocols provide asymmetric cryptography for 11905 server authentication (verifying the server's identity to the 11906 client) and optional client authentication (verifying the client's 11907 identity to the server), and also enable them, before the 11908 application protocol transmits or receives data, to negotiate a 11909 symmetric encryption algorithm and secret session key (to use for 11910 data confidentiality service) and a keyed hash (to use for data 11911 integrity service). 11913 SSL is independent of the application it encapsulates, and any 11914 application can layer on top of SSL transparently. However, many 11915 Internet applications might be better served by IPsec. 11917 $ secure state 11918 1a. (I) A system condition in which the system is in conformance 11919 with the applicable security policy. (Compare: clean system, 11920 transaction.) 11922 1b. (I) /formal model/ A system condition in which no subject can 11923 access any object in an unauthorized manner. (See: secondary 11924 definition under "Bell-LaPadula model".) 11926 $ security 11927 1a. (I) A system condition that results from the establishment and 11928 maintenance of measures to protect the system. 11930 1b. (I) A system condition in which system resources are free from 11931 unauthorized access and from unauthorized or accidental change, 11932 destruction, or loss. (Compare: safety.) 11934 2. (I) Measures taken to protect a system. 11936 Tutorial: Parker suggests that providing a condition of system 11937 security may involve the following six basic functions [Park]; 11938 however, these functions overlap to some extent: 11939 - "Deterrence": Reducing an intelligent threat by discouraging 11940 action, such as by fear or doubt. (See: attack, threat action.) 11941 - "Avoidance": Reducing a risk by either reducing the value of 11942 the potential loss or reducing the probability that the loss 11943 will occur. (See: risk analysis. Compare: "risk avoidance" 11944 under "risk".) 11945 - "Prevention": Impeding a security violation by using a 11946 countermeasure. 11947 - "Detection": Determining that a security violation is 11948 impending, is in progress, or has recently occurred, and thus 11949 make it possible to reduce the potential loss. (See: intrusion 11950 detection.) 11951 - "Recovery": Restoring a normal state of system operation by 11952 compensating for a security violation, possibly by eliminating 11953 or repairing its effects. (See: contingency plan, main entry 11954 for "recovery".) 11955 - "Correction": Changing a security architecture to eliminate or 11956 reduce the risk of reoccurrence of a security violation or 11957 threat consequence, such as by eliminating a vulnerability. 11959 $ security architecture 11960 (I) A plan and set of principles that describe (a) the security 11961 services that a system is required to provide to meet the needs of 11962 its users, (b) the system components required to implement the 11963 services, and (c) the performance levels required in the 11964 components to deal with the threat environment (e.g., [R2179]). 11965 (See: defense in depth, IATF, security controls, Tutorial under 11966 "security policy". Compare: OSIRM System Architecture.) 11968 Tutorial: A security architecture is the result of applying the 11969 system engineering process. A complete system security 11970 architecture includes administrative security, communication 11971 security, computer security, emanations security, personnel 11972 security, and physical security. A complete security architecture 11973 needs to deal with both intentional, intelligent threats and 11974 accidental threats. 11976 $ Security Assertion Markup Language (SAML) 11977 (N) A protocol consisting of XML-based request and response 11978 message formats for exchanging security information, expressed in 11979 the form of assertions about subjects, between online business 11980 partners. [SAML] 11982 $ security association 11983 1. (I) A relationship established between two or more entities to 11984 enable them to protect data they exchange. (See: association, 11985 ISAKMP, SAD. Compare: session.) 11986 Tutorial: The relationship is represented by a set of data that is 11987 shared between the entities and is agreed upon and considered a 11988 contract between them. The data describes how the associated 11989 entities jointly use security services. The relationship is used 11990 to negotiate characteristics of security mechanisms, but the 11991 relationship is usually understood to exclude the mechanisms 11992 themselves. 11994 2. (I) /IPsec/ A simplex (uni-directional) logical connection 11995 created for security purposes and implemented with either AH or 11996 ESP (but not both). The security services offered by a security 11997 association depend on the protocol (AH or ESP), the IPsec mode 11998 (transport or tunnel), the endpoints, and the election of optional 11999 services within the protocol. A security association is identified 12000 by a triple consisting of (a) a destination IP address, (b) a 12001 protocol (AH or ESP) identifier, and (c) a Security Parameter 12002 Index. 12004 3. (O) "A set of policy and cryptographic keys that provide 12005 security services to network traffic that matches that policy". 12006 [R3740] (See: cryptographic association, group security 12007 association.) 12009 4. (O) "The totality of communications and security mechanisms and 12010 functions (e.g., communications protocols, security protocols, 12011 security mechanisms and functions) that securely binds together 12012 two security contexts in different end systems or relay systems 12013 supporting the same information domain." [DGSA] 12015 $ Security Association Database (SAD) 12016 (I) /IPsec/ In an IPsec implementation that operates in a network 12017 node, a database that contains parameters to describe the status 12018 and operation of each of the active security associations that the 12019 node has established with other nodes. Separate inbound and 12020 outbound SADs are needed because of the directionality of IPsec 12021 security associations. [R2401] (Compare: SPD.) 12023 $ security association identifier (SAID) 12024 (I) A data field in a security protocol (such as NLSP or SDE), 12025 used to identify the security association to which a PDU is bound. 12026 The SAID value is usually used to select a key for decryption or 12027 authentication at the destination. (See: Security Parameter 12028 Index.) 12030 $ security assurance 12031 1. (I) An attribute of an information system that provides grounds 12032 for having confidence that the system operates such that the 12033 system's security policy is enforced. (Compare: trust.) 12035 2. (I) A procedure that ensures a system is developed and operated 12036 as intended by the system's security policy. 12038 3. (D) "The degree of confidence one has that the security 12039 controls operate correctly and protect the system as intended." 12040 [SP12] 12042 Deprecated Definition: ISDs SHOULD NOT use definition 3; it is a 12043 definition for "assurance level" rather than for "assurance". 12045 4. (D) /U.S. Government, identity authentication/ The (a) "degree 12046 of confidence in the vetting process used to establish the 12047 identity of the individual to whom the [identity] credential was 12048 issued" and (b) "the degree of confidence that the individual who 12049 uses the credential is the individual to whom the credential was 12050 issued". [M0404] 12052 Deprecated Definition: ISDs SHOULD NOT use definition 4; it mixes 12053 concepts in a potentially misleading way. Part "a" is a definition 12054 for "assurance level" (rather than "security assurance") of an 12055 identity registration process; and part "b" is a definition for 12056 "assurance level" (rather than "security assurance") of an 12057 identity authentication process. Also, the processes of 12058 registration and authentication should be defined and designed 12059 separately to ensure clarity in certification. 12061 $ security audit 12062 (I) An independent review and examination of a system's records 12063 and activities to determine the adequacy of system controls, 12064 ensure compliance with established security policy and procedures, 12065 detect breaches in security services, and recommend any changes 12066 that are indicated for countermeasures. [I7498-2, NCS01] (Compare: 12067 accounting, intrusion detection.) 12069 Tutorial: The basic audit objective is to establish accountability 12070 for system entities that initiate or participate in security- 12071 relevant events and actions. Thus, means are needed to generate 12072 and record a security audit trail and to review and analyze the 12073 audit trail to discover and investigate security violations. 12075 $ security audit trail 12076 (I) A chronological record of system activities that is sufficient 12077 to enable the reconstruction and examination of the sequence of 12078 environments and activities surrounding or leading to an 12079 operation, procedure, or event in a security-relevant transaction 12080 from inception to final results. [NCS04] (See: security audit.) 12082 $ security by obscurity 12083 (O) Attempting to maintain or increase security of a system by 12084 keeping secret the design or construction of a security mechanism. 12086 Tutorial: This approach has long been discredited in cryptography, 12087 where the phrase refers to trying to keep an algorithm secret, 12088 rather than just concealing the keys [Schn]. One must assume that 12089 mass-produced or widely fielded cryptographic devices eventually 12090 will be lost or stolen and, therefore, that the algorithms will be 12091 reverse engineered and become known to the adversary. Thus, one 12092 should rely on only those algorithms and protocols that are strong 12093 enough to have been published widely, and have been peer reviewed 12094 for long enough that their flaws have been found and removed. For 12095 example, NIST used a long, public process to select AES to replace 12096 DES. 12098 In computer and network security, the principle of "no security by 12099 obscurity" also applies to security mechanisms other than 12100 cryptography. For example, if the design and implementation of a 12101 protocol for access control are strong, than reading the 12102 protocol's source code should not enable you to find a way to 12103 evade the protection and penetrate the system. 12105 $ security class 12106 (D) Synonym for "security level". 12108 Deprecated Term: ISDs SHOULD NOT use this term. Instead, use 12109 "security level", which is more widely established and understood. 12111 $ security clearance 12112 (I) A determination that a person is eligible, under the standards 12113 of a specific security policy, for authorization to access 12114 sensitive information or other system resources. (See: clearance 12115 level.) 12117 $ security compromise 12118 (I) A security violation in which a system resource is exposed, or 12119 is potentially exposed, to unauthorized access. (Compare: data 12120 compromise, exposure, violation.) 12122 $ security controls 12123 (N) The management, operational, and technical controls 12124 (safeguards or countermeasures) prescribed for an information 12125 system which, taken together, satisfy the specified security 12126 requirements and adequately protect the confidentiality, 12127 integrity, and availability of the system and its information. 12128 [FP199] (See: security architecture.) 12130 $ security doctrine 12131 1. (I) A specified set of procedures or practices that direct or 12132 provide guidance for how to comply with security policy. (Compare: 12133 security mechanism, security policy.) 12135 Tutorial: Security policy and security doctrine are closely 12136 related. However, policy deals mainly with strategy, and doctrine 12137 deals with tactics. 12139 Security doctrine is often understood to refer mainly to 12140 administrative security, personnel security, and physical 12141 security. For example, security mechanisms and devices that 12142 implement them are normally designed to operate in a limited range 12143 of environmental and administrative conditions, and these 12144 conditions must be met to complement and ensure the technical 12145 protection afforded by the hardware, firmware, and software in the 12146 devices. Security doctrine specifies how to achieve those 12147 conditions. (See: "first law" under "Courtney's laws".) 12149 $ security domain 12150 (I) See: domain. 12152 $ security environment 12153 (I) The set of external entities, procedures, and conditions that 12154 affect secure development, operation, and maintenance of a system. 12155 (See: "first law" under "Courtney's laws".) 12157 $ security event 12158 (I) An occurrence in a system that is relevant to the security of 12159 the system. (See: security incident.) 12161 Tutorial: The term covers both events that are security incidents 12162 and those that are not. In a CA workstation, for example, a list 12163 of security events might include the following: 12164 - Logging an operator into or out of the system. 12165 - Performing a cryptographic operation, e.g., signing a digital 12166 certificate or CRL. 12167 - Performing a cryptographic card operation: creation, insertion, 12168 removal, or backup. 12169 - Performing a digital certificate lifecycle operation: rekey, 12170 renewal, revocation, or update. 12171 - Posting a digital certificate to an X.500 Directory. 12172 - Receiving a key compromise notification. 12173 - Receiving an improper certification request. 12174 - Detecting an alarm condition reported by a cryptographic 12175 module. 12176 - Failing a built-in hardware self-test or a software system 12177 integrity check. 12179 $ security fault analysis 12180 (I) A security analysis, usually performed on hardware at the 12181 level of gate logic, gate-by-gate, to determine the security 12182 properties of a device when a hardware fault is encountered. 12184 $ security gateway 12185 1. (I) An internetwork gateway that separates trusted (or 12186 relatively more trusted) hosts on one side from untrusted (or less 12187 trusted) hosts on the other side. (See: firewall and guard.) 12189 2. (O) /IPsec/ "An intermediate system that implements IPsec 12190 protocols." [R2401] 12192 Tutorial: IPsec's AH or ESP can be implemented on a gateway 12193 between a protected network and an unprotected network, in order 12194 to provide security services to the protected network's hosts when 12195 they communicate across the unprotected network to other hosts and 12196 gateways. 12198 $ security incident 12199 1. (I) A security event that involves a security violation. (See: 12200 CERT, security event, security intrusion, security violation.) 12202 Tutorial: In other words, a security-relevant system event in 12203 which the system's security policy is disobeyed or otherwise 12204 breached. 12206 2. (D) "Any adverse event [that] compromises some aspect of 12207 computer or network security." [R2350] 12209 Deprecated Definition: ISDs SHOULD NOT use definition 2 because 12210 (a) a security incident may occur without actually being harmful 12211 (i.e., adverse) and (b) this Glossary defines "compromise" more 12212 narrowly in relation to unauthorized access. 12214 3. (D) "A violation or imminent threat of violation of computer 12215 security policies, acceptable use policies, or standard computer 12216 security practices." [SP61] 12218 Deprecated Definition: ISDs SHOULD NOT use this definition because 12219 mixes concepts in way that does not agree with common usage; a 12220 security incident is commonly thought of as involving a 12221 realization of a threat (see: threat action), not just a threat. 12223 $ security intrusion 12224 (I) A security event, or a combination of multiple security 12225 events, that constitutes a security incident in which an intruder 12226 gains, or attempts to gain, access to a system or system resource 12227 without having authorization to do so. 12229 $ security kernel 12230 (I) "The hardware, firmware, and software elements of a trusted 12231 computing base that implement the reference monitor concept. It 12232 must mediate all accesses, be protected from modification, and be 12233 verifiable as correct." [NCS04] (See: kernel, TCB.) 12235 Tutorial: A security kernel is an implementation of a reference 12236 monitor for a given hardware base. [Huff] 12238 $ security label 12239 (I) An item of meta-data that designates the value of one or more 12240 security-relevant attributes (e.g., security level) of a system 12241 resource. (See: [R1457]. Compare: security marking.) 12243 Deprecated usage: To avoid confusion, ISDs SHOULD NOT use 12244 "security label" for "security marking", or vice versa, even 12245 though that is commonly done (including in some national and 12246 international standards that should know better). 12248 Tutorial: Humans and automated security mechanisms use a security 12249 label of a system resource to determine, according to applicable 12250 security policy, how to control access to the resource (and they 12251 affix appropriate, matching security markings to physical 12252 instances of the resource). Security labels are most often used to 12253 support data confidentiality policy, and sometimes used to support 12254 data integrity policy. 12256 As explained in [R1457], the form that is taken by security labels 12257 of a protocol's packets varies depending on the OSIRM layer in 12258 which the protocol operates. Like meta-data generally, a security 12259 label of a data packet may be either explicit (e.g., IPSO) or 12260 implicit (e.g., Alice treats all messages received from Bob as 12261 being labeled "Not For Public Release"). In a connectionless 12262 protocol, every packet might have an explicit label; but in a 12263 connection-oriented protocol, all packets might have the same 12264 implicit label that is determined at the time the connection is 12265 established. 12267 Both classified and unclassified system resources may require a 12268 security label. (See: FOUO.) 12270 $ security level 12271 (I) The combination of a hierarchical classification level and a 12272 set of non-hierarchical category designations that represents how 12273 sensitive a specified type or item of information is. (See: 12274 dominate, lattice model. Compare: classification level.) 12276 Usage: ISDs that use this term SHOULD state a definition for it. 12277 The term is usually understood to involve sensitivity to 12278 disclosure, but it also is used in many other ways and could 12279 easily be misunderstood. 12281 $ Security Level field 12282 (I) A 16-bit field that specifies a security level value in the 12283 security option (option type 130) of version 4 IP's datagram 12284 header format. 12286 Deprecated Abbreviation: ISDs SHOULD NOT use the abbreviation "S 12287 field", which is potentially ambiguous. 12289 $ security management infrastructure (SMI) 12290 (I) System components and activities that support security policy 12291 by monitoring and controlling security services and mechanisms, 12292 distributing security information, and reporting security events. 12294 Tutorial: The associated functions are as follows [I7498-4]: 12295 - Controlling (granting or restricting) access to system 12296 resources: This includes verifying authorizations and 12297 identities, controlling access to sensitive security data, and 12298 modifying access priorities and procedures in the event of 12299 attacks. 12300 - Retrieving (gathering) and archiving (storing) security 12301 information: This includes logging security events and 12302 analyzing the log, monitoring and profiling usage, and 12303 reporting security violations. 12304 - Managing and controlling the encryption process: This includes 12305 performing the functions of key management and reporting on key 12306 management problems. (See: PKI.) 12308 $ security marking 12309 (I) A physical marking that is bound to an instance of a system 12310 resource and that represents a security label of the resource, 12311 i.e., that names or designates the value of one or more security- 12312 relevant attributes of the resource. (Compare: security label.) 12314 Tutorial: A security label may be represented by various 12315 equivalent markings depending on the physical form taken by the 12316 labeled resource. For example, a document could have a marking 12317 composed of a bit pattern [FP188] when the document is stored 12318 electronically as a file in a computer, and also a marking of 12319 printed alphabetic characters when the document is in paper form. 12321 $ security mechanism 12322 (I) A process (or a device incorporating such a process) that can 12323 be used in a system to implement a security service that is 12324 provided by or within the system. (See: Tutorial under "security 12325 policy". Compare: security doctrine.) 12327 Usage: Usually understood to refer primarily to components of 12328 communication security, computer security, and emanation security. 12330 Examples: Authentication exchange, checksum, digital signature, 12331 encryption, and traffic padding. 12333 $ security model 12334 (I) A schematic description of a set of entities and relationships 12335 by which a specified set of security services are provided by or 12336 within a system. Example: Bell-LaPadula model, OSIRM . (See: 12337 Tutorial under "security policy".) 12339 $ security parameters index (SPI) 12340 (I) /IPsec/ A 32-bit identifier used to distinguish among security 12341 associations that terminate at the same destination (IP address) 12342 and use the same security protocol (AH or ESP). Carried in AH and 12343 ESP to enable the receiving system to determine under which 12344 security association to process a received packet. 12346 (I) /mobile IP/ A 32-bit index identifying a security association 12347 from among the collection of associations that are available 12348 between a pair of nodes, for application to mobile IP protocol 12349 messages that the nodes exchange. 12351 $ security perimeter 12352 (I) A physical or logical boundary that is defined for a domain or 12353 enclave and within which a particular security policy or security 12354 architecture applies. (See: insider, outsider.) 12356 $ security policy 12357 1. (I) A definite goal, course, or method of action to guide and 12358 determine present and future decisions concerning security in a 12359 system. [R3198] (Compare: certificate policy.) 12361 2a. (I) A set of policy rules (or principles) that direct how a 12362 system (or an organization) provides security services to protect 12363 sensitive and critical system resources. (See: identity-based 12364 security policy, policy rule, rule-based security policy, rules of 12365 behavior. Compare: security architecture, security doctrine, 12366 security mechanism, security model, [R1281].) 12368 2b. (O) A set of rules to administer, manage, and control access 12369 to network resources. [R3060, R3198] 12371 2c. (O) /X.509/ A set of rules laid down by an authority to govern 12372 the use and provision of security services and facilities. 12374 2d. (O) /Common Criteria/ A set of rules that regulate how assets 12375 are managed, protected, and distributed within a TOE. 12377 Tutorial: Ravi Sandhu suggests that security policy is one of four 12378 layers of the security engineering process (as shown in the 12379 following diagram). Each layer provides a different view of 12380 security, ranging from what services are needed to how services 12381 are implemented. 12383 What Security Services 12384 Should Be Provided? +- - - - - - - - - - - - -+ 12385 ^ +- - - - - - - - - - - -| Mission Functions View | 12386 | | Security Policy |- - - - - - - - - - - - -+ 12387 | +- - - - - - - - - - - -| Domain Practices View | 12388 | | Security Model |- - - - - - - - - - - - -+ 12389 | +- - - - - - - - - - - -| Enclave Services View | 12390 | | Security Architecture |- - - - - - - - - - - - -+ 12391 | +- - - - - - - - - - - -| Agent Mechanisms View | 12392 | | Security Mechanism |- - - - - - - - - - - - -+ 12393 v +- - - - - - - - - - - -| Platform Devices View | 12394 How Are Security +- - - - - - - - - - - - -+ 12395 Services Implemented? 12397 We suggest that each of Sandhu's four layers is a mapping between 12398 two points of view that differ in their degree of abstraction, 12399 according to the perspectives of various participants in system 12400 design, development, and operation activities, as follows:. 12401 - Mission functions view: The perspective of a user of system 12402 resources. States time-phased protection needs for resources 12403 and identifies sensitive and critical resources -- networks, 12404 hosts, applications, and databases. Independent of rules and 12405 practices used to achieve protection. 12406 - Domain practices view: The perspective of an enterprise manager 12407 who sets protection standards for resources. States rules and 12408 practices for protection. Identifies domain members; i.e., 12409 entities (users/providers) and resources (including data 12410 objects). Independent of system topology. Not required to be 12411 hierarchical. 12412 - Enclave services view: The perspective of a system designer who 12413 allocates security functions to major components. Assigns 12414 security services to system topology structures and their 12415 contents. Independent of security mechanisms. Hierarchical 12416 across all domains. 12417 - Agent mechanisms view: The perspective of a system engineer who 12418 specifies security mechanisms to implement security services. 12419 Specifies mechanisms to be used by protocol, database, and 12420 application engines. Independent of type and manufacture of 12421 platforms and other physical devices. 12422 - Platform devices view: The perspective of an as-built 12423 description of the system in operation. Specifies exactly how 12424 to build or assemble the system, and also specifies procedures 12425 for operating the system. 12427 $ Security Policy Database (SPD) 12428 (I) /IPsec/ In an IPsec implementation operating in a network 12429 node, a database that contains parameters that specify policies 12430 set by a user or administrator to determine what IPsec services, 12431 if any, are to be provided to IP datagrams sent or received by the 12432 node, and in what fashion they are provided. For each datagram, 12433 the SPD specifies one of three choices: discard the datagram, 12434 apply IPsec services (e.g., AH or ESP), or bypass IPsec. Separate 12435 inbound and outbound SPDs are needed because of the directionality 12436 of IPsec security associations. [R2401] (Compare: SAD.) 12438 $ Security Protocol 3 (SP3) 12439 (O) A protocol [SDNS3] developed by SDNS to provide connectionless 12440 data security at the top of OSIRM Layer 3. (Compare: IPsec, NLSP.) 12442 $ Security Protocol 4 (SP4) 12443 (O) A protocol [SDNS4] developed by SDNS to provide either 12444 connectionless or end-to-end connection-oriented data security at 12445 the bottom of OSIRM Layer 4. (See: TLSP.) 12447 $ security-relevant event 12448 (D) See: security event. 12450 $ security service 12451 1. (I) A processing or communication service that is provided by a 12452 system to give a specific kind of protection to system resources. 12453 (See: access control service, audit service, availability service, 12454 data confidentiality service, data integrity service, data origin 12455 authentication service, non-repudiation service, peer entity 12456 authentication service, system integrity service.) 12458 Tutorial: Security services implement security policies, and are 12459 implemented by security mechanisms. 12461 2. (O) "A service, provided by a layer of communicating open 12462 systems, which ensures adequate security of the systems or the 12463 data transfers." [I7498-2] 12465 $ security situation 12466 (I) /ISAKMP/ The set of all security-relevant information -- e.g., 12467 network addresses, security classifications, manner of operation 12468 (normal or emergency) -- that is needed to decide the security 12469 services that are required to protect the association that is 12470 being negotiated. 12472 $ security target 12473 (N) /Common Criteria/ A set of security requirements and 12474 specifications to be used as the basis for evaluation of an 12475 identified TOE. 12477 Tutorial: An security target (ST) is a statement of security 12478 claims for a particular information technology security product or 12479 system, and is the basis for agreement among all parties as to 12480 what security the product or system offers. An ST parallels the 12481 structure of an protection profile, but has additional elements 12482 that include product-specific detailed information. An ST contains 12483 a summary specification, which defines the specific measures taken 12484 in the product or system to meet the security requirements. 12486 $ security token 12487 (I) See: token. 12489 $ security violation 12490 (I) An act or event that disobeys or otherwise breaches security 12491 policy. (See: compromise, penetration, security incident.) 12493 $ seed 12494 (I) A value that is an input to a pseudorandom number generator. 12496 $ selective-field confidentiality 12497 (I) A data confidentiality service that preserves confidentiality 12498 for one or more parts (i.e., fields) of each packet. (See: 12499 selective-field integrity.) 12501 Tutorial: Data confidentiality service usually is applied to 12502 entire SDUs, but some situations might require protection of only 12503 part of each packet. For example, when Alice uses a debit card at 12504 an automated teller machine (ATM), perhaps only her personal 12505 identification number (PIN) is enciphered for confidentiality when 12506 her transaction request is transmitted from the ATM to her bank's 12507 computer. 12509 In any given operational situation, there could be many different 12510 reasons for using selective field confidentiality. In the ATM 12511 example, there are at least four possibilities: The service may 12512 provide a fail-safe mode of operation, ensuring that the bank can 12513 still process transactions (although with some risk) even when the 12514 encryption system fails. It may make messages easier to work with 12515 when doing system fault isolation. It may avoid problems with laws 12516 that prevent shipping enciphered data across international 12517 borders. It may improve efficiency by reducing processing load at 12518 a central computer site. 12520 $ selective-field integrity 12521 (I) A data integrity service that preserves integrity for one or 12522 more parts (i.e., fields) of each packet. (See: selective-field 12523 confidentiality.) 12525 Tutorial: Data integrity service may be implemented in a protocol 12526 to protect the SDU part of packets, the PCI part, or both. 12527 - SDU protection: When service is provided for SDUs, it usually 12528 is applied to entire SDUs, but it might be applied only to 12529 parts of SDUs in some situations. For example, an IPS 12530 Application-Layer protocol might need protection of only part 12531 of each packet, and this might enable faster processing. 12532 - PCI protection: To prevent active wiretapping, it might be 12533 desirable to apply data integrity service to the entire PCI, 12534 but some PCI fields in some protocols need to be mutable in 12535 transit. For example, the "Time to Live" field in IPv4 is 12536 changed each time a packet passes through a router in the 12537 Internet Layer. Thus, the value that the field will have when 12538 the packet arrives at its destination is not predictable by the 12539 sender and cannot be included in a checksum computed by the 12540 sender. (See: Authentication Header.) 12542 $ self-signed certificate 12543 (I) A public-key certificate for which the public key bound by the 12544 certificate and the private key used to sign the certificate are 12545 components of the same key pair, which belongs to the signer. 12546 (Compare: root certificate.) 12548 Tutorial: In a self-signed X.509 public-key certificate, the 12549 issuer's DN is the same as the subject's DN. 12551 $ semantic security 12552 (I) An attribute of a encryption algorithm that is a formalization 12553 of the notion that the algorithm not only hides the plain text but 12554 also reveals no partial information about the plain text; i.e., 12555 whatever is computable about the plain text when given the cipher 12556 text, is also computable without the cipher text. (Compare: 12557 indistinguishability.) 12559 $ semiformal 12560 (I) Expressed in a restricted syntax language with defined 12561 semantics. [CCIB] (Compare: formal, informal.) 12563 $ sensitive 12564 (I) A condition of a system resource such that the loss of some 12565 specified property of that resource, such as confidentiality or 12566 integrity, would adversely affect the interests or business of its 12567 owner or user. (See: sensitive information. Compare: critical.) 12569 $ sensitive compartmented information (SCI) 12570 (O) /U.S. Government/ Classified information concerning or derived 12571 from intelligence sources, methods, or analytical processes, which 12572 is required to be handled within formal control systems 12573 established by the Director of Central Intelligence. [DC6/9] (See: 12574 compartment, SCIF) 12576 $ sensitive compartmented information facility (SCIF) 12577 (O) /U.S. Government/ An accredited area, room, group of rooms, 12578 building, or installation where SCI may be stored, used, 12579 discussed, or electronically processed. [DC6/9] (See: SCI. 12580 Compare: shielded enclosure.) 12582 $ sensitive information 12583 (I) Information for which (a) disclosure, (b) alteration, or (c) 12584 destruction or loss could adversely affect the interests or 12585 business of its owner or user. (See: data confidentiality, data 12586 integrity, sensitive. Compare: classified, critical.) 12588 (O) /U.S. Government/ Information for which (a) loss, (b) misuse, 12589 (c) unauthorized access, or (d) unauthorized modification could 12590 adversely affect the national interest or the conduct of federal 12591 programs, or the privacy to which individuals are entitled under 12592 the Privacy Act of 1974, but that has not been specifically 12593 authorized under criteria established by an Executive Order or an 12594 Act of Congress to be kept classified in the interest of national 12595 defense or foreign policy. 12597 Tutorial: Systems that are not U.S. national security systems, but 12598 contain sensitive U.S. Federal Government information, must be 12599 protected according to the Computer Security Act of 1987 (Public 12600 Law 100-235). 12602 $ sensitivity label 12603 (D) Synonym for "classification label". 12605 Deprecated term: ISDs SHOULD NOT use this term because the 12606 definition of "sensitive" involves not only data confidentiality, 12607 but also data integrity. 12609 $ sensitivity level 12610 (D) Synonym for "classification level". 12612 Deprecated term: ISDs SHOULD NOT use this term because the 12613 definition of "sensitive" involves not only data confidentiality, 12614 but also data integrity. 12616 $ separation of duties 12617 (I) The practice of dividing the steps in a system process among 12618 different individual entities (i.e., different users or different 12619 roles) so as to prevent a single entity acting alone from being 12620 able to subvert the process. Usage: a.k.a. "separation of 12621 privilege". (See: administrative security, dual control.) 12623 $ serial number 12624 See: certificate serial number. 12626 $ Serpent 12627 (O) A symmetric, 128-bit block cipher designed by Ross Anderson, 12628 Eli Biham, and Lars Knudsen as a candidate for the AES. 12630 $ server 12631 (I) A system entity that provides a service in response to 12632 requests from other system entities called clients. 12634 $ service data unit (SDU) 12635 (N) See: secondary definition under "protocol data unit". 12637 $ session 12638 1a. (I) /computer usage/ A continuous period of time, usually 12639 initiated by a login, during which a user accesses a computer 12640 system. 12642 1b. (I) /computer activity/ The set of transactions or other 12643 computer activities that are performed by or for a user during a 12644 period of computer usage. 12646 2. (I) /access control/ A temporary mapping of a principal to one 12647 or more roles. (See: role-based access control.) 12649 Tutorial: A user establishes a session as a principal and 12650 activates some subset of roles to which the principal has been 12651 assigned. The authorizations available to the principal in the 12652 session are the union of the permissions of all the roles 12653 activated in the session. Each session is associated with a single 12654 principal and, therefore, with a single user. A principal may have 12655 multiple, concurrent sessions and may activate a different set of 12656 roles in each session. 12658 3. (I) /computer network/ A persistent but (normally) temporary 12659 association between a user agent (typically a client) and a second 12660 process (typically a server). The association may persist across 12661 multiple exchanges of data, including multiple connections. 12662 (Compare: security association.) 12664 $ session key 12665 (I) In the context of symmetric encryption, a key that is 12666 temporary or is used for a relatively short period of time. (See: 12667 ephemeral, KDC, session. Compare: master key.) 12669 Tutorial: A session key is used for a defined period of 12670 communication between two system entities or components, such as 12671 for the duration of a single connection or transaction set; or the 12672 key is used in an application that protects relatively large 12673 amounts of data and, therefore, needs to be rekeyed frequently. 12675 $ SET(trademark) 12676 (O) See: SET Secure Electronic Transaction(trademark). 12678 $ SET private extension 12679 (O) One of the private extensions defined by SET for X.509 12680 certificates. Carries information about hashed root key, 12681 certificate type, merchant data, cardholder certificate 12682 requirements, encryption support for tunneling, or message support 12683 for payment instructions. 12685 $ SET qualifier 12686 (O) A certificate policy qualifier that provides information about 12687 the location and content of a SET certificate policy. 12689 Tutorial: In addition to the policies and qualifiers inherited 12690 from its own certificate, each CA in the SET certification 12691 hierarchy may add one qualifying statement to the root policy when 12692 the CA issues a certificate. The additional qualifier is a 12693 certificate policy for that CA. Each policy in a SET certificate 12694 may have these qualifiers: (a) a URL where a copy of the policy 12695 statement may be found; (b) an electronic mail address where a 12696 copy of the policy statement may be found; (c) a hash result of 12697 the policy statement, computed using the indicated algorithm; and 12698 (d) a statement declaring any disclaimers associated with the 12699 issuing of the certificate. 12701 $ SET Secure Electronic Transaction(trademark) or SET(trademark) 12702 (N) A protocol developed jointly by MasterCard International and 12703 Visa International and published as an open standard to provide 12704 confidentiality of transaction information, payment integrity, and 12705 authentication of transaction participants for payment card 12706 transactions over unsecured networks, such as the Internet. [SET1] 12707 (See: acquirer, brand, cardholder, dual signature, electronic 12708 commerce, IOTP, issuer, merchant, payment gateway, third party.) 12710 Tutorial: This term and acronym are trademarks of SETCo. 12711 MasterCard and Visa announced the SET standard on 1 February 1996. 12713 $ SETCo 12714 (O) Abbreviation of "SET Secure Electronic Transaction LLC", 12715 formed on 19 December 1997 by MasterCard and Visa for the purpose 12716 of implementing the SET Secure Electronic Transaction(trademark) 12717 standard. A later memorandum of understanding added American 12718 Express and JCB Credit Card Company as co-owners of SETCo. 12720 $ SHA, SHA-1, SHA-2 12721 (N) See: Secure Hash Algorithm. 12723 $ shared identity 12724 (I) See: secondary definition under "identity". 12726 $ shared secret 12727 (D) A synonym for "cryptographic key" or "password". 12729 Deprecated Usage: ISDs that use this term SHOULD state a 12730 definition for it because the term is used in many ways and could 12731 easily be misunderstood. 12733 $ shielded enclosure 12734 (O) "Room or container designed to attenuate electromagnetic 12735 radiation." [C4009] (See: emanation. Compare: SCIF.) 12737 $ short title 12738 (O) "Identifying combination of letters and numbers assigned to 12739 certain items of COMSEC material to facilitate handling, 12740 accounting, and controlling." [C4009] (Compare: KMID, long title.) 12742 $ shroud 12743 (D) /verb/ To encrypt a private key, possibly in concert with a 12744 policy that prevents the key from ever being available in 12745 cleartext form beyond a certain, well-defined security perimeter. 12746 [PKCS12] (See: encrypt. Compare: seal, wrap.) 12748 Deprecated Term: ISDs SHOULD NOT use this term as defined here; 12749 the definition duplicates the meaning of other, standard terms. 12750 Instead, use "encrypt" or another term that is specific with 12751 regard to the mechanism being used. 12753 $ SHS 12754 (N) See: Secure Hash Standard. 12756 $ sign 12757 (I) Create a digital signature for a data object. (See: signer.) 12759 $ signal analysis 12760 (I) Gaining indirect knowledge (inference) of communicated data by 12761 monitoring and analyzing a signal that is emitted by a system and 12762 that contains the data but is not intended to communicate the 12763 data. (See: emanation. Compare: traffic analysis.) 12765 $ signal intelligence 12766 (I) The science and practice of extracting information from 12767 signals. (See: signal security.) 12769 $ signal security 12770 (N) (I) The science and practice of protecting signals. (See: 12771 cryptology, security.) 12773 Tutorial: The term "signal" denotes (a) communication in almost 12774 any form and also (b) emanations for other purposes, such as 12775 radar. Signal security is opposed by signal intelligence, and each 12776 discipline includes opposed sub-disciplines as follows [Kahn]: 12778 Signal Security Signal Intelligence 12779 ------------------------------ --------------------------------- 12780 1. Communication Security 1. Communication Intelligence 12781 1a. Cryptography 1a. Cryptanalysis 12782 1b. Traffic Security 1b. Traffic Analysis 12783 1c. Steganography 1c. Detection and Interception 12784 2. Electronic Security 2. Electronic Intelligence 12785 2a. Emission Security 2a. Electronic Reconnaissance 12786 2b. Counter-Countermeasures 2b. Countermeasures 12787 ------------------------------ --------------------------------- 12789 $ signature 12790 (O) A symbol or process adopted or executed by a system entity 12791 with present intention to declare that a data object is genuine. 12792 (See: digital signature, electronic signature.) 12794 $ signature certificate 12795 (I) A public-key certificate that contains a public key that is 12796 intended to be used for verifying digital signatures, rather than 12797 for encrypting data or performing other cryptographic functions. 12799 Tutorial: A v3 X.509 public-key certificate may have a "keyUsage" 12800 extension that indicates the purpose for which the certified 12801 public key is intended. (See: certificate profile.) 12803 $ signed receipt 12804 (I) An S/MIME service [R2634] that (a) provides, to the originator 12805 of a message, proof of delivery of the message and (b) enables the 12806 originator to demonstrate to a third party that the recipient was 12807 able to verify the signature of the original message. 12809 Tutorial: The receipt is bound to the original message by a 12810 signature; consequently, the service may be requested only for a 12811 message that is signed. The receipt sender may optionally also 12812 encrypt the receipt to provide confidentiality between the receipt 12813 sender and the receipt recipient. 12815 $ signer 12816 (N) A human being or organization entity that uses a private key 12817 to sign (i.e., create a digital signature on) a data object. [DSG] 12819 $ SILS 12820 (N) See: Standards for Interoperable LAN/MAN Security. 12822 $ simple authentication 12823 1. (I) An authentication process that uses a password as the 12824 information needed to verify an identity claimed for an entity. 12825 (Compare: strong authentication.) 12827 2. (O) "Authentication by means of simple password arrangements." 12828 [X509] 12830 $ Simple Authentication and Security Layer (SASL) 12831 (I) An Internet specification [R2222] for adding authentication 12832 service to connection-based protocols. 12834 Tutorial: To use SASL, a protocol includes a command for 12835 authenticating a user to a server and for optionally negotiating 12836 protection of subsequent protocol interactions. The command names 12837 a registered security mechanism. SASL mechanisms include Kerberos, 12838 GSSAPI, S/KEY, and others. Some protocols that use SASL are IMAP4 12839 and POP3. 12841 $ Simple Key Management for Internet Protocols (SKIP) 12842 (I) A key-distribution protocol that uses hybrid encryption to 12843 convey session keys that are used to encrypt data in IP packets. 12845 Tutorial: SKIP was designed by Ashar Aziz and Whitfield Diffie at 12846 Sun Microsystems and proposed as the standard key management 12847 protocol for IPsec, but IKE was chosen instead. Although IKE is 12848 mandatory for an IPsec implementation, the use of SKIP is not 12849 excluded. 12851 SKIP uses the Diffie-Hellman algorithm (or could use another key- 12852 agreement algorithm) to generate a key-encrypting key for use 12853 between two entities. A session key is used with a symmetric 12854 algorithm to encrypt data in one or more IP packets that are to be 12855 sent from one entity to the other. A symmetric KEK is established 12856 and used to encrypt the session key, and the encrypted session key 12857 is placed in a SKIP header that is added to each IP packet that is 12858 encrypted with that session key. 12860 $ Simple Mail Transfer Protocol (SMTP) 12861 (I) A TCP-based, Application-Layer, Internet Standard protocol 12862 (RFC 821) for moving electronic mail messages from one computer to 12863 another. 12865 $ Simple Network Management Protocol (SNMP) 12866 (I) A TCP-based, Application-Layer, Internet Standard protocol 12867 [R3410, R3414] for conveying management information between system 12868 components that act as managers and agents. 12870 $ Simple Public Key Infrastructure (SPKI) 12871 (I) A set of experimental concepts (RFCs 2692, 2693) that were 12872 proposed as alternatives to the concepts standardized in PKIX. 12874 $ simple security property 12875 (N) /formal model/ Property of a system whereby a subject has 12876 read access to an object only if the clearance of the subject 12877 dominates the classification of the object. See: Bell-LaPadula 12878 model. 12880 $ single sign-on 12881 (I) A system that enables a user to access multiple computer 12882 platforms (usually a set of hosts on the same network) or multiple 12883 application systems after being authenticated just one time. (See: 12884 Kerberos.) 12886 Tutorial: In a single sign-on system, a user typically logs in 12887 just once, and then is transparently granted access to a set of 12888 system resources with no further login being required (unless, of 12889 course, the user logs out). Such a system has the advantages of 12890 being user friendly and enabling authentication to be managed 12891 consistently across an entire enterprise. Such a system also has 12892 the disadvantage of requiring all hosts and applications to trust 12893 the same authentication information. 12895 $ singular identity 12896 (I) See: secondary definition under "identity". 12898 $ site 12899 (I) A facility -- i.e., a physical space, room, or building 12900 together with its physical, personnel, administrative, and other 12901 safeguards -- in which system functions are performed. (See: 12902 node.) 12904 $ situation 12905 (I) See: security situation. 12907 $ SKEME 12908 (I) A key-distribution protocol from which features were adapted 12909 for IKE. [SKEME] 12911 $ SKIP 12912 (I) See: Simple Key Management for Internet Protocols. 12914 $ SKIPJACK 12915 (N) A type 2, 64-bit block cipher [SKIP, R2773] with a key size of 12916 80 bits. (See: CAPSTONE, CLIPPER, FORTEZZA, Key Exchange 12917 Algorithm.) 12919 Tutorial: SKIPJACK was developed by NSA and formerly classified at 12920 the U.S. DoD "Secret" level. On 23 June 1998, NSA announced that 12921 SKIPJACK had been declassified. 12923 $ slot 12924 (O) /MISSI/ One of the FORTEZZA PC card storage areas that are 12925 each able to hold an X.509 certificate plus other data, including 12926 the private key that is associated with a public-key certificate. 12928 $ smart card 12929 (I) A credit-card sized device containing one or more integrated 12930 circuit chips, which perform the functions of a computer's central 12931 processor, memory, and input/output interface. (See: PC card, 12932 smart token.) 12934 Usage: Sometimes this term is used rather strictly to mean a card 12935 that closely conforms to the dimensions and appearance of the kind 12936 of plastic credit card issued by banks and merchants. At other 12937 times, the term is used loosely to include cards that are larger 12938 than credit cards, especially cards that are thicker, such as PC 12939 cards. 12941 $ smart token 12942 (I) A device that conforms to the definition of "smart card" 12943 except that rather than having the standard dimensions of a credit 12944 card, the token is packaged in some other form, such as a military 12945 dog tag or a door key. (See: smart card, cryptographic token.) 12947 $ SMI 12948 (I) See: security management infrastructure. 12950 $ SMTP 12951 (I) See: Simple Mail Transfer Protocol. 12953 $ smurf attack 12954 (D) /slang/ A denial-of-service attack that uses IP broadcast 12955 addressing to send ICMP ping packets with the intent of flooding a 12956 system. (See: ICMP flood.) 12958 Deprecated Term: ISDs SHOULD NOT use this term. It is not listed 12959 in most English dictionaries, and other cultures are likely to use 12960 different metaphors for this concept. 12962 Derivation: The Smurfs are a fictional race of many small, blue 12963 creatures that were created by a cartoonist. Perhaps the inventor 12964 of this attack thought that a swarm of ping packets resembled a 12965 gang of smurfs. (See: Deprecated Usage under "Green Book".) 12967 Tutorial: The attacker sends ICMP echo request ("ping") packets 12968 that appear to originate not from the attacker's own IP address, 12969 but from the address of the host or router that is the target of 12970 the attack. Each packet is addressed to an IP broadcast address, 12971 e.g., to all IP addresses in a given network. Thus, each echo 12972 request that is sent by the attacker results in many echo 12973 responses being sent to the target address. This attack can 12974 disrupt service at a particular host, at the hosts that depend on 12975 a particular router, or in an entire network. 12977 $ sneaker net 12978 (D) /slang/ A process that transfers data between systems only 12979 manually, under human control; i.e., a data transfer process that 12980 involves an air gap. 12982 Deprecated Term: ISDs SHOULD NOT use this term. It is not listed 12983 in most English dictionaries, and other cultures are likely to use 12984 different metaphors for this concept. 12986 $ Snefru 12987 (N) A public-domain, cryptographic hash function (also called "The 12988 Xerox Secure Hash Function") designed by Ralph C. Merkle at Xerox 12989 Corporation. Snefru can produce either a 128-bit or 256-bit output 12990 (i.e., hash result). [Schn] (See: Khafre, Khufu.) 12992 $ sniffing 12993 (D) /slang/ Synonym for "passive wiretapping"; most often refers 12994 to capturing and examining the data packets carried on a LAN. 12995 (See: password sniffing.) 12997 Deprecated Term: ISDs SHOULD NOT use this term; it unnecessarily 12998 duplicates the meaning of a term that is better established. (See: 12999 Deprecated Usage under "Green Book". 13001 $ SNMP 13002 (I) See: Simple Network Management Protocol. 13004 $ social engineering 13005 (D) A euphemism for non-technical or low-technology methods, often 13006 involving trickery or fraud, that are used to attack information 13007 systems. Example: phishing. 13009 Deprecated Term: ISDs SHOULD NOT use this term; it is too vague. 13010 Instead, use a term that is specific with regard to the means of 13011 attack, e.g., blackmail, bribery, coercion, impersonation, 13012 intimidation, lying, or theft. 13014 $ SOCKS 13015 (I) An Internet protocol [R1928] that provides a generalized proxy 13016 server that enables client-server applications (e.g., TELNET, FTP, 13017 or HTTP; running over either TCP or UDP) to use the services of a 13018 firewall. 13020 Tutorial: SOCKS is layered under the IPS Application Layer and 13021 above the Transport Layer. When a client inside a firewall wishes 13022 to establish a connection to an object that is reachable only 13023 through the firewall, it uses TCP to connect to the SOCKS server, 13024 negotiates with the server for the authentication method to be 13025 used, authenticates with the chosen method, and then sends a relay 13026 request. The SOCKS server evaluates the request, typically based 13027 on source and destination addresses, and either establishes the 13028 appropriate connection or denies it. 13030 $ soft TEMPEST 13031 (O) The use of software techniques to reduce the radio frequency 13032 information leakage from computer displays and keyboards. [Kuhn] 13033 (See: TEMPEST.) 13035 $ soft token 13036 (D) A data object that is used to control access or authenticate 13037 authorization. (See: token.) 13039 Deprecated Term: ISDs SHOULD NOT use this term as defined here; 13040 the definition duplicates the meaning of other, standard terms. 13041 Instead, use "attribute certifate" or another term that is 13042 specific with regard to the mechanism being used. 13044 $ software 13045 (I) Computer programs (which are stored in and executed by 13046 computer hardware) and associated data (which also is stored in 13047 the hardware) that may be dynamically written or modified during 13048 execution. (Compare: firmware.) 13050 $ SORA 13051 (O) See: SSO-PIN ORA. 13053 $ source authentication 13054 (D) Synonym for "data origin authentication" or "peer entity 13055 authentication". (See: data origin authentication, peer entity 13056 authentication). 13058 Deprecated Term: ISDs SHOULD NOT use this term because it is 13059 ambiguous and, in either meaning, duplicates the meaning of 13060 internationally standardized terms. If the intent is to 13061 authenticate the original creator or packager of data received, 13062 then use "data origin authentication". If the intent is to 13063 authenticate the identity of the sender of data in the current 13064 instance, then use "peer entity authentication". 13066 $ source integrity 13067 (I) The property that data is trustworthy (i.e., worthy of 13068 reliance or trust), based on the trustworthiness of its sources 13069 and the trustworthiness of any procedures used for handling data 13070 in the system. Usage: a.k.a. Biba integrity. (See: integrity. 13071 Compare: correctness integrity, data integrity.) 13073 Tutorial: For this kind of integrity, there are formal models of 13074 unauthorized modification (see: Biba model) that logically 13075 complement the more familiar models of unauthorized disclosure 13076 (see: Bell-LaPadula model). In these models, objects are labeled 13077 to indicate the credibility of the data they contain, and there 13078 are rules for access control that depend on the labels. 13080 $ SP3 13081 (O) See: Security Protocol 3. 13083 $ SP4 13084 (O) See: Security Protocol 4. 13086 $ spam 13087 1a. (I) /slang verb/ To indiscriminately send unsolicited, 13088 unwanted, irrelevant, or inappropriate messages, especially 13089 commercial advertising in mass quantities. 13091 1b. (I) /slang noun/ Electronic "junk mail". [R2635] 13093 Deprecated Usage: ISDs SHOULD NOT use this term in upper-case 13094 letters, because SPAM(trademark) is a trademark of Hormel Foods 13095 Corporation. Hormel says, "We do not object to use of this slang 13096 term [spam] to describe [unsolicited advertising email], although 13097 we do object to the use of our product image in association with 13098 that term. Also, if the term is to be used, it SHOULD be used in 13099 all lower-case letters to distinguish it from our trademark SPAM, 13100 which SHOULD be used with all uppercase letters." (See: metadata.) 13102 Tutorial: In sufficient volume, spam can cause denial of service. 13103 (See: flooding.) According to Hormel, the term was adopted as a 13104 result of a Monty Python skit in which a group of Vikings sang a 13105 chorus of 'SPAM, SPAM, SPAM ...' in an increasing crescendo, 13106 drowning out other conversation. This lyric became a metaphor for 13107 the unsolicited advertising messages that threaten to overwhelm 13108 other discourse on the Internet. 13110 $ SPD 13111 (I) See: Security Policy Database. 13113 $ special access program (SAP) 13114 (O) /U.S. Government/ "[A kind of p]rogram [that is] established 13115 for a specific class of classified information [and] that imposes 13116 safeguarding and access requirements that exceed those normally 13117 required for information at the same classified level." [C4009] 13118 (See: formal access approval, SCI.) 13120 $ SPI 13121 (I) See: Security Parameters Index. 13123 $ SPKI 13124 (I) See: Simple Public Key Infrastructure. 13126 $ split key 13127 (I) A cryptographic key that is generated and distributed as two 13128 or more separate data items that individually convey no knowledge 13129 of the whole key that results from combining the items. (See: dual 13130 control, split knowledge.) 13132 $ split knowledge 13133 1. (I) A security technique in which two or more entities 13134 separately hold data items that individually do not convey 13135 knowledge of the information that results from combining the 13136 items. (See: dual control, split key.) 13138 2. (O) "A condition under which two or more entities separately 13139 have key components which individually convey no knowledge of the 13140 plaintext key which will be produced when the key components are 13141 combined in the cryptographic module." [FP140] 13143 $ spoofing attack 13144 (I) Synonym for "masquerade attack". 13146 $ spread spectrum 13147 (N) A TRANSEC technique that transmits a signal in a bandwidth 13148 much greater than the transmitted information needs. [F1037] 13149 Example: frequency hopping. 13151 Tutorial: Usually uses a sequential, noise-like signal structure 13152 to spread the normally narrowband information signal over a 13153 relatively wide band of frequencies. The receiver correlates the 13154 signals to retrieve the original information signal. This 13155 technique decreases potential interference to other receivers, 13156 while achieving data confidentiality and increasing immunity of 13157 spread spectrum receivers to noise and interference. 13159 $ spyware 13160 (D) /slang/ Software that an intruder has installed 13161 surreptitiously on a networked computer to gather data from that 13162 computer and send it through the network to the intruder or some 13163 other interested party. (See: malicious logic, Trojan horse.) 13165 Deprecated Usage: ISDs that use this term SHOULD state a 13166 definition for it because the term is used in many ways and could 13167 easily be misunderstood. 13169 Tutorial: Some examples of the types of data that might be 13170 gathered by spyware are application files, passwords, email 13171 addresses, usage histories, and keystrokes. Some examples of 13172 motivations for gathering the data are blackmail, financial fraud, 13173 identity theft, industrial espionage, market research, and 13174 voyeurism. 13176 $ SSH(trademark) 13177 (N) See: Secure Shell(trademark). 13179 $ SSL 13180 (I) See: Secure Sockets Layer. 13182 $ SSO 13183 (I) See: system security officer. 13185 $ SSO PIN 13186 (O) /MISSI/ One of two personal identification numbers that 13187 control access to the functions and stored data of a FORTEZZA PC 13188 card. Knowledge of the SSO PIN enables the card user to perform 13189 the FORTEZZA functions intended for use by an end user and also 13190 the functions intended for use by a MISSI CA. (See: user PIN.) 13192 $ SSO-PIN ORA (SORA) 13193 (O) /MISSI/ A MISSI organizational RA that operates in a mode in 13194 which the ORA performs all card management functions and, 13195 therefore, requires knowledge of the SSO PIN for FORTEZZA PC cards 13196 issued to end users. 13198 $ Standards for Interoperable LAN/MAN Security (SILS) 13199 1. (N) The IEEE 802.10 standards committee. (See: FP191.) 13201 2. (N) A set of IEEE standards, which has eight parts: (a) Model, 13202 including security management, (b) Secure Data Exchange protocol, 13203 (c) Key Management, (d) [has been incorporated in (a)], (e) SDE 13204 Over Ethernet 2.0, (f) SDE Sublayer Management, (g) SDE Security 13205 Labels, and (h) SDE PICS Conformance. Parts b, e, f, g, and h are 13206 incorporated in IEEE Standard 802.10-1998. 13208 $ star property 13209 (N) See: *-property. 13211 $ Star Trek attack 13212 (D) /slang/ An attack that penetrates your system where no attack 13213 has ever gone before. 13215 Deprecated Usage: This is a joke for Trekkies. (See: Deprecated 13216 Usage under "Green Book".) 13218 $ static 13219 (I) /adjective/ Refers to a cryptographic key or other parameter 13220 that is relatively long-lived. (Compare: ephemeral.) 13222 $ steganography 13223 (I) Methods of hiding the existence of a message or other data. 13224 This is different than cryptography, which hides the meaning of a 13225 message but does not hide the message itself. Examples: For 13226 classic, physical methods, see [Kahn]; for modern, digital 13227 methods, see [John]. (See: cryptology. Compare: digital 13228 watermarking.) 13230 $ storage channel 13231 (I) See: covert storage channel. 13233 $ storage key 13234 (I) A cryptographic key used by a device for protecting 13235 information that is being maintained in the device, as opposed to 13236 protecting information that is being transmitted between devices. 13237 (See: cryptographic token, token copy. Compare: traffic key.) 13239 $ stream cipher 13240 (I) An encryption algorithm that breaks plain text into a stream 13241 of successive elements (usually, bits) and encrypts the n-th 13242 plaintext element with the n-th element of a parallel key stream, 13243 thus converting the plaintext stream into a ciphertext stream. 13244 [Schn] (See: block cipher.) 13246 $ stream integrity service 13247 (I) A data integrity service that preserves integrity for a 13248 sequence of data packets, including both (a) bit-by-bit datagram 13249 integrity of each individual packet in the set and (b) packet-by- 13250 packet sequential integrity of the set as a whole. (See: data 13251 integrity. Compare: datagram integrity service.) 13253 Tutorial: Some internet applications need only datagram integrity, 13254 but others require that an entire stream of packets be protected 13255 against insertion, reordering, deletion, and delay: 13256 - "Insertion": The destination receives an additional packet that 13257 was not sent by the source. 13258 - "Reordering": The destination receives packets in a different 13259 order than that in which they were sent by the source. 13260 - "Deletion": A packet sent by the source is not ever delivered 13261 to the intended destination. 13262 - "Delay": A packet is detained for some period of time at a 13263 relay, thus hampering and postponing the packet's normal timely 13264 delivery from source to destination. 13266 $ strength 13267 1. (I) /cryptography/ A cryptographic mechanism's level of 13268 resistance to attacks [R3776]. (See: strong.) 13270 2. (N) /Common Criteria/ "Strength of function" is a 13271 "qualification of a TOE security function expressing the minimum 13272 efforts assumed necessary to defeat its expected security behavior 13273 by directly attacking its underlying security mechanisms": (See: 13274 strong.) 13275 - Basic: "A level of the TOE strength of function where analysis 13276 shows that the function provides adequate protection against 13277 casual breach of TOE security by attackers possessing a low 13278 attack potential." 13279 - Medium: "... against straightforward or intentional breach ... 13280 by attackers possessing a moderate attack potential. 13281 - High: "... against deliberately planned or organized breach ... 13282 by attackers possessing a high attack potential." 13284 $ strong 13285 1. (I) /cryptography/ Used to describe a cryptographic algorithm 13286 that would require a large amount of computational power to defeat 13287 it. (See: strength, work factor.) 13289 2. (I) /COMPUSEC/ Used to describe a security mechanism that would 13290 be difficult to defeat. (See: strength, work factor.) 13292 $ strong authentication 13293 1. (I) An authentication process that uses a cryptographic 13294 security mechanism -- particularly public-key certificates -- to 13295 verify the identity claimed for an entity. (Compare: simple 13296 authentication.) 13298 2. (O) "Authentication by means of cryptographically derived 13299 credentials." [X509] 13301 $ subject 13302 1a. (I) A process in a computer system that represents a principal 13303 and that executes with the privileges that have been granted to 13304 that principal. (Compare: principal, user.) 13306 1b. (I) /formal model/ A system entity that causes information to 13307 flow among objects or changes the system state; technically, a 13308 process-domain pair. A subject may itself be an object relative to 13309 some other subject; thus, the set of subjects in a system is a 13310 subset of the set of objects. (See: Bell-LaPadula model, object.) 13312 2. (I) /digital certificate/ The entity name that is bound to the 13313 data items in a digital certificate, and particularly a name that 13314 is bound to a key in a public-key certificate. (See: X.509.) 13316 $ subject CA 13317 (D) The CA that is the subject of a cross-certificate issued by 13318 another CA. [X509] (See: cross-certification.) 13320 Deprecated Term: ISDs SHOULD NOT use this term because it is not 13321 widely known and could be misunderstood. Instead, say "the CA that 13322 is the subject of the cross-certificate". 13324 $ subnetwork 13325 (N) An OSI term for a system of packet relays and connecting links 13326 that implement OSIRM layers 2 or 3 to provide a communication 13327 service that interconnects attached end systems. Usually, the 13328 relays are all of the same type (e.g., X.25 packet switches, or 13329 interface units in an IEEE 802.3 LAN). (See: gateway, internet, 13330 router.) 13332 $ subordinate CA (SCA) 13333 1. (I) A CA whose public-key certificate is issued by another 13334 (superior) CA. (See: certification hierarchy. Compare: cross- 13335 certification.) 13336 2. (O) /MISSI/ The fourth-highest (i.e., bottom) level of a MISSI 13337 certification hierarchy; a MISSI CA whose public-key certificate 13338 is signed by a MISSI CA rather than by a MISSI PCA. A MISSI SCA is 13339 the administrative authority for a subunit of an organization, 13340 established when it is desirable to organizationally distribute or 13341 decentralize the CA service. The term refers both to that 13342 authoritative office or role, and to the person who fills that 13343 office. A MISSI SCA registers end users and issues their 13344 certificates and may also register ORAs, but may not register 13345 other CAs. An SCA periodically issues a CRL. 13347 $ subordinate DN 13348 (I) An X.500 DN is subordinate to another X.500 DN if it begins 13349 with a set of attributes that is the same as the entire second DN 13350 except for the terminal attribute of the second DN (which is 13351 usually the name of a CA). For example, the DN is subordinate to the DN 13353 . 13355 $ subscriber 13356 (I) /PKI/ A user that is registered in a PKI and, therefore, can 13357 be named in the "subject" field of a certificate issued by a CA in 13358 that PKI. (See: registration, user.) 13360 Usage: This term is needed to distinguish registered users from 13361 two other kinds of PKI users: 13362 - Users that access the PKI but are not identified to it: For 13363 example a relying party may access a PKI repository to obtain 13364 the certificate of some other party. (See: access.) 13365 - Users that do not access the PKI: For example, a relying party 13366 (see: certificate user) may use a digital certificate that was 13367 obtained from a database that is not part of the PKI that 13368 issued the certificate. 13370 $ substitution 13371 (I) /cryptography/ A method of encryption in which elements of the 13372 plain text retain their original sequence but are replaced by 13373 other elements. (Compare: transposition.) 13375 $ subsystem 13376 (I) A collection of related system components that together 13377 perform a system function or deliver a system service. 13379 $ superuser 13380 (I) /UNIX/ Synonym for "root". 13382 $ superencryption 13383 (I) An encryption operation for which the plaintext input to be 13384 transformed is the ciphertext output of a previous encryption 13385 operation. (Compare: hybrid encryption.) 13387 $ survivability 13388 (I) The ability of a system to remain in operation or existence 13389 despite adverse conditions, including natural occurrences, 13390 accidental actions, and attacks. (Compare: availability, 13391 reliability.) 13393 $ swIPe 13394 (I) An encryption protocol for IP that provides confidentiality, 13395 integrity, and authentication and can be used for both end-to-end 13396 and intermediate-hop security. [Ioan] (Compare: IPsec.) 13398 Tutorial: The swIPe protocol is an IP predecessor that is 13399 concerned only with encryption mechanisms; policy and key 13400 management are handled outside the protocol. 13402 $ syllabary 13403 (N) /encryption/ A list of individual letters, combinations of 13404 letters, or syllables, with their equivalent code groups, used for 13405 spelling out proper names or other unusual words that are not 13406 present in the basic vocabulary (i.e., are not in the codebook) of 13407 a code used for encryption. 13409 $ symmetric cryptography 13410 (I) A branch of cryptography in which the algorithms use the same 13411 key for both of two counterpart cryptographic operations (e.g., 13412 encryption and decryption). (See: asymmetric cryptography. 13413 Compare: secret-key cryptography.) 13415 Tutorial: Symmetric cryptography has been used for thousands of 13416 years [Kahn]. A modern example is AES. 13418 Symmetric cryptography has a disadvantage compared to asymmetric 13419 cryptography with regard to key distribution. For example, when 13420 Alice wants to ensure confidentiality for data she sends to Bob, 13421 she encrypts the data with a key, and Bob uses the same key to 13422 decrypt. However, keeping the shared key secret entails both cost 13423 and risk when the key is distributed to both Alice and Bob. (See: 13424 key distribution, key management.) 13426 $ symmetric key 13427 (I) A cryptographic key that is used in a symmetric cryptographic 13428 algorithm. (See: symmetric cryptography.) 13430 $ SYN flood 13431 (I) A denial-of-service attack that sends a large number of TCP 13432 SYN (synchronize) packets to a host with the intent of disrupting 13433 the operation of that host. (See: blind attack, flooding.) 13435 Tutorial: This attack seeks to exploit a vulnerability in the TCP 13436 specification or in a TCP implementation. Normally, two hosts use 13437 a three-way exchange of packets to establish a TCP connection: (a) 13438 host 1 requests a connection by sending a SYN packet to host 2; 13439 (b) host 2 replies by sending a SYN-ACK (acknowledgement) packet 13440 to host 1; and (c) host 1 completes the connection by sending an 13441 ACK packet to host 2. To attack host 2, host 1 can send a series 13442 of TCP SYNs, each with a different phony source address. ([R2827] 13443 discusses how to use packet filtering to prevent such attacks from 13444 being launched from behind an Internet service provider's 13445 aggregation point.) Host 2 treats each SYN as a request from a 13446 separate host, replies to each with a SYN-ACK, and waits to 13447 receive the matching ACKs. (The attacker can use random or 13448 unreachable sources addresses in the SYN packets, or can use 13449 source addresses that belong to third parties, that then become 13450 secondary victims.) 13452 For each SYN-ACK that is sent, the TCP process in host 2 needs 13453 some memory space to store state information while waiting for the 13454 matching ACK to be returned. If the matching ACK never arrives at 13455 host 2, a timer associated with the pending SYN-ACK will 13456 eventually expire and release the space. But if host 1 (or a 13457 cooperating group of hosts) can rapidly send many SYNs to host 2, 13458 host 2 will need to store state information for many pending SYN- 13459 ACKs and may run out of space. This can prevent host 2 from 13460 responding to legitimate connection requests from other hosts or 13461 even, if there are flaws in host 2's TCP implementation, crash 13462 when the available space is exhausted. 13464 $ synchronization 13465 (I) Any technique by which a receiving (decrypting) cryptographic 13466 process attains an internal state that matches the transmitting 13467 (encrypting) process, i.e., has the appropriate keying material to 13468 process the cipher text and is correctly initialized to do so. 13470 $ system 13471 (I) Synonym for "information system". 13473 Usage: This is a generic definition, and is the one with which the 13474 term is used in this Glossary. However, ISDs that use the term in 13475 protocol specifications SHOULD provide a much more specific 13476 definition for it. Also, ISDs that specify security features, 13477 services, and assurances need to define which system components 13478 and system resources are inside the applicable security perimeter 13479 and which are outside. (See: security architecture.) 13481 $ system architecture 13482 (N) The structure of system components, their relationships, and 13483 the principles and guidelines governing their design and evolution 13484 over time. [DoDAF1] (Compare: security architecture.) 13486 $ system component 13487 1. (I) A collection of system resources that (a) forms a physical 13488 or logical part of the system, (b) has specified functions and 13489 interfaces, and (c) is treated (e.g., by policies or 13490 specifications) as existing independently of other parts of the 13491 system. (See: subsystem.) 13493 2. (O) /ITSEC/ An identifiable and self-contained part of a TOE. 13495 Usage: Component is a relative term because components may be 13496 nested; i.e., one component of system may be a part of another 13497 component of that system. 13499 Tutorial: Components can be characterized as follows: 13500 - A "physical component" has mass and takes up space. 13501 - A "logical component" is an abstraction used to manage and 13502 coordinate aspects of the physical environment, and typically 13503 represents a set of states or capabilities of the system. 13505 $ system entity 13506 (I) An active component of a system -- e.g., an automated process 13507 or set of processes (see: subsystem), or a person or set of 13508 persons (e.g., an organization) -- that incorporates a specific 13509 set of capabilities. (Compare: subject, user.) 13511 $ system high 13512 (I) The highest security level at which a system operates, or is 13513 capable of operating, at a particular time or in a particular 13514 environment. (See: system-high security mode.) 13516 $ system-high security mode 13517 (I) A mode of system operation wherein all users having access to 13518 the system possess all necessary authorizations (both security 13519 clearance and formal access approval) for all data handled by the 13520 system, but some users might not have need-to-know for all the 13521 data. (See: /system operation/ under "mode", formal access 13522 approval, protection level, security clearance.) 13524 Usage: Usually abbreviated as "system-high mode". This mode was 13525 defined in U.S. DoD policy that applied to system accreditation, 13526 but the term is widely used outside the Government. 13528 $ system integrity 13529 (I) "The quality that a system has when it can perform its 13530 intended function in a unimpaired manner, free from deliberate or 13531 inadvertent unauthorized manipulation." [NCS04] (See: recovery, 13532 system integrity service.) 13534 $ system integrity service 13535 (I) A security service that protects system resources in a 13536 verifiable manner against unauthorized or accidental change, loss, 13537 or destruction. (See: system integrity.) 13539 $ system low 13540 (I) The lowest security level supported by a system at a 13541 particular time or in a particular environment. (Compare: system 13542 high.) 13544 $ system resource 13545 (I) Data contained in an information system; or a service provided 13546 by a system; or a system capacity, such as processing power or 13547 communication bandwidth; or an item of system equipment (i.e., 13548 hardware, firmware, software, or documentation); or a facility 13549 that houses system operations and equipment. (See: system 13550 component.) 13552 $ system security officer (SSO) 13553 (I) A person responsible for enforcement or administration of the 13554 security policy that applies to a system. 13556 $ TACACS 13557 (I) See: Terminal Access Controller (TAC) Access Control System. 13559 $ TACACS+ 13560 (I) A TCP-based protocol that improves on TACACS and XTACACS by 13561 separating the functions of authentication, authorization, and 13562 accounting and by encrypting all traffic between the network 13563 access server and authentication server. TACACS+ is extensible to 13564 allow any authentication mechanism to be used with TACACS+ 13565 clients. (See: TACACS, XTACACS.) 13567 $ tamper 13568 (I) Make an unauthorized modification in a system that alters the 13569 system's functioning in a way that degrades the security services 13570 that the system was intended to provide. (See: QUADRANT. Compare: 13571 secondary definitions under "corruption" and "misuse".) 13573 $ tamper-evident 13574 (I) A characteristic of a system component that provides evidence 13575 that an attack has been attempted on that component or system. 13577 Usage: Usually involves physical evidence. (See: tamper.) 13579 $ tamper-resistant 13580 (I) A characteristic of a system component that provides passive 13581 protection against an attack. (See: tamper.) 13583 Usage: Usually involves physical means of protection. 13585 $ target of evaluation (TOE) 13586 (N) /Common Criteria/ An information technology product or system 13587 that is the subject of a security evaluation, together with the 13588 product's associated administrator and user documentation. 13589 (Compare: protection profile.) 13591 Tutorial: The security characteristics of the target of evaluation 13592 (TOE) are described in specific terms by a corresponding security 13593 target, or in more general terms by a protection profile. In 13594 Common Criteria philosophy, it is important that a TOE be 13595 evaluated against the specific set of criteria expressed in the 13596 target. This evaluation consists of rigorous analysis and testing 13597 performed by an accredited, independent laboratory. The scope of a 13598 TOE evaluation is set by the EAL and other requirements specified 13599 in the target. Part of this process is an evaluation of the target 13600 itself, to ensure that it is correct, complete, and internally 13601 consistent and can be used as the baseline for the TOE evaluation. 13603 $ TCB 13604 (N) See: trusted computing base. 13606 $ TCC field 13607 (I) See: Transmission Control Code field. 13609 $ TCP 13610 (I) See: Transmission Control Protocol. 13612 $ TCP/IP 13613 (I) Synonym for "Internet Protocol Suite". 13615 $ TCSEC 13616 (N) See: Trusted Computer System Evaluation Criteria. (Compare: 13617 TSEC.) 13619 $ TDEA 13620 (I) See: Triple Data Encryption Algorithm. 13622 $ teardrop attack 13623 (D) /slang/ An denial-of-service attack that sends improperly 13624 formed IP packet fragments with the intent of causing the 13625 destination system to fail. 13627 Deprecated Term: ISDs that use this term SHOULD state a definition 13628 for it because the term is often used imprecisely and could easily 13629 be misunderstood. (See: Deprecated Usage under "Green Book".) 13631 $ technical non-repudiation 13632 (I) See: (secondary definition under) non-repudiation. 13634 $ technical security 13635 (I) Security mechanisms and procedures that are implemented in and 13636 executed by computer hardware, firmware, or software to provide 13637 automated protection for a system. (See: security architecture. 13638 Compare: administrative security.) 13640 $ Telecommunications Security Word System (TSEC) 13641 (O) /U.S. Government/ A terminology for designating 13642 telecommunication security equipment. (Compare: TCSEC.) 13644 Tutorial: A TSEC designator has the following parts: 13645 - Prefix "TSEC/" for items and systems, or suffix "/TSEC" for 13646 assemblies. (Often omitted when the context is clear.) 13648 - First letter, for function: "C" COMSEC equipment system, "G" 13649 general purpose, "K" cryptographic, "H" crypto-ancillary, "M" 13650 manufacturing, "N" noncryptographic, "S" special purpose. 13651 - Second letter, for type or purpose: "G" key generation, "I" 13652 data transmission, "L" literal conversion, "N" signal 13653 conversion, "O" multipurpose, "P" materials production, "S" 13654 special purpose, "T" testing or checking, "U" television, "W" 13655 teletypewriter, "X" facsimile, "Y" speech. 13656 - Optional third letter, used only in designations of assemblies, 13657 for type or purpose: "A" advancing, "B" base or cabinet, "C" 13658 combining, "D" drawer or panel, "E" strip or chassis, "F" frame 13659 or rack, "G" key generator, "H" keyboard, "I" translator or 13660 reader, "J" speech processing, "K" keying or permuting, "L" 13661 repeater, "M" memory or storage, "O" observation, "P" power 13662 supply or converter, "R" receiver, "S" synchronizing, "T" 13663 transmitter, "U" printer, "V" removable COMSEC component, "W" 13664 logic programmer/programming, "X" special purpose. 13665 - Model number, usually two or 3 digits, assigned sequentially 13666 within each letter combination (e.g., KG-34, KG-84). 13667 - Optional suffix letter, used to designate a version. First 13668 version has no letter, next version has "A" (e.g., KG-84, KG- 13669 84A), etc. 13671 $ TELNET 13672 (I) A TCP-based, Application-Layer, Internet Standard protocol 13673 (RFC 854) for remote login from one host to another. 13675 $ TEMPEST 13676 (N) Short name for technology and methods for protecting against 13677 data compromise due to electromagnetic emanations from electrical 13678 and electronic equipment. [Russ] (See: inspectable space, soft 13679 TEMPEST, TEMPEST zone. Compare: QUADRANT) 13681 (O) /U.S. Government/ "Short name referring to investigation, 13682 study, and control of compromising emanations from IS equipment." 13683 [C4009] 13685 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 13686 "electromagnetic emanations security"; instead, use EMSEC. Also, 13687 the term is NOT an acronym for Transient Electromagnetic Pulse 13688 Surveillance Technology. 13690 Tutorial: The U.S. Federal Government issues security policies 13691 that (a) state specifications and standards for techniques to 13692 reduce the strength of emanations from systems and reduce the 13693 ability of unauthorized parties to receive and make use of 13694 emanations and (b) state rules for applying those techniques. 13695 Other nations presumably do the same. 13697 $ TEMPEST zone 13698 (O) "Designated area [i.e., a physical volume] within a facility 13699 where equipment that has appropriate TEMPEST characteristics ... 13701 may be operated." [C4009] (See: emanation security, TEMPEST. 13702 Compare: inspectable space.) 13704 Tutorial: The strength of an electromagnetic signal decreases in 13705 proportion to the square of the distance between the source and 13706 the receiver. Therefore, EMSEC for electromagnetic signals can be 13707 achieved by a combination of (a) reducing the strength of 13708 emanations to a defined level and (b) establishing around that 13709 equipment an appropriately sized physical buffer zone from which 13710 unauthorized entities are excluded. By making the zone large 13711 enough, it is possible to limit the signal strength available to 13712 entities outside the zone to a level lower than can be received 13713 and read with known, state-of-the-art methods. Typically, the need 13714 for and size of a TEMPEST zone established by a security policy 13715 depends not only on the measured level of signal emitted by 13716 equipment, but also on the perceived threat level in the 13717 equipment's environment. 13719 $ Terminal Access Controller (TAC) Access Control System (TACACS) 13720 (I) A UDP-based authentication and access control protocol [R1492] 13721 in which a network access server receives an identifier and 13722 password from a remote terminal and passes them to a separate 13723 authentication server for verification. (See: TACACS+, XTACACS.) 13725 Tutorial: TACACS can provide service not only for network access 13726 servers but also routers and other networked computing devices via 13727 one or more centralized authentication servers. TACACS was 13728 originally developed for ARPANET and has evolved for use in 13729 commercial equipment. 13731 $ TESS 13732 (I) See: The Exponential Encryption System. 13734 $ The Exponential Encryption System (TESS) 13735 (I) A system of separate but cooperating cryptographic mechanisms 13736 and functions for the secure authenticated exchange of 13737 cryptographic keys, the generation of digital signatures, and the 13738 distribution of public keys. TESS uses asymmetric cryptography, 13739 based on discrete exponentiation, and a structure of self- 13740 certified public keys. [R1824] 13742 $ threat 13743 1a. (I) A potential for violation of security, which exists when 13744 there is an entity, circumstance, capability, action, or event 13745 that could cause harm. (See: dangling threat, INFOCON level, 13746 threat action, threat agent, threat consequence. Compare: attack, 13747 vulnerability.) 13749 1b. (N) Any circumstance or event with the potential to adversely 13750 affect a system through unauthorized access, destruction, 13751 disclosure, or modification of data, or denial of service. [C4009] 13752 (See: sensitive information.) 13753 Usage: (a) Frequently misused with the meaning of either "threat 13754 action" or "vulnerability". (b) In some contexts, "threat" is used 13755 more narrowly to refer only to intelligent threats; for example, 13756 see definition 2 below. (c) In some contexts, "threat" is used 13757 more broadly to cover both definition 1 and other concepts, such 13758 as in definition 3 below. 13760 Tutorial: A threat is a possible danger that might exploit a 13761 vulnerability. Thus, a threat may be intentional or not: 13762 - "Intentional threat": A possibility of an attack by an 13763 intelligent entity (e.g., an individual cracker or a criminal 13764 organization). 13765 - "Accidental threat": A possibility of human error or omission, 13766 unintended equipment malfunction, or natural disaster (e.g., 13767 fire, flood, earthquake, windstorm, and other causes listed in 13768 [FP031]). 13770 The Common Criteria characterizes a threat in terms of (a) a 13771 threat agent, (b) a presumed method of attack, (c) any 13772 vulnerabilities that are the foundation for the attack, and (d) 13773 the system resource that is attacked. That characterization agrees 13774 with the definitions in this Glossary (see: diagram under 13775 "attack"). 13777 2. (O) The technical and operational ability of a hostile entity 13778 to detect, exploit, or subvert a friendly system and the 13779 demonstrated, presumed, or inferred intent of that entity to 13780 conduct such activity. 13782 Tutorial: To be likely to launch an attack, an adversary must have 13783 (a) a motive to attack, (b) a method or technical ability to make 13784 the attack, and (c) an opportunity to appropriately access the 13785 targeted system. 13787 3. (D) "An indication of an impending undesirable event." [Park] 13789 Deprecated Definition: ISDs SHOULD NOT use the term with 13790 definition 3 because the definition is ambiguous. This definition 13791 was intended to include the following three meanings: 13792 - "Potential threat": A possible security violation; i.e., the 13793 same as definition 1. 13794 - "Active threat": An expression of intent to violate security. 13795 (Context usually distinguishes this meaning from the previous 13796 one.) 13797 - "Accomplished threat" or "actualized threat": That is, a threat 13798 action. Deprecated Usage: ISDs SHOULD NOT use the term "threat" 13799 with this meaning; instead, use "threat action". 13801 $ threat action 13802 (I) A realization of a threat, i.e., an occurrence in which system 13803 security is assaulted as the result of either an accidental event 13804 or an intentional act. (See: attack, threat, threat consequence.) 13806 Tutorial: A complete security architecture deals with both 13807 intentional acts (i.e. attacks) and accidental events [FIPS31]. 13808 (See: various kinds of threat actions defined under the four kinds 13809 of "threat consequence".) 13811 $ threat agent 13812 (I) A system entity that performs a threat action, or an event 13813 that results in a threat action. 13815 $ threat analysis 13816 (I) An analysis of the threat actions that might affect a system, 13817 primarily emphasizing their probability of occurrence but also 13818 considering their resulting threat consequences. Example: RFC 13819 3833. (Compare: risk analysis.) 13821 $ threat consequence 13822 (I) A security violation that results from a threat action. 13824 Tutorial: The four basic types of threat consequence are 13825 "unauthorized disclosure", "deception", "disruption", and 13826 "usurpation". (See main Glossary entries of each of these four 13827 terms for lists of the types of threat actions that can result in 13828 these consequences.) 13830 $ thumbprint 13831 1. (I) A pattern of curves formed by the ridges on the tip of a 13832 thumb. (See: biometric authentication, fingerprint.) 13834 2. (D) Synonym for some type of "hash result". (See: biometric 13835 authentication. Compare: fingerprint.) 13837 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 13838 "hash result" because that meaning mixes concepts in a potentially 13839 misleading way. 13841 $ ticket 13842 (I) Synonym for "capability token". 13844 Tutorial: A ticket is usually granted by a centralized access 13845 control server (ticket-granting agent) to authorize access to a 13846 system resource for a limited time. Tickets can be implemented 13847 with either symmetric cryptography (see: Kerberos) or asymmetric 13848 cryptography (see: attribute certificate). 13850 $ tiger team 13851 (I) A group of evaluators employed by a system's managers to 13852 perform penetration tests on the system. 13854 Deprecated Term: It is likely that other cultures use different 13855 metaphors for this concept. Therefore, to avoid international 13856 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 13857 Usage under "Green Book".) 13859 $ time stamp 13860 (I) /noun/ With respect to a data object, a label or marking in 13861 which is recorded the time (time of day or other instant of 13862 elapsed time) at which the label or marking was affixed to the 13863 data object. (See: Time-Stamp Protocol.) 13865 (O) /noun/ "With respect to a recorded network event, a data field 13866 in which is recorded the time (time of day or other instant of 13867 elapsed time) at which the event took place." [A1523] 13869 Tutorial: A time stamp can be used as evidence to prove that a 13870 data object existed (or that an event occurred) at or before a 13871 particular time. For example, a time stamp might be used to prove 13872 that a digital signature based on a private key was created while 13873 the corresponding public-key certificate was valid, i.e., before 13874 the certificate either expired or was revoked. Establishing this 13875 proof would enable the certificate to be used after its expiration 13876 or revocation, to verify a signature that was created earlier. 13877 This kind of proof is required as part of implementing PKI 13878 services such as non-repudiation service and long-term security 13879 services such as audit. 13881 $ Time-Stamp Protocol 13882 (I) An Internet protocol (RFC 3161) that specifies how a client 13883 requests and receives a time stamp from a server for a data object 13884 held by the client. 13886 Tutorial: The protocol describes the format of (a) a request sent 13887 to a time stamping authority and (b) the response that is returned 13888 containing a time stamp. The authority creates the stamp by 13889 concatenating (a) a hash value of the input data object with (b) a 13890 UTC time value and other parameters (policy OID, serial number, 13891 indication of time accuracy, nonce, DN of the authority, and 13892 various extensions), and then signing that dataset with the 13893 authority's private key as specified in CMS. Such an authority 13894 typically would operate as a trusted third-party service, but 13895 other operational models might be used. 13897 $ timing channel 13898 (I) See: covert timing channel. 13900 $ TKEY 13901 (I) A mnemonic referring to an Internet protocol (RFC 2930) for 13902 establishing a shared secret key between a DNS resolver and a DNS 13903 name server. (See: TSIG.) 13905 $ TLS 13906 (I) See: Transport Layer Security. 13908 $ TLSP 13909 (N) See: Transport Layer Security Protocol. 13911 $ TOE 13912 (N) See: target of evaluation 13914 $ token 13915 1. (I) /cryptography/ See: cryptographic token. (Compare: dongle.) 13917 2. (I) /access control/ An object that is used to control access 13918 and is passed between cooperating entities in a protocol that 13919 synchronizes use of a shared resource. Usually, the entity that 13920 currently holds the token has exclusive access to the resource. 13921 (See: capability token.) 13923 Usage: This term is heavily overloaded in the computing 13924 literature; therefore, ISDs SHOULD NOT use this term with any 13925 definition other than 1 or 2. 13927 3a. (D) /authentication/ A data object or a physical device used 13928 to verify an identity in an authentication process. 13930 3b. (D) /U.S. Government/ Something that the claimant in an 13931 authentication process (i.e., the entity that claims an identity) 13932 possesses and controls, and uses to prove the claim during the 13933 verification step of the process. [SP63] 13935 Usage: Deprecated usage: ISDs SHOULD NOT use this term with 13936 definitions 3a and 3b; instead, use more specifically descriptive 13937 and informative terms such as "authentication information" or 13938 "cryptographic token", depending on what is meant. 13940 NIST defines four types of claimant tokens for electronic 13941 authentication in an information system [SP63]. ISDs SHOULD NOT 13942 use these four NIST terms; they mix concepts in potentially 13943 confusing ways and duplicate the meaning of better-established 13944 terms. These four terms can be avoided by using more specifically 13945 descriptive terms as follows: 13946 - NIST "hard token": A hardware device that contains a protected 13947 cryptographic key. (This is a type of "cryptographic token", 13948 and the key is a type of "authentication information".) 13949 - NIST "one-time password device token": A personal hardware 13950 device that generates one-time passwords. (One-time passwords 13951 are typically generated cryptographically. Therefore, this is a 13952 type of "cryptographic token", and the key is a type of 13953 "authentication information".) 13954 - NIST "soft token": A cryptographic key that typically is stored 13955 on disk or some other magnetic media. (The key is a type of 13956 "authentication information"; "authentication key" would be a 13957 better description.) 13958 - NIST "password token": A secret data value that the claimant 13959 memorizes. (This is a "password" that is being used as 13960 "authentication information".) 13962 $ token backup 13963 (I) A token management operation that stores sufficient 13964 information in a database (e.g., in a CAW) to recreate or restore 13965 a security token (e.g., a smart card) if it is lost or damaged. 13967 $ token copy 13968 (I) A token management operation that copies all the personality 13969 information from one security token to another. However, unlike in 13970 a token restore operation, the second token is initialized with 13971 its own, different local security values such as PINs and storage 13972 keys. 13974 $ token management 13975 (I) The process that includes initializing security tokens (e.g., 13976 see: smart card), loading data into the tokens, and controlling 13977 the tokens during their life cycle. May include performing key 13978 management and certificate management functions; generating and 13979 installing PINs; loading user personality data; performing card 13980 backup, card copy, and card restore operations; and updating 13981 firmware. 13983 $ token restore 13984 (I) A token management operation that loads a security token with 13985 data for the purpose of recreating (duplicating) the contents 13986 previously held by that or another token. (See: recovery.) 13988 $ token storage key 13989 (I) A cryptographic key used to protect data that is stored on a 13990 security token. 13992 $ top CA 13993 (I) A synonym for "root" in a certification hierarchy. (See: apex 13994 trust anchor.) 13996 $ top-level specification 13997 (I) "A non-procedural description of system behavior at the most 13998 abstract level; typically a functional specification that omits 13999 all implementation details." [NCS04] (See: Tutorial under 14000 "security policy".) 14002 Tutorial: A top-level specification is at a level of abstraction 14003 below "security model" and above "security architecture" (see: 14004 Tutorial under "security policy"). 14006 A top-level specification may be descriptive or formal: 14007 - "Descriptive top-level specification": One that is written in a 14008 natural language like English or an informal design notation. 14009 - "Formal top-level specification": One that is written in a 14010 formal mathematical language to enable theorems to be proven 14011 that show that the specification correctly implements a set of 14012 formal requirements or a formal security model. (See: 14013 correctness proof.) 14015 $ traceback 14016 (I) Identification of the source of a data packet. (See: 14017 masquerade, network weaving.) 14019 $ tracker 14020 (N) An attack technique for achieving unauthorized disclosure from 14021 a statistical database. [Denns] (See: Tutorial under "inference 14022 control".) 14024 $ traffic analysis 14025 1. (I) Gaining knowledge of information by inference from 14026 observable characteristics of a data flow, even if the information 14027 is not directly available (e.g., when the data is encrypted). 14028 These characteristics include the identities and locations of the 14029 source(s) and destination(s) of the flow, and the flow's presence, 14030 amount, frequency, and duration of occurrence. The object of the 14031 analysis might be information in SDUs, information in the PCI, or 14032 both. (See: inference, traffic-flow confidentiality, wiretapping. 14033 Compare: signal analysis.) 14035 2. (O) "The inference of information from observation of traffic 14036 flows (presence, absence, amount, direction, and frequency)." 14037 [I7498-2] 14039 $ traffic-flow analysis 14040 (I) Synonym for "traffic analysis". 14042 $ traffic-flow confidentiality (TFC) 14043 1. (I) A data confidentiality service to protect against traffic 14044 analysis. (See: communications cover.) 14046 2. (O) "A confidentiality service to protect against traffic 14047 analysis." [I7498-2] 14049 Tutorial: Confidentiality concerns involve both direct and 14050 indirect disclosure of data, and the latter includes traffic 14051 analysis. However, operational considerations can make TFC 14052 difficult to achieve. For example, if Alice sends a product idea 14053 to Bob in an email message, she wants data confidentiality for the 14054 message's content, and she might also want to conceal the 14055 destination of the message in order to hide Bob's identity from 14056 her competitors. However, the identity of the intended recipient, 14057 or at least a network address for that recipient, needs to be made 14058 available to the mail system. Thus, complex forwarding schemes may 14059 be needed to conceal the ultimate destination as the message 14060 travels through the open Internet (see: onion routing). 14062 Later, if Alice uses an ATM during a clandestine visit to 14063 negotiate with Bob, she might prefer that her bank conceal the 14064 origin of her transaction, because knowledge of the ATM's location 14065 might allow a competitor to infer Bob's identity. The bank, on the 14066 other hand, might prefer to protect only Alice's PIN (see: 14067 selective-field confidentiality). 14069 A TFC service can be either full or partial: 14070 - "Full TFC": This type of service conceals all traffic 14071 characteristics. 14072 - "Partial TFC": This type of service either (a) conceals some 14073 but not all of the characteristics or (b) does not completely 14074 conceal some characteristic. 14076 On point-to-point data links, full TFC can be provided by 14077 enciphering all PDUs and also generating a continuous, random data 14078 stream to seamlessly fill all gaps between PDUs. To a wiretapper, 14079 the link then appears to be carrying an unbroken stream of 14080 enciphered data. In other cases -- including on a shared or 14081 broadcast medium, or end-to-end in a network -- only partial TFC 14082 is possible, and that may require a combination of techniques. For 14083 example, a LAN that uses "carrier sense multiple access with 14084 collision detection" (CSMA/CD; a.k.a. "listen while talk") to 14085 control access to the medium, relies on detecting intervals of 14086 silence, which prevents using full TFC. Partial TFC can be 14087 provided on that LAN by measures such as adding spurious PDUs, 14088 padding PDUs to a constant size, or enciphering addresses just 14089 above the Physical Layer; but these measures reduce the efficiency 14090 with which the LAN can carry traffic. At higher protocol layers, 14091 SDUs can be protected, but addresses and other items of PCI must 14092 be visible at the layers below. 14094 $ traffic key 14095 (I) A cryptographic key used by a device for protecting 14096 information that is being transmitted between devices, as opposed 14097 to protecting information that being is maintained in the device. 14098 (Compare: storage key.) 14100 $ traffic padding 14101 (I) "The generation of spurious instances of communication, 14102 spurious data units, and/or spurious data within data units." 14103 [I7498-2] 14105 $ tranquillity property 14106 (N) /formal model/ Property of a system whereby the security level 14107 of an object cannot change while the object is being processed by 14108 the system. (See: Bell-LaPadula model.) 14110 $ transaction 14111 1. (I) A unit of interaction between an external entity and a 14112 system, or between components within a system, that involves a 14113 series of system actions or events. 14115 2. (O) "A discrete event between user and systems that supports a 14116 business or programmatic purpose." [M0404] 14118 Tutorial: To maintain secure state, transactions need to be 14119 processed coherently and reliably. Usually, they need to be 14120 designed to be atomic, consistent, isolated, and durable [Gray]: 14121 - "Atomic": All actions and events that comprise the transaction 14122 are guaranteed to be completed successfully, or else the result 14123 is as if none at all were executed. 14124 - "Consistent": The transaction satisfies correctness constraints 14125 defined for the data that is being processed. 14126 - "Isolated": If two transactions are performed concurrently, 14127 they do not interfere with each other, and it appears as though 14128 the system performs one at a time. 14129 - "Durable": System state and transaction semantics survive 14130 system failures. 14132 $ TRANSEC 14133 (I) See: transmission security. 14135 $ Transmission Control Code field (TCC field) 14136 (I) A data field that provides a means to segregate traffic and 14137 define controlled communities of interest in the security option 14138 (option type = 130) of IPv4's datagram header format. The TCC 14139 values are alphanumeric trigraphs assigned by the U.S. Government 14140 as specified in RFC 791. 14142 $ Transmission Control Protocol (TCP) 14143 (I) An Internet Standard, Transport-Layer protocol (RFC 793) that 14144 reliably delivers a sequence of datagrams from one computer to 14145 another in a computer network. (See: TCP/IP.) 14147 Tutorial: TCP is designed to fit into a layered suite of protocols 14148 that support internetwork applications. TCP assumes it can obtain 14149 a simple but potentially unreliable end-to-end datagram service 14150 (such as IP) from the lower layer protocols. 14152 $ transmission security (TRANSEC) 14153 (I) COMSEC measures that protect communications from interception 14154 and exploitation by means other than cryptanalysis. Example: 14155 frequency hopping. (Compare: anti-jam, traffic flow 14156 confidentiality.) 14158 $ Transport Layer 14159 See: Internet Protocol Suite, OSIRM. 14161 $ Transport Layer Security (TLS) 14162 (I) TLS Version 1.0 is an Internet protocol [R2246] that is based 14163 on, and very similar to, SSL Version 3.0. (Compare: TLSP.) 14165 Deprecated Usage: The TLS protocol is misnamed. The name 14166 misleadingly suggests that TLS is situated in the IPS Transport 14167 Layer, but TLS is always layered above a reliable Transport-Layer 14168 protocol (usually TCP) and either layered immediately below or 14169 integrated with an Application-Layer protocol (often HTTP). 14171 $ Transport Layer Security Protocol (TLSP) 14172 (N) An end-to-end encryption protocol (ISO 10736) that provides 14173 security services at the bottom of OSIRM Layer 4, i.e., directly 14174 above Layer 3. (Compare: TLS.) 14176 Tutorial: TLSP evolved directly from SP4. 14178 $ transport mode 14179 (I) One of two ways to apply AH or ESP to protect data packets; in 14180 this mode, the IPsec protocol encapsulates (i.e., the protection 14181 applies to) the packets of an IPS Transport-Layer protocol (e.g., 14182 TCP, UDP), which is normally carried directly above IP in an IPS 14183 protocol stack. (Compare: tunnel mode.) 14185 Tutorial: An IPsec transport-mode security association is always 14186 between two hosts; neither end has the role of a security gateway. 14187 Whenever either end of an IPsec security association is a security 14188 gateway, the association is required to be in tunnel mode. 14190 $ transposition 14191 (I) /cryptography/ A method of encryption in which elements of the 14192 plain text retain their original form but undergo some change in 14193 their relative position. (Compare: substitution.) 14195 $ trap door 14196 (I) Synonym for "back door". 14198 $ Triple Data Encryption Algorithm 14199 (I) An block cipher that transforms each 64-bit plaintext block by 14200 applying the DEA three successive times, using either two or three 14201 different keys for an effective key length of 112 or 168 bits. 14202 [A9052, SP67] 14204 Example: A variation proposed for IPsec's ESP uses a 168-bit key, 14205 consisting of three independent 56-bit values used by the DEA, and 14206 a 64-bit initialization vector. Each datagram contains an IV to 14207 ensure that each received datagram can be decrypted even when 14208 other datagrams are dropped or a sequence of datagrams is 14209 reordered in transit. [R1851] 14211 $ triple-wrapped 14212 (I) /S-MIME/ Data that has been signed with a digital signature, 14213 then encrypted, and then signed again. [R2634] 14215 $ Trojan horse 14216 (I) A computer program that appears to have a useful function, but 14217 also has a hidden and potentially malicious function that evades 14218 security mechanisms, sometimes by exploiting legitimate 14219 authorizations of a system entity that invokes the program. (See: 14221 malware, spyware. Compare: logic bomb, virus, worm.) 14223 $ trust 14224 1. (I) /information system/ A feeling of certainty (sometimes 14225 based on inconclusive evidence) either (a) that the system will 14226 not fail or (b) that the system meets its specifications (i.e., 14227 the system does what it claims to do and does not perform unwanted 14228 functions). (See: trust level, trusted system, trustworthy system. 14229 Compare: assurance.) 14231 Tutorial: Components of a system can be grouped into three classes 14232 of trust [Gass]: 14233 - "Trusted": The component is responsible for enforcing security 14234 policy on other components; the system's security depends on 14235 flawless operation of the component. (See: trusted process.) 14236 - "Benign": The component is not responsible for enforcing 14237 security policy, but it has sensitive authorizations. It must 14238 be trusted not to intentionally violate security policy, but 14239 security violations are assumed to be accidental and not likely 14240 to affect overall system security. 14241 - "Untrusted": The component is of unknown or suspicious 14242 provenance and must be treated as deliberately malicious. (See: 14243 malicious logic.) 14245 2. (I) /PKI/ A relationship between a certificate user and a CA in 14246 which the user acts according to the assumption that the CA 14247 creates only valid digital certificates. 14249 Tutorial: "Generally, an entity is said to 'trust' a second entity 14250 when the first entity makes the assumption that the second entity 14251 will behave exactly as the first entity expects. This trust may 14252 apply only for some specific function. The key role of trust in 14253 [X.509] is to describe the relationship between an entity [i.e., a 14254 certificate user] and a [CA]; an entity shall be certain that it 14255 can trust the CA to create only valid and reliable certificates." 14256 [X509] 14258 $ trust anchor 14259 (I) /PKI/ An established point of trust (usually based on the 14260 authority of some person, office, or organization) from which a 14261 certificate user begins the validation of a certification path. 14262 (See: path validation, trust anchor CA, trust anchor certificate, 14263 trust anchor key.) 14265 Usage: ISDs that use this term SHOULD state a definition for it 14266 because it is used in various ways in existing ISDs and other PKI 14267 literature. The literature almost always uses this term in a sense 14268 that is equivalent to this definition, but usage often differs 14269 with regard to what constitutes the point of trust. 14271 Tutorial: A trust anchor may be defined as being based on a public 14272 key, a CA, a public-key certificate, or some combination or 14273 variation of those: 14275 - 1. A public key as a point of trust: Although a certification 14276 path is defined as beginning with a "sequence of public-key 14277 certificates", an implementation of a path validation process 14278 might not explicitly handle a root certificate as part of the 14279 path, but instead begin the process by using a trusted root key 14280 to verify the signature on a certificate that was issued by the 14281 root. 14283 Therefore, "trust anchor" is sometimes defined as just a public 14284 key. (See: root key, trust anchor key, trusted key.) 14286 - 2. A CA as a point of trust: A trusted public key is just one 14287 of the data elements needed for path validation; the IPS path 14288 validation algorithm [R3280] also needs the name of the CA to 14289 which that key belongs, i.e., the DN of the issuer of the first 14290 X.509 certificate to be validated on the path. (See: issue.) 14292 Therefore, "trust anchor" is sometimes defined as either just a 14293 CA (where some public key is implied) or as a CA together with 14294 a specified public key belonging to that CA. (See: root, trust 14295 anchor CA, trusted CA.) 14297 Example: "A public key and the name of a [CA] that is used to 14298 validate the first certificate in a sequence of certificates. 14299 The trust anchor public key is used to verify the signature on 14300 a certificate issued by a trust anchor [CA]." [SP57] 14302 - 3. A public-key certificate as a point of trust: In addition to 14303 the trusted CA's public key and name, the path validation 14304 algorithm needs to know the digital signature algorithm and any 14305 associated parameters with which the public key is used, and 14306 also any constraints that have been placed on the set of paths 14307 that may be validated using the key. All of this information is 14308 available from a CA's public-key certificate. 14310 Therefore, "trust anchor" is sometimes defined as a public-key 14311 certificate of a CA. (See: root certificate, trust anchor 14312 certificate, trusted certificate.) 14314 - 4. Combinations: Combinations and variations of the first three 14315 definitions are also used in the PKI literature. 14317 Example: "trust anchor information". The IPS standard for path 14318 validation [R3280] specifies the information that describes "a 14319 CA that serves as a trust anchor for the certification path. 14320 The trust anchor information includes: (a) the trusted issuer 14321 name, (b) the trusted public key algorithm, (c) the trusted 14322 public key, and (d) optionally, the trusted public key 14323 parameters associated with the public key. The trust anchor 14324 information may be provided to the path processing procedure in 14325 the form of a self-signed certificate. The trusted anchor 14326 information is trusted because it was delivered to the path 14327 processing procedure by some trustworthy out-of-band procedure. 14328 If the trusted public key algorithm requires parameters, then 14329 the parameters are provided along with the trusted public key." 14331 $ trust anchor CA 14332 (I) A CA that is the subject of a trust anchor certificate or 14333 otherwise establishes a trust anchor key. (See: root, trusted CA.) 14335 Tutorial; The selection of a CA to be a trust anchor is a matter 14336 of policy. Some of the possible choices include (a) the top CA in 14337 a hierarchical PKI, (b) the CA that issued the verifier's own 14338 certificate, or (c) any other CA in a network PKI. Different 14339 applications may rely on different trust anchors, or may accept 14340 paths that begin with any of a set of trust anchors. The IPS path 14341 validation algorithm is the same regardless of the choice. 14343 $ trust anchor certificate 14344 (I) A public-key certificate that is used to provide the first 14345 public key in a certification path. (See: root certificate, trust 14346 anchor, trusted certificate.) 14348 $ trust anchor key 14349 (I) A public key that is used as the first public key in a 14350 certification path. (See: root key, trust anchor, trusted public 14351 key.) 14353 $ trust anchor information 14354 (I) See: secondary definition under "trust anchor". 14356 $ trust chain 14357 (D) Synonym for "certification path". (See: trust anchor, trusted 14358 certificate.) 14360 Deprecated Term: ISDs SHOULD NOT use this term, because it 14361 unnecessarily duplicates the meaning of the internationally 14362 standardized term. 14364 Also, the term mixes concepts in a potentially misleading way. 14365 Having "trust" involves factors unrelated to simply verifying 14366 signatures and performing other tests as specified by a standard 14367 algorithm for path validation (e.g., RFC 3280). Thus, even if a 14368 user is able to validate a certification path algorithmically, the 14369 user still might distrust one of the CAs that issued certificates 14370 in that path or distrust some other aspects of the PKI. 14372 $ trust-file PKI 14373 (I) A non-hierarchical PKI in which each certificate user has a 14374 local file (which is used by application software) of public-key 14375 certificates that the user trusts as starting points (i.e., trust 14376 anchors) for certification paths. (Compare: hierarchical PKI, mesh 14377 PKI, trusted certificate, web of trust.) 14379 Example: Popular browsers are distributed with an initial file of 14380 trust anchor certificates, which often are self-signed 14381 certificates. Users can add certificates to the file or delete 14382 from it. The file may be directly managed by the user, or the 14383 user's organization may manage it from a centralized server. 14385 $ trust hierarchy 14386 (D) Synonym for "certification hierarchy". 14388 Deprecated Usage: ISDs SHOULD NOT use this term because it mixes 14389 concepts in a potentially misleading way. (See: trust, trust 14390 chain, web of trust.) 14392 $ trust level 14393 (N) A characterization of a standard of security protection to be 14394 met by an information system. (See: Common Criteria, TCSEC.) 14396 Tutorial: A trust level is based not only on (a) the presence of 14397 security mechanisms, but also on the use of (b) systems 14398 engineering discipline to properly structure the system and (c) 14399 implementation analysis to ensure that the system provides an 14400 appropriate degree of trust. 14402 $ trusted 14403 (I) See: secondary definition under "trust". 14405 $ trusted CA 14406 (I) A CA upon which a certificate user relies as issuing valid 14407 certificates; especially a CA that is used as a trust anchor CA. 14408 (See: certification path, root, trust anchor CA, validation.) 14410 Tutorial. This trust is transitive to the extent that the X.509 14411 certificate extensions permit; that is, if a trusted CA issues a 14412 certificate to another CA, a user that trusts the first CA also 14413 trusts the second CA if the user succeeds in validating the 14414 certificate path (see: path validation). 14416 $ trusted certificate 14417 1. (I) A digital certificate that a certificate user accepts as 14418 being valid "a priori", i.e., without testing the certificate to 14419 validate it as the final certificate on a certification path; 14420 especially a certificate that is used as a trust anchor 14421 certificate. (See: certification path, root certificate, trust 14422 anchor certificate, trust-file PKI, validation.) 14424 Tutorial: The acceptance of a certificate as trusted is a matter 14425 of policy and choice. Usually, a certificate is accepted as 14426 trusted because the user obtained it by reliable, out-of-band 14427 means that cause the user to believe the certificate accurately 14428 binds its subject's name to the subject's public key or other 14429 attribute values. Many choices are possible; e.g., a trusted 14430 public-key certificate might be (a) the root certificate in a 14431 hierarchical PKI, (b) the certificate of the CA that issued the 14432 user's own certificate in a mesh PKI, or (c) a certificate 14433 provided with an application that uses a trust-file PKI. 14435 $ Trusted Computer System Evaluation Criteria (TCSEC) 14436 (N) A standard for evaluating the security provided by operating 14437 systems [CSC001, DoD1]. Known as the "Orange Book" because of the 14438 color of its cover; first document in the Rainbow Series. (See: 14439 Common Criteria, Deprecated Usage under "Green Book", Orange Book, 14440 trust level, trusted computer system. Compare: TSEC.) 14442 Tutorial: The TCSEC defines classes of hierarchically ordered 14443 assurance levels for rating computer systems. From highest to 14444 lowest, the classes are as follows: 14445 - Division A: Verified protection. 14446 Beyond A1 Beyond current technology. (See: beyond A1.) 14447 Class A1 Verified design. (See: SCOMP.) 14448 - Division B: Mandatory protection. 14449 Class B3 Security domains. 14450 Class B2 Structured protection. (See: Multics.) 14451 Class B1 Labeled security protection. 14452 - Division C: Discretionary protection. 14453 Class C2 Controlled access protection. 14454 Class C1 Discretionary security protection. 14455 - Division D: Minimal protection, i.e., has been evaluated but 14456 does not meet the requirements for a higher evaluation class. 14458 $ trusted computing base (TCB) 14459 (N) "The totality of protection mechanisms within a computer 14460 system, including hardware, firmware, and software, the 14461 combination of which is responsible for enforcing a security 14462 policy." [NCS04] (See: "trusted" under "trust".) 14464 $ trusted distribution 14465 (I) /COMPUSEC/ "A trusted method for distributing the TCB 14466 hardware, software, and firmware components, both originals and 14467 updates, that provides methods for protecting the TCB from 14468 modification during distribution and for detection of any changes 14469 to the TCB that may occur." [NCS04] (See: code signing, 14470 configuration control.) 14472 $ trusted key 14473 (D) Abbreviation for "trusted public key" and also for other types 14474 of keys. (See: root key, trust anchor key.) 14476 Deprecated Usage: ISDs SHOULD either (a) state a definition for 14477 this term or (b) use a different, less ambiguous term. This term 14478 is ambiguous when it stands alone; e.g., it could refer to a 14479 trusted public key or to a private key or symmetric key that is 14480 believed to be secure (i.e., not compromised). 14482 $ trusted path 14483 1a. (I) /COMPUSEC/ A mechanism by which a computer system user can 14484 communicate directly and reliably with the TCB and that can only 14485 be activated by the user or the TCB and cannot be imitated by 14486 untrusted software within the computer. [NCS04] 14488 1b. (I) /COMSEC/ A mechanism by which a person or process can 14489 communicate directly with a cryptographic module and that can only 14490 be activated by the person, process, or module, and cannot be 14491 imitated by untrusted software within the module. [FP140] 14493 $ trusted process 14494 1. (I) A system component that has privileges that enable it to 14495 affect the state of system security and that can, therefore, 14496 through incorrect or malicious execution, violate the system's 14497 security policy. (See: privileged process, trusted system.) 14499 $ trusted public key 14500 (I) A public key upon which a user relies; especially a public key 14501 that is used as a trust anchor key. (See: certification path, root 14502 key, trust anchor key, validation.) 14504 Tutorial: A trusted public key could be (a) the root key in a 14505 hierarchical PKI, (b) the key of the CA that issued the user's own 14506 certificate in a mesh PKI, or (c) any key accepted by the user in 14507 a trust-file PKI. 14509 $ trusted recovery 14510 (I) A process that, after a system has experienced a failure or an 14511 attack, restores the system to normal operation (or to a secure 14512 state) without causing a security compromise. (See: recovery.) 14514 $ trusted subnetwork 14515 (I) A subnetwork containing hosts and routers that trust each 14516 other not to engage in active or passive attacks. (There also is 14517 an assumption that the underlying communication channels -- e.g., 14518 telephone lines, or a LAN -- are protected from attack.) 14520 $ trusted system 14521 1. (I) /information system/ A system that operates as expected, 14522 according to design and policy, doing what is required -- despite 14523 environmental disruption, human user and operator errors, and 14524 attacks by hostile parties -- and not doing other things [NRC98]. 14525 (See: trust level, trusted process. Compare: trustworthy.) 14527 2. (N) /multilevel secure/ "A [trusted computer system is a] 14528 system that employs sufficient hardware and software assurance 14529 measures to allow its use for simultaneous processing of a range 14530 of sensitive or classified information." [NCS04] (See: multilevel 14531 security mode.) 14533 $ Trusted Systems Interoperability Group (TSIG) 14534 (N) A forum of computer vendors, system integrators, and users 14535 devoted to promoting interoperability of trusted computer systems. 14537 $ trustworthy system 14538 1. (I) A system that not only is trusted, but also for which the 14539 trust can be guaranteed in some convincing way, such as through 14540 formal analysis or code review. (See: trust. Compare: trusted.) 14542 2. (O) /Digital Signature Guidelines/ "Computer hardware, 14543 software, and procedures that: (a) are reasonably secure from 14544 intrusion and misuse; (b) provide a reasonably reliable level of 14545 availability, reliability, and correct operation; (c) are 14546 reasonably suited to performing their intended functions; and (d) 14547 adhere to generally accepted security principles." [DSG] 14549 $ TSEC 14550 (O) See: Telecommunications Security Nomenclature System. 14551 (Compare: TCSEC.) 14553 $ TSIG 14554 1. (N) See: Trusted System Interoperability Group. 14556 2. (I) A mnemonic (presumed to be derived from "Transaction 14557 SIGnature") referring to an Internet protocol (RFC 2845) for data 14558 origin authentication and data integrity for certain DNS 14559 operations. (See: TKEY.) 14561 $ tunnel 14562 1. (I) A communication channel created in a computer network by 14563 encapsulating (i.e., layering) a communication protocol's data 14564 packets in (i.e., above) a second protocol that normally would be 14565 carried above, or at the same layer as, the first one. (See: L2TP, 14566 VPN.) (Compare: covert channel.) 14568 Tutorial: Tunneling can involve almost any two IPS protocol 14569 layers. For example, a TCP connection between two hosts could 14570 conceivably be carried above SMTP (i.e., in SMTP messages) as a 14571 covert channel to evade access controls that a security gateway 14572 applies to the normal TCP layer that is below SMTP. 14574 Usually, however, a tunnel is a logical point-to-point link -- 14575 i.e., an OSIRM Layer 2 connection -- created by encapsulating the 14576 Layer 2 protocol in one of the following three types of IPS 14577 protocols: (a) an IPS Transport-Layer protocol (such as TCP), (b) 14578 an IPS Network-Layer or Internet-Layer protocol (such as IP), or 14579 (c) another Layer 2 protocol. In many cases, the encapsulation is 14580 accomplished with an extra, intermediate protocol (i.e., a 14581 "tunneling protocol"; e.g., L2TP) that is layered below the 14582 tunneled Layer 2 protocol and above the encapsulating protocol. 14584 Tunneling can be used to move data between computers that use a 14585 protocol not supported by the network connecting them. Tunneling 14586 also can enable a computer network to use the services of a second 14587 network as though the second network were a set of point-to-point 14588 links between the first network's nodes. (See: virtual private 14589 network.) 14591 2. (O) /SET/ The name of a SET private extension that indicates 14592 whether the CA or the payment gateway supports passing encrypted 14593 messages to the cardholder through the merchant. If so, the 14594 extension lists OIDs of symmetric encryption algorithms that are 14595 supported. 14597 $ tunnel mode 14598 (I) One of two ways to apply the IPsec protocols (AH and ESP) to 14599 protect data packets; in this mode, the IPsec protocol 14600 encapsulates (i.e., the protection applies to) IP packets, rather 14601 than the packets of higher layer protocols. (Compare: transport 14602 mode.) 14604 Tutorial: Each end of a tunnel-mode security association may be 14605 either a host or a security gateway. Whenever either end of an 14606 IPsec security association is a security gateway, the association 14607 is required to be in tunnel mode. 14609 $ two-person control 14610 (I) The close surveillance and control of a system, a process, or 14611 materials (especially with regard to cryptography) at all times by 14612 a minimum of two appropriately authorized persons, each capable of 14613 detecting incorrect and unauthorized procedures with respect to 14614 the tasks to be performed and each familiar with established 14615 security requirements. (See: dual control, no-lone zone.) 14617 $ Twofish 14618 (O) A symmetric, 128-bit block cipher with variable key length 14619 (128, 192, or 256 bits), developed by Counterpane Labs as a 14620 candidate for the AES. (See: Blowfish.) 14622 $ type 0 product 14623 (O) /cryptography, U.S. Government/ Classified cryptographic 14624 equipment endorsed by NSA specifically for use (when appropriately 14625 keyed) in electronically distributing bulk keying material. 14627 $ type 1 product 14628 (O) /cryptography, U.S. Government/ "Classified or controlled 14629 cryptographic item endorsed by the NSA for securing classified and 14630 sensitive U.S. Government information, when appropriately keyed. 14631 The term refers only to products, and not to information, key, 14632 services, or controls. Type 1 products contain classified NSA 14633 algorithms. They are available to U.S. Government users, their 14634 contractors, and federally sponsored non-U.S. Government 14635 activities subject to export restrictions in accordance with 14636 International Traffic in Arms Regulation." [C4009] (See: ITAR.) 14638 $ type 2 product 14639 (O) /cryptography, U.S. Government/ "Unclassified cryptographic 14640 equipment, assembly, or component, endorsed by the NSA, for use in 14641 national security systems as defined in Title 40 U.S.C. Section 14642 1452." [C4009] (See: national security system. Compare: EUCI.) 14644 $ type 3 algorithm 14645 (O) /cryptography, U.S. Government/ "Cryptographic algorithm 14646 registered by [NIST] and published as a [FIPS] for use in 14647 protecting unclassified sensitive information or commercial 14648 information." [C4009] 14650 $ type 4 algorithm 14651 (O) /cryptography, U.S. Government/ "Unclassified cryptographic 14652 algorithm that has been registered by [NIST] but not published as 14653 a [FIPS]." [C4009] 14655 $ UDP 14656 (I) See: User Datagram Protocol. 14658 $ UDP flood 14659 (I) A denial-of-service attack that takes advantage of (a) one 14660 system's UDP test function that generates a series of characters 14661 for each packet it receives and (b) another system's UPD test 14662 function that echoes any character it receives; the attack 14663 connects (a) to (b) to cause a nonstop flood of data between the 14664 two systems. 14666 $ unauthorized disclosure 14667 (I) A circumstance or event whereby an entity gains access to 14668 information for which the entity is not authorized. 14670 Tutorial: This type of threat consequence can be caused by the 14671 following types of threat actions: exposure, interception, 14672 inference, intrusion. Some methods of protecting against this 14673 consequence include access control, flow control, and inference 14674 control. (See: data confidentiality.) 14676 $ unauthorized user 14677 (I) /access control/ A system entity that accesses a system 14678 resource for which the entity has not received an authorization. 14679 (See: user. Compare: authorized user, insider, outsider.) 14681 Usage: ISDs that use this term SHOULD state a definition for it 14682 because the term is used in many ways and could easily be 14683 misunderstood. 14685 $ uncertainty 14686 (N) An information-theoretic measure (usually stated as a number 14687 of bits) of the minimum amount of plaintext information that needs 14688 to be recovered from cipher text in order to learn the entire 14689 plain text that was encrypted. [SP63] (See: entropy.) 14691 $ unclassified 14692 (I) Not classified. 14694 $ unencrypted 14695 (I) Not encrypted. 14697 $ unforgeable 14698 (I) /cryptography/ The property of a cryptographic data structure 14699 (i.e., a data structure that is defined using one or more 14700 cryptographic functions, e.g., see digital certificate) that makes 14701 it computationally infeasible to construct (i.e., compute) an 14702 unauthorized but correct value of the structure without having 14703 knowledge of one of more keys. 14705 Tutorial: This definition is narrower than general English usage, 14706 where "unforgeable" means unable to be fraudulently created or 14707 duplicated. In that broader sense, anyone can forge a digital 14708 certificate containing any set of data items whatsoever by 14709 generating the to-be-signed certificate and signing it with any 14710 private key whatsoever. But for PKI purposes, the forged data 14711 structure is invalid if it is not signed with the true private key 14712 of the claimed issuer; thus, the forgery will be detected when a 14713 certificate user uses the true public key of the claimed issuer to 14714 verify the signature. 14716 $ uniform resource identifier (URI) 14717 (I) A type of formatted identifier (RFC 1630) that encapsulates 14718 the name of an Internet object, and labels it with an 14719 identification of the name space, thus producing a member of the 14720 universal set of names in registered name spaces and of addresses 14721 referring to registered protocols or name spaces. 14723 Tutorial: URIs are used in HTML to identify the target of 14724 hyperlinks. In common practice, URIs include URLs and relative 14725 URLs (RFC 1808). 14727 $ uniform resource locator (URL) 14728 (I) A type of formatted identifier (RFC 1738) that describes the 14729 access method and location of an information resource object on 14730 the Internet. 14732 Tutorial: A URL is a URI that provides explicit instructions on 14733 how to access the named object. For example, 14734 "ftp://bbnarchive.bbn.com/foo/bar/picture/cambridge.zip" is a URL. 14735 The part before the colon specifies the access scheme or protocol, 14736 and the part after the colon is interpreted according to that 14737 access method. Usually, two slashes after the colon indicate the 14738 host name of a server (written as a domain name). In an FTP or 14739 HTTP URL, the host name is followed by the path name of a file on 14740 the server. The last (optional) part of a URL may be either a 14741 fragment identifier that indicates a position in the file, or a 14742 query string. 14744 $ uniform resource name (URN) 14745 (I) A URI that has an institutional commitment to persistence and 14746 availability. 14748 $ untrusted 14749 (I) See: secondary definition under "trust". 14751 $ untrusted process 14752 1. (I) A system component that is not able to affect the state of 14753 system security through incorrect or malicious operation. Example: 14754 A component that has its operations confined by a security kernel. 14755 (See: trusted process.) 14757 2. (I) A system component that (a) has not been evaluated or 14758 examined for adherence to a specified security policy and, 14759 therefore, (b) must be assumed to contain logic that might attempt 14760 to circumvent system security. 14762 $ UORA 14763 (O) See: user-PIN ORA. 14765 $ update 14766 See: "certificate update" and "key update". 14768 $ upgrade 14769 (I) /data security/ Increase the classification level of data 14770 without changing the information content of the data. (See: 14771 classify, downgrade, regrade.) 14773 $ URI 14774 (I) See: uniform resource identifier. 14776 $ URL 14777 (I) See: uniform resource locator. 14779 $ URN 14780 (I) See: uniform resource name. 14782 $ user 14783 (I) An active system entity that uses a product or service 14784 provided by the system, or that accesses system resources to 14785 produce a product or service of the system. (See: access, [R2504]. 14786 Compare: authorized user, manager, operator, principal, privileged 14787 user, subject, subscriber, unauthorized user.) 14789 Usage: ISDs that use this term SHOULD state a definition for it 14790 because the term is used in many ways and could easily be 14791 misunderstood: 14792 - This term usually refers to an entity that has been authorized 14793 to access the system, but the term sometimes is used without 14794 regard for whether access is authorized. 14795 - This term usually refers to a living human being acting either 14796 personally or in an organizational role, but the term also may 14797 refer to an automated process in the form of hardware, 14798 softwarr, or firmware; to a set of persons; or to a set of 14799 processes. 14800 - ISDs SHOULD exclude the case of a mixed set containing both 14801 persons and processes. The exclusion is intended to prevent 14802 situations that might require a security policy to be 14803 interpreted in two different and conflicting ways. 14805 A user can be characterized as direct or indirect: 14806 - "Passive user": A system entity that is (a) outside the 14807 system's security perimeter *and* (b) can receive output from 14808 the system but cannot provide input or otherwise interact with 14809 the system. 14810 - "Active user": A system entity that is (a) inside the system's 14811 security perimeter *or* (b) can provide input or otherwise 14812 interact with the system. 14814 $ user authentication service 14815 (I) A security service that verifies the identity claimed by an 14816 entity that attempts to access the system. (See: authentication, 14817 user.) 14819 $ User Datagram Protocol (UDP) 14820 (I) An Internet Standard, Transport-Layer protocol (RFC 768) that 14821 delivers a sequence of datagrams from one computer to another in a 14822 computer network. (See: UPD flood.) 14824 Tutorial: UDP assumes that IP is the underlying protocol. UDP 14825 enables application programs to send transaction-oriented data to 14826 other programs with minimal protocol mechanism. UDP does not 14827 provide reliable delivery, flow control, sequencing, or other end- 14828 to-end service guarantees that TCP does. 14830 $ user identity 14831 (I) See: identity. 14833 $ user identifier 14834 (I) See: identifier. 14836 $ user PIN 14837 (O) /MISSI/ One of two PINs that control access to the functions 14838 and stored data of a FORTEZZA PC card. Knowledge of the user PIN 14839 enables the card user to perform the FORTEZZA functions that are 14840 intended for use by an end user. (Compare: SSO PIN.) 14842 $ user-PIN ORA (UORA) 14843 (O) /MISSI/ A MISSI organizational RA that operates in a mode in 14844 which the ORA performs only the subset of card management 14845 functions that are possible with knowledge of the user PIN for a 14846 FORTEZZA PC card. (See: no-PIN ORA, SSO-PIN ORA.) 14848 $ usurpation 14849 (I) A circumstance or event that results in control of system 14850 services or functions by an unauthorized entity. This type of 14851 threat consequence can be caused by the following types of threat 14852 actions: misappropriation, misuse. (See: access control.) 14854 $ UTCTime 14855 (N) The ASN.1 data type "UTCTime" contains a calendar date 14856 (YYMMDD) and a time to a precision of either one minute (HHMM) or 14857 one second (HHMMSS), where the time is either (a) Coordinated 14858 Universal Time or (b) the local time followed by an offset that 14859 enables Coordinated Universal Time to be calculated. Note: UTCTime 14860 has the Year 2000 problem. (See: Coordinated Universal Time, 14861 GeneralizedTime.) 14863 $ v1 certificate 14864 (N) An abbreviation that ambiguously refers to either an "X.509 14865 public-key certificate in version 1 format" or an "X.509 attribute 14866 certificate in version 1 format". 14868 Deprecated Usage: ISDs MAY use this term as an abbreviation of 14869 "version 1 X.509 public-key certificate", but only after using the 14870 full term at the first instance. Otherwise, the term is ambiguous, 14871 because X.509 specifies both v1 public-key certificates and v1 14872 attribute certificates. (See: X.509 attribute certificate, X.509 14873 public-key certificate.) 14875 $ v1 CRL 14876 (N) Abbreviation of "X.509 CRL in version 1 format". 14878 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 14879 term at its first occurrence and define the abbreviation there. 14881 $ v2 certificate 14882 (N) Abbreviation of "X.509 public-key certificate in version 2 14883 format". 14885 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 14886 term at its first occurrence and define the abbreviation there. 14888 $ v2 CRL 14889 (N) Abbreviation of "X.509 CRL in version 2 format". 14891 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 14892 term at its first occurrence and define the abbreviation there. 14894 $ v3 certificate 14895 (N) Abbreviation of "X.509 public-key certificate in version 3 14896 format". 14898 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 14899 term at its first occurrence and define the abbreviation there. 14901 $ valid certificate 14902 1. (I) A digital certificate that can be validated successfully. 14903 (See: validate, verify.) 14905 2. (I) A digital certificate for which the binding of the data 14906 items can be trusted. 14908 $ valid signature 14909 (D) Synonym for "authentic signature". 14911 Deprecated Term: ISDs SHOULD NOT use this term; instead, say 14912 "authentic signature". This Glossary recommends saying "validate 14913 the certificate" and "verify the signature"; therefore, it would 14914 be inconsistent to say that a signature is "valid". (See: 14915 validate, verify.) 14917 $ validate 14918 1. (I) Establish the soundness or correctness of a construct. 14919 Example: certificate validation. (See: validate vs. verify.) 14921 2. (I) To officially approve something, sometimes in relation to a 14922 standard. Example: NIST validates cryptographic modules for 14923 conformance with FIPS PUB 140 [FP140]. 14925 $ validate vs. verify 14926 Usage: To ensure consistency and align with ordinary English 14927 usage, ISDs SHOULD comply with the following two rules: 14928 - Rule 1: Use "validate" when referring to a process intended to 14929 establish the soundness or correctness of a construct (e.g., 14930 see: certificate validation). (See: validate.) 14931 - Rule 2: Use "verify" when referring to a process intended to 14932 test or prove the truth or accuracy of a fact or value (e.g., 14933 see: authenticate). (See: verify.) 14935 Tutorial: The Internet security community sometimes uses these two 14936 terms inconsistently, especially in a PKI context. Most often, 14937 however, we say "verify the signature" but say "validate the 14938 certificate". That is, we "verify" atomic truths but "validate" 14939 data structures, relationships, and systems that are composed of 14940 or depend on verified items. This usage has a basis in Latin: 14942 The word "valid" derives from a Latin word that means "strong". 14943 Thus, to validate means to check that a construct is sound. For 14944 example, a certificate user validates a public-key certificate to 14945 establish trust in the binding that the certificate asserts 14946 between an identity and a key. This can include checking various 14947 aspects of the certificate's construction, such as verifying the 14948 digital signature on the certificate by performing calculations, 14949 verifying that the current time is within the certificate's 14950 validity period, and validating a certification path involving 14951 additional certificates. 14953 The word "verify" derives from a Latin word that means "true". 14954 Thus, to verify means to check the truth of an assertion by 14955 examining evidence or performing tests. For example, to verify an 14956 identity, an authentication process examines identification 14957 information that is presented or generated. To validate a 14958 certificate, a certificate user verifies the digital signature on 14959 the certificate by performing calculations, verifies that the 14960 current time is within the certificate's validity period, and may 14961 need to validate a certification path involving additional 14962 certificates. 14964 $ validation 14965 (I) See: validate vs. verify. 14967 $ validity period 14968 (I) /PKI/ A data item in a digital certificate that specifies the 14969 time period for which the binding between data items (especially 14970 between the subject name and the public key value in a public-key 14971 certificate) is valid, except if the certificate appears on a CRL 14972 or the key appears on a CKL. (See: cryptoperiod, key lifetime.) 14974 $ value-added network (VAN) 14975 (I) A computer network or subnetwork (usually a commercial 14976 enterprise) that transmits, receives, and stores EDI transactions 14977 on behalf of its users. 14979 Tutorial: A VAN may also provide additional services, ranging from 14980 EDI format translation, to EDI-to-FAX conversion, to integrated 14981 business systems. 14983 $ VAN 14984 (I) See: value-added network. 14986 $ verification 14987 1. (I) /authentication/ Presenting information to establish the 14988 truth of a claimed identity. (See: validate vs. verify.) 14990 2. (N) /COMPUSEC/ The process of comparing two levels of system 14991 specification for proper correspondence, such as comparing a 14992 security model with a top-level specification, a top-level 14993 specification with source code, or source code with object code. 14994 [NCS04] 14996 $ verified design 14997 (O) See: TCSEC Class A1. 14999 $ verify 15000 (I) To test or prove the truth or accuracy of a fact or value. For 15001 example, see "authenticate". (See: validate vs. verify.) 15003 $ vet 15004 (I) /verb/ To examine or evaluate thoroughly. (Compare: 15005 authenticate, identity proofing, validate, verify.) 15007 $ violation 15008 See: security violation. 15010 $ virtual private network (VPN) 15011 (I) A restricted-use, logical (i.e., artificial or simulated) 15012 computer network that is constructed from the system resources of 15013 a relatively public, physical (i.e., real) network (e.g., the 15014 Internet), often by using encryption (located at hosts or 15015 gateways), and often by tunneling links of the virtual network 15016 across the real network. 15018 Tutorial: A VPN is generally less expensive to build and operate 15019 than a dedicated real network, because the virtual network shares 15020 the cost of system resources with other users of the underlying 15021 real network. For example, if a corporation has LANs at several 15022 different sites, each connected to the Internet by a firewall, the 15023 corporation could create a VPN by (a) using encrypted tunnels to 15024 connect from firewall to firewall across the Internet and (b) not 15025 allowing any other traffic through the firewalls. 15027 $ virus 15028 (I) A self-replicating (and usually hidden) section of computer 15029 software (usually malicious logic) that propagates by infecting -- 15030 i.e., inserting a copy of itself into and becoming part of -- 15031 another program. A virus cannot run by itself; it requires that 15032 its host program be run to make the virus active. 15034 $ VisaCash 15035 (O) A smartcard-based electronic money system that incorporates 15036 cryptography and can be used to make payments via the Internet. 15037 (See: IOTP.) 15039 $ volatile media 15040 (I) Storage media that require an external power supply to 15041 maintain stored information. (Compare: non-volatile media, 15042 permanent storage.) 15044 $ VPN 15045 (I) See: virtual private network. 15047 $ vulnerability 15048 (I) A flaw or weakness in a system's design, implementation, or 15049 operation and management that could be exploited to violate the 15050 system's security policy. (See: harden.) 15052 Tutorial: A system can have three types of vulnerabilities: (a) 15053 vulnerabilities in design or specification; (b) vulnerabilities in 15054 implementation; and (c) vulnerabilities in operation and 15055 management. Most systems have one or more vulnerabilities, but 15056 this does not mean that the systems are too flawed to use. Not 15057 every threat results in an attack, and not every attack succeeds. 15058 Success depends on the degree of vulnerability, the strength of 15059 attacks, and the effectiveness of any countermeasures in use. If 15060 the attacks needed to exploit a vulnerability are very difficult 15061 to carry out, then the vulnerability may be tolerable. If the 15062 perceived benefit to an attacker is small, then even an easily 15063 exploited vulnerability may be tolerable. However, if the attacks 15064 are well understood and easily made, and if the vulnerable system 15065 is employed by a wide range of users, then it is likely that there 15066 will be enough motivation for someone to launch an attack. 15068 $ W3 15069 (D) Synonym for WWW. 15071 Deprecated Abbreviation: This abbreviation could be confused with 15072 W3C; use "WWW" instead. 15074 $ W3C 15075 (N) See: World Wide Web Consortium. 15077 $ war dialer 15078 (I) /slang/ A computer program that automatically dials a series 15079 of telephone numbers to find lines connected to computer systems, 15080 and catalogs those numbers so that a cracker can try to break the 15081 systems. 15083 Deprecated Usage: ISDs that use this term SHOULD state a 15084 definition for it because the term could confuse international 15085 readers. 15087 $ Wassenaar Arrangement 15088 (N) The Wassenaar Arrangement on Export Controls for Conventional 15089 Arms and Dual-Use Goods and Technologies is a global, multilateral 15090 agreement approved by 33 countries in July 1996 to contribute to 15091 regional and international security and stability, by promoting 15092 information exchange concerning, and greater responsibility in, 15093 transfers of arms and dual-use items, thus preventing 15094 destabilizing accumulations. (See: International Traffic in Arms 15095 Regulations.) 15097 Tutorial: The Arrangement began operations in September 1996 with 15098 headquarters in Vienna. The participating countries were 15099 Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech 15100 Republic, Denmark, Finland, France, Germany, Greece, Hungary, 15101 Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, 15102 Norway, Poland, Portugal, Republic of Korea, Romania, Russian 15103 Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, 15104 Ukraine, United Kingdom, and United States. 15106 Participating countries seek through their national policies to 15107 ensure that transfers do not contribute to the development or 15108 enhancement of military capabilities that undermine the goals of 15109 the arrangement, and are not diverted to support such 15110 capabilities. The countries maintain effective export controls for 15111 items on the agreed lists, which are reviewed periodically to 15112 account for technological developments and experience gained. 15113 Through transparency and exchange of views and information, 15114 suppliers of arms and dual-use items can develop common 15115 understandings of the risks associated with their transfer and 15116 assess the scope for coordinating national control policies to 15117 combat these risks. Members provide semi-annual notification of 15118 arms transfers, covering seven categories derived from the UN 15119 Register of Conventional Arms. Members also report transfers or 15120 denials of transfers of certain controlled dual-use items. 15121 However, the decision to transfer or deny transfer of any item is 15122 the sole responsibility of each participating country. All 15123 measures undertaken with respect to the arrangement are in 15124 accordance with national legislation and policies and are 15125 implemented on the basis of national discretion. 15127 $ watermarking 15128 See: digital watermarking. 15130 $ weak key 15131 (I) In the context of a particular cryptographic algorithm, a key 15132 value that provides poor security. 15134 Example: The DEA has four "weak keys" [Schn] for which encryption 15135 produces the same result as decryption. It also has ten pairs of 15136 "semi-weak keys" [Schn] (a.k.a. "dual keys" [FP074]) for which 15137 encryption with one key in the pair produces the same result as 15138 decryption with the other key. 15140 $ web, Web 15141 1. (I) /not capitalized/ ISDs SHOULD NOT capitalize "web" when 15142 using the term (usually as an adjective) to refer generically to 15143 technology -- such as web browsers, web servers, HTTP, and HTML -- 15144 that is used in the Web or similar networks. 15146 2. (I) /capitalized/ ISDs SHOULD capitalize "Web" when using the 15147 term (as either a noun or an adjective) to refer specifically to 15148 the World Wide Web. (Similarly, see: internet.) 15150 Usage: ISDs SHOULD NOT use "web" or "Web" in a way that might 15151 confuse these definitions with the PGP "web of trust". When using 15152 Web as an abbreviation for "World Wide Web", ISDs SHOULD fully 15153 spell out the term at the first instance of usage. 15155 $ web of trust 15156 (D) /PGP/ A trust-file PKI technique used for building a file of 15157 trusted public keys by making personal judgments about being able 15158 to trust certain people to be holding properly certified keys of 15159 other people. (See: certification hierarchy, mesh PKI, trust 15160 anchor, web, Web.) 15162 Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts 15163 in a potentially misleading way. This PKI technique does not 15164 depend on World Wide Web technology. 15166 $ web server 15167 (I) A software process that runs on a host computer connected to a 15168 network and responds to HTTP requests made by client web browsers. 15170 $ WEP 15171 (N) See: Wired Equivalency Protocol. 15173 $ Wired Equivalent Privacy (WEP) 15174 (N) A cryptographic protocol that is defined in the IEEE 802.11 15175 standard and encapsulates the packets on wireless LANs. Usage: 15176 a.k.a. "Wired Equivalency Protocol". 15178 Tutorial: The WEP design, which uses RC4 to encrypt both the plain 15179 text and a CRC, has been shown to be flawed in multiple ways; and 15180 it also has often suffered from flawed implementation and 15181 management. 15183 $ wiretapping 15184 (I) An attack that intercepts and accesses information contained 15185 in a data flow in a communication system. (See: active 15186 wiretapping, end-to-end encryption, passive wiretapping.) 15188 Usage: Although the term originally referred to making a 15189 mechanical connection to an electrical conductor that links two 15190 nodes, it is now used to refer to accessing information from any 15191 sort of medium used for a link or even from a node, such as a 15192 gateway or subnetwork switch. 15194 Tutorial: Wiretapping can be characterized according to intent: 15195 - "Active wiretapping" attempts to alter the data or otherwise 15196 affect the flow. 15197 - "Passive wiretapping" only attempts to observe the data flow 15198 and gain knowledge of information contained in it. 15200 $ work factor 15201 1a. (I) /COMPUSEC/ The estimated amount of effort or time that can 15202 be expected to be expended by a potential intruder to penetrate a 15203 system, or defeat a particular countermeasure, when using 15204 specified amounts of expertise and resources. (See: brute force, 15205 impossible, strength.) 15207 1b. (I) /cryptography/ The estimated amount of computing power and 15208 time needed to break a cryptographic system. (See: brute force, 15209 impossible, strength.) 15211 $ World Wide Web ("the Web", WWW) 15212 (N) The global, hypermedia-based collection of information and 15213 services that is available on Internet servers and is accessed by 15214 browsers using Hypertext Transfer Protocol and other information 15215 retrieval mechanisms. (See: web vs. Web, [R2084].) 15217 $ World Wide Web Consortium (W3C) 15218 (N) Created in October 1994 to develop and standardize protocols 15219 to promote the evolution and interoperability of the Web, and now 15220 consisting of hundreds of member organizations (commercial firms, 15221 government agencies, schools, and others). 15223 Tutorial: W3C Recommendations are developed through a process 15224 similar to that of the standards published by other organizations, 15225 such as the IETF. The W3 Recommendation Track (i.e., standards 15226 track) has four levels of increasing maturity: Working, Candidate 15227 Recommendation, Proposed Recommendation, and W3C Recommendation 15228 W3C Recommendations are similar to the standards published by 15229 others organizations. (Compare: Internet Standard, ISO.) 15231 $ worm 15232 (I) A computer program that can run independently, can propagate a 15233 complete working version of itself onto other hosts on a network, 15234 and may consume system resources destructively. (See: mobile code, 15235 Morris Worm, virus.) 15237 $ wrap 15238 (D) /verb/ To use cryptography to provide data confidentiality 15239 service for keying material. (See: encrypt. Compare: seal, 15240 shroud.) 15242 Deprecated Term: ISDs SHOULD NOT use this term as defined here; 15243 the definition duplicates the meaning of other, standard terms. 15244 Instead, use "encrypt" or another term that is specific with 15245 regard to the mechanism being used. 15247 $ write 15248 (I) /COMPUSEC/ A fundamental operation in an information system 15249 that results in a flow of information only from a subject to an 15250 object. (See: access mode.) 15252 $ WWW 15253 (I) See: World Wide Web. 15255 $ X.400 15256 (N) An ITU-T Recommendation [X400] that is one part of a joint 15257 ITU-T/ISO multi-part standard (X.400-X.421) that defines the 15258 Message Handling Systems. (The ISO equivalent is IS 10021, parts 15259 1-7.) (See: Message Handling Systems.) 15261 $ X.500 15262 (N) An ITU-T Recommendation [X500] that is one part of a joint 15263 ITU-T/ISO multi-part standard (X.500-X.525) that defines the X.500 15264 Directory, a conceptual collection of systems that provide 15265 distributed directory capabilities for OSI entities, processes, 15266 applications, and services. (The ISO equivalent is IS 9594-1 and 15267 related standards, IS 9594-x.) (See: directory vs. Directory, 15268 X.509.) 15270 Tutorial: The X.500 Directory is structured as a tree (the 15271 Directory Information Tree), and information is stored in 15272 directory entries. Each entry is a collection of information about 15273 one object, and each object has a DN. A directory entry is 15274 composed of attributes, each with a type and one or more values. 15275 For example, if a PKI uses the Directory to distribute 15276 certificates, then the X.509 public-key certificate of an end user 15277 is normally stored as a value of an attribute of type 15278 "userCertificate" in the Directory entry that has the DN that is 15279 the subject of the certificate. 15281 $ X.509 15282 (N) An ITU-T Recommendation [X509] that defines a framework to 15283 provide and support data origin authentication and peer entity 15284 authentication, including formats for X.509 public-key 15285 certificates, X.509 attribute certificates, and X.509 CRLs. (The 15286 ISO equivalent is IS 9498-4.) (See: X.500.) 15288 Tutorial: X.509 describes two "levels" of authentication: "simple 15289 authentication" and "strong authentication". It recommends, "While 15290 simple authentication offers some limited protection against 15291 unauthorized access, only strong authentication should be used as 15292 the basis for providing secure services." 15294 $ X.509 attribute certificate 15295 (N) An attribute certificate in the version 1 (v1) format defined 15296 by X.509. (The v1 designation for an X.509 attribute certificate 15297 is disjoint from the v1 designation for an X.509 public-key 15298 certificate, and from the v1 designation for an X.509 CRL.) 15300 Tutorial: An X.509 attribute certificate has a "subject" field, 15301 but the attribute certificate is a separate data structure from 15302 that subject's public-key certificate. A subject may have multiple 15303 attribute certificates associated with each of its public-key 15304 certificates, and an attribute certificate may be issued by a 15305 different CA than the one that issued the associated public-key 15306 certificate. 15308 An X.509 attribute certificate contains a sequence of data items 15309 and has a digital signature that is computed from that sequence. 15310 In addition to the signature, an attribute certificate contains 15311 items 1 through 9 listed below: 15313 1. version Identifies v1. 15314 2. subject Is one of the following: 15315 2a. baseCertificateID Issuer and serial number of an 15316 X.509 public-key certificate. 15317 2b. subjectName DN of the subject. 15318 3. issuer DN of the issuer (the CA who signed). 15319 4. signature OID of algorithm that signed the cert. 15320 5. serialNumber Certificate serial number; 15321 an integer assigned by the issuer. 15322 6. attCertValidityPeriod Validity period; a pair of UTCTime 15323 values: "not before" and "not after". 15324 7. attributes Sequence of attributes describing the 15325 subject. 15326 8. issuerUniqueId Optional, when a DN is not sufficient. 15327 9. extensions Optional. 15329 $ X.509 certificate 15330 (N) Synonym for "X.509 public-key certificate". 15332 Usage: ISDs MAY use this term as an abbreviation of "X.509 public- 15333 key certificate", but only after using the full term at the first 15334 instance. Otherwise, the term is ambiguous, because X.509 15335 specifies both public-key certificates and attribute certificates. 15336 (See: X.509 attribute certificate, X.509 public-key certificate.) 15338 Deprecated Usage: ISDs SHOULD NOT use this term as an abbreviation 15339 of "X.509 attribute certificate", because the term is much more 15340 commonly used to mean "X.509 public-key certificate" and, 15341 therefore, is likely to be misunderstood. 15343 $ X.509 certificate revocation list (CRL) 15344 (N) A CRL in one of the formats defined by X.509 -- version 1 (v1) 15345 or version 2 (v2). (The v1 and v2 designations for an X.509 CRL 15346 are disjoint from the v1 and v2 designations for an X.509 public- 15347 key certificate, and from the v1 designation for an X.509 15348 attribute certificate.) (See: certificate revocation.) 15350 Usage: ISDs SHOULD NOT refer to an X.509 CRL as a digital 15351 certificate; however, note that an X.509 CRL does meet this 15352 Glossary's definition of "digital certificate". That is, like a 15353 digital certificate, an X.509 CRL makes an assertion and is signed 15354 by a CA. But instead of binding a key or other attributes to a 15355 subject, an X.509 CRL asserts that certain previously issued, 15356 X.509 certificates have been revoked. 15358 Tutorial: An X.509 CRL contains a sequence of data items and has a 15359 digital signature computed on that sequence. In addition to the 15360 signature, both v1 and v2 contain items 2 through 6b listed below. 15361 Version 2 contains item 1 and may optionally contain 6c and 7. 15363 1. version Optional. If present, identifies v2. 15364 2. signature OID of the algorithm that signed CRL. 15366 3. issuer DN of the issuer (the CA who signed). 15367 4. thisUpdate A UTCTime value. 15368 5. nextUpdate A UTCTime value. 15369 6. revokedCertificates 3-tuples of 6a, 6b, and (optional) 6c: 15370 6a. userCertificate A certificate's serial number. 15371 6b. revocationDate UTCTime value for the revocation date. 15372 6c. crlEntryExtensions Optional. 15373 7. crlExtensions Optional. 15375 $ X.509 public-key certificate 15376 (N) A public-key certificate in one of the formats defined by 15377 X.509 -- version 1 (v1), version 2 (v2), or version 3 (v3). (The 15378 v1 and v2 designations for an X.509 public-key certificate are 15379 disjoint from the v1 and v2 designations for an X.509 CRL, and 15380 from the v1 designation for an X.509 attribute certificate.) 15382 Tutorial: An X.509 public-key certificate contains a sequence of 15383 data items and has a digital signature computed on that sequence. 15384 In addition to the signature, all three versions contain items 1 15385 through 7 listed below. Only v2 and v3 certificates may also 15386 contain items 8 and 9, and only v3 may contain item 10. 15388 1. version Identifies v1, v2, or v3. 15389 2. serialNumber Certificate serial number; 15390 an integer assigned by the issuer. 15391 3. signature OID of algorithm that was used to 15392 sign the certificate. 15393 4. issuer DN of the issuer (the CA who signed). 15394 5. validity Validity period; a pair of UTCTime 15395 values: "not before" and "not after". 15396 6. subject DN of entity who owns the public key. 15397 7. subjectPublicKeyInfo Public key value and algorithm OID. 15398 8. issuerUniqueIdentifier Defined for v2, v3; optional. 15399 9. subjectUniqueIdentifier Defined for v2, v2; optional. 15400 10. extensions Defined only for v3; optional. 15402 $ X9 15403 See: "Accredited Standards Committee X9" under "ANSI". 15405 $ XML 15406 (N) See: Extensible Markup Language. 15408 $ XML-Signature. 15409 (N) A W3C Recommendation (i.e. approved standard) that specifies 15410 XML syntax and processing rules for creating and representing 15411 digital signatures (based on asymmetric cryptography) that can be 15412 applied to any digital content (i.e., any data object) including 15413 other XML material. 15415 $ XTACACS 15416 (I) Cisco Corporation's implementation of the Terminal Access 15417 Controller (TAC) Access Control System. This implementation 15418 enhances and extends the original TACACS. (See: TACACS, TACACS+.) 15420 $ Yellow Book 15421 (D) /slang/ Synonym for "Computer Security Requirements: Guidance 15422 for Applying the [U.S.] Department of Defense Trusted Computer 15423 System Evaluation Criteria in Specific Environments" [CSC3] (See: 15424 "first law" under "Courtney's laws".) 15426 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 15427 that or any other document. Instead, use the full proper name of 15428 the document or, in subsequent references, a conventional 15429 abbreviation. (See: Deprecated Usage under "Green Book", Rainbow 15430 Series.) 15432 $ zero-knowledge proof 15433 (I) /cryptography/ A proof-of-possession protocol whereby a system 15434 entity can prove possession of some information to another entity, 15435 without revealing any of that information. (See: proof-of- 15436 possession protocol.) 15438 $ zeroize 15439 1. (I) Synonym for "purge". Usage: Particularly with regard to 15440 erasing keys that are stored in a cryptographic module. 15442 2. (O) Erase electronically stored data by altering the contents 15443 of the data storage so as to prevent the recovery of the data. 15444 [FP140] 15446 $ zombie 15447 (I) /slang/ An Internet host computer that has been 15448 surreptitiously penetrated by an intruder that installed malicious 15449 daemon software to cause the host to operate as an accomplice in 15450 attacking other hosts, particularly in distributed attacks that 15451 attempt denial of service through flooding. 15453 Deprecated Term: It is likely that other cultures use different 15454 metaphors for this concept. Therefore, to avoid international 15455 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 15456 Usage under "Green Book".) 15458 $ zone of control 15459 (O) /EMSEC/ Synonym for "inspectable space". [C4009] (See: 15460 TEMPEST.) 15462 5. Informative References 15464 This Glossary focuses on the Internet Standards Process. Therefore, 15465 this set of informative references emphasizes international, 15466 governmental, and industry standards documents. Some RFCs that are 15467 especially relevant to Internet security are mentioned in Glossary 15468 entries in square brackets (e.g., see "[R1457]" in the entry for 15469 "security label") and are listed here; some other RFCs are mentioned 15470 in parentheses (e.g., see "(RFC 959)" in the entry for "File 15471 Transport Protocol") but are not listed here. 15473 This Glossary does not require any normative references. 15475 [A1523] American National Standards Institute, "American National 15476 Standard Telecomm Glossary", ANSI T1.523-2001. 15478 [A3092] ---, "American National Standard Data Encryption Algorithm", 15479 ANSI X3.92-1981, 30 December 1980. 15481 [A9009] ---, "Financial Institution Message Authentication 15482 (Wholesale)", ANSI X9.9-1986, 15 August 1986. 15484 [A9017] ---, "Financial Institution Key Management (Wholesale)", 15485 X9.17, 4 April 1985. (Defines procedures for manual and 15486 automated management of keying material and uses DES to 15487 provide key management for a variety of operational 15488 environments.) 15490 [A9042] ---, "Public key Cryptography for the Financial Service 15491 Industry: Agreement of Symmetric Keys Using Diffie-Hellman 15492 and MQV Algorithms", X9.42, 29 January 1999. 15494 [A9052] ---, "Triple Data Encryption Algorithm Modes of Operation", 15495 X9.52-1998, ANSI approval 9 November 1998. 15497 [A9062] ---, "Public Key Cryptography for the Financial Services 15498 Industry: The Elliptic Curve Digital Signature Algorithm 15499 (ECDSA)", X9.62-1998, ANSI approval 7 January 1999. 15501 [A9063] ---, "---: Key Agreement and Key Transport Using Elliptic 15502 Curve Cryptography", X9.63-2001. 15504 [ACM] Association for Computing Machinery, "Communications of the 15505 ACM", July 1998 issue with: M. Yeung, "Digital 15506 Watermarking"; N. Memom and P. Wong, "Protecting Digital 15507 Media Content"; and S. Craver, B.-L. Yeo, and M. Yeung, 15508 "Technical Trials and Legal Tribulations". 15510 [Ande] Anderson, J., "Computer Security Technology Planning Study", 15511 ESD-TR-73-51, Vols. I and II, USAF Electronics Systems Div., 15512 Bedford, MA, October 1972. (Available as AD-758206 and - 15513 772806, National Technical Information Service, Springfield, 15514 VA.) 15516 [ANSI] American National Standards Institute, "Role Based Access 15517 Control", Secretariat, Information Technology Industry 15518 Council, BSR INCITS 359, DRAFT, 10 November 2003. 15520 [Army] U.S. Army Corps of Engineers, "Electromagnetic Pulse (EMP) 15521 and Tempest Protection for Facilities", EP 1110-3-2, 31 15522 December 1990. 15524 [B1822] Bolt Baranek and Newman Inc., "Appendix H: Interfacing a 15525 Host to a Private Line Interface", in "Specifications for 15526 the Interconnection of a Host and an IMP", BBN Report No. 15527 1822, revised, December 1983. 15529 [B4799] ---, "A History of the Arpanet: The First Decade", BBN 15530 Report No. 4799, April 1981. 15532 [BS7799] British Standards Institution, "Information Security 15533 Management, Part 1: Code of Practice for Information 15534 Security Management", BS 7799-1:1999, 15 May 1999. 15536 ---, ---, "Part 2: Specification for Information Security 15537 Management Systems", BS 7799-2:1999, 15 May 1999. 15539 [Bell] Bell, D. and L. LaPadula, "Secure Computer Systems: 15540 Mathematical Foundations and Model", M74-244, The MITRE 15541 Corporation, Bedford, MA, May 1973. (Available as AD-771543, 15542 National Technical Information Service, Springfield, VA.) 15544 [Biba] K. Biba, "Integrity Considerations for Secure Computer 15545 Systems", ESD-TR-76-372, USAF Electronic Systems Division, 15546 Bedford, MA, April 1977. 15548 [BN89] Brewer, D. and M. Nash, "The Chinese wall security policy", 15549 in "Proceedings of IEEE Symposium on Security and Privacy", 15550 May 1989, pp. 205-214. 15552 [C4009] Committee on National Security Systems (U.S. Government), 15553 "National Information Assurance (IA) Glossary", CNSS 15554 Instruction No. 4009, revised May 2003. 15556 [CCIB] Common Criteria Implementation Board, "Common Criteria for 15557 Information Technology Security Evaluation, Part 1: 15558 Introduction and General Model", version 2.0, CCIB-98-026, 15559 May 1998. 15561 [Chau] D. Chaum, "Untraceable Electronic Mail, Return Addresses, 15562 and Digital Pseudonyms", in "Communications of the ACM", 15563 vol. 24, no. 2, February 1981, pp. 84-88. 15565 [Cheh] Cheheyl, M., Gasser, M., Huff, G., and J. Millen, "Verifying 15566 Security", in "ACM Computing Surveys", vol. 13, no. 3, 15567 September 1981, pp. 279-339. 15569 [Chris] Chrissis, M. et al, 1993. "SW-CMM [Capability Maturity Model 15570 for Software Version", Release 3.0, Software Engineering 15571 Institute, Carnegie Mellon University, August 1996. 15573 [CIPSO] Trusted Systems Interoperability Working Group, "Common IP 15574 Security Option", version 2.3, 9 March 1993. 15576 [Clark] Clark, D. and D. Wilson, "A Comparison of Commercial and 15577 Military computer Security Policies", in "Proceedings of the 15578 IEEE Symposium on Security and Privacy", April 1987, pp. 15579 184-194. 15581 [Cons] NSA, "Consistency Instruction Manual for Development of U.S. 15582 Government Protection Profiles for Use in Basic Robustness 15583 Environments", Release 2.0, 1 March 2004 15585 [CSC1] U.S. DoD Computer Security Center, "Department of Defense 15586 Trusted Computer System Evaluation Criteria", CSC-STD-001- 15587 83, 15 August 1983. (Superseded by [DoD1].) 15589 [CSC2] ---, "Department of Defense Password Management Guideline", 15590 CSC-STD-002-85, 12 April 1985. 15592 [CSC3] ---, "Computer Security Requirements: Guidance for Applying 15593 the Department of Defense Trusted Computer System Evaluation 15594 Criteria in Specific Environments", CSC-STD-003-85, 25 June 15595 1985. 15597 [CSOR] U.S. Department of Commerce, "General Procedures for 15598 Registering Computer Security Objects", National Institute 15599 of Standards Interagency Report 5308, December 1993. 15601 [Daem] Daemen, J. and V. Rijmen, "Rijndael, the advanced encryption 15602 standard", in "Dr. Dobb's Journal", vol. 26, no. 3, March 15603 2001, pp.137-139. 15605 [DC6/9] Director of Central Intelligence, "Physical Security 15606 Standards for Sensitive Compartmented Information 15607 Facilities", DCI Directive 6/9, 18 November 2002. 15609 [Denn] Denning, D., "A Lattice Model of Secure Information Flow", 15610 in "Communications of the ACM", vol. 19, no. 5, May 1976, 15611 pp. 236-243. 15613 [Denns] Denning, D. and P. Denning, "Data Security", in "ACM 15614 Computing Surveys", vol. 11, no. 3, September 1979, pp. 227- 15615 249. 15617 [DH76] Diffie, W. and M. Hellman, "New Directions in Cryptography", 15618 in "IEEE Transactions on Information Theory", vol. IT-22, 15619 no. 6, November 1976, pp. 644-654. 15621 [DoD1] U.S. DoD, "Department of Defense Trusted Computer System 15622 Evaluation Criteria", DoD 5200.28-STD, 26 December 1985. 15623 (Supersedes [CSC1].) (Superseded by DoD Directive 8500.1.) 15625 [DoD4] ---, "NSA Key Recovery Assessment Criteria", 8 June 1998. 15627 [DoD5] ---, Directive 5200.1, "DoD Information Security Program", 15628 13 December 1996. 15630 [DoD6] ---, "DoD Architecture Framework", Version 1, 30 August 15631 2003. 15633 [DoD7] ---, "X.509 Certificate Policy for the United States 15634 Department of Defense", version 7, 18 December 2002. 15635 (Superseded by [DoD9].) 15637 [DoD9] ---, "X.509 Certificate Policy for the United States 15638 Department of Defense", version 9, 9 February 2005. 15640 [DSG] American Bar Association, "Digital Signature Guidelines: 15641 Legal Infrastructure for Certification Authorities and 15642 Secure Electronic Commerce", Chicago, IL, 1 August 1996. 15643 (See: [PAG].) 15645 [ElGa] El Gamal, T., "A Public-Key Cryptosystem and a Signature 15646 Scheme Based on Discrete Logarithms", in "IEEE Transactions 15647 on Information Theory", vol. IT-31, no. 4, 1985, pp. 469- 15648 472. 15650 [EMV1] Europay International S.A., MasterCard International 15651 Incorporated, and Visa International Service Association, 15652 "EMV '96 Integrated Circuit Card Specification for Payment 15653 Systems", version 3.1.1, 31 May 1998. 15655 [EMV2] ---, "EMV '96 Integrated Circuit Card Terminal Specification 15656 for Payment Systems", version 3.1.1, 31 May 1998. 15658 [EMV3] ---, "EMV '96 Integrated Circuit Card Application 15659 Specification for Payment Systems", version 3.1.1, 31 May 15660 1998. 15662 [F1037] U.S. General Services Administration, "Glossary of 15663 Telecommunications Terms", FED STD 1037C, 7 August 1996. 15665 [For94] Ford, W., "Computer Communications Security: Principles, 15666 Standard Protocols and Techniques", ISBN 0-13-799453-2, 15667 1994. 15669 [For97] --- and M. Baum, "Secure Electronic Commerce: Building the 15670 Infrastructure for Digital Signatures and Encryption", ISBN 15671 0-13-476342-4, 1994. 15673 [FP001] U.S. Department of Commerce, "Code for Information 15674 Interchange", Federal Information Processing Standards 15675 Publication (FIPS PUB) 1, 1 November 1968. 15677 [FP031] ---, "Guidelines for Automatic Data Processing Physical 15678 Security and Risk Management", FIPS PUB 31, June 1974. 15680 [FP039] ---, "Glossary for Computer Systems Security", FIPS PUB 39, 15681 15 February 1976. 15683 [FP041] ---, "Computer Security Guidelines for Implementing the 15684 Privacy Act of 1974", FIPS PUB 41, 30 May 1975. 15686 [FP046] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25 15687 October 1999. 15689 [FP074] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25 15690 October 1999. 15692 [FP081] ---, "DES Modes of Operation", FIPS PUB 81, 2 December 1980. 15694 [FP087] ---, "Guidelines for ADP Contingency Planning", FIPS PUB 87, 15695 27 March 1981. 15697 [FP102] ---, "Guideline for Computer Security Certification and 15698 Accreditation", FIPS PUB 102, 27 September 1983. 15700 [FP113] ---, "Computer Data Authentication", FIPS PUB 113, 30 May 15701 1985. 15703 [FP140] ---, "Security Requirements for Cryptographic Modules", FIPS 15704 PUB 140-2, 25 May 2001; with change notice 4, 3 December 15705 2002. 15707 [FP151] ---, "Portable Operating System Interface (POSIX) -- System 15708 Application Program Interface [C Language]", FIPS PUB 151-2, 15709 12 May 1993 15711 [FP180] ---, "Secure Hash Standard", FIPS PUB 180-2, August 2000; 15712 with change notice 1, 25 February 2004. 15714 [FP185] ---, "Escrowed Encryption Standard", FIPS PUB 185, 9 15715 February 1994. 15717 [FP186] ---, "Digital Signature Standard (DSS)", FIPS PUB 186-2, 27 15718 June 2000; with change notice 1, 5 October 2001. 15720 [FP188] ---, "Standard Security Label for Information Transfer", 15721 FIPS PUB 188, 6 September 1994. 15723 [FP191] ---, "Guideline for the Analysis of Local Area Network 15724 Security", FIPS PUB 191, 9 November 1994. 15726 [FP197] ---, "Advanced Encryption Standard", FIPS PUB 197, 26 15727 November 2001. 15729 [FP199] ---, "Standards for Security Categorization of Federal 15730 Information and Information Systems ", FIPS PUB 199, 15731 December 2003. 15733 [FPKI] ---, "Public Key Infrastructure (PKI) Technical 15734 Specifications: Part A -- Technical Concept of Operations", 15735 NIST, 4 September 1998. 15737 [Gass] Gasser, M., "Building a Secure Computer System", Van 15738 Nostrand Reinhold Company, New York, 1988, ISBN 0-442-23022- 15739 2. 15741 [Gray] Gray, J. and A. Reuter, "Transaction Processing: Concepts 15742 and Techniques", Morgan Kaufmann Publishers, Inc., 1993. 15744 [Hafn] Hafner, K. and M. Lyon, "Where Wizards Stay Up Late: The 15745 Origins of the Internet", Simon & Schuster, New York, 1996. 15747 [Huff] Huff, G., "Trusted Computer Systems -- Glossary", MTR 8201, 15748 The MITRE Corporation, March 1981. 15750 [I3166] International Standards Organization, "Codes for the 15751 Representation of Names of Countries and Their Subdivisions, 15752 Part 1: Country Codes", ISO 3166-1:1997. 15754 ---, ---, "Part 2: Country Subdivision Codes", ISO/DIS 3166- 15755 2. 15757 ---, ---, "Part 3: Codes for Formerly Used Names of 15758 Countries", ISO/DIS 3166-3. 15760 [I7498-1] ---, "Information Processing Systems -- Open Systems 15761 Interconnection Reference Model, [Part 1:] Basic Reference 15762 Model", ISO/IEC 7498-1. (Equivalent to ITU-T Recommendation 15763 X.200.) 15765 [I7498-2] ---, ---, "Part 2: Security Architecture", ISO/IEC 7499-2. 15767 [I7498-4] ---, ---, "Part 4: Management Framework", ISO/IEC 7498-4. 15769 [I7812] ---, "Identification cards -- Identification of Issuers, 15770 Part 1: Numbering System", ISO/IEC 7812-1:1993 15772 ---, ---, "Part 2: Application and Registration Procedures", 15773 ISO/IEC 7812-2:1993. 15775 [I8073] ---, "Information Processing Systems -- Open Systems 15776 Interconnection, Transport Protocol Specification", ISO IS 15777 8073. 15779 [I8327] ---, ---, "Session Protocol Specification", ISO IS 8327. 15781 [I8473] ---, ---, "Protocol for Providing the Connectionless Network 15782 Service", ISO IS 8473. 15784 [I8802-2] ---, "Information Processing Systems -- Local Area 15785 Networks, Part 2: Logical Link Control", ISO IS 8802-2. 15786 (Equivalent to IEEE 802.2.) 15788 [I8802-3] ---, ---, "Part 3: Carrier Sense Multiple Access with 15789 Collision Detection (CSMA/CD) Access Method and Physical 15790 Layer Specifications", ISO IS 8802-3. (Equivalent to IEEE 15791 802.3.) 15793 [I8823] ---, "Information Processing Systems -- Open Systems 15794 Interconnection -- Connection-Oriented Presentation Protocol 15795 Specification", ISO IS 8823. 15797 [I9945] "Portable Operating System Interface for Computer 15798 Environments", ISO/IEC 9945-1: 1990. 15800 [IATF] NSA, "Information Assurance Technical Framework", Release 3, 15801 NSA, September 2000. (See: IATF.) 15803 [IDSAN] ---, "Intrusion Detection System Analyzer Protection 15804 Profile", version 1.1, NSA, 10 December 2001. 15806 [IDSSC] ---, "Intrusion Detection System Scanner Protection 15807 Profile", version 1.1, NSA, 10 December 2001. 15809 [IDSSE] ---, "Intrusion Detection System Sensor Protection Profile", 15810 version 1.1, NSA, 10 December 2001. 15812 [IDSSY] ---, "Intrusion Detection System", version 1.4, NSA, 4 15813 February 2002. 15815 [Ioan] Ioannidis, J. and M. Blaze, "The Architecture and 15816 Implementation of Network Layer Security in UNIX", in "UNIX 15817 Security IV Symposium", October 1993, pp. 29-39. 15819 [ITSEC] "Information Technology Security Evaluation Criteria 15820 (ITSEC): Harmonised Criteria of France, Germany, the 15821 Netherlands, and the United Kingdom", version 1.2, U.K. 15822 Department of Trade and Industry, June 1991. 15824 [JCSP1] U.S. DoD, "Dictionary of Military and Associated Terms", 15825 Joint Chiefs of Staff, JCS Pub. 1, 1 April 1984. 15827 [John] Johnson, N. and S. Jajodia, "Exploring Steganography; Seeing 15828 the Unseen", in "IEEE Computer", February 1998, pp. 26-34. 15830 [Kahn] Kahn, D., "The Codebreakers: The Story of Secret Writing", 15831 The Macmillan Company, New York, 1967. 15833 [Knut] Knuth, D., Chapter 3 ("Random Numbers") of Volume 2 15834 ("Seminumerical Algorithms") of "The Art of Computer 15835 Programming", Addison-Wesley, Reading, MA, 1969. 15837 [Kuhn] Kuhn, M. and R. Anderson, "Soft Tempest: Hidden Data 15838 Transmission Using Electromagnetic Emanations", in David 15839 Aucsmith, ed., "Information Hiding, Second International 15840 Workshop, IH'98", Portland, Oregon, USA, 15-17 April 1998, 15841 LNCS 1525, Springer-Verlag, ISBN 3-540-65386-4, pp. 124-142. 15843 [Land] Landwehr, C., "Formal Models for Computer Security", in "ACM 15844 Computing Surveys", vol. 13, no. 3, September 1981, pp. 247- 15845 278. 15847 [Larm] Larmouth, J., "ASN.1 Complete", Open System Solutions, 1999 15848 (a freeware book). 15850 [M0404] U.S. Office of Management and Budget, "E-Authentication 15851 Guidance for Federal Agencies", Memorandum M-04-04, 16 15852 December 2003. 15854 [Mene] Menezes, A. et al, "Some Key Agreement Protocols Providing 15855 Implicit Authentication", in "The 2nd Workshop on Selected 15856 Areas in Cryptography", 1995. 15858 [Moor] Moore, A. et al, "Attack Modeling for Information Security 15859 and Survivability", Carnegie-Mellon University / Software 15860 Engineering Institute, CMU/SEI-2001-TN-001, March 2001. 15862 [Murr] Murray, W., "Courtney's Laws of Security", in "Infosecurity 15863 News", March/April 1993, p. 65. 15865 [N4001] National Security Telecommunications and Information System 15866 Security Committee, "Controlled Cryptographic Items", 15867 NSTISSI No. 4001, 25 March 1985. 15869 [N4006] ---, "Controlled Cryptographic Items", NSTISSI No. 4006, 2 15870 December 1991. 15872 [N7003] ---, "Protective Distribution Systems", NSTISSI No. 7003, 13 15873 December 1996. 15875 [NCS01] National Computer Security Center, "A Guide to Understanding 15876 Audit in Trusted Systems", NCSC-TG-001, 1 June 1988. (See: 15878 Rainbow Series.) 15880 [NCS03] ---, "Information System Security Policy Guideline", I942- 15881 TR-003, version 1, July 1994. (See: Rainbow Series.) 15883 [NCS04] ---, "Glossary of Computer Security Terms", NCSC-TG-004, 15884 version 1, 21 October 1988. (See: Rainbow Series.) 15886 [NCS05] ---, "Trusted Network Interpretation of the Trusted Computer 15887 System Evaluation Criteria", NCSC-TG-005, version 1, 31 July 15888 1987. (See: Rainbow Series.) 15890 [NCS25] ---, "A Guide to Understanding Data Remanence in Automated 15891 Information Systems", NCSC-TG-025, version 2, September 15892 1991. (See: Rainbow Series.) 15894 [NCS25] ---, "A Guide to Understanding Data Remanence in Automated 15895 Information Systems", NCSC-TG-025, version 2, September 15896 1991. (See: Rainbow Series.) 15898 [NRC91] National Research Council, "Computers At Risk: Safe 15899 Computing in the Information Age", National Academy Press, 15900 1991. 15902 [NRC98] Schneider, F., ed., "Trust in Cyberspace", National Research 15903 Council, National Academy of Sciences, 1998. 15905 [Padl] Padlipsky, M., "The Elements of Networking Style", 1985, 15906 ISBN 0-13-268111-0. 15908 [PAG] American Bar Association, "PKI Assessment Guidelines", 15909 version 1.0, 10 May 2002. (See: [DSG].) 15911 [Park] Parker, D., "Computer Security Management", ISBN 0-8359- 15912 0905-0, 1981 15914 [Perr] Perrine, T. et al, "An Overview of the Kernelized Secure 15915 Operating System (KSOS)", in "Proceedings of the 7th DoD/NBS 15916 Computer Security Conference", 24-26 September 1984. 15918 [PGP] Garfinkel, S.. "PGP: Pretty Good Privacy", O'Reilly & 15919 Associates, Inc., Sebastopol, CA, 1995. 15921 [PKCS] Kaliski Jr., B., "An Overview of the PKCS Standards", RSA 15922 Data Security, Inc., 3 June 1991. 15924 [PKC05] RSA Laboratories, "PKCS #5: Password-Based Encryption 15925 Standard ", version 1.5, 1 November 1993. (See: [R2898].) 15927 [PKC07] ---, "PKCS #7: Cryptographic Message Syntax Standard", 15928 version 1.5, 1 November 1993. 15930 [PKC10] ---, "PKCS #10: Certification Request Syntax Standard", 15931 version 1.0, 1 November 1993. 15933 [PKC11] ---, "PKCS #11: Cryptographic Token Interface Standard", 15934 version 1.0, 28 April 1995. 15936 [PKC12] ---, "PKCS #12: Personal Information Exchange Syntax", 15937 version 1.0, 24 June 1995. 15939 [R1108] Kent, S., "U.S. Department of Defense Security Options for 15940 the Internet Protocol", RFC 1108, November 1991. 15942 [R1135] Reynolds, J., "The Helminthiasis of the Internet", RFC 1135, 15943 December 1989 15945 [R1208] Jacobsen, O. and D. Lynch, "A Glossary of Networking Terms", 15946 RFC 1208, March 1991. 15948 [R1281] Pethia, R., Crocker, S., and B. Fraser, "Guidelines for 15949 Secure Operation of the Internet", RFC 1281, November 1991. 15951 [R1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, 15952 April 1992. 15954 [R1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, 15955 April 1992. 15957 [R1321] ---, "The MD5 Message-Digest Algorithm", RFC 1321, April 15958 1992. 15960 [R1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 15961 RFC 1334, October 1992. 15963 [R1413] St. Johns, M., "Identification Protocol", RFC 1413, February 15964 1993. 15966 [R1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail, 15967 Part I: Message Encryption and Authentication Procedures", 15968 RFC 1421, February 1993. 15970 [R1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail, 15971 Part II: Certificate-Based Key Management", RFC 1422, 15972 February 1993. 15974 [R1455] Eastlake 3rd, D., "Physical Link Security Type of Service", 15975 RFC 1455, May 1993. 15977 [R1457] Housley, R., "Security Label Framework for the Internet", 15978 RFC 1457, May 1993. 15980 [R1492] Finseth, C., "An Access Control Protocol, Sometimes Called 15981 TACACS", RFC 1492, July 1993. 15983 [R1507] Kaufman, C., "DASS: Distributed Authentication Security 15984 Service", RFC 1507, September 1993. 15986 [R1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication 15987 Service (V5)", RFC 1510, September 1993. (Superseded by RFC 15988 4120.) 15990 [R1731] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, 15991 December 1994. 15993 [R1734] ---, "POP3 AUTHentication Command", RFC 1734, Dec, 1994. 15995 [R1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness 15996 Recommendations for Security", RFC 1750, December 1994. 15997 (Superseded by RFC 4086.) 15999 [R1760] Haller, N., "The S/KEY One-Time Password System", RFC 1760, 16000 February 1995. 16002 [R1824] Danisch, H., "The Exponential Security System TESS: An 16003 Identity-Based Cryptographic Protocol for Authenticated Key- 16004 Exchange (E.I.S.S.-Report 1995/4)", RFC 1824, August 1995. 16006 [R1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed 16007 MD5", RFC 1828, August 1995. 16009 [R1829] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC 16010 Transform", RFC 1829, August 1995. 16012 [R1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME 16013 Object Security Services", RFC 1848, October 1995. 16015 [R1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES 16016 Transform", RFC 1851, September 1995. 16018 [R1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. 16019 Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. 16021 [R1938] Haller, N. and C. Metz, "A One-Time Password System", RFC 16022 1938, May 1996. (Superseded by RFC 2289.) 16024 [R1958] Carpenter, B., "Architectural Principles of the Internet", 16025 RFC 1958, June 1996. 16027 [R1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, 16028 August 1996. 16030 [R1994] Simpson, W., "PPP Challenge Handshake Authentication 16031 Protocol (CHAP)", RFC 1994, August 1996. 16033 [R2078] Linn, J., "Generic Security Service Application Program 16034 Interface, Version 2", RFC 2078, January 1997. (Superseded 16035 by RFC 2743.) 16037 [R2084] Bossert, G., Cooper, S., and W. Drummond, "Considerations 16038 for Web Transaction Security", RFC 2084, January 1997. 16040 [R2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 16041 Hashing for Message Authentication", RFC 2104, February 16042 1997. 16044 [R2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 16045 May 1997. 16047 [R2179] Gwinn, A., "Network Security For Trade Shows", RFC 2179, 16048 July 1997. 16050 [R2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 16051 AUTHorize Extension for Simple Challenge/Response", RFC 16052 2195, September 1997. 16054 [R2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 16055 September 1997. 16057 [R2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 16058 SHA-1", RFC 2202, Sep. 1997. 16060 [R2222] Myers, J., "Simple Authentication and Security Layer 16061 (SASL)", RFC 2222, October 1997. 16063 [R2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", 16064 RFC 2246, January 1999. 16066 [R2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax, Version 16067 1.5", RFC 2315, March 1998. 16069 [R2323] Ramos, A., "IETF Identification and Security Guidelines", 16070 RFC 2323, 1 April 1998. (Intended for humorous entertainment 16071 -- "please laugh loud and hard" -- and does not contain 16072 serious security information.) 16074 [R2350] Brownlee, N. and E. Guttman, "Expectations for Computer 16075 Security Incident Response", BCP 21, RFC 2350, June 1998. 16077 [R2356] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal 16078 for Mobile IP", RFC 2356, June 1998. 16080 [R2401] Kent, S. and R. Atkinson, "Security Architecture for the 16081 Internet Protocol", RFC 2401, November 1998. 16083 [R2402] ---, "IP Authentication Header", RFC 2402, November 1998. 16085 [R2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP 16086 and AH", RFC 2403, November 1998. 16088 [R2404] ---, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, 16089 November 1998. 16091 [R2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 16092 Algorithm With Explicit IV", RFC 2405, November 1998. 16094 [R2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 16095 (ESP)", RFC 2406, November 1998. 16097 [R2407] Piper, D. "The Internet IP Security Domain of Interpretation 16098 for ISAKMP", RFC 2407, November 1998. 16100 [R2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 16101 "Internet Security Association and Key Management Protocol 16102 (ISAKMP)", RFC 2408, November 1998. 16104 [R2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 16105 (IKE)", RFC 2409, November 1998. 16107 [R2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 16108 Its Use With IPsec", RFC 2410, November 1998. 16110 [R2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 16111 2412, November 1998. 16113 [R2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 16114 Algorithms", RFC 2451, November 1998. 16116 [R2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security 16117 Handbook", RFC 2504, February 1999. 16119 [R2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 16120 Infrastructure Certificate Management Protocols", RFC 2510, 16121 March 1999. 16123 [R2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 16124 Adams, "X.509 Internet Public Key Infrastructure Online 16125 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 16127 [R2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption 16128 Algorithm", RFC 2612, June 1999. 16130 [R2628] Smyslov, V., "Simple Cryptographic Program Interface (Crypto 16131 API)", RFC 2628, June 1999. 16133 [R2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 16134 2631, June 1999. 16136 [R2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 16137 2634, June 1999. 16139 [R2635] Hambridge, S. and A. Lunde, "DON'T SPEW: A Set of Guidelines 16140 for Mass Unsolicited Mailings and Postings", RFC 2635, June 16141 1999. 16143 [R2660] Rescorla, E. and A. Schiffman, "The Secure HyperText 16144 Transfer Protocol", RFC 2660, August 1999. 16146 [R2773] Housley, R., Yee, P., and W. Nace, "Encryption using KEA and 16147 SKIPJACK", RFC 2773, February 2000. 16149 [R2801] Burdett, D., "Internet Open Trading Protocol - IOTP, Version 16150 1.0", RFC 2801, April 2000. 16152 [R2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 16153 Defeating Denial of Service Attacks which employ IP Source 16154 Address Spoofing", BCP 38, RFC 2827, May 2000. 16156 [R2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 16157 Authentication Dial In User Service (RADIUS)", RFC 2865, 16158 June 2000. 16160 [R2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 16161 Specification, Version 2.0", RFC 2898, September 2000. (See: 16162 [PKC05].) 16164 [R3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 16165 "Policy Core Information Model -- Version 1 Specification", 16166 RFC 3060, February 2001. 16168 [R3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 16169 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 16170 J., and S. Waldbusser, "Terminology for Policy-Based 16171 Management", RFC 3198, November 2001. 16173 [R3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 16174 X.509 Public Key Infrastructure Certificate and Certificate 16175 Revocation List (CRL) Profile", RFC 3280, April 2002. 16177 [R3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 16178 "Introduction and Applicability Statements for Internet- 16179 Standard Management Framework", RFC 3410, December 2002. 16181 [R3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 16182 (USM) for version 3 of the Simple Network Management 16183 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 16185 [R3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "Group 16186 Domain of Interpretation", RFC 3547, July 2003. 16188 [R3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text 16189 on Security Considerations", RFC 3552, July 2003. 16191 [R3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, 16192 "Internet X.509 Public Key Infrastructure Certificate Policy 16193 and Certification Practices Framework", RFC 3647, November 16194 2003. 16196 [R3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 16197 Public Key Infrastructure: Qualified Certificates Profile", 16198 RFC 3739, March 2004. 16200 [R3740] Hardjono, T. and B. Weis, "The Multicast Group Security 16201 Architecture", RFC 3740, March 2004. 16203 [R3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 16204 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 16205 3748, June 2004. 16207 [R3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 16208 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 16209 April 2004. 16211 [R3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. 16212 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 16213 Proxy Certificate Profile", RFC 3820, June 2004. 16215 [R3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 16216 (S/MIME) Version 3.1 Message Specification", RFC 3851, July 16217 2004. 16219 [R3871] Jones, G., "Operational Security Requirements for Large 16220 Internet Service Provider (ISP) IP Network Infrastructure", 16221 RFC 3871, September 2004. 16223 [R4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 16224 Rose, "DNS Security Introduction and Requirements", RFC 16225 4033, March 2005. 16227 [R4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 16228 Rose, "Resource Records for the DNS Security Extensions", 16229 RFC 4034, March 2005. 16231 [R4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 16232 Rose, "Protocol Modifications for the DNS Security 16233 Extensions", RFC 4035, March 2005. 16235 [R4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 16236 Nicholas, "Internet X.509 Public Key Infrastructure: 16237 Certification Path Building", RFC 4158, September 2005. 16239 [Raym] Raymond, E., ed., "The On-Line Hacker Jargon File", version 16240 4.0.0, 24 July 1996. (See: http://www.tuxedo.org/jargon/ for 16241 the latest version. Also, "The New Hacker's Dictionary", 2nd 16242 edition, MIT Press, September 1993, ISBN 0-262-18154-1.) 16244 [Roge] Rogers, H., "An Overview of the Caneware Program", in 16245 "Proceedings of the 10th National Computer Security 16246 Conference", NIST and NCSC, September 1987. 16248 [RSCG] NSA, "Router Security Configuration Guide: Principles and 16249 Guidance for Secure Configuration of IP Routers, with 16250 Detailed Instructions for Cisco Systems Routers", version 16251 1.0g, C4-054R-00, 20 April 2001, available at 16252 http://www.nsa.gov. 16254 [Russ] Russell, D. et al, Chapter 10 ("TEMPEST") of "Computer 16255 Security Basics", ISBN 0-937175-71-4, 1991. 16257 [SAML] Organization for the Advancement of Structured Information 16258 Standards (OASIS), "Assertions and Protocol for the OASIS 16259 Security Assertion Markup Language (SAML)", version 1.1, 2 16260 September 2003. 16262 [Sand] Sandhu, R. et al, "Role-Based Access Control Models", in 16263 "IEEE Computer", vol. 29, no.2, February 1996, pp. 38-47. 16265 [Schn] Schneier, B., "Applied Cryptography Second Edition", John 16266 Wiley & Sons, Inc., New York, 1996. 16268 [SDNS3] U.S. DoD, NSA, "Secure Data Network Systems, Security 16269 Protocol 3 (SP3)", document SDN.301, Revision 1.5, 15 May 16270 1989. 16272 [SDNS4] ---, ---, "Security Protocol 4 (SP4)", document SDN.401, 16273 Revision 1.2, 12 July 1988. 16275 [SDNS7] ---, ---, "Secure data Network System, Message Security 16276 Protocol (MSP)", SDN.701, Revision 4.0, 7 June 1996, with 16277 "Corrections to Message Security Protocol, SDN.701, Rev 4.0, 16278 96-06-07", 30 Aug, 1996. 16280 [SET1] MasterCard and Visa, "SET Secure Electronic Transaction 16281 Specification, Book 1: Business Description", version 1.0, 16282 31 May 1997. 16284 [SET2] ---, "SET Secure Electronic Transaction Specification, Book 16285 2: Programmer's Guide", version 1.0, 31 May 1997. 16287 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 16288 Mechanism for Internet", in "Proceedings of the 1996 16289 Symposium on Network and Distributed Systems Security". 16291 [SKIP] "SKIPJACK and KEA Algorithm Specifications", version 2.0, 22 16292 May 1998, and "Clarification to the SKIPJACK Algorithm 16293 Specification", 9 May 2002 (available from NIST Computer 16294 Security Resource Center). 16296 [SP12] NIST, "An Introduction to Computer Security: The NIST 16297 Handbook", Special Publication 800-12. 16299 [SP14] Swanson, M. et al (NIST), "Generally Accepted Principles and 16300 Practices for Security Information Technology Systems", --- 16301 800-14, September 1996. 16303 [SP15] Burr, W. et al (NIST), "Minimum Interoperability 16304 Specification for PKI Components (MISPC), Version 1", --- 16305 800-15, September 1997. 16307 [SP22] Rukhin, A. et al (NIST), "A Statistical Test Suite for 16308 Random and Pseudorandom Number Generators for Cryptographic 16309 Applications", --- 800-15, 15 May 2001. 16311 [SP27] Stoneburner, G. et al (NIST), "Engineering Principles for 16312 Information Technology Security (A Baseline for Achieving 16313 Security)", --- 800-27 Rev A, June 2004. 16315 [SP28] Jansen, W. (NIST), "Guidelines on Active Content and Mobile 16316 Code", --- 800-28, October 2001. 16318 [SP30] Stoneburner, G. et al (NIST), "Risk Management Guide for 16319 Information Technology Systems", --- 800-30, October 2001. 16321 [SP31] Bace, R. et al (NIST), "Intrusion Detection Systems", --- 16322 800-31. 16324 [SP32] Kuhn, D. (NIST), "Introduction to Public Key Technology and 16325 the Federal PKI Infrastructure ", --- 800-32, 26 February 16326 2001. 16328 [SP33] Stoneburner, G. (NIST), "Underlying Technical Models for 16329 Information Technology Security", --- 800-33, December 2001. 16331 [SP37] Ross, R. et al (NIST), "Guide for the Security Certification 16332 and Accreditation of Federal Information Systems", --- 800- 16333 37, May 2004 16335 [SP41] Wack. J. et al (NIST), "Guidelines on Firewalls and Firewall 16336 Policy", --- 800-41, January 2002. 16338 [SP42] ---, "Guideline on Network Security Testing", --- 800-42, 16339 October 2003. 16341 [SP56] NIST, "Recommendations on Key Establishment Schemes", Draft 16342 2.0, --- 800-63, January 2003. 16344 [SP57] ---, "Recommendation for Key Management", Part 1 "General 16345 Guideline" and Part 2 "Best Practices for Key Management 16346 Organization", --- 800-57, DRAFT, January 2003. 16348 [SP61] Grance, T. et al (NIST), "Computer Security Incident 16349 Handling Guide", --- 800-57, January 2003. 16351 [SP63] Burr, W. et al (NIST), "Electronic Authentication 16352 Guideline", --- 800-63, June 2004 16354 [SP67] Barker, W. (NIST), "Recommendation for the Triple Data 16355 Encryption Algorithm (TDEA) Block Cipher", --- 800-67, May 16356 2004 16358 [Stal] Stallings, W., "Local Networks", 1987, ISBN 0-02-415520-9. 16360 [Stei] Steiner, J. et al, "Kerberos: An Authentication Service for 16361 Open Network Systems", in "Usenix Conference Proceedings", 16362 February 1988. 16364 [Weis] Weissman, C., "Blacker: Security for the DDN: Examples of A1 16365 Security Engineering Trades", in "Symposium on Security and 16366 Privacy", IEEE Computer Society Press, May 1992, pp. 286- 16367 292. 16369 [X400] International Telecommunications Union -- Telecommunication 16370 Standardization Sector (formerly "CCITT"), Recommendation 16371 X.400, "Message Handling Services: Message Handling System 16372 and Service Overview". 16374 [X419] ---, "Message Handling Systems: Protocol Specifications", 16375 ITU-T Recommendation X.419. (Equivalent to ISO 10021-6). 16377 [X420] ---, ---: "Interpersonal Messaging System", ITU-T 16378 Recommendation X.420. (Equivalent to ISO 10021-7.). 16380 [X500] ---, Recommendation X.500, "Information Technology -- Open 16381 Systems Interconnection -- The Directory: Overview of 16382 Concepts, Models, and Services". (Equivalent to ISO 9594-1.) 16384 [X501] ---, Recommendation X.501, ---: "Models". 16386 [X509] ---, Recommendation X.509, ---: "Authentication Framework", 16387 COM 7-250-E Revision 1, 23 February 2001. (Equivalent to ISO 16388 9594-8.) 16390 [X519] ---, Recommendation X.519, ---: "Protocol Specifications". 16392 [X520] ---, Recommendation X.520, ---: "Selected Attribute Types". 16394 [X680] ---, Recommendation X.680, "Information Technology -- 16395 Abstract Syntax Notation One (ASN.1) -- Specification of 16396 Basic Notation", 15 November 1994. (Equivalent to ISO/IEC 16397 8824-1.) 16399 [X690] ---, Recommendation X.690, "Information Technology -- ASN.1 16400 Encoding Rules -- Specification of Basic Encoding Rules 16401 (BER), Canonical Encoding Rules (CER) and Distinguished 16402 Encoding Rules (DER)", 15 November 1994. (Equivalent to 16403 ISO/IEC 8825-1.) 16405 6. Security Considerations and IANA Considerations 16407 This document mainly defines security terms and recommends how to use 16408 them. It also provides limited tutorial information about security 16409 aspects of Internet protocols, but it does not describe in detail the 16410 vulnerabilities of, or threats to, specific protocols and does not 16411 definitively describe mechanisms that protect specific protocols. 16413 This document has no actions for IANA. 16415 7. Acknowledgments 16417 Funding for the RFC Editor function is currently provided by the 16418 Internet Society. 16420 George Huff had a good idea! [Huff] 16422 8. Author's Address 16424 Please address all comments to: 16426 Robert W. Shirey BBN Technologies 16427 Email addresses: Suite 400, Mail Stop 30/6C1 16428 Current - rshirey@bbn.com 1300 Seventeenth Street North 16429 Long-term - rwshirey@uwalumni.com Arlington, VA 22209-3801 USA 16431 9. Full Copyright Statement 16433 Copyright (C) The Internet Society (2005). This document is subject 16434 to the rights, licenses and restrictions contained in BCP 78, and 16435 except as set forth therein, the authors retain all their rights. 16437 This document and the information contained herein are provided on an 16438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE IS SPONSORED 16439 BY, THE INTERNET SOCIETY, AND THE INTERNET ENGINEERING TASK FORCE 16440 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 16441 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 16442 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 16443 OR FITNESS FOR A PARTICULAR PURPOSE. 16445 Expiration Date: 10 May 2006.