idnits 2.17.00 (12 Aug 2021) /tmp/idnits60337/draft-shirey-secgloss-v2-01.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 3667, Section 5.1 on line 13. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 16221), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 149: '... the SHOULD NOTs -- so that readers ...' RFC 2119 keyword, line 166: '... that are RECOMMENDED for use in ...' RFC 2119 keyword, line 194: '... - "I" for a RECOMMENDED term or d...' RFC 2119 keyword, line 195: '... - "N" if RECOMMENDED but not of...' RFC 2119 keyword, line 199: '...tion that is deprecated and SHOULD NOT...' (222 more instances...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2828, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2540 has weird spacing: '...ificate or...' == Line 11366 has weird spacing: '...dentity v ...' == Line 12873 has weird spacing: '...ng over eithe...' == Line 13836 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 (9 March 2005) is 6281 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 926, but not defined == Missing Reference: 'ABA96' is mentioned on line 2558, but not defined == Missing Reference: 'It' is mentioned on line 3426, but not defined == Missing Reference: 'DGSA' is mentioned on line 11879, but not defined == Missing Reference: 'CORBA' is mentioned on line 4906, but not defined == Missing Reference: 'RFC 2323' is mentioned on line 7075, but not defined == Missing Reference: 'SP-28' is mentioned on line 8638, but not defined == Missing Reference: 'NS4009' is mentioned on line 8914, but not defined == Missing Reference: 'CSC001' is mentioned on line 14262, but not defined == Missing Reference: 'I7498-2' is mentioned on line 9404, but not defined == Missing Reference: 'IS7498-2' is mentioned on line 9418, but not defined == Missing Reference: 'IS9945-1' is mentioned on line 10179, but not defined == Missing Reference: 'IS7812' is mentioned on line 10256, but not defined == Missing Reference: 'C4008' is mentioned on line 10449, but not defined == Missing Reference: 'EU-ESDIR' is mentioned on line 10801, but not defined == Missing Reference: 'RSA78' is mentioned on line 11284, but not defined == Missing Reference: 'Constraints' is mentioned on line 11369, but not defined == Missing Reference: 'I7498-4' is mentioned on line 12163, but not defined == Missing Reference: 'R3776' is mentioned on line 13114, but not defined == Missing Reference: 'DoDAF1' is mentioned on line 13324, but not defined == Missing Reference: 'N4009' is mentioned on line 13521, but not defined == Missing Reference: 'FIPS31' is mentioned on line 13643, but not defined == Missing Reference: 'CA' is mentioned on line 14128, but not defined == Missing Reference: 'NIST' is mentioned on line 14472, but not defined == Missing Reference: 'FIPS' is mentioned on line 14473, but not defined == Unused Reference: 'Army' is defined on line 15334, but no explicit reference was found in the text == Unused Reference: 'DoD6' is defined on line 15447, but no explicit reference was found in the text == Unused Reference: 'ElGa' is defined on line 15450, but no explicit reference was found in the text == Unused Reference: 'FP041' is defined on line 15488, but no explicit reference was found in the text == Unused Reference: 'FP191' is defined on line 15528, but no explicit reference was found in the text == Unused Reference: 'I7498' is defined on line 15565, but no explicit reference was found in the text == Unused Reference: 'I7812' is defined on line 15574, but no explicit reference was found in the text == Unused Reference: 'I9945' is defined on line 15602, but no explicit reference was found in the text == Unused Reference: 'Knut' is defined on line 15638, but no explicit reference was found in the text == Unused Reference: 'N4006' is defined on line 15674, but no explicit reference was found in the text == Unused Reference: 'NCS01' is defined on line 15680, but no explicit reference was found in the text == Unused Reference: 'NCS03' is defined on line 15684, but no explicit reference was found in the text == Unused Reference: 'PKCS' is defined on line 15722, but no explicit reference was found in the text == Unused Reference: 'R1208' is defined on line 15746, but no explicit reference was found in the text == Unused Reference: 'R1750' is defined on line 15795, but no explicit reference was found in the text == Unused Reference: 'R2323' is defined on line 15867, but no explicit reference was found in the text == Unused Reference: 'R2356' is defined on line 15875, but no explicit reference was found in the text == Unused Reference: 'R2801' is defined on line 15953, but no explicit reference was found in the text == Unused Reference: 'R3766' is defined on line 16011, but no explicit reference was found in the text == Unused Reference: 'R3820' is defined on line 16015, but no explicit reference was found in the text == Unused Reference: 'SP27' is defined on line 16099, 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 1510 (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 1734 (Obsoleted by RFC 5034) -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 1938 (Obsoleted by RFC 2289) -- Obsolete informational reference (is this intentional?): RFC 2078 (Obsoleted by RFC 2743) -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 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 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- 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: 13 errors (**), 0 flaws (~~), 55 warnings (==), 29 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: 9 September 2005 9 March 2005 5 Internet Security Glossary, Version 2 6 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 This document may not be modified, and derivative works of it may 16 not be created, except to publish it as an RFC and to translate it 17 into languages other than English. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than a "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html" 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This Glossary provides definitions, abbreviations, and explanations 41 of terminology for information system security. The 288 pages of 42 listings offer recommendations to improve the clarity of Internet 43 Standards documents (ISDs) and to make them more easily understood by 44 international readers. The recommendations follow the principles that 45 ISDs should (a) use the same term or definition whenever the same 46 concept is mentioned; (b) use terms in their plainest, dictionary 47 sense; (c) use terms that are already well-established in open 48 publications; and (d) avoid terms that are proprietary, favor a 49 particular vendor, or create a bias toward a particular technology or 50 mechanism versus other, competing techniques that already exist or 51 might be developed. 53 Table of Contents 55 Section Page 56 ------- ---- 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Format of Entries . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1 Presentation Order . . . . . . . . . . . . . . . . . . . . 4 60 2.2 Capitalization and Abbreviation . . . . . . . . . . . . . 4 61 2.3 Support for Automated Searching . . . . . . . . . . . . . 5 62 2.4 Definition Type and Context . . . . . . . . . . . . . . . 5 63 2.5 Explanatory Notes . . . . . . . . . . . . . . . . . . . . 5 64 2.6 Cross-References . . . . . . . . . . . . . . . . . . . . . 5 65 2.7 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.8 The New Punctuation . . . . . . . . . . . . . . . . . . . 6 67 3. Types of Entries . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1 Type "I": Recommended Definitions of Internet Origin . . . 6 69 3.2 Type "N": Recommended Definitions of Non-Internet Origin . 7 70 3.3 Type "O": Other Terms and Definitions to be Noted . . . . 7 71 3.4 Type "D": Deprecated Terms and Definitions . . . . . . . . 7 72 3.5 Definition Substitutions . . . . . . . . . . . . . . . . . 7 73 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Informative References . . . . . . . . . . . . . . . . . . . . 297 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 315 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 315 77 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 315 78 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 315 80 1. Introduction 82 This Glossary provides an internally consistent and self-contained 83 set of terms, abbreviations, and definitions -- supported by 84 explanations, recommendations, and references -- for terminology that 85 concerns information system security. The intent of this Glossary is 86 to improve the comprehensibility of Internet Standards documents 87 (ISDs) -- i.e., RFCs, Internet-Drafts, and other material produced as 88 part of the Internet Standards Process (RFC 2026) -- and other 89 Internet-related discourse. A few non-security, networking terms are 90 included to make the Glossary self-contained, but more complete 91 glossaries of networking terms are available elsewhere [A1523, F1037, 92 R1208, R1983]. 94 This Glossary supports the goals of the Internet Standards Process: 96 o Clear, Concise, Easily Understood Documentation 98 This Glossary seeks to improve comprehensibility of security- 99 related content of ISDs. That requires wording to be clear and 100 understandable, and requires the set of security-related terms and 101 definitions to be consistent and self-supporting. Also, 102 terminology needs to be uniform across all ISDs; i.e., the same 103 term or definition needs to be used whenever and wherever the same 104 concept is mentioned. Harmonization of existing ISDs need not be 105 done immediately, but it is desirable to correct and standardize 106 terminology when new versions are issued in the normal course of 107 standards development and evolution. 109 o Technical Excellence 111 Just as Internet Standard (STD) protocols should operate 112 effectively, ISDs should use terminology accurately, precisely, 113 and unambiguously to enable standards to be implemented correctly. 115 o Prior Implementation and Testing 117 Just as STD protocols require demonstrated experience and 118 stability before adoption, ISDs need to use well-established 119 language. Using terms in their plainest, dictionary sense (when 120 appropriate) helps to ensure international understanding. ISDs 121 need to avoid using private, made-up terms in place of generally 122 accepted terms from open publications. ISDs need to avoid 123 substituting new definitions that conflict with established ones. 124 ISDs need to avoid using "cute" synonyms (e.g., see: Green Book), 125 because no matter how popular a nickname may be in one community, 126 it is likely to cause confusion in another. 128 o Openness, Fairness, and Timeliness 130 ISDs need to avoid terms that are proprietary or otherwise favor a 131 particular vendor, or that create a bias toward a particular 132 security technology or mechanism over other, competing techniques 133 that already exist or might be developed in the future. The set of 134 terminology used across the set of ISDs needs to be flexible and 135 adaptable as the state of Internet security art evolves. 137 In support of those goals, this Glossary provides guidance by marking 138 terms and definitions as being either endorsed or deprecated for use 139 in ISDs. The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 140 and "OPTIONAL" are intended to be interpreted the same way as in an 141 Internet Standard (i.e., as specified in RFC 2119). Other glossaries 142 (e.g., [Raym]) list additional terms that deal with Internet security 143 but have not been included in this Glossary because they are not 144 appropriate for ISDs. 146 This Glossary is not an Internet standard, and its guidance 147 represents only the recommendations of this author. However, this 148 Glossary provides reasons for its recommendations -- particularly for 149 the SHOULD NOTs -- so that readers can judge for themselves whether 150 to follow the guidance. 152 2. Format of Entries 154 Section 4 presents Glossary entries in the following manner: 156 2.1 Order of Entries 158 Entries are sorted in lexicographic order, without regard to 159 capitalization. Numeric digits are treated as preceding alphabetic 160 characters; special characters are treated as preceding digits; 161 blanks are treated as preceding all other characters; and a hyphen 162 or slash between two parts of an entry is treated like a blank. 164 If an entry has multiple definitions (e.g., "domain"), they are 165 numbered beginning with "1", and any of those multiple definitions 166 that are RECOMMENDED for use in ISDs are presented before other 167 definitions for that entry. If definitions are closely related 168 (e.g., "threat"), they are denoted by adding letters to a number, 169 such as "1a" and "1b". 171 2.2 Capitalization and Abbreviations 173 Entries that are proper nouns are capitalized (e.g., "Data 174 Encryption Algorithm"), as are other words derived from proper 175 nouns (e.g., "Caesar cipher"). All other entries are not 176 capitalized (e.g., "certification authority"). Each acronym or 177 other abbreviation that appears in this Glossary, either as an 178 entry or in a definition or explanation, is defined in this 179 Glossary, except items of common English usage, such as "e.g.", 180 "etc.", "i.e.", "vol.", "pp.", and "U.S.". 182 2.3 Support for Automated Searching 184 Each entry is preceded by a dollar sign ($) and a space. This 185 makes it possible to find the defining entry for an item "X" by 186 searching for the character string "$ X", without stopping at 187 entries in which "X" is used in explanations. 189 2.4 Definition Type and Context 191 Each entry is preceded by a character -- I, N, O, or D -- enclosed 192 in parentheses, to indicate the type of definition (as is 193 explained further in Section 3): 194 - "I" for a RECOMMENDED term or definition of Internet origin. 195 - "N" if RECOMMENDED but not of Internet origin. 196 - "O" for a term or definition that is NOT recommended for use in 197 ISDs but is something that authors of Internet documents should 198 know about. 199 - "D" for a term or definition that is deprecated and SHOULD NOT 200 be used in Internet documents. 202 If a definition is valid only in a specific context (e.g., 203 "baggage"), that context is shown immediately following the 204 definition type and is enclosed by a pair of slash symbols (/). If 205 the definition is valid only for specific parts of speech, that is 206 shown in the same way (e.g., "archive). 208 2.5 Explanatory Notes 210 Some entries have explanatory text that is introduced by one or 211 more of the following keywords: 212 - Deprecated Abbreviation (e.g., "EE", "H field", "W3") 213 - Deprecated Definition (e.g., "digital certification") 214 - Deprecated Usage (e.g., "authenticate") 215 - Deprecated Term (e.g., "certificate authority") 216 - Pronunciation (e.g., "*-property") 217 - Derivation (e.g., "discretionary access control") 218 - Tutorial (e.g., "accreditation") 219 - Example (e.g., "back door") 220 - Usage (e.g., "access") 222 Explanatory text in this Glossary MAY be reused in other ISDs. 223 However, such text is not intended to authoritatively supersede 224 text of an ISD in which the Glossary entry is already used. 226 2.6 Cross-References 228 Some entries contain a parenthetical remark of the form "(See: 229 X.)", where X is a list one of more related Glossary entries. Some 230 entries contain a remark of the form "(Compare: X)", where X is a 231 list of other entries that either are antonyms or differ in some 232 other manner worth noting. 234 2.7 Trademarks 236 All servicemarks and trademarks that appear in this Glossary are 237 used in an editorial fashion and to the benefit of the mark owner, 238 without any intention of infringement. 240 2.8 The New Punctuation 242 This Glossary uses the "new" or "logical" punctuation style 243 favored by computer programmers, as described by Raymond [Raym]: 244 Programmers use pairs of quotation marks the same way they use 245 pairs of parentheses, i.e., as balanced delimiters. For example, 246 if "Alice sends" is a phrase, and so are "Bill receives" and "Eve 247 listens", then a programmer would write the following sentence: 249 "Alice sends", "Bill receives", and "Eve listens". 251 According to standard American usage, the punctuation in that 252 sentence is incorrect; the continuation commas and the final 253 period should go inside the string quotes, like this: 255 "Alice sends," "Bill receives," and "Eve listens." 257 However, a programmer would not include a character in a literal 258 string if the character did not belong there, because that could 259 cause an error. For example, suppose a sentence in a draft of a 260 tutorial on the vi editing language looked like this: 262 Then delete one line from the file by typing "dd". 264 A book editor following standard usage might change the sentence 265 to look like this: 267 Then delete one line from the file by typing "dd." 269 However, in the vi language, the dot character repeats the last 270 command accepted. So, if a reader entered "dd.", two lines would 271 be deleted instead of one. 273 Similarly, use of standard American punctuation might cause 274 misunderstanding in entries in this Glossary. Thus, the new 275 punctuation is used here, and we recommend it for ISDs. 277 3. Types of Entries 279 Each entry in this Glossary is marked as type I, N, O, or D: 281 3.1 Type "I": Recommended Definitions of Internet Origin 283 The marking "I" indicates two things: 284 - Origin: "I" (as opposed to "N") means either that the Internet 285 Standards Process or Internet community is authoritative for 286 the definition *or* that the term is sufficiently generic that 287 this Glossary can freely state a definition without 288 contradicting a non-Internet authority (e.g., "attack"). 289 - Recommendation: "I" (as opposed to "O") means that the term and 290 definition are RECOMMENDED for use in ISDs. However, some "I" 291 entries may be accompanied by a "Usage" note that states a 292 limitation (e.g., "certification"), and ISDs SHOULD NOT use the 293 defined term outside that limited context. 295 Many "I" entries are proper nouns (e.g., "Internet Protocol") for 296 which the definition is intended only to provide basic 297 information; i.e., the authoritative definition of such terms is 298 found elsewhere. For a proper noun described as an "Internet 299 protocol", please refer to the current edition of "Internet 300 Official Protocol Standards" (Standard 1) for the standardization 301 status of the protocol. 303 3.2 Type "N": Recommended Definitions of Non-Internet Origin 305 The marking "N" indicates two things: 306 - Origin: "N" (as opposed to "I") means that the entry has a non- 307 Internet basis or origin. 308 - Recommendation: "N" (as opposed to "O") means that the term and 309 definition are RECOMMENDED for use in ISDs, if they are needed 310 at all in ISDs. Many of these entries are accompanied by a 311 label that states a context (e.g., "package") or a note that 312 states a limitation (e.g., "data integrity"), and ISDs SHOULD 313 NOT use the defined term outside that context or limit. Some of 314 the contexts are rarely if ever expected to occur in an ISD 315 (e.g., see: baggage). In those cases, the listing exists to 316 make Internet authors aware of the non-Internet usage so that 317 they can avoid conflicts with non-Internet documents. 319 3.3 Type "O": Other Terms and Definitions To Be Noted 321 The marking "O" means that the definition is of non-Internet 322 origin and SHOULD NOT be used in ISDs *except* in cases where the 323 term is specifically identified as non-Internet. 325 For example, an ISD might mention "BCA" (see: brand certification 326 authority) or "baggage" as an example of some concept; in that 327 case, the document should specifically say "SET(trademark) BCA" or 328 "SET(trademark) baggage" and include the definition of the term. 330 3.4 Type "D": Deprecated Terms and Definitions 332 If this Glossary recommends that a term or definition SHOULD NOT 333 be used in ISDs, then the entry is marked as type "D", and a 334 "Deprecated Term", "Deprecated Definition", or "Deprecated Usage" 335 explanatory note is provided. 337 3.5 Definition Substitutions 339 Some terms have a definition published by a non-Internet authority 340 -- government (e.g., "object reuse"), industry (e.g., "Secure Data 341 Exchange"), national authority (e.g., "Data Encryption Standard"), 342 or international body (e.g., "data confidentiality") -- that is 343 suitable for use in ISDs. In those cases, this Glossary marks the 344 definition "N", recommending its use in Internet documents. 346 Other such terms have definitions that are inadequate or 347 inappropriate for ISDs. For example, a definition might be 348 outdated or too narrow, or it might need clarification by 349 substituting more careful wording (e.g., "authentication 350 exchange") or explanations, using other terms that are defined in 351 this Glossary. In those cases, this Glossary marks the entry "O", 352 and provides an "I" or "N" entry that precedes, and is intended to 353 supersede, the "O" entry. 355 In some cases where this Glossary provides a definition to 356 supersede an "O" definition, the substitute is intended to subsume 357 the meaning of the "O" entry and not conflict with it. For the 358 term "security service", for example, the "O" definition deals 359 narrowly with only communication services provided by layers in 360 the OSIRM and is inadequate for the full range of ISD usage, while 361 the new "I" definition provided by this Glossary can be used in 362 more situations and for more kinds of service. However, the "O" 363 definition is also listed so that ISD authors will be aware of the 364 context in which the term is used more narrowly. 366 When making substitutions, this Glossary attempts to avoid 367 contradicting any non-Internet authority. Still, terminology 368 differs between authorities such as the American Bar Association, 369 OSI, SET, the U.S. DoD, and other authorities; and this Glossary 370 probably is not exactly aligned with any of them. 372 4. Definitions 374 $ *-property 375 (N) Synonym for "confinement property" in the context of the Bell- 376 LaPadula model. Pronunciation: star property. 378 $ 3DES 379 (N) See: Triple Data Encryption Algorithm. 381 $ A1 computer system 382 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 383 Evaluation Criteria". 385 $ AA 386 See: attribute authority. 388 $ ABA Guidelines 389 (N) "American Bar Association (ABA) Digital Signature Guidelines" 390 [ABA], a framework of legal principles for using digital 391 signatures and digital certificates in electronic commerce. 393 $ Abstract Syntax Notation One (ASN.1) 394 (N) A standard for describing data objects. [Larm, X680] (See: 395 CMS.) 397 Deprecated Usage: The term "ASN.1" can be used narrowly to 398 describe the notation or language called "Abstract 399 Syntax Notation One", or can be used more broadly to 400 encompass the notation, its associated encoding rules 401 (see: BER), and software tools that assist in its use. 403 Tutorial: OSIRM defines computer network functionality in layers. 404 Protocols and data objects at higher layers are abstractly defined 405 to be implemented using protocols and data objects from lower 406 layers. A higher layer may define transfers of abstract objects 407 between computers, and a lower layer may define those transfers 408 concretely as strings of bits. Syntax is needed to specify data 409 formats of abstract objects, and encoding rules are needed to 410 transform abstract objects into bit strings at lower layers. OSI 411 standards use ASN.1 for those specifications and use various 412 encoding rules for those transformations. (See: BER.) 414 In ASN.1, formal names are written without spaces, and separate 415 words in a name are indicated by capitalizing the first letter of 416 each word except the first word. For example, the name of a CRL is 417 "certificateRevocationList". 419 $ ACC 420 (I) See: access control center. 422 $ acceptable risk 423 (I) A risk that is understood and tolerated by a system's user, 424 operator, owner, or accreditor, usually because the cost or 425 difficulty of implementing an effective countermeasure for the 426 associated vulnerability exceeds the expectation of loss. (See: 427 adequate security, "second law" under "Courtney's laws".) 429 $ access 430 1. (I) The ability and means to communicate with or otherwise 431 interact with a system to use system resources either to handle 432 information or to gain knowledge of the information the system 433 contains. (Compare: handle.) 435 Usage: The definition is intended to include all types of 436 communication with a system, including one-way communication in 437 either direction. In actual practice, however, passive users might 438 be treated as not having "access" and, therefore, be exempt from 439 most requirements of the system's security policy. (See: "passive 440 user" under "user".) 442 2. (O) /formal model/ "A specific type of interaction between a 443 subject and an object that results in the flow of information from 444 one to the other." [NCS04] 446 $ Access Certificate for Electronic Services (ACES) 447 (O) A PKI operated by the U.S. Government's General Services 448 Administration in cooperation with industry partners. (See: CAM.) 450 $ access control 451 1. (I) Protection of system resources against unauthorized access. 453 2. (I) A process by which use of system resources is regulated 454 according to a security policy and is permitted only by authorized 455 entities (users, programs, processes, or other systems) according 456 to that policy. (See: access, access control service, computer 457 security, discretionary access control, mandatory access control, 458 role-based access control.) 460 3. (I) /formal model/ Limitations on interactions between subjects 461 and objects in an information system. 463 4. (O) "The prevention of unauthorized use of a resource, 464 including the prevention of use of a resource in an unauthorized 465 manner." [I7498 Part 2] 467 5. (O) /U.S. Government/ A system using physical, electronic, or 468 human controls to identify or admit personnel with properly 469 authorized access to a SCIF. 471 $ access control center (ACC) 472 (I) A computer that maintains a database (possibly in the form of 473 an access control matrix) defining the security policy for an 474 access control service, and that acts as a server for clients 475 requesting access control decisions. 477 Tutorial: An ACC is sometimes used in conjunction with a key 478 center to implement access control in a key-distribution system 479 for symmetric cryptography. (See: BLACKER, Kerberos.) 481 $ access control list (ACL) 482 (I) /information system/ A mechanism that implements access 483 control for a system resource by enumerating the system entities 484 that are permitted to access the resource and stating, either 485 implicitly or explicitly, the access modes granted to each entity. 486 (Compare: access control matrix, access list, access profile, 487 capability list.) 489 $ access control matrix 490 (I) A rectangular array of cells, with one row per subject and one 491 column per object. The entry in a cell -- that is, the entry for a 492 particular subject-object pair -- indicates the access mode that 493 the subject is permitted to exercise on the object. Each column is 494 equivalent to an "access control list" for the object; and each 495 row is equivalent to an "access profile" for the subject. 497 $ access control service 498 (I) A security service that protects against a system entity using 499 a system resource in a way not authorized by the system's security 500 policy. (See: access control, discretionary access control, 501 identity-based security policy, mandatory access control, rule- 502 based security policy.) 504 Tutorial: This service includes protecting against use of a 505 resource in an unauthorized manner by an entity (i.e., a 506 principal) that is authorized to use the resource in some other 507 manner. (See: insider.) The two basic mechanisms for implementing 508 this service are ACLs and tickets. 510 $ access level 511 (D) Synonym for the hierarchical "classification level" in a 512 security level. [C4009] (See: security level.) 514 Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts 515 in a potentially misleading way. Access control may be based on 516 attributes other than classification level. 518 $ access list 519 (I) /physical security/ Roster of persons who are authorized to 520 enter a controlled area. (Compare: access control list.) 522 $ access mode 523 (I) A distinct type of data processing operation -- e.g., read, 524 write, append, or execute, or a combination of operations -- that 525 a subject can potentially perform on an object in an information 526 system. [Huff] 528 $ access policy 529 (I) A kind of "security policy". (See: access, access control.) 531 $ access profile 532 (O) A synonym for "capability list". 534 Usage: ISDs that use this term SHOULD state a definition for it 535 because the definition is not widely known. 537 $ access right 538 (I) Synonym for "authorization"; emphasizes the possession of the 539 authorization by a system entity. 541 $ accountability 542 (I) The property of a system or system resource that ensures that 543 the actions of a system entity may be traced uniquely to that 544 entity, which can then be held responsible for its actions. [Huff] 545 (See: audit service.) 547 Tutorial: Accountability (a.k.a. "individual accountability") 548 typically requires a system ability to positively associate the 549 identity of a user with the time, method, and mode of the user's 550 access to the system. This ability supports detection and 551 subsequent investigation of security breaches. Individual persons 552 who are system users are held accountable for their actions after 553 being notified of the rules of behavior for using the system and 554 the penalties associated with violating those rules. 556 $ accounting 557 See: COMSEC accounting. 559 $ accounting legend code (ALC) 560 (O) /U.S. Government/ Numeric system used to indicate the minimum 561 accounting controls required for items of COMSEC material within 562 the CMCS. [C4009] (See: COMSEC accounting.) 564 $ accreditation 565 (N) An administrative action by which a designated authority 566 declares that an information system is approved to operate in a 567 particular security configuration with a prescribed set of 568 safeguards. [FP102, SP37] (See: certification.) 570 Tutorial: An accreditation is usually based on a technical 571 certification of the system's security mechanisms. To accredit a 572 system, the approving authority must determine that any residual 573 risk is an acceptable risk. Although the terms "certification" and 574 "accreditation" are used more in the U.S. DoD and other government 575 agencies than in commercial organizations, the concepts apply any 576 place where managers are required to deal with and accept 577 responsibility for security risks. For example, the American Bar 578 Association is developing accreditation criteria for CAs. 580 $ accreditation boundary 581 (O) Synonym for "security perimeter". [C4009] 583 $ accreditor 584 (N) A management official who has been designated to have the 585 formal authority to "accredit" an information system, i.e., to 586 authorize the operation of, and the processing of sensitive data 587 in, the system and to accept the residual risk associated with the 588 system. (See: accreditation, residual risk.) 590 $ ACES 591 (O) See: Access Certificate for Electronic Services. 593 $ ACL 594 (I) See: access control list. 596 $ acquirer 597 1. (O) /SET/ "The financial institution that establishes an 598 account with a merchant and processes payment card authorizations 599 and payments." [SET1] 601 2. (O) /SET/ "The institution (or its agent) that acquires from 602 the card acceptor the financial data relating to the transaction 603 and initiates that data into an interchange system." [SET2] 605 $ activation data 606 (N) Secret data, other than keys, that is required to access a 607 cryptographic module. 609 $ active attack 610 (I) See: secondary definition under "attack". 612 $ active content 613 (O) "Electronic documents that can carry out or trigger actions 614 automatically on a computer platform without the intervention of a 615 user. [This technology enables] mobile code associated with a 616 document to execute as the document is rendered." [SP28] (See: 617 mobile code.) 619 $ active user 620 (I) See: secondary definition under "attack". 622 $ active wiretapping 623 (I) A wiretapping attack that attempts to alter data being 624 communicated or otherwise affect data flow. (See: wiretapping. 625 Compare: active attack, passive wiretapping.) 627 $ add-on security 628 (N) The retrofitting of protection mechanisms, implemented by 629 hardware or software, in an information system after the system 630 has become operational. [FP039] (Compare: baked-in security.) 632 $ adequate security 633 (O) /U.S. DoD/ "Security commensurate with the risk and magnitude 634 of harm resulting from the loss, misuse, or unauthorized access to 635 or modification of information." (See: acceptable risk, residual 636 risk.) 638 $ administrative security 639 1. (I) Management procedures and constraints to prevent 640 unauthorized access to a system. (See: "third law" under 641 "Courtney's laws", operational security, procedural security, 642 security architecture. Compare: technical security.) 644 Examples: Clear delineation and separation of duties; 645 configuration control. 647 Usage: Administrative security is usually understood to consist of 648 methods and mechanisms that are implemented and executed primarily 649 by people, rather than by automated systems. 651 2. (O) "The management constraints, operational procedures, 652 accountability procedures, and supplemental controls established 653 to provide an acceptable level of protection for sensitive data." 654 [FP039] 656 $ administrator 657 1. (O) /Common Criteria/ A person that is responsible for 658 configuring, maintaining, and administering the TOE in a correct 659 manner for maximum security. (See: administrative security.) 661 2. (O) /ITSEC/ A person in contact with the TOE, who is 662 responsible for maintaining its operational capability. 664 $ Advanced Encryption Standard (AES) 665 (N) A U.S. Government standard [FP197] (the successor to DES) that 666 (a) specifies "the AES algorithm", which is a symmetric block 667 cipher that is based on Rijndael and uses key sizes of 128, 192, 668 or 256 bits to operate on a 128-bit block, and (b) states policy 669 for using that algorithm to protect unclassified, sensitive data. 671 Tutorial: Rijndael was designed to handle additional block sizes 672 and key lengths that were not adopted in the AES. Rijndael was 673 selected by NIST through a public competition that was held to 674 find a successor to the DEA; the other finalists were MARS, RC6, 675 Serpent, and Twofish. 677 $ adversary 678 1. (I) An entity that attacks a system. (Compare: intruder.) 680 2. (I) An entity that is a threat to a system. 682 $ AES 683 (N) See: Advanced Encryption Standard. 685 $ Affirm 686 (O) A formal methodology, language, and integrated set of software 687 tools developed at the University of Southern California's 688 Information Sciences Institute for specifying, coding, and 689 verifying software to produce correct and reliable programs. 690 [Cheh] 692 $ aggregation 693 (I) A circumstance in which a collection of information items is 694 required to be classified at a higher security level than any of 695 the items is classified individually. (See: classification.) 697 $ AH 698 (I) See: Authentication Header 700 $ air gap 701 (I) An interface between two systems at which (a) they are not 702 connected physically and (b) any logical connection is not 703 automated (i.e., data is transferred through the interface only 704 manually, under human control). (See: sneaker net. Compare: 705 gateway.) 707 Example: Computer A and computer B are on opposite sides of a 708 room. To move data from A to B, a person carries a floppy disk 709 across the room. If A and B operate in different security domains, 710 than moving data across the air gap may involve an upgrade or 711 downgrade operation. 713 $ ALC 714 (O) See: accounting legend code. 716 $ algorithm 717 (I) A finite set of step-by-step instructions for a problem- 718 solving or computation procedure, especially one that can be 719 implemented by a computer. (See: cryptographic algorithm.) 721 $ alias 722 (I) A name that an entity uses in place of its real name, usually 723 for the purpose of either anonymity or masquerade. 725 $ Alice and Bob 726 (I) The parties that are most often called upon to illustrate the 727 operation of bipartite security protocols. These and other 728 dramatis personae are listed by Schneier [Schn]. 730 $ American National Standards Institute (ANSI) 731 (N) A private, not-for-profit association that administers U.S. 732 private sector voluntary standards. 734 Tutorial: ANSI has approximately 1,000 member organizations, 735 including equipment users, manufacturers, and others. These 736 include commercial firms, government agencies, and other 737 institutions and international entities. 739 ANSI is the sole U.S. representative to (1) ISO and (2) (via the 740 U.S. National Committee) the International Electrotechnical 741 Commission (IEC), which are the two major, non-treaty, 742 international standards organizations. 744 ANSI provides a forum for ANSI-accredited standards development 745 groups. Among those groups, the following are especially relevant 746 to Internet security: 747 - International Committee for Information Technology 748 Standardization (INCITS) (formerly X3): Primary U.S. focus of 749 standardization in information and communications technologies, 750 encompassing storage, processing, transfer, display, 751 management, organization, and retrieval of information. 752 Example: [A3092]. 753 - Accredited Standards Committee X9: Develops, establishes, 754 maintains, and promotes standards for the financial services 755 industry. Example: [A9009]. 756 - Alliance for Telecommunications Industry Solutions (ATIS): 757 Develops standards, specifications, guidelines, requirements, 758 technical reports, industry processes, and verification tests 759 for interoperability and reliability of telecommunications 760 networks, equipment, and software. Example: [A1523]. 762 $ American Standard Code for Information Interchange (ASCII) 763 (N) A scheme that encodes 128 specified characters -- the numbers 764 0-9, the letters a-z and A-Z, some basic punctuation symbols, some 765 control codes that originated with Teletype machines, and a blank 766 space -- into the 7-bit binary numbers. Forms the basis of the 767 character set representations used in most computers and many 768 Internet standards. [FP001] (See: code.) 770 $ Anderson report 771 (O) A 1972 study of computer security that was written by James P. 772 Anderson for the U.S. Air Force [Ande]. 774 Tutorial: Anderson collaborated with a panel of experts to study 775 Air Force requirements for multilevel security. The study 776 recommended research and development that was urgently needed to 777 provide secure information processing for command and control 778 systems and support systems. The report introduced the reference 779 monitor concept and provided development impetus for computer and 780 network security technology. However, many of the security 781 problems that the 1972 report called "current" still plague 782 information systems today. 784 $ anomaly detection 785 (I) A intrusion detection method that searches for activity that 786 is different from the normal behavior of system entities and 787 system resources. (See: IDS. Compare: misuse detection.) 789 $ anonymity 790 (I) The condition of having a name that is unknown or concealed. 791 (See: alias, anonymizer, anonymous credential, anonymous login, 792 onion routing, persona certificate. Compare: privacy.) 794 Tutorial: An application may require security services that 795 maintain anonymity of users or other system entities, perhaps to 796 preserve their privacy or hide them from attack. To hide an 797 entity's real name, an alias may be used. For example, a financial 798 institution may assign an account number. Parties to a transaction 799 can thus remain relatively anonymous, but can also accept the 800 transaction as legitimate. Real names of the parties cannot be 801 easily determined by observers of the transaction, but an 802 authorized third party may be able to map an alias to a real name, 803 such as by presenting the institution with a court order. In other 804 applications, anonymous entities may be completely untraceable. 806 $ anonymizer 807 (I) A internetwork service, usually provided via a proxy server, 808 that provides anonymity and privacy for clients. That is, the 809 service enables a client to access servers without allowing the 810 anyone to gather information about which servers the client 811 accesses and without allowing the accessed servers to gather 812 information about the client, such as its IP address. 814 $ anonymous credential 815 (D) /U.S. Government/ A credential that (a) can be used to 816 authenticate a person as having a specific attribute or being a 817 member of a specific group (e.g., military veterans or U.S. 818 citizens) but (b) does not reveal the individual identity of the 819 person that presents the credential. [M0404] (See: anonymity.) 821 Deprecated term: ISDs SHOULD NOT use this term; it mixes concepts 822 in a potentially misleading way. For example, when the credential 823 is an X.509 certificate, the term could be misunderstood to mean 824 that the certificate was signed by a CA that has a persona 825 certificate. Instead, use "attribute certificate", "organizational 826 certificate", or "persona certificate" depending on what is meant, 827 and provide additional explanations as needed. 829 $ anonymous login 830 (I) An access control feature (actually, an access control 831 vulnerability) in many Internet hosts that enables users to gain 832 access to general-purpose or public services and resources of a 833 host (such as allowing any user to transfer data using File 834 Transfer Protocol) without having a pre-established, identity- 835 specific account (i.e., user name and password). (See: anonymity.) 837 Tutorial: This feature exposes a system to more threats than when 838 all the users are known, pre-registered entities that are 839 individually accountable for their actions. A user logs in using a 840 special, publicly known user name (e.g., "anonymous", "guest", or 841 "ftp"). To use the public login name, the user is not required to 842 know a secret password and may not be required to input anything 843 at all except the name. In other cases, to complete the normal 844 sequence of steps in a login protocol, the system may require the 845 user to input a matching, publicly known password (such as 846 "anonymous") or may ask the user for an e-mail address or some 847 other arbitrary character string. 849 $ ANSI 850 (N) See: American National Standards Institute. 852 $ anti-jam 853 (N) "Measures ensuring that transmitted information can be 854 received despite deliberate jamming attempts." [C4009] (See: 855 electronic security, frequency hopping, jam, spread spectrum.) 857 $ apex trust anchor 858 (N) The trust anchor that is superior to all other trust anchors 859 in a particular system or context. (See: trust anchor, top CA.) 861 $ API 862 (I) See: application programming interface. 864 $ APOP 865 (I) See: POP3 APOP. 867 $ Application Layer 868 See: Internet Protocol Suite, OSIRM. 870 $ application program 871 (I) A computer program that performs a specific function directly 872 for a user (as opposed to a program that is part of a computer 873 operating system and exists to perform functions in support of 874 application programs). 876 $ archive 877 1a. (I) /noun/ A collection of data that is stored for a 878 relatively long period of time for historical and other purposes, 879 such as to support audit service, availability service, or system 880 integrity service. (Compare: backup, repository.) 882 1b. (I) /verb/ To store data in such a way as to create an 883 archive. (Compare: back up.) 885 Tutorial: A digital signature may need to be verified many years 886 after the signing occurs. The CA -- the one that issued the 887 certificate containing the public key needed to verify that 888 signature -- may not stay in operation that long. So every CA 889 needs to provide for long-term storage of the information needed 890 to verify the signatures of those to whom it issues certificates. 892 $ ARPANET 893 (I) Advanced Research Projects Agency (ARPA) Network, a pioneer 894 packet-switched network that (a) was designed, implemented, 895 operated, and maintained by BBN from January 1969 until July 1975 896 under contract to the U.S. Government; (b) led to the development 897 of today's Internet; and (c) was decommissioned in June 1990. 898 [B4799, Hafn] 900 $ ASCII 901 (N) See: American Standard Code for Information Interchange. 903 $ ASN.1 904 (N) See: Abstract Syntax Notation One. 906 $ asset 907 (I) A system resource that is (a) required to be protected by an 908 information system's security policy, (b) intended to be protected 909 by a countermeasure, or (c) required for a system's mission. 911 $ association 912 (I) A cooperative relationship between system entities, usually 913 for the purpose of transferring information between them. (See: 914 security association.) 916 $ assurance 917 See: security assurance. 919 $ assurance level 920 (N) A rank on a hierarchical scale that judges the confidence 921 someone can have that a TOE adequately fulfills stated security 922 requirements. (See: assurance, certificate policy, EAL, TCSEC.) 924 Example: U.S. Government guidance [M0404] describes four assurance 925 levels for identity authentication, where each level "describes 926 the [Government] agency's degree of certainty that the user has 927 presented [a credential] that refers to [the user's] identity." In 928 that guidance, "assurance is defined as (a) "the degree of 929 confidence in the vetting process used to establish the identity 930 of the individual to whom the credential was issued" and (b) "the 931 degree of confidence that the individual who uses the credential 932 is the individual to whom the credential was issued." 934 The four levels are described as follows: 935 - Level 1: Little or no confidence in the asserted identity. 936 - Level 2: Some confidence in the asserted identity. 937 - Level 3: High confidence in the asserted identity. 938 - Level 4: Very high confidence in the asserted identity. 940 Standards for determining these levels are provided in a NIST 941 publication [SP12]. However, as noted there, an assurance level is 942 "a degree of confidence, not a true measure of how secure the 943 system actually is. This distinction is necessary because it is 944 extremely difficult -- and in many cases virtually impossible -- 945 to know exactly how secure a system is." 947 $ asymmetric cryptography 948 (I) A modern branch of cryptography (popularly known as "public- 949 key cryptography") in which the algorithms use a pair of keys (a 950 public key and a private key) and use a different component of the 951 pair for each of two counterpart cryptographic operations (e.g., 952 encryption and decryption, or signature creation and signature 953 verification). (See: key pair, symmetric cryptography.) 955 Tutorial: Asymmetric algorithms have key management advantages 956 over equivalently strong symmetric ones. First, one key of the 957 pair need not be known by anyone but its owner; so it can more 958 easily be kept secret. Second, although the other key is shared by 959 all entities that use the algorithm, that key need not be kept 960 secret from other, non-using entities; thus, the key-distribution 961 part of key management can be done more easily. 963 Asymmetric cryptography can be used to create algorithms for 964 encryption, digital signature, and key agreement: 965 - In an asymmetric encryption algorithm (e.g., see: RSA), when 966 Alice wants to ensure confidentiality for data she sends to 967 Bob, she encrypts the data with a public key provided by Bob. 968 Only Bob has the matching private key that is needed to decrypt 969 the data. (Compare: seal.) 970 - In an asymmetric digital signature algorithm (e.g., see: DSA), 971 when Alice wants to ensure data integrity or provide 972 authentication for data she sends to Bob, she uses her private 973 key to sign the data (i.e., create a digital signature based on 974 the data). To verify the signature, Bob uses the matching 975 public key that Alice has provided. 976 - In an asymmetric key-agreement algorithm (e.g., see: Diffie- 977 Hellman), Alice and Bob each send their own public key to the 978 other party. Then each uses their own private key and the 979 other's public key to compute the new key value. 981 $ asymmetric key 982 (I) A cryptographic key that is used in an asymmetric 983 cryptographic algorithm. (See: asymmetric cryptography, private 984 key, public key.) 986 $ ATIS 987 (N) See: "Alliance for Telecommunications Industry Solutions" 988 under "ANSI". 990 $ attack 991 1. (I) An intentional act by which an entity attempts to evade 992 security services and violate the security policy of a system. 993 That is, an actual assault on system security that derives from an 994 intelligent threat. (See: penetration, violation, vulnerability.) 995 2. (I) A method or technique used in an assault (e.g., 996 masquerade). (See: distributed attack.) 998 Tutorial: Attacks can be characterized according to intent: 999 - An "active attack" attempts to alter system resources or affect 1000 their operation. 1001 - A "passive attack" attempts to learn or make use of information 1002 from the system but does not affect system resources. (E.g., 1003 see: wiretapping.) 1005 The object of a passive attack might be to obtain data that is 1006 needed for an off-line attack. 1007 - An "off-line attack" is one in which the attacker obtains data 1008 from the target system and then analyzes the data on a 1009 different system of the attacker's own choosing, possibly in 1010 preparation for a second stage of attack on the target. 1012 Attacks can be characterized according to point of initiation: 1013 - An "inside attack" is one that is initiated by an entity inside 1014 the security perimeter (an "insider"), i.e., an entity that is 1015 authorized to access system resources but uses them in a way 1016 not approved by those who granted the authorization. 1017 - An "outside attack" is initiated from outside the perimeter, by 1018 an unauthorized or illegitimate user of the system (an 1019 "outsider"). In the Internet, potential outside attackers range 1020 from amateur pranksters to organized criminals, international 1021 terrorists, and hostile governments. 1023 The term "attack" relates to some other basic security terms as 1024 shown in the following diagram: 1026 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 1027 | An Attack: | |Counter- | | A System Resource: | 1028 | i.e., A Threat Action | | measure | | Target of the Attack | 1029 | +----------+ | | | | +-----------------+ | 1030 | | Attacker |<==================||<========= | | 1031 | | i.e., | Passive | | | | | Vulnerability | | 1032 | | A Threat |<=================>||<========> | | 1033 | | Agent | or Active | | | | +-------|||-------+ | 1034 | +----------+ Attack | | | | VVV | 1035 | | | | | Threat Consequences | 1036 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 1038 $ attack potential 1039 (I) The perceived likelihood of success should an attack be 1040 launched, expressed in terms of the attacker's ability (i.e., 1041 expertise and resources) and motivation. (Compare: threat, risk.) 1043 $ attack sensing, warning, and response 1044 (I) A set of security services that cooperate with audit service 1045 to detect and react to indications of threat actions, including 1046 both inside and outside attacks. (See: indicator.) 1048 $ attack tree 1049 (I) A branching, hierarchical data structure that represents a set 1050 of potential approaches to achieving an event in which system 1051 security is penetrated or compromised in a specified way. [Moor] 1053 Tutorial: Attack trees are special cases of fault trees. The 1054 security incident that is the goal of the attack is represented as 1055 the root node of the tree, and the ways that an attacker could 1056 reach that goal are iteratively and incrementally represented as 1057 branches and subnodes of the tree. Each subnode defines a subgoal, 1058 and each subgoal may have its own set of further subgoals, etc. 1059 The final nodes on the paths outward from the root, i.e., the leaf 1060 nodes, represent different ways to initiate an attack. Each node 1061 other than a leaf is either an AND-node or an OR-node. To achieve 1062 the goal represented by an AND-node, the subgoals represented by 1063 all of that node's subnodes must be achieved; and for an OR-node, 1064 at least one of the subgoals must be achieved. Branches can be 1065 labeled with values representing difficulty, cost, or other attack 1066 attributes, so that alternative attacks can be compared. 1068 $ attribute 1069 1. (N) The information of a particular type concerning an 1070 identifiable system entity or object. An "attribute type" is the 1071 component of an attribute that indicates the class of information 1072 given by the attribute; and an "attribute value" is a particular 1073 instance of the class of information indicated by an attribute 1074 type. (See: attribute certificate.) 1076 $ attribute authority (AA) 1077 1. (N) A CA that issues attribute certificates. 1079 2. (O) "An authority [that] assigns privileges by issuing 1080 attribute certificates." [X509] 1082 Deprecated Abbreviation: The abbreviation "AA" SHOULD NOT be used 1083 in an ISD unless it is first defined in the ISD. 1085 $ attribute certificate 1086 1. (I) A digital certificate that binds a set of descriptive data 1087 items, other than a public key, either directly to a subject name 1088 or to the identifier of another certificate that is a public-key 1089 certificate. (See: capability token.) 1091 2. (O) "A data structure, digitally signed by an [a]ttribute 1092 [a]uthority, that binds some attribute values with identification 1093 information about its holder." [X509] 1095 Tutorial: A public-key certificate binds a subject name to a 1096 public key value, along with information needed to perform certain 1097 cryptographic functions using that key. Other attributes of a 1098 subject, such as a security clearance, may be certified in a 1099 separate kind of digital certificate, called an attribute 1100 certificate. A subject may have multiple attribute certificates 1101 associated with its name or with each of its public-key 1102 certificates. 1104 An attribute certificate might be issued to a subject in the 1105 following situations: 1106 - Different lifetimes: When the lifetime of an attribute binding 1107 is shorter than that of the related public-key certificate, or 1108 when it is desirable not to need to revoke a subject's public 1109 key just to revoke an attribute. 1110 - Different authorities: When the authority responsible for the 1111 attributes is different than the one that issues the public-key 1112 certificate for the subject. (There is no requirement that an 1113 attribute certificate be issued by the same CA that issued the 1114 associated public-key certificate.) 1116 $ audit 1117 See: security audit. 1119 $ audit log 1120 (I) Synonym for "security audit trail". 1122 $ audit service 1123 (I) A security service that records information needed to 1124 establish accountability for system events and for the actions of 1125 system entities that cause them. (See: security audit.) 1127 $ audit trail 1128 (I) See: security audit trail. 1130 $ AUTH 1131 (I) See: POP3 AUTH. 1133 $ authentic signature 1134 (I) A signature (especially a digital signature) that can be 1135 trusted because it can be verified. (See: validate vs. verify.) 1137 $ authenticate 1138 (I) Verify (i.e., establish the truth of) an identity claimed by 1139 or for a system entity. (See: authentication, validate vs. verify, 1140 "relationship between data integrity service and authentication 1141 services" under "data integrity service".) 1143 Deprecated Usage: In general English usage, this term is used with 1144 the meaning "to prove genuine" (e.g., an art expert authenticates 1145 a Michelangelo painting); but this Internet definition restricts 1146 usage as follows: 1147 - ISDs SHOULD NOT use this term to refer to proving or checking 1148 that data has not been changed, destroyed or lost in an 1149 unauthorized or accidental manner. Instead use "verify". 1150 - ISDs SHOULD NOT use this term to refer to proving the truth or 1151 accuracy of a fact or value such as a digital signature. 1152 Instead, use "verify". 1153 - ISDs SHOULD NOT use this term to refer to establishing the 1154 soundness or correctness of a construct, such as a digital 1155 certificate. Instead, use "validate". 1157 $ authentication 1158 (I) The process of verifying an identity claimed by or for a 1159 system entity. (See: authenticate, authentication exchange, 1160 authentication information, credential, data origin 1161 authentication, peer entity authentication, "relationship between 1162 data integrity service and authentication services" under "data 1163 integrity service", simple authentication, strong authentication, 1164 X.509.) 1166 Tutorial: An authentication process consists of two steps: 1167 - Identification step: Presenting an identifier to the security 1168 system. (Identifiers should be assigned carefully, because 1169 authenticated identities are the basis for other security 1170 services, such as access control service.) 1171 - Verification step: Presenting or generating authentication 1172 information that acts as evidence to prove the binding between 1173 the claimant and the identifier. (See: verification.) 1175 $ authentication code 1176 (D) Synonym for a checksum based on cryptography. (Compare: 1177 Message Authentication Code.) 1179 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 1180 any form of checksum, cryptographic or not. Instead, use 1181 "checksum", "error detection code", "hash", "keyed hash", "Message 1182 Authentication Code", or "protected checksum", depending on what 1183 is meant. 1185 The term mixes concepts in a potentially misleading way. The word 1186 "authentication" is misleading because the checksum may be used to 1187 perform a data integrity function rather than a data origin 1188 authentication function. The word "code" is misleading because it 1189 suggests either that encoding or encryption is involved or that 1190 the term refers to computer software. 1192 $ authentication exchange 1193 1. (I) A mechanism to verify the identity of an entity by means of 1194 information exchange. 1196 2. (O) "A mechanism intended to ensure the identity of an entity 1197 by means of information exchange." [I7498 Part 2] 1199 $ Authentication Header (AH) 1200 (I) An Internet protocol [R2402] designed to provide 1201 connectionless data integrity service and connectionless data 1202 origin authentication service for IP datagrams, and (optionally) 1203 to provide partial sequence integrity and protection against 1204 replay attacks. (See: IPsec. Compare: ESP.) 1206 Tutorial: Replay protection may be selected by the receiver when a 1207 security association is established. AH authenticates the upper- 1208 layer PDU that is carried as an IP SDU, and also authenticates as 1209 much of the IP PCI (i.e., the IP header) as possible. However, 1210 some IP header fields may change in transit, and the value of 1211 these fields, when the packet arrives at the receiver, may not be 1212 predictable by the sender. Thus, the values of such fields cannot 1213 be protected end-to-end by AH; protection of the IP header by AH 1214 is only partial when such fields are present. 1216 AH may be used alone, or in combination with the ESP, or in a 1217 nested fashion with tunneling. Security services can be provided 1218 between a pair of communicating hosts, between a pair of 1219 communicating security gateways, or between a host and a gateway. 1220 ESP can provide nearly the same security services as AH, and ESP 1221 can also provide data confidentiality service. The main difference 1222 between authentication services provided by ESP and AH is the 1223 extent of the coverage; ESP does not protect IP header fields 1224 unless they are encapsulated by AH. 1226 $ authentication information 1227 (I) Information used to verify an identity claimed by or for an 1228 entity. (See: authentication, credential, user. Compare: 1229 identification information.) 1231 Tutorial: Authentication information may exist as, or be derived 1232 from, one of the following: (a) Something the entity knows (see: 1233 password); (b) something the entity possesses (see: token); (c) 1234 something the entity is (see: biometric authentication). 1236 $ authentication service 1237 (I) A security service that verifies an identity claimed by or for 1238 an entity. (See: authentication.) 1240 Tutorial: In a network, there are two general forms of 1241 authentication service: data origin authentication service and 1242 peer entity authentication service. 1244 $ authenticity 1245 (I) The property of being genuine and able to be verified and be 1246 trusted. (See: authenticate, authentication, validate vs. verify.) 1248 $ authority 1249 (D) "An entity, responsible for the issuance of certificates." 1250 [X509] 1252 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 1253 attribute authority, certification authority, registration 1254 authority, or similar terms; the shortened form may cause 1255 confusion. Instead, use the full term at the first instance of 1256 usage and then, if it is necessary to shorten text, use AA, CA, 1257 RA, and other abbreviations defined in this Glossary. 1259 $ authority certificate 1260 (D) "A certificate issued to an authority (e.g. either to a 1261 certification authority or to an attribute authority)." [X509] 1262 (See: authority.) 1264 Deprecated Term: ISDs SHOULD NOT use this term as defined here; it 1265 is ambiguous. Instead, use the full term "certification authority 1266 certificate", "attribute authority certificate", "registration 1267 authority certificate", etc. at the first instance of usage and 1268 then, if it is necessary to shorten text, use AA, CA, RA, and 1269 other abbreviations defined in this Glossary. 1271 $ Authority Information Access extension 1272 (I) The private extension defined by PKIX for X.509 certificates 1273 to indicate "how to access CA information and services for the 1274 issuer of the certificate in which the extension appears. 1275 Information and services may include on-line validation services 1276 and CA policy data." [R3280] (See: private extension.) 1278 $ authorization 1279 1a. (I) An approval that is granted to a system entity to access a 1280 system resource. (Compare: permission, privilege.) 1282 Usage: Some synonyms are "permission" and "privilege". Specific 1283 terms are preferred in certain contexts: 1284 - /PKI/ "Authorization" SHOULD be used, to align with 1285 "certification authority" in the standard [X509]. 1286 - /role-based access control/ "Permission" SHOULD be used, to 1287 align with the standard [ANSI]. 1288 - /computer operating systems/ "Privilege" SHOULD be used, to 1289 align with the literature. (See: privileged process, privileged 1290 user.) 1292 Tutorial: The semantics and granularity of authorizations depend 1293 on the application and implementation (see: "first law" under 1294 "Courtney's laws"). An authorization may specify a particular 1295 access mode -- such as read, write, or execute -- for one or more 1296 system resources. 1298 1b. (I) A process for granting approval to a system entity to 1299 access a system resource. 1301 2. (O) /SET/ "The process by which a properly appointed person or 1302 persons grants permission to perform some action on behalf of an 1303 organization. This process assesses transaction risk, confirms 1304 that a given transaction does not raise the account holder's debt 1305 above the account's credit limit, and reserves the specified 1306 amount of credit. (When a merchant obtains authorization, payment 1307 for the authorized amount is guaranteed -- provided, of course, 1308 that the merchant followed the rules associated with the 1309 authorization process.)" [SET2] 1311 $ authorization credential 1312 (I) See: /access control/ under "credential". 1314 $ authorize 1315 (I) Grant an authorization to a system entity. 1317 $ authorized user 1318 (I) /access control/ A system entity that accesses a system 1319 resource for which the entity has received an authorization. 1320 (Compare: insider, outsider, unauthorized user.) 1322 Deprecated Usage: ISDs that use this term SHOULD state a 1323 definition for it because the term is used in many ways and could 1324 easily be misunderstood. 1326 $ automated information system 1327 See: information system. 1329 $ availability 1330 1. (I) The property of a system or a system resource being 1331 accessible, or usable or operational upon demand, by an authorized 1332 system entity, according to performance specifications for the 1333 system; i.e., a system is available if it provides services 1334 according to the system design whenever users request them. (See: 1335 critical, denial of service. Compare: precedence, reliability, 1336 survivability.) 1338 2. (O) "The property of being accessible and usable upon demand by 1339 an authorized entity." [I7498 Part 2] 1341 Tutorial: This service addresses the security concerns raised by 1342 denial-of-service attacks. It depends on proper management and 1343 control of system resources, and thus depends on access control 1344 service and other security services. 1346 Availability requirements can be specified by quantitative 1347 metrics, but sometimes are stated qualitatively, such as in the 1348 following: 1349 - "Flexible tolerance for delay" may mean that brief system 1350 outages do not endanger mission accomplishment, but extended 1351 outages may endanger the mission. 1352 - "Minimum tolerance for delay" may mean that mission 1353 accomplishment requires the system to provide requested 1354 services in a short time. 1356 $ availability service 1357 (I) A security service that protects a system to ensure its 1358 availability. 1360 Tutorial: This service addresses the security concerns raised by 1361 denial-of-service attacks. It depends on proper management and 1362 control of system resources, and thus depends on access control 1363 service and other security services. 1365 $ avoidance 1366 (I) See: secondary definition under "security". 1368 $ B1, B2, or B3 computer system 1369 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 1370 Evaluation Criteria". 1372 $ back door 1373 1. (I) /computer security/ A computer system feature -- which may 1374 be (a) an unintentional flaw, (b) a mechanism deliberately 1375 installed by the system's creator, or (c) a mechanism 1376 surreptitiously installed by an intruder -- that provides access 1377 to a system resource by other than the usual procedure and usually 1378 is hidden or otherwise not well-known. (See: maintenance hook. 1379 Compare: Trojan Horse.) 1381 Example: A way to access a computer other than through a normal 1382 login. Such an access path is not necessarily designed with 1383 malicious intent; operating systems sometimes are shipped by the 1384 manufacturer with hidden accounts intended for use by field 1385 service technicians or the vendor's maintenance programmers. 1387 2. (I) /cryptography/ A feature of a cryptographic system that 1388 makes it easily possible to break or circumvent the protection 1389 that the system is designed to provided. 1391 Example: A feature that makes it possible to decrypt cipher text 1392 much more quickly than by brute force cryptanalysis, without 1393 having prior knowledge of the decryption key. 1395 $ back up 1396 (I) /verb/ Create a reserve copy of data or, more generally, 1397 provide alternate means to perform system functions despite loss 1398 of system resources. (See: contingency plan. Compare: archive.) 1400 $ backup 1401 (I) /noun or adjective/ Refers to alternate means of performing 1402 system functions despite loss of system resources. (See: 1403 contingency plan). 1405 Example: A reserve copy of data, preferably one that is stored 1406 separately from the original, for use if the original becomes lost 1407 or damaged. (Compare: archive.) 1409 $ baggage 1410 (O) /SET/ An "opaque encrypted tuple, which is included in a SET 1411 message but appended as external data to the PKCS encapsulated 1412 data. This avoids superencryption of the previously encrypted 1413 tuple, but guarantees linkage with the PKCS portion of the 1414 message." [SET2] 1416 Deprecated Usage: ISDs SHOULD NOT use this term to describe a data 1417 element, except in the form "SET(trademark) baggage" with the 1418 meaning given above. 1420 $ baked-in security 1421 (I) The inclusion of security mechanisms in an information system 1422 beginning at an early point in the system's life cycle, i.e., 1423 during the design phase, or at least early in the implementation 1424 phase. (Compare: add-on security.) 1426 Deprecated Term: It is likely that other cultures use different 1427 metaphors for this concept. Therefore, to avoid international 1428 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 1429 Usage under "Green Book".) 1431 $ bandwidth 1432 (I) The total width of the frequency band that is available to or 1433 used by a communication channel; usually expressed in Hertz (Hz). 1434 (RFC 3753) (Compare: channel capacity.) 1436 $ bank identification number (BIN) 1437 1. (O) The digits of a credit card number that identify the 1438 issuing bank. (See: primary account number.) 1440 2. (O) /SET/ The first six digits of a primary account number. 1442 $ Basic Encoding Rules (BER) 1443 (I) A standard for representing ASN.1 data types as strings of 1444 octets. [X690] (See: Distinguished Encoding Rules.) 1446 Deprecated Usage: Sometimes incorrectly treated as part of ASN.1. 1447 However, ASN.1 properly refers only to a syntax description 1448 language, and not to the encoding rules for the language. 1450 $ Basic Security Option 1451 (I) See: secondary definition under "IPSO". 1453 $ bastion host 1454 (I) A strongly protected computer that is in a network protected 1455 by a firewall (or is part of a firewall) and is the only host (or 1456 one of only a few) in the network that can be directly accessed 1457 from networks on the other side of the firewall. (See: firewall.) 1459 Tutorial: Filtering routers in a firewall typically restrict 1460 traffic from the outside network to reaching just one host, the 1461 bastion host, which usually is part of the firewall. Since only 1462 this one host can be directly attacked, only this one host needs 1463 to be very strongly protected, so security can be maintained more 1464 easily and less expensively. However, to allow legitimate internal 1465 and external users to access application resources through the 1466 firewall, higher layer protocols and services need to be relayed 1467 and forwarded by the bastion host. Some services (e.g., DNS and 1468 SMTP) have forwarding built in; other services (e.g., TELNET and 1469 FTP) require a proxy server on the bastion host. 1471 $ BBN Technologies 1472 (O) The research-and-development company (originally called Bolt 1473 Baranek and Newman, Inc.) that built the ARPANET. 1475 $ BCA 1476 (O) See: brand certification authority. 1478 $ BCR 1479 (O) See: BLACK/Crypto/RED. 1481 $ BCI 1482 (O) See: brand CRL identifier. 1484 $ Bell-LaPadula model 1485 (N) A formal, mathematical, state-transition model of 1486 confidentiality policy for multilevel-secure computer systems 1487 [Bell]. (Compare: Biba model, Brewer-Nash model.) 1489 Tutorial: The model, devised by David Bell and Leonard LaPadula at 1490 The MITRE Corporation in 1973, characterizes computer system 1491 elements as subjects and objects. To determine whether or not a 1492 subject is authorized for a particular access mode on an object, 1493 the clearance of the subject is compared to the classification of 1494 the object. The model defines the notion of a "secure state", in 1495 which the only permitted access modes of subjects to objects are 1496 in accordance with a specified security policy. It is proven that 1497 each state transition preserves security by moving from secure 1498 state to secure state, thereby proving that the system is secure. 1499 In this model, a multilevel-secure system satisfies several rules, 1500 including the "confinement property" (a.k.a. the "*-property"), 1501 the "simple security property", and the "tranquillity property". 1503 $ benign 1504 (N) "Condition of cryptographic data [such] that [it] cannot be 1505 compromised by human access [to the data]." [C4009] 1507 $ benign fill 1508 (N) Process by which keying material is generated, distributed, 1509 and placed into an ECU without exposure to any human or other 1510 system entity, except the cryptographic module that consumes and 1511 uses the material. 1513 $ BER 1514 (I) See: Basic Encoding Rules. 1516 A1 1517 1. (O) /formal/ A level of security assurance that is beyond the 1518 highest level (level A1) of criteria specified by the TCSEC. (See: 1519 Tutorial under "Trusted Computer System Evaluation Criteria".) 1521 2. (O) /informal/ A level of trust so high that it is beyond 1522 state-of-the-art technology; i.e., it cannot be provided or 1523 verified by currently available assurance methods, and especially 1524 not by currently available formal methods. 1526 $ Biba integrity 1527 (N) Synonym for "source integrity". 1529 $ Biba model 1530 (N) A formal, mathematical, state-transition model of integrity 1531 policy for multilevel-secure computer systems [Biba]. (See: source 1532 integrity. Compare: Bell-LaPadula model.) 1534 Tutorial: This model for integrity control is analogous to the 1535 Bell-LaPadula model for confidentiality control. Each subject and 1536 object is assigned an integrity level and, to determine whether or 1537 not a subject is authorized for a particular access mode on an 1538 object, the integrity level of the subject is compared to that of 1539 the object. The model prohibits the changing of information in an 1540 object by a subject with a lesser or incomparable level. The rules 1541 of the Biba model are duals of the corresponding rules in the 1542 Bell-LaPadula model. 1544 $ billet 1545 (N) A position or assignment that can be filled by one system 1546 entity at a time. [JCSP1] (Compare: principal, role, user.) 1548 Tutorial: In an organization, a "billet" is a populational 1549 position, of which there is exactly one instance; but a "role" is 1550 functional position, of which there can be multiple instances. 1551 System entities are in one-to-one relationships with their 1552 billets, but may be in many-to-one and one-to-many relationships 1553 with their roles. 1555 $ BIN 1556 (O) See: bank identification number. 1558 $ bind 1559 (I) To inseparably associate by applying some mechanism. 1561 Example: A CA creates a public-key certificate by using a digital 1562 signature to bind together (a) a subject name, (b) a public key, 1563 and usually (c) some additional data items (e.g., see "X.509 1564 public-key certificate"). 1566 $ biometric authentication 1567 (I) A method of generating authentication information for a person 1568 by digitizing measurements of a physical or behavioral 1569 characteristic, such as a fingerprint, hand shape, retina pattern, 1570 voiceprint, handwriting style, or face. 1572 $ birthday attack 1573 (I) A class of attacks against cryptographic functions, including 1574 both encryption functions and hash functions. The attacks take 1575 advantage of a statistical property: Given a cryptographic 1576 function having an N-bit output, the probability is greater than 1577 1/2 that for 2**(N/2) randomly chosen inputs, the function will 1578 produce at least two outputs that are identical. (See: Tutorial 1579 under "hash function".) 1581 Derivation: From the somewhat surprising fact (often called the 1582 "birthday paradox") that although there are 365 days in a year, 1583 the probability is greater than 1/2 that two of more people share 1584 the same birthday in any randomly chosen group of 23 people. 1586 Birthday attacks enable an adversary to find two inputs for which 1587 a cryptographic function produces the same cipher text (or find 1588 two inputs for which a hash functions produces the same hash 1589 result) much faster than a brute force attack can; and a clever 1590 adversary can use such a capability to create considerable 1591 mischief. However, no birthday attack can enable an adversary to 1592 decrypt a given cipher text (or find a hash input that results in 1593 a given hash result) any faster than a brute force attack can. 1595 $ bit 1596 (I) A contraction of the term "binary digit"; the smallest unit of 1597 information storage, which has two possible states or values. The 1598 values usually are represented by the symbols "0" (zero) and "1" 1599 (one). (See: block, byte, word.) 1601 $ bit string 1602 (I) A sequence of bits, each of which is either "0" or "1". 1604 $ BLACK 1605 1. (I) Designation for data that consists only of cipher text, and 1606 for information system equipment items or facilities that handle 1607 only cipher text. Example: "BLACK key".(See: color change, 1608 RED/BLACK separation. Compare: RED.) 1610 2. (O) /U.S. Government/ "Designation applied to information 1611 systems, and to associated areas, circuits, components, and 1612 equipment, in which national security information is encrypted or 1613 is not processed. [C4009] 1615 $ BLACK/Crypto/RED (BCR) 1616 (N) An experimental, end-to-end, network packet encryption system 1617 developed in a working prototype form by BBN and the Collins Radio 1618 division of Rockwell Corporation in the 1975-1980 time frame for 1619 the U.S. DoD. BCR was the first network security system to support 1620 TCP/IP traffic, and it incorporated the first DES chips that were 1621 validated by the U.S. National Bureau of Standards (now called 1622 NIST). BCR also was the first to use a KDC and an ACC to manage 1623 connections. 1625 $ BLACK key 1626 (I) A key that is protected with a key-encrypting key and that 1627 must be decrypted before use. (See: BLACK. Compare: RED key.) 1629 $ BLACKER 1630 (O) An end-to-end encryption system for computer data networks 1631 that was developed by the U.S. DoD in the 1980s to provide host- 1632 to-host data confidentiality service for datagrams at OSIRM Layer 1633 3. [Weis] (Compare: Caneware, IPsec.) 1635 Tutorial: Each user host connects to its own bump-in-the-wire 1636 encryption device called a BLACKER Front End (BFE, TSEC/KI-111), 1637 through which the host connects to the subnetwork. The system also 1638 includes two types of centralized devices: one or more KDCs 1639 connect to the subnetwork and communicate with assigned sets of 1640 BFEs, and one or more ACCs connect to the subnetwork and 1641 communicate with assigned KDCs. BLACKER uses only symmetric 1642 encryption. A KDC distributes session keys to BFE pairs as 1643 authorized by an ACC. Each ACC maintains a database for a set of 1644 BFEs, and the database determines which pairs from that set (i.e., 1645 which pairs of user hosts behind the BFEs) are authorized to 1646 communicate and at what security levels. 1648 The BLACKER system is MLS in three ways: (a) The BFEs form a 1649 security perimeter around a subnetwork, separating user hosts from 1650 the subnetwork, so that the subnetwork can operate at a different 1651 security level (possibly a lower, less expensive level) than the 1652 hosts. (b) The BLACKER components are trusted to separate 1653 datagrams of different security levels, so that each datagram of a 1654 given security level can be received only by a host that is 1655 authorized for that security level; and thus BLACKER can separate 1656 host communities that operate at different security levels. (c) 1657 The host side of a BFE is itself MLS and can recognize a security 1658 label on each packet, so that an MLS user host can be authorized 1659 to successively transmit datagrams that are labeled with different 1660 security levels. 1662 $ block 1663 (I) A bit string or bit vector of finite length. (See: block 1664 cipher. Compare: byte, word.) 1666 Usage: An "N-bit block" contains N bits, which usually are 1667 numbered from left to right as 1, 2, 3, ..., N. 1669 $ block cipher 1670 (I) An encryption algorithm that breaks plain text into fixed-size 1671 segments and uses the same key to transform each plaintext segment 1672 into a fixed-size segment of cipher text. Examples: AES, Blowfish, 1673 DEA, IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream 1674 cipher.) 1676 Tutorial: A block cipher can be adapted to have a different 1677 external interface, such as that of a stream cipher, by using a 1678 mode of cryptographic operation to package the basic algorithm. 1679 (See: CBC, CFB, DEA, ECB, OFB.) 1681 $ Blowfish 1682 (N) A symmetric block cipher with variable-length key (32 to 448 1683 bits) designed in 1993 by Bruce Schneier as an unpatented, 1684 license-free, royalty-free replacement for DES or IDEA. [Schn] 1685 (See: Twofish.) 1687 $ brand 1688 1. (I) A distinctive mark or name that identifies a product or 1689 business entity. 1691 2. (O) /SET/ The name of a payment card. (See: BCA.) 1693 Tutorial: Financial institutions and other companies have founded 1694 payment card brands, protect and advertise the brands, establish 1695 and enforce rules for use and acceptance of their payment cards, 1696 and provide networks to interconnect the financial institutions. 1697 These brands combine the roles of issuer and acquirer in 1698 interactions with cardholders and merchants. [SET1] 1700 $ brand certification authority (BCA) 1701 (O) /SET/ A CA owned by a payment card brand, such as MasterCard, 1702 Visa, or American Express. [SET2] (See: certification hierarchy, 1703 SET.) 1705 $ brand CRL identifier (BCI) 1706 (O) /SET/ A digitally signed list, issued by a BCA, of the names 1707 of CAs for which CRLs need to be processed when verifying 1708 signatures in SET messages. [SET2] 1710 $ break 1711 (I) /cryptography/ To successfully perform cryptanalysis and thus 1712 succeed in decrypting data or performing some other cryptographic 1713 function, without initially having knowledge of the key that the 1714 function requires. (See: penetrate.) 1716 Usage: This term applies to encrypted data or, more generally, to 1717 a cryptographic algorithm or cryptographic system. 1719 $ Brewer-Nash model 1720 (N) A security model [BN89] to enforce the Chinese wall policy. 1722 (Compare: Bell-LaPadula model, Clark-Wilson model.) 1724 Tutorial: All proprietary information in the set of commercial 1725 firms F(1), F(2), ..., F(N) is categorized into mutually exclusive 1726 conflict-of-interest classes I(1), I(2), ..., I(M) that apply 1727 across all firms. Each firm belongs to exactly one class. The 1728 Brewer-Nash model has the following mandatory rules: 1729 - Brewer-Nash Read Rule: Subject S can read information object O 1730 from firm F(i) only if either (a) O is from the same firm as 1731 some object previously read by S *or* (b) O belongs to a class 1732 I(i) from which S has not previously read any object. (See: 1733 object, subject.) 1734 - Brewer-Nash Write Rule: Subject S can write information object 1735 O to firm F(i) only if (a) S can read O by the Brewer-Nash Read 1736 Rule *and* (b) no object can be read by S from a different firm 1737 F(j), no matter whether F(j) belongs to the same class as F(i) 1738 or to a different class. 1740 $ bridge 1741 (I) A gateway for traffic flowing at OSIRM Layer 2 between two 1742 networks (usually two LANs). (Compare: bridge CA, router.) 1744 $ bridge CA 1745 (I) A PKI consisting of only a CA that cross-certifies with CAs of 1746 some other PKIs. (See: cross-certification. Compare: bridge.) 1748 Tutorial: A bridge CA functions as a hub that enables a 1749 certificate user in any of the PKIs that attach to the bridge, to 1750 validate certificates issued in the other attached PKIs. 1752 For example, a bridge CA (BCA) CA1 1753 could cross-certify with four ^ 1754 PKIs that have the roots CA1, | 1755 CA2, CA3, and CA4. The cross- v 1756 certificates that the roots CA2 <-> BCA <-> CA3 1757 exchange with the BCA enable an ^ 1758 end entity EE1 certified under | 1759 under CA1 in PK1 to construct v 1760 a certification path needed to CA4 1761 validate the certificate of 1762 end entity EE2 under CA2, CA1 -> BCA -> CA2 -> EE2 1763 or vice versa. CA2 -> BCA -> CA1 -> EE1 1765 $ British Standard 7799 1766 (N) Part 1 of the standard is a code of practice for how to secure 1767 an information system. Part 2 specifies the management framework, 1768 objectives, and control requirements for information security 1769 management systems. [BS7799] (See: ISO 17799.) 1771 $ browser 1772 (I) An client computer program that can retrieve and display 1773 information from servers on the World Wide Web. Examples: 1775 Netscape's Navigator and Microsoft's Internet Explorer. 1777 $ brute force 1778 (I) A cryptanalysis technique or other kind of attack method 1779 involving an exhaustive procedure that tries a large number of 1780 possible solutions to the problem, one-by-one. 1782 Tutorial: In some cases, brute force involves trying all of the 1783 possibilities. For example, for cipher text where the analyst 1784 already knows the decryption algorithm, a brute force technique 1785 for finding matching plain text is to decrypt the message with 1786 every possible key. In other cases, brute force involves trying a 1787 large number of possibilities but substantially fewer than all of 1788 them. For example, given a hash function that produces a N-bit 1789 hash result, the probability is greater than 1/2 that the analyst 1790 will find two inputs that have the same hash result after trying 1791 only 2**(N/2) random chosen inputs. (See: birthday attack.) 1793 $ BS7799 1794 (N) See: British Standard 7799. 1796 $ buffer overflow 1797 (I) Any attack technique that exploits a vulnerability resulting 1798 from computer software or hardware that does not check for 1799 exceeding the bounds of a storage area when data is written into a 1800 sequence of storage locations beginning in that area. 1802 Tutorial: By causing a normal system operation to write data 1803 beyond the bounds of a storage area, the attacker seeks to either 1804 disrupt system operation or cause the system to execute malicious 1805 software inserted by the attacker. 1807 $ buffer zone 1808 (I) A neutral internetwork segment used to connect other segments 1809 that each operate under a different security policy. 1811 Tutorial: To connect a private network to the Internet or some 1812 other relatively public network, one could construct a small, 1813 separate, isolated LAN and connect it to both the private network 1814 and the public network; one or both of the connections would 1815 implement a firewall to limit the traffic that could pass through 1816 the buffer zone. 1818 $ bulk encryption 1819 (N) "Simultaneous encryption of all channels of a multichannel 1820 telecommunications link." [C4009] (Compare: bulk keying material.) 1822 $ bulk key 1823 (D) In a few published descriptions of hybrid encryption for SSH, 1824 Windows 2000, and other applications, this term refers to a 1825 symmetric key that (a) is used to encrypt a relatively large 1826 amount of data and (b) is itself encrypted with a public key. 1828 (Compare: bulk keying material.) 1830 Example: To send a large file to Bob, Alice (a) generates a 1831 symmetric key and uses it to encrypt the file (i.e., encrypt the 1832 bulk of the information that is to be sent) and then (b) encrypts 1833 that symmetric key (the "bulk key") with Bob's public key. 1835 Deprecated Term: ISDs SHOULD NOT use this term or definition; they 1836 are not well-established and could be confused with the 1837 established term "bulk keying material". Instead, use "symmetric 1838 key" and carefully explain how the key is applied. 1840 $ bulk keying material 1841 (N) Refers to handling keying material in large quantities, e.g., 1842 as a dataset that contains many items of keying material. (See: 1843 type 0. Compare: bulk key, bulk encryption.) 1845 $ bump-in-the-stack 1846 (I) An implementation approach that places a network security 1847 mechanism inside the system that is to be protected. (Compare: 1848 bump-in-the-wire.) 1850 Example: IPsec can be implemented inboard, in the protocol stack 1851 of an existing system or existing system design, by placing a new 1852 layer between the existing IP layer and the OSIRM Layer 3 drivers. 1853 Source code access for the existing stack is not required, but the 1854 system that contains the stack does need to be modified [R2401]. 1856 $ bump-in-the-wire 1857 (I) An implementation approach that places a network security 1858 mechanism outside of the system that is to be protected. (Compare: 1859 bump-in-the-stack.) 1861 Example: IPsec can be implemented outboard, in a physically 1862 separate device, so that the system that receives the IPsec 1863 protection does not need to be modified at all [R2401]. Military- 1864 grade link encryption has mainly been implemented as bump-in-the- 1865 wire devices. 1867 $ business case analysis 1868 (N) An extended form of cost-benefit analysis that considers 1869 factors beyond financial metrics, including security factors such 1870 as the requirement for security services, their technical and 1871 programmatic feasibility, their qualitative benefits, and 1872 associated risks. (See: risk analysis.) 1874 $ byte 1875 (I) A fundamental unit of computer storage; the smallest 1876 addressable unit in a computer's architecture. Usually holds one 1877 character of information and, today, usually means eight bits. 1878 (Compare: octet.) 1879 Usage: Understood to be larger than a "bit", but smaller than a 1880 "word". Although "byte" almost always means "octet" today, some 1881 computer architectures have had bytes in other sizes (e.g., six 1882 bits, nine bits). Therefore, an STD SHOULD state the number of 1883 bits in a byte where the term is first used in the STD. 1885 $ C field 1886 (D) See: Compartments field. 1888 $ C1 or C2 computer system 1889 (O) /TCSEC/ See: Tutorial under "Trusted Computer System 1890 Evaluation Criteria". 1892 $ CA 1893 (I) See: certification authority. 1895 $ CA certificate 1896 (D) "A [digital] certificate for one CA issued by another CA." 1897 [X509] 1899 Deprecated Definition: ISDs SHOULD NOT use the term with this 1900 definition; the definition is ambiguous with regard to how the 1901 certificate is constructed and how it is intended to be used. ISDs 1902 that use this term SHOULD provide a technical definition for it. 1903 (See: certificate profile.) 1905 Tutorial: There is no single, obvious choice for a technical 1906 definition of this term. Different PKIs can use different 1907 certificate profiles, and X.509 provides several choices of how to 1908 issue certificates to CAs. For example, one possible definition is 1909 the following: A v3 X.509 public-key certificate that has a 1910 "basicConstraints" extension containing a "cA" value of "TRUE". 1911 That would specifically indicate that "the certified public key 1912 may be used to verify certificate signatures", i.e., that the 1913 private key may be used by a CA. 1915 However, there also are other ways to indicate such usage. The 1916 certificate may have a "key Usage" extension that indicates the 1917 purposes for which the public key may be used, and one of the 1918 values that X.509 defines for that extension is "keyCertSign", to 1919 indicate that the certificate may be used for verifying a CA's 1920 signature on certificates. If "keyCertSign" is present in a 1921 certificate that also has a "basicConstraints" extension, than 1922 "cA" is set to "TRUE" in that extension. Alternatively, a CA could 1923 be issued a certificate in which "keyCertSign" is asserted without 1924 "basicConstraints" being present; and an entity that acts as a CA 1925 could be issued a certificate with "keyUsage" set to other values, 1926 either with or without "keyCertSign". 1928 $ Caesar cipher 1929 (I) A cipher that, given an alphabet of N characters, A(1), A(2), 1930 character A(i) by A(i+K, mod N) for some 0 one-to-many, <=> many-to-many. 6567 +- - - - - - - - - - - - - - - - - - - - - - - - - - + 6568 | PKI System | 6569 + - - - - + | +------------------+ +-------------------------+ | 6570 | User, | | |Subscriber, i.e., | | Identity of Subscriber | | 6571 |i.e., one| | | Registered User, | | is system-unique | | 6572 | of the | | | is system-unique | | +---------------------+ | | 6573 |following| | | +--------------+ | | | Subscriber | | | 6574 | | | | | User's core | | | | Identity's | | | 6575 | +-----+ |===| | Registration | |==>| | Registration data | | | 6576 | |human| | | | | data, i.e., | | | |+-------------------+| | | 6577 | |being| | | | | an entity's | | | || same core data || | | 6578 | +-----+ | | | |distinguishing|========|for all Identities || | | 6579 | or | | | | attribute | | | || of the same User || | | 6580 | +-----+ | | | | values | | +===|+-------------------+| | | 6581 | |auto-| | | | +--------------+ | | | +---------------------+ | | 6582 | |mated| | | +------------------+ | +------------|------------+ | 6583 | |pro- | | | | +=======+ | | 6584 | |cess | | | +-------v----|----------------------|------------+ | 6585 | +-----+ | | | +----------v---+ +------------v----------+ | | 6586 | or | | | |Authentication|<===>|Identifier of Identity | | | 6587 |+-------+| | | | Information | | is system-unique | | | 6588 || a set || | | +--------------+ +-----------------------+ | | 6589 || of || | | Identifier Credential that associates unit of | | 6590 || either|| | | Authentication Information with the Identifier | | 6591 |+-------+| | +------------------------------------------------+ | 6592 + - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - -+ 6594 $ identity-based security policy 6595 (I) "A security policy based on the identities and/or attributes 6596 of users, a group of users, or entities acting on behalf of the 6597 users and the resources/objects being accessed." [I7498 Part 2] 6598 (See: rule-based security policy.) 6600 $ identity proofing 6601 (I) A process that vets and verifies the information that is used 6602 to establish the identity of a system entity. (See: registration.) 6604 $ IDS 6605 (I) See: intrusion detection system. 6607 $ IEEE 6608 (N) See: Institute of Electrical and Electronics Engineers, Inc. 6610 $ IEEE 802.10 6611 (N) An IEEE committee developing security standards for local area 6612 networks. (See: SILS.) 6614 $ IEEE P1363 6615 (N) An IEEE working group, Standard for Public-Key Cryptography, 6616 engaged in developing a comprehensive reference standard for 6617 asymmetric cryptography. Covers discrete logarithm (e.g., DSA), 6618 elliptic curve, and integer factorization (e.g., RSA); and covers 6619 key agreement, digital signature, and encryption. 6621 $ IESG 6622 (I) See: Internet Engineering Steering Group. 6624 $ IETF 6625 (I) See: Internet Engineering Task Force. 6627 $ IKE 6628 (I) See: IPsec Key Exchange. 6630 $ IMAP4 6631 (I) See: Internet Message Access Protocol, version 4. 6633 $ IMAP4 AUTHENTICATE 6634 (I) A IMAP4 command (better described as a transaction type, or 6635 subprotocol) by which an IMAP4 client optionally proposes a 6636 mechanism to an IMAP4 server to authenticate the client to the 6637 server and provide other security services. (See: POP3.) 6639 Tutorial: If the server accepts the proposal, the command is 6640 followed by performing a challenge-response authentication 6641 protocol and, optionally, negotiating a protection mechanism for 6642 subsequent POP3 interactions. The security mechanisms that are 6643 used by IMAP4 AUTHENTICATE -- including Kerberos, GSSAPI, and 6644 S/Key -- are described in [R1731]. 6646 $ in the clear 6647 (I) Not encrypted. (See: clear text.) 6649 $ Ina Jo 6650 (O) A methodology, language, and integrated set of software tools 6651 developed at the System Development Corporation for specifying, 6652 coding, and verifying software to produce correct and reliable 6653 programs. Usage: a.k.a. the Formal Development Methodology. [Cheh] 6655 $ incapacitation 6656 (I) A type of threat action that prevents or interrupts system 6657 operation by disabling a system component. (See: disruption.) 6659 Usage: This type includes the following subtypes: 6660 - "Malicious logic": In context of incapacitation, any hardware, 6661 firmware, or software (e.g., logic bomb) intentionally 6662 introduced into a system to destroy system functions or 6663 resources. (See: corruption, main entry for "malicious logic", 6664 masquerade, misuse.) 6665 - "Physical destruction": Deliberate destruction of a system 6666 component to interrupt or prevent system operation. 6667 - "Human error": In context of incapacitation, action or inaction 6668 that unintentionally disables a system component. (See: 6669 corruption, exposure.) 6670 - "Hardware or software error": In context of incapacitation, 6671 error that unintentionally causes failure of a system component 6672 and leads to disruption of system operation. (See: corruption, 6673 exposure.) 6674 - "Natural disaster": In context of incapacitation, any "act of 6675 God" (e.g., fire, flood, earthquake, lightning, or wind) that 6676 disables a system component. [FP031 section 2] 6678 $ incident 6679 See: security incident. 6681 $ INCITS 6682 (N) See: "International Committee for Information Technology 6683 Standardization" under "ANSI". 6685 $ indicator 6686 (N) An action -- either specific, generalized, or theoretical -- 6687 that an adversary might be expected to take in preparation for an 6688 attack. [C4009] (See: attack sensing, warning, and response.) 6690 $ indirect certificate revocation list (ICRL) 6691 (N) In X.509, a CRL that may contain certificate revocation 6692 notifications for certificates issued by CAs other than the issuer 6693 (i.e., signer) of the ICRL. 6695 $ indistinguishability 6696 (I) An attribute of an encryption algorithm that is a 6697 formalization of the notion that the encryption of some string is 6698 indistinguishable from the encryption of an equal-length string of 6699 nonsense. (Compare: semantic security.) 6701 $ inference 6702 1. (I) A type of threat action that reasons from characteristics 6703 or byproducts of communication and thereby indirectly accesses 6704 sensitive data, but not necessarily the data contained in the 6705 communication. (See: traffic analysis, signal analysis.) 6707 2. (I) A type of threat action that indirectly gains unauthorized 6708 access to sensitive information in a database management system by 6709 correlating query responses with information that is already 6710 known. 6712 $ inference control 6713 (I) Protection of data confidentiality against inference attack. 6714 (See: traffic-flow confidentiality.) 6716 Tutorial: A database management system containing N records about 6717 individuals may be required to provide statistical summaries about 6718 subsets of the population, while not revealing sensitive 6719 information about a single individual. An attacker may try to 6720 obtain sensitive information about an individual by isolating a 6721 desired record at the intersection of a set of overlapping 6722 queries. A system can attempt to prevent this by restricting the 6723 size and overlap of query sets, distorting responses by rounding 6724 or otherwise perturbing database values, and limiting queries to 6725 random samples. However, these techniques may be impractical to 6726 implement or use, and no technique is totally effective. For 6727 example, restricting the minimum size of a query set -- that is, 6728 not responding to queries for which there are fewer than K or more 6729 than N-K records that satisfy the query -- usually cannot prevent 6730 unauthorized disclosure. An attacker can pad small query sets with 6731 extra records, and then remove the effect of the extra records. 6732 The formula for identifying the extra records is called the 6733 "tracker". [Denns] 6735 $ INFOCON 6736 (O) See: information operations condition 6738 $ informal 6739 (N) Expressed in natural language. [CCIB] (Compare: formal, 6740 semiformal.) 6742 $ information 6743 (I) Facts and ideas, which can be represented (encoded) as various 6744 forms of data. 6746 $ information assurance 6747 (N) /U.S. Government/ "Measures that protect and defend 6748 information and information systems by ensuring their availability 6749 integrity, authentication, confidentiality, and non-repudiation. 6750 These measures include providing for restoration of information 6751 systems by incorporating protection, detection, and reaction 6752 capabilities." [C4009] 6754 $ Information Assurance Technical Framework (IATF) 6755 (O) A publicly available document [IATF], developed through a 6756 collaborative effort by organizations in the U.S. Government and 6757 industry, and issued by NSA. Intended for security managers and 6758 system security engineers as a tutorial and reference document 6759 about security problems in information systems and networks, to 6760 improve awareness of tradeoffs among available technology 6761 solutions and of desired characteristics of security approaches 6762 for particular problems. (See: ISO 17799, [SP14].) 6764 $ information domain 6765 (O) See: secondary definition under "domain". 6767 $ information domain security policy 6768 (O) See: secondary definition under "domain". 6770 $ information flow policy 6771 (N) /formal model/ A triple consisting of a set of security 6772 levels (or their equivalent security labels), a binary operator 6773 that maps each pair of security levels into a security level, and 6774 a binary relation on the set that selects a set of pairs of levels 6775 such that information is permitted to flow from an object of the 6776 first level to an object of the second level. (See: flow control, 6777 lattice model.) 6779 $ information operations condition (INFOCON) 6780 (O) /U.S. DoD/ A comprehensive defense posture and response based 6781 on the status of information systems, military operations, and 6782 intelligence assessments of adversary capabilities and intent. 6783 (See: threat) 6785 Derivation: From DEFCON, i.e., defense condition. 6787 Tutorial: The U.S. DoD defines five INFOCON levels: NORMAL (normal 6788 activity), ALPHA (increased risk of attack), BRAVO (specific risk 6789 of attack), CHARLIE (limited attack), and DELTA (general attack). 6791 $ information security (INFOSEC) 6792 (N) Measures that implement and assure security services in 6793 information systems, including in computer systems (see: COMPUSEC) 6794 and in communication systems (see: COMSEC). 6796 $ information system 6797 (I) An organized assembly of computing and communication resources 6798 and procedures -- i.e., equipment and services, together with 6799 their supporting infrastructure, facilities, and personnel -- that 6800 collect, record, process, store, transport, retrieve, display, 6801 disseminate, or dispose of information to accomplish a specified 6802 set of functions. (See: system entity, system resource.) 6804 $ Information Technology Security Evaluation Criteria (ITSEC) 6805 (N) A Standard [ITSEC] jointly developed by France, Germany, the 6806 Netherlands, and the United Kingdom for use in the European Union; 6807 accommodates a wider range of security assurance and functionality 6808 combinations than the TCSEC. Superseded by the Common Criteria. 6810 $ INFOSEC 6811 (I) See: information security. 6813 $ ingress filtering 6814 (I) A method [R2827] for countering attacks that use packets with 6815 false IP source addresses, by blocking such packets at the 6816 boundary between connected networks. 6818 Tutorial: Suppose network A of an internet service provider (ISP) 6819 includes a filtering router that is connected to customer network 6820 B, and an attacker in B at IP source address "foo" attempts to 6821 send packets with false source address "bar" into A. The false 6822 address may be either fixed or randomly changing, and it may 6823 either be unreachable or be a forged address that legitimately 6824 exists within either B or some other network C. In ingress 6825 filtering, the ISP's router blocks all inbound packet that arrive 6826 from B with a source address that is not within the range of 6827 legitimately advertised addresses for B. This method does not 6828 prevent all attacks that can originate from B, but the actual 6829 source of such attacks can be more easily traced because the 6830 originating network is known. 6832 $ initialization value (IV) 6833 (I) /cryptography/ An input parameter that sets the starting state 6834 of a cryptographic algorithm or mode. 6836 Usage: Sometimes called "initialization vector" or "message 6837 indicator", but ISDs SHOULD NOT use these synonyms because they 6838 mix concepts in potentially confusing ways. 6840 Tutorial: An IV can be used to synchronize one cryptographic 6841 process with another; e.g., CBC, CFB, and OFB use IVs. An IV also 6842 can be used to introduce cryptographic variance (see: salt) in 6843 addition to that provided by a key. 6845 $ initialization vector 6846 (D) /cryptographic function/ Synonym for "initialization value". 6848 Deprecated Term: For consistency, ISDs SHOULD NOT use this term in 6849 the context of cryptographic functions. 6851 $ insertion 6852 (I) /packet/ See: secondary definition under "stream integrity 6853 service". 6855 $ inside attack 6856 (I) See: secondary definition under "attack". Compare: insider. 6858 $ insider 6859 1. (I) A user (usually a person) that accesses a system from a 6860 position that is inside the system's security perimeter. (Compare: 6861 authorized user, outsider, unauthorized user.) 6863 Tutorial: An insider has been assigned a role that has more 6864 privileges to access system resources than do some other types of 6865 users, or can access those resources without being constrained by 6866 some access controls that are applied to outside users. For 6867 example, a salesclerk is an insider who has access to the cash 6868 register, but a store customer is an outsider. 6870 The actions performed by an insider in accessing the system may be 6871 either authorized or unauthorized; i.e., an insider may act either 6872 as an authorized user or as an unauthorized user. 6874 2. (O) A person with authorized physical access to the system. 6875 Example: In this sense, an office janitor is an insider, but a 6876 burglar or casual visitor is not. [NRC98] 6878 3. (O) A person with an organizational status that causes the 6879 system or members of the organization to view access requests as 6880 being authorized. Example: In this sense, a purchasing agent is an 6881 insider but a vendor is not. [NRC98] 6883 $ inspectable space 6884 (O) /EMSEC/ "Three-dimensional space surrounding equipment that 6885 process classified and/or sensitive information within which 6886 TEMPEST exploitation is not considered practical or where legal 6887 authority to identify and/or remove a potential TEMPEST 6888 exploitation exists." [C4009] 6890 $ Institute of Electrical and Electronics Engineers, Inc. (IEEE) 6891 (N) The IEEE is a not-for-profit association of approximately 6892 300,000 individual members in 150 countries. The IEEE produces 6893 nearly one third of the world's published literature in electrical 6894 engineering, computers, and control technology; holds hundreds of 6895 major, annual conferences; and maintains more than 800 active 6896 standards, with many more under development. (See: SILS.) 6898 $ integrity 6899 See: data integrity, datagram integrity service, correctness 6900 integrity, source integrity, stream integrity service, system 6901 integrity. 6903 $ integrity check 6904 (D) A computation that is part of a mechanism to provide data 6905 integrity service or data origin authentication service. (Compare: 6906 checksum.) 6908 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 6909 "cryptographic hash" or "protected checksum. This term 6910 unnecessarily duplicates the meaning of other, well-established 6911 terms; this term only mentions integrity, even though the intended 6912 service may be data origin authentication; and not every checksum 6913 is cryptographically protected. 6915 $ integrity label 6916 (I) A security label that tells the degree of confidence that may 6917 be placed in the data, and may also tell what countermeasures are 6918 required to be applied to protect the data against from alteration 6919 and destruction. (See: integrity. Compare: classification label.) 6921 $ intelligent threat 6922 (I) A circumstance in which an adversary has the technical and 6923 operational ability to detect and exploit a vulnerability and also 6924 has the demonstrated, presumed, or inferred intent to do so. (See: 6925 threat.) 6927 $ interception 6928 (I) A type of threat action whereby an unauthorized entity 6929 directly accesses sensitive data while the data is traveling 6930 between authorized sources and destinations. (See: unauthorized 6931 disclosure.) 6933 Usage: This type includes the following subtypes: 6934 - "Theft": Gaining access to sensitive data by stealing a 6935 shipment of a physical medium, such as a magnetic tape or disk, 6936 that holds the data. 6937 - "Wiretapping (passive)": Monitoring and recording data that is 6938 flowing between two points in a communication system. (See: 6939 wiretapping.) 6940 - "Emanations analysis": Gaining direct knowledge of communicated 6941 data by monitoring and resolving a signal that is emitted by a 6942 system and that contains the data but was not intended to 6943 communicate the data. (See: emanation.) 6945 $ interference 6946 (I) /threat action/ See: secondary definition under "obstruction". 6948 $ intermediate CA 6949 (D) The CA that issues a cross-certificate to another CA. [X509] 6950 (See: cross-certification.) 6952 Deprecated Term: ISDs SHOULD NOT use this term because it is not 6953 widely known and mixes concepts in a potentially misleading way. 6954 For example, suppose that end entity 1 ("EE1) is in one PKI 6955 ("PKI1"), end entity 2 ("EE2) is in another PKI ("PKI2"), and the 6956 root in PKI1 ("CA1") cross-certifies the root CA in PKI2 ("CA2"). 6957 Then if EE1 constructs the certification path CA1-to-CA2-to-EE2 to 6958 validate a certificate of EE2, conventional English usage would 6959 describe CA2 as being in the "intermediate" position in that path, 6960 not CA1. 6962 $ internal controls 6963 (I) /computer security/ Functions, features, and technical 6964 characteristics of computer hardware and software, especially of 6965 operating systems. Includes mechanisms to regulate the operation 6966 of a computer system with regard to access control, flow control, 6967 and inference control. (Compare: external controls.) 6969 $ International Data Encryption Algorithm (IDEA) 6970 (N) A patented, symmetric block cipher that uses a 128-bit key and 6971 operates on 64-bit blocks. [Schn] (See: symmetric cryptography.) 6973 $ International Standard 6974 (N) See: secondary definition under "ISO". 6976 $ International Traffic in Arms Regulations (ITAR) 6977 (O) Rules issued by the U.S. State Department, by authority of the 6978 Arms Export Control Act (22 U.S.C. 2778), to control export and 6979 import of defense articles and defense services, including 6980 information security systems, such as cryptographic systems, and 6981 TEMPEST suppression technology. (See: type 1 product, Wassenaar 6982 Arrangement.) 6984 $ internet, Internet 6985 1. (I) /not capitalized/ Abbreviation of "internetwork". 6987 2. (I) /capitalized/ The Internet is the single, interconnected, 6988 worldwide system of commercial, government, educational, and other 6989 computer networks that share (a) the protocol suite specified by 6990 the IAB (RFC 2026) and (b) the name and address spaces managed by 6991 the ICANN. (See: Internet Layer, Internet Protocol Suite.) 6993 Usage: Use with definite article "the" when using as a noun. E.g., 6994 say "My LAN is small, but the Internet is large." Don't say "My 6995 LAN is small, but Internet is large." 6997 $ Internet Architecture Board (IAB) 6998 (I) A technical advisory group of the ISOC, chartered by the ISOC 6999 Trustees to provide oversight of Internet architecture and 7000 protocols and, in the context of Internet Standards, a body to 7001 which decisions of the IESG may be appealed. Responsible for 7002 approving appointments to the IESG from among nominees submitted 7003 by the IETF nominating committee. (RFC 2026) 7005 $ Internet Assigned Numbers Authority (IANA) 7006 (I) From the early days of the Internet, the IANA was chartered by 7007 the ISOC and the U.S. Government's Federal Network Council to be 7008 the central coordination, allocation, and registration body for 7009 parameters for Internet protocols. Superseded by ICANN. 7011 $ Internet Control Message Protocol (ICMP) 7012 (I) An Internet Standard protocol (RFC 792) that is used to report 7013 error conditions during IP datagram processing and to exchange 7014 other information concerning the state of the IP network. 7016 $ Internet Corporation for Assigned Names and Numbers (ICANN) 7017 (I) The non-profit, private corporation that has assumed 7018 responsibility for the IP address space allocation, protocol 7019 parameter assignment, DNS management, and root server system 7020 management functions formerly performed under U.S. Government 7021 contract by IANA and other entities. 7023 Tutorial: The IPS, as defined by the IETF and the IESG, contains 7024 numerous parameters, such as internet addresses, domain names, 7025 autonomous system numbers, protocol numbers, port numbers, 7026 management information base OIDs, including private enterprise 7027 numbers, and many others. The Internet community requires that the 7028 values used in these parameter fields be assigned uniquely. ICANN 7029 makes those assignments as requested and maintains a registry of 7030 the current values. 7032 ICANN was formed in October 1998, by a coalition of the Internet's 7033 business, technical, and academic communities. The U.S. Government 7034 designated ICANN to serve as the global consensus entity with 7035 responsibility for coordinating four key functions for the 7036 Internet: allocation of IP address space, assignment of protocol 7037 parameters, management of the DNS, and management of the DNS root 7038 server system. 7040 $ Internet-Draft 7041 (I) A working document of the IETF, its areas, and its working 7042 groups. (RFC 2026) 7044 Usage: The term is customarily hyphenated when used either as a 7045 adjective or a noun, even though the latter is not standard 7046 English punctuation. 7048 Tutorial: An Internet-Draft is not an archival document like an 7049 RFC is. Instead, an Internet-Draft is a preliminary or working 7050 document that is valid for a maximum of six months and may be 7051 updated, replaced, or made obsolete by other documents at any 7052 time. It is inappropriate to use an Internet Draft as reference 7053 material or to cite it other than as "work in progress". Although 7054 most of the Internet-Drafts are produced by the IETF, any 7055 interested organization may request to have its working documents 7056 published as Internet-Drafts. 7058 $ Internet Engineering Steering Group (IESG) 7059 (I) The part of the ISOC responsible for technical management of 7060 IETF activities and administration of the Internet Standards 7061 Process according to procedures approved by the ISOC Trustees. 7062 Directly responsible for actions along the "standards track", 7063 including final approval of specifications as Internet Standards. 7064 Composed of IETF Area Directors and the IETF chairperson, who also 7065 chairs the IESG. (RFC 2026) 7067 $ Internet Engineering Task Force (IETF) 7068 (I) A self-organized group of people who make contributions to the 7069 development of Internet technology. The principal body engaged in 7070 developing Internet Standards, although not itself a part of the 7071 ISOC. Composed of Working Groups, which are arranged into Areas 7072 (such as the Security Area), each coordinated by one or more Area 7073 Directors. Nominations to the IAB and the IESG are made by a 7074 committee selected at random from regular IETF meeting attendees 7075 who have volunteered. (RFC 2026) [RFC 2323] 7077 $ Internet Layer 7078 (I) See: Internet Protocol Suite. 7080 $ Internet Message Access Protocol, version 4 (IMAP4) 7081 (I) An Internet protocol (RFC 2060) by which a client workstation 7082 can dynamically access a mailbox on a server host to manipulate 7083 and retrieve mail messages that the server has received and is 7084 holding for the client. (See: POP3.) 7086 Tutorial: IMAP4 has mechanisms for optionally authenticating a 7087 client to a server and providing other security services. (See: 7088 IMAP4 AUTHENTICATE.) 7090 $ Internet Open Trading Protocol (IOTP) 7091 (I) An Internet protocol (RFC 2801) proposed as a general 7092 framework for Internet commerce, able to encapsulate transactions 7093 of various proprietary payment systems (e.g., GeldKarte, Mondex, 7094 SET, VisaCash). Provides optional security services by 7095 incorporating various Internet security mechanisms (e.g., MD5) and 7096 protocols (e.g., TLS). 7098 $ Internet Policy Registration Authority (IPRA) 7099 (I) An X.509-compliant CA that is the top CA of the Internet 7100 certification hierarchy operated under the auspices of the ISOC 7101 [R1422]. (See: /PEM/ under "certification hierarchy".) 7103 $ Internet Private Line Interface (IPLI) 7104 (O) A successor to the PLI, updated to use TCP/IP and newer 7105 military-grade COMSEC equipment (TSEC/KG-84). The IPLI was a 7106 portable, modular system that was developed for use in tactical, 7107 packet-radio networks. 7109 $ Internet Protocol (IP) 7110 (I) A Internet Standard, Internet-Layer protocol that moves 7111 datagrams (discrete sets of bits) from one computer to another 7112 across an internetwork but does not provide reliable delivery, 7113 flow control, sequencing, or other end-to-end services that TCP 7114 provides. IP version 4 (IPv4) is specified in RFC 791, and IP 7115 version 6 (IPv6) is specified in RFC 2460. (See: IP address, 7116 TCP/IP.) 7118 Tutorial: If IP were used in an OSIRM stack, IP would be placed at 7119 the top of Layer 3, above other Layer 3 protocols in the stack. 7121 In any IPS stack, IP is always present in the Internet Layer and 7122 is always placed at the top of that layer, on top of any other 7123 protocols that are used in that layer. In some sense, IP is the 7124 only protocol specified for the IPS Internet Layer; other 7125 protocols used there, such as AH and ESP, are just IP variations. 7127 $ Internet Protocol security 7128 See: IPsec. 7130 $ Internet Protocol Security Option (IPSO) 7131 (I) Refers to one of three types of IP security options, which are 7132 fields that may be added to an IP datagram for the purpose of 7133 carrying security information about the datagram. (Compare: 7134 IPsec.) 7136 Deprecated Usage: ISDs SHOULD NOT use this term without a modifier 7137 to indicate which of the following three types is meant. 7138 - "DoD Basic Security Option" (IP option type 130): Defined for 7139 use on U.S. DoD common-use data networks. Identifies the DoD 7140 classification level at which the datagram is to be protected 7141 and the protection authorities whose rules apply to the 7142 datagram. (A "protection authority" is a National Access 7143 Program (e.g., GENSER, SIOP-ESI, SCI, NSA, Department of 7144 Energy) or Special Access Program that specifies protection 7145 rules for transmission and processing of the information 7146 contained in the datagram.) [R1108] 7147 - "DoD Extended Security Option" (IP option type 133): Permits 7148 additional security labeling information, beyond that present 7149 in the Basic Security Option, to be supplied in the datagram to 7150 meet the needs of registered authorities. [R1108] 7151 - "Common IP Security Option" (CIPSO) (IP option type 134): 7152 Designed by TSIG to carry hierarchic and non-hierarchic 7153 security labels. (Formerly called "Commercial IP Security 7154 Option"; a version 2.3 draft was published 9 March 1993 as an 7155 Internet-Draft but did not advance to RFC form.) [CIPSO] 7157 $ Internet Protocol Suite (IPS) 7158 (I) The set of network communication protocols that are specified 7159 by the IETF, and approved as Internet Standards by the IESG, 7160 within the oversight of the IAB. (See: OSIRM Security 7161 Architecture. Compare: OSIRM.) 7163 Usage: This set of protocols is popularly known as "TCP/IP" 7164 because TCP and IP are its most basic and important components. 7166 For clarity, this Glossary refers to IPS protocol layers by name 7167 and capitalizes those names, and refers to OSIRM protocol layers 7168 by number. 7170 Tutorial: The IPS does have architectural principles [R1958], but 7171 there is no Internet Standard that defines a layered IPS reference 7172 model like the OSIRM. Still, Internet community literature has 7173 referred (inconsistently) to IPS layers since early in the 7174 Internet's development [Padl]. 7176 This Glossary treats the IPS as having five protocol layers -- 7177 Application, Transport, Internet, Network Interface, and Network 7178 Hardware (or Network Substrate) -- which are illustrated in the 7179 following diagram: 7181 OSIRM Layers Examples IPS Layers Examples 7182 ------------------ --------------- --------------- -------------- 7183 Message Format: P2 [X420] Message Format: ARPA (RFC 822) 7184 +----------------+ +-------------+ 7185 |7.Application | P1 [X419] | Application | SMTP (RFC 821) 7186 +----------------+ - - - - - - | | 7187 |6.Presentatation| [I8823] | | 7188 +----------------+ - - - - - - | | 7189 |5.Session | [I8327] +-------------+ 7190 +----------------+ - - - - - - | Transport | TCP (RFC 793) 7191 |4.Transport | TP4 [I8073] | | 7192 +----------------+ - - - - - - +-------------+ 7193 |3.Network | CLNP [I8473] | Internet | IP (RFC 791) 7194 | | +-------------+ 7195 | | | Network | IP over IEEE 7196 +----------------+ - - - - - - | Interface | 802 (RFC 1042) 7197 |2.Data Link | +-------------+ 7198 | | LLC [I8802-2] - Network - The IPS does 7199 | | MAC [I8802-3] - Hardware - not include 7200 +----------------+ - (or Network - standards for 7201 |1.Physical | Baseband - Substrate) - this layer. 7202 +----------------+ Signaling [Stal] + - - - - - - + 7204 The diagram approximates how the five IPS layers align with the 7205 seven OSIRM layers, and it offers examples of protocol stacks that 7206 provide roughly equivalent electronic mail service over a private 7207 local area network that uses baseband signaling. 7209 - IPS Application Layer: The user runs an application program. 7210 The program selects the data transport service it needs -- 7211 either a sequence of data messages or a continuous stream of 7212 data -- and hands application data to the Transport Layer for 7213 delivery. 7215 - IPS Transport Layer: This layer divides application data into 7216 packets, adds a destination address to each, and communicates 7217 them end-to-end -- from one application program to another -- 7218 optionally regulating the flow and ensuring reliable (error- 7219 free and sequenced) delivery. 7221 - IPS Internet Layer: This layer carries transport packets in IP 7222 datagrams. It moves each datagram independently, from its 7223 source computer to its addressed destination computer, routing 7224 the datagram through a sequence of networks and relays and 7225 selecting appropriate network interfaces en route. 7227 - IPS Network Interface Layer: This layer accepts datagrams for 7228 transmission over a specific network. This layer specifies 7229 interface conventions for carrying IP over OSIRM Layer 3 7230 protocols and over Media Access Control sublayer protocols of 7231 OSIRM Layer 2. An example is IP over IEEE 802 (RFD 1042). 7233 - IPS Network Hardware Layer: This layer consists of specific, 7234 physical communication media. However, the IPS does not specify 7235 its own peer-to-peer protocols in this layer. Instead, the 7236 layering conventions specified by the Network Interface Layer 7237 use Layer 2 and Layer 3 protocols that are specified by bodies 7238 other than the IETF. That it, the IPS addresses *inter*-network 7239 functions and does not address *intra*-network functions. 7241 The two models are most dissimilar in the upper layers, where the 7242 IPS model does not include Session and Presentation layers. 7243 However, this omission causes fewer functional differences between 7244 the models than might be imagined, and the differences have 7245 relatively few security implications: 7247 - Formal separation of OSIRM Layers 5, 6, and 7 is not needed in 7248 implementations; the functions of these layers sometimes are 7249 mixed in a single software unit, even in protocols in the OSI 7250 suite. 7252 - Some OSIRM Layer 5 services -- for example, connection 7253 termination -- are built into TCP, and the remaining Layer 5 7254 and 6 functions are built into IPS Application-Layer protocols 7255 where needed. 7257 - The OSIRM does not place any security services in Layer 5 (see: 7258 OSIRM Security Architecture). 7260 - The lack of an explicit Presentation Layer in the IPS sometimes 7261 makes it simpler to implement security in IPS applications. For 7262 example, a primary function of Layer 6 is to convert data 7263 between internal and external forms, using a transfer syntax to 7264 unambiguously encode data for transmission. If an OSIRM 7265 application encrypts data to protect against disclosure during 7266 transmission, the transfer encoding must be done before the 7267 encryption. If an application does encryption, as is done in 7268 OSI message handling and directory service protocols, then 7269 Layer 6 functions must be replicated in Layer 7. [X400, X500]. 7271 The two models are most alike at the top of OSIRM Layer 3, where 7272 the OSI Connectionless Network Layer Protocol (CLNP) and the IPS 7273 IP are quite similar. Connection-oriented security services 7274 offered in OSIRM Layer 3 are inapplicable in the IPS, because the 7275 IPS Internet Layer lacks the explicit, connection-oriented service 7276 offered in the OSIRM. 7278 $ Internet Security Association and Key Management Protocol (ISAKMP) 7279 (I) An Internet IPsec protocol [R2408] to negotiate, establish, 7280 modify, and delete security associations, and to exchange key 7281 generation and authentication data, independent of the details of 7282 any specific key generation technique, key establishment protocol, 7283 encryption algorithm, or authentication mechanism. 7285 Tutorial: ISAKMP supports negotiation of security associations for 7286 protocols at all IPS layers. By centralizing management of 7287 security associations, ISAKMP reduces duplicated functionality 7288 within each protocol. ISAKMP can also reduce connection setup 7289 time, by negotiating a whole stack of services at once. Strong 7290 authentication is required on ISAKMP exchanges, and a digital 7291 signature algorithm based on asymmetric cryptography is used 7292 within ISAKMP's authentication component. 7294 ISAKMP negotiations are conducted in two "phases": 7295 - "Phase 1 negotiation". A phase 1 negotiation establishes a 7296 security association to be used by ISAKMP to protect its own 7297 protocol operations. 7298 - "Phase 2 negotiation". A phase 2 negotiation (which is 7299 protected by a security association that was established by a 7300 phase 1 negotiation) establishes a security association to be 7301 used to protect the operations of a protocol other than ISAKMP, 7302 such as ESP. 7304 $ Internet Society (ISOC) 7305 (I) A professional society concerned with Internet development 7306 (including technical Internet Standards); with how the Internet is 7307 and can be used; and with social, political, and technical issues 7308 that result. The ISOC Board of Trustees approves appointments to 7309 the IAB from among nominees submitted by the IETF nominating 7310 committee. (RFC 2026) 7312 $ Internet Standard 7313 (I) A specification, approved by the IESG and published as an RFC, 7314 that is stable and well-understood, is technically competent, has 7315 multiple, independent, and interoperable implementations with 7316 substantial operational experience, enjoys significant public 7317 support, and is recognizably useful in some or all parts of the 7318 Internet. (RFC 2026) (Compare: RFC.) 7320 Tutorial: The "Internet Standards Process" is an activity of the 7321 ISOC and is organized and managed by the IAB and the IESG. The 7322 process is concerned with all protocols, procedures, and 7323 conventions used in or by the Internet, whether or not they are 7324 part of the IPS. The "Internet Standards Track" has three levels 7325 of increasing maturity: Proposed Standard, Draft Standard, and 7326 Standard. (Compare: ISO, W3C.) 7328 $ Internet Standards document (ISD) 7329 (I) An RFC or an Internet-Draft that is produced as part of the 7330 Internet Standards Process (RFC 2026). (See: Internet Standard.) 7332 Deprecated Usage: ISDs that use this term SHOULD state a 7333 definition for it because neither the term nor the abbreviation is 7334 widely accepted. 7336 $ internetwork 7337 (I) A system of interconnected networks; a network of networks. 7338 Usually shortened to "internet". (See: internet, Internet.) 7340 Tutorial: An internet can be built using OSIRM Layer 3 gateways to 7341 implement connections between a set of similar subnetworks. With 7342 dissimilar subnetworks, i.e., subnetworks that differ in the Layer 7343 3 protocol service they offer, an internet can be built by 7344 implementing a uniform internetwork protocol (e.g., IP) that 7345 operates at the top of Layer 3 and hides the underlying 7346 subnetworks' heterogeneity from hosts that use communication 7347 services provided by the internet. (See: router.) 7349 $ intranet 7350 (I) A computer network, especially one based on Internet 7351 technology, that an organization uses for its own internal (and 7352 usually private) purposes and that is closed to outsiders. (See: 7353 extranet, virtual private network.) 7355 $ intruder 7356 (I) An entity that gains or attempts to gain access to a system or 7357 system resource without having authorization to do so. (See: 7358 intrusion. Compare: adversary, cracker.) 7360 $ intrusion 7361 1. (I) A security event, or a combination of multiple security 7362 events, that constitutes a security incident in which an intruder 7363 gains, or attempts to gain, access to a system or system resource 7364 without having authorization to do so. (See: IDS.) 7366 2. (I) A type of threat action whereby an unauthorized entity 7367 gains access to sensitive data by circumventing a system's 7368 security protections. (See: unauthorized disclosure.) 7370 Usage: This type includes the following subtypes: 7371 - "Trespass": Gaining physical access to sensitive data by 7372 circumventing a system's protections. 7373 - "Penetration": Gaining logical access to sensitive data by 7374 circumventing a system's protections. 7375 - "Reverse engineering": Acquiring sensitive data by 7376 disassembling and analyzing the design of a system component. 7377 - "Cryptanalysis": Transforming encrypted data into plain text 7378 without having prior knowledge of encryption parameters or 7379 processes. (See: main entry for "cryptanalysis".) 7381 $ intrusion detection 7382 (I) Sensing and analyzing system events for the purpose of 7383 noticing (i.e., becoming aware of) attempts to access system 7384 resources in an unauthorized manner. (See: anomaly detection, IDS, 7385 misuse detection.) [IDSAN, IDSSC, IDSSE, IDSSY] 7387 Usage: This includes the following subtypes: 7388 - "Active detection": Real-time or near-real-time analysis of 7389 system event data to detect current intrusions, which result in 7390 an immediate protective response. 7391 - "Passive detection": Off-line analysis of audit data to detect 7392 past intrusions, which are reported to the system security 7393 officer for corrective action. (Compare: security audit.) 7395 $ intrusion detection system (IDS) 7396 1. (N) A process or subsystem, implemented in software or 7397 hardware, that automates the tasks of (a) monitoring events that 7398 occur in a computer network and (b) analyzing them for signs of 7399 security problems. [SP31] (See: intrusion detection.) 7401 2. (N) A security alarm system to detect unauthorized entry. 7402 [DC6/9]. 7404 Tutorial: Active intrusion detection processes can be either host- 7405 based or network-based: 7406 - "Host-based": Intrusion detection components -- traffic sensors 7407 and analyzers -- run directly on the hosts that they are 7408 intended to protect. 7409 - "Network-based": Sensors are placed on subnetwork components, 7410 and analysis components run either on subnetwork components or 7411 hosts. 7413 $ invalidity date 7414 (N) An X.509 CRL entry extension that "indicates the date at which 7415 it is known or suspected that the [revoked certificate's private 7416 key] was compromised or that the certificate should otherwise be 7417 considered invalid." [X509]. 7419 Tutorial: This date may be earlier than the revocation date in the 7420 CRL entry, and may even be earlier than the date of issue of 7421 earlier CRLs. However, the invalidity date is not, by itself, 7422 sufficient for purposes of non-repudiation service. For example, 7423 to fraudulently repudiate a validly generated signature, a private 7424 key holder may falsely claim that the key was compromised at some 7425 time in the past. 7427 $ IOTP 7428 (I) See: Internet Open Trading Protocol. 7430 $ IP 7431 (I) See: Internet Protocol. 7433 $ IP address 7434 (I) A computer's internetwork address that is assigned for use by 7435 IP and other protocols. 7437 Tutorial: An IP version 4 address (RFC 791) has four 8-bit parts 7438 and is written as a series of four decimal numbers separated by 7439 periods. Example: The address of the host named "rosslyn.bbn.com" 7440 is 192.1.7.10. 7442 An IP version 6 address (RFC 2373) has eight 16-bit parts and is 7443 written as eight hexadecimal numbers separated by colons. 7444 Examples: 1080:0:0:0:8:800:200C:417A and 7445 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210. 7447 $ IP Security Option 7448 (I) See: Internet Protocol Security Option. 7450 $ IP Security Protocol (IPsec) 7451 1a. (I) The name of the IETF working group that is specifying an 7452 architecture [R2401] and set of protocols to provide security 7453 services for IP traffic. (See: AH, ESP, IKE, SAD, SPD. Compare: 7454 IPSO.) 7456 1b. (I) A collective name for the IP security architecture and 7457 associated set of protocols (primarily AH, ESP, and IKE). 7459 Usage: Note that the letters "sec" are in lower case in "IPsec". 7461 Tutorial: The security services provided by IPsec include access 7462 control service, connectionless data integrity service, data 7463 origin authentication service, protection against replays 7464 (detection of the arrival of duplicate datagrams, within a 7465 constrained window), data confidentiality service, and limited 7466 traffic-flow confidentiality. IPsec specifies (a) security 7467 protocols (AH and ESP), (b) security associations (what they are, 7468 how they work, how they are managed, and associated processing), 7469 (c) key management (IKE), and (d) algorithms for authentication 7470 and encryption. Implementation of IPsec is optional for IP version 7471 4, but mandatory for IP version 6. 7473 $ IPLI 7474 (I) See: Internet Private Line Interface. 7476 $ IPRA 7477 (I) See: Internet Policy Registration Authority. 7479 $ IPS 7480 (I) See: Internet Protocol Suite. 7482 $ IPsec 7483 (I) See: IP Security Protocol. 7485 $ IPsec Key Exchange (IKE) 7486 (I) An Internet, IPsec, key-establishment protocol [R2409] for 7487 putting in place authenticated keying material (a) for use with 7488 ISAKMP and (b) for other security associations, such as in AH and 7489 ESP. 7491 Tutorial: IKE is based on three earlier protocol designs: ISAKMP, 7492 OAKLEY, and SKEME. 7494 $ IPSO 7495 (I) See: Internet Protocol Security Option. 7497 $ ISAKMP 7498 (I) See: Internet Security Association and Key Management 7499 Protocol. 7501 $ ISD 7502 (I) See: Internet Standards document. 7504 $ ISO 7505 (I) International Organization for Standardization, a voluntary, 7506 non-treaty, non-government organization, established in 1947, with 7507 voting members that are designated standards bodies of 7508 participating nations and non-voting observer organizations. 7509 (Compare: ANSI, IETF, ITU-T, W3C.) 7511 Tutorial: Legally, ISO is a Swiss, non-profit, private 7512 organization. ISO and the IEC (the International Electrotechnical 7513 Commission) form the specialized system for worldwide 7514 standardization. National bodies that are members of ISO or IEC 7515 participate in developing international standards through ISO and 7516 IEC technical committees that deal with particular fields of 7517 activity. Other international governmental and non-governmental 7518 organizations, in liaison with ISO and IEC, also take part. (ANSI 7519 is the U.S. voting member of ISO. ISO is a class D member of 7520 ITU-T.) 7522 The ISO standards development process has four levels of 7523 increasing maturity: Working Draft (WD), Committee Draft (CD), 7524 Draft International Standard (DIS), and International Standard 7525 (IS). (Compare: "Internet Standards Track" under "Internet 7526 Standard".) In information technology, ISO and IEC have a joint 7527 technical committee, ISO/IEC JTC 1. DISs adopted by JTC 1 are 7528 circulated to national bodies for voting, and publication as an IS 7529 requires approval by at least 75% of the national bodies casting a 7530 vote. 7532 $ ISO 17799 7533 (N) An International Standard that is a code of practice, derived 7534 from Part 1 of British Standard 7799, for managing the security of 7535 information systems in an organization. This standard does not 7536 provide definitive or specific material on any security topic. It 7537 provides general guidance on a wide variety of topics, but 7538 typically does not go into depth. (See: IATF, [SP14].) 7540 $ ISOC 7541 (I) See: Internet Society. 7543 $ issue (a digital certificate or CRL) 7544 (I) Generate and sign a digital certificate (or CRL) and, usually, 7545 distribute it and make it available to potential certificate users 7546 (or CRL users). (See: certificate creation.) 7548 Usage: The ABA Guidelines [ABA] explicitly limit this term to 7549 certificate creation, and exclude the act of publishing. In 7550 general usage, however, "issuing" a digital certificate (or CRL) 7551 includes not only certificate creation but also making it 7552 available to potential users, such as by storing it in a 7553 repository or other directory or otherwise publishing it. 7555 $ issuer 7556 1. (I) /certificate, CRL/ The CA that signs a digital certificate 7557 or CRL. 7559 Tutorial: An X.509 certificate always includes the issuer's name. 7560 The name may include a common name value. 7562 2. (O) /payment card, SET/ "The financial institution or its agent 7563 that issues the unique primary account number to the cardholder 7564 for the payment card brand." [SET2] 7566 Tutorial: The institution that establishes the account for a 7567 cardholder and issues the payment card also guarantees payment for 7568 authorized transactions that use the card in accordance with card 7569 brand regulations and local legislation. [SET1] 7571 $ ITAR 7572 (O) See: International Traffic in Arms Regulations. 7574 $ ITSEC 7575 (N) See: Information Technology System Evaluation Criteria. 7577 $ ITU-T 7578 (N) International Telecommunications Union, Telecommunication 7579 Standardization Sector (formerly "CCITT"), a United Nations treaty 7580 organization that is composed mainly of postal, telephone, and 7581 telegraph authorities of the member countries and that publishes 7582 standards called "Recommendations". (See: X.400, X.500.) 7584 Tutorial: The Department of State represents the United States. 7585 ITU-T works on many kinds of communication systems. ITU-T 7586 cooperates with ISO on communication protocol standards, and many 7587 Recommendations in that area are also published as an ISO standard 7588 with an ISO name and number. 7590 $ IV 7591 (I) See: initialization value. 7593 $ jamming 7594 (I) An attack that attempts to interfere with the reception of 7595 broadcast communications. (See: anti-jam, denial of service. 7596 Compare: flooding.) 7598 Tutorial: Jamming uses "interference" as a type of "obstruction" 7599 intended to cause "disruption". Jamming a broadcast signal is 7600 typically done by broadcasting a second signal that receivers 7601 cannot separate from the first one. Jamming is mainly thought of 7602 in the context of wireless communication, but also can be done in 7603 some wired technologies, such as LANs that use contention 7604 techniques to share a broadcast medium. 7606 $ KAK 7607 (D) See: key-auto-key. (Compare: KEK.) 7609 $ KDC 7610 (I) See: Key Distribution Center. 7612 $ KEA 7613 (N) See: Key Exchange Algorithm. 7615 $ KEK 7616 (I) See: key-encrypting key. (Compare: KAK.) 7618 $ Kerberos 7619 (N) A system developed at the Massachusetts Institute of 7620 Technology that depends on passwords and symmetric cryptography 7621 (DES) to implement ticket-based, peer entity authentication 7622 service and access control service distributed in a client-server 7623 network environment. [R1510, Stei] 7625 Tutorial: Kerberos was developed by Project Athena and is named 7626 for the mythical three-headed dog that guards Hades. The system 7627 architecture includes servers that function as an ACC and a KDC. 7629 $ kernel 7630 (I) A small, trusted part of a system that provides services on 7631 which the other parts of the system depend. (See: security 7632 kernel.) 7634 $ Kernelized Secure Operating System (KSOS) 7635 (O) An MLS computer operating system, designed to be a provably 7636 secure replacement for UNIX Version 6, and consisting of a 7637 security kernel, non-kernel security-related utility programs, and 7638 optional UNIX application development and support environments. 7639 [Perr] 7641 Tutorial: KSOS-6 was the implementation on a SCOMP. KSOS-11 was 7642 the implementation by Ford Aerospace and Communications 7643 Corporation on the DEC PDP-11/45 and PDP-111/70 computers. 7645 $ key 7646 1. (I) /cryptography/ An input parameter used to vary a 7647 transformation function performed by a cryptographic algorithm. 7648 (See: private key, public key, storage key, symmetric key, traffic 7649 key. Compare: initialization value.) 7651 2. (I) /anti-jam/ An input parameter used to vary a process that 7652 determines patterns for an anti-jam measure. (See: frequency 7653 hopping, spread spectrum.) 7655 Tutorial: A key is usually specified as a sequence of bits or 7656 other symbols. If a key value needs to be kept secret, the 7657 sequence of symbols that comprise it should be random, or at least 7658 pseudorandom, because that makes the key harder for an adversary 7659 to guess. (See: brute force attack, cryptanalysis, strength.) 7661 $ key agreement (algorithm or protocol) 7662 1. (I) A key establishment method (especially one involving 7663 asymmetric cryptography) by which two or more entities, without 7664 prior arrangement except a public exchange of data (such as public 7665 keys), each can generate the same key value. That is, the method 7666 does not send a secret from one entity to the other; instead, both 7667 entities, without prior arrangement except a public exchange of 7668 data, can compute the same secret value, but that value cannot be 7669 computed by other, unauthorized entities. (See: Diffie-Hellman, 7670 key establishment, KEA, MQV. Compare: key transport.) 7672 2. (O) "A method for negotiating a key value on line without 7673 transferring the key, even in an encrypted form, e.g., the Diffie- 7674 Hellman technique." [X509] 7676 3. (O) "The procedure whereby two different parties generate 7677 shared symmetric keys such that any of the shared symmetric keys 7678 is a function of the information contributed by all legitimate 7679 participants, so that no party [alone] can predetermine the value 7680 of the key." [A9042] 7682 Example: A message originator and the intended recipient can each 7683 use their own private key and the other's public key with the 7684 Diffie-Hellman algorithm to first compute a shared secret value 7685 and, from that value, derive a session key to encrypt the message. 7687 $ key authentication 7688 (N) "The assurance of the legitimate participants in a key 7689 agreement [i.e., in a key-agreement protocol] that no non- 7690 legitimate party possesses the shared symmetric key." [A9042] 7692 $ key-auto-key (KAK) 7693 (D) "Cryptographic logic [i.e., a mode of operation] using 7694 previous key to produce key." [C4009, A1523] (See: CTAK, 7695 /cryptographic operation/ under "mode".) 7697 Deprecated Term: IDS SHOULD NOT use this term; it is neither well- 7698 known nor precisely defined. Instead, use terms associated with 7699 modes that are defined in standards, such as CBC, CFB, and OFB. 7701 $ key center 7702 (I) A centralized, key-distribution process (used in symmetric 7703 cryptography), usually a separate computer system, that uses 7704 master keys (i.e., KEKs) to encrypt and distribute session keys 7705 needed by a community of users. 7707 Tutorial: An ANSI standard [A9017] defines two types of key 7708 center: "key distribution center" and "key translation center". 7710 $ key confirmation 7711 (N) "The assurance [provided to] the legitimate participants in a 7712 key establishment protocol that the [parties that are intended to 7713 share] the symmetric key actually possess the shared symmetric 7714 key." [A9042] 7716 $ key distribution 7717 (I) A process that delivers a cryptographic key from the location 7718 where it is generated to the locations where it is used in a 7719 cryptographic algorithm. (See: key establishment, key management.) 7721 $ key distribution center (KDC) 7722 1. (I) A type of key center (used in symmetric cryptography) that 7723 implements a key-distribution protocol to provide keys (usually, 7724 session keys) to two (or more) entities that wish to communicate 7725 securely. (Compare: key translation center.) 7727 2. (N) "COMSEC facility generating and distributing key in 7728 electrical form." [C4009] 7730 Tutorial: A KDC distributes keys to Alice and Bob, who (a) wish to 7731 communicate with each other but do not currently share keys, (b) 7732 each share a KEK with the KDC, and (c) may not be able to generate 7733 or acquire keys by themselves. Alice requests the keys from the 7734 KDC. The KDC generates or acquires the keys and makes two 7735 identical sets. The KDC encrypts one set in the KEK it shares with 7736 Alice, and sends that encrypted set to Alice. The KDC encrypts the 7737 second set in the KEK it shares with Bob, and either (a) sends 7738 that encrypted set to Alice for her to forward to Bob or (b) sends 7739 it directly to Bob (although the latter option is not supported in 7740 the ANSI standard [A9017]). 7742 $ key encapsulation 7743 (N) A key recovery technique for storing knowledge of a 7744 cryptographic key by encrypting it with another key and ensuring 7745 that that only certain third parties called "recovery agents" can 7746 perform the decryption operation to retrieve the stored key. Key 7747 encapsulation typically permits direct retrieval of a secret key 7748 used to provide data confidentiality. (Compare: key escrow.) 7750 $ key-encrypting key (KEK) 7751 (I) A cryptographic key that (a) is used to encrypt other keys 7752 (either DEKs or other TEKs) for transmission or storage but (b) 7753 usually is not used to encrypt application data. Usage: Sometimes 7754 called "key-encryption key". 7756 $ key escrow 7757 (N) A key recovery technique for storing knowledge of a 7758 cryptographic key or parts thereof in the custody of one or more 7759 third parties called "escrow agents", so that the key can be 7760 recovered and used in specified circumstances. (Compare: key 7761 encapsulation.) 7763 Tutorial: Key escrow is typically implemented with split knowledge 7764 techniques. For example, the Escrowed Encryption Standard [FP185] 7765 entrusts two components of a device-unique split key to separate 7766 escrow agents. The agents provide the components only to someone 7767 legally authorized to conduct electronic surveillance of 7768 telecommunications encrypted by that specific device. The 7769 components are used to reconstruct the device-unique key, and it 7770 is used to obtain the session key needed to decrypt 7771 communications. 7773 $ key establishment (algorithm or protocol) 7774 1. (I) A procedure that combines the key generation and key- 7775 distribution steps needed to set up or install a secure 7776 communication association. 7778 2. (I) A procedure that results in keying material being shared 7779 among two or more system entities. [A9042, SP56] 7781 Tutorial: The two basic techniques for key establishment are "key 7782 agreement" and "key transport". 7784 $ Key Exchange Algorithm (KEA) 7785 (N) A key-agreement method [SKIP, R2773] that is based on the 7786 Diffie-Hellman algorithm and uses 1024-bit asymmetric keys. (See: 7787 CAPSTONE, CLIPPER, FORTEZZA, SKIPJACK.) 7789 Tutorial: KEA was developed by NSA and formerly classified at the 7790 U.S. DoD "Secret" level. On 23 June 1998, the NSA announced that 7791 KEA had been declassified. 7793 $ key generation 7794 (I) A process that creates the sequence of symbols that comprise a 7795 cryptographic key. (See: key management.) 7797 $ key generator 7798 1. (I) An algorithm that uses mathematical rules to 7799 deterministically produce a pseudorandom sequence of cryptographic 7800 key values. 7802 2. (I) An encryption device that incorporates a key generation 7803 mechanism and applies the key to plain text to produce cipher text 7804 (e.g., by exclusive OR-ing (a) a bit string representation of the 7805 key with (b) a bit string representation of the plaintext). 7807 $ key length 7808 (I) The number of symbols (usually stated as a number of bits) 7809 needed to be able to represent any of the possible values of a 7810 cryptographic key. (See: key space.) 7812 $ key lifetime 7813 1. (D) Synonym for "cryptoperiod". 7815 Deprecated Definition: ISDs SHOULD NOT use this term with this 7816 definition because a key's cryptoperiod may be only a part of the 7817 key's lifetime. A key could be generated at some time prior to 7818 when its cryptoperiod begins and might not be destroyed (i.e., 7819 zeroized) until some time after its cryptoperiod ends. 7821 2. (O) /MISSI/ An attribute of a MISSI key pair that specifies a 7822 time span that bounds the validity period of any MISSI X.509 7823 public-key certificate that contains the public component of the 7824 pair. (See: cryptoperiod.) 7826 $ key loader 7827 (N) Synonym for "fill device". 7829 $ key management 7830 1a. (I) The process of handling keying material during its life 7831 cycle in a cryptographic system; and the supervision and control 7832 of that process. (See: key distribution, key escrow, keying 7833 material, public-key infrastructure.) 7835 Usage: Usually understood to include ordering, generating, 7836 storing, archiving, escrowing, distributing, loading, destroying, 7837 auditing, and accounting for the material. 7839 1b. (O) /NIST/ "The activities involving the handling of 7840 cryptographic keys and other related security parameters (e.g., 7841 IVs, counters) during the entire life cycle of the keys, including 7842 their generation, storage, distribution, entry and use, deletion 7843 or destruction, and archiving." [FP140, SP57] 7844 2. (O) /OSIRM/ "The generation, storage, distribution, deletion, 7845 archiving and application of keys in accordance with a security 7846 policy." [I7498 Part 2] 7848 $ Key Management Protocol (KMP) 7849 (N) A protocol to establish a shared symmetric key between a pair 7850 (or a group) of users. (One version of KMP was developed by SDNS, 7851 and another by SILS.) Superseded by ISAKMP and IKE. 7853 $ key material 7854 (D) A synonym for "keying material". 7856 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 7857 "keying material". 7859 $ key pair 7860 (I) A set of mathematically related keys -- a public key and a 7861 private key -- that are used for asymmetric cryptography and are 7862 generated in a way that makes it computationally infeasible to 7863 derive the private key from knowledge of the public key. (See: 7864 Diffie-Hellman, RSA.) 7866 Tutorial: A key pair's owner discloses the public key to other 7867 system entities so they can use the key to (a) encrypt data, (b) 7868 verify a digital signature, or (c) generate a key with a key- 7869 agreement algorithm. The matching private key is kept secret by 7870 the owner, who uses it to (a') decrypt data, (b') generate a 7871 digital signature, or (c') generate a key with a key-agreement 7872 algorithm. 7874 $ key recovery 7875 1. (I) /cryptanalysis/ A process for learning the value of a 7876 cryptographic key that was previously used to perform some 7877 cryptographic operation. (See: cryptanalysis, recovery.) 7879 2. (I) /backup/ Techniques that provide an intentional, alternate, 7880 means to access the key used for data confidentiality service in 7881 an encrypted association. [DoD4] (Compare: recovery.) 7883 Tutorial: It is assumed that the cryptographic system includes a 7884 primary means of obtaining the key through a key establishment 7885 algorithm or protocol. For the secondary means, there are two 7886 classes of key recovery techniques: key encapsulation and key 7887 escrow. 7889 $ key space 7890 (I) The range of possible values of a cryptographic key; or the 7891 number of distinct transformations supported by a particular 7892 cryptographic algorithm. (See: key length.) 7894 $ key translation center 7895 (I) A type of key center that implements a key-distribution 7896 protocol (based on symmetric cryptography) to convey keys between 7897 two (or more) parties who wish to communicate securely. (Compare: 7898 key distribution center.) 7900 Tutorial: A key translation center transfers keys for future 7901 communication between Bob and Alice, who (a) wish to communicate 7902 with each other but do not currently share keys, (b) each share a 7903 KEK with the center, and (c) have the ability to generate or 7904 acquire keys by themselves. Alice generates or acquires a set of 7905 keys for communication with Bob. Alice encrypts the set in the KEK 7906 she shares with the center and sends the encrypted set to the 7907 center. The center decrypts the set, reencrypts the set in the KEK 7908 it shares with Bob, and either (a) sends that reencrypted set to 7909 Alice for her to forward to Bob or (b) sends it directly to Bob 7910 (although direct distribution is not supported in the ANSI 7911 standard [A9017]). 7913 $ key transport (algorithm or protocol) 7914 1. (I) A key establishment method by which a secret key is 7915 generated by a system entity in a communication association and 7916 securely sent to another entity in the association. (Compare: key 7917 agreement.) 7919 Tutorial: Either (a) one entity generates a secret key and 7920 securely sends it to the other entity, or (b) each entity 7921 generates a secret value and securely sends it to the other 7922 entity, where the two values are combined to form a secret key. 7923 For example, a message originator can generate a random session 7924 key and then use the RSA algorithm to encrypt that key with the 7925 public key of the intended recipient. 7927 2. (O) "The procedure to send a symmetric key from one party to 7928 other parties. As a result, all legitimate participants share a 7929 common symmetric key in such a way that the symmetric key is 7930 determined entirely by one party." [A9042] 7932 $ key update 7933 1. (I) Derive a new key from an existing key. (Compare: rekey.) 7935 2. (O) Irreversible cryptographic process that modifies a key to 7936 produce a new key. [C4009] 7938 $ key validation 7939 1. (I) "The procedure for the receiver of a public key to check 7940 that the key conforms to the arithmetic requirements for such a 7941 key in order to thwart certain types of attacks." [A9042] (See: 7942 weak key) 7944 2. (D) A synonym for "certificate validation". 7946 Deprecated Usage: ISDs SHOULD NOT use the term as a synonym for 7947 "certificate validation"; that would unnecessarily duplicate the 7948 meaning of the latter term and mix concepts in a potentially 7949 misleading way. In validating an X.509 public-key certificate, the 7950 public key contained in the certificate is normally treated as an 7951 opaque data object. 7953 $ keyed hash 7954 (I) A cryptographic hash (e.g., [R1828]) in which the mapping to a 7955 hash result is varied by a second input parameter that is a 7956 cryptographic key. (See: checksum.) 7958 Tutorial: If the input data object is changed, a new, 7959 corresponding hash result cannot be correctly computed without 7960 knowledge of the secret key. Thus, the secret key protects the 7961 hash result so it can be used as a checksum even when there is a 7962 threat of an active attack on the data. There are two basic types 7963 of keyed hash: 7964 - A function based on a keyed encryption algorithm. Example: Data 7965 Authentication Code. 7966 - A function based on a keyless hash that is enhanced by 7967 combining (e.g., by concatenating) the input data object 7968 parameter with a key parameter before mapping to the hash 7969 result. Example: HMAC. 7971 $ keying material 7972 (I) Data that is needed to establish and maintain a cryptographic 7973 security association, such as keys, key pairs, and IVs. 7975 (O) "Key, code, or authentication information in physical or 7976 magnetic form." [C4009] (Compare: COMSEC material.) 7978 $ keying material identifier (KMID) 7979 1. (I) An identifier assigned to an item of keying material. 7981 2. (O) /MISSI/ A 64-bit identifier that is assigned to a key pair 7982 when the public key is bound in a MISSI X.509 public-key 7983 certificate. 7985 $ Khafre 7986 (N) A patented, symmetric block cipher designed by Ralph C. Merkle 7987 as a plug-in replacement for DES. [Schn] 7989 Tutorial: Khafre was designed for efficient encryption of small 7990 amounts of data. However, because Khafre does not precompute 7991 tables used for encryption, it is slower than Khufu for large 7992 amounts of data. 7994 $ Khufu 7995 (N) A patented, symmetric block cipher designed by Ralph C. Merkle 7996 as a plug-in replacement for DES. [Schn] 7998 Tutorial: Khufu was designed for fast encryption of large amounts 7999 of data. However, because Khufu precomputes tables used in 8000 encryption, it is less efficient that Khafre for small amounts of 8001 data. 8003 $ KMID 8004 (I) See: keying material identifier. 8006 $ known-plaintext attack 8007 (I) A cryptanalysis technique in which the analyst tries to 8008 determine the key from knowledge of some plaintext-ciphertext 8009 pairs (although the analyst may also have other clues, such as 8010 knowing the cryptographic algorithm). 8012 $ KSOS, KSOS-6, KSOS-11 8013 (O) See: Kernelized Secure Operating System. 8015 $ L2F 8016 (N) See: Layer 2 Forwarding Protocol. 8018 $ L2TP 8019 (N) See: Layer 2 Tunneling Protocol. 8021 $ label 8022 See: time stamp, security label. 8024 $ laboratory attack 8025 (O) "Use of sophisticated signal recovery equipment in a 8026 laboratory environment to recover information from data storage 8027 media." [C4009] 8029 $ LAN 8030 (I) local area network. 8032 $ land attack 8033 (I) A denial-of-service attack that sends an IP packet that (a) 8034 has the same address in both the Source Address and Destination 8035 Address fields and (b) contains a TCP SYN packet that has the same 8036 port number in both the Source Port and Destination Port fields. 8038 Derivation: This single-packet attack was named for "land", the 8039 program originally published by the cracker who invented this 8040 exploit. Perhaps that name was chosen because the inventor thought 8041 of multi-packet (i.e., flooding) attacks as arriving by "sea". 8043 $ Language of Temporal Ordering Specification (LOTOS) 8044 (N) A language (ISO 8807-1990) for formal specification of 8045 computer network protocols; describes the order in which events 8046 occur. 8048 $ lattice 8049 (I) A finite set together with a partial ordering on its elements 8050 such that for every pair of elements there is a least upper bound 8051 and a greatest lower bound. 8053 Example: A lattice is formed by a finite set S of security levels 8054 -- i.e., a set S of all ordered pairs (x,c), where x is one of a 8055 finite set X of hierarchically ordered classification levels X(1), 8056 non-hierarchical categories C(1), ..., C(M) -- together with the 8057 "dominate" relation. Security level (x,c) is said to "dominate" 8058 (x',c') if and only if (a) x is greater (higher) than or equal to 8059 x' and (b) c includes at least all of the elements of c'. (See: 8060 dominate, lattice model.) 8062 $ lattice model 8063 1. (I) A description of the semantic structure formed by a finite 8064 set of security levels, such as those used in military 8065 organizations. (See: dominate, lattice, security model.) 8067 2. (I) /formal model/ A model for flow control in a system, based 8068 on the lattice that is formed by the finite security levels in a 8069 system and their partial ordering. [Denn] 8071 $ Law Enforcement Access Field (LEAF) 8072 (N) A data item that is automatically embedded in data encrypted 8073 by devices (e.g., CLIPPER chip) that implement the Escrowed 8074 Encryption Standard. 8076 $ Layer 1, 2, 3, 4, 5, 6, 7 8077 (N) See: OSIRM. 8079 $ Layer 2 Forwarding Protocol (L2F) 8080 (N) An Internet protocol (originally developed by Cisco 8081 Corporation) that uses tunneling of PPP over IP to create a 8082 virtual extension of a dial-up link across a network, initiated by 8083 the dial-up server and transparent to the dial-up user. (See: 8084 L2TP.) 8086 $ Layer 2 Tunneling Protocol (L2TP) 8087 (N) An Internet client-server protocol that combines aspects of 8088 PPTP and L2F and supports tunneling of PPP over an IP network or 8089 over frame relay or other switched network. (See: virtual private 8090 network.) 8092 Tutorial: PPP can in turn encapsulate any OSIRM Layer 3 protocol. 8093 Thus, L2TP does not specify security services; it depends on 8094 protocols layered above and below it to provide any needed 8095 security. 8097 $ LDAP 8098 (I) See: Lightweight Directory Access Protocol. 8100 $ least common mechanism 8101 (I) The principle that a security architecture should minimize 8102 reliance on mechanisms that are shared by many users. 8104 Tutorial: Shared mechanisms may include cross-talk paths that 8105 permit a breach of data security, and it is difficult to make a 8106 single mechanism operate in a correct and trusted manner to the 8107 satisfaction of a wide range of users. 8109 $ least privilege 8110 (I) The principle that a security architecture should be designed 8111 so that each system entity is granted the minimum system resources 8112 and authorizations that the entity needs to do its work. (Compare: 8113 economy of mechanism, least trust.) 8115 Tutorial: This principle tends to limit damage that can be caused 8116 by an accident, error, or unauthorized act. This principle also 8117 tends to reduce complexity and promote modularity, which can make 8118 certification easier and more effective. This principle is similar 8119 to the principle of protocol layering, wherein each layer provides 8120 specific, limited communication services, and the functions in one 8121 layer are independent of those in other layers. 8123 $ least trust 8124 (I) The principle that a security architecture should be designed 8125 in a way that minimizes (a) the number of components that require 8126 trust and (b) the extent to which each component is trusted. 8127 (Compare: least privilege, trust level.) 8129 $ legacy system 8130 (I) A system that is in operation but will not be improved or 8131 expanded while a new system is being developed to supersede it. 8133 $ legal non-repudiation 8134 (I) See: secondary definition under "non-repudiation". 8136 $ level of concern 8137 (N) /U.S. DoD/ A rating assigned to an information system that 8138 indicates the extent to which protective measures, techniques, and 8139 procedures must be applied. (See: critical, sensitive, level of 8140 robustness.) 8142 $ level of robustness 8143 (N) /U.S. DoD/ A characterization of the strength of a security 8144 function, mechanism, service, or solution, and the assurance (or 8145 confidence) that is implemented and functioning. [Cons, IATF] 8146 (See: level of concern.) 8148 $ Lightweight Directory Access Protocol (LDAP) 8149 (I) An Internet client-server protocol (RFC 3377) that supports 8150 basic use of the X.500 Directory (or other directory servers) 8151 without incurring the resource requirements of the full Directory 8152 Access Protocol (DAP). 8154 Tutorial: Designed for simple management and browser applications 8155 that provide simple read/write interactive directory service. 8156 Supports both simple authentication and strong authentication of 8157 the client to the directory server. 8159 $ link 8160 1a. (I) A communication facility or physical medium that can 8161 sustain data communications between multiple network nodes, in the 8162 protocol layer immediately below IP. (RFC 3753) 8164 1b. (I) /subnetwork/ A communication channel connecting subnetwork 8165 relays (especially one between two packet switches) that is 8166 implemented at OSIRM Layer 2. (See: link encryption.) 8168 Tutorial: The relay computers assume that links are logically 8169 passive. If a computer at one end of a link sends a sequence of 8170 bits, the sequence simply arrives at the other end after a finite 8171 time, although some bits may have been changed either accidentally 8172 (errors) or by active wiretapping. 8174 2. (I) /World Wide Web/ See: hyperlink. 8176 $ link encryption 8177 (I) Stepwise (link-by-link) protection of data that flows between 8178 two points in a network, provided by encrypting data separately on 8179 each network link, i.e., by encrypting data when it leaves a host 8180 or subnetwork relay and decrypting when it arrives at the next 8181 host or relay. Each link may use a different key or even a 8182 different algorithm. [R1455] (Compare: end-to-end encryption.) 8184 $ liveness 8185 (I) A property of a communication association or a feature of a 8186 communication protocol that provides assurance to the recipient of 8187 data that the data is being freshly transmitted by its originator, 8188 i.e., that the data is not being replayed, by either the 8189 originator or a third party, from a previous transmission. (See: 8190 nonce, replay attack.) 8192 $ logic bomb 8193 (I) Malicious logic that activates when specified conditions are 8194 met. Usually intended to cause denial of service or otherwise 8195 damage system resources. (See: Trojan horse, virus, worm.) 8197 $ login 8198 (I) The act by which a system entity establishes a session in 8199 which the entity can use system resources. (See: principal, 8200 session.) 8202 Usage: Usually understood to be accomplished by providing a user 8203 name and password to an access control system that authenticates 8204 the user, but sometimes refers to establishing a connection with a 8205 server when no authentication or specific authorization is 8206 involved. 8208 Derivation: Refers to "log" file", a security audit trail that 8209 records (a) security events, such as the beginning of a session, 8210 and (b) the names of the system entities that initiate events. 8212 $ long title 8213 (O) /U.S. Government/ "Descriptive title of [an item of COMSEC 8214 material]." [C4009] (Compare: short title.) 8216 $ low probability of detection 8217 (I) Result of TRANSEC measures used to hide or disguise a 8218 communication. 8220 $ low probability of intercept 8221 (I) Result of TRANSEC measures used to prevent interception of a 8222 communication. 8224 $ LOTOS 8225 (N) See: Language of Temporal Ordering Specification. 8227 $ MAC 8228 (N) See: mandatory access control, Message Authentication Code. 8230 Deprecated Usage: ISDs that use this term SHOULD state a 8231 definition for it because this abbreviation is ambiguous. 8233 $ magnetic remanence 8234 (N) Magnetic representation of residual information remaining on a 8235 magnetic medium after the medium has been cleared. [NCS25] (See: 8236 clear, degauss, purge.) 8238 $ main mode 8239 (I) See: /IKE/ under "mode". 8241 $ maintenance hook 8242 (N) "Special instructions (trapdoors) in software allowing easy 8243 maintenance and additional feature development. Since maintenance 8244 hooks frequently allow entry into the code without the usual 8245 checks, they are a serious security risk if they are not removed 8246 prior to live implementation." [C4009] (See: back door.) 8248 $ malicious logic 8249 (I) Hardware, firmware, or software that is intentionally included 8250 or inserted in a system for a harmful purpose. (See: logic bomb, 8251 Trojan horse, spyware, virus, worm. Compare: secondary definitions 8252 under "corruption", "incapacitation", "masquerade", and "misuse".) 8254 $ malware 8255 (D) A contraction of "malicious software". (See: malicious logic.) 8257 Deprecated Term: ISDs SHOULD NOT use this term; it is not listed 8258 in most dictionaries and could confuse international readers. 8260 $ MAN 8261 (I) metropolitan area network. 8263 $ man-in-the-middle attack 8264 (I) A form of active wiretapping attack in which the attacker 8265 intercepts and selectively modifies communicated data in order to 8266 masquerade as one or more of the entities involved in a 8267 communication association. (See: hijack attack, piggyback attack.) 8269 Tutorial: For example, suppose Alice and Bob try to establish a 8270 session key by using the Diffie-Hellman algorithm without data 8271 origin authentication service. A "man in the middle" could (a) 8272 block direct communication between Alice and Bob and then (b) 8273 masquerade as Alice sending data to Bob, (c) masquerade as Bob 8274 sending data to Alice, (d) establish separate session keys with 8275 each of them, and (e) function as a clandestine proxy server 8276 between them in order to capture or modify sensitive information 8277 that Alice and Bob think they are sending only to each other. 8279 $ manager 8280 (I) A person who controls the service configuration of a system or 8281 the functional privileges of operators and other users. 8283 $ mandatory access control 8284 1. (I) An access control service that enforces a security policy 8285 based on comparing (a) security labels, which indicate how 8286 sensitive or critical system resources are, with (b) security 8287 clearances, which indicate that system entities are eligible to 8288 access certain resources. (See: discretionary access control, MAC, 8289 rule-based security policy.) 8291 Derivation: This kind of access control is called "mandatory" 8292 because an entity that has clearance to access a resource is not 8293 permitted, just by its own volition, to enable another entity to 8294 access that resource. 8296 2. (O) "A means of restricting access to objects based on the 8297 sensitivity (as represented by a label) of the information 8298 contained in the objects and the formal authorization (i.e., 8299 clearance) of subjects to access information of such sensitivity." 8300 [DoD1] 8302 $ manipulation detection code 8303 (D) Synonym for "checksum". 8305 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 8306 "checksum"; the word "manipulation" implies protection against 8307 active attacks, which an ordinary checksum might not provide. 8308 Instead, if such protection is intended, use "protected checksum" 8309 or some particular type thereof, depending on which is meant. If 8310 such protection is not intended, use "error detection code" or 8311 some specific type of checksum that is not protected. 8313 $ marking 8314 See: time stamp, security marking. 8316 $ MARS 8317 (O) A symmetric, 128-bit block cipher with variable key length 8318 (128 to 448 bits), developed by IBM as a candidate for the AES. 8320 $ Martian 8321 (D) /slang/ A packet that arrives unexpectedly at the wrong 8322 address or on the wrong network because of incorrect routing or 8323 because it has a non-registered or ill-formed IP address. 8325 Deprecated Term: It is likely that other cultures use different 8326 metaphors for this concept. Therefore, to avoid international 8327 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 8328 Usage under "Green Book".) 8330 $ masquerade 8331 (I) A type of threat action whereby an unauthorized entity gains 8332 access to a system or performs a malicious act by illegitimately 8333 posing as an authorized entity. (See: deception.) 8335 Usage: This type includes the following subtypes: 8336 - "Spoof": Attempt by an unauthorized entity to gain access to a 8337 system by posing as an authorized user. 8338 - "Malicious logic": In context of masquerade, any hardware, 8339 firmware, or software (e.g., Trojan horse) that appears to 8340 perform a useful or desirable function, but actually gains 8341 unauthorized access to system resources or tricks a user into 8342 executing other malicious logic. (See: corruption, 8343 incapacitation, main entry for "malicious logic", misuse.) 8345 $ MCA 8346 (O) See: merchant certification authority. 8348 $ MD2 8349 (N) A cryptographic hash [R1319] that produces a 128-bit hash 8350 result, was designed by Ron Rivest, and is similar to MD4 and MD5 8351 but slower. 8353 Derivation: Apparently an abbreviation of "message digest", but 8354 that term is deprecated by this Glossary. 8356 $ MD4 8357 (N) A cryptographic hash [R1320] that produces a 128-bit hash 8358 result and was designed by Ron Rivest. (See: Derivation under 8359 "MD2", SHA-1.) 8361 $ MD5 8362 (N) A cryptographic hash [R1321] that produces a 128-bit hash 8363 result and was designed by Ron Rivest to be an improved version of 8364 MD4. (See: Derivation under "MD2".) 8366 $ merchant 8367 (O) /SET/ "A seller of goods, services, and/or other information 8368 who accepts payment for these items electronically." [SET2] A 8369 merchant may also provide electronic selling services and/or 8370 electronic delivery of items for sale. With SET, the merchant can 8371 offer its cardholders secure electronic interactions, but a 8372 merchant that accepts payment cards is required to have a 8373 relationship with an acquirer. [SET1, SET2] 8375 $ merchant certificate 8376 (O) /SET/ A public-key certificate issued to a merchant. Sometimes 8377 used to refer to a pair of such certificates where one is for 8378 digital signature use and the other is for encryption. 8380 $ merchant certification authority (MCA) 8381 (O) /SET/ A CA that issues digital certificates to merchants and 8382 is operated on behalf of a payment card brand, an acquirer, or 8383 another party according to brand rules. Acquirers verify and 8384 approve requests for merchant certificates prior to issuance by 8385 the MCA. An MCA does not issue a CRL, but does distribute CRLs 8386 issued by root CAs, brand CAs, geopolitical CAs, and payment 8387 gateway CAs. [SET2] 8389 $ mesh PKI 8390 (I) A non-hierarchical PKI architecture in which there are several 8391 trusted CAs rather than a single root. Each certificate user bases 8392 path validations on the public key of one of the trusted CAs, 8393 usually the one that issued that user's own public-key 8394 certificate. Rather than having superior-to-subordinate 8395 relationships between CAs, the relationships are peer-to-peer, and 8396 CAs issue cross-certificates to each other. (Compare: hierarchical 8397 PKI, trust-file PKI.) 8399 $ Message Authentication Code, message authentication code 8400 (N) /capitalized/ A specific ANSI standard for a checksum that is 8401 computed with a keyed hash that is based on DES. [A9009] Usage: 8402 a.k.a. Data Authentication Code, which is a U.S. Government 8403 standard. [FP113] (See: MAC.) 8405 (D) /not capitalized/ Synonym for "error detection code". 8407 Deprecated Term: ISDs SHOULD NOT use the uncapitalized form 8408 "message authentication code". Instead, use "checksum", "error 8409 detection code", "hash", "keyed hash", "Message Authentication 8410 Code", or "protected checksum", depending on what is meant. (See: 8411 authentication code.) 8413 The uncapitalized form mixes concepts in a potentially misleading 8414 way. The word "message" is misleading because it implies that the 8415 mechanism is particularly suitable for or limited to electronic 8416 mail (see: Message Handling Systems). The word "authentication" is 8417 misleading because the mechanism primarily serves a data integrity 8418 function rather than an authentication function. The word "code" 8419 is misleading because it implies that either encoding or 8420 encryption is involved or that the term refers to computer 8421 software. 8423 $ message digest 8424 (D) Synonym for "hash result". (See: cryptographic hash.) 8426 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 8427 "hash result"; the term unnecessarily duplicates the meaning of 8428 the other, more general term and mixes concepts in a potentially 8429 misleading way. The word "message" is misleading because it 8430 implies that the mechanism is particularly suitable for or limited 8431 to electronic mail (see: Message Handling Systems). 8433 $ message handling system 8434 (D) A synonym for the Internet electronic mail system. 8436 Deprecated Term: ISDs SHOULD NOT use this term, because it could 8437 be confused with Message Handling System. Instead, use "Internet 8438 electronic mail" or some other, more specific term. 8440 $ Message Handling System 8441 (O) A ITU-T system concept that encompasses the notion of 8442 electronic mail but defines more comprehensive OSI systems and 8443 services that enable users to exchange messages on a store-and- 8444 forward basis. (The ISO equivalent is "Message Oriented Text 8445 Interchange System".) (See: X.400.) 8447 $ message indicator 8448 1. (D) /cryptographic function/ Synonym for "initialization 8449 value". 8451 2. (D) "Sequence of bits transmitted over a communications system 8452 for synchronizing cryptographic equipment." [C4009] 8454 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 8455 "initialization value"; the term mixes concepts in a potentially 8456 misleading way. The word "message" is misleading because it 8457 suggests that the mechanism is limited to electronic mail. (See: 8458 Message Handling System.) 8460 $ message integrity check 8461 $ message integrity code (MIC) 8462 (D) Synonyms for some form of "checksum". 8464 Deprecated Term: ISDs SHOULD NOT use these terms for any form of 8465 checksum. Instead, use "checksum", "error detection code", "hash", 8466 "keyed hash", "Message Authentication Code", or "protected 8467 checksum", depending on what is meant. 8469 These two terms mix concepts in potentially misleading ways. The 8470 word "message" is misleading because it suggests that the 8471 mechanism is particularly suitable for or limited to electronic 8472 mail. The word "integrity" is misleading because the checksum may 8473 be used to perform a data origin authentication function rather 8474 than an integrity function. The word "code" is misleading because 8475 it suggests either that either encoding or encryption is involved 8476 or that the term refers to computer software. 8478 $ Message Security Protocol (MSP) 8479 (N) A secure message handling protocol [SDNS7] for use with X.400 8480 and Internet mail protocols. Developed by NSA's SDNS program and 8481 used in the U.S. DoD's Defense Message System. 8483 $ meta-data 8484 (I) Descriptive information about a data object; i.e., data about 8485 data, or data labels that describe other data. (See: security 8486 label. Compare: metadata) 8488 Tutorial: Meta-data can serve various management purposes: 8489 - System management: File name, type, size, creation date. 8490 - Application management: Document title, version, author. 8491 - Usage management: Data categories, keywords, classifications. 8493 Meta-data can be associated with a data object in two basic ways: 8494 - Explicitly: Be part of the data object (e.g., a header field of 8495 a data file or packet) or be linked to the object. 8496 - Implicitly: Be associated with the data object because of some 8497 other, explicit attribute of the object. 8499 $ metadata, Metadata(trademark), METADATA(trademark) 8500 (D) Proprietary variants of "meta-data". (See: SPAM(trademark).) 8502 Deprecated Terms: ISDs SHOULD NOT use these unhypenated forms; 8503 ISDs SHOULD use only the uncapitalized, hyphenated "meta-data". 8504 The terms "Metadata" and "METADATA" are claimed as registered 8505 trademarks (numbers 1,409,260 and 2,185,504) owned by The Metadata 8506 Company, originally known as Metadata Information Partners, a 8507 company founded by Jack Myers. The status of "metadata" is 8508 unclear. 8510 $ MHS 8511 (N) See: message handling system. 8513 $ MIC 8514 (D) See: message integrity code. 8516 $ MIME 8517 (I) See: Multipurpose Internet Mail Extensions. 8519 $ MIME Object Security Services (MOSS) 8520 (I) An Internet protocol [R1848] that applies end-to-end 8521 encryption and digital signature to MIME message content, using 8522 symmetric cryptography for encryption and asymmetric cryptography 8523 for key distribution and signature. MOSS is based on features and 8524 specifications of PEM. (See: S/MIME.) 8526 $ Minimum Interoperability Specification for PKI Components (MISPC) 8527 (N) A technical description to provide a basis for interoperation 8528 between PKI components from different vendors; consists primarily 8529 of a profile of certificate and CRL extensions and a set of 8530 transactions for PKI operation. [SP15] 8532 $ misappropriation 8533 (I) A type of threat action whereby an entity assumes unauthorized 8534 logical or physical control of a system resource. (See: 8535 usurpation.) 8537 Usage: This type includes the following subtypes: 8538 - Theft of data: Unauthorized acquisition and use of data 8539 contained in a system. 8540 - Theft of service: Unauthorized use of a system service. 8541 - Theft of functionality: Unauthorized acquisition of actual 8542 hardware, firmware, or software of a system component. 8544 $ MISPC 8545 (N) See: Minimum Interoperability Specification for PKI 8546 Components. 8548 $ MISSI 8549 (O) Multilevel Information System Security Initiative, an NSA 8550 program to encourage development of interoperable, modular 8551 products for constructing secure network information systems in 8552 support of a wide variety of Government missions. (See: MSP, SP3, 8553 SP4.) 8555 $ MISSI user 8556 (O) /MISSI/ A system entity that is the subject of one or more 8557 MISSI X.509 public-key certificates issued under a MISSI 8558 certification hierarchy. (See: personality.) 8560 Tutorial: MISSI users include both end users and the authorities 8561 that issue certificates. A MISSI user is usually a person but may 8562 be a machine or other automated process. Machines that are 8563 required to operate non-stop may be issued their own certificates 8564 to avoid downtime needed to exchange the FORTEZZA cards of machine 8565 operators at shift changes. 8567 $ mission 8568 (I) A statement of a (relatively long-term) duty or (relatively 8569 short-term) task that is assigned to an organization or system, 8570 indicates the purpose and objectives of the duty or task, and may 8571 indicate the actions to be taken to achieve it. 8573 $ mission critical 8574 (I) A condition of a system service or other system resource such 8575 that denial of access to, or lack of availability of, the resource 8576 would jeopardize a system user's ability to perform a primary 8577 mission function or would result in other serious consequences. 8578 (See: Critical. Compare: mission essential.) 8580 $ mission essential 8581 (O) /DoD/ Refers to materiel that is authorized and available to 8582 combat, combat support, combat service support, and combat 8583 readiness training forces to accomplish their assigned missions. 8584 [JCSP1] (Compare: mission critical.) 8586 $ misuse 8587 1. (I) The intentional use (by authorized users) of system 8588 resources for other than authorized purposes. Example: An 8589 authorized system administrator creates an unauthorized account 8590 for a friend. 8592 2. (I) A type of threat action that causes a system component to 8593 perform a function or service that is detrimental to system 8594 security. (See: usurpation.) 8596 Usage: This type includes the following subtypes: 8597 - "Tampering": In context of misuse, deliberately altering a 8598 system's logic, data, or control information to cause the 8599 system to perform unauthorized functions or services. (See: 8600 corruption, main entry for "tampering".) 8601 - "Malicious logic": In context of misuse, any hardware, 8602 firmware, or software intentionally introduced into a system to 8603 perform or control execution of an unauthorized function or 8604 service. (See: corruption, incapacitation, main entry for 8605 "malicious logic", masquerade.) 8606 - "Violation of authorizations": Action by an entity that exceeds 8607 the entity's system privileges by executing an unauthorized 8608 function. (See: authorization.) 8610 $ misuse detection 8611 (I) An intrusion detection method that is based on rules that 8612 specify system events, sequences of events, or observable 8613 properties of a system that are believed to be symptomatic of 8614 security incidents. (See: IDS. Compare: anomaly detection.) 8616 $ MLS 8617 (I) See: multilevel secure 8619 $ mobile code 8620 1a. (I) Software that originates from a remote server or is 8621 embedded in a document or other application file, is transmitted 8622 across a network, and is loaded onto and executed on a local 8623 client system. 8625 1b. (O) /U.S. DoD/ "Software obtained from remote systems outside 8626 the enclave boundary, transferred across a network, and then 8627 downloaded and executed on a local system without explicit 8628 installation or execution by the recipient." 8630 2a. (O) /U.S. DoD/ "Technology that enables the creation of 8631 executable information that can be delivered to an information 8632 system and directly executed on any hardware/software architecture 8633 that has an appropriate host execution environment." 8635 2b. (O) "Programs (e.g., script, macro, or other portable 8636 instruction) that can be shipped unchanged to a heterogeneous 8637 collection of platforms and executed with identical semantics" 8638 [SP-28]. (See: active content.) 8640 Tutorial: Mobile code might be malicious. Using techniques such as 8641 "code signing" and a "sandbox" can reduce the risks of receiving 8642 and executing mobile code. 8644 $ mode 8645 $ mode of operation 8646 1. (I) /cryptographic operation/ A technique for enhancing the 8647 effect of a cryptographic algorithm or adapting the algorithm for 8648 an application, such as applying a block cipher to a sequence of 8649 data blocks or a data stream. (See: ECB, CBC, CFB, OFB.) 8651 2. (I) /system operation/ A type of security policy that states 8652 the range of classification levels of information that a system is 8653 permitted to handle and the range of clearances and authorizations 8654 of users who are permitted to access the system. (See: 8655 compartmented security mode, controlled security mode, dedicated 8656 security mode, multilevel security mode, partitioned security 8657 mode, system-high security mode. Compare: protection level.) 8659 3. (I) /IKE/ IKE refers to its various types of ISAKMP-scripted 8660 exchanges of messages as "modes". Among these are the following: 8661 - "Main mode": One of IKE's two phase 1 modes. (See: ISAKMP.) 8662 - "Quick mode": IKE's only phase 2 mode. (See: ISAKMP.) 8664 $ modulus 8665 (I) The defining constant in modular arithmetic, and usually a 8666 part of the public key in asymmetric cryptography that is based on 8667 modular arithmetic. (See: Diffie-Hellman, RSA.) 8669 $ Mondex 8670 (O) A smartcard-based electronic money system that incorporates 8671 cryptography and can be used to make payments via the Internet. 8672 (See: IOTP.) 8674 $ Morris Worm 8675 (I) A worm program that flooded the ARPANET in November, 1988, 8676 causing problems for thousands of hosts. [R1135] (See: community 8677 risk, worm) 8679 $ MOSS 8680 (I) See: MIME Object Security Services. 8682 $ MQV 8683 (N) A key-agreement protocol [Mene] that was proposed by A.J. 8684 Menezes, M. Qu, and S.A. Vanstone in 1995 and is based on the 8685 Diffie-Hellman algorithm. 8687 $ MSP 8688 (N) See: Message Security Protocol. 8690 $ multicast security 8691 See: secure multicast 8693 $ Multics 8694 (N) MULTiplexed Information and Computing Service, an MLS computer 8695 timesharing system designed and implemented during 1965-69 by a 8696 consortium including Massachusetts Institute of Technology, 8697 General Electric, and Bell Laboratories, and later offered 8698 commercially by Honeywell. 8700 Tutorial: Multics was one of the first large, general-purpose, 8701 operating systems to include security as a primary goal from the 8702 inception of the design and development and was rated in TCSEC 8703 Class B2. Its many innovative hardware and software security 8704 mechanisms (e.g., protection ring) were adopted by later systems. 8706 $ multilevel secure (MLS) 8707 (I) Describes an information system that is trusted to contain, 8708 and maintain separation between, resources (particularly stored 8709 data) of different security levels. (Examples: BLACKER, CANEWARE, 8710 KSOS, Multics, SCOMP.) 8712 Usage: Usually understood to mean that the system permits 8713 concurrent access by users who differ in their access 8714 authorizations, while denying users access to resources for which 8715 they lack authorization. 8717 $ multilevel security mode 8718 1. (N) A mode of system operation wherein (a) two or more security 8719 levels of information are allowed to be to be handled concurrently 8720 within the same system when some users having access to the system 8721 have neither a security clearance nor need-to-know for some of the 8722 data handled by the system and (b) separation of the users and the 8723 classified material on the basis, respectively, of clearance and 8724 classification level are dependent on operating system control. 8725 (See: /system operation/ under "mode", need to know, protection 8726 level, security clearance. Compare: controlled mode.) 8728 Usage: Usually abbreviated as "multilevel mode". This term was 8729 defined in Government policy regarding system accreditation, but 8730 the term is also used outside the Government. 8732 2. (O) A mode of system operation in which all three of the 8733 following statements are true: (a) Some authorized users do not 8734 have a security clearance for all the information handled in the 8735 system. (b) All authorized users have the proper security 8736 clearance and appropriate specific access approval for the 8737 information to which they have access. (c) All authorized users 8738 have a need-to-know only for information to which they have 8739 access. [C4009] (See: formal access approval, protection level.) 8741 $ Multipurpose Internet Mail Extensions (MIME) 8742 (I) An Internet protocol (RFC 2045) that enhances the basic format 8743 of Internet electronic mail messages (RFC 822) (1) to enable 8744 character sets other than U.S. ASCII to be used for textual 8745 headers and content and (2) to carry non-textual and multi-part 8746 content. (See: S/MIME.) 8748 $ mutual suspicion 8749 (I) The state that exists between two interacting system entities 8750 in which neither entity can trust the other to function correctly 8751 with regard to some security requirement. 8753 $ name 8754 (I) Synonym for "identifier". 8756 $ National Computer Security Center (NCSC) 8757 (O) A U.S. DoD organization, housed in NSA, that has 8758 responsibility for encouraging widespread availability of trusted 8759 computer systems throughout the Federal Government. It has 8760 established criteria for, and performed evaluations of, computer 8761 and network systems that have a TCB. (See: Evaluated Products 8762 List, Rainbow Series, TCSEC.) 8764 $ National Information Assurance Partnership (NIAP) 8765 (N) An joint initiative of NIST and NSA to enhance the quality of 8766 commercial products for information security and increase consumer 8767 confidence in those products through objective evaluation and 8768 testing methods. 8770 Tutorial: NIAP is registered, through the U.S. DoD, as a National 8771 Performance Review Reinvention Laboratory. NIAP functions include 8772 the following: 8773 - Developing tests, test methods, and other tools that developers 8774 and testing laboratories may use to improve and evaluate 8775 security products. 8776 - Collaborating with industry and others on research and testing 8777 programs. 8779 - Using the Common Criteria to develop protection profiles and 8780 associated test sets for security products and systems. 8781 - Cooperating with the NIST National Voluntary Laboratory 8782 Accreditation Program to develop a program to accredit private- 8783 sector laboratories for the testing of information security 8784 products using the Common Criteria. 8785 - Working to establish a formal, international mutual recognition 8786 scheme for a Common Criteria-based evaluation. 8788 $ National Institute of Standards and Technology (NIST) 8789 (N) A U.S. Department of Commerce organization that promotes U.S. 8790 economic growth by working with industry to develop and apply 8791 technology, measurements, and standards. Has primary Government 8792 responsibility for INFOSEC standards for sensitive unclassified 8793 information. (See: ANSI, DES, DSA, DSS, FIPS, NIAP, NSA.) 8795 $ National Security Agency (NSA) 8796 (N) A U.S. DoD organization that has primary Government 8797 responsibility for INFOSEC standards for classified information 8798 and for sensitive unclassified information handled by national 8799 security systems. (See: FORTEZZA, KEA, MISSI, national security 8800 system, NIAP, NIST, SKIPJACK.) 8802 $ national security information 8803 (N) /U.S. Government/ Information that has been determined, 8804 pursuant to Executive Order 12958 or any predecessor order, to 8805 require protection against unauthorized disclosure. [C4009] 8807 $ national security system 8808 (O) /U.S. Government/ Any Government-operated information system 8809 for which the function, operation, or use (a) involves 8810 intelligence activities; (b) involves cryptologic activities 8811 related to national security; (c) involves command and control of 8812 military forces; (d) involves equipment that is an integral part 8813 of a weapon or weapon system; or (e) is critical to the direct 8814 fulfillment of military or intelligence missions and does not 8815 include a system that is to be used for routine administrative and 8816 business applications (including payroll, finance, logistics, and 8817 personnel management applications). [Title 40 U.S.C. Section 1552, 8818 Information Technology Management Reform Act of 1996.] (See: type 8819 2 product.) 8821 $ NCSC 8822 (O) See: National Computer Security Center. 8824 $ need to know, need-to-know 8825 (I) The necessity for access to, knowledge of, or possession of 8826 specific information required to carry out official duties. 8828 Usage: The compound "need-to-know" is used as both an adjective 8829 and a noun. 8831 Tutorial: The need-to-know criterion is used in security 8832 procedures that require a custodian of sensitive information, 8833 prior to disclosing the information to someone else, to establish 8834 that the intended recipient has proper authorization to access the 8835 information. 8837 $ network 8838 (I) An information system comprised of a collection of 8839 interconnected nodes. (See: computer network.) 8841 $ Network Hardware Layer 8842 (I) See: Internet Protocol Suite. 8844 $ Network Interface Layer 8845 (I) See: Internet Protocol Suite. 8847 $ Network Layer Security Protocol (NLSP). 8848 (N) An OSI protocol (IS0 11577) for end-to-end encryption services 8849 at the top of OSIRM Layer 3. NLSP is derived from SP3 but is more 8850 complex. (Compare: IPsec.) 8852 $ Network Substrate Layer 8853 (I) Synonym for "Network Hardware Layer". 8855 $ network weaving 8856 (I) A penetration technique in which an intruder avoids detection 8857 and traceback by using multiple linked communication networks to 8858 access and attack a system. [C4009] 8860 $ NIAP 8861 (N) See: National Information Assurance Partnership. 8863 $ nibble 8864 (D) Half of a byte (i.e., usually, 4 bits). 8866 Deprecated Term: To avoid international misunderstanding, ISDs 8867 SHOULD NOT use this term; instead, state the size of the block 8868 explicitly (e.g., "4-bit block"). (See: Deprecated Usage under 8869 "Green Book".) 8871 $ NIPRNET 8872 (O) The U.S. DoD's common-use Non-Classified Internet Protocol 8873 Router Network; the part of the Internet that is wholly controlled 8874 by the U.S. DoD and is used for official DoD business. 8876 $ NIST 8877 (N) See: National Institute of Standards and Technology. 8879 $ NLSP 8880 (N) See: Network Layer Security Protocol 8882 $ no-lone zone 8883 (I) A room or other space or area to which no person may have 8884 unaccompanied access and that, when occupied, is required to be 8885 occupied by two or more appropriately authorized persons. [C4009] 8886 (See: dual control.) 8888 $ no-PIN ORA (NORA) 8889 (O) /MISSI/ An organizational RA that operates in a mode in which 8890 the ORA performs no card management functions and, therefore, does 8891 not require knowledge of either the SSO PIN or user PIN for an end 8892 user's FORTEZZA PC card. 8894 $ node 8895 (I) A collection of related subsystems located on one or more 8896 computer platforms at a single system site. 8898 $ nonce 8899 (I) A random or non-repeating value that is included in data 8900 exchanged by a protocol, usually for the purpose of guaranteeing 8901 liveness and thus detecting and protecting against replay attacks. 8903 $ non-critical 8904 See: critical. 8906 $ non-repudiation service 8907 1. (I) A security service that provide protection against false 8908 denial of involvement in a communication. (See: repudiation, time 8909 stamp.) 8911 2. (D) "Assurance [that] the sender of data is provided with proof 8912 of delivery and the recipient is provided with proof of the 8913 sender's identity, so neither can later deny having processed the 8914 data." [NS4009] 8916 Deprecated Definition: ISDs SHOULD NOT use this definition because 8917 it bundles two security services -- non-repudiation with proof of 8918 origin, and non-repudiation with proof of receipt -- that can be 8919 provided independently of each other. 8921 Usage: ISDs SHOULD distinguish between the technical aspects and 8922 the legal aspects of a non-repudiation service: 8923 - "Technical non-repudiation": Refers to the assurance a relying 8924 party has that if a public key is used to validate a digital 8925 signature, then that signature had to have been made by the 8926 corresponding private signature key. [SP32] 8927 - "Legal non-repudiation": Refers to how well possession or 8928 control of the private signature key can be established. [SP32] 8930 Tutorial: Non-repudiation service does not prevent an entity from 8931 repudiating a communication. Instead, the service provides 8932 evidence that can be stored and later presented to a third party 8933 to resolve disputes that arise if and when a communication is 8934 repudiated by one of the entities involved. 8936 Ford describes the six phases of a complete non-repudiation 8937 service and uses "critical action" to refer to the act of 8938 communication that is the subject of the service [For94, For97]: 8940 -------- -------- -------- -------- -------- . -------- 8941 Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6: 8942 Request Generate Transfer Verify Retain . Resolve 8943 Service Evidence Evidence Evidence Evidence . Dispute 8944 -------- -------- -------- -------- -------- . -------- 8946 Service Critical Evidence Evidence Archive . Evidence 8947 Request => Action => Stored => Is => Evidence . Is 8948 Is Made Occurs For Later Tested In Case . Verified 8949 and Use | ^ Critical . ^ 8950 Evidence v | Action Is . | 8951 Is +-------------------+ Repudiated . | 8952 Generated |Verifiable Evidence|------> ... . ----+ 8953 +-------------------+ 8955 Phase / Explanation 8956 ------------------- 8957 1. Request service: Before the critical action, the service 8958 requester asks, either implicitly or explicitly, to have 8959 evidence of the action be generated. 8960 2. Generate evidence: When the critical action occurs, evidence is 8961 generated by a process involving the potential repudiator and 8962 possibly also a trusted third party. 8963 3. Transfer evidence: The evidence is transferred to the requester 8964 or stored by a third party, for later use (if needed.) 8965 4. Verify evidence: The entity that holds the evidence tests it to 8966 be sure that it will suffice if a dispute arises. 8967 5. Retain evidence: The evidence is retained for possible future 8968 retrieval and use. 8969 6. Resolve dispute: In this phase, which occurs only if the 8970 critical action is repudiated, the evidence is retrieved from 8971 storage, presented, and verified to resolve the dispute. 8973 $ non-repudiation with proof of origin 8974 (I) A security service that provides the recipient of data with 8975 evidence that proves the origin of the data, and thus protects the 8976 recipient against an attempt by the originator to falsely deny 8977 sending the data. (See: non-repudiation service.) 8979 Tutorial: This service is a strong version of data origin 8980 authentication service. This service can not only verify the 8981 identity of a system entity that is the original source of 8982 received data; it can also provide proof of that identity to a 8983 third party. 8985 $ non-repudiation with proof of receipt 8986 (I) A security service that provides the originator of data with 8987 evidence that proves the data was received as addressed, and thus 8988 protects the originator against an attempt by the recipient to 8989 falsely deny receiving the data. (See: non-repudiation service.) 8991 $ non-volatile media 8992 (I) Storage media that, once written into, provide stable storage 8993 of information without an external power supply. (Compare: 8994 permanent storage, volatile media.) 8996 $ NORA 8997 (O) See: no-PIN ORA. 8999 $ notarization 9000 (I) Registration of data under the authority or in the care of a 9001 trusted third party, thus making it possible to provide subsequent 9002 assurance of the accuracy of characteristics claimed for the data, 9003 such as content, origin, time of existence, and delivery. [I7498 9004 Part 2] (See: digital notary.) 9006 $ NSA 9007 (N) See: National Security Agency 9009 $ null 9010 (N) /encryption/ "Dummy letter, letter symbol, or code group 9011 inserted into an encrypted message to delay or prevent its 9012 decryption or to complete encrypted groups for transmission or 9013 transmission security purposes." [C4009] 9015 $ NULL encryption algorithm 9016 (I) An algorithm [R2410] that is specified as doing nothing to 9017 transform plaintext data; i.e., a no-op. It originated because ESP 9018 always specifies the use of an encryption algorithm for 9019 confidentiality. The NULL encryption algorithm is a convenient way 9020 to represent the option of not applying encryption in ESP (or in 9021 any other context where a no-op is needed). (Compare: null.) 9023 $ OAKLEY 9024 (I) A key establishment protocol (proposed for IPsec but 9025 superseded by IKE) based on the Diffie-Hellman algorithm and 9026 designed to be a compatible component of ISAKMP. [R2412] 9028 Tutorial: OAKLEY establishes a shared key with an assigned 9029 identifier and associated authenticated identities for parties; 9030 i.e., OAKLEY provides authentication service to ensure the 9031 entities of each other's identity, even if the Diffie-Hellman 9032 exchange is threatened by active wiretapping. Also, it provides 9033 public-key forward secrecy for the shared key and supports key 9034 updates, incorporation of keys distributed by out-of-band 9035 mechanisms, and user-defined abstract group structures for use 9036 with Diffie-Hellman. 9038 $ object 9039 (I) /formal model/ Trusted computer system modeling usage: A 9040 system component that contains or receives information. (See: 9041 Bell-LaPadula model, trusted computer system.) 9043 $ object identifier (OID) 9044 1. (N) An official, globally unique name for a thing, written as a 9045 sequence of integers (which are formed and assigned as defined in 9046 the ASN.1 standard) and used to reference the thing in abstract 9047 specifications and during negotiation of security services in a 9048 protocol. 9050 2. (O) "A value (distinguishable from all other such values) which 9051 is associated with an object." [X680] 9053 Tutorial: Objects named by OIDs are leaves of the object 9054 identifier tree (which is similar to but different from the X.500 9055 Directory Information Tree). Each arc (i.e., each branch of the 9056 tree) is labeled with a non-negative integer. An OID is the 9057 sequence of integers on the path leading from the root of the tree 9058 to a named object. 9060 The OID tree has three arcs immediately below the root: {0} for 9061 use by ITU-T, {1} for use by ISO, and {2} for use by both jointly. 9062 Below ITU-T are four arcs, where {0 0} is for ITU-T 9063 recommendations. Below {0 0} are 26 arcs, one for each series of 9064 recommendations starting with the letters A to Z, and below these 9065 are arcs for each recommendation. Thus, the OID for ITU-T 9066 Recommendation X.509 is {0 0 24 509}. Below ISO are four arcs, 9067 where {1 0 }is for ISO standards, and below these are arcs for 9068 each ISO standard. Thus, the OID for ISO/IEC 9594-8 (the ISO 9069 number for X.509) is {1 0 9594 8}. 9071 ANSI registers organization names below the branch {joint-iso- 9072 ccitt(2) country(16) US(840) organization(1) gov(101) csor(3)}. 9073 The NIST CSOR records PKI objects below the branch {joint-iso-itu- 9074 t(2) country(16) us(840) organization (1) gov(101) csor(3)}. The 9075 U.S. DoD registers INFOSEC objects below the branch {joint-iso- 9076 itu-t(2) country(16) us(840) organization(1) gov(101) dod(2) 9077 infosec(1)}. 9079 The IETF's Public-Key Infrastructure (pkix) Working Group 9080 registers PKI objects below the branch {iso(1) identified- 9081 organization(3) dod(6) internet(1) security(5) mechanisms(5) 9082 pkix(7)}. [R3280] 9084 $ object reuse 9085 (N) /COMPUSEC/ Reassignment and reuse of an area of a storage 9086 medium (e.g., random-access memory, floppy disk, magnetic tape) 9087 that once contained sensitive data objects. Before being 9088 reassigned for use by a new subject, the area needs to be erased 9089 or, in some cases, purged. [NCS04] 9091 $ obstruction 9092 (I) A type of threat action that interrupts delivery of system 9093 services by hindering system operations. (See: disruption.) 9095 Tutorial: This type includes the following subtypes: 9096 - "Interference": Disruption of system operations by blocking 9097 communication of user data or control information. (See: 9098 jamming.) 9099 - "Overload": Hindrance of system operation by placing excess 9100 burden on the performance capabilities of a system component. 9101 (See: flooding.) 9103 $ OCSP 9104 (I) See: On-line Certificate Status Protocol. 9106 $ octet 9107 (I) A data unit of eight bits. (Compare: byte.) 9109 Usage: This term is used in networking (especially in OSI 9110 standards) in preference to "byte", because some systems use 9111 "byte" for data storage units of a size other than eight bits. 9113 $ OFB 9114 (N) See: output feedback. 9116 $ off-line attack 9117 (I) See: secondary definition under "attack". 9119 $ ohnosecond 9120 (D) That minuscule fraction of time in which you realize that your 9121 private key has been compromised. 9123 Deprecated Usage: This is a joke for English speakers. (See: 9124 Deprecated Usage under "Green Book".) 9126 $ OID 9127 (N) See: object identifier. 9129 $ On-line Certificate Status Protocol (OCSP) 9130 (I) An Internet protocol [R2560] used by a client to obtain from a 9131 server the validity status and other information about a digital 9132 certificate. 9134 Tutorial: In some applications, such as those involving high-value 9135 commercial transactions, it may be necessary either (a) to obtain 9136 certificate revocation status that is more timely than is possible 9137 with CRLs or (b) to obtain other kinds of status information. OCSP 9138 may be used to determine the current revocation status of a 9139 digital certificate, in lieu of or as a supplement to checking 9140 against a periodic CRL. An OCSP client issues a status request to 9141 an OCSP server and suspends acceptance of the certificate in 9142 question until the server provides a response. 9144 $ one-time pad 9145 1. (N) A manual encryption system in the form of a paper pad for 9146 one-time use. 9148 2. (I) An encryption algorithm in which the key is a random 9149 sequence of symbols and each symbol is used for encryption only 9150 one time -- i.e., used to encrypt only one plaintext symbol and 9151 thus produce only one ciphertext symbol -- and a copy of the key 9152 is used similarly for decryption. 9154 Tutorial: To ensure one-time use, the copy of the key used for 9155 encryption is destroyed after use, as is the copy used for 9156 decryption. This is the only encryption algorithm that is truly 9157 unbreakable, even given unlimited resources for cryptanalysis 9158 [Schn], but key management costs and synchronization problems make 9159 it impractical except in special situations. 9161 $ one-time password, One-Time Password (OTP) 9162 1. (I) /not capitalized/ A "one-time password" is a simple 9163 authentication technique in which each password is used only once 9164 as authentication information that verifies an identity. This 9165 technique counters the threat of a replay attack that uses 9166 passwords captured by wiretapping. 9168 2. (I) /capitalized/ "One-Time Password" is an Internet protocol 9169 [R1938] that is based on S/KEY and uses a cryptographic hash 9170 function to generate one-time passwords for use as authentication 9171 information in system login and in other processes that need 9172 protection against replay attacks. 9174 $ one-way encryption 9175 (I) Irreversible transformation of plain text to cipher text, such 9176 that the plain text cannot be recovered from the cipher text by 9177 other than exhaustive procedures even if the cryptographic key is 9178 known. (See: encryption.) 9180 $ one-way function 9181 (I) "A (mathematical) function, f, which is easy to compute, but 9182 which for a general value y in the range, it is computationally 9183 difficult to find a value x in the domain such that f(x) = y. 9184 There may be a few values of y for which finding x is not 9185 computationally difficult." [X509] 9187 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 9188 "cryptographic hash". 9190 $ onion routing 9191 (I) A system that can be used to provide both (a) data 9192 confidentiality and (b) traffic-flow confidentiality for network 9193 packets, and also provide (c) anonymity for the source of the 9194 packets. 9196 Tutorial: The source, instead of sending a packet directly to the 9197 intended destination, sends it to an "onion routing proxy" that 9198 builds an anonymous connection through several other "onion 9199 routers" to the destination. The proxy defines a route through the 9200 "onion routing network" by encapsulating the original payload in a 9201 layered data packet called an "onion", in which each layer defines 9202 the next hop in the route and each layer is also encrypted. Along 9203 the route, each onion router that receives the onion peels off one 9204 layer; decrypts that layer and reads from it the address of the 9205 next onion router on the route; pads the remaining onion to some 9206 constant size; and sends the padded onion to that next router. 9208 $ open security environment 9209 (O) /U.S. DoD/ A system environment that meets at least one of the 9210 following two conditions: (a) Application developers (including 9211 maintainers) do not have sufficient clearance or authorization to 9212 provide an acceptable presumption that they have not introduced 9213 malicious logic. (b) Configuration control does not provide 9214 sufficient assurance that applications and the equipment are 9215 protected against the introduction of malicious logic prior to and 9216 during the operation of system applications. [NCS04] (See: "first 9217 law" under "Courtney's laws". Compare: closed security 9218 environment.) 9220 $ open storage 9221 (N) /U.S. Government/ "Storage of classified information within an 9222 accredited facility, but not in General Services Administration 9223 approved secure containers, while the facility is unoccupied by 9224 authorized personnel." [C4009] 9226 $ Open Systems Interconnection (OSI) Reference Model (OSIRM) 9227 (N) A joint ISO/ITU-T standard [I7498 Part 1] for a seven-layer, 9228 architectural communication framework for interconnection of 9229 computers in networks. (See: OSIRM Security Architecture. Compare: 9230 Internet Protocol Suite.) 9232 Tutorial: OSIRM-based standards include communication protocols 9233 that are mostly incompatible with the IPS, but also include 9234 security models, such as X.509, that are used in the Internet. 9236 The OSIRM layers, from highest to lowest, are (7) Application, (6) 9237 Presentation, (5) Session, (4) Transport, (3) Network, (2) Data 9238 Link, and (1) Physical. 9240 Usage: This Glossary refers to OSIRM layers by number to avoid 9241 confusing them with IPS layers, which are referred to by name. 9243 Some unknown person described how the OSIRM layers correspond to 9244 the seven deadly sins: 9246 7. Wrath: Application is always angry at the mess it sees below 9247 itself. (Hey! Who is it to be pointing fingers?) 9248 6. Sloth: Presentation is too lazy to do anything productive by 9249 itself. 9250 5. Lust: Session is always craving and demanding what truly 9251 belongs to Application's functionality. 9252 4. Avarice: Transport wants all of the end-to-end functionality. 9253 (Of course, it deserves it, but life isn't fair.) 9254 3. Gluttony: (Connection-Oriented) Network is overweight and 9255 overbearing after trying too often to eat Transport's lunch. 9256 2. Envy: Poor Data Link is always starved for attention. (With 9257 Asynchronous Transfer Mode, maybe now it is feeling less 9258 neglected.) 9259 1. Pride: Physical has managed to avoid much of the controversy, 9260 and nearly all of the embarrassment, suffered by the others. 9262 John G. Fletcher described how the OSIRM layers correspond to Snow 9263 White's dwarf friends: 9265 7. Doc: Application acts as if it is in charge, but sometimes 9266 muddles its syntax. 9267 6. Sleepy: Presentation is indolent, being guilty of the sin of 9268 Sloth. 9269 5. Dopey: Session is confused because its charter is not very 9270 clear. 9271 4. Grumpy: Transport is irritated because Network has encroached 9272 on Transport's turf. 9273 3. Happy: Network smiles for the same reason that Transport is 9274 irritated. 9275 2. Sneezy: Data Link makes loud noises in the hope of attracting 9276 attention. 9277 1. Bashful: Physical quietly does its work, unnoticed by the 9278 others. 9280 $ operational integrity 9281 (I) Synonym for "system integrity"; this synonym emphasizes the 9282 actual performance of system functions rather than just the 9283 ability to perform them. 9285 $ operational security 9286 1. (I) System capabilities, or performance of system functions, 9287 that are needed either (a) to securely manage a system or (b) to 9288 manage security features of a system. (Compare: operations 9289 security (OPSEC).) 9291 Usage: ISDs that use this term SHOULD state a definition because 9292 (a) the definition provide here is general and vauge and (b) the 9293 term could easily be confused with "operations security", which is 9294 a different concept. 9296 Tutorial: For example, in the context of an Internet service 9297 provider, the term could refer to capabilities to manage network 9298 devices in the event of attacks, simplify troubleshooting, keep 9299 track of events that affect system integrity, help analyze sources 9300 of attacks, and provide administrators with control over network 9301 addresses and protocols to help mitigate the most common attacks 9302 and exploits. [R3871] 9304 2. (D) Synonym for "administrative security". 9306 Deprecated Definition: ISDs SHOULD NOT use this term as a synonym 9307 for "administrative security". Any type of security may affect 9308 system operations; therefore, the term may be misleading. Instead, 9309 use "administrative security", "communication security", "computer 9310 security", "emanations security", "personnel security", "physical 9311 security", or whatever specific type is meant. (See: security 9312 architecture. Compare: operational integrity, OPSEC.) 9314 $ operations security (OPSEC) 9315 (I) A process to identify, control, and protect evidence of the 9316 planning and execution of sensitive activities and operations, and 9317 thereby prevent potential adversaries from gaining knowledge of 9318 capabilities and intentions. (See: communications cover. Compare: 9319 operational security.) 9321 $ operator 9322 (I) A person who has been authorized to direct selected functions 9323 of a system. (Compare: manager.) 9325 Usage: ISDs that use this term SHOULD state a definition for it 9326 because a system operator may or may not be treated as a "user". 9328 $ OPSEC 9329 1. (I) Abbreviation for "operations security". 9331 2. (D) Abbreviation for "operational security". 9333 Deprecated Usage: ISDs SHOULD NOT use this abbreviation for 9334 "operational security" (as defined in this Glossary), because its 9335 use for "operations security" has been well established for many 9336 years, particular in the military community. 9338 $ ORA 9339 See: organizational registration authority. 9341 $ Orange Book 9342 (D) /slang/ Synonym for "Trusted Computer System Evaluation 9343 Criteria" [CSC001, DoD1]. 9345 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 9346 "Trusted Computer System Evaluation Criteria" [CSC001, DoD1]. 9347 Instead, use the full, proper name of the document or, in 9348 subsequent references, the abbreviation "TCSEC". (See: Deprecated 9349 Usage under "Green Book".) 9351 $ organizational certificate 9352 (I) An X.509 certificate in which the "subject" field contains the 9353 name of an institution or set (e.g., a business, government, 9354 school, labor union, club, ethnic group, nationality, system, or 9355 group of individuals playing the same role), rather than the name 9356 of an individual person or device. (Compare: persona certificate, 9357 role certificate.) 9359 Tutorial: Such a certificate might be issued for one of the 9360 following purposes: 9361 - To enable an individual to prove membership in the 9362 organization. 9363 - To enable an individual to represent the organization, i.e., to 9364 act in its name and with it powers or permissions. 9366 (O) /MISSI/ A type of MISSI X.509 public-key certificate that is 9367 issued to support organizational message handling for the U.S. 9368 DoD's Defense Message System. 9370 $ organizational registration authority (ORA) 9371 1. (I) /PKI/ An RA for an organization. 9373 2. (O) /MISSI/ An end entity that (a) assists a PCA, CA, or SCA to 9374 register other end entities, by gathering, verifying, and entering 9375 data and forwarding it to the signing authority and (b) may also 9376 assist with card management functions. An ORA is a local 9377 administrative authority, and the term refers both to the role and 9378 to the person who plays that role. An ORA does not sign 9379 certificates, CRLs, or CKLs. (See: no-PIN ORA, SSO-PIN ORA, user- 9380 PIN ORA.) 9382 $ origin authentication 9383 (D) Synonym for "data origin authentication". (See: 9384 authentication, data origin authentication.) 9386 Deprecated Term: ISDs SHOULD NOT use this term; it suggests 9387 careless use of the internationally standardized term "data origin 9388 authentication" and also could be confused with "peer entity 9389 authentication." 9391 $ origin authenticity 9392 (D) Synonym for "data origin authentication". (See: authenticity, 9393 data origin authentication.) 9395 Deprecated Term: ISDs SHOULD NOT use this term; it suggests 9396 careless use of the internationally standardized term "data origin 9397 authentication" and mixes concepts in a potentially misleading 9398 way. 9400 $ OSI, OSIRM 9401 (N) See: Open Systems Interconnection Reference Model. 9403 $ OSIRM Security Architecture 9404 (N) The part of the OSIRM [I7498-2] that specifies the security 9405 services and security mechanisms that can be applied to protect 9406 communications between two systems. (See: security architecture.) 9408 Tutorial: This part of the OSIRM includes an allocation of 9409 security services to protocol layers. The following table show 9410 which security services (see definitions in this Glossary) are 9411 permitted by the OSIRM in each of its layer. (Also, an application 9412 process that operates above the Application Layer may itself 9413 provide security services.) Similarly, the table suggests which 9414 services are suitable for each IPS layer. However, explaining and 9415 justifying these allocations is beyond the scope of this Glossary. 9417 Legend for Table Entries: 9418 O = Yes, [IS7498-2] permits the service in this OSIRM layer. 9419 I = Yes, the service can be incorporated in this IPS layer. 9421 IPS Protocol Layers +-----------------------------------------+ 9422 |Network| Net |In-| Trans | Application | 9423 | H/W |Inter|ter| -port | | 9424 | |-face|net| | | 9425 OSIRM Protocol Layers +-----------------------------------------+ 9426 | 1 | 2 | 3 | 4 | 5 | 6 | 7 # | 9427 Confidentiality +-----------------------------------------+ 9428 - Datagram | O I | O I | O I | O I | | O * | O I | 9429 - Selective Field | | | I | | | O * | O I | 9430 - Traffic Flow | O | | O | | | | O | 9431 -- Full | I | | | | | | | 9432 -- Partial | | I | I | | | | I | 9433 Integrity +-----------------------------------------+ 9434 - Datagram | I | I | O I | O I | | | O I | 9435 - Selective Field | | | I | | | | O I | 9436 - Stream | | | O I | O I | | | O I | 9437 Authentication +-----------------------------------------+ 9438 - Peer Entity | | I | O I | O I | | | O I | 9439 - Data Origin | | I | O I | O I | | | O I | 9440 Access Control +-----------------------------------------+ 9441 - type as appropriate | | I | O I | O I | | | O I | 9442 Non-Repudiation +-----------------------------------------+ 9443 - of Origin | | | | | | | O I | 9444 - of Receipt | | | | | | | O I | 9445 +-----------------------------------------+ 9447 $ OTAR 9448 (N) See: over-the-air rekeying. 9450 $ OTP 9451 (I) See: One-Time Password. 9453 $ out-of-band 9454 (I) /adjective, adverb/ Information transfer using a channel or 9455 method that is outside (i.e., separate from or different from) the 9456 main channel or normal method. 9458 Tutorial: Out-of-band mechanisms are often used to distribute 9459 shared secrets (e.g., a symmetric key) or other sensitive 9460 information items (e.g., a root key) that are needed to initialize 9461 or otherwise enable the operation of cryptography or other 9462 security mechanisms. Example: Using postal mail to distribute 9463 printed or magnetic media containing symmetric cryptographic keys 9464 for use in Internet encryption devices. (See: key distribution.) 9466 $ output feedback (OFB) 9467 (N) A block cipher mode [FP081] that modifies ECB mode to operate 9468 on plaintext segments of variable length less than or equal to the 9469 block length. 9471 Tutorial: This mode operates by directly using the algorithm's 9472 previously generated output block as the algorithm's next input 9473 block (i.e., by "feeding back" the output block) and combining 9474 (exclusive OR-ing) the output block with the next plaintext 9475 segment (of block length or less) to form the next ciphertext 9476 segment. 9478 $ outside attack 9479 (I) See: secondary definition under "attack". Compare: outsider.) 9481 $ outsider 9482 (I) A user (usually a person) that accesses a system from a 9483 position that is outside the system's security perimeter. 9484 (Compare: authorized user, insider, unauthorized user.) 9486 Tutorial: The actions performed by an outsider in accessing the 9487 system may be either authorized or unauthorized; i.e., an outsider 9488 may act either as an authorized user or as an unauthorized user. 9490 $ over-the-air rekeying (OTAR) 9491 (N) Changing a key in a remote cryptographic device by sending a 9492 new key directly to the device via a channel that the device is 9493 protecting. [C4009] 9495 $ overload 9496 (I) /threat action/ See: secondary definition under "obstruction". 9498 $ P1363 9499 (N) See: IEEE P1363. 9501 $ PAA 9502 (O) See: policy approving authority. 9504 $ package 9505 (N) /Common Criteria/ A reusable set of either functional or 9506 assurance components (e.g. an EAL), combined in a single unit to 9507 satisfy a set of identified security objectives. Example: The 9508 seven EALs defined in Part 3 of the Common Criteria are predefined 9509 assurance packages. (Compare: protection profile.) 9511 Tutorial: A package is a combination of security requirement 9512 components and is intended to be reusable in the construction of 9513 either more complex packages or protection profiles and security 9514 targets. A package expresses a set of either functional or 9515 assurance requirements that meet some particular need, expressed 9516 as a set of security objectives. 9518 $ packet 9519 (I) A block of data that is carried from a source to a destination 9520 through a communication channel or, more generally, across a 9521 network. (Compare: datagram, PDU.) 9523 $ packet filter 9524 (I) See: secondary definition under "filtering router". 9526 $ packet monkey 9527 (D) /slang/ Someone who floods a system with packets, creating a 9528 denial-of-service condition for the system's users. (See: 9529 cracker.) 9531 Deprecated Term: To avoid international misunderstanding, ISDs 9532 SHOULD NOT use this term. (See: Deprecated Usage under "Green 9533 Book".) 9535 $ pagejacking 9536 (D) /slang/ A contraction of "Web page hijacking". A masquerade 9537 attack in which the attacker copies (steals) a home page or other 9538 material from the target server, rehosts the page on a server the 9539 attacker controls, and causes the rehosted page to be indexed by 9540 the major Web search services, thereby diverting browsers from the 9541 target server to the attacker's server. 9543 Deprecated Term: ISDs SHOULD NOT use this contraction. The term is 9544 not listed in most dictionaries and could confuse international 9545 readers. (See: Deprecated Usage under "Green Book".) 9547 $ PAN 9548 (O) See: primary account number. 9550 $ PAP 9551 (I) See: Password Authentication Protocol. 9553 $ parity bit 9554 (I) A checksum that is computed on a block of bits by computing 9555 the binary sum of the individual bits in the block and then 9556 discarding all but the low-order bit of the sum. (See: checksum.) 9558 $ partitioned security mode 9559 (N) A mode of system operation wherein all users having access to 9560 the system have the necessary security clearances for all data 9561 handled by the system, but some users might not have either formal 9562 access approval or need-to-know for all the data. (See: /system 9563 operation/ under "mode", formal access approval, need to know, 9564 protection level, security clearance.) 9566 Usage: Usually abbreviated as "partitioned mode". This term was 9567 defined in U.S. Government policy on system accreditation. 9569 $ PASS 9570 (N) See: personnel authentication system string. 9572 $ passive attack 9573 (I) See: secondary definition under "attack". 9575 $ passive user 9576 (I) See: secondary definition under "user". 9578 $ passive wiretapping 9579 (I) A wiretapping attack that attempts only to observe a 9580 communication flow and gain knowledge of the data it contains, but 9581 does not alter or otherwise affect that flow. (See: wiretapping. 9582 Compare: passive attack, active wiretapping.) 9584 $ password 9585 (I) A secret data value, usually a character string, that is 9586 presented to a system by a user to authenticate the user's 9587 identity. (See: authentication information, challenge-response, 9588 PIN, simple authentication.) 9590 (O) "A character string used to authenticate an identity." [CSC2] 9592 (O) "A string of characters (letters, numbers, and other symbols) 9593 used to authenticate an identity or to verify access 9594 authorization." [FP140] 9596 (O) "A secret that a claimant memorizes and uses to authenticate 9597 his or her identity. Passwords are typically character strings." 9598 [SP63] 9600 Tutorial: A password is usually paired with a user identifier that 9601 is explicit in the authentication process, although in some cases 9602 the identifier may be implicit. A password is usually verified by 9603 matching it to a stored value held by the access control system 9604 for that identifier. 9606 Using a password as authentication information is based on 9607 assuming that the password is known only by the system entity for 9608 which the identity is being authenticated. Therefore, in a network 9609 environment where wiretapping is possible, simple authentication 9610 that relies on transmission of static (i.e., repetitively used) 9611 passwords in cleartext form is inadequate. (See: one-time 9612 password, strong authentication.) 9614 $ Password Authentication Protocol (PAP) 9615 (I) A simple authentication mechanism in PPP. In PAP, a user 9616 identifier and password are transmitted in cleartext form. [R1334] 9617 (See: CHAP.) 9619 $ password sniffing 9620 (I) Passive wiretapping, usually on a LAN, to gain knowledge of 9621 passwords. (See: Deprecated Usage under "sniffing".) 9623 $ path discovery 9624 (I) For a digital certificate, the process of finding a set of 9625 public-key certificates that comprise a certification path from a 9626 trusted key to that specific certificate. 9628 $ path validation 9629 (I) The process of validating (a) all of the digital certificates 9630 in a certification path and (b) the required relationships between 9631 those certificates, thus validating the contents of the last 9632 certificate on the path. (See: certificate validation.) 9634 Tutorial: To promote interoperable PKI applications in the 9635 Internet, RFC 3280 specifies a detailed algorithm for validation 9636 of a certification path. 9638 $ payment card 9639 (N) /SET/ Collectively refers "to credit cards, debit cards, 9640 charge cards, and bank cards issued by a financial institution and 9641 which reflects a relationship between the cardholder and the 9642 financial institution." [SET2] 9644 $ payment gateway 9645 (O) /SET/ A system operated by an acquirer, or a third party 9646 designated by an acquirer, for the purpose of providing electronic 9647 commerce services to the merchants in support of the acquirer, and 9648 which interfaces to the acquirer to support the authorization, 9649 capture, and processing of merchant payment messages, including 9650 payment instructions from cardholders. [SET1, SET2] 9652 $ payment gateway certification authority (SET PCA) 9653 (O) /SET/ A CA that issues digital certificates to payment 9654 gateways and is operated on behalf of a payment card brand, an 9655 acquirer, or another party according to brand rules. A SET PCA 9656 issues a CRL for compromised payment gateway certificates. [SET2] 9657 (See: PCA.) 9659 $ PC card 9660 (N) A type of credit card-sized, plug-in peripheral device that 9661 was originally developed to provide memory expansion for portable 9662 computers, but is also used for other kinds of functional 9663 expansion. (See: FORTEZZA, PCMCIA.) 9665 Tutorial: The international PC Card Standard defines a non- 9666 proprietary form factor in three sizes -- Types I, II and III -- 9667 each of which have a 68-pin interface between the card and the 9668 socket into which it plugs. All three types have the same length 9669 and width, roughly the size of a credit card, but differ in their 9670 thickness from 3.3 to 10.5 mm. Examples include storage modules, 9671 modems, device interface adapters, and cryptographic modules. 9673 $ PCA 9674 (D) Abbreviation of various kinds of "certification authority". 9675 (See: Internet policy certification authority, (MISSI) policy 9676 creation authority, (SET) payment gateway certification 9677 authority.) 9679 Deprecated Abbreviation: An ISD that uses this abbreviation SHOULD 9680 define it at the point of first use. 9682 $ PCI 9683 (N) See: "protocol control information" under "protocol data 9684 unit". 9686 $ PCMCIA 9687 (N) Personal Computer Memory Card International Association, a 9688 group of manufacturers, developers, and vendors, founded in 1989 9689 to standardize plug-in peripheral memory cards for personal 9690 computers and now extended to deal with any technology that works 9691 in the PC Card form factor. (See: PC card.) 9693 $ PDS 9694 (N) See: protective distribution system. 9696 $ PDU 9697 (N) See: protocol data unit. 9699 $ peer entity authentication 9700 (I) "The corroboration that a peer entity in an association is the 9701 one claimed." [I7498 Part 2] (See: authentication.) 9703 $ peer entity authentication service 9704 (I) A security service that verifies an identity claimed by or for 9705 a system entity in an association. (See: authentication, 9706 authentication service.) 9708 Tutorial: This service is used at the establishment of, or at 9709 times during, an association to confirm the identity of one entity 9710 to another, thus protecting against a masquerade by the first 9711 entity. However, unlike data origin authentication service, this 9712 service requires an association to exist between the two entities, 9713 and the corroboration provided by the service is valid only at the 9714 current time that the service is provided. (See: "relationship 9715 between data integrity service and authentication services" under 9716 "data integrity service"). 9718 $ PEM 9719 (I) See: Privacy Enhanced Mail. 9721 $ penetrate 9722 1a. Circumvent a system's security protections. (See: attack, 9723 break, violation.) 9725 1b. (I) Successfully and repeatedly gain unauthorized access to a 9726 protected system resource. [Huff] 9728 $ penetration test 9729 (I) A system test, often part of system certification, in which 9730 evaluators attempt to circumvent the security features of a 9731 system. [NCS04, SP42] (See: tiger team.) 9733 Tutorial: Penetration testing evaluates the relative vulnerability 9734 of a system to attacks and identifies methods of gaining access to 9735 a system by using tools and techniques that are available to 9736 adversaries. Testing may be performed under various constraints 9737 and conditions, including a specified level of knowledge of the 9738 system design and implementation. For a TCSEC evaluation, testers 9739 are assumed to have all system design and implementation 9740 documentation, including source code, manuals, and circuit 9741 diagrams, and to work under no greater constraints than those 9742 applied to ordinary users. 9744 $ perfect forward secrecy 9745 (I) See: Usage under "public-key forward secrecy". 9747 $ perimeter 9748 See: security perimeter. 9750 $ periods processing 9751 (I) A mode of system operation in which information of different 9752 sensitivities is processed at distinctly different times by the 9753 same system, with the system being properly purged or sanitized 9754 between periods. (See: color change.) 9756 Tutorial: The security mode of operation and maximum 9757 classification of data handled by the system is established for an 9758 interval of time and then is changed for the following interval of 9759 time. A period extends from the secure initialization of the 9760 system to the completion of any purging of sensitive data handled 9761 by the system during the period. 9763 $ permanent storage 9764 (I) Non-volatile media that, once written into, can never be 9765 completely erased. 9767 $ permission 9768 1a. (I) A synonym for "authorization". (Compare: privilege.) 9770 1b. (N) An authorization or set of authorizations to perform 9771 security-relevant functions in the context of role-based access 9772 control. [ANSI] 9774 Tutorial: A permission is a positively stated authorization for 9775 access that (a) can be associated with one or more roles and (b) 9776 enables a user in a role to access a specified set of system 9777 resources by causing a specific set of system actions to be 9778 performed on the resources. 9780 $ persona certificate 9781 (I) An X.509 certificate issued to a system entity that wishes to 9782 use a persona to conceal its true identity when using PEM or other 9783 Internet services that depend on PKI support. (See: anonymity.) 9784 [R1422] 9786 Tutorial: PEM designers intended that (a) a CA issuing persona 9787 certificates would explicitly not be vouching for the identity of 9788 the system entity to whom the certificate is issued, (b) such 9789 certificates would be issued only by CAs subordinate to a policy 9790 CA having a policy stating that purpose (i.e., that would warn 9791 relying parties that the "subject" field DN represented only a 9792 persona and not a true, vetted user identity), and (c) the CA 9793 would not need to maintain records binding the true identity of 9794 the subject to the certificate. 9796 However, the PEM designers also intended that a CA issuing persona 9797 certificates would establish procedures (d) to enable "the holder 9798 of a PERSONA certificate to request that his certificate be 9799 revoked" and (e) to ensure that it did not issue the same subject 9800 DN to multiple users. The latter condition implies that a persona 9801 certificate is not an organizational certificate unless the 9802 organization has just one member or representative. 9804 $ personal identification number (PIN) 9805 1a. (I) A character string used as a password to gain access to a 9806 system resource. (See: authentication information.) 9808 1b. (O) An alphanumeric code or password used to authenticate an 9809 identity. 9811 Tutorial: Despite the words "identification" and "number", a PIN 9812 seldom serves as a user identifier, and a PIN's characters are not 9813 necessarily all numeric. Retail banking applications use 4-digit 9814 numeric user PINs, but the FORTEZZA PC card uses 12-character 9815 alphanumeric SSO PINs. 9817 Thus, a better name for this concept would have been "personnel 9818 authentication system string" (PASS), in which case an 9819 alphanumeric character string for this purpose would have been 9820 called, obviously, a "PASSword". 9822 $ personal information 9823 (I) Information about a particular person, especially information 9824 of an intimate or critical nature, that could cause harm or pain 9825 to that person if disclosed to unauthorized parties. Examples: 9826 medical record, arrest record, credit report, academic transcript, 9827 training report, job application, credit card number, Social 9828 Security number. (See: privacy.) 9830 $ personality 9831 1. (I) Synonym for "principal". 9833 2. (O) /MISSI/ A set of MISSI X.509 public-key certificates that 9834 have the same subject DN, together with their associated private 9835 keys and usage specifications, that is stored on a FORTEZZA PC 9836 card to support a role played by the card's user. 9838 Tutorial: When a card's user selects a personality to use in a 9839 FORTEZZA-aware application, the data determines behavior traits 9840 (the personality) of the application. A card's user may have 9841 multiple personalities on the card. Each has a "personality 9842 label", a user-friendly character string that applications can 9843 display to the user for selecting or changing the personality to 9844 be used. For example, a military user's card might contain three 9845 personalities: GENERAL HALFTRACK, COMMANDER FORT SWAMPY, and NEW 9846 YEAR'S EVE PARTY CHAIRMAN. Each personality includes one or more 9847 certificates of different types (such as DSA versus RSA), for 9848 different purposes (such as digital signature versus encryption), 9849 or with different authorizations. 9851 $ personnel authentication system string (PASS) 9852 (N) See: Tutorial under "personal identification number". 9854 $ personnel security 9855 (I) Procedures to ensure that persons who access a system have 9856 proper clearance, authorization, and need-to-know as required by 9857 the system's security policy. 9859 $ PGP(trademark) 9860 (O) See: Pretty Good Privacy(trademark). 9862 $ phase 1 negotiation 9863 $ phase 2 negotiation 9864 (I) /ISAKMP/ See: secondary definition under "Internet Security 9865 Association and Key Management Protocol". 9867 $ Photuris 9868 (I) A UDP-based, key establishment protocol for session keys, 9869 designed for use with the IPsec protocols AH and ESP. Superseded 9870 by IKE. 9872 $ phreaking 9873 (D) A contraction of "telephone breaking". An attack on or 9874 penetration of a telephone system or, by extension, any other 9875 communication or information system. [Raym] 9877 Deprecated Term: ISDs SHOULD NOT use this contraction; it is not 9878 listed in most dictionaries and could confuse international 9879 readers. 9881 $ physical security 9882 (I) Tangible means of preventing unauthorized physical access to a 9883 system. Examples: Fences, walls, and other barriers; locks, safes, 9884 and vaults; dogs and armed guards; sensors and alarm bells. 9885 [FP031, R1455] 9887 $ piggyback attack 9888 (I) A form of active wiretapping in which the attacker gains 9889 access to a system via intervals of inactivity in another user's 9890 legitimate communication connection. Sometimes called a "between- 9891 the-lines" attack. (See: hijack attack, man-in-the-middle attack.) 9893 Deprecated Usage: ISDs that use this term SHOULD state a 9894 definition for it because the term could confuse international 9895 readers. 9897 $ PIN 9898 (I) See: personal identification number. 9900 $ ping of death 9901 (D) A denial-of-service attack that sends an improperly large ICMP 9902 echo request packet (a "ping") with the intent of causing the 9903 destination system to fail. (See: ping sweep, teardrop.) 9905 Deprecated Term: ISDs SHOULD NOT use this term; instead, use "ping 9906 packet overflow attack" or some other term that is specific with 9907 regard to the attack mechanism. 9909 Tutorial: This attack seeks to exploit an implementation 9910 vulnerability. The IP specification requires hosts to be prepared 9911 to accept datagrams of up to 576 octets, but also permits IP 9912 datagrams to be up to 65,535 octets long. If an IP implementation 9913 does not properly handle very long IP packets, the ping packet may 9914 overflow the input buffer and cause a fatal system error. 9916 $ ping sweep 9917 (I) An attack that sends ICMP echo requests ("pings") to a range 9918 of IP addresses, with the goal of finding hosts that can be probed 9919 for vulnerabilities. (See: ping of death. Compare: port scan.) 9921 $ PKCS 9922 (N) See: Public-Key Cryptography Standards. 9924 $ PKCS #5 9925 (N) A standard [PKC05, R2898] from the PKCS series; defines a 9926 method for encrypting an octet string with a secret key derived 9927 from a password. 9929 Tutorial: Although the method can be used for arbitrary octet 9930 strings, its intended primary application in public-key 9931 cryptography is for encrypting private keys when transferring them 9932 from one computer system to another, as described in PKCS #8. 9934 $ PKCS #7 9935 (N) A standard [PKC07, R2315] from the PKCS series; defines a 9936 syntax for data that may have cryptography applied to it, such as 9937 for digital signatures and digital envelopes. (See: CMS.) 9939 $ PKCS #10 9940 (N) A standard [PKC10] from the PKCS series; defines a syntax for 9941 requests for public-key certificates. (See: certification 9942 request.) 9944 Tutorial: A PKCS #10 request contains a DN and a public key, and 9945 may contain other attributes, and is signed by the entity making 9946 the request. The request is sent to a CA, who converts it to an 9947 X.509 public-key certificate (or some other form), and returns it, 9948 possibly in PKCS #7 format. 9950 $ PKCS #11 9951 (N) A standard [PKC11] from the PKCS series; defines CAPI called 9952 "Cryptoki" for devices that hold cryptographic information and 9953 perform cryptographic functions. 9955 $ PKI 9956 (I) See: public-key infrastructure. 9958 $ PKIX 9959 1a. (I) A contraction of "Public-Key Infrastructure (X.509)", the 9960 name of the IETF working group that is specifying an architecture 9961 [R3280] and set of protocols [R2510] to provide X.509-based PKI 9962 services for the Internet. 9964 1b. (I) A collective name for that Internet PKI architecture and 9965 associated set of protocols. 9967 Tutorial: The goal of PKIX is to facilitate the use of X.509 9968 public-key certificates in multiple Internet applications and to 9969 promote interoperability between different implementations that 9970 use those certificates. The resulting PKI is intended to provide a 9971 framework that supports a range of trust and hierarchy 9972 environments and a range of usage environments. PKIX specifies (a) 9973 profiles of the v3 X.509 public-key certificate standards and the 9974 v2 X.509 CRL standards for the Internet, (b) operational protocols 9975 used by relying parties to obtain information such as certificates 9976 or certificate status, (c) management protocols used by system 9977 entities to exchange information needed for proper management of 9978 the PKI, and (d) information about certificate policies and CPSs, 9979 covering the areas of PKI security not directly addressed in the 9980 rest of PKIX. 9982 $ plain text 9983 (I) /noun/ Data that is input to and transformed by an encryption 9984 process, or that is output from a decryption process. (See: 9985 plaintext. Compare: cipher text, clear text.) 9987 Tutorial: Usually, the plain text that is the input to an 9988 encryption operation is clear text, but the input could be cipher 9989 text that was output from another encryption operation. (See: 9990 superencryption.) 9992 $ plaintext 9993 1. (I) /adjective/ Referring to plain text. (See: plain text. 9994 Compare: ciphertext, cleartext.) 9996 2. (D) /noun/ A synonym for plain text. 9998 Deprecated Usage: ISDs should not use this term as a synonym for 9999 "plain text". ISDs SHOULD distinguish between the adjective 10000 "plaintext" and the noun phrase "plain text". 10002 $ PLI 10003 (I) See: Private Line Interface. 10005 $ Point-to-Point Protocol (PPP) 10006 (I) An Internet Standard protocol (RFC 1661) for encapsulation and 10007 full-duplex transportation of protocol data packets in OSIRM Layer 10008 3 over an OSIRM Layer 2 link between two peers, and for 10009 multiplexing different Layer 3 protocols over the same link. 10010 Includes optional negotiation to select and use a peer entity 10011 authentication protocol to authenticate the peers to each other 10012 before they exchange Layer 3 data. (See: CHAP, EAP, PAP.) 10014 $ Point-to-Point Tunneling Protocol (PPTP) 10015 (I) An Internet client-server protocol (RFC 2637) (originally 10016 developed by Ascend and Microsoft) that enables a dial-up user to 10017 create a virtual extension of the dial-up link across a network by 10018 tunneling PPP over IP. (See: L2TP.) 10020 Tutorial: PPP can encapsulate any IPS Network Interface Layer 10021 protocol or OSIRM Layer 3 protocol. Therefore, PPTP does not 10022 specify security services; it depends on protocols above and below 10023 it to provide any needed security. PPTP makes it possible to 10024 divorce the location of the initial dial-up server (i.e., the PPTP 10025 Access Concentrator, the client, which runs on a special-purpose 10026 host) from the location at which the dial-up protocol (PPP) 10027 connection is terminated and access to the network is provided 10028 (i.e., at the PPTP Network Server, which runs on a general-purpose 10029 host). 10031 $ policy 10032 1a. (I) A plan or course of action that is stated for a system or 10033 organization and is intended to affect and direct the decisions 10034 and deeds of that entity's components or members. (See: security 10035 policy.) 10037 1b. (O) A definite goal, course, or method of action to guide and 10038 determine present and future decisions, that is implemented or 10039 executed within a particular context, such as within a business 10040 unit. [R3198] 10042 Deprecated Abbreviation: ISDs SHOULD NOT use "policy" as an 10043 abbreviation of either "security policy" or "certificate policy". 10044 Instead, to avoid misunderstanding, use a fully qualified term, at 10045 least at the point of first usage. 10047 Tutorial: The introduction of new technology to replace 10048 traditional systems can result in new systems being deployed 10049 without adequate policy definition and before the implications of 10050 the new technology are fully understand. In some cases, it can be 10051 difficult to establish policies for new technology before the 10052 technology has been operationally tested and evaluated. Thus, 10053 policy changes tend to lag behind technological changes, such that 10054 either old policies impede the technical innovation, or the new 10055 technology is deployed without adequate policies to govern its 10056 use. 10058 When new technology changes the ways that things are done, new 10059 "procedures" must be defined to establish operational guidelines 10060 for using the technology and achieving satisfactory results, and 10061 new "practices" must be established for managing new systems and 10062 monitoring results. Practices and procedures are more directly 10063 coupled to actual systems and business operations than are 10064 polices, which tend to be more abstract. 10065 - "Practices" define how a system is to be managed and what 10066 controls are in place to monitor the system and detect abnormal 10067 behavior or quality problems. Practices are established to 10068 ensure that a system is managed in compliance with stated 10069 policies. System audits are primarily concerned with whether or 10070 not practices are being followed. Auditors evaluate the 10071 controls to make sure they conform to accepted industry 10072 standards, and then confirm that controls are in place and that 10073 control measurements are being gathered. Audit trails are 10074 examples of control measurements that are recorded as part of 10075 system operations. 10076 - "Procedures" define how a system is operated, and relate 10077 closely to issues of what technology is used, who the operators 10078 are, and how the system is deployed physically. Procedures 10079 define both normal and abnormal operating circumstances. 10080 - For every control defined by a practice statement, there should 10081 be corresponding procedures to implement the control and 10082 provide ongoing measurement of the control parameters. 10083 Conversely, procedures require management practices to insure 10084 consistent and correct operational behavior. 10086 $ policy approving authority (PAA) 10087 (O) /MISSI/ The top-level signing authority of a MISSI 10088 certification hierarchy. The term refers both to that 10089 authoritative office or role and to the person who plays that 10090 role. (See: root registry.) 10092 Tutorial: A PAA registers MISSI PCAs and signs their X.509 public- 10093 key certificates. A PAA issues CRLs but does not issue a CKL. A 10094 PAA may issue cross-certificates to other PAAs. 10096 $ policy certification authority (Internet PCA) 10097 (I) An X.509-compliant CA at the second level of the Internet 10098 certification hierarchy, under the IPRA. Each PCA operates in 10099 accordance with its published security policy (see: certificate 10100 policy, CPS) and within constraints established by the IPRA for 10101 all PCAs. [R1422]. (See: policy creation authority.) 10103 $ policy creation authority (MISSI PCA) 10104 (O) /MISSI/ The second level of a MISSI certification hierarchy; 10105 the administrative root of a security policy domain of MISSI users 10106 and other, subsidiary authorities. The term refers both to that 10107 authoritative office or role and to the person who fills that 10108 office. (See: policy certification authority.) 10110 Tutorial: A MISSI PCA's certificate is issued by a PAA. The PCA 10111 registers the CAs in its domain, defines their configurations, and 10112 issues their X.509 public-key certificates. (The PCA may also 10113 issue certificates for SCAs, ORAs, and other end entities, but a 10114 PCA does not usually do this.) The PCA periodically issues CRLs 10115 and CKLs for its domain. 10117 $ Policy Management Authority 10118 (O) Canadian usage: An organization responsible for PKI oversight 10119 and policy management in the Government of Canada. 10121 $ policy mapping 10122 (I) "Recognizing that, when a CA in one domain certifies a CA in 10123 another domain, a particular certificate policy in the second 10124 domain may be considered by the authority of the first domain to 10125 be equivalent (but not necessarily identical in all respects) to a 10126 particular certificate policy in the first domain." [X509] 10128 $ policy rule 10129 (I) A building block of a security policy; it (a) defines a set of 10130 system conditions and (b) specifies a set of system actions that 10131 are to be performed if those conditions occur. [R3198] 10133 $ POP3 10134 (I) See: Post Office Protocol, version 3. 10136 $ POP3 APOP 10137 (I) A POP3 command (better described as a transaction type, or 10138 subprotocol) by which a POP3 client optionally uses a keyed hash 10139 (based on MD5) to authenticate itself to a POP3 server and, 10140 depending on the server implementation, to protect against replay 10141 attacks. (See: CRAM, POP3 AUTH, IMAP4 AUTHENTICATE.) 10143 Tutorial: The server includes a unique timestamp in its greeting 10144 to the client. The subsequent APOP command sent by the client to 10145 the server contains the client's name and the hash result of 10146 applying MD5 to a string formed from both the timestamp and a 10147 shared secret value that is known only to the client and the 10148 server. APOP was designed to provide an alternative to using 10149 POP3's USER and PASS (i.e., password) command pair, in which the 10150 client sends a cleartext password to the server. 10152 $ POP3 AUTH 10153 (I) A POP3 command [R1734] (better described as a transaction 10154 type, or subprotocol) by which a POP3 client optionally proposes a 10155 mechanism to a POP3 server to authenticate the client to the 10156 server and provide other security services. (See: POP3 APOP, IMAP4 10157 AUTHENTICATE.) 10159 Tutorial: If the server accepts the proposal, the command is 10160 followed by performing a challenge-response authentication 10161 protocol and, optionally, negotiating a protection mechanism for 10162 subsequent POP3 interactions. The security mechanisms used by POP3 10163 AUTH are those used by IMAP4. 10165 $ port scan 10166 (I) An attack that sends client requests to a range of server port 10167 addresses on a host, with the goal of finding an active port and 10168 exploiting a known vulnerability of that service. (Compare: ping 10169 sweep.) 10171 $ positive authorization 10172 (I) The principle that a security architecture should be designed 10173 so that access to system resources is granted only in a positive 10174 way; i.e., in the absence of an explicit authorization that grants 10175 access, the default action shall be to refuse access. 10177 $ POSIX 10178 (N) Portable Operating System Interface for Computer Environments, 10179 a standard [FP151, IS9945-1] (originally IEEE Standard P1003.1) 10180 that defines an operating system interface and environment to 10181 support application portability at the source code level. It is 10182 intended to be used by both application developers and system 10183 implementers. 10185 Tutorial: P1003.1 supports security functionality like that on 10186 most UNIX systems, including discretionary access control and 10187 privileges. IEEE Draft Standard P1003.6 specifies additional 10188 functionality not provided in the base standard, including (a) 10189 discretionary access control, (b) audit trail mechanisms, (c) 10190 privilege mechanisms, (d) mandatory access control, and (e) 10191 information label mechanisms. 10193 $ Post Office Protocol, version 3 (POP3) 10194 (I) An Internet Standard protocol (RFC 1939) by which a client 10195 workstation can dynamically access a mailbox on a server host to 10196 retrieve mail messages that the server has received and is holding 10197 for the client. (See: IMAP4.) 10199 Tutorial: POP3 has mechanisms for optionally authenticating a 10200 client to a server and providing other security services. (See: 10201 POP3 APOP, POP3 AUTH.) 10203 $ PPP 10204 (I) See: Point-to-Point Protocol. 10206 $ PPTP 10207 (I) See: Point-to-Point Tunneling Protocol. 10209 $ preauthorization 10210 (N) /PKI/ A CAW feature that enables certification requests to be 10211 automatically validated against data provided in advance to the CA 10212 by an authorizing entity. 10214 $ precedence 10215 (N) A designation assigned to a communication (i.e., packet, 10216 message, data stream, connection, etc.) by the originator to state 10217 the importance or urgency of that communication versus other 10218 communications, and thus indicate to the transmission system the 10219 relative order of handling, and indicate to the receiver the order 10220 in which the communication is to be noted. [F1037] (See: 10221 availability, critical, preemption.) 10223 Example: The "Precedence" subfield of the "Type of Service" field 10224 of the IPv4 header supports the following designations (in 10225 descending order of importance): 111 Network Control, 110 10226 Internetwork Control, 101 CRITIC/ECP (Critical Intelligence 10227 Communication/Emergency Command Precedence), 100 Flash Override, 10228 011 Flash, 010 Immediate, 001 Priority, and 000 Routine. These 10229 designations were adopted from U.S. DoD systems that existed 10230 before ARPANET. 10232 $ preemption 10233 (N) The seizure, usually automatic, of system resources that are 10234 being used to serve a lower precedence communication, in order to 10235 serve immediately a higher precedence communication. [F1037] 10237 $ Pretty Good Privacy(trademark) (PGP(trademark)) 10238 (O) Trademarks of Network Associates, Inc., referring to a 10239 computer program (and related protocols) that uses cryptography to 10240 provide data security for electronic mail and other applications 10241 on the Internet. (Compare: MOSS, MSP, PEM, S/MIME.) 10243 Tutorial: PGP encrypts messages with IDEA in CFB mode, distributes 10244 the IDEA keys by encrypting them with RSA, and creates digital 10245 signatures on messages with MD5 and RSA. To establish ownership of 10246 public keys, PGP depends on the web of trust. 10248 $ prevention 10249 (I) See: secondary definition under "security". 10251 $ primary account number (PAN) 10252 (O) /SET/ "The assigned number that identifies the card issuer and 10253 cardholder. This account number is composed of an issuer 10254 identification number, an individual account number 10255 identification, and an accompanying check digit as defined by ISO 10256 7812-1985." [SET2, IS7812] (See: bank identification number.) 10258 Tutorial: The PAN is embossed, encoded, or both on a magnetic- 10259 strip-based credit card. The PAN identifies the issuer to which a 10260 transaction is to be routed and the account to which it is to be 10261 applied unless specific instructions indicate otherwise. The 10262 authority that assigns the BIN part of the PAN is the American 10263 Bankers Association. 10265 $ principal 10266 (I) A specific identity claimed by a user when accessing a system. 10268 Usage: Usually understood to be an identity that is registered in 10269 and authenticated by the system; equivalent to the notion of login 10270 account identifier. Each principal is normally assigned to a 10271 single user, but a single user may be assigned (or attempt to use) 10272 more than one principal. Each principal can spawn one or more 10273 subjects, but each subject is associated with only one principal. 10274 (Compare: role, subject, user.) 10276 (N) /Kerberos/ A uniquely named client or server instance that 10277 participates in a network communication. 10279 $ privacy 10280 1. (I) The right of an entity (normally a person), acting in its 10281 own behalf, to determine the degree to which it will interact with 10282 its environment, including the degree to which the entity is 10283 willing to share its personal information with others. (See: 10284 HIPAA, personal information, Privacy Act of 1974. Compare: 10285 anonymity, data confidentiality.) 10287 2. (O) "The right of individuals to control or influence what 10288 information related to them may be collected and stored and by 10289 whom and to whom that information may be disclosed." [I7498 Part 10290 2] 10292 3. (D) Synonym for "data confidentiality". 10294 Deprecated Definition: ISDs SHOULD NOT use this term as a synonym 10295 for "data confidentiality" or "data confidentiality service", 10296 which are different concepts. Privacy is a reason for security 10297 rather than a kind of security. For example, a system that stores 10298 personal data needs to protect the data to prevent harm, 10299 embarrassment, inconvenience, or unfairness to any person about 10300 whom data is maintained, and to protect the person's privacy. For 10301 that reason, the system may need to provide data confidentiality 10302 service. 10304 $ Privacy Act of 1974 10305 (O) A U.S. Federal law (Section 552a of Title 5, United States 10306 Code) that seeks to balance the U.S. Government's need to maintain 10307 data about individuals with the rights of individuals to be 10308 protected against unwarranted invasions of their privacy stemming 10309 from federal agencies' collection, maintenance, use, and 10310 disclosure of personal data. (See: privacy.) 10312 Tutorial: In 1974, the U.S. Congress was concerned with the 10313 potential for abuses that could arise from the Government's 10314 increasing use of computers to store and retrieve personal data. 10315 Therefore, the Act has four basic policy objectives: 10316 - To restrict disclosure of personally identifiable records 10317 maintained by Federal agencies. 10318 - To grant individuals increased rights of access to Federal 10319 agency records maintained on themselves. 10320 - To grant individuals the right to seek amendment of agency 10321 records maintained on themselves upon a showing that the 10322 records are not accurate, relevant, timely, or complete. 10323 - To establish a code of "fair information practices" that 10324 requires agencies to comply with statutory norms for 10325 collection, maintenance, and dissemination of records. 10327 $ Privacy Enhanced Mail (PEM) 10328 (I) An Internet protocol to provide data confidentiality, data 10329 integrity, and data origin authentication for electronic mail. 10330 [R1421, R1422]. (Compare: MOSS, MSP, PGP, S/MIME.) 10332 Tutorial: PEM encrypts messages with DES in CBC mode, provides 10333 distribution for DES keys by encrypting them with RSA, and signs 10334 messages with RSA over either MD2 or MD5. To establish ownership 10335 of public keys, PEM uses a certification hierarchy, with X.509 10336 public-key certificates and X.509 CRLs that are signed with RSA 10337 and MD2. 10339 PEM is designed to be compatible with a wide range of key 10340 management methods, but is limited to specifying security services 10341 only for text messages and, like MOSS, has not been widely 10342 implemented in the Internet. 10344 $ private component 10345 (I) Synonym for "private key". 10347 Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; 10348 instead, to avoid confusing readers, use "private key". However, 10349 the term MAY be used when discussing a key pair; e.g., "A key pair 10350 has a public component and a private component." 10352 $ private extension 10353 (I) See: secondary definition under "extension". 10355 $ private key 10356 1. (I) The secret component of a pair of cryptographic keys used 10357 for asymmetric cryptography. (See: key pair, public key, secret 10358 key.) 10360 2. (O) In a public key cryptosystem, "that key of a user's key 10361 pair which is known only by that user." [X509] 10363 $ Private Line Interface (PLI) 10364 (I) The first end-to-end packet encryption system for a computer 10365 network, developed by BBN starting in 1975 for the U.S. DoD, 10366 incorporating Government-furnished, military-grade COMSEC 10367 equipment (TSEC/KG-34). [B1822] (Compare: IPLI.) 10369 $ privilege 10370 1a. (I) /access control/ A synonym for "authorization". (See 10371 authorization. Compare: permission.) 10373 1b. (I) /computer platform/ An authorization to perform a 10374 security-relevant function in the context of a computer's 10375 operating system. 10377 $ privilege management infrastructure 10378 (O) "The infrastructure able to support the management of 10379 privileges in support of a comprehensive authorization service and 10380 in relationship with a" PKI; i.e., processes concerned with 10381 attribute certificates. [X509] 10383 Deprecated Usage: ISDs SHOULD NOT use this term with this 10384 definition. This definition is vague, and there is no consensus on 10385 a more specific one. 10387 $ privileged process 10388 (I) An computer process that is authorized (and, therefore, 10389 trusted) to perform some security-relevant functions that ordinary 10390 processes are not. (See: privilege, trusted process.) 10392 $ privileged user 10393 (I) An user that has access to system control, monitoring, or 10394 administration functions. (See: privilege, /UNIX/ under "root", 10395 superuser, user.) 10397 Tutorial: Privileged users include the following types: 10398 - Users with near or complete control of a system, who are 10399 authorized to set up and administer user accounts, identifiers, 10400 and authentication information, or are authorized to assign or 10401 change other users' access to system resources. 10402 - Users that are authorized to change control parameters (e.g., 10403 network addresses, routing tables, processing priorities) on 10404 routers, multiplexers, and other important equipment. 10405 - Users that are authorized to monitor or perform troubleshooting 10406 for a system's security functions, typically using special 10407 tools and features that are not available to ordinary users. 10409 $ probe 10410 (I) /verb/ To access an information system in an attempt to gather 10411 information about the system for the purpose of circumventing the 10412 system's security measures. 10414 $ procedural security 10415 (D) Synonym for "administrative security". 10417 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 10418 "administrative security". The term may be misleading because any 10419 type of security may involve procedures, and procedures may be 10420 either external to the system or internal. Instead, use 10421 "administrative security", "communication security", "computer 10422 security", "emanations security", "personnel security", "physical 10423 security", or whatever specific type is meant. (See: security 10424 architecture.) 10426 $ profile 10427 See: certificate profile, protection profile. 10429 $ proof-of-possession protocol 10430 (I) A protocol whereby a system entity proves to another that it 10431 possesses and controls a cryptographic key or other secret 10432 information. (See: zero-knowledge proof.) 10434 $ proprietary 10435 (I) Refers to information (or other property) that is owned by an 10436 individual or organization and for which the use is restricted by 10437 that entity. 10439 $ protected checksum 10440 (I) A checksum that is computed for a data object by means that 10441 protect against active attacks that would attempt to change the 10442 checksum to make it match changes made to the data object. (See: 10443 digital signature, keyed hash, Tutorial under "checksum".) 10445 $ protective packaging 10446 (N) Packaging techniques for COMSEC material that discourage 10447 penetration, reveal a penetration has occurred or was attempted, 10448 or inhibit viewing or copying of keying material prior to the time 10449 it is exposed for use. [C4008] (See: tamper-evident, tamper- 10450 resistant. Compare: QUADRANT.) 10452 $ protection authority 10453 (I) See: secondary definition under "Internet Protocol Security 10454 Option". 10456 $ protection level 10457 (N) /U.S. Government/ An indication of the trust that is needed in 10458 a system's technical ability to enforce security policy for 10459 confidentiality. (Compare: /system operation/ under "mode of 10460 operation".) 10462 Tutorial: An organization's security policy could define 10463 protection levels that are based on (a) the sensitivity of 10464 information handled by a system compared to (b) the authorizations 10465 of users that receive information from the system without manual 10466 intervention and reliable human review. For each level, the policy 10467 could specify security features and assurances that must be 10468 included in any system that was intended to operate at that level. 10470 Example: Given some set of data objects that are classified at one 10471 or more hierarchical levels and in one or more non-hierarchical 10472 categories, the following table defines five protection levels for 10473 systems that would handle that data. Beginning with PL1 and 10474 evolving to PL5, each successive level would require stronger 10475 features and assurances to handle the dataset. (See: clearance, 10476 formal access approval, and need-to-know.) 10477 Lowest Clearance Formal Access Need-To-Know 10478 Among All Users Approval of Users of Users 10479 +-------------------+-------------------+-------------------+ 10480 PL5 | Some user has no | [Does not matter.]| [Does not matter.]| 10481 High | clearance at all. | | | 10482 +-------------------+-------------------+-------------------+ 10483 PL4 | All are cleared | [Does not matter.]| [Does not matter.]| 10484 | for some data. | | | 10485 +-------------------+-------------------+-------------------+ 10486 PL3 | All are cleared | Some not approved | [Does not matter.]| 10487 | for all data. | for all data. | | 10488 +-------------------+-------------------+-------------------+ 10489 PL2 | All are cleared | All are approved | Some don't need to| 10490 | for all data. | for all data. | to know all data. | 10491 +-------------------+-------------------+-------------------+ 10492 PL1 | All are cleared | All are approved | All have a need | 10493 Low | for all data. | for all data. | to know all data.| 10494 +-------------------+-------------------+-------------------+ 10496 Each of these protection levels can be viewed as being equivalent 10497 to one or more modes of system operation defined in this Glossary: 10498 - PL5 is equivalent to multilevel security mode. 10499 - PL4 is equivalent to either multilevel or compartmented 10500 security mode, depending on the details of users' clearances. 10501 - PL3 is equivalent to partitioned security mode. 10502 - PL2 is equivalent to system-high security mode. 10503 - PL1 is equivalent to dedicated security mode. 10505 $ protection profile 10506 (N) /Common Criteria/ An implementation-independent set of 10507 security requirements for a category of targets of evaluation that 10508 meet specific consumer needs. [CCIB] Example: [IDSAN]. (See: 10509 target of evaluation. Compare: package.) 10511 Tutorial: A protection profile (PP) is the kind of document used 10512 by consumers to specify functional requirements they want in a 10513 product, and a target of evaluation (TOE) is the kind of document 10514 used by vendors to make functional claims about a product. 10516 A PP is intended to be a reusable statement of product security 10517 needs, which are known to be useful and effective, for a set of 10518 information technology security products that could be built. A PP 10519 contains a set of security requirements, preferably taken from the 10520 catalogs in Parts 2 and 3 of the Common Criteria, and should 10521 include an EAL. A PP could be developed by user communities, 10522 product developers, or any other parties interested in defining a 10523 common set of requirements. 10525 $ protection ring 10526 (I) One of a hierarchy of privileged operation modes of a system 10527 that gives certain access rights to processes authorized to 10528 operate in that mode. (See: Multics.) 10530 $ protective distribution system (PDS) 10531 (N) A wireline or fiber-optic communication system used to 10532 transmit cleartext classified information through an area of 10533 lesser classification or control. [N7003] 10535 $ protocol 10536 1a. (I) A set of rules (i.e., formats and procedures) to implement 10537 and control some type of association (e.g., communication) between 10538 systems. Example: Internet Protocol. 10540 1b. (I) A series of ordered computing and communication steps that 10541 are performed by two or more system entities to achieve a joint 10542 objective. [A9042] 10544 $ protocol control information (PCI) 10545 (N) See: secondary definition under "protocol data unit". 10547 $ protocol data unit (PDU) 10548 (N) A data packet that is defined for peer-to-peer transfers in a 10549 protocol layer. 10551 Tutorial: A PDU consists of two disjoint subsets of data: the SDU 10552 and the PCI. (Although these terms -- PDU, SDU, and PCI -- 10553 originated in the OSIRM, they are also useful and permissible in 10554 an IPS context.) 10555 - The "service data unit" (SDU) in a packet is data that the 10556 protocol transfers between peer protocol entities on behalf of 10557 the users of that layer's services. For Layers 1 through 6, the 10558 layer's users are peer protocol entities at a higher layer; for 10559 Layer 7, the users are application entities outside the scope 10560 of the OSIRM. 10561 - The "protocol control information" (PCI) in a packet is data 10562 that peer protocol entities exchange between themselves to 10563 control their joint operation of the layer. 10565 $ protocol suite 10566 (I) A complementary collection of communication protocols used in 10567 a computer network. (See: IPS, OSI.) 10569 $ proxy 10570 1. (I) A computer process that acts on behalf of a user or client. 10572 2. (I) A computer process -- often used as, or as part of, a 10573 firewall -- that relays a protocol between client and server 10574 computer systems, by appearing to the client to be the server and 10575 appearing to the server to be the client. (See: SOCKS.) 10577 Tutorial: In a firewall, a proxy server usually runs on a bastion 10578 host, which may support proxies for several protocols (e.g., FTP, 10579 HTTP, and TELNET). Instead of a client in the protected enclave 10580 connecting directly to an external server, the internal client 10581 connects to the proxy server which in turn connects to the 10582 external server. The proxy server waits for a request from inside 10583 the firewall, forwards the request to the server outside the 10584 firewall, gets the response, then sends the response back to the 10585 client. The proxy may be transparent to the clients, or they may 10586 need to connect first to the proxy server, and then use that 10587 association to also initiate a connection to the real server. 10589 Proxies are generally preferred over SOCKS for their ability to 10590 perform caching, high-level logging, and access control. A proxy 10591 can provide security service beyond that which is normally part of 10592 the relayed protocol, such as access control based on peer entity 10593 authentication of clients, or peer entity authentication of 10594 servers when clients do not have that ability. A proxy at OSIRM 10595 Layer 7 can also provide finer-grained security service than can a 10596 filtering router at Layer 3. For example, an FTP proxy could 10597 permit transfers out of, but not into, a protected network. 10599 $ proxy certificate 10600 (I) An X.509 public-key certificate derived from a end-entity 10601 certificate, or from another proxy certificate, for the purpose of 10602 establishing proxies and delegating authorizations in the context 10603 of a PKI-based authentication system. [R3280] 10605 Tutorial: A proxy certificate has the following properties: 10606 - It contains an critical extension that (a) identifies it as a 10607 proxy certificate and (b) may contain a certification path 10608 length constraint and policy constraints. 10609 - It contains the public component of a key pair that is distinct 10610 from that associated with any other certificate. 10611 - It is signed by the private component of a key pair that is 10612 associated with an end-entity certificate or another proxy 10613 certificate. 10614 - Its associated private key can be used to sign only other proxy 10615 certificates (not end-entity certificates). 10616 - Its "subject" DN is derived from its "issuer" DN and is unique. 10617 - Its "issuer" DN is the "subject" DN of an end-entity 10618 certificate or another proxy certificate. 10620 $ pseudorandom 10621 (I) A sequence of values that appears to be random (i.e., 10622 unpredictable) but is actually generated by a deterministic 10623 algorithm. (See: compression, random, random number generator.) 10625 $ pseudorandom number generator 10626 (I) See: secondary definition under "random number generator". 10628 $ public component 10629 (I) Synonym for "public key". 10631 Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; to 10632 avoid confusing readers, use "private key" instead. However, the 10633 term MAY be used when discussing a key pair; e.g., "A key pair has 10634 a public component and a private component." 10636 $ public key 10637 1. (I) The publicly disclosable component of a pair of 10638 cryptographic keys used for asymmetric cryptography. (See: key 10639 pair. Compare: private key.) 10641 2. (O) In a public key cryptosystem, "that key of a user's key 10642 pair which is publicly known." [X509] 10644 $ public-key certificate 10645 1. (I) A digital certificate that binds a system entity's 10646 identifier to a public key value, and possibly to additional, 10647 secondary data items; i.e., a digitally signed data structure that 10648 attests to the ownership of a public key. (See: X.509 public-key 10649 certificate.) 10651 2. (O) "The public key of a user, together with some other 10652 information, rendered unforgeable by encipherment with the private 10653 key of the certification authority which issued it." [X509] 10655 Tutorial: The digital signature on a public-key certificate is 10656 unforgeable. Thus, the certificate can be published, such as by 10657 posting it in a directory, without the directory having to protect 10658 the certificate's data integrity. 10660 $ public-key cryptography 10661 (I) Synonym for "asymmetric cryptography". 10663 $ Public-Key Cryptography Standards (PKCS) 10664 (N) A series of specifications published by RSA Laboratories for 10665 data structures and algorithms used in basic applications of 10666 asymmetric cryptography. (See: PKCS #5 through PKCS #11.) 10668 Tutorial: The PKCS were begun in 1991 in cooperation with industry 10669 and academia, originally including Apple, Digital, Lotus, 10670 Microsoft, Northern Telecom, Sun, and MIT. Today, the 10671 specifications are widely used, but they are not sanctioned by an 10672 official standards organization, such as ANSI, ITU-T, or IETF. RSA 10673 Laboratories retains sole decision-making authority over the PKCS. 10675 $ public-key forward secrecy (PFS) 10676 (I) For a key-agreement protocol based on asymmetric cryptography, 10677 the property that ensures that a session key derived from a set of 10678 long-term public and private keys will not be compromised if one 10679 of the private keys is compromised in the future. 10681 Usage: Some existing RFCs use the term "perfect forward secrecy" 10682 but either do not define it or do not define it precisely. While 10683 preparing this Glossary, we tried to find a good definition for 10684 that term, but found this to be a muddled area. Experts did not 10685 agree. For all practical purposes, the literature defines "perfect 10686 forward secrecy" by stating the Diffie-Hellman algorithm. The term 10687 "public-key forward secrecy" (suggested by Hilarie Orman) and the 10688 "I" definition stated for it here were crafted to be compatible 10689 with current Internet documents, yet be narrow and leave room for 10690 improved terminology. 10692 Challenge to the Internet security community: We need a taxonomy 10693 of terms and definitions to cover the basic properties discussed 10694 here for the full range of cryptographic algorithms and protocols 10695 used in Internet Standards: 10697 Involvement of session keys vs. long-term keys: Experts disagree 10698 about the basic ideas involved: 10699 - One concept of "forward secrecy" is that, given observations of 10700 the operation of a key establishment protocol up to time t, and 10701 given some of the session keys derived from those protocol 10702 runs, you cannot derive unknown past session keys or future 10703 session keys. 10704 - A related property is that, given observations of the protocol 10705 and knowledge of the derived session keys, you cannot derive 10706 one or more of the long-term private keys. 10707 - The "I" definition presented above involves a third concept of 10708 "forward secrecy" that refers to the effect of the compromise 10709 of long-term keys. 10710 - All three concepts involve the idea that a compromise of "this" 10711 encryption key is not supposed to compromise the "next" one. 10712 There also is the idea that compromise of a single key will 10713 compromise only the data protected by the single key. In 10714 Internet literature, the focus has been on protection against 10715 decryption of back traffic in the event of a compromise of 10716 secret key material held by one or both parties to a 10717 communication. 10719 Forward vs. backward: Experts are unhappy with the word "forward", 10720 because compromise of "this" encryption key also is not supposed 10721 to compromise the "previous" one, which is "backward" rather than 10722 forward. In S/KEY, if the key used at time t is compromised, then 10723 all keys used prior to that are compromised. If the "long-term" 10724 key (i.e., the base of the hashing scheme) is compromised, then 10725 all keys past and future are compromised; thus, you could say that 10726 S/KEY has neither forward nor backward secrecy. 10728 Asymmetric cryptography vs. symmetric: Experts disagree about 10729 forward secrecy in the context of symmetric cryptographic systems. 10730 In the absence of asymmetric cryptography, compromise of any long- 10731 term key seems to compromise any session key derived from the 10732 long-term key. For example, Kerberos isn't forward secret, because 10733 compromising a client's password (thus compromising the key shared 10734 by the client and the authentication server) compromises future 10735 session keys shared by the client and the ticket-granting server. 10737 Ordinary forward secrecy vs. "perfect" forward secret: Experts 10738 disagree about the difference between these two. Some say there is 10739 no difference, and some say that the initial naming was 10740 unfortunate and suggest dropping the word "perfect". Some suggest 10741 using "forward secrecy" for the case where one long-term private 10742 key is compromised, and adding "perfect" for when both private 10743 keys (or, when the protocol is multi-party, all private keys) are 10744 compromised. 10746 Acknowledgements: Bill Burr, Burt Kaliski, Steve Kent, Paul Van 10747 Oorschot, Michael Wiener, and, especially, Hilarie Orman 10748 contributed ideas to this discussion. 10750 $ public-key infrastructure (PKI) 10751 1. (I) A system of CAs (and, optionally, RAs and other supporting 10752 servers and agents) that perform some set of certificate 10753 management, archive management, key management, and token 10754 management functions for a community of users in an application of 10755 asymmetric cryptography. (See: hierarchical PKI, mesh PKI, 10756 security management infrastructure, trust-file PKI.) 10758 2. (I) /PKIX/ The set of hardware, software, people, policies, and 10759 procedures needed to create, manage, store, distribute, and revoke 10760 digital certificates based on asymmetric cryptography. 10762 Tutorial: The core PKI functions are (a) to register users and 10763 issue their public-key certificates, (b) to revoke certificates 10764 when required, and (c) to archive data needed to validate 10765 certificates at a much later time. Key pairs for data 10766 confidentiality may be generated (and perhaps escrowed) by CAs or 10767 RAs, but requiring a PKI client to generate its own digital 10768 signature key pair helps maintain system integrity of the 10769 cryptographic system, because then only the client ever possesses 10770 the private key it uses. Also, an authority may be established to 10771 approve or coordinate CPSs, which are security policies under 10772 which components of a PKI operate. 10774 A number of other servers and agents may support the core PKI, and 10775 PKI clients may obtain services from them. The full range of such 10776 services is not yet fully understood and is evolving, but 10777 supporting roles may include archive agent, certified delivery 10778 agent, confirmation agent, digital notary, directory, key escrow 10779 agent, key generation agent, naming agent who ensures that issuers 10780 and subjects have unique identifiers within the PKI, repository, 10781 ticket-granting agent, and time-stamp agent. 10783 $ purge 10784 (I) Use degaussing or other means to render (magnetically) stored 10785 data unusable and unrecoverable by any means, including laboratory 10786 methods. [C4009] (See: zeroize. Compare: erase, sanitize.) 10788 $ QUADRANT 10789 (O) /U.S. Government/ Short name for technology and methods that 10790 protect cryptographic equipment by making the equipment tamper- 10791 resistant. [C4009] (Compare: protective packaging, TEMPEST.) 10793 Tutorial: Equipment cannot be made completely tamper-proof, but it 10794 can be made tamper-resistant or tamper-evident. 10796 $ qualified certificate 10797 (I) A public-key certificate that has the primary purpose of 10798 identifying a person with a high level of assurance, where the 10799 certificate meets some qualification requirements defined by an 10800 applicable legal framework, such as the European Directive on 10801 Electronic Signature [EU-ESDIR]. [R3739]. 10803 $ quick mode 10804 (I) See: /IKE/ under "mode". 10806 $ RA 10807 (I) See: registration authority. 10809 $ RA domains 10810 (I) A feature of a CAW that allows a CA to divide the 10811 responsibility for certificate requests among multiple RAs. 10813 Tutorial: This ability might be used to restrict access to private 10814 authorization data that is provided with a certificate request, 10815 and to distribute the responsibility to review and approve 10816 certificate requests in high volume environments. RA domains might 10817 segregate certificate requests according to an attribute of the 10818 certificate subject, such as an organizational unit. 10820 $ RADIUS 10821 (I) See: Remote Authentication Dial-In User Service. 10823 $ Rainbow Series 10824 (O) /COMPUSEC/ A set of more than 30 technical and policy 10825 documents with colored covers, issued by the NCSC, that discuss in 10826 detail the TCSEC and provide guidance for meeting and applying the 10827 criteria. (See: Green Book, Orange Book, Red Book, Yellow Book.) 10829 $ random 10830 (I) In essence, "random" means "unpredictable". [SP22, Knut, 10831 R1750] (See: cryptographic key, pseudorandom.) 10832 - "Random sequence": A sequence in which each successive value is 10833 obtained merely by chance and does not depend on the preceding 10834 values of the sequence. In a random sequence of bits, each bit 10835 is unpredictable; i.e., (a) the probability of each bit being a 10836 "0" or "1" is 1/2, and (b) the value of each bit is independent 10837 of any other bit in the sequence. 10838 - "Random value": A individual value that is unpredictable; i.e., 10839 each value in the total population of possibilities has equal 10840 probability of being selected. 10842 $ random number generator 10843 (I) A process that is invoked to generate a random sequence of 10844 values (usually a sequence of bits) or an individual random value. 10846 Tutorial: There are two basic types of generators. [SP22] 10847 - "(True) random number generator": It uses one or more non- 10848 deterministic bit sources (e.g., electrical circuit noise, 10849 timing of human processes such as key strokes or mouse 10850 movements, semiconductor quantum effects, and other physical 10851 phenomena) and a processing function that formats the bits, and 10852 it outputs a sequence of values that is unpredictable and 10853 uniformly distributed. 10854 - "Pseudorandom number generator": It uses a deterministic 10855 computational process (usually implemented by software) that 10856 has one or more inputs called "seeds", and it outputs a 10857 sequence of values that appears to be random according to 10858 specified statistical tests. 10860 $ RBAC 10861 (N) See: role-based access control, rule-based access control. 10863 Deprecated Usage: ISDs that use this term SHOULD state a 10864 definition for it because the abbreviation is ambiguous. 10866 $ RC2, RC4, RC6 10867 (N) See: Rivest Cipher #2, #4, #6. 10869 $ read 10870 (I) A fundamental operation in an information system that results 10871 only in the flow of information from an object to a subject. (See: 10872 access mode.) 10874 $ realm 10875 (O) /Kerberos/ The domain of authority of a Kerberos server 10876 (consisting of an authentication server and a ticket-granting 10877 server), including the Kerberized clients and the Kerberized 10878 application servers. (See: domain.) 10880 $ recovery 10881 1. (I) /cryptography/ The process of learning or obtaining 10882 cryptographic data or plain text through cryptanalysis. (See: key 10883 recovery, data recovery.) 10885 2a. (I) /system integrity/ The process of restoring a secure state 10886 in a system after there has been an accidental failure or a 10887 successful attack. (See: secondary definition under "security", 10888 system integrity.) 10890 2b. (I) /system integrity/ The process of restoring an information 10891 system's assets and operation following damage or destruction. 10893 (See: contingency plan.) 10895 $ RED 10896 1. (I) Designation for data that consists only of clear text, and 10897 for information system equipment items and facilities that handle 10898 only clear text. Example: "RED key". (See: color change, RED/BLACK 10899 separation. Compare: BLACK.) 10901 Derivation: From the practice of marking equipment with colors to 10902 prevent operational errors. 10904 2. (O) /U.S. Government/ Designation applied to information 10905 systems, and to associated areas, circuits, components, and 10906 equipment, "in which unencrypted national security information is 10907 being processed." [C4009] 10909 $ RED/BLACK separation 10910 (I) An architectural concept for cryptographic systems that 10911 strictly separates the parts of a system that handle plain text 10912 (i.e., RED information) from the parts that handle cipher text 10913 (i.e., BLACK information). (See: BLACK, RED.) 10915 $ Red Book 10916 (D) /slang/ Synonym for "Trusted Network Interpretation of the 10917 Trusted Computer System Evaluation Criteria" [NCS05]. 10919 Deprecated Term: ISDs SHOULD NOT use this term. Instead, use the 10920 full proper name of the document or, in subsequent references, a 10921 more conventional abbreviation, e.g., TNI-TCSEC. (See: TCSEC, 10922 Rainbow Series, Deprecated Usage under "Green Book".) 10924 $ RED key 10925 (I) A cleartext key, which is usable in its present form (i.e., it 10926 does not need to be decrypted before being used). (See: RED. 10927 Compare: BLACK key.) 10929 $ reference monitor 10930 (I) "An access control concept that refers to an abstract machine 10931 that mediates all accesses to objects by subjects." [NCS04] (See: 10932 security kernel.) 10934 Tutorial: This concept was described in the Anderson report. A 10935 reference monitor should be (a) complete (i.e., it mediates every 10936 access), (b) isolated (i.e., it cannot be modified by other system 10937 entities), and (c) verifiable (i.e., small enough to be subjected 10938 to analysis and tests to ensure that it is correct). 10940 $ reflection attack 10941 (I) An attack in which a valid data transmission is maliciously or 10942 fraudulently retransmitted, either by an adversary who intercepts 10943 the data or by its originator. (Compare: replay attack.) 10945 $ registered user 10946 (I) A system entity that is authorized to receive a system's 10947 products and services or otherwise access system resources. (See: 10948 registration, user.) 10950 $ registration 10951 1. (I) /information system/ A system process that (a) initializes 10952 an identity (of a system entity) in the system, (b) establishes an 10953 identifier for that identity, (c) may associate authentication 10954 information with that identifier, and (d) may issue an identifier 10955 credential (depending on the type of authentication mechanism 10956 being used). (See: authentication information, credential, 10957 identifier, identity, identity proofing.) 10959 2. (I) /PKI/ An administrative act or process whereby an entity's 10960 name and other attributes are established for the first time at a 10961 CA, prior to the CA issuing a digital certificate that has the 10962 entity's name as the subject. (See: registration authority.) 10964 Tutorial: Registration may be accomplished either directly, by the 10965 CA, or indirectly, by a separate RA. An entity is presented to the 10966 CA or RA, and the authority either records the name(s) claimed for 10967 the entity or assigns the entity's name(s). The authority also 10968 determines and records other attributes of the entity that are to 10969 be bound in a certificate (such as a public key or authorizations) 10970 or maintained in the authority's database (such as street address 10971 and telephone number). The authority is responsible, possibly 10972 assisted by an RA, for verifying the entity's identity and vetting 10973 the other attributes, in accordance with the CA's CPS. 10975 Among the registration issues that a CPS may address are the 10976 following [R3647]: 10977 - How a claimed identity and other attributes are verified. 10978 - How organization affiliation or representation is verified. 10979 - What forms of names are permitted, such as X.500 DN, domain 10980 name, or IP address. 10981 - Whether names are required to be meaningful or unique, and 10982 within what domain. 10983 - How naming disputes are resolved, including the role of 10984 trademarks. 10985 - Whether certificates are issued to entities that are not 10986 persons. 10987 - Whether a person is required to appear before the CA or RA, or 10988 can instead be represented by an agent. 10989 - Whether and how an entity proves possession of the private key 10990 matching a public key. 10992 $ registration authority (RA) 10993 1. (I) An optional PKI entity (separate from the CAs) that does 10994 not sign either digital certificates or CRLs but has 10995 responsibility for recording or verifying some or all of the 10996 information (particularly the identities of subjects) needed by a 10997 CA to issue certificates and CRLs and to perform other certificate 10998 management functions. (See: ORA, registration.) 11000 2. (I) /PKIX/ An optional PKI component, separate from the CA(s). 11001 The functions that the RA performs will vary from case to case but 11002 may include identity authentication and name assignment, key 11003 generation and archiving of key pairs, token distribution, and 11004 revocation reporting. [R2510] 11006 Tutorial: Sometimes, a CA may perform all certificate management 11007 functions for all end users for which the CA signs certificates. 11008 Other times, such as in a large or geographically dispersed 11009 community, it may be necessary or desirable to offload secondary 11010 CA functions and delegate them to an assistant, while the CA 11011 retains the primary functions (signing certificates and CRLs). The 11012 tasks that are delegated to an RA by a CA may include personal 11013 authentication, name assignment, token distribution, revocation 11014 reporting, key generation, and archiving. 11016 An RA is an optional PKI entity, separate from the CA, that is 11017 assigned secondary functions. The duties assigned to RAs vary from 11018 case to case but may include the following: 11019 - Verifying a subject's identity, i.e., performing personal 11020 authentication functions. 11021 - Assigning a name to a subject. (See: distinguished name.) 11022 - Verifying that a subject is entitled to have the attributes 11023 requested for a certificate. 11024 - Verifying that a subject possesses the private key that matches 11025 the public key requested for a certificate. 11026 - Performing functions beyond mere registration, such as 11027 generating key pairs, distributing tokens, handling revocation 11028 reports, and archiving data. (Such functions may be assigned to 11029 a PKI component that is separate from both the CA and the RA.) 11031 3. (O) /SET/ "An independent third-party organization that 11032 processes payment card applications for multiple payment card 11033 brands and forwards applications to the appropriate financial 11034 institutions." [SET2] 11036 $ regrade 11037 (I) Deliberately change the security level (especially the 11038 hierarchical classification level) of information in an authorized 11039 manner. (See: downgrade, upgrade.) 11041 $ rekey 11042 (I) Change the value of a cryptographic key that is being used in 11043 an application of a cryptographic system. (See: certificate 11044 rekey.) 11046 Tutorial: Rekey is required at the end of a cryptoperiod or key 11047 lifetime. 11049 $ reliability 11050 (I) The ability of a system to perform a required function under 11051 stated conditions for a specified period of time. (Compare: 11052 availability, survivability.) 11054 $ reliable human review 11055 (I) Any manual, automated, or hybrid process or procedure for 11056 opening and reviewing a digital object, such as text or an image, 11057 to determine whether the object may be permitted, according to 11058 some security policy, to be transferred across a controlled 11059 interface. (See: guard.) 11061 $ relying party 11062 (I) Synonym for "certificate user". 11064 Usage: Used in a legal context to mean a recipient of a 11065 certificate who acts in reliance on that certificate. (See: ABA 11066 Guidelines.) 11068 $ remanence 11069 (I) Residual information that can be recovered from a storage 11070 medium after clearing. (See: clear, magnetic remanence, purge.) 11072 $ Remote Authentication Dial-In User Service (RADIUS) 11073 (I) An Internet protocol [R2865] for carrying dial-in users' 11074 authentication information and configuration information between a 11075 shared, centralized authentication server (the RADIUS server) and 11076 a network access server (the RADIUS client) that needs to 11077 authenticate the users of its network access ports. (See: TACACS.) 11079 Tutorial: A user of the RADIUS client presents authentication 11080 information to the client, and the client passes that information 11081 to the RADIUS server. The server authenticates the client using a 11082 shared secret value, then checks the user's authentication 11083 information, and finally returns to the client all authorization 11084 and configuration information needed by the client to deliver 11085 service to the user. 11087 $ renew 11088 See: certificate renewal. 11090 $ replay attack 11091 (I) An attack in which a valid data transmission is maliciously or 11092 fraudulently repeated, either by the originator or by an adversary 11093 who intercepts the data and retransmits it, possibly as part of a 11094 masquerade attack. (See: active wiretapping, liveness. Compare: 11095 reflection attack.) 11097 $ reordering 11098 (I) /packet/ See: secondary definition under "stream integrity 11099 service". 11101 $ repository 11102 1. (I) A system for storing and distributing digital certificates 11103 and related information (including CRLs, CPSs, and certificate 11104 policies) to certificate users. (Compare: archive, directory.) 11106 2. (O) "A trustworthy system for storing and retrieving 11107 certificates or other information relevant to certificates." [ABA] 11109 Tutorial: A certificate is published to those who might need it by 11110 putting it in a repository. The repository usually is a publicly 11111 accessible, on-line server. In the FPKI, for example, the expected 11112 repository is a directory that uses LDAP, but also may be an X.500 11113 Directory that uses DAP, or an HTTP server, or an FTP server that 11114 permits anonymous login. 11116 $ repudiation 11117 1. (I) Denial by a system entity that was involved in an 11118 association (especially an association that transfers information) 11119 of having participated in the relationship. (See: accountability, 11120 non-repudiation service.) 11122 2. (I) A type of threat action whereby an entity deceives another 11123 by falsely denying responsibility for an act. (See: deception.) 11125 Usage: This type of threat action includes the following subtypes: 11126 - False denial of origin: Action whereby an originator denies 11127 responsibility for sending data. 11128 - False denial of receipt: Action whereby a recipient denies 11129 receiving and possessing data. 11131 3. (O) /OSIRM/ "Denial by one of the entities involved in a 11132 communication of having participated in all or part of the 11133 communication." [I7498 Part 2] 11135 $ Request for Comment (RFC) 11136 1. (I) One of the documents in the archival series that is the 11137 official channel for ISDs and other publications of the Internet 11138 Engineering Steering Group, the Internet Architecture Board, and 11139 the Internet community in general. (RFC 2026, 2223) (See: Internet 11140 Standard.) 11142 2. (D) A popularly misused synonym for a document on the Internet 11143 Standards Track, i.e., an Internet Standard, Draft Standard, or 11144 Proposed Standard. (See: Internet Standard.) 11146 Deprecated Definition: This term SHOULD NOT be used as a synonym 11147 for a document on the Internet Standards Track because many other 11148 types of documents also are published as RFCs. 11150 $ residual risk 11151 (I) The portion of an original risk or set of risks that remains 11152 after countermeasures have been applied. (Compare: acceptable 11153 risk, risk analysis.) 11155 $ restore 11156 See: card restore. 11158 $ revocation 11159 See: certificate revocation. 11161 $ revocation date 11162 (N) /X.509/ In a CRL entry, a date-time field that states when the 11163 certificate revocation occurred, i.e., when the CA declared the 11164 digital certificate to be invalid. (See: invalidity date.) 11166 Tutorial: The revocation date may not resolve some disputes 11167 because, in the worst case, all signatures made during the 11168 validity period of the certificate may have to be considered 11169 invalid. However, it may be desirable to treat a digital signature 11170 as valid even though the private key used to sign was compromised 11171 after the signing. If more is known about when the compromise 11172 actually occurred, a second date-time, an "invalidity date", can 11173 be included in an extension of the CRL entry. 11175 $ revocation list 11176 See: certificate revocation list. 11178 $ revoke 11179 (I) See: certificate revocation. 11181 $ RFC 11182 (I) See: Request for Comment. 11184 $ Rijndael 11185 (N) A symmetric, block cipher that was designed by Joan Daemen and 11186 Vincent Rijmen as a candidate for the AES, and that won that 11187 competition. [Daem] (See: Advanced Encryption Standard.) 11189 $ risk 11190 1. (I) An expectation of loss expressed as the probability that a 11191 particular threat will exploit a particular vulnerability with a 11192 particular harmful result. 11194 2. (O) /SET/ "The possibility of loss because of one or more 11195 threats to information (not to be confused with financial or 11196 business risk)." [SET2] 11198 Tutorial: There are four basic ways to deal with a risk [SP30]: 11199 - "Risk avoidance": Eliminate the risk by either countering the 11200 threat or removing the vulnerability. (Compare: "avoidance" 11201 under "security".) 11202 - "Risk transference": Shift the risk to another system or 11203 entity; e.g., buy insurance to compensate for potential loss. 11204 - "Risk limitation": Limit the risk by implementing controls that 11205 minimize resulting loss. 11206 - "Risk assumption": Accept the potential for loss and continue 11207 operating the system. 11209 $ risk analysis 11210 (I) An assessment process that systematically (a) identifies 11211 valuable system resources and threats to those resources, (b) 11212 quantifies loss exposures (i.e., loss potential) based on 11213 estimated frequencies and costs of occurrence, and (c) 11214 (optionally) recommends how to allocate available resources to 11215 countermeasures so as to minimize total exposure. (See: risk 11216 management, business case analysis. Compare: threat analysis.) 11218 Tutorial: Usually, it is financially and technically infeasible to 11219 avoid or transfer all risks (see: "first corollary" of "second 11220 law" under "Courtney's laws"), and some residual risks will 11221 remain, even after all available countermeasures have been 11222 deployed (see: "second corollary" of "second law" under 11223 "Courtney's laws"). Thus, a risk analysis typically lists risks in 11224 order of cost and criticality, thereby determining where 11225 countermeasures should be applied first. [FP031, R2196] 11227 In some contexts, it is infeasible or inadvisable to attempt a 11228 complete or quantitative risk analysis because needed data, time, 11229 and expertise are not available. Instead, basic answers to 11230 questions about threats and risks may be already built into 11231 institutional security policies. For example, U.S. DoD policies 11232 for data confidentiality "do not explicitly itemize the range of 11233 expected threats" but instead "reflect an operational approach ... 11234 by stating the particular management controls that must be used to 11235 achieve [confidentiality] ... Thus, they avoid listing threats, 11236 which would represent a severe risk in itself, and avoid the risk 11237 of poor security design implicit in taking a fresh approach to 11238 each new problem". [NRC91] 11240 $ risk assumption 11241 (I) See: secondary definition under "risk". 11243 $ risk avoidance 11244 (I) See: secondary definition under "risk". 11246 $ risk limitation 11247 (I) See: secondary definition under "risk". 11249 $ risk management 11250 1. (I) The process of identifying, measuring, and controlling 11251 (i.e., mitigating) risks in information systems so as to reduce 11252 the risks to a level commensurate with the value of the assets 11253 protected. (See: risk analysis.) 11255 2. (I) The process of controlling uncertain events that may affect 11256 information system resources. 11258 3. (O) "The total process of identifying, controlling, and 11259 mitigating information system- Drelated risks. It includes risk 11260 assessment; cost-benefit analysis; and the selection, 11261 implementation, test, and security evaluation of safeguards. This 11262 overall system security review considers both effectiveness and 11263 efficiency, including impact on the mission and constraints due to 11264 policy, regulations, and laws." [SP30] 11266 $ risk transference 11267 (I) See: secondary definition under "risk". 11269 $ Rivest Cipher #2 (RC2) 11270 (N) A proprietary, variable-key-length block cipher invented by 11271 Ron Rivest for RSA Data Security, Inc. 11273 $ Rivest Cipher #4 (RC4) 11274 (N) A proprietary, variable-key-length stream cipher invented by 11275 Ron Rivest for RSA Data Security, Inc. 11277 $ Rivest Cipher #6 (RC6) 11278 (N) A symmetric, block cipher with 128-bit or longer key length, 11279 developed by Ron Rivest for RSA Data Security, Inc. as a candidate 11280 for the AES. 11282 $ Rivest-Shamir-Adleman (RSA) 11283 (N) An algorithm for asymmetric cryptography, invented in 1977 by 11284 Ron Rivest, Adi Shamir, and Leonard Adleman [RSA78]. 11286 Tutorial: RSA uses exponentiation modulo the product of two large 11287 prime numbers. The difficulty of breaking RSA is believed to be 11288 equivalent to the difficulty of factoring integers that are the 11289 product of two large prime numbers of approximately equal size. 11291 To create an RSA key pair, randomly choose two large prime 11292 numbers, p and q, and compute the modulus, n = pq. Randomly choose 11293 a number e, the public exponent, that is less than n and 11294 relatively prime to (p-1)(q-1). Choose another number d, the 11295 private exponent, such that ed-1 evenly divides (p-1)(q-1). The 11296 public key is the set of numbers (n,e), and the private key is the 11297 set (n,d). 11299 It is assumed to be difficult to compute the private key (n,d) 11300 from the public key (n,e). However, if n can be factored into p 11301 and q, then the private key d can be computed easily. Thus, RSA 11302 security depends on the assumption that it is computationally 11303 difficult to factor a number that is the product of two large 11304 prime numbers. (Of course, p and q are treated as part of the 11305 private key, or else are destroyed after computing n.) 11307 For encryption of a message, m, to be sent to Bob, Alice uses 11308 Bob's public key (n,e) to compute m**e (mod n) = c. She sends c to 11309 Bob. Bob computes c**d (mod n) = m. Only Bob knows d, so only Bob 11310 can compute c**d (mod n) to recover m. 11312 To provide data origin authentication of a message, m, to be sent 11313 to Bob, Alice computes m**d (mod n) = s, where (d,n) is Alice's 11314 private key. She sends m and s to Bob. To recover the message that 11315 only Alice could have sent, Bob computes s**e (mod n) = m, where 11316 (e,n) is Alice's public key. 11318 To ensure data integrity in addition to data origin authentication 11319 requires extra computation steps in which Alice and Bob use a 11320 cryptographic hash function h (see: digital signature). Alice 11321 computes the hash value h(m) = v, and then encrypts v with her 11322 private key to get s. She sends m and s. Bob receives m' and s', 11323 either of which might have been changed from the m and s that 11324 Alice sent. To test this, he decrypts s' with Alice's public key 11325 to get v'. He then computes h(m') = v". If v' equals v", Bob is 11326 assured that m' is the same m that Alice sent. 11328 $ robustness 11329 (N) See: level of robustness. 11331 $ role 11332 1. (I) A job function (or a job title that implies a function) to 11333 which people or other system entities may be assigned in a system. 11334 (See: role-based access control. Compare: duty, billet, principal, 11335 user.) 11337 2. (O) /Common Criteria/ A pre-defined set of rules establishing 11338 the allowed interactions between a user and the TOE. 11340 $ role-based access control 11341 (I) A form of identity-based access control wherein the system 11342 entities that are identified and controlled are functional 11343 positions in an organization or process. [Sand] (See: 11344 authorization, constraint, identity, principal, role.) 11346 Tutorial: Administrators assign permissions to roles as needed to 11347 perform functions in the system. Administrators separately assign 11348 user identities to roles. When a user accesses the system in an 11349 identity (for which the user has been registered) and initiates a 11350 session using a role (to which the user has been assigned), then 11351 the permissions that have been assigned to the role are available 11352 to be exercised by the user. 11354 The following diagram shows that role-based access control 11355 involves five different relationships: (1) administrators assign 11356 identities to roles, (2) administrators assign permissions to 11357 roles, (3) administrators assign roles to roles, (4) users select 11358 identities in sessions, and (5) users select roles in sessions. 11359 Security policies may define constraints on these assignments and 11360 selections. 11362 (3) Permission Inheritance Assignments (i.e., Role Hierarchy) 11363 [Constraints] 11364 +=====+ 11365 | | 11366 (1) Identity v v (2) Permission 11367 +----------+ Assignments +-------+ Assignments +----------+ 11368 |Identities|<=============>| Roles |<=============>|Permissions| 11369 +----------+ [Constraints] +-------+ [Constraints] +----------+ 11370 | | ^ ^ 11371 | | +-----------+ | | +---------------------+ 11372 | | | +-------+ | | | | Legend | 11373 | +====>|Session|=====+ | | | 11374 | | +-------+ | | | One-to-One | 11375 | | ... | | | =================== | 11376 | | +-------+ | | | | 11377 +========>|Session|=========+ | One-to-Many | 11378 (4) Identity | +-------+ | (5) Role | ==================> | 11379 Selections | | Selections | | 11380 [Constraints]| Access |[Constraints] | Many-to-Many | 11381 | Sessions | | <=================> | 11382 +-----------+ +---------------------+ 11384 $ role certificate 11385 (I) An organizational certificate that is issued to a system 11386 entity that is a member of the set of users that have identities 11387 that are assigned to the same role. (See: role-based access 11388 control.) 11390 $ root, root CA 11391 1. (I) /PKI/ A CA that is directly trusted by an end entity. (See: 11392 trust anchor, trusted CA.) 11394 2. (I) /hierarchical PKI/ The CA that is the highest level (most 11395 trusted) CA in a certification hierarchy; i.e., the authority upon 11396 whose public key all certificate users base their validation of 11397 certificates, CRLs, certification paths, and other constructs. 11398 (See: top CA.) 11400 Tutorial: The root CA in a certification hierarchy issues public- 11401 key certificates to one or more additional CAs that form the 11402 second highest level. Each of these CAs may issue certificates to 11403 more CAs at the third highest level, and so on. To initialize 11404 operation of a hierarchical PKI, the root's initial public key is 11405 securely distributed to all certificate users in a way that does 11406 not depend on the PKI's certification relationships, i.e., by an 11407 out-of-band procedure. The root's public key may be distributed 11408 simply as a numerical value, but typically is distributed in a 11409 self-signed certificate in which the root is the subject. The 11410 root's certificate is signed by the root itself because there is 11411 no higher authority in a certification hierarchy. The root's 11412 certificate is then the first certificate in every certification 11413 path. 11415 3. (I) /DNS/ The base of the tree structure that defines the name 11416 space for the Internet DNS. (See: domain name.) 11418 4. (O) /MISSI/ A name previously used for a MISSI policy creation 11419 authority, which is not a root as defined above for general usage, 11420 but is a CA at the second level of the MISSI hierarchy, 11421 immediately subordinate to a MISSI policy approving authority. 11423 5. (O) /UNIX/ A user account (also called "superuser") that has 11424 all privileges (including all security-related privileges) and 11425 thus can manage the system and its other user accounts. 11427 $ root certificate 11428 1. (I) /PKI/ A certificate for which the subject is a root. (See: 11429 trust anchor certificate, trusted certificate.) 11431 2. (I) /hierarchical PKI/ The self-signed public-key certificate 11432 at the top of a certification hierarchy. 11434 $ root key 11435 (I) /PKI/ A public key for which the matching private key is held 11436 by a root. (See: trust anchor key, trusted key.) 11438 $ root registry 11439 (O) /MISSI/ A name previously used for a MISSI PAA. 11441 $ ROT13 11442 (I) See: secondary definition under "Caesar cipher". 11444 $ router 11445 1a. (I) /IP/ A networked computer that forwards IP packets that 11446 are not addressed to the computer itself. (Compare: host.) 11448 1b. (I) /IPS/ A gateway that operates in the IPS Internet Layer to 11449 connect two or more subnetworks. 11451 1c. (N) /OSIRM/ A computer that is a gateway between two networks 11452 at OSIRM Layer 3 and that relays and directs data packets through 11453 that internetwork. (Compare: bridge, proxy.) 11455 $ RSA 11456 (N) See: Rivest-Shamir-Adleman. 11458 $ rule 11459 See: policy rule. 11461 $ rule-based security policy 11462 (I) "A security policy based on global rules [i.e., policy rules] 11463 imposed for all users. These rules usually rely on comparison of 11464 the sensitivity of the resource being accessed and the possession 11465 of corresponding attributes of users, a group of users, or 11466 entities acting on behalf of users." [I7498 Part 2] (Compare: 11467 identity-based security policy, policy rule, RBAC.) 11469 $ rules of behavior 11470 (I) A body of security policy that has been established and 11471 implemented concerning the responsibilities and expected behavior 11472 of entities that have access to a system. (Compare: [R1281].) 11474 Tutorial: For persons employed by a corporation or government, the 11475 rules might cover such matters as working at home, remote access, 11476 use of the Internet, use of copyrighted works, use of system 11477 resources for unofficial purpose, assignment and limitation of 11478 system privileges, and individual accountability. 11480 $ S field 11481 (D) See: Security Level field. 11483 $ S-BGP 11484 (I) See: Secure BGP. 11486 $ S-HTTP 11487 (I) See: Secure Hypertext Transfer Protocol. 11489 $ S/Key 11490 (I) A security mechanism that uses a cryptographic hash function 11491 to generate a sequence of 64-bit, one-time passwords for remote 11492 user login. [R1760] 11494 Tutorial: The client generates a one-time password by applying the 11495 MD4 cryptographic hash function multiple times to the user's 11496 secret key. For each successive authentication of the user, the 11497 number of hash applications is reduced by one. (Thus, an intruder 11498 using wiretapping cannot compute a valid password from knowledge 11499 of one previously used.) The server verifies a password by hashing 11500 the currently presented password (or initialization value) one 11501 time and comparing the hash result with the previously presented 11502 password. 11504 $ S/MIME 11505 (I) See: Secure/MIME. 11507 $ SAD 11508 (I) See: Security Association Database. 11510 $ safety 11511 (I) The property of a system being free from risk of causing harm 11512 (especially physical harm) to its system entities. (Compare: 11513 security.) 11515 $ SAID 11516 (I) See: security association identifier. 11518 $ salt 11519 (I) A data value used to vary the results of a computation in a 11520 security mechanism, so that an exposed computational result from 11521 one instance of applying the mechanism cannot be reused by an 11522 attacker in another instance. (Compare: initialization value.) 11524 Example: A password-based access control mechanism might protect 11525 against capture or accidental disclosure of its password file by 11526 applying a one-way encryption algorithm to passwords before 11527 storing them in the file. To increase the difficulty of off-line, 11528 dictionary attacks that match encrypted values of potential 11529 passwords against a copy of the password file, the mechanism can 11530 concatenate each password with its own random salt value before 11531 applying the one-way function. 11533 $ SAML 11534 (N) See: Security Assertion Markup Language (SAML). 11536 $ sandbox 11537 (I) A restricted, controlled execution environment that prevents 11538 potentially malicious software, such as mobile code, from 11539 accessing any system resources except those for which the software 11540 is authorized. 11542 $ sanitize 11543 1. (I) Delete sensitive data from a file, device, or system. 11545 2. (I) Modify data so as to be able either (a) to completely 11546 declassify it or (b) to downgrade it to a lower security level. 11548 $ SAP 11549 (O) See: special access program. 11551 $ SASL 11552 (I) See: Simple Authentication and Security Layer. 11554 $ SCA 11555 (I) See: subordinate certification authority. 11557 $ scavenging 11558 (I) See: secondary definition under "threat consequence". 11560 $ SCI 11561 (O) See: sensitive compartmented information. 11563 $ SCIF 11564 (O) See: sensitive compartmented information facility. 11566 $ SCOMP 11567 (N) Secure COMmunications Processor; an enhanced, MLS version of 11568 the Honeywell Level 6 minicomputer. It was the first system to be 11569 rated in TCSEC Class A1. (See: KSOS.) 11571 $ screen room 11572 (D) /slang/ Synonym for "shielded enclosure" in the context of 11573 electromagnetic emanations. (See: EMSEC, TEMPEST.) 11575 Deprecated Term: To avoid international misunderstanding, ISDs 11576 SHOULD NOT use this term. 11578 $ screening router 11579 (I) Synonym for "filtering router". 11581 $ script kiddy 11582 (D) /slang/ A cracker who is able to use existing attack 11583 techniques (i.e., to read scripts) and execute existing attack 11584 software, but is unable to invent new exploits or manufacture the 11585 tools to perform them; pejoratively, an immature or novice 11586 cracker. 11588 Deprecated Term: It is likely that other cultures use different 11589 metaphors for this concept. Therefore, to avoid international 11590 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 11591 Usage under "Green Book".) 11593 $ SDE 11594 (N) See: Secure Data Exchange. 11596 $ SDNS 11597 (O) See: Secure Data Network System. 11599 $ SDU 11600 (N) See: "service data unit" under "protocol data unit". 11602 $ seal 11603 1. (I) To use asymmetric cryptography to encrypt plain text with a 11604 public key in such a way that only the holder of the matching 11605 private key can learn what was the plain text. [Chau] 11607 Usage: ISDs that use this term SHOULD state a definition for it 11608 because this definition is not widely known. 11610 Tutorial: The definition does *not* say "only the holder of the 11611 matching private key can decrypt the ciphertext to learn what was 11612 the plaintext"; sealing is stronger than that. If Alice simply 11613 encrypts a plaintext P with a public key K to produce ciphertext C 11614 = K(P), then if Bob guesses that P = X, Bob could verify the guess 11615 by checking whether K(P) = K(X). To "seal" P and block Bob's 11616 guessing attack, Alice could attach a long string R of random bits 11617 to P before encrypting to produce C = K(P,R); if Bob guesses that 11618 P = X, Bob can only test the guess by also guessing R. 11620 2. (D) To use cryptography to provide data integrity service for a 11621 data object. (See: sign.) 11623 Deprecated Definition: ISDs SHOULD NOT use this term with this 11624 definition. Instead, use a term that is more specific with regard 11625 to the mechanism used to provide the data integrity service; e.g., 11626 use "sign" when the mechanism is digital signature. 11628 $ secret 11629 1a. (I) /adjective/ The condition of information being protected 11630 from being known by any system entities except those that are 11631 intended to know it. 11633 1b. (I) /noun/ An item of information that is protected thusly. 11635 Usage: This term applies to symmetric keys, private keys, and 11636 passwords. 11638 $ secret key 11639 (D) A key that is kept secret or needs to be kept secret. 11641 Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts 11642 in a potentially misleading way. In the context of asymmetric 11643 cryptography, ISDs SHOULD use "private key". In the context of 11644 symmetric cryptography, the adjective "secret" is unnecessary 11645 because all keys must be kept secret. 11647 $ secret-key cryptography 11648 (D) Synonym for "symmetric cryptography". 11650 Deprecated Term: ISDs SHOULD NOT use this term; it could be 11651 confused with asymmetric cryptography, in which the private key is 11652 kept secret. 11654 Derivation: Symmetric cryptography is sometimes called "secret-key 11655 cryptography" because entities that share the key, such as the 11656 originator and the recipient of a message, need to keep the key 11657 secret from other entities. 11659 $ Secure BGP (S-BGP) 11660 (I) A project of BBN Technologies, sponsored by the U.S. DoD's 11661 Defense Advanced Research Projects Agency, to design and 11662 demonstrate an architecture to secure the Border Gateway Protocol 11663 (RFC 1771) and to promote deployment of that architecture in the 11664 Internet. 11666 Tutorial: S-BGP incorporates three security mechanisms: 11667 - A PKI supports authentication of ownership of IP address 11668 blocks, autonomous system (AS) numbers, an AS's identity, and a 11669 BGP router's identity and its authorization to represent an AS. 11670 This PKI parallels and takes advantage of the Internet's 11671 existing IP address and AS number assignment system. 11673 - A new, optional, BGP transitive path attribute carries digital 11674 signatures (in "attestations") covering the routing information 11675 in a BGP UPDATE. These signatures along with certificates from 11676 the S-BGP PKI enable the receiver of a BGP routing UPDATE to 11677 validate the attribute and gain trust in the address prefixes 11678 and path information that it contains. 11679 - IPsec provides data and partial sequence integrity, and enables 11680 BGP routers to authenticate each other for exchanges of BGP 11681 control traffic. 11683 $ Secure Data Exchange (SDE) 11684 (N) A LAN security protocol defined by the IEEE 802.10 standard. 11686 $ Secure Data Network System (SDNS) 11687 (O) An NSA program that developed security protocols for 11688 electronic mail (see: MSP), OSIRM Layer 3 (see: SP3), OSIRM Layer 11689 4 (see: SP4), and key establishment (see: KMP). 11691 $ Secure Hash Algorithm (SHA) 11692 (N) A cryptographic hash function (specified in SHS) that produces 11693 a 160-bit output (hash result) for input data of any length < 11694 2**64 bits. 11696 $ Secure Hash Standard (SHS) 11697 (N) The U.S. Government standard [FP180] that specifies SHA. 11699 $ Secure Hypertext Transfer Protocol (S-HTTP) 11700 (I) A Internet protocol [R2660] for providing client-server 11701 security services for HTTP communications. (Compare: https.) 11703 Tutorial: S-HTTP was originally specified by CommerceNet, a 11704 coalition of businesses interested in developing the Internet for 11705 commercial uses. Several message formats may be incorporated into 11706 S-HTTP clients and servers, particularly CMS and MOSS. S-HTTP 11707 supports choice of security policies, key management mechanisms, 11708 and cryptographic algorithms through option negotiation between 11709 parties for each transaction. S-HTTP supports modes of operation 11710 for both asymmetric and symmetric cryptography. S-HTTP attempts to 11711 avoid presuming a particular trust model, but it attempts to 11712 facilitate multiply rooted, hierarchical trust and anticipates 11713 that principals may have many public-key certificates. 11715 $ Secure/MIME (S/MIME) 11716 (I) Secure/Multipurpose Internet Mail Extensions, an Internet 11717 protocol [R3851] to provide encryption and digital signatures for 11718 Internet mail messages. 11720 $ secure multicast 11721 (I) Refers generally to providing security services for multicast 11722 groups of various types (e.g., 1-to-N and M-to-N) and to classes 11723 of protocols used to protect multicast packets. 11725 Tutorial: Multicast applications include video broadcast and 11726 multicast file transfer, and many of these applications require 11727 network security services. The Multicast Security Reference 11728 Framework [R3740] covers three functional areas: 11729 - Multicast data handling: Security-related treatment of 11730 multicast data by the sender and the receiver. 11731 - Group key management: Secure distribution and refreshment of 11732 keying material. (See: Group Domain of Interpretation.) 11733 - Multicast security policy: Policy translation and 11734 interpretation across the multiple administrative domains that 11735 typically are spanned by a multicast application. 11737 $ Secure Shell(trademark) (SSH(trademark)) 11738 (N) Trademarks of SSH Communications Security Corp. that refer to 11739 a protocol for secure remote login and other secure network 11740 services. 11742 Tutorial: SSH has three main parts: 11743 - Transport layer protocol: Provides server authentication, 11744 confidentiality, and integrity; and can optionally provide 11745 compression. This layer typically runs over a TCP connection, 11746 but might also run on top of any other reliable data stream. 11747 - User authentication protocol: Authenticates the client-side 11748 user to the server. It runs over the transport layer protocol. 11749 - Connection protocol: Multiplexes the encrypted tunnel into 11750 several logical channels. It runs over the user authentication 11751 protocol. 11753 $ Secure Sockets Layer (SSL) 11754 (N) An Internet protocol (originally developed by Netscape 11755 Communications, Inc.) that uses connection-oriented end-to-end 11756 encryption to provide data confidentiality service and data 11757 integrity service for traffic between a client (often a web 11758 browser) and a server, and that can optionally provide peer entity 11759 authentication between the client and the server. (See: Transport 11760 Layer Security.) 11762 Tutorial: SSL has two layers; SSL's lower layer, the SSL Record 11763 Protocol, is layered on top of an IPS Transport-Layer protocol and 11764 encapsulates protocols that run in the upper layer. The upper 11765 layer protocols are the three SSL management protocols -- SSL 11766 Handshake Protocol, SSL Change Cipher Spec Protocol, or SSL Alert 11767 Protocol -- and some Application-Layer protocol (e.g., HTTP). 11769 The SSL management protocols provide asymmetric cryptography for 11770 server authentication (verifying the server's identity to the 11771 client) and optional client authentication (verifying the client's 11772 identity to the server), and also enable them, before the 11773 application protocol transmits or receives data, to negotiate a 11774 symmetric encryption algorithm and secret session key (to use for 11775 data confidentiality service) and a keyed hash (to use for data 11776 integrity service). 11778 SSL is independent of the application it encapsulates, and any 11779 application can layer on top of SSL transparently. However, many 11780 Internet applications might be better served by IPsec. 11782 $ secure state 11783 1a. (I) A system condition in which the system is in conformance 11784 with the applicable security policy. (Compare: clean system, 11785 transaction.) 11787 1b. (I) /formal model/ A system condition in which no subject can 11788 access any object in an unauthorized manner. (See: secondary 11789 definition under "Bell-LaPadula model".) 11791 $ security 11792 1a. (I) A system condition that results from the establishment and 11793 maintenance of measures to protect the system. 11795 1b. (I) A system condition in which system resources are free from 11796 unauthorized access and from unauthorized or accidental change, 11797 destruction, or loss. (Compare: safety.) 11799 2. (I) Measures taken to protect a system. 11801 Tutorial: Parker suggests that providing a condition of system 11802 security may involve the following six basic functions [Park]; 11803 however, these functions overlap to some extent: 11804 - "Deterrence": Reducing an intelligent threat by discouraging 11805 action, such as by fear or doubt. (See: attack, threat action.) 11806 - "Avoidance": Reducing a risk by either reducing the value of 11807 the potential loss or reducing the probability that the loss 11808 will occur. (See: risk analysis. Compare: "risk avoidance" 11809 under "risk".) 11810 - "Prevention": Impeding a security violation by using a 11811 countermeasure. 11812 - "Detection": Determining that a security violation is 11813 impending, is in progress, or has recently occurred, and thus 11814 make it possible to reduce the potential loss. (See: intrusion 11815 detection.) 11816 - "Recovery": Restoring a normal state of system operation by 11817 compensating for a security violation, possibly by eliminating 11818 or repairing its effects. (See: contingency plan, main entry 11819 for "recovery".) 11820 - "Correction": Changing a security architecture to eliminate or 11821 reduce the risk of reoccurrence of a security violation or 11822 threat consequence, such as by eliminating a vulnerability. 11824 $ security architecture 11825 (I) A plan and set of principles that describe (a) the security 11826 services that a system is required to provide to meet the needs of 11827 its users, (b) the system components required to implement the 11828 services, and (c) the performance levels required in the 11829 components to deal with the threat environment (e.g., [R2179]). 11830 (See: defense in depth, IATF, security controls, Tutorial under 11831 "security policy". Compare: OSIRM System Architecture.) 11833 Tutorial: A security architecture is the result of applying the 11834 system engineering process. A complete system security 11835 architecture includes administrative security, communication 11836 security, computer security, emanations security, personnel 11837 security, and physical security. A complete security architecture 11838 needs to deal with both intentional, intelligent threats and 11839 accidental threats. 11841 $ Security Assertion Markup Language (SAML) 11842 (N) A protocol consisting of XML-based request and response 11843 message formats for exchanging security information, expressed in 11844 the form of assertions about subjects, between online business 11845 partners. [SAML] 11847 $ security association 11848 1. (I) A relationship established between two or more entities to 11849 enable them to protect data they exchange. (See: association, 11850 ISAKMP, SAD. Compare: session.) 11852 Tutorial: The relationship is represented by a set of data that is 11853 shared between the entities and is agreed upon and considered a 11854 contract between them. The data describes how the associated 11855 entities jointly use security services. The relationship is used 11856 to negotiate characteristics of security mechanisms, but the 11857 relationship is usually understood to exclude the mechanisms 11858 themselves. 11860 2. (I) /IPsec/ A simplex (uni-directional) logical connection 11861 created for security purposes and implemented with either AH or 11862 ESP (but not both). The security services offered by a security 11863 association depend on the protocol (AH or ESP), the IPsec mode 11864 (transport or tunnel), the endpoints, and the election of optional 11865 services within the protocol. A security association is identified 11866 by a triple consisting of (a) a destination IP address, (b) a 11867 protocol (AH or ESP) identifier, and (c) a Security Parameter 11868 Index. 11870 3. (O) "A set of policy and cryptographic keys that provide 11871 security services to network traffic that matches that policy". 11872 [R3740] (See: cryptographic association, group security 11873 association.) 11875 4. (O) "The totality of communications and security mechanisms and 11876 functions (e.g., communications protocols, security protocols, 11877 security mechanisms and functions) that securely binds together 11878 two security contexts in different end systems or relay systems 11879 supporting the same information domain." [DGSA] 11881 $ Security Association Database (SAD) 11882 (I) /IPsec/ In an IPsec implementation that operates in a network 11883 node, a database that contains parameters to describe the status 11884 and operation of each of the active security associations that the 11885 node has established with other nodes. Separate inbound and 11886 outbound SADs are needed because of the directionality of IPsec 11887 security associations. [R2401] (Compare: SPD.) 11889 $ security association identifier (SAID) 11890 (I) A data field in a security protocol (such as NLSP or SDE), 11891 used to identify the security association to which a PDU is bound. 11892 The SAID value is usually used to select a key for decryption or 11893 authentication at the destination. (See: Security Parameter 11894 Index.) 11896 $ security assurance 11897 1. (I) An attribute of an information system that provides grounds 11898 for having confidence that the system operates such that the 11899 system's security policy is enforced. (Compare: trust.) 11901 2. (I) A procedure that ensures a system is developed and operated 11902 as intended by the system's security policy. 11904 3. (D) "The degree of confidence one has that the security 11905 controls operate correctly and protect the system as intended." 11906 [SP12] 11908 Deprecated Definition: ISDs SHOULD NOT use definition 3; it is a 11909 definition for "assurance level" rather than for "assurance". 11911 4. (D) /U.S. Government, identity authentication/ The (a) "degree 11912 of confidence in the vetting process used to establish the 11913 identity of the individual to whom the [identity] credential was 11914 issued" and (b) "the degree of confidence that the individual who 11915 uses the credential is the individual to whom the credential was 11916 issued". [M0404] 11918 Deprecated Definition: ISDs SHOULD NOT use definition 4; it mixes 11919 concepts in a potentially misleading way. Part "a" is a definition 11920 for "assurance level" (rather than "security assurance") of an 11921 identity registration process; and part "b" is a definition for 11922 "assurance level" (rather than "security assurance") of an 11923 identity authentication process. Also, the processes of 11924 registration and authentication should be defined and designed 11925 separately to ensure clarity in certification. 11927 $ security audit 11928 (I) An independent review and examination of a system's records 11929 and activities to determine the adequacy of system controls, 11930 ensure compliance with established security policy and procedures, 11931 detect breaches in security services, and recommend any changes 11932 that are indicated for countermeasures. [I7498 Part 2, NCS01] 11933 (Compare: accounting, intrusion detection.) 11935 Tutorial: The basic audit objective is to establish accountability 11936 for system entities that initiate or participate in security- 11937 relevant events and actions. Thus, means are needed to generate 11938 and record a security audit trail and to review and analyze the 11939 audit trail to discover and investigate security violations. 11941 $ security audit trail 11942 (I) A chronological record of system activities that is sufficient 11943 to enable the reconstruction and examination of the sequence of 11944 environments and activities surrounding or leading to an 11945 operation, procedure, or event in a security-relevant transaction 11946 from inception to final results. [NCS04] (See: security audit.) 11948 $ security by obscurity 11949 (O) Attempting to maintain or increase security of a system by 11950 keeping secret the design or construction of a security mechanism. 11952 Tutorial: This approach has long been discredited in cryptography, 11953 where the phrase refers to trying to keep an algorithm secret, 11954 rather than just concealing the keys [Schn]. One must assume that 11955 mass-produced or widely fielded cryptographic devices eventually 11956 will be lost or stolen and, therefore, that the algorithms will be 11957 reverse engineered and become known to the adversary. Thus, one 11958 should rely only on algorithms and protocols that are strong 11959 enough to have been published widely, and have been peer reviewed 11960 for long enough that their flaws have been found and removed. For 11961 example, NIST used a long, public process to select AES to replace 11962 DES. 11964 In computer and network security, the principle of "no security by 11965 obscurity" also applies to security mechanisms other than 11966 cryptography. For example, if the design and implementation of a 11967 protocol for access control are strong, than reading the 11968 protocol's source code should not enable you to find a way to 11969 evade the protection and penetrate the system. 11971 $ security class 11972 (D) Synonym for "security level". 11974 Deprecated Term: ISDs SHOULD NOT use this term. Instead, use 11975 "security level", which is more widely established and understood. 11977 $ security clearance 11978 (I) A determination that a person is eligible, under the standards 11979 of a specific security policy, for authorization to access 11980 sensitive information or other system resources. (See: clearance 11981 level.) 11983 $ security compromise 11984 (I) A security violation in which a system resource is exposed, or 11985 is potentially exposed, to unauthorized access. (Compare: data 11986 compromise, exposure, violation.) 11988 $ security controls 11989 (N) The management, operational, and technical controls 11990 (safeguards or countermeasures) prescribed for an information 11991 system which, taken together, satisfy the specified security 11992 requirements and adequately protect the confidentiality, 11993 integrity, and availability of the system and its information. 11994 [FP199] (See: security architecture.) 11996 $ security doctrine 11997 1. (I) A specified set of procedures or practices that direct or 11998 provide guidance for how to comply with security policy. (Compare: 11999 security mechanism, security policy.) 12001 Tutorial: Security policy and security doctrine are closely 12002 related. However, policy deals mainly with strategy, and doctrine 12003 deals with tactics. 12005 Security doctrine is often understood to refer mainly to 12006 administrative security, personnel security, and physical 12007 security. For example, security mechanisms and devices that 12008 implement them are normally designed to operate in a limited range 12009 of environmental and administrative conditions, and these 12010 conditions must be met to complement and ensure the technical 12011 protection afforded by the hardware, firmware, and software in the 12012 devices. Security doctrine specifies how to achieve those 12013 conditions. (See: "first law" under "Courtney's laws".) 12015 $ security domain 12016 (I) See: domain. 12018 $ security environment 12019 (I) The set of external entities, procedures, and conditions that 12020 affect secure development, operation, and maintenance of a system. 12021 (See: "first law" under "Courtney's laws".) 12023 $ security event 12024 (I) An occurrence in a system that is relevant to the security of 12025 the system. (See: security incident.) 12027 Tutorial: The term covers both events that are security incidents 12028 and those that are not. In a CA workstation, for example, a list 12029 of security events might include the following: 12030 - Logging an operator into or out of the system. 12031 - Performing a cryptographic operation, e.g., signing a digital 12032 certificate or CRL. 12033 - Performing a cryptographic card operation: creation, insertion, 12034 removal, or backup. 12035 - Performing a digital certificate lifecycle operation: rekey, 12036 renewal, revocation, or update. 12038 - Posting a digital certificate to an X.500 Directory. 12039 - Receiving a key compromise notification. 12040 - Receiving an improper certification request. 12041 - Detecting an alarm condition reported by a cryptographic 12042 module. 12043 - Failing a built-in hardware self-test or a software system 12044 integrity check. 12046 $ security fault analysis 12047 (I) A security analysis, usually performed on hardware at the 12048 level of gate logic, gate-by-gate, to determine the security 12049 properties of a device when a hardware fault is encountered. 12051 $ security gateway 12052 1. (I) An internetwork gateway that separates trusted (or 12053 relatively more trusted) hosts on one side from untrusted (or less 12054 trusted) hosts on the other side. (See: firewall and guard.) 12056 2. (O) /IPsec/ "An intermediate system that implements IPsec 12057 protocols." [R2401] 12059 Tutorial: IPsec's AH or ESP can be implemented on a gateway 12060 between a protected network and an unprotected network, in order 12061 to provide security services to the protected network's hosts when 12062 they communicate across the unprotected network to other hosts and 12063 gateways. 12065 $ security incident 12066 1. (I) A security event that involves a security violation. (See: 12067 CERT, GRIP, security event, security intrusion, security 12068 violation.) 12070 Tutorial: In other words, a security-relevant system event in 12071 which the system's security policy is disobeyed or otherwise 12072 breached. 12074 2. (D) "Any adverse event [that] compromises some aspect of 12075 computer or network security." [R2350] 12077 Deprecated Definition: ISDs SHOULD NOT use this definition, 12078 because (a) a security incident may occur without actually being 12079 harmful (i.e., adverse) and (b) this Glossary defines "compromise" 12080 more narrowly in relation to unauthorized access. 12082 3. (D) "A violation or imminent threat of violation of computer 12083 security policies, acceptable use policies, or standard computer 12084 security practices." [SP61] 12086 Deprecated Definition: ISDs SHOULD NOT use this definition because 12087 mixes concepts in way that does not agree with common usage; a 12088 security incident is commonly thought of as involving a 12089 realization of a threat (see: threat action), not just a threat. 12091 $ security intrusion 12092 (I) A security event, or a combination of multiple security 12093 events, that constitutes a security incident in which an intruder 12094 gains, or attempts to gain, access to a system or system resource 12095 without having authorization to do so. 12097 $ security kernel 12098 (I) "The hardware, firmware, and software elements of a trusted 12099 computing base that implement the reference monitor concept. It 12100 must mediate all accesses, be protected from modification, and be 12101 verifiable as correct." [NCS04] (See: kernel, TCB.) 12103 Tutorial: A security kernel is an implementation of a reference 12104 monitor for a given hardware base. [Huff] 12106 $ security label 12107 (I) An item of meta-data that designates the value of one or more 12108 security-relevant attributes (e.g., security level) of a system 12109 resource. (See: [R1457]. Compare: security marking.) 12111 Deprecated usage: To avoid confusion, ISDs SHOULD NOT use 12112 "security label" for "security marking", or vice versa, even 12113 though that is commonly done (including in some national and 12114 international standards that should know better). 12116 Tutorial: Humans and automated security mechanisms use a security 12117 label of a system resource to determine, according to applicable 12118 security policy, how to control access to the resource (and they 12119 affix appropriate, matching security markings to physical 12120 instances of the resource). Security labels are most often used to 12121 support data confidentiality policy, and sometimes used to support 12122 data integrity policy. 12124 As explained in [R1457], the form that is taken by security labels 12125 of a protocol's packets varies depending on the OSIRM layer in 12126 which the protocol operates. Like meta-data generally, a security 12127 label of a data packet may be either explicit (e.g., IPSO) or 12128 implicit (e.g., Alice treats all messages received from Bob as 12129 being labeled "Not For Public Release"). In a connectionless 12130 protocol, every packet might have an explicit label; but in a 12131 connection-oriented protocol, all packets might have the same 12132 implicit label that is determined at the time the connection is 12133 established. 12135 Both classified and unclassified system resources may require a 12136 security label. (See: FOUO.) 12138 $ security level 12139 (I) The combination of a hierarchical classification level and a 12140 set of non-hierarchical category designations that represents how 12141 sensitive a specified type or item of information is. (See: 12143 dominate, lattice model. Compare: classification level.) 12145 Usage: ISDs that use this term SHOULD state a definition for it. 12146 The term is usually understood to involve sensitivity to 12147 disclosure, but it also is used in many other ways and could 12148 easily be misunderstood. 12150 $ Security Level field 12151 (I) A 16-bit field that specifies a security level value in the 12152 security option (option type 130) of version 4 IP's datagram 12153 header format. 12155 Deprecated Abbreviation: ISDs SHOULD NOT use the abbreviation "S 12156 field", which is potentially ambiguous. 12158 $ security management infrastructure (SMI) 12159 (I) System components and activities that support security policy 12160 by monitoring and controlling security services and mechanisms, 12161 distributing security information, and reporting security events. 12163 Tutorial: The associated functions are as follows [I7498-4]: 12164 - Controlling (granting or restricting) access to system 12165 resources: This includes verifying authorizations and 12166 identities, controlling access to sensitive security data, and 12167 modifying access priorities and procedures in the event of 12168 attacks. 12169 - Retrieving (gathering) and archiving (storing) security 12170 information: This includes logging security events and 12171 analyzing the log, monitoring and profiling usage, and 12172 reporting security violations. 12173 - Managing and controlling the encryption process: This includes 12174 performing the functions of key management and reporting on key 12175 management problems. (See: PKI.) 12177 $ security marking 12178 (I) A physical marking that is bound to an instance of a system 12179 resource and that represents a security label of the resource, 12180 i.e., that names or designates the value of one or more security- 12181 relevant attributes of the resource. (Compare: security label.) 12183 Tutorial: A security label may be represented by various 12184 equivalent markings depending on the physical form taken by the 12185 labeled resource. For example, a document could have a marking 12186 composed of a bit pattern [FP188] when the document is stored 12187 electronically as a file in a computer, and also a marking of 12188 printed alphabetic characters when the document is in paper form. 12190 $ security mechanism 12191 (I) A process (or a device incorporating such a process) that can 12192 be used in a system to implement a security service that is 12193 provided by or within the system. (See: Tutorial under "security 12194 policy". Compare: security doctrine.) 12195 Usage: Usually understood to refer primarily to components of 12196 communication security, computer security, and emanation security. 12198 Examples: Authentication exchange, checksum, digital signature, 12199 encryption, and traffic padding. 12201 $ security model 12202 (I) A schematic description of a set of entities and relationships 12203 by which a specified set of security services are provided by or 12204 within a system. Example: Bell-LaPadula model, OSIRM . (See: 12205 Tutorial under "security policy".) 12207 $ security parameters index (SPI) 12208 (I) /IPsec/ A 32-bit identifier used to distinguish among security 12209 associations that terminate at the same destination (IP address) 12210 and use the same security protocol (AH or ESP). Carried in AH and 12211 ESP to enable the receiving system to determine under which 12212 security association to process a received packet. 12214 (I) /mobile IP/ A 32-bit index identifying a security association 12215 from among the collection of associations that are available 12216 between a pair of nodes, for application to mobile IP protocol 12217 messages that the nodes exchange. 12219 $ security perimeter 12220 (I) A physical or logical boundary that is defined for a domain or 12221 enclave and within which a particular security policy or security 12222 architecture applies. (See: insider, outsider.) 12224 $ security policy 12225 1. (I) A definite goal, course, or method of action to guide and 12226 determine present and future decisions concerning security in a 12227 system. [R3198] 12229 2a. (I) A set of policy rules (or principles) that direct how a 12230 system (or an organization) provides security services to protect 12231 sensitive and critical system resources. (See: identity-based 12232 security policy, policy rule, rule-based security policy, rules of 12233 behavior. Compare: security architecture, security doctrine, 12234 security mechanism, security model, [R1281].) 12236 2b. (O) A set of rules to administer, manage, and control access 12237 to network resources. [R3060, R3198] 12239 2c. (O) /X.509/ A set of rules laid down by an authority to govern 12240 the use and provision of security services and facilities. 12242 2d. (O) /Common Criteria/ A set of rules that regulate how assets 12243 are managed, protected, and distributed within a TOE. 12245 Tutorial: Ravi Sandhu suggests that security policy is one of four 12246 layers of the security engineering process (as shown in the 12247 following diagram). Each layer provides a different view of 12248 security, ranging from what services are needed to how services 12249 are implemented. 12251 What Security Services 12252 Should Be Provided? +- - - - - - - - - - - - -+ 12253 ^ +- - - - - - - - - - - -| Mission Functions View | 12254 | | Security Policy |- - - - - - - - - - - - -+ 12255 | +- - - - - - - - - - - -| Domain Practices View | 12256 | | Security Model |- - - - - - - - - - - - -+ 12257 | +- - - - - - - - - - - -| Enclave Services View | 12258 | | Security Architecture |- - - - - - - - - - - - -+ 12259 | +- - - - - - - - - - - -| Agent Mechanisms View | 12260 | | Security Mechanism |- - - - - - - - - - - - -+ 12261 v +- - - - - - - - - - - -| Platform Devices View | 12262 How Are Security +- - - - - - - - - - - - -+ 12263 Services Implemented? 12265 We suggest that each of Sandhu's four layers is a mapping between 12266 two points of view that differ in their degree of abstraction, 12267 according to the perspectives of various participants in system 12268 design, development, and operation activities, as follows:. 12269 - Mission functions view: The perspective of a user of system 12270 resources. States time-phased protection needs for resources 12271 and identifies sensitive and critical resources -- networks, 12272 hosts, applications, and databases. Independent of rules and 12273 practices used to achieve protection. 12274 - Domain practices view: The perspective of an enterprise manager 12275 who sets protection standards for resources. States rules and 12276 practices for protection. Identifies domain members; i.e., 12277 entities (users/providers) and resources (including data 12278 objects). Independent of system topology. Not required to be 12279 hierarchical. 12280 - Enclave services view: The perspective of a system designer who 12281 allocates security functions to major components. Assigns 12282 security services to system topology structures and their 12283 contents. Independent of security mechanisms. Hierarchical 12284 across all domains. 12285 - Agent mechanisms view: The perspective of a system engineer who 12286 specifies security mechanisms to implement security services. 12287 Specifies mechanisms to be used by protocol, database, and 12288 application engines. Independent of type and manufacture of 12289 platforms and other physical devices. 12290 - Platform devices view: The perspective of an as-built 12291 description of the system in operation. Specifies exactly how 12292 to build or assemble the system, and also specifies procedures 12293 for operating the system. 12295 $ Security Policy Database (SPD) 12296 (I) /IPsec/ In an IPsec implementation operating in a network 12297 node, a database that contains parameters that specify policies 12298 set by a user or administrator to determine what IPsec services, 12299 if any, are to be provided to IP datagrams sent or received by the 12300 node, and in what fashion they are provided. For each datagram, 12301 the SPD specifies one of three choices: discard the datagram, 12302 apply IPsec services (e.g., AH or ESP), or bypass IPsec. Separate 12303 inbound and outbound SPDs are needed because of the directionality 12304 of IPsec security associations. [R2401] (Compare: SAD.) 12306 $ Security Protocol 3 (SP3) 12307 (O) A protocol [SDNS3] developed by SDNS to provide connectionless 12308 data security at the top of OSIRM Layer 3. (Compare: IPsec, NLSP.) 12310 $ Security Protocol 4 (SP4) 12311 (O) A protocol [SDNS4] developed by SDNS to provide either 12312 connectionless or end-to-end connection-oriented data security at 12313 the bottom of OSIRM Layer 4. (See: TLSP.) 12315 $ security-relevant event 12316 (D) See: security event. 12318 $ security service 12319 1. (I) A processing or communication service that is provided by a 12320 system to give a specific kind of protection to system resources. 12321 (See: access control service, audit service, availability service, 12322 data confidentiality service, data integrity service, data origin 12323 authentication service, non-repudiation service, peer entity 12324 authentication service, system integrity service.) 12326 Tutorial: Security services implement security policies, and are 12327 implemented by security mechanisms. 12329 2. (O) "A service, provided by a layer of communicating open 12330 systems, which ensures adequate security of the systems or the 12331 data transfers." [I7498 Part 2] 12333 $ security situation 12334 (I) /ISAKMP/ The set of all security-relevant information -- e.g., 12335 network addresses, security classifications, manner of operation 12336 (normal or emergency) -- that is needed to decide the security 12337 services that are required to protect the association that is 12338 being negotiated. 12340 $ security target 12341 (N) /Common Criteria/ A set of security requirements and 12342 specifications to be used as the basis for evaluation of an 12343 identified TOE. 12345 Tutorial: An security target (ST) is a statement of security 12346 claims for a particular information technology security product or 12347 system, and is the basis for agreement among all parties as to 12348 what security the product or system offers. An ST parallels the 12349 structure of an protection profile, but has additional elements 12350 that include product-specific detailed information. An ST contains 12351 a summary specification, which defines the specific measures taken 12352 in the product or system to meet the security requirements. 12354 $ security token 12355 (I) See: token. 12357 $ security violation 12358 (I) An act or event that disobeys or otherwise breaches security 12359 policy. (See: compromise, penetration, security incident.) 12361 $ seed 12362 (I) A value that is an input to a pseudorandom number generator. 12364 $ selective-field confidentiality 12365 (I) A data confidentiality service that preserves confidentiality 12366 for one or more parts (i.e., fields) of each packet. (See: 12367 selective-field integrity.) 12369 Tutorial: Data confidentiality service usually is applied to 12370 entire SDUs, but some situations might require protection of only 12371 part of each packet. For example, when Alice uses a debit card at 12372 an automated teller machine (ATM), perhaps only her personal 12373 identification number (PIN) is enciphered for confidentiality when 12374 her transaction request is transmitted from the ATM to her bank's 12375 computer. 12377 In any given operational situation, there could be many different 12378 reasons for using selective field confidentiality. In the ATM 12379 example, there are at least four possibilities: The service may 12380 provide a fail-safe mode of operation, ensuring that the bank can 12381 still process transactions (although with some risk) even when the 12382 encryption system fails. It may make messages easier to work with 12383 when doing system fault isolation. It may avoid problems with laws 12384 that prevent shipping enciphered data across international 12385 borders. It may improve efficiency by reducing processing load at 12386 a central computer site. 12388 $ selective-field integrity 12389 (I) A data integrity service that preserves integrity for one or 12390 more parts (i.e., fields) of each packet. (See: selective-field 12391 confidentiality.) 12393 Tutorial: Data integrity service may be implemented in a protocol 12394 to protect the SDU part of packets, the PCI part, or both. 12395 - SDU protection: When service is provided for SDUs, it usually 12396 is applied to entire SDUs, but it might be applied only to 12397 parts of SDUs in some situations. For example, an IPS 12398 Application-Layer protocol might need protection of only part 12399 of each packet, and this might enable faster processing. 12400 - PCI protection: To prevent active wiretapping, it might be 12401 desirable to apply data integrity service to the entire PCI, 12402 but some PCI fields in some protocols need to be mutable in 12403 transit. For example, the "Time to Live" field in IPv4 is 12404 changed each time a packet passes through a router in the 12405 Internet Layer. Thus, the value that the field will have when 12406 the packet arrives at its destination is not predictable by the 12407 sender and cannot be included in a checksum computed by the 12408 sender. (See: Authentication Header.) 12410 $ self-signed certificate 12411 (I) A public-key certificate for which the public key bound by the 12412 certificate and the private key used to sign the certificate are 12413 components of the same key pair, which belongs to the signer. 12414 (Compare: root certificate.) 12416 Tutorial: In a self-signed X.509 public-key certificate, the 12417 issuer's DN is the same as the subject's DN. 12419 $ semantic security 12420 (I) An attribute of a encryption algorithm that is a formalization 12421 of the notion that the algorithm not only hides the plain text but 12422 also reveals no partial information about the plain text; i.e., 12423 whatever is computable about the plain text when given the cipher 12424 text, is also computable without the cipher text. (Compare: 12425 indistinguishability.) 12427 $ semiformal 12428 (I) Expressed in a restricted syntax language with defined 12429 semantics. [CCIB] (Compare: formal, informal.) 12431 $ sensitive 12432 (I) A condition of a system resource such that the loss of some 12433 specified property of that resource, such as confidentiality or 12434 integrity, would adversely affect the interests or business of its 12435 owner or user. (See: sensitive information. Compare: critical.) 12437 $ sensitive compartmented information (SCI) 12438 (O) /U.S. Government/ Classified information concerning or derived 12439 from intelligence sources, methods, or analytical processes, which 12440 is required to be handled within formal control systems 12441 established by the Director of Central Intelligence. [DC6/9] (See: 12442 compartment, SCIF) 12444 $ sensitive compartmented information facility (SCIF) 12445 (O) /U.S. Government/ An accredited area, room, group of rooms, 12446 building, or installation where SCI may be stored, used, 12447 discussed, or electronically processed. [DC6/9] (See: SCI. 12448 Compare: shielded enclosure.) 12450 $ sensitive information 12451 (I) Information for which (a) disclosure, (b) alteration, or (c) 12452 destruction or loss could adversely affect the interests or 12453 business of its owner or user. (See: data confidentiality, data 12454 integrity, sensitive. Compare: classified, critical.) 12456 (O) /U.S. Government/ Information for which (a) loss, (b) misuse, 12457 (c) unauthorized access, or (d) unauthorized modification could 12458 adversely affect the national interest or the conduct of federal 12459 programs, or the privacy to which individuals are entitled under 12460 the Privacy Act of 1974, but that has not been specifically 12461 authorized under criteria established by an Executive Order or an 12462 Act of Congress to be kept classified in the interest of national 12463 defense or foreign policy. 12465 Tutorial: Systems that are not U.S. national security systems, but 12466 contain sensitive U.S. Federal Government information, must be 12467 protected according to the Computer Security Act of 1987 (Public 12468 Law 100-235). 12470 $ sensitivity label 12471 (D) Synonym for "classification label". 12473 Deprecated term: ISDs SHOULD NOT use this term because the 12474 definition of "sensitive" involves not only data confidentiality, 12475 but also data integrity. 12477 $ sensitivity level 12478 (D) Synonym for "classification level". 12480 Deprecated term: ISDs SHOULD NOT use this term because the 12481 definition of "sensitive" involves not only data confidentiality, 12482 but also data integrity. 12484 $ separation of duties 12485 (I) The practice of dividing the steps in a system process among 12486 different individual entities (i.e., different users or different 12487 roles) so as to prevent a single entity acting alone from being 12488 able to subvert the process. Usage: a.k.a. "separation of 12489 privilege". (See: administrative security, dual control.) 12491 $ serial number 12492 See: certificate serial number. 12494 $ Serpent 12495 (O) A symmetric, 128-bit block cipher designed by Ross Anderson, 12496 Eli Biham, and Lars Knudsen as a candidate for the AES. 12498 $ server 12499 (I) A system entity that provides a service in response to 12500 requests from other system entities called clients. 12502 $ service data unit (SDU) 12503 (N) See: secondary definition under "protocol data unit". 12505 $ session 12506 1a. (I) /computer usage/ A continuous period of time, usually 12507 initiated by a login, during which a user accesses a computer 12508 system. 12510 1b. (I) /computer activity/ The set of transactions or other 12511 computer activities that are performed by or for a user during a 12512 period of computer usage. 12514 2. (I) /access control/ A temporary mapping of a principal to one 12515 or more roles. (See: role-based access control.) 12517 Tutorial: A user establishes a session as a principal and 12518 activates some subset of roles to which the principal has been 12519 assigned. The authorizations available to the principal in the 12520 session are the union of the permissions of all the roles 12521 activated in the session. Each session is associated with a single 12522 principal and, therefore, with a single user. A principal may have 12523 multiple, concurrent sessions and may activate a different set of 12524 roles in each session. 12526 3. (I) /computer network/ A persistent but (normally) temporary 12527 association between a user agent (typically a client) and a second 12528 process (typically a server). The association may persist across 12529 multiple exchanges of data, including multiple connections. 12530 (Compare: security association.) 12532 $ session key 12533 (I) In the context of symmetric encryption, a key that is 12534 temporary or is used for a relatively short period of time. (See: 12535 ephemeral, KDC, session. Compare: master key.) 12537 Tutorial: A session key is used for a defined period of 12538 communication between two system entities or components, such as 12539 for the duration of a single connection or transaction set; or the 12540 key is used in an application that protects relatively large 12541 amounts of data and, therefore, needs to be rekeyed frequently. 12543 $ SET(trademark) 12544 (O) See: SET Secure Electronic Transaction(trademark). 12546 $ SET private extension 12547 (O) One of the private extensions defined by SET for X.509 12548 certificates. Carries information about hashed root key, 12549 certificate type, merchant data, cardholder certificate 12550 requirements, encryption support for tunneling, or message support 12551 for payment instructions. 12553 $ SET qualifier 12554 (O) A certificate policy qualifier that provides information about 12555 the location and content of a SET certificate policy. 12557 Tutorial: In addition to the policies and qualifiers inherited 12558 from its own certificate, each CA in the SET certification 12559 hierarchy may add one qualifying statement to the root policy when 12560 the CA issues a certificate. The additional qualifier is a 12561 certificate policy for that CA. Each policy in a SET certificate 12562 may have these qualifiers: (a) a URL where a copy of the policy 12563 statement may be found; (b) an electronic mail address where a 12564 copy of the policy statement may be found; (c) a hash result of 12565 the policy statement, computed using the indicated algorithm; and 12566 (d) a statement declaring any disclaimers associated with the 12567 issuing of the certificate. 12569 $ SET Secure Electronic Transaction(trademark) or SET(trademark) 12570 (N) A protocol developed jointly by MasterCard International and 12571 Visa International and published as an open standard to provide 12572 confidentiality of transaction information, payment integrity, and 12573 authentication of transaction participants for payment card 12574 transactions over unsecured networks, such as the Internet. [SET1] 12575 (See: acquirer, brand, cardholder, dual signature, electronic 12576 commerce, IOTP, issuer, merchant, payment gateway, third party.) 12578 Tutorial: This term and acronym are trademarks of SETCo. 12579 MasterCard and Visa announced the SET standard on 1 February 1996. 12581 $ SETCo 12582 (O) Abbreviation of "SET Secure Electronic Transaction LLC", 12583 formed on 19 December 1997 by MasterCard and Visa for the purpose 12584 of implementing the SET Secure Electronic Transaction(trademark) 12585 standard. A later memorandum of understanding added American 12586 Express and JCB Credit Card Company as co-owners of SETCo. 12588 $ SHA, SHA-1, SHA-2 12589 (N) See: Secure Hash Algorithm. 12591 $ shared identity 12592 (I) See: secondary definition under "identity". 12594 $ shared secret 12595 (D) A synonym for "cryptographic key" or "password". 12597 Deprecated Usage: ISDs that use this term SHOULD state a 12598 definition for it because the term is used in many ways and could 12599 easily be misunderstood. 12601 $ shielded enclosure 12602 (O) "Room or container designed to attenuate electromagnetic 12603 radiation." [C4009] (See: emanation. Compare: SCIF.) 12605 $ short title 12606 (O) "Identifying combination of letters and numbers assigned to 12607 certain items of COMSEC material to facilitate handling, 12608 accounting, and controlling." [C4009] (Compare: KMID, long title.) 12610 $ SHS 12611 (N) See: Secure Hash Standard. 12613 $ sign 12614 (I) Create a digital signature for a data object. (See: signer.) 12616 $ signal analysis 12617 (I) Gaining indirect knowledge (inference) of communicated data by 12618 monitoring and analyzing a signal that is emitted by a system and 12619 that contains the data but is not intended to communicate the 12620 data. (See: emanation. Compare: traffic analysis.) 12622 $ signal intelligence 12623 (I) The science and practice of extracting information from 12624 signals. (See: signal security.) 12626 $ signal security 12627 (N) (I) The science and practice of protecting signals. (See: 12628 cryptology, security.) 12630 Tutorial: The term "signal" denotes (a) communication in almost 12631 any form and also (b) emanations for other purposes, such as 12632 radar. Signal security is opposed by signal intelligence, and each 12633 discipline includes opposed sub-disciplines as follows [Kahn]: 12635 Signal Security Signal Intelligence 12636 ------------------------------ --------------------------------- 12637 1. Communication Security 1. Communication Intelligence 12638 1a. Cryptography 1a. Cryptanalysis 12639 1b. Traffic Security 1b. Traffic Analysis 12640 1c. Steganography 1c. Detection and Interception 12641 2. Electronic Security 2. Electronic Intelligence 12642 2a. Emission Security 2a. Electronic Reconnaissance 12643 2b. Counter-Countermeasures 2b. Countermeasures 12644 ------------------------------ --------------------------------- 12646 $ signature 12647 (O) A symbol or process adopted or executed by a system entity 12648 with present intention to declare that a data object is genuine. 12649 (See: digital signature, electronic signature.) 12651 $ signature certificate 12652 (I) A public-key certificate that contains a public key that is 12653 intended to be used for verifying digital signatures, rather than 12654 for encrypting data or performing other cryptographic functions. 12656 Tutorial: A v3 X.509 public-key certificate may have a "keyUsage" 12657 extension that indicates the purpose for which the certified 12658 public key is intended. (See: certificate profile.) 12660 $ signed receipt 12661 (I) An S/MIME service [R2634] that (a) provides, to the originator 12662 of a message, proof of delivery of the message and (b) enables the 12663 originator to demonstrate to a third party that the recipient was 12664 able to verify the signature of the original message. 12666 Tutorial: The receipt is bound to the original message by a 12667 signature; consequently, the service may be requested only for a 12668 message that is signed. The receipt sender may optionally also 12669 encrypt the receipt to provide confidentiality between the receipt 12670 sender and the receipt recipient. 12672 $ signer 12673 (N) A human being or organization entity that uses a private key 12674 to sign (i.e., create a digital signature on) a data object. [ABA] 12676 $ SILS 12677 (N) See: Standards for Interoperable LAN/MAN Security. 12679 $ simple authentication 12680 1. (I) An authentication process that uses a password as the 12681 information needed to verify an identity claimed for an entity. 12682 (Compare: strong authentication.) 12684 2. (O) "Authentication by means of simple password arrangements." 12685 [X509] 12687 $ Simple Authentication and Security Layer (SASL) 12688 (I) An Internet specification [R2222] for adding authentication 12689 service to connection-based protocols. 12691 Tutorial: To use SASL, a protocol includes a command for 12692 authenticating a user to a server and for optionally negotiating 12693 protection of subsequent protocol interactions. The command names 12694 a registered security mechanism. SASL mechanisms include Kerberos, 12695 GSSAPI, S/KEY, and others. Some protocols that use SASL are IMAP4 12696 and POP3. 12698 $ Simple Key Management for Internet Protocols (SKIP) 12699 (I) A key-distribution protocol that uses hybrid encryption to 12700 convey session keys that are used to encrypt data in IP packets. 12702 Tutorial: SKIP was designed by Ashar Aziz and Whitfield Diffie at 12703 Sun Microsystems and proposed as the standard key management 12704 protocol for IPsec, but IKE was chosen instead. Although IKE is 12705 mandatory for an IPsec implementation, the use of SKIP is not 12706 excluded. 12708 SKIP uses the Diffie-Hellman algorithm (or could use another key- 12709 agreement algorithm) to generate a key-encrypting key for use 12710 between two entities. A session key is used with a symmetric 12711 algorithm to encrypt data in one or more IP packets that are to be 12712 sent from one entity to the other. A symmetric KEK is established 12713 and used to encrypt the session key, and the encrypted session key 12714 is placed in a SKIP header that is added to each IP packet that is 12715 encrypted with that session key. 12717 $ Simple Mail Transfer Protocol (SMTP) 12718 (I) A TCP-based, Application-Layer, Internet Standard protocol 12719 (RFC 821) for moving electronic mail messages from one computer to 12720 another. 12722 $ Simple Network Management Protocol (SNMP) 12723 (I) A TCP-based, Application-Layer, Internet Standard protocol 12724 [R3410, R3414] for conveying management information between system 12725 components that act as managers and agents. 12727 $ Simple Public Key Infrastructure (SPKI) 12728 (I) A set of experimental concepts (RFCs 2692, 2693) that were 12729 proposed as alternatives to the concepts standardized in PKIX. 12731 $ simple security property 12732 (N) /formal model/ Property of a system whereby a subject has 12733 read access to an object only if the clearance of the subject 12734 dominates the classification of the object. See: Bell-LaPadula 12735 model. 12737 $ single sign-on 12738 (I) A system that enables a user to access multiple computer 12739 platforms (usually a set of hosts on the same network) or multiple 12740 application systems after being authenticated just one time. (See: 12741 Kerberos.) 12743 Tutorial: In a single sign-on system, a user typically logs in 12744 just once, and then is transparently granted access to a set of 12745 system resources with no further login being required (unless, of 12746 course, the user logs out). Such a system has the advantages of 12747 being user friendly and enabling authentication to be managed 12748 consistently across an entire enterprise. Such a system also has 12749 the disadvantage of requiring all hosts and applications to trust 12750 the same authentication information. 12752 $ singular identity 12753 (I) See: secondary definition under "identity". 12755 $ site 12756 (I) A facility -- i.e., a physical space, room, or building 12757 together with its physical, personnel, administrative, and other 12758 safeguards -- in which system functions are performed. (See: 12759 node.) 12761 $ situation 12762 (I) See: security situation. 12764 $ SKEME 12765 (I) A key-distribution protocol from which features were adapted 12766 for IKE. [SKEME] 12768 $ SKIP 12769 (I) See: Simple Key Management for Internet Protocols. 12771 $ SKIPJACK 12772 (N) A type 2, 64-bit block cipher [SKIP, R2773] with a key size of 12773 80 bits. (See: CAPSTONE, CLIPPER, FORTEZZA, Key Exchange 12774 Algorithm.) 12776 Tutorial: SKIPJACK was developed by NSA and formerly classified at 12777 the U.S. DoD "Secret" level. On 23 June 1998, NSA announced that 12778 SKIPJACK had been declassified. 12780 $ slot 12781 (O) /MISSI/ One of the FORTEZZA PC card storage areas that are 12782 each able to hold an X.509 certificate plus other data, including 12783 the private key that is associated with a public-key certificate. 12785 $ smart card 12786 (I) A credit-card sized device containing one or more integrated 12787 circuit chips, which perform the functions of a computer's central 12788 processor, memory, and input/output interface. (See: PC card, 12789 smart token.) 12791 Usage: Sometimes this term is used rather strictly to mean a card 12792 that closely conforms to the dimensions and appearance of the kind 12793 of plastic credit card issued by banks and merchants. At other 12794 times, the term is used loosely to include cards that are larger 12795 than credit cards, especially cards that are thicker, such as PC 12796 cards. 12798 $ smart token 12799 (I) A device that conforms to the definition of "smart card" 12800 except that rather than having the standard dimensions of a credit 12801 card, the token is packaged in some other form, such as a military 12802 dog tag or a door key. (See: smart card, cryptographic token.) 12804 $ SMI 12805 (I) See: security management infrastructure. 12807 $ SMTP 12808 (I) See: Simple Mail Transfer Protocol. 12810 $ smurf attack 12811 (D) /slang/ A denial-of-service attack that uses IP broadcast 12812 addressing to send ICMP ping packets with the intent of flooding a 12813 system. (See: ICMP flood.) 12815 Deprecated Term: ISDs SHOULD NOT use this term. It is not listed 12816 in most English dictionaries, and other cultures are likely to use 12817 different metaphors for this concept. 12819 Derivation: The Smurfs are a fictional race of many small, blue 12820 creatures that were created by a cartoonist. Perhaps the inventor 12821 of this attack thought that a swarm of ping packets resembled a 12822 gang of smurfs. (See: Deprecated Usage under "Green Book".) 12824 Tutorial: The attacker sends ICMP echo request ("ping") packets 12825 that appear to originate not from the attacker's own IP address, 12826 but from the address of the host or router that is the target of 12827 the attack. Each packet is addressed to an IP broadcast address, 12828 e.g., to all IP addresses in a given network. Thus, each echo 12829 request that is sent by the attacker results in many echo 12830 responses being sent to the target address. This attack can 12831 disrupt service at a particular host, at the hosts that depend on 12832 a particular router, or in an entire network. 12834 $ sneaker net 12835 (D) /slang/ A process that transfers data between systems only 12836 manually, under human control; i.e., a data transfer process that 12837 involves an air gap. 12839 Deprecated Term: ISDs SHOULD NOT use this term. It is not listed 12840 in most English dictionaries, and other cultures are likely to use 12841 different metaphors for this concept. 12843 $ Snefru 12844 (N) A public-domain, cryptographic hash function (also called "The 12845 Xerox Secure Hash Function") designed by Ralph C. Merkle at Xerox 12846 Corporation. Snefru can produce either a 128-bit or 256-bit output 12847 (i.e., hash result). [Schn] (See: Khafre, Khufu.) 12849 $ sniffing 12850 (D) /slang/ Synonym for "passive wiretapping". (See: password 12851 sniffing.) 12853 Deprecated Term: ISDs SHOULD NOT use this term; it unnecessarily 12854 duplicates the meaning of a term that is better established. (See: 12855 Deprecated Usage under "Green Book". 12857 $ SNMP 12858 (I) See: Simple Network Management Protocol. 12860 $ social engineering 12861 (D) A euphemism for non-technical or low-technology methods, often 12862 involving trickery or fraud, that are used to attack information 12863 systems. 12865 Deprecated Term: ISDs SHOULD NOT use this term; it is too vague. 12866 Instead, use a term that is specific with regard to the means of 12867 attack, e.g., blackmail, bribery, coercion, impersonation, 12868 intimidation, lying, or theft. 12870 $ SOCKS 12871 (I) An Internet protocol [R1928] that provides a generalized proxy 12872 server that enables client-server applications (e.g., TELNET, FTP, 12873 or HTTP; running over either TCP or UDP) to use the services of a 12874 firewall. 12876 Tutorial: SOCKS is layered under the IPS Application Layer and 12877 above the Transport Layer. When a client inside a firewall wishes 12878 to establish a connection to an object that is reachable only 12879 through the firewall, it uses TCP to connect to the SOCKS server, 12880 negotiates with the server for the authentication method to be 12881 used, authenticates with the chosen method, and then sends a relay 12882 request. The SOCKS server evaluates the request, typically based 12883 on source and destination addresses, and either establishes the 12884 appropriate connection or denies it. 12886 $ soft TEMPEST 12887 (O) The use of software techniques to reduce the radio frequency 12888 information leakage from computer displays and keyboards. [Kuhn] 12889 (See: TEMPEST.) 12891 $ software 12892 (I) Computer programs (which are stored in and executed by 12893 computer hardware) and associated data (which also is stored in 12894 the hardware) that may be dynamically written or modified during 12895 execution. (Compare: firmware.) 12897 $ SORA 12898 (O) See: SSO-PIN ORA. 12900 $ source authentication 12901 (D) Synonym for "data origin authentication" or "peer entity 12902 authentication". (See: data origin authentication, peer entity 12903 authentication). 12905 Deprecated Term: ISDs SHOULD NOT use this term because it is 12906 ambiguous and, in either meaning, duplicates the meaning of 12907 internationally standardized terms. If the intent is to 12908 authenticate the original creator or packager of data received, 12909 then use "data origin authentication". If the intent is to 12910 authenticate the identity of the sender of data in the current 12911 instance, then use "peer entity authentication". 12913 $ source integrity 12914 (I) The property that data is trustworthy (i.e., worthy of 12915 reliance or trust), based on the trustworthiness of its sources 12916 and the trustworthiness of any procedures used for handling data 12917 in the system. Usage: a.k.a. Biba integrity. (See: integrity. 12918 Compare: correctness integrity, data integrity.) 12919 Tutorial: For this kind of integrity, there are formal models of 12920 unauthorized modification (see: Biba model) that logically 12921 complement the more familiar models of unauthorized disclosure 12922 (see: Bell-LaPadula model). In these models, objects are labeled 12923 to indicate the credibility of the data they contain, and there 12924 are rules for access control that depend on the labels. 12926 $ SP3 12927 (O) See: Security Protocol 3. 12929 $ SP4 12930 (O) See: Security Protocol 4. 12932 $ spam 12933 1a. (I) /slang verb/ To indiscriminately send unsolicited, 12934 unwanted, irrelevant, or inappropriate messages, especially 12935 commercial advertising in mass quantities. 12937 1b. (I) /slang noun/ Electronic "junk mail". [R2635] 12939 Deprecated Usage: ISDs SHOULD NOT use this term in upper-case 12940 letters, because SPAM(trademark) is a trademark of Hormel Foods 12941 Corporation. Hormel says, "We do not object to use of this slang 12942 term [spam] to describe [unsolicited advertising email], although 12943 we do object to the use of our product image in association with 12944 that term. Also, if the term is to be used, it SHOULD be used in 12945 all lower-case letters to distinguish it from our trademark SPAM, 12946 which SHOULD be used with all uppercase letters." (See: metadata.) 12948 Tutorial: In sufficient volume, spam can cause denial of service. 12949 (See: flooding.) According to Hormel, the term was adopted as a 12950 result of a Monty Python skit in which a group of Vikings sang a 12951 chorus of 'SPAM, SPAM, SPAM ...' in an increasing crescendo, 12952 drowning out other conversation. This lyric became a metaphor for 12953 the unsolicited advertising messages that threaten to overwhelm 12954 other discourse on the Internet. 12956 $ SPD 12957 (I) See: Security Policy Database. 12959 $ special access program (SAP) 12960 (O) /U.S. Government/ "[A kind of p]rogram [that is] established 12961 for a specific class of classified information [and] that imposes 12962 safeguarding and access requirements that exceed those normally 12963 required for information at the same classified level." [C4009] 12964 (See: formal access approval, SCI.) 12966 $ SPI 12967 (I) See: Security Parameters Index. 12969 $ SPKI 12970 (I) See: Simple Public Key Infrastructure. 12972 $ split key 12973 (I) A cryptographic key that is generated and distributed as two 12974 or more separate data items that individually convey no knowledge 12975 of the whole key that results from combining the items. (See: dual 12976 control, split knowledge.) 12978 $ split knowledge 12979 1. (I) A security technique in which two or more entities 12980 separately hold data items that individually do not convey 12981 knowledge of the information that results from combining the 12982 items. (See: dual control, split key.) 12984 2. (O) "A condition under which two or more entities separately 12985 have key components which individually convey no knowledge of the 12986 plaintext key which will be produced when the key components are 12987 combined in the cryptographic module." [FP140] 12989 $ spoofing attack 12990 (I) Synonym for "masquerade attack". 12992 $ spread spectrum 12993 (N) A TRANSEC technique that transmits a signal in a bandwidth 12994 much greater than the transmitted information needs. [F1037] 12995 Example: frequency hopping. 12997 Tutorial: Usually uses a sequential, noise-like signal structure 12998 to spread the normally narrowband information signal over a 12999 relatively wide band of frequencies. The receiver correlates the 13000 signals to retrieve the original information signal. This 13001 technique decreases potential interference to other receivers, 13002 while achieving data confidentiality and increasing immunity of 13003 spread spectrum receivers to noise and interference. 13005 $ spyware 13006 (D) /slang/ Software that an intruder has installed 13007 surreptitiously on a networked computer to gather data from that 13008 computer and send it through the network to the intruder or some 13009 other interested party. (See: malicious logic, Trojan horse.) 13011 Deprecated Usage: ISDs that use this term SHOULD state a 13012 definition for it because the term is used in many ways and could 13013 easily be misunderstood. 13015 Tutorial: Some examples of the types of data that might be 13016 gathered by spyware are application files, passwords, email 13017 addresses, usage histories, and keystrokes. Some examples of 13018 motivations for gathering the data are blackmail, financial fraud, 13019 identity theft, industrial espionage, market research, and 13020 voyeurism. 13022 $ SSH(trademark) 13023 (N) See: Secure Shell(trademark). 13025 $ SSL 13026 (I) See: Secure Sockets Layer. 13028 $ SSO 13029 (I) See: system security officer. 13031 $ SSO PIN 13032 (O) /MISSI/ One of two personal identification numbers that 13033 control access to the functions and stored data of a FORTEZZA PC 13034 card. Knowledge of the SSO PIN enables the card user to perform 13035 the FORTEZZA functions intended for use by an end user and also 13036 the functions intended for use by a MISSI CA. (See: user PIN.) 13038 $ SSO-PIN ORA (SORA) 13039 (O) /MISSI/ A MISSI organizational RA that operates in a mode in 13040 which the ORA performs all card management functions and, 13041 therefore, requires knowledge of the SSO PIN for FORTEZZA PC cards 13042 issued to end users. 13044 $ Standards for Interoperable LAN/MAN Security (SILS) 13045 1. (N) The IEEE 802.10 standards committee. (See: FP191.) 13047 2. (N) A set of IEEE standards, which has eight parts: (a) Model, 13048 including security management, (b) Secure Data Exchange protocol, 13049 (c) Key Management, (d) [has been incorporated in (a)], (e) SDE 13050 Over Ethernet 2.0, (f) SDE Sublayer Management, (g) SDE Security 13051 Labels, and (h) SDE PICS Conformance. Parts b, e, f, g, and h are 13052 incorporated in IEEE Standard 802.10-1998. 13054 $ star property 13055 (N) See: *-property. 13057 $ Star Trek attack 13058 (D) /slang/ An attack that penetrates your system where no attack 13059 has ever gone before. 13061 Deprecated Usage: This is a joke for Trekkies. (See: Deprecated 13062 Usage under "Green Book".) 13064 $ static 13065 (I) /adjective/ Refers to a cryptographic key or other parameter 13066 that is relatively long-lived. (Compare: ephemeral.) 13068 $ steganography 13069 (I) Methods of hiding the existence of a message or other data. 13070 This is different than cryptography, which hides the meaning of a 13071 message but does not hide the message itself. Examples: For 13072 classic, physical methods, see [Kahn]; for modern, digital 13073 methods, see [John]. (See: cryptology. Compare: digital 13074 watermarking.) 13076 $ storage channel 13077 (I) See: covert storage channel. 13079 $ storage key 13080 (I) A cryptographic key used by a device for protecting 13081 information that is being maintained in the device, as opposed to 13082 protecting information that is being transmitted between devices. 13083 (See: cryptographic token, token copy. Compare: traffic key.) 13085 $ stream cipher 13086 (I) An encryption algorithm that breaks plain text into a stream 13087 of successive elements (usually, bits) and encrypts the n-th 13088 plaintext element with the n-th element of a parallel key stream, 13089 thus converting the plaintext stream into a ciphertext stream. 13090 [Schn] (See: block cipher.) 13092 $ stream integrity service 13093 (I) A data integrity service that preserves integrity for a 13094 sequence of data packets, including both (a) bit-by-bit datagram 13095 integrity of each individual packet in the set and (b) packet-by- 13096 packet sequential integrity of the set as a whole. (See: data 13097 integrity. Compare: datagram integrity service.) 13099 Tutorial: Some internet applications need only datagram integrity, 13100 but others require that an entire stream of packets be protected 13101 against insertion, reordering, deletion, and delay: 13102 - "Insertion": The destination receives an additional packet that 13103 was not sent by the source. 13104 - "Reordering": The destination receives packets in a different 13105 order than that in which they were sent by the source. 13106 - "Deletion": A packet sent by the source is not ever delivered 13107 to the intended destination. 13108 - "Delay": A packet is detained for some period of time at a 13109 relay, thus hampering and postponing the packet's normal timely 13110 delivery from source to destination. 13112 $ strength 13113 1. (I) /cryptography/ A cryptographic mechanism's level of 13114 resistance to attacks [R3776]. 13116 2. (N) /Common Criteria/ "Strength of function" is a 13117 "qualification of a TOE security function expressing the minimum 13118 efforts assumed necessary to defeat its expected security behavior 13119 by directly attacking its underlying security mechanisms": (See: 13120 strong.) 13121 - Basic: "A level of the TOE strength of function where analysis 13122 shows that the function provides adequate protection against 13123 casual breach of TOE security by attackers possessing a low 13124 attack potential." 13125 - Medium: "... against straightforward or intentional breach ... 13127 by attackers possessing a moderate attack potential. 13128 - High: "... against deliberately planned or organized breach ... 13129 by attackers possessing a high attack potential." 13131 $ strong 13132 1. (I) /cryptography/ Used to describe a cryptographic algorithm 13133 that would require a large amount of computational power to defeat 13134 it. (See: work factor, strength.) 13136 2. (I) /COMPUSEC/ Used to describe a security mechanism that would 13137 be difficult to defeat. (See: strength.) 13139 $ strong authentication 13140 1. (I) An authentication process that uses a cryptographic 13141 security mechanism -- particularly public-key certificates -- to 13142 verify the identity claimed for an entity. (Compare: simple 13143 authentication.) 13145 2. (O) "Authentication by means of cryptographically derived 13146 credentials." [X509] 13148 $ subject 13149 1a. (I) A process in a computer system that represents a principal 13150 and that executes with the privileges that have been granted to 13151 that principal. (Compare: principal, user.) 13153 1b. (I) /formal model/ A system entity that causes information to 13154 flow among objects or changes the system state; technically, a 13155 process-domain pair. A subject may itself be an object relative to 13156 some other subject; thus, the set of subjects in a system is a 13157 subset of the set of objects. (See: Bell-LaPadula model, object.) 13159 2. (I) /digital certificate/ The entity name that is bound to the 13160 data items in a digital certificate, and particularly a name that 13161 is bound to a key in a public-key certificate. (See: X.509.) 13163 $ subject CA 13164 (D) The CA that is the subject of a cross-certificate issued by 13165 another CA. [X509] (See: cross-certification.) 13167 Deprecated Term: ISDs SHOULD NOT use this term because it is not 13168 widely known and could be misunderstood. Instead, say "the CA that 13169 is the subject of the cross-certificate". 13171 $ subnetwork 13172 (N) An OSI term for a system of packet relays and connecting links 13173 that implement OSIRM layers 2 or 3 to provide a communication 13174 service that interconnects attached end systems. Usually, the 13175 relays are all of the same type (e.g., X.25 packet switches, or 13176 interface units in an IEEE 802.3 LAN). (See: gateway, internet, 13177 router.) 13179 $ subordinate CA (SCA) 13180 1. (I) A CA whose public-key certificate is issued by another 13181 (superior) CA. (See: certification hierarchy. Compare: cross- 13182 certification.) 13184 2. (O) /MISSI/ The fourth-highest (i.e., bottom) level of a MISSI 13185 certification hierarchy; a MISSI CA whose public-key certificate 13186 is signed by a MISSI CA rather than by a MISSI PCA. A MISSI SCA is 13187 the administrative authority for a subunit of an organization, 13188 established when it is desirable to organizationally distribute or 13189 decentralize the CA service. The term refers both to that 13190 authoritative office or role, and to the person who fills that 13191 office. A MISSI SCA registers end users and issues their 13192 certificates and may also register ORAs, but may not register 13193 other CAs. An SCA periodically issues a CRL. 13195 $ subordinate DN 13196 (I) An X.500 DN is subordinate to another X.500 DN if it begins 13197 with a set of attributes that is the same as the entire second DN 13198 except for the terminal attribute of the second DN (which is 13199 usually the name of a CA). For example, the DN is subordinate to the DN 13201 . 13203 $ subscriber 13204 (I) /PKI/ A user that is registered in a PKI and, therefore, can 13205 be named in the "subject" field of a certificate issued by a CA in 13206 that PKI. (See: registration, user.) 13208 Usage: This term is needed to distinguish registered users from 13209 two other kinds of PKI users: 13210 - Users that access the PKI but are not identified to it: For 13211 example a relying party may access a PKI repository to obtain 13212 the certificate of some other party. (See: access.) 13213 - Users that do not access the PKI: For example, a relying party 13214 (see: certificate user) may use a digital certificate that was 13215 obtained from a database that is not part of the PKI that 13216 issued the certificate. 13218 $ substitution 13219 (I) /cryptography/ A method of encryption in which elements of the 13220 plain text retain their original sequence but are replaced by 13221 other elements. (Compare: transposition.) 13223 $ subsystem 13224 (I) A collection of related system components that together 13225 perform a system function or deliver a system service. 13227 $ superuser 13228 (I) /UNIX/ Synonym for "root". 13230 $ superencryption 13231 (I) An encryption operation for which the plaintext input to be 13232 transformed is the ciphertext output of a previous encryption 13233 operation. (Compare: hybrid encryption.) 13235 $ survivability 13236 (I) The ability of a system to remain in operation or existence 13237 despite adverse conditions, including natural occurrences, 13238 accidental actions, and attacks. (Compare: availability, 13239 reliability.) 13241 $ swIPe 13242 (I) An encryption protocol for IP that provides confidentiality, 13243 integrity, and authentication and can be used for both end-to-end 13244 and intermediate-hop security. [Ioan] (Compare: IPsec.) 13246 Tutorial: The swIPe protocol is an IP predecessor that is 13247 concerned only with encryption mechanisms; policy and key 13248 management are handled outside the protocol. 13250 $ syllabary 13251 (N) /encryption/ A list of individual letters, combinations of 13252 letters, or syllables, with their equivalent code groups, used for 13253 spelling out proper names or other unusual words that are not 13254 present in the basic vocabulary (i.e., are not in the codebook) of 13255 a code used for encryption. 13257 $ symmetric cryptography 13258 (I) A branch of cryptography in which the algorithms use the same 13259 key for both of two counterpart cryptographic operations (e.g., 13260 encryption and decryption). (See: asymmetric cryptography. 13261 Compare: secret-key cryptography.) 13263 Tutorial: Symmetric cryptography has been used for thousands of 13264 years [Kahn]. A modern example is AES. 13266 Symmetric cryptography has a disadvantage compared to asymmetric 13267 cryptography with regard to key distribution. For example, when 13268 Alice wants to ensure confidentiality for data she sends to Bob, 13269 she encrypts the data with a key, and Bob uses the same key to 13270 decrypt. However, keeping the shared key secret entails both cost 13271 and risk when the key is distributed to both Alice and Bob. (See: 13272 key distribution, key management.) 13274 $ symmetric key 13275 (I) A cryptographic key that is used in a symmetric cryptographic 13276 algorithm. (See: symmetric cryptography.) 13278 $ SYN flood 13279 (I) A denial-of-service attack that sends a large number of TCP 13280 SYN (synchronize) packets to a host with the intent of disrupting 13281 the operation of that host. (See: flooding.) 13282 Tutorial: This attack seeks to exploit a vulnerability in the TCP 13283 specification or in a TCP implementation. Normally, two hosts use 13284 a three-way exchange of packets to establish a TCP connection: (a) 13285 host 1 requests a connection by sending a SYN packet to host 2; 13286 (b) host 2 replies by sending a SYN-ACK (acknowledgement) packet 13287 to host 1; and (c) host 1 completes the connection by sending an 13288 ACK packet to host 2. To attack host 2, host 1 can send a series 13289 of TCP SYNs, each with a different phony source address. ([R2827] 13290 discusses how to use packet filtering to prevent such attacks from 13291 being launched from behind an Internet service provider's 13292 aggregation point.) Host 2 treats each SYN as a request from a 13293 separate host, replies to each with a SYN-ACK, and waits to 13294 receive the matching ACKs. (The attacker can use random or 13295 unreachable sources addresses in the SYN packets, or can use 13296 source addresses that belong to third parties, that then become 13297 secondary victims.) 13299 For each SYN-ACK that is sent, the TCP process in host 2 needs 13300 some memory space to store state information while waiting for the 13301 matching ACK to be returned. If the matching ACK never arrives at 13302 host 2, a timer associated with the pending SYN-ACK will 13303 eventually expire and release the space. But if host 1 (or a 13304 cooperating group of hosts) can rapidly send many SYNs to host 2, 13305 host 2 will need to store state information for many pending SYN- 13306 ACKs and may run out of space. This can prevent host 2 from 13307 responding to legitimate connection requests from other hosts or 13308 even, if there are flaws in host 2's TCP implementation, crash 13309 when the available space is exhausted. 13311 $ synchronization 13312 (I) Any technique by which a receiving (decrypting) cryptographic 13313 process attains an internal state that matches the transmitting 13314 (encrypting) process, i.e., has the appropriate keying material to 13315 process the cipher text and is correctly initialized to do so. 13317 $ system 13318 Usage: In this Glossary, the term is mainly used as an 13319 abbreviation of "information system". (See: subsystem.) 13321 $ system architecture 13322 (N) The structure of system components, their relationships, and 13323 the principles and guidelines governing their design and evolution 13324 over time. [DoDAF1] (Compare: security architecture.) 13326 $ system component 13327 1. (I) A collection of system resources that (a) forms a physical 13328 or logical part of the system, (b) has specified functions and 13329 interfaces, and (c) is treated (e.g., by policies or 13330 specifications) as existing independently of other parts of the 13331 system. (See: subsystem.) 13332 2. (O) /ITSEC/ An identifiable and self-contained part of a TOE. 13334 Usage: Component is a relative term because components may be 13335 nested; i.e., one component of system may be a part of another 13336 component of that system. 13338 Tutorial: Components can be characterized as follows: 13339 - A "physical component" has mass and takes up space. 13340 - A "logical component" is an abstraction used to manage and 13341 coordinate aspects of the physical environment, and typically 13342 represents a set of states or capabilities of the system. 13344 $ system entity 13345 (I) An active component of a system -- e.g., an automated process 13346 or set of processes (see: subsystem), or a person or set of 13347 persons (e.g., an organization) -- that incorporates a specific 13348 set of capabilities. (Compare: subject, user.) 13350 $ system high 13351 (I) The highest security level at which a system operates, or is 13352 capable of operating, at a particular time or in a particular 13353 environment. (See: system-high security mode.) 13355 $ system-high security mode 13356 (I) A mode of system operation wherein all users having access to 13357 the system possess all necessary authorizations (both security 13358 clearance and formal access approval) for all data handled by the 13359 system, but some users might not have need-to-know for all the 13360 data. (See: /system operation/ under "mode", formal access 13361 approval, protection level, security clearance.) 13363 Usage: Usually abbreviated as "system-high mode". This mode was 13364 defined in U.S. DoD policy that applied to system accreditation, 13365 but the term is widely used outside the Government. 13367 $ system integrity 13368 (I) "The quality that a system has when it can perform its 13369 intended function in a unimpaired manner, free from deliberate or 13370 inadvertent unauthorized manipulation." [NCS04] (See: recovery, 13371 system integrity service.) 13373 $ system integrity service 13374 (I) A security service that protects system resources in a 13375 verifiable manner against unauthorized or accidental change, loss, 13376 or destruction. (See: system integrity.) 13378 $ system low 13379 (I) The lowest security level supported by a system at a 13380 particular time or in a particular environment. (Compare: system 13381 high.) 13383 $ system resource 13384 (I) Data contained in an information system; or a service provided 13385 by a system; or a system capacity, such as processing power or 13386 communication bandwidth; or an item of system equipment (i.e., 13387 hardware, firmware, software, or documentation); or a facility 13388 that houses system operations and equipment. (See: system 13389 component.) 13391 $ system security officer (SSO) 13392 (I) A person responsible for enforcement or administration of the 13393 security policy that applies to a system. 13395 $ TACACS 13396 (I) See: Terminal Access Controller (TAC) Access Control System. 13398 $ TACACS+ 13399 (I) A TCP-based protocol that improves on TACACS and XTACACS by 13400 separating the functions of authentication, authorization, and 13401 accounting and by encrypting all traffic between the network 13402 access server and authentication server. TACACS+ is extensible to 13403 allow any authentication mechanism to be used with TACACS+ 13404 clients. (See: TACACS, XTACACS.) 13406 $ tamper 13407 (I) Make an unauthorized modification in a system that alters the 13408 system's functioning in a way that degrades the security services 13409 that the system was intended to provide. (See: QUADRANT. Compare: 13410 secondary definitions under "corruption" and "misuse".) 13412 $ tamper-evident 13413 (I) A characteristic of a system component that provides evidence 13414 that an attack has been attempted on that component or system. 13416 Usage: Usually involves physical evidence. (See: tamper.) 13418 $ tamper-resistant 13419 (I) A characteristic of a system component that provides passive 13420 protection against an attack. (See: tamper.) 13422 Usage: Usually involves physical means of protection. 13424 $ target of evaluation (TOE) 13425 (N) /Common Criteria/ An information technology product or system 13426 that is the subject of a security evaluation, together with the 13427 product's associated administrator and user documentation. 13428 (Compare: protection profile.) 13430 Tutorial: The security characteristics of the target of evaluation 13431 (TOE) are described in specific terms by a corresponding security 13432 target, or in more general terms by a protection profile. In 13433 Common Criteria philosophy, it is important that a TOE be 13434 evaluated against the specific set of criteria expressed in the 13435 target. This evaluation consists of rigorous analysis and testing 13436 performed by an accredited, independent laboratory. The scope of a 13437 TOE evaluation is set by the EAL and other requirements specified 13438 in the target. Part of this process is an evaluation of the target 13439 itself, to ensure that it is correct, complete, and internally 13440 consistent and can be used as the baseline for the TOE evaluation. 13442 $ TCB 13443 (N) See: trusted computing base. 13445 $ TCC field 13446 (I) See: Transmission Control Code field. 13448 $ TCP 13449 (I) See: Transmission Control Protocol. 13451 $ TCP/IP 13452 (I) Synonym for "Internet Protocol Suite". 13454 $ TCSEC 13455 (N) See: Trusted Computer System Evaluation Criteria. (Compare: 13456 TSEC.) 13458 $ TDEA 13459 (I) See: Triple Data Encryption Algorithm. 13461 $ teardrop attack 13462 (D) /slang/ An denial-of-service attack that sends improperly 13463 formed IP packet fragments with the intent of causing the 13464 destination system to fail. 13466 Deprecated Term: ISDs that use this term SHOULD state a definition 13467 for it because the term is often used imprecisely and could easily 13468 be misunderstood. (See: Deprecated Usage under "Green Book".) 13470 $ technical non-repudiation 13471 (I) See: (secondary definition under) non-repudiation. 13473 $ technical security 13474 (I) Security mechanisms and procedures that are implemented in and 13475 executed by computer hardware, firmware, or software to provide 13476 automated protection for a system. (See: security architecture. 13477 Compare: administrative security.) 13479 $ Telecommunications Security Word System (TSEC) 13480 (O) /U.S. Government/ A terminology for designating 13481 telecommunication security equipment. (Compare: TCSEC.) 13483 Tutorial: A TSEC designator has the following parts: 13484 - Prefix "TSEC/" for items and systems, or suffix "/TSEC" for 13485 assemblies. (Often omitted when the context is clear.) 13486 - First letter, for function: "C" COMSEC equipment system, "G" 13487 general purpose, "K" cryptographic, "H" crypto-ancillary, "M" 13488 manufacturing, "N" noncryptographic, "S" special purpose. 13489 - Second letter, for type or purpose: "G" key generation, "I" 13490 data transmission, "L" literal conversion, "N" signal 13491 conversion, "O" multipurpose, "P" materials production, "S" 13492 special purpose, "T" testing or checking, "U" television, "W" 13493 teletypewriter, "X" facsimile, "Y" speech. 13494 - Optional third letter, used only in designations of assemblies, 13495 for type or purpose: "A" advancing, "B" base or cabinet, "C" 13496 combining, "D" drawer or panel, "E" strip or chassis, "F" frame 13497 or rack, "G" key generator, "H" keyboard, "I" translator or 13498 reader, "J" speech processing, "K" keying or permuting, "L" 13499 repeater, "M" memory or storage, "O" observation, "P" power 13500 supply or converter, "R" receiver, "S" synchronizing, "T" 13501 transmitter, "U" printer, "V" removable COMSEC component, "W" 13502 logic programmer/programming, "X" special purpose. 13503 - Model number, usually two or 3 digits, assigned sequentially 13504 within each letter combination (e.g., KG-34, KG-84). 13505 - Optional suffix letter, used to designate a version. First 13506 version has no letter, next version has "A" (e.g., KG-84, KG- 13507 84A), etc. 13509 $ TELNET 13510 (I) A TCP-based, Application-Layer, Internet Standard protocol 13511 (RFC 854) for remote login from one host to another. 13513 $ TEMPEST 13514 (N) Short name for technology and methods for protecting against 13515 data compromise due to electromagnetic emanations from electrical 13516 and electronic equipment. [Russ] (See: inspectable space, soft 13517 TEMPEST, TEMPEST zone. Compare: QUADRANT) 13519 (O) /U.S. Government/ "Short name referring to investigation, 13520 study, and control of compromising emanations from IS equipment." 13521 [N4009] 13523 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 13524 "electromagnetic emanations security"; instead, use EMSEC. Also, 13525 the term is NOT an acronym for Transient Electromagnetic Pulse 13526 Surveillance Technology. 13528 Tutorial: The U.S. Federal Government issues security policies 13529 that (a) state specifications and standards for techniques to 13530 reduce the strength of emanations from systems and reduce the 13531 ability of unauthorized parties to receive and make use of 13532 emanations and (b) state rules for applying those techniques. 13533 Other nations presumably do the same. 13535 $ TEMPEST zone 13536 (O) "Designated area [i.e., a physical volume] within a facility 13537 where equipment that has appropriate TEMPEST characteristics ... 13538 may be operated." [C4009] (See: emanation security, TEMPEST. 13540 Compare: inspectable space.) 13542 Tutorial: The strength of an electromagnetic signal decreases in 13543 proportion to the square of the distance between the source and 13544 the receiver. Therefore, EMSEC for electromagnetic signals can be 13545 achieved by a combination of (a) reducing the strength of 13546 emanations to a defined level and (b) establishing around that 13547 equipment an appropriately sized physical buffer zone from which 13548 unauthorized entities are excluded. By making the zone large 13549 enough, it is possible to limit the signal strength available to 13550 entities outside the zone to a level lower than can be received 13551 and read with known, state-of-the-art methods. Typically, the need 13552 for and size of a TEMPEST zone established by a security policy 13553 depends not only on the measured level of signal emitted by 13554 equipment, but also on the perceived threat level in the 13555 equipment's environment. 13557 $ Terminal Access Controller (TAC) Access Control System (TACACS) 13558 (I) A UDP-based authentication and access control protocol [R1492] 13559 in which a network access server receives an identifier and 13560 password from a remote terminal and passes them to a separate 13561 authentication server for verification. (See: TACACS+, XTACACS.) 13563 Tutorial: TACACS can provide service not only for network access 13564 servers but also routers and other networked computing devices via 13565 one or more centralized authentication servers. TACACS was 13566 originally developed for ARPANET and has evolved for use in 13567 commercial equipment. 13569 $ TESS 13570 (I) See: The Exponential Encryption System. 13572 $ The Exponential Encryption System (TESS) 13573 (I) A system of separate but cooperating cryptographic mechanisms 13574 and functions for the secure authenticated exchange of 13575 cryptographic keys, the generation of digital signatures, and the 13576 distribution of public keys. TESS uses asymmetric cryptography, 13577 based on discrete exponentiation, and a structure of self- 13578 certified public keys. [R1824] 13580 $ threat 13581 1a. (I) A potential for violation of security, which exists when 13582 there is an entity, circumstance, capability, action, or event 13583 that could cause harm. (See: dangling threat, INFOCON level, 13584 threat action, threat agent, threat consequence. Compare: attack, 13585 vulnerability.) 13587 1b. (N) Any circumstance or event with the potential to adversely 13588 affect a system through unauthorized access, destruction, 13589 disclosure, or modification of data, or denial of service. [C4009] 13590 (See: sensitive information.) 13591 Usage: (a) Frequently misused with the meaning of either "threat 13592 action" or "vulnerability". (b) In some contexts, "threat" is used 13593 more narrowly to refer only to intelligent threats; for example, 13594 see definition 2 below. (c) In some contexts, "threat" is used 13595 more broadly to cover both definition 1 and other concepts, such 13596 as in definition 3 below. 13598 Tutorial: A threat is a possible danger that might exploit a 13599 vulnerability. Thus, a threat may be intentional or not: 13600 - "Intentional threat": A possibility of an attack by an 13601 intelligent entity (e.g., an individual cracker or a criminal 13602 organization). 13603 - "Accidental threat": A possibility of human error or omission, 13604 unintended equipment malfunction, or natural disaster (e.g., 13605 fire, flood, earthquake, windstorm, and other causes listed in 13606 [FP031]). 13608 The Common Criteria characterizes a threat in terms of (a) a 13609 threat agent, (b) a presumed method of attack, (c) any 13610 vulnerabilities that are the foundation for the attack, and (d) 13611 the system resource that is attacked. That characterization agrees 13612 with the definitions in this Glossary (see: diagram under 13613 "attack"). 13615 2. (O) The technical and operational ability of a hostile entity 13616 to detect, exploit, or subvert a friendly system and the 13617 demonstrated, presumed, or inferred intent of that entity to 13618 conduct such activity. 13620 Tutorial: To be likely to launch an attack, an adversary must have 13621 (a) a motive to attack, (b) a method or technical ability to make 13622 the attack, and (c) an opportunity to appropriately access the 13623 targeted system. 13625 3. (O) "An indication of an impending undesirable event." [Park] 13627 Tutorial: Definition 3 was intended to include these meanings: 13628 - "Potential threat": A possible security violation; i.e., the 13629 same as definition 1. 13630 - "Active threat": An expression of intent to violate security. 13631 (Context usually distinguishes this meaning from the previous 13632 one.) 13633 - "Accomplished threat" or "actualized threat": That is, a threat 13634 action. Deprecated Usage: ISDs SHOULD NOT use the term "threat" 13635 with this meaning; instead, use "threat action". 13637 $ threat action 13638 (I) A realization of a threat, i.e., an occurrence in which system 13639 security is assaulted as the result of either an accidental event 13640 or an intentional act. (See: attack, threat, threat consequence.) 13642 Tutorial: A complete security architecture deals with both 13643 intentional acts (i.e. attacks) and accidental events [FIPS31]. 13644 (See: various kinds of threat actions defined under the four kinds 13645 of "threat consequence".) 13647 $ threat agent 13648 (I) A system entity that performs a threat action, or an event 13649 that results in a threat action. 13651 $ threat analysis 13652 (I) An analysis of the threat actions that might affect a system, 13653 primarily emphasizing their probability of occurrence but also 13654 considering their resulting threat consequences. (Compare: risk 13655 analysis.) 13657 $ threat consequence 13658 (I) A security violation that results from a threat action. 13660 Tutorial: The four basic types of threat consequence are 13661 "unauthorized disclosure", "deception", "disruption", and 13662 "usurpation". (See main Glossary entries of each of these four 13663 terms for lists of the types of threat actions that can result in 13664 these consequences.) 13666 $ thumbprint 13667 1. (I) A pattern of curves formed by the ridges on the tip of a 13668 thumb. (See: biometric authentication, fingerprint.) 13670 2. (D) Synonym for some type of "hash result". (See: biometric 13671 authentication. Compare: fingerprint.) 13673 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 13674 "hash result" because that meaning mixes concepts in a potentially 13675 misleading way. 13677 $ ticket 13678 (I) Synonym for "capability token". 13680 Tutorial: A ticket is usually granted by a centralized access 13681 control server (ticket-granting agent) to authorize access to a 13682 system resource for a limited time. Tickets can be implemented 13683 with either symmetric cryptography (see: Kerberos) or asymmetric 13684 cryptography (see: attribute certificate). 13686 $ tiger team 13687 (I) A group of evaluators employed by a system's managers to 13688 perform penetration tests on the system. 13690 Deprecated Term: It is likely that other cultures use different 13691 metaphors for this concept. Therefore, to avoid international 13692 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 13693 Usage under "Green Book".) 13695 $ time stamp 13696 (I) /noun/ With respect to a data object, a label or marking in 13697 which is recorded the time (time of day or other instant of 13698 elapsed time) at which the label or marking was affixed to the 13699 data object. (See: Time-Stamp Protocol.) 13701 (O) /noun/ "With respect to a recorded network event, a data field 13702 in which is recorded the time (time of day or other instant of 13703 elapsed time) at which the event took place." [A1523] 13705 Tutorial: A time stamp can be used as evidence to prove that a 13706 data object existed (or that an event occurred) at or before a 13707 particular time. For example, a time stamp might be used to prove 13708 that a digital signature based on a private key was created while 13709 the corresponding public-key certificate was valid, i.e., before 13710 the certificate either expired or was revoked. Establishing this 13711 proof would enable the certificate to be used after its expiration 13712 or revocation, to verify a signature that was created earlier. 13713 This kind of proof is required as part of implementing PKI 13714 services such as non-repudiation service and long-term security 13715 services such as audit. 13717 $ Time-Stamp Protocol 13718 (I) An Internet protocol (RFC 3161) that specifies how a client 13719 requests and receives a time stamp from a server for a data object 13720 held by the client. 13722 Tutorial: The protocol describes the format of (a) a request sent 13723 to a time stamping authority and (b) the response that is returned 13724 containing a time stamp. The authority creates the stamp by 13725 concatenating (a) a hash value of the input data object with (b) a 13726 UTC time value and other parameters (policy OID, serial number, 13727 indication of time accuracy, nonce, DN of the authority, and 13728 various extensions), and then signing that dataset with the 13729 authority's private key as specified in CMS. Such an authority 13730 typically would operate as a trusted third-party service, but 13731 other operational models might be used. 13733 $ timing channel 13734 (I) See: covert timing channel. 13736 $ TLS 13737 (I) See: Transport Layer Security. 13739 $ TLSP 13740 (N) See: Transport Layer Security Protocol. 13742 $ TOE 13743 (N) See: target of evaluation 13745 $ token 13746 1. (I) /cryptography/ See: cryptographic token. (Compare: dongle.) 13747 2. (I) /access control/ An object that is used to control access 13748 and is passed between cooperating entities in a protocol that 13749 synchronizes use of a shared resource. Usually, the entity that 13750 currently holds the token has exclusive access to the resource. 13751 (See: capability token.) 13753 Usage: This term is heavily overloaded in the computing 13754 literature; therefore, ISDs SHOULD NOT use this term with any 13755 definition other than 1 or 2. 13757 3a. (D) /authentication/ A data object or a physical device used 13758 to verify an identity in an authentication process. 13760 3b. (D) /U.S. Government/ Something that the claimant in an 13761 authentication process (i.e., the entity that claims an identity) 13762 possesses and controls, and uses to prove the claim during the 13763 verification step of the process. [SP63] 13765 Usage: Deprecated usage: ISDs SHOULD NOT use this term with 13766 definitions 3a and 3b; instead, use more specifically descriptive 13767 and informative terms such as "authentication information" or 13768 "cryptographic token", depending on what is meant. 13770 NIST defines four types of claimant tokens for electronic 13771 authentication in an information system [SP63]. ISDs SHOULD NOT 13772 use these four NIST terms; they mix concepts in potentially 13773 confusing ways and duplicate the meaning of better-established 13774 terms. These four terms can be avoided by using more specifically 13775 descriptive terms as follows: 13776 - NIST "hard token": A hardware device that contains a protected 13777 cryptographic key. (This is a type of "cryptographic token", 13778 and the key is a type of "authentication information".) 13779 - NIST "one-time password device token": A personal hardware 13780 device that generates one-time passwords. (One-time passwords 13781 are typically generated cryptographically. Therefore, this is a 13782 type of "cryptographic token", and the key is a type of 13783 "authentication information".) 13784 - NIST "soft token": A cryptographic key that typically is stored 13785 on disk or some other magnetic media. (The key is a type of 13786 "authentication information"; "authentication key" would be a 13787 better description.) 13788 - NIST "password token": A secret data value that the claimant 13789 memorizes. (This is a "password" that is being used as 13790 "authentication information".) 13792 $ token backup 13793 (I) A token management operation that stores sufficient 13794 information in a database (e.g., in a CAW) to recreate or restore 13795 a security token (e.g., a smart card) if it is lost or damaged. 13797 $ token copy 13798 (I) A token management operation that copies all the personality 13799 information from one security token to another. However, unlike in 13800 a token restore operation, the second token is initialized with 13801 its own, different local security values such as PINs and storage 13802 keys. 13804 $ token management 13805 (I) The process that includes initializing security tokens (e.g., 13806 see: smart card), loading data into the tokens, and controlling 13807 the tokens during their life cycle. May include performing key 13808 management and certificate management functions; generating and 13809 installing PINs; loading user personality data; performing card 13810 backup, card copy, and card restore operations; and updating 13811 firmware. 13813 $ token restore 13814 (I) A token management operation that loads a security token with 13815 data for the purpose of recreating (duplicating) the contents 13816 previously held by that or another token. (See: recovery.) 13818 $ token storage key 13819 (I) A cryptographic key used to protect data that is stored on a 13820 security token. 13822 $ top CA 13823 (I) A synonym for "root" in a certification hierarchy. (See: apex 13824 trust anchor.) 13826 $ top-level specification 13827 (I) "A non-procedural description of system behavior at the most 13828 abstract level; typically a functional specification that omits 13829 all implementation details." [NCS04] (See: Tutorial under 13830 "security policy".) 13832 Tutorial: A top-level specification is at a level of abstraction 13833 below "security model" and above "security architecture" (see: 13834 Tutorial under "security policy"). 13836 A top-level specification may be descriptive or formal: 13837 - "Descriptive top-level specification": One that is written in a 13838 natural language like English or an informal design notation. 13839 - "Formal top-level specification": One that is written in a 13840 formal mathematical language to enable theorems to be proven 13841 that show that the specification correctly implements a set of 13842 formal requirements or a formal security model. (See: 13843 correctness proof.) 13845 $ traceback 13846 (I) Identification of the source of a data packet. (See: 13847 masquerade, network weaving.) 13849 $ tracker 13850 (N) An attack technique for achieving unauthorized disclosure from 13851 a statistical database. [Denns] (See: Tutorial under "inference 13852 control".) 13854 $ traffic analysis 13855 1. (I) Gaining knowledge of information by inference from 13856 observable characteristics of a data flow, even if the information 13857 is not directly available (e.g., when the data is encrypted). 13858 These characteristics include the identities and locations of the 13859 source(s) and destination(s) of the flow, and the flow's presence, 13860 amount, frequency, and duration of occurrence. The object of the 13861 analysis might be information in SDUs, information in the PCI, or 13862 both. (See: inference, traffic-flow confidentiality, wiretapping. 13863 Compare: signal analysis.) 13865 2. (O) "The inference of information from observation of traffic 13866 flows (presence, absence, amount, direction, and frequency)." 13867 [I7498 Part 2] 13869 $ traffic-flow analysis 13870 (I) Synonym for "traffic analysis". 13872 $ traffic-flow confidentiality (TFC) 13873 1. (I) A data confidentiality service to protect against traffic 13874 analysis. (See: communications cover.) 13876 2. (O) "A confidentiality service to protect against traffic 13877 analysis." [I7498 Part 2] 13879 Tutorial: Confidentiality concerns involve both direct and 13880 indirect disclosure of data, and the latter includes traffic 13881 analysis. However, operational considerations can make TFC 13882 difficult to achieve. For example, if Alice sends a product idea 13883 to Bob in an email message, she wants data confidentiality for the 13884 message's content, and she might also want to conceal the 13885 destination of the message in order to hide Bob's identity from 13886 her competitors. However, the identity of the intended recipient, 13887 or at least a network address for that recipient, needs to be made 13888 available to the mail system. Thus, complex forwarding schemes may 13889 be needed to conceal the ultimate destination as the message 13890 travels through the open Internet (see: onion routing). 13892 Later, if Alice uses an ATM during a clandestine visit to 13893 negotiate with Bob, she might prefer that her bank conceal the 13894 origin of her transaction, because knowledge of the ATM's location 13895 might allow a competitor to infer Bob's identity. The bank, on the 13896 other hand, might prefer to protect only Alice's PIN (see: 13897 selective-field confidentiality). 13899 A TFC service can be either full or partial: 13900 - "Full TFC": This type of service conceals all traffic 13901 characteristics. 13902 - "Partial TFC": This type of service either (a) conceals some 13903 but not all of the characteristics or (b) does not completely 13904 conceal some characteristic. 13906 On point-to-point data links, full TFC can be provided by 13907 enciphering all PDUs and also generating a continuous, random data 13908 stream to seamlessly fill all gaps between PDUs. To a wiretapper, 13909 the link then appears to be carrying an unbroken stream of 13910 enciphered data. In other cases -- including on a shared or 13911 broadcast medium, or end-to-end in a network -- only partial TFC 13912 is possible, and that may require a combination of techniques. For 13913 example, a LAN that uses "carrier sense multiple access with 13914 collision detection" (CSMA/CD; a.k.a. "listen while talk") to 13915 control access to the medium, relies on detecting intervals of 13916 silence, which prevents using full TFC. Partial TFC can be 13917 provided on that LAN by measures such as adding spurious PDUs, 13918 padding PDUs to a constant size, or enciphering addresses just 13919 above the Physical Layer; but these measures reduce the efficiency 13920 with which the LAN can carry traffic. At higher protocol layers, 13921 SDUs can be protected, but addresses and other items of PCI must 13922 be visible at the layers below. 13924 $ traffic key 13925 (I) A cryptographic key used by a device for protecting 13926 information that is being transmitted between devices, as opposed 13927 to protecting information that being is maintained in the device. 13928 (Compare: storage key.) 13930 $ traffic padding 13931 (I) "The generation of spurious instances of communication, 13932 spurious data units, and/or spurious data within data units." 13933 [I7498 Part 2] 13935 $ tranquillity property 13936 (N) /formal model/ Property of a system whereby the security level 13937 of an object cannot change while the object is being processed by 13938 the system. (See: Bell-LaPadula model.) 13940 $ transaction 13941 1. (I) A unit of interaction between an external entity and a 13942 system, or between components within a system, that involves a 13943 series of system actions or events. 13945 2. (O) "A discrete event between user and systems that supports a 13946 business or programmatic purpose." [M0404] 13948 Tutorial: To maintain secure state, transactions need to be 13949 processed coherently and reliably. Usually, they need to be 13950 designed to be atomic, consistent, isolated, and durable [Gray]: 13951 - "Atomic": All actions and events that comprise the transaction 13952 are guaranteed to be completed successfully, or else the result 13953 is as if none at all were executed. 13954 - "Consistent": The transaction satisfies correctness constraints 13955 defined for the data that is being processed. 13956 - "Isolated": If two transactions are performed concurrently, 13957 they do not interfere with each other, and it appears as though 13958 the system performs one at a time. 13959 - "Durable": System state and transaction semantics survive 13960 system failures. 13962 $ TRANSEC 13963 (I) See: transmission security. 13965 $ Transmission Control Code field (TCC field) 13966 (I) A data field that provides a means to segregate traffic and 13967 define controlled communities of interest in the security option 13968 (option type = 130) of IPv4's datagram header format. The TCC 13969 values are alphanumeric trigraphs assigned by the U.S. Government 13970 as specified in RFC 791. 13972 $ Transmission Control Protocol (TCP) 13973 (I) An Internet Standard, Transport-Layer protocol (RFC 793) that 13974 reliably delivers a sequence of datagrams from one computer to 13975 another in a computer network. (See: TCP/IP.) 13977 Tutorial: TCP is designed to fit into a layered suite of protocols 13978 that support internetwork applications. TCP assumes it can obtain 13979 a simple but potentially unreliable end-to-end datagram service 13980 (such as IP) from the lower layer protocols. 13982 $ transmission security (TRANSEC) 13983 (I) Measures that protect communications from interception and 13984 exploitation by means other than cryptanalysis. Usually understood 13985 to be a part of COMSEC. (Compare: traffic flow confidentiality.) 13987 $ Transport Layer 13988 See: Internet Protocol Suite, OSIRM. 13990 $ Transport Layer Security (TLS) 13991 (I) TLS Version 1.0 is an Internet protocol [R2246] that is based 13992 on, and very similar to, SSL Version 3.0. (Compare: TLSP.) 13994 Deprecated Usage: The TLS protocol is misnamed. The name 13995 misleadingly suggests that TLS is situated in the IPS Transport 13996 Layer, but TLS is always layered above a reliable Transport-Layer 13997 protocol (usually TCP) and either layered immediately below or 13998 integrated with an Application-Layer protocol (often HTTP). 14000 $ Transport Layer Security Protocol (TLSP) 14001 (N) An end-to-end encryption protocol (ISO 10736) that provides 14002 security services at the bottom of OSIRM Layer 4, i.e., directly 14003 above Layer 3. (Compare: TLS.) 14004 Tutorial: TLSP evolved directly from SP4. 14006 $ transport mode 14007 (I) One of two ways to apply AH or ESP to protect data packets; in 14008 this mode, the IPsec protocol encapsulates (i.e., the protection 14009 applies to) the packets of an IPS Transport-Layer protocol (e.g., 14010 TCP, UDP), which is normally carried directly above IP in an IPS 14011 protocol stack. (Compare: tunnel mode.) 14013 Tutorial: An IPsec transport-mode security association is always 14014 between two hosts; neither end has the role of a security gateway. 14015 Whenever either end of an IPsec security association is a security 14016 gateway, the association is required to be in tunnel mode. 14018 $ transposition 14019 (I) /cryptography/ A method of encryption in which elements of the 14020 plain text retain their original form but undergo some change in 14021 their relative position. (Compare: substitution.) 14023 $ trap door 14024 (I) Synonym for "back door". 14026 $ Triple Data Encryption Algorithm 14027 (I) An block cipher that transforms each 64-bit plaintext block by 14028 applying the DEA three successive times, using either two or three 14029 different keys for an effective key length of 112 or 168 bits. 14030 [A9052, SP67] 14032 Example: A variation proposed for IPsec's ESP uses a 168-bit key, 14033 consisting of three independent 56-bit values used by the DEA, and 14034 a 64-bit initialization vector. Each datagram contains an IV to 14035 ensure that each received datagram can be decrypted even when 14036 other datagrams are dropped or a sequence of datagrams is 14037 reordered in transit. [R1851] 14039 $ triple-wrapped 14040 (I) /S-MIME/ Data that has been signed with a digital signature, 14041 then encrypted, and then signed again. [R2634] 14043 $ Trojan horse 14044 (I) A computer program that appears to have a useful function, but 14045 also has a hidden and potentially malicious function that evades 14046 security mechanisms, sometimes by exploiting legitimate 14047 authorizations of a system entity that invokes the program. (See: 14048 malware, spyware. Compare: logic bomb, virus, worm.) 14050 $ trust 14051 1. (I) /information system/ A feeling of certainty (sometimes 14052 based on inconclusive evidence) either (a) that the system will 14053 not fail or (b) that the system meets its specifications (i.e., 14054 the system does what it claims to do and does not perform unwanted 14055 functions). (See: trust level, trusted system, trustworthy system. 14057 Compare: assurance.) 14059 2. (I) /PKI/ A relationship between a certificate user and a CA in 14060 which the user acts according to the assumption that the CA 14061 creates only valid digital certificates. 14063 Tutorial: "Generally, an entity is said to 'trust' a second entity 14064 when the first entity makes the assumption that the second entity 14065 will behave exactly as the first entity expects. This trust may 14066 apply only for some specific function. The key role of trust in 14067 [X.509] is to describe the relationship between an entity [i.e., a 14068 certificate user] and a [CA]; an entity shall be certain that it 14069 can trust the CA to create only valid and reliable certificates." 14070 [X509] 14072 Components of a system can be grouped into three classes of trust 14073 [Gass]: 14074 - "Trusted": The component is responsible for enforcing security 14075 policy on other components; the system's security depends on 14076 flawless operation of the component. (See: trusted process.) 14077 - "Benign": The component is not responsible for enforcing 14078 security policy, but it has sensitive authorizations. It must 14079 be trusted not to intentionally violate security policy, but 14080 security violations are assumed to be accidental and not likely 14081 to affect overall system security. 14082 - "Untrusted": The component is of unknown or suspicious 14083 provenance and must be treated as deliberately malicious. (See: 14084 malicious logic.) 14086 $ trust anchor 14087 (I) /PKI/ An established point of trust (usually based on the 14088 authority of some person, office, or organization) from which a 14089 certificate user begins the validation of a certification path. 14090 (See: path validation, trust anchor CA, trust anchor certificate, 14091 trust anchor key.) 14093 Usage: ISDs that use this term SHOULD state a definition for it 14094 because it is used in various ways in existing ISDs and other PKI 14095 literature. The literature almost always uses this term in a sense 14096 that is equivalent to this definition, but usage often differs 14097 with regard to what constitutes the point of trust. 14099 Tutorial: A trust anchor may be defined as being based on a public 14100 key, a CA, a public-key certificate, or some combination or 14101 variation of those: 14103 - A public key as a point of trust: Although a certification path 14104 is defined as beginning with a "sequence of public-key 14105 certificates", an implementation of a path validation process 14106 might not explicitly handle a root certificate as part of the 14107 path, but instead begin the process by using a trusted root key 14108 to verify the signature on a certificate that was issued by the 14109 root. 14111 Therefore, "trust anchor" is sometimes defined as just a public 14112 key. (See: root key, trust anchor key, trusted key.) 14114 - A CA as a point of trust: A trusted public key is just one of 14115 the data elements needed for path validation; the IPS path 14116 validation algorithm [R3280] also needs the name of the CA to 14117 which that key belongs, i.e., the DN of the issuer of the first 14118 X.509 certificate to be validated on the path. (See: issue.) 14120 Therefore, "trust anchor" is sometimes defined as either just a 14121 CA (where some public key is implied) or as a CA together with 14122 a specified public key belonging to that CA. (See: root, trust 14123 anchor CA, trusted CA.) 14125 Example: "A public key and the name of a [CA] that is used to 14126 validate the first certificate in a sequence of certificates. 14127 The trust anchor public key is used to verify the signature on 14128 a certificate issued by a trust anchor [CA]." [SP57] 14130 - A public-key certificate as a point of trust: In addition to 14131 the trusted CA's public key and name, the path validation 14132 algorithm needs to know the digital signature algorithm and any 14133 associated parameters with which the public key is used, and 14134 also any constraints that have been placed on the set of paths 14135 that may be validated using the key. All of this information is 14136 available from a CA's public-key certificate. 14138 Therefore, "trust anchor" is sometimes defined as a public-key 14139 certificate of a CA. (See: root certificate, trust anchor 14140 certificate, trusted certificate.) 14142 - Combinations: Combinations and variations of the first three 14143 definitions are also used in the PKI literature. 14145 Example: "trust anchor information". The IPS standard for path 14146 validation [R3280] specifies the information that describes "a 14147 CA that serves as a trust anchor for the certification path. 14148 The trust anchor information includes: (1) the trusted issuer 14149 name, (2) the trusted public key algorithm, (3) the trusted 14150 public key, and (4) optionally, the trusted public key 14151 parameters associated with the public key. The trust anchor 14152 information may be provided to the path processing procedure in 14153 the form of a self-signed certificate. The trusted anchor 14154 information is trusted because it was delivered to the path 14155 processing procedure by some trustworthy out-of-band procedure. 14156 If the trusted public key algorithm requires parameters, then 14157 the parameters are provided along with the trusted public key." 14159 $ trust anchor CA 14160 (I) A CA that is the subject of a trust anchor certificate or 14161 otherwise establishes a trust anchor key. (See: root, trusted CA.) 14163 Tutorial; The selection of a CA to be a trust anchor is a matter 14164 of policy. Some of the possible choices include (a) the top CA in 14165 a hierarchical PKI, (b) the CA that issued the verifier's own 14166 certificate, or (c) any other CA in a network PKI. Different 14167 applications may rely on different trust anchors, or may accept 14168 paths that begin with any of a set of trust anchors. The IPS path 14169 validation algorithm is the same regardless of the choice. 14171 $ trust anchor certificate 14172 (I) A public-key certificate that is used to provide the first 14173 public key in a certification path. (See: root certificate, trust 14174 anchor, trusted certificate.) 14176 $ trust anchor key 14177 (I) A public key that is used as the first public key in a 14178 certification path. (See: root key, trust anchor, trusted public 14179 key.) 14181 $ trust anchor information 14182 (I) See: secondary definition under "trust anchor". 14184 $ trust chain 14185 (D) Synonym for "certification path". (See: trust anchor, trusted 14186 certificate.) 14188 Deprecated Term: ISDs SHOULD NOT use this term, because it 14189 unnecessarily duplicates the meaning of the internationally 14190 standardized term. 14192 Also, the term mixes concepts in a potentially misleading way. 14193 Having "trust" involves factors unrelated to simply verifying 14194 signatures and performing other tests as specified by a standard 14195 algorithm for path validation (e.g., RFC 3280). Thus, even if a 14196 user is able to validate a certification path algorithmically, the 14197 user still might distrust one of the CAs that issued certificates 14198 in that path or distrust some other aspects of the PKI. 14200 $ trust-file PKI 14201 (I) A non-hierarchical PKI in which each certificate user has a 14202 local file (which is used by application software) of public-key 14203 certificates that the user trusts as starting points (i.e., trust 14204 anchors) for certification paths. (Compare: hierarchical PKI, mesh 14205 PKI, trusted certificate, web of trust.) 14207 Example: Popular browsers are distributed with an initial file of 14208 trust anchor certificates, which often are self-signed 14209 certificates. Users can add certificates to the file or delete 14210 from it. The file may be directly managed by the user, or the 14211 user's organization may manage it from a centralized server. 14213 $ trust hierarchy 14214 (D) Synonym for "certification hierarchy". 14216 Deprecated Usage: ISDs SHOULD NOT use this term because it mixes 14217 concepts in a potentially misleading way. (See: trust, trust 14218 chain, web of trust.) 14220 $ trust level 14221 (N) A characterization of a standard of security protection to be 14222 met by an information system. (See: Common Criteria, TCSEC.) 14224 Tutorial: A trust level is based not only on (a) the presence of 14225 security mechanisms, but also on the use of (b) systems 14226 engineering discipline to properly structure the system and (c) 14227 implementation analysis to ensure that the system provides an 14228 appropriate degree of trust. 14230 $ trusted CA 14231 (I) A CA upon which a certificate user relies as issuing valid 14232 certificates; especially a CA that is used as a trust anchor CA. 14233 (See: certification path, root, trust anchor CA, validation.) 14235 Tutorial. This trust is transitive to the extent that the X.509 14236 certificate extensions permit; that is, if a trusted CA issues a 14237 certificate to another CA, a user that trusts the first CA also 14238 trusts the second CA if the user succeeds in validating the 14239 certificate path (see: path validation). 14241 $ trusted certificate 14242 1. (I) A digital certificate that a certificate user accepts as 14243 being valid "a priori", i.e., without testing the certificate to 14244 validate it as the final certificate on a certification path; 14245 especially a certificate that is used as a trust anchor 14246 certificate. (See: certification path, root certificate, trust 14247 anchor certificate, trust-file PKI, validation.) 14249 Tutorial: The acceptance of a certificate as trusted is a matter 14250 of policy and choice. Usually, a certificate is accepted as 14251 trusted because the user obtained it by reliable, out-of-band 14252 means that cause the user to believe the certificate accurately 14253 binds its subject's name to the subject's public key or other 14254 attribute values. Many choices are possible; e.g., a trusted 14255 public-key certificate might be (a) the root certificate in a 14256 hierarchical PKI, (b) the certificate of the CA that issued the 14257 user's own certificate in a mesh PKI, or (c) a certificate 14258 provided with an application that uses a trust-file PKI. 14260 $ Trusted Computer System Evaluation Criteria (TCSEC) 14261 (N) A standard for evaluating the security provided by operating 14262 systems [CSC001, DoD1]. Known as the "Orange Book" because of the 14263 color of its cover; first document in the Rainbow Series. (See: 14264 Common Criteria, Deprecated Usage under "Green Book", Orange Book, 14265 trust level, trusted computer system. Compare: TSEC.) 14267 Tutorial: The TCSEC defines classes of hierarchically ordered 14268 assurance levels for rating computer systems. From highest to 14269 lowest, the classes are as follows: 14270 - Division A: Verified protection. 14271 Beyond A1 Beyond current technology. (See: beyond A1.) 14272 Class A1 Verified design. (See: SCOMP.) 14273 - Division B: Mandatory protection. 14274 Class B3 Security domains. 14275 Class B2 Structured protection. (See: Multics.) 14276 Class B1 Labeled security protection. 14277 - Division C: Discretionary protection. 14278 Class C2 Controlled access protection. 14279 Class C1 Discretionary security protection. 14280 - Division D: Minimal protection, i.e., has been evaluated but 14281 does not meet the requirements for a higher evaluation class. 14283 $ trusted computing base (TCB) 14284 (N) "The totality of protection mechanisms within a computer 14285 system, including hardware, firmware, and software, the 14286 combination of which is responsible for enforcing a security 14287 policy." [NCS04] (See: "trusted" under "trust".) 14289 $ trusted distribution 14290 (I) /computer security/ "A trusted method for distributing the TCB 14291 hardware, software, and firmware components, both originals and 14292 updates, that provides methods for protecting the TCB from 14293 modification during distribution and for detection of any changes 14294 to the TCB that may occur." [NCS04] (See: code signing, 14295 configuration control.) 14297 $ trusted key 14298 (D) Abbreviation for "trusted public key" and also for other types 14299 of keys. (See: root key, trust anchor key.) 14301 Deprecated Usage: ISDs SHOULD either (a) state a definition for 14302 this term or (b) use a different, less ambiguous term. This term 14303 is ambiguous when it stands alone; e.g., it could refer to a 14304 trusted public key or to a private key or symmetric key that is 14305 believed to be secure (i.e., not compromised). 14307 $ trusted path 14308 1a. (I) /COMPUSEC/ A mechanism by which a computer system user can 14309 communicate directly and reliably with the TCB and that can only 14310 be activated by the user or the TCB and cannot be imitated by 14311 untrusted software within the computer. [NCS04] 14313 1b. (I) /COMSEC/ A mechanism by which a person or process can 14314 communicate directly with a cryptographic module and that can only 14315 be activated by the person, process, or module, and cannot be 14316 imitated by untrusted software within the module. [FP140] 14318 $ trusted process 14319 1. (I) A system component that has privileges that enable it to 14320 affect the state of system security and that can, therefore, 14321 through incorrect or malicious execution, violate the system's 14322 security policy. (See: privileged process, trusted system.) 14324 $ trusted public key 14325 (I) A public key upon which a user relies; especially a public key 14326 that is used as a trust anchor key. (See: certification path, root 14327 key, trust anchor key, validation.) 14329 Tutorial: A trusted public key could be (a) the root key in a 14330 hierarchical PKI, (b) the key of the CA that issued the user's own 14331 certificate in a mesh PKI, or (c) any key accepted by the user in 14332 a trust-file PKI. 14334 $ trusted recovery 14335 (I) A process that, after a system has experienced a failure or an 14336 attack, restores the system to normal operation (or to a secure 14337 state) without causing a security compromise. (See: recovery.) 14339 $ trusted subnetwork 14340 (I) A subnetwork containing hosts and routers that trust each 14341 other not to engage in active or passive attacks. (There also is 14342 an assumption that the underlying communication channels -- e.g., 14343 telephone lines, or a LAN -- are protected from attack.) 14345 $ trusted system 14346 1. (I) /information system/ A system that operates as expected, 14347 according to design and policy, doing what is required -- despite 14348 environmental disruption, human user and operator errors, and 14349 attacks by hostile parties -- and not doing other things [NRC98]. 14350 (See: trust level, trusted process. Compare: trustworthy.) 14352 2. (N) /multilevel secure/ "A [trusted computer system is a] 14353 system that employs sufficient hardware and software assurance 14354 measures to allow its use for simultaneous processing of a range 14355 of sensitive or classified information." [NCS04] (See: multilevel 14356 security mode.) 14358 $ Trusted Systems Interoperability Group (TSIG) 14359 (N) A forum of computer vendors, system integrators, and users 14360 devoted to promoting interoperability of trusted computer systems. 14362 $ trustworthy system 14363 1. (I) A system that not only is trusted, but also for which the 14364 trust can be guaranteed in some convincing way, such as through 14365 formal analysis or code review. (See: trust. Compare: trusted.) 14367 2. (O) /Digital Signature Guidelines/ "Computer hardware, 14368 software, and procedures that: (a) are reasonably secure from 14369 intrusion and misuse; (b) provide a reasonably reliable level of 14370 availability, reliability, and correct operation; (c) are 14371 reasonably suited to performing their intended functions; and (d) 14372 adhere to generally accepted security principles." [ABA] 14374 $ TSEC 14375 (O) See: Telecommunications Security Nomenclature System. 14376 (Compare: TCSEC.) 14378 $ TSIG 14379 (N) See: Trusted System Interoperability Group. 14381 $ tunnel 14382 1. (I) A communication channel created in a computer network by 14383 encapsulating (i.e., layering) a communication protocol's data 14384 packets in (i.e., above) a second protocol that normally would be 14385 carried above, or at the same layer as, the first one. (See: L2TP, 14386 VPN.) (Compare: covert channel.) 14388 Tutorial: Tunneling can involve almost any two IPS protocol 14389 layers. For example, a TCP connection between two hosts could 14390 conceivably be carried above SMTP (i.e., in SMTP messages) as a 14391 covert channel to evade access controls that a security gateway 14392 applies to the normal TCP layer that is below SMTP. 14394 Usually, however, a tunnel is a logical point-to-point link -- 14395 i.e., an OSIRM Layer 2 connection -- created by encapsulating the 14396 Layer 2 protocol in one of the following three types of IPS 14397 protocols: (a) an IPS Transport-Layer protocol (such as TCP), (b) 14398 an IPS Network-Layer or Internet-Layer protocol (such as IP), or 14399 (c) another Layer 2 protocol. In many cases, the encapsulation is 14400 accomplished with an extra, intermediate protocol (i.e., a 14401 "tunneling protocol"; e.g., L2TP) that is layered below the 14402 tunneled Layer 2 protocol and above the encapsulating protocol. 14404 Tunneling can be used to move data between computers that use a 14405 protocol not supported by the network connecting them. Tunneling 14406 also can enable a computer network to use the services of a second 14407 network as though the second network were a set of point-to-point 14408 links between the first network's nodes. (See: virtual private 14409 network.) 14411 2. (O) /SET/ The name of a SET private extension that indicates 14412 whether the CA or the payment gateway supports passing encrypted 14413 messages to the cardholder through the merchant. If so, the 14414 extension lists OIDs of symmetric encryption algorithms that are 14415 supported. 14417 $ tunnel mode 14418 (I) One of two ways to apply the IPsec protocols (AH and ESP) to 14419 protect data packets; in this mode, the IPsec protocol 14420 encapsulates (i.e., the protection applies to) IP packets, rather 14421 than the packets of higher layer protocols. (Compare: transport 14422 mode.) 14424 Tutorial: Each end of a tunnel-mode security association may be 14425 either a host or a security gateway. Whenever either end of an 14426 IPsec security association is a security gateway, the association 14427 is required to be in tunnel mode. 14429 $ two-person control 14430 (I) The close surveillance and control of a system, a process, or 14431 materials (especially with regard to cryptography) at all times by 14432 a minimum of two appropriately authorized persons, each capable of 14433 detecting incorrect and unauthorized procedures with respect to 14434 the tasks to be performed and each familiar with established 14435 security requirements. (See: dual control, no-lone zone.) 14437 $ Twofish 14438 (O) A symmetric, 128-bit block cipher with variable key length 14439 (128, 192, or 256 bits), developed by Counterpane Labs as a 14440 candidate for the AES. (See: Blowfish.) 14442 $ type 0 product 14443 (O) /cryptography, U.S. Government/ Classified cryptographic 14444 equipment endorsed by NSA specifically for use (when appropriately 14445 keyed) in electronically distributing bulk keying material. 14447 $ type 1 product 14448 (O) /cryptography, U.S. Government/ "Classified or controlled 14449 cryptographic item endorsed by the NSA for securing classified and 14450 sensitive U.S. Government information, when appropriately keyed. 14451 The term refers only to products, and not to information, key, 14452 services, or controls. Type 1 products contain classified NSA 14453 algorithms. They are available to U.S. Government users, their 14454 contractors, and federally sponsored non-U.S. Government 14455 activities subject to export restrictions in accordance with 14456 International Traffic in Arms Regulation." [C4009] (See: ITAR.) 14458 $ type 2 product 14459 (O) /cryptography, U.S. Government/ "Unclassified cryptographic 14460 equipment, assembly, or component, endorsed by the NSA, for use in 14461 national security systems as defined in Title 40 U.S.C. Section 14462 1452." [C4009] (See: national security system. Compare: EUCI.) 14464 $ type 3 algorithm 14465 (O) /cryptography, U.S. Government/ "Cryptographic algorithm 14466 registered by [NIST] and published as a [FIPS] for use in 14467 protecting unclassified sensitive information or commercial 14468 information." [C4009] 14470 $ type 4 algorithm 14471 (O) /cryptography, U.S. Government/ "Unclassified cryptographic 14472 algorithm that has been registered by [NIST] but not published as 14473 a [FIPS]." [C4009] 14475 $ UDP 14476 (I) See: User Datagram Protocol. 14478 $ UDP flood 14479 (I) A denial-of-service attack that takes advantage of (a) one 14480 system's UDP test function that generates a series of characters 14481 for each packet it receives and (b) another system's UPD test 14482 function that echoes any character it receives; the attack 14483 connects (a) to (b) to cause a nonstop flood of data between the 14484 two systems. 14486 $ unauthorized disclosure 14487 (I) A circumstance or event whereby an entity gains access to 14488 information for which the entity is not authorized. 14490 Tutorial: This type of threat consequence can be caused by the 14491 following types of threat actions: exposure, interception, 14492 inference, intrusion. Some methods of protecting against this 14493 consequence include access control, flow control, and inference 14494 control. (See: data confidentiality.) 14496 $ unauthorized user 14497 (I) /access control/ A system entity that accesses a system 14498 resource for which the entity has not received an authorization. 14499 (See: user. Compare: authorized user, insider, outsider.) 14501 Usage: ISDs that use this term SHOULD state a definition for it 14502 because the term is used in many ways and could easily be 14503 misunderstood. 14505 $ uncertainty 14506 (N) An information-theoretic measure (usually stated as a number 14507 of bits) of the minimum amount of plaintext information that needs 14508 to be recovered from cipher text in order to learn the entire 14509 plain text that was encrypted. [SP63] (See: entropy.) 14511 $ unclassified 14512 (I) Not classified. 14514 $ unencrypted 14515 (I) Not encrypted. 14517 $ unforgeable 14518 (I) /cryptography/ The property of a cryptographic data structure 14519 (i.e., a data structure that is defined using one or more 14520 cryptographic functions, e.g., see digital certificate) that makes 14521 it computationally infeasible to construct (i.e., compute) an 14522 unauthorized but correct value of the structure without having 14523 knowledge of one of more keys. 14525 Tutorial: This definition is narrower than general English usage, 14526 where "unforgeable" means unable to be fraudulently created or 14527 duplicated. In that broader sense, anyone can forge a digital 14528 certificate containing any set of data items whatsoever by 14529 generating the to-be-signed certificate and signing it with any 14530 private key whatsoever. But for PKI purposes, the forged data 14531 structure is invalid if it is not signed with the true private key 14532 of the claimed issuer; thus, the forgery will be detected when a 14533 certificate user uses the true public key of the claimed issuer to 14534 verify the signature. 14536 $ uniform resource identifier (URI) 14537 (I) A type of formatted identifier (RFC 1630) that encapsulates 14538 the name of an Internet object, and labels it with an 14539 identification of the name space, thus producing a member of the 14540 universal set of names in registered name spaces and of addresses 14541 referring to registered protocols or name spaces. 14543 Tutorial: URIs are used in HTML to identify the target of 14544 hyperlinks. In common practice, URIs include URLs and relative 14545 URLs (RFC 1808). 14547 $ uniform resource locator (URL) 14548 (I) A type of formatted identifier (RFC 1738) that describes the 14549 access method and location of an information resource object on 14550 the Internet. 14552 Tutorial: A URL is a URI that provides explicit instructions on 14553 how to access the named object. For example, 14554 "ftp://bbnarchive.bbn.com/foo/bar/picture/cambridge.zip" is a URL. 14555 The part before the colon specifies the access scheme or protocol, 14556 and the part after the colon is interpreted according to that 14557 access method. Usually, two slashes after the colon indicate the 14558 host name of a server (written as a domain name). In an FTP or 14559 HTTP URL, the host name is followed by the path name of a file on 14560 the server. The last (optional) part of a URL may be either a 14561 fragment identifier that indicates a position in the file, or a 14562 query string. 14564 $ uniform resource name (URN) 14565 (I) A URI that has an institutional commitment to persistence and 14566 availability. 14568 $ untrusted process 14569 1. (I) A system component that is not able to affect the state of 14570 system security through incorrect or malicious operation. Example: 14571 A component that has its operations confined by a security kernel. 14572 (See: trusted process.) 14574 2. (I) A system component that (a) has not been evaluated or 14575 examined for adherence to a specified security policy and, 14576 therefore, (b) must be assumed to contain logic that might attempt 14577 to circumvent system security. 14579 $ UORA 14580 (O) See: user-PIN ORA. 14582 $ update 14583 See: "certificate update" and "key update". 14585 $ upgrade 14586 (I) /data security/ Increase the classification level of data 14587 without changing the information content of the data. (See: 14588 classify, downgrade, regrade.) 14590 $ URI 14591 (I) See: uniform resource identifier. 14593 $ URL 14594 (I) See: uniform resource locator. 14596 $ URN 14597 (I) See: uniform resource name. 14599 $ user 14600 (I) An active system entity that uses a product or service 14601 provided by the system, or that accesses system resources to 14602 produce a product or service of the system. (See: access, [R2504]. 14603 Compare: authorized user, manager, operator, principal, privileged 14604 user, subject, subscriber, unauthorized user.) 14606 Usage: ISDs that use this term SHOULD state a definition for it 14607 because the term is used in many ways and could easily be 14608 misunderstood: 14609 - This term usually refers to an entity that has been authorized 14610 to access the system, but the term sometimes is used without 14611 regard for whether access is authorized. 14612 - This term usually refers to a living human being acting either 14613 personally or in an organizational role, but the term also may 14614 refer to an automated process in the form of hardware, 14615 softwarr, or firmware; to a set of persons; or to a set of 14616 processes. 14617 - ISDs SHOULD exclude the case of a mixed set containing both 14618 persons and processes. The exclusion is intended to prevent 14619 situations that might require a security policy to be 14620 interpreted in two different and conflicting ways. 14622 A user can be characterized as direct or indirect: 14623 - "Passive user": A system entity that is (a) outside the 14624 system's security perimeter *and* (b) can receive output from 14625 the system but cannot provide input or otherwise interact with 14626 the system. 14627 - "Active user": A system entity that is (a) inside the system's 14628 security perimeter *or* (b) can provide input or otherwise 14629 interact with the system. 14631 $ user authentication service 14632 (I) A security service that verifies the identity claimed by an 14633 entity that attempts to access the system. (See: authentication, 14634 user.) 14636 $ User Datagram Protocol (UDP) 14637 (I) An Internet Standard, Transport-Layer protocol (RFC 768) that 14638 delivers a sequence of datagrams from one computer to another in a 14639 computer network. (See: UPD flood.) 14641 Tutorial: UDP assumes that IP is the underlying protocol. UDP 14642 enables application programs to send transaction-oriented data to 14643 other programs with minimal protocol mechanism. UDP does not 14644 provide reliable delivery, flow control, sequencing, or other end- 14645 to-end service guarantees that TCP does. 14647 $ user identity 14648 (I) See: identity. 14650 $ user identifier 14651 (I) See: identifier. 14653 $ user PIN 14654 (O) /MISSI/ One of two PINs that control access to the functions 14655 and stored data of a FORTEZZA PC card. Knowledge of the user PIN 14656 enables the card user to perform the FORTEZZA functions that are 14657 intended for use by an end user. (Compare: SSO PIN.) 14659 $ user-PIN ORA (UORA) 14660 (O) /MISSI/ A MISSI organizational RA that operates in a mode in 14661 which the ORA performs only the subset of card management 14662 functions that are possible with knowledge of the user PIN for a 14663 FORTEZZA PC card. (See: no-PIN ORA, SSO-PIN ORA.) 14665 $ usurpation 14666 (I) A circumstance or event that results in control of system 14667 services or functions by an unauthorized entity. This type of 14668 threat consequence can be caused by the following types of threat 14669 actions: misappropriation, misuse. (See: access control.) 14671 $ UTCTime 14672 (N) The ASN.1 data type "UTCTime" contains a calendar date 14673 (YYMMDD) and a time to a precision of either one minute (HHMM) or 14674 one second (HHMMSS), where the time is either (a) Coordinated 14675 Universal Time or (b) the local time followed by an offset that 14676 enables Coordinated Universal Time to be calculated. Note: UTCTime 14677 has the Year 2000 problem. (See: Coordinated Universal Time, 14678 GeneralizedTime.) 14680 $ v1 certificate 14681 (N) An abbreviation that ambiguously refers to either an "X.509 14682 public-key certificate in version 1 format" or an "X.509 attribute 14683 certificate in version 1 format". 14685 Deprecated Usage: ISDs MAY use this term as an abbreviation of 14686 "version 1 X.509 public-key certificate", but only after using the 14687 full term at the first instance. Otherwise, the term is ambiguous, 14688 because X.509 specifies both v1 public-key certificates and v1 14689 attribute certificates. (See: X.509 attribute certificate, X.509 14690 public-key certificate.) 14692 $ v1 CRL 14693 (N) Abbreviation of "X.509 CRL in version 1 format". 14695 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 14696 term at its first occurrence and define the abbreviation there. 14698 $ v2 certificate 14699 (N) Abbreviation of "X.509 public-key certificate in version 2 14700 format". 14702 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 14703 term at its first occurrence and define the abbreviation there. 14705 $ v2 CRL 14706 (N) Abbreviation of "X.509 CRL in version 2 format". 14708 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 14709 term at its first occurrence and define the abbreviation there. 14711 $ v3 certificate 14712 (N) Abbreviation of "X.509 public-key certificate in version 3 14713 format". 14715 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 14716 term at its first occurrence and define the abbreviation there. 14718 $ valid certificate 14719 1. (I) A digital certificate that can be validated successfully. 14720 (See: validate, verify.) 14722 2. (I) A digital certificate for which the binding of the data 14723 items can be trusted. 14725 $ valid signature 14726 (D) Synonym for "authentic signature". 14728 Deprecated Term: ISDs SHOULD NOT use this term; instead, say 14729 "authentic signature". This Glossary recommends saying "validate 14730 the certificate" and "verify the signature"; therefore, it would 14731 be inconsistent to say that a signature is "valid". (See: 14733 validate, verify.) 14735 $ validate 14736 1. (I) Establish the soundness or correctness of a construct. 14737 Example: certificate validation. (See: validate vs. verify.) 14739 2. (I) To officially approve something, sometimes in relation to a 14740 standard. Example: NIST validates cryptographic modules for 14741 conformance with FIPS PUB 140 [FP140]. 14743 $ validate vs. verify 14744 Usage: To ensure consistency and align with ordinary English 14745 usage, ISDs SHOULD comply with the following two rules: 14746 - Rule 1: Use "validate" when referring to a process intended to 14747 establish the soundness or correctness of a construct (e.g., 14748 see: certificate validation). (See: validate.) 14749 - Rule 2: Use "verify" when referring to a process intended to 14750 test or prove the truth or accuracy of a fact or value (e.g., 14751 see: authenticate). (See: verify.) 14753 Tutorial: The Internet security community sometimes uses these two 14754 terms inconsistently, especially in a PKI context. Most often, 14755 however, we say "verify the signature" but say "validate the 14756 certificate". That is, we "verify" atomic truths but "validate" 14757 data structures, relationships, and systems that are composed of 14758 or depend on verified items. This usage has a basis in Latin: 14760 The word "valid" derives from a Latin word that means "strong". 14761 Thus, to validate means to check that a construct is sound. For 14762 example, a certificate user validates a public-key certificate to 14763 establish trust in the binding that the certificate asserts 14764 between an identity and a key. This can include checking various 14765 aspects of the certificate's construction, such as verifying the 14766 digital signature on the certificate by performing calculations, 14767 verifying that the current time is within the certificate's 14768 validity period, and validating a certification path involving 14769 additional certificates. 14771 The word "verify" derives from a Latin word that means "true". 14772 Thus, to verify means to check the truth of an assertion by 14773 examining evidence or performing tests. For example, to verify an 14774 identity, an authentication process examines identification 14775 information that is presented or generated. To validate a 14776 certificate, a certificate user verifies the digital signature on 14777 the certificate by performing calculations, verifies that the 14778 current time is within the certificate's validity period, and may 14779 need to validate a certification path involving additional 14780 certificates. 14782 $ validation 14783 (I) See: validate vs. verify. 14785 $ validity period 14786 (I) /PKI/ A data item in a digital certificate that specifies the 14787 time period for which the binding between data items (especially 14788 between the subject name and the public key value in a public-key 14789 certificate) is valid, except if the certificate appears on a CRL 14790 or the key appears on a CKL. (See: cryptoperiod, key lifetime.) 14792 $ value-added network (VAN) 14793 (I) A computer network or subnetwork (usually a commercial 14794 enterprise) that transmits, receives, and stores EDI transactions 14795 on behalf of its users. 14797 Tutorial: A VAN may also provide additional services, ranging from 14798 EDI format translation, to EDI-to-FAX conversion, to integrated 14799 business systems. 14801 $ VAN 14802 (I) See: value-added network. 14804 $ verification 14805 1. (I) /authentication/ Presenting information to establish the 14806 truth of a claimed identity. (See: validate vs. verify.) 14808 2. (N) /computer security/ The process of comparing two levels of 14809 system specification for proper correspondence, such as comparing 14810 a security model with a top-level specification, a top-level 14811 specification with source code, or source code with object code. 14812 [NCS04] 14814 $ verified design 14815 (O) See: TCSEC Class A1. 14817 $ verify 14818 (I) To test or prove the truth or accuracy of a fact or value. For 14819 example, see "authenticate". (See: validate vs. verify.) 14821 $ vet 14822 (I) /verb/ To examine or evaluate thoroughly. (Compare: 14823 authenticate, identity proofing, validate, verify.) 14825 $ violation 14826 See: security violation. 14828 $ virtual private network (VPN) 14829 (I) A restricted-use, logical (i.e., artificial or simulated) 14830 computer network that is constructed from the system resources of 14831 a relatively public, physical (i.e., real) network (e.g., the 14832 Internet), often by using encryption (located at hosts or 14833 gateways), and often by tunneling links of the virtual network 14834 across the real network. 14836 Tutorial: A VPN is generally less expensive to build and operate 14837 than a dedicated real network, because the virtual network shares 14838 the cost of system resources with other users of the underlying 14839 real network. For example, if a corporation has LANs at several 14840 different sites, each connected to the Internet by a firewall, the 14841 corporation could create a VPN by (a) using encrypted tunnels to 14842 connect from firewall to firewall across the Internet and (b) not 14843 allowing any other traffic through the firewalls. 14845 $ virus 14846 (I) A self-replicating (and usually hidden) section of computer 14847 software (usually malicious logic) that propagates by infecting -- 14848 i.e., inserting a copy of itself into and becoming part of -- 14849 another program. A virus cannot run by itself; it requires that 14850 its host program be run to make the virus active. 14852 $ VisaCash 14853 (O) A smartcard-based electronic money system that incorporates 14854 cryptography and can be used to make payments via the Internet. 14855 (See: IOTP.) 14857 $ volatile media 14858 (I) Storage media that require an external power supply to 14859 maintain stored information. (Compare: non-volatile media, 14860 permanent storage.) 14862 $ VPN 14863 (I) See: virtual private network. 14865 $ vulnerability 14866 (I) A flaw or weakness in a system's design, implementation, or 14867 operation and management that could be exploited to violate the 14868 system's security policy. (See: harden.) 14870 Tutorial: A system can have three types of vulnerabilities: (a) 14871 vulnerabilities in design or specification; (b) vulnerabilities in 14872 implementation; and (c) vulnerabilities in operation and 14873 management. Most systems have one or more vulnerabilities, but 14874 this does not mean that the systems are too flawed to use. Not 14875 every threat results in an attack, and not every attack succeeds. 14876 Success depends on the degree of vulnerability, the strength of 14877 attacks, and the effectiveness of any countermeasures in use. If 14878 the attacks needed to exploit a vulnerability are very difficult 14879 to carry out, then the vulnerability may be tolerable. If the 14880 perceived benefit to an attacker is small, then even an easily 14881 exploited vulnerability may be tolerable. However, if the attacks 14882 are well understood and easily made, and if the vulnerable system 14883 is employed by a wide range of users, then it is likely that there 14884 will be enough motivation for someone to launch an attack. 14886 $ W3 14887 (D) Synonym for WWW. 14889 Deprecated Abbreviation: This abbreviation could be confused with 14890 W3C; use "WWW" instead. 14892 $ W3C 14893 (N) See: World Wide Web Consortium. 14895 $ war dialer 14896 (I) /slang/ A computer program that automatically dials a series 14897 of telephone numbers to find lines connected to computer systems, 14898 and catalogs those numbers so that a cracker can try to break the 14899 systems. 14901 Deprecated Usage: ISDs that use this term SHOULD state a 14902 definition for it because the term could confuse international 14903 readers. 14905 $ Wassenaar Arrangement 14906 (N) The Wassenaar Arrangement on Export Controls for Conventional 14907 Arms and Dual-Use Goods and Technologies is a global, multilateral 14908 agreement approved by 33 countries in July 1996 to contribute to 14909 regional and international security and stability, by promoting 14910 information exchange concerning, and greater responsibility in, 14911 transfers of arms and dual-use items, thus preventing 14912 destabilizing accumulations. (See: International Traffic in Arms 14913 Regulations.) 14915 Tutorial: The Arrangement began operations in September 1996 with 14916 headquarters in Vienna. The participating countries were 14917 Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech 14918 Republic, Denmark, Finland, France, Germany, Greece, Hungary, 14919 Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, 14920 Norway, Poland, Portugal, Republic of Korea, Romania, Russian 14921 Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, 14922 Ukraine, United Kingdom, and United States. 14924 Participating countries seek through their national policies to 14925 ensure that transfers do not contribute to the development or 14926 enhancement of military capabilities that undermine the goals of 14927 the arrangement, and are not diverted to support such 14928 capabilities. The countries maintain effective export controls for 14929 items on the agreed lists, which are reviewed periodically to 14930 account for technological developments and experience gained. 14931 Through transparency and exchange of views and information, 14932 suppliers of arms and dual-use items can develop common 14933 understandings of the risks associated with their transfer and 14934 assess the scope for coordinating national control policies to 14935 combat these risks. Members provide semi-annual notification of 14936 arms transfers, covering seven categories derived from the UN 14937 Register of Conventional Arms. Members also report transfers or 14938 denials of transfers of certain controlled dual-use items. 14939 However, the decision to transfer or deny transfer of any item is 14940 the sole responsibility of each participating country. All 14941 measures undertaken with respect to the arrangement are in 14942 accordance with national legislation and policies and are 14943 implemented on the basis of national discretion. 14945 $ watermarking 14946 See: digital watermarking. 14948 $ weak key 14949 (I) In the context of a particular cryptographic algorithm, a key 14950 value that provides poor security. 14952 Example: The DEA has four "weak keys" [Schn] for which encryption 14953 produces the same result as decryption. It also has ten pairs of 14954 "semi-weak keys" [Schn] (a.k.a. "dual keys" [FP074]) for which 14955 encryption with one key in the pair produces the same result as 14956 decryption with the other key. 14958 $ web, Web 14959 1. (I) /not capitalized/ ISDs SHOULD NOT capitalize "web" when 14960 using the term (usually as an adjective) to refer generically to 14961 technology -- such as web browsers, web servers, HTTP, and HTML -- 14962 that is used in the Web or similar networks. 14964 2. (I) /capitalized/ ISDs SHOULD capitalize "Web" when using the 14965 term (as either a noun or an adjective) to refer specifically to 14966 the World Wide Web. (Similarly, see: internet.) 14968 Usage: ISDs SHOULD NOT use "web" or "Web" in a way that might 14969 confuse these definitions with the PGP "web of trust". When using 14970 Web as an abbreviation for "World Wide Web", ISDs SHOULD fully 14971 spell out the term at the first instance of usage. 14973 $ web of trust 14974 (D) /PGP/ A trust-file PKI technique used for building a file of 14975 trusted public keys by making personal judgments about being able 14976 to trust certain people to be holding properly certified keys of 14977 other people. (See: certification hierarchy, mesh PKI, trust 14978 anchor, web, Web.) 14980 Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts 14981 in a potentially misleading way. This PKI technique does not 14982 depend on World Wide Web technology. 14984 $ web server 14985 (I) A software process that runs on a host computer connected to a 14986 network and responds to HTTP requests made by client web browsers. 14988 $ WEP 14989 (N) See: Wired Equivalency Protocol. 14991 $ Wired Equivalent Privacy (WEP) 14992 (N) A cryptographic protocol that is defined in the IEEE 802.11 14993 standard and encapsulates the packets on wireless LANs. Usage: 14994 a.k.a. "Wired Equivalency Protocol". 14996 Tutorial: The WEP design, which uses RC4 to encrypt both the plain 14997 text and a CRC, has been shown to be flawed in multiple ways; and 14998 it also has often suffered from flawed implementation and 14999 management. 15001 $ wiretapping 15002 (I) An attack that intercepts and accesses information contained 15003 in a data flow in a communication system. (See: active 15004 wiretapping, end-to-end encryption, passive wiretapping.) 15006 Usage: Although the term originally referred to making a 15007 mechanical connection to an electrical conductor that links two 15008 nodes, it is now used to refer to accessing information from any 15009 sort of medium used for a link or even from a node, such as a 15010 gateway or subnetwork switch. 15012 Tutorial: Wiretapping can be characterized according to intent: 15013 - "Active wiretapping" attempts to alter the data or otherwise 15014 affect the flow. 15015 - "Passive wiretapping" only attempts to observe the data flow 15016 and gain knowledge of information contained in it. 15018 $ work factor 15019 1. (I) /COMPUSEC/ The estimated amount of effort or time that can 15020 be expected to be expended by a potential intruder to penetrate a 15021 system, or defeat a particular countermeasure, when using 15022 specified amounts of expertise and resources. (See: strength.) 15024 2. (I) /cryptography/ The estimated amount of computing power and 15025 time needed to break a cryptographic system. 15027 $ World Wide Web ("the Web", WWW) 15028 (N) The global, hypermedia-based collection of information and 15029 services that is available on Internet servers and is accessed by 15030 browsers using Hypertext Transfer Protocol and other information 15031 retrieval mechanisms. (See: web vs. Web, [R2084].) 15033 $ World Wide Web Consortium (W3C) 15034 (N) Created in October 1994 to develop and standardize protocols 15035 to promote the evolution and interoperability of the Web, and now 15036 consisting of hundreds of member organizations (commercial firms, 15037 government agencies, schools, and others). 15039 Tutorial: W3C Recommendations are developed through a process 15040 similar to that of the standards published by other organizations, 15041 such as the IETF. The W3 Recommendation Track (i.e., standards 15042 track) has four levels of increasing maturity: Working, Candidate 15043 Recommendation, Proposed Recommendation, and W3C Recommendation 15044 W3C Recommendations are similar to the standards published by 15045 others organizations. (Compare: Internet Standard, ISO.) 15047 $ worm 15048 (I) A computer program that can run independently, can propagate a 15049 complete working version of itself onto other hosts on a network, 15050 and may consume system resources destructively. (See: mobile code, 15051 Morris Worm, virus.) 15053 $ wrap 15054 (D) To use cryptography to provide data confidentiality service 15055 for keying material. (See: encrypt. Compare: seal.) 15057 Deprecated Term: ISDs SHOULD NOT use this term as defined here; 15058 the definition duplicates the meaning of other, standard terms. 15059 Instead, use "encrypt" or another term that is specific with 15060 regard to the mechanism being used. 15062 $ write 15063 (I) /COMPUSEC/ A fundamental operation in an information system 15064 that results in a flow of information only from a subject to an 15065 object. (See: access mode.) 15067 $ WWW 15068 (I) See: World Wide Web. 15070 $ X.400 15071 (N) An ITU-T Recommendation [X400] that is one part of a joint 15072 ITU-T/ISO multi-part standard (X.400-X.421) that defines the 15073 Message Handling Systems. (The ISO equivalent is IS 10021, parts 15074 1-7.) (See: Message Handling Systems.) 15076 $ X.500 15077 (N) An ITU-T Recommendation [X500] that is one part of a joint 15078 ITU-T/ISO multi-part standard (X.500-X.525) that defines the X.500 15079 Directory, a conceptual collection of systems that provide 15080 distributed directory capabilities for OSI entities, processes, 15081 applications, and services. (The ISO equivalent is IS 9594-1 and 15082 related standards, IS 9594-x.) (See: directory vs. Directory, 15083 X.509.) 15085 Tutorial: The X.500 Directory is structured as a tree (the 15086 Directory Information Tree), and information is stored in 15087 directory entries. Each entry is a collection of information about 15088 one object, and each object has a DN. A directory entry is 15089 composed of attributes, each with a type and one or more values. 15090 For example, if a PKI uses the Directory to distribute 15091 certificates, then the X.509 public-key certificate of an end user 15092 is normally stored as a value of an attribute of type 15093 "userCertificate" in the Directory entry that has the DN that is 15094 the subject of the certificate. 15096 $ X.509 15097 (N) An ITU-T Recommendation [X509] that defines a framework to 15098 provide and support data origin authentication and peer entity 15099 authentication, including formats for X.509 public-key 15100 certificates, X.509 attribute certificates, and X.509 CRLs. (The 15101 ISO equivalent is IS 9498-4.) (See: X.500.) 15103 Tutorial: X.509 describes two "levels" of authentication: "simple 15104 authentication" and "strong authentication". It recommends, "While 15105 simple authentication offers some limited protection against 15106 unauthorized access, only strong authentication should be used as 15107 the basis for providing secure services." 15109 $ X.509 attribute certificate 15110 (N) An attribute certificate in the version 1 (v1) format defined 15111 by X.509. (The v1 designation for an X.509 attribute certificate 15112 is disjoint from the v1 designation for an X.509 public-key 15113 certificate, and from the v1 designation for an X.509 CRL.) 15115 Tutorial: An X.509 attribute certificate has a "subject" field, 15116 but the attribute certificate is a separate data structure from 15117 that subject's public-key certificate. A subject may have multiple 15118 attribute certificates associated with each of its public-key 15119 certificates, and an attribute certificate may be issued by a 15120 different CA than the one that issued the associated public-key 15121 certificate. 15123 An X.509 attribute certificate contains a sequence of data items 15124 and has a digital signature that is computed from that sequence. 15125 In addition to the signature, an attribute certificate contains 15126 items 1 through 9 listed below: 15128 1. version Identifies v1. 15129 2. subject Is one of the following: 15130 2a. baseCertificateID Issuer and serial number of an 15131 X.509 public-key certificate. 15132 2b. subjectName DN of the subject. 15133 3. issuer DN of the issuer (the CA who signed). 15134 4. signature OID of algorithm that signed the cert. 15135 5. serialNumber Certificate serial number; 15136 an integer assigned by the issuer. 15137 6. attCertValidityPeriod Validity period; a pair of UTCTime 15138 values: "not before" and "not after". 15139 7. attributes Sequence of attributes describing the 15140 subject. 15141 8. issuerUniqueId Optional, when a DN is not sufficient. 15142 9. extensions Optional. 15144 $ X.509 certificate 15145 (N) Synonym for "X.509 public-key certificate". 15147 Usage: ISDs MAY use this term as an abbreviation of "X.509 public- 15148 key certificate", but only after using the full term at the first 15149 instance. Otherwise, the term is ambiguous, because X.509 15150 specifies both public-key certificates and attribute certificates. 15151 (See: X.509 attribute certificate, X.509 public-key certificate.) 15153 Deprecated Usage: ISDs SHOULD NOT use this term as an abbreviation 15154 of "X.509 attribute certificate", because the term is much more 15155 commonly used to mean "X.509 public-key certificate" and, 15156 therefore, is likely to be misunderstood. 15158 $ X.509 certificate revocation list (CRL) 15159 (N) A CRL in one of the formats defined by X.509 -- version 1 (v1) 15160 or version 2 (v2). (The v1 and v2 designations for an X.509 CRL 15161 are disjoint from the v1 and v2 designations for an X.509 public- 15162 key certificate, and from the v1 designation for an X.509 15163 attribute certificate.) (See: certificate revocation.) 15165 Usage: ISDs SHOULD NOT refer to an X.509 CRL as a digital 15166 certificate; however, note that an X.509 CRL does meet this 15167 Glossary's definition of "digital certificate". That is, like a 15168 digital certificate, an X.509 CRL makes an assertion and is signed 15169 by a CA. But instead of binding a key or other attributes to a 15170 subject, an X.509 CRL asserts that certain previously issued, 15171 X.509 certificates have been revoked. 15173 Tutorial: An X.509 CRL contains a sequence of data items and has a 15174 digital signature computed on that sequence. In addition to the 15175 signature, both v1 and v2 contain items 2 through 6b listed below. 15176 Version 2 contains item 1 and may optionally contain 6c and 7. 15178 1. version Optional. If present, identifies v2. 15179 2. signature OID of the algorithm that signed CRL. 15180 3. issuer DN of the issuer (the CA who signed). 15181 4. thisUpdate A UTCTime value. 15182 5. nextUpdate A UTCTime value. 15183 6. revokedCertificates 3-tuples of 6a, 6b, and (optional) 6c: 15184 6a. userCertificate A certificate's serial number. 15185 6b. revocationDate UTCTime value for the revocation date. 15186 6c. crlEntryExtensions Optional. 15187 7. crlExtensions Optional. 15189 $ X.509 public-key certificate 15190 (N) A public-key certificate in one of the formats defined by 15191 X.509 -- version 1 (v1), version 2 (v2), or version 3 (v3). (The 15192 v1 and v2 designations for an X.509 public-key certificate are 15193 disjoint from the v1 and v2 designations for an X.509 CRL, and 15194 from the v1 designation for an X.509 attribute certificate.) 15196 Tutorial: An X.509 public-key certificate contains a sequence of 15197 data items and has a digital signature computed on that sequence. 15198 In addition to the signature, all three versions contain items 1 15199 through 7 listed below. Only v2 and v3 certificates may also 15200 contain items 8 and 9, and only v3 may contain item 10. 15202 1. version Identifies v1, v2, or v3. 15203 2. serialNumber Certificate serial number; 15204 an integer assigned by the issuer. 15205 3. signature OID of algorithm that was used to 15206 sign the certificate. 15207 4. issuer DN of the issuer (the CA who signed). 15208 5. validity Validity period; a pair of UTCTime 15209 values: "not before" and "not after". 15210 6. subject DN of entity who owns the public key. 15211 7. subjectPublicKeyInfo Public key value and algorithm OID. 15212 8. issuerUniqueIdentifier Defined for v2, v3; optional. 15213 9. subjectUniqueIdentifier Defined for v2, v2; optional. 15214 10. extensions Defined only for v3; optional. 15216 $ X9 15217 See: "Accredited Standards Committee X9" under "ANSI". 15219 $ XML 15220 (N) See: Extensible Markup Language. 15222 $ XML-Signature. 15223 (N) A W3C Recommendation (i.e. approved standard) that specifies 15224 XML syntax and processing rules for creating and representing 15225 digital signatures (based on asymmetric cryptography) that can be 15226 applied to any digital content (i.e., any data object) including 15227 other XML material. 15229 $ XTACACS 15230 (I) Cisco Corporation's implementation of the Terminal Access 15231 Controller (TAC) Access Control System. This implementation 15232 enhances and extends the original TACACS. (See: TACACS, TACACS+.) 15234 $ Yellow Book 15235 (D) /slang/ Synonym for "Computer Security Requirements: Guidance 15236 for Applying the [U.S.] Department of Defense Trusted Computer 15237 System Evaluation Criteria in Specific Environments" [CSC3] (See: 15238 "first law" under "Courtney's laws".) 15240 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 15241 that or any other document. Instead, use the full proper name of 15242 the document or, in subsequent references, a conventional 15243 abbreviation. (See: Deprecated Usage under "Green Book", Rainbow 15244 Series.) 15246 $ zero-knowledge proof 15247 (I) /cryptography/ A proof-of-possession protocol whereby a system 15248 entity can prove possession of some information to another entity, 15249 without revealing any of that information. (See: proof-of- 15250 possession protocol.) 15252 $ zeroize 15253 1. (I) Synonym for "purge". Usage: Particularly with regard to 15254 erasing keys that are stored in a cryptographic module. 15256 2. (O) Erase electronically stored data by altering the contents 15257 of the data storage so as to prevent the recovery of the data. 15258 [FP140] 15260 $ zombie 15261 (I) /slang/ An Internet host computer that has been 15262 surreptitiously penetrated by an intruder that installed malicious 15263 daemon software to cause the host to operate as an accomplice in 15264 attacking other hosts, particularly in distributed attacks that 15265 attempt denial of service through flooding. 15267 Deprecated Term: It is likely that other cultures use different 15268 metaphors for this concept. Therefore, to avoid international 15269 misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated 15270 Usage under "Green Book".) 15272 $ zone of control 15273 (O) /EMSEC/ Synonym for "inspectable space". [C4009] (See: 15274 TEMPEST.) 15276 5. Informative References 15278 This Glossary focuses on the Internet Standards Process. Therefore, 15279 this set of references emphasizes international, governmental, and 15280 industry standards documents. RFCs referenced in Glossary entries are 15281 listed here if they are specifically security-relevant; other 15282 referenced RFCs are only mentioned by number (e.g., see "RFC 959" in 15283 the entry for "File Transport Protocol"). 15285 [A1523] American National Standards Institute, "American National 15286 Standard Telecomm Glossary", ANSI T1.523-2001. 15288 [A3092] ---, "American National Standard Data Encryption Algorithm", 15289 ANSI X3.92-1981, 30 December 1980. 15291 [A9009] ---, "Financial Institution Message Authentication 15292 (Wholesale)", ANSI X9.9-1986, 15 August 1986. 15294 [A9017] ---, "Financial Institution Key Management (Wholesale)", 15295 X9.17, 4 April 1985. (Defines procedures for manual and 15296 automated management of keying material and uses DES to 15297 provide key management for a variety of operational 15298 environments.) 15300 [A9042] ---, "Public key Cryptography for the Financial Service 15301 Industry: Agreement of Symmetric Keys Using Diffie-Hellman 15302 and MQV Algorithms", X9.42, 29 January 1999. 15304 [A9052] ---, "Triple Data Encryption Algorithm Modes of Operation", 15305 X9.52-1998, ANSI approval 9 November 1998. 15307 [A9062] ---, "Public Key Cryptography for the Financial Services 15308 Industry: The Elliptic Curve Digital Signature Algorithm 15309 (ECDSA)", X9.62-1998, ANSI approval 7 January 1999. 15311 [A9063] ---, "---: Key Agreement and Key Transport Using Elliptic 15312 Curve Cryptography", X9.63-2001. 15314 [ABA] American Bar Association, "Digital Signature Guidelines: 15315 Legal Infrastructure for Certification Authorities and 15316 Secure Electronic Commerce", Chicago, IL, 1 August 1996. 15318 [ACM] Association for Computing Machinery, "Communications of the 15319 ACM", July 1998 issue with: M. Yeung, "Digital 15320 Watermarking"; N. Memom and P. Wong, "Protecting Digital 15321 Media Content"; and S. Craver, B.-L. Yeo, and M. Yeung, 15322 "Technical Trials and Legal Tribulations". 15324 [Ande] Anderson, J., "Computer Security Technology Planning Study", 15325 ESD-TR-73-51, Vols. I and II, USAF Electronics Systems Div., 15326 Bedford, MA, October 1972. (Available as AD-758206 and - 15327 772806, National Technical Information Service, Springfield, 15328 VA.) 15330 [ANSI] American National Standards Institute, "Role Based Access 15331 Control", Secretariat, Information Technology Industry 15332 Council, BSR INCITS 359, DRAFT, 10 November 2003. 15334 [Army] U.S. Army Corps of Engineers, "Electromagnetic Pulse (EMP) 15335 and Tempest Protection for Facilities", EP 1110-3-2, 31 15336 December 1990. 15338 [B1822] Bolt Baranek and Newman Inc., "Appendix H: Interfacing a 15339 Host to a Private Line Interface", in "Specifications for 15340 the Interconnection of a Host and an IMP", BBN Report No. 15341 1822, revised, December 1983. 15343 [B4799] ---, "A History of the Arpanet: The First Decade", BBN 15344 Report No. 4799, April 1981. 15346 [BS7799] British Standards Institution, "Information Security 15347 Management, Part 1: Code of Practice for Information 15348 Security Management", BS 7799-1:1999, 15 May 1999. 15350 ---, ---, "Part 2: Specification for Information Security 15351 Management Systems", BS 7799-2:1999, 15 May 1999. 15353 [Bell] Bell, D. and L. LaPadula, "Secure Computer Systems: 15354 Mathematical Foundations and Model", M74-244, The MITRE 15355 Corporation, Bedford, MA, May 1973. (Available as AD-771543, 15356 National Technical Information Service, Springfield, VA.) 15358 [Biba] K. Biba, "Integrity Considerations for Secure Computer 15359 Systems", ESD-TR-76-372, USAF Electronic Systems Division, 15360 Bedford, MA, April 1977. 15362 [BN89] Brewer, D. and M. Nash, "The Chinese wall security policy", 15363 in "Proceedings of IEEE Symposium on Security and Privacy", 15364 May 1989, pp. 205-214. 15366 [C4009] Committee on National Security Systems (U.S. Government), 15367 "National Information Assurance (IA) Glossary", CNSS 15368 Instruction No. 4009, revised May 2003. 15370 [CCIB] Common Criteria Implementation Board, "Common Criteria for 15371 Information Technology Security Evaluation, Part 1: 15372 Introduction and General Model", version 2.0, CCIB-98-026, 15373 May 1998. 15375 [Chau] D. Chaum, "Untraceable Electronic Mail, Return Addresses, 15376 and Digital Pseudonyms", in "Communications of the ACM", 15377 vol. 24, no. 2, February 1981, pp. 84-88. 15379 [Cheh] Cheheyl, M., Gasser, M., Huff, G., and J. Millen, "Verifying 15380 Security", in "ACM Computing Surveys", vol. 13, no. 3, 15381 September 1981, pp. 279-339. 15383 [Chris] Chrissis, M. et al, 1993. "SW-CMM [Capability Maturity Model 15384 for Software Version", Release 3.0, Software Engineering 15385 Institute, Carnegie Mellon University, August 1996. 15387 [CIPSO] Trusted Systems Interoperability Working Group, "Common IP 15388 Security Option", version 2.3, 9 March 1993. 15390 [Clark] Clark, D. and D. Wilson, "A Comparison of Commercial and 15391 Military computer Security Policies", in "Proceedings of the 15392 IEEE Symposium on Security and Privacy", April 1987, pp. 15393 184-194. 15395 [Cons] NSA, "Consistency Instruction Manual for Development of U.S. 15396 Government Protection Profiles for Use in Basic Robustness 15397 Environments", Release 2.0, 1 March 2004 15399 [CSC1] U.S. DoD Computer Security Center, "Department of Defense 15400 Trusted Computer System Evaluation Criteria", CSC-STD-001- 15401 83, 15 August 1983. (Superseded by [DoD1].) 15403 [CSC2] ---, "Department of Defense Password Management Guideline", 15404 CSC-STD-002-85, 12 April 1985. 15406 [CSC3] ---, "Computer Security Requirements: Guidance for Applying 15407 the Department of Defense Trusted Computer System Evaluation 15408 Criteria in Specific Environments", CSC-STD-003-85, 25 June 15409 1985. 15411 [CSOR] U.S. Department of Commerce, "General Procedures for 15412 Registering Computer Security Objects", National Institute 15413 of Standards Interagency Report 5308, December 1993. 15415 [Daem] Daemen, J. and V. Rijmen, "Rijndael, the advanced encryption 15416 standard", in "Dr. Dobb's Journal", vol. 26, no. 3, March 15417 2001, pp.137-139. 15419 [DC6/9] Director of Central Intelligence, "Physical Security 15420 Standards for Sensitive Compartmented Information 15421 Facilities", DCI Directive 6/9, 18 November 2002. 15423 [Denn] Denning, D., "A Lattice Model of Secure Information Flow", 15424 in "Communications of the ACM", vol. 19, no. 5, May 1976, 15425 pp. 236-243. 15427 [Denns] Denning, D. and P. Denning, "Data Security", in "ACM 15428 Computing Surveys", vol. 11, no. 3, September 1979, pp. 227- 15429 249. 15431 [DH76] Diffie, W. and M. Hellman, "New Directions in Cryptography", 15432 in "IEEE Transactions on Information Theory", vol. IT-22, 15433 no. 6, November 1976, pp. 644-654. 15435 [DoD1] U.S. DoD, "Department of Defense Trusted Computer System 15436 Evaluation Criteria", DoD 5200.28-STD, 26 December 1985. 15437 (Supersedes [CSC1].) (Superseded by DoD Directive 8500.1.) 15439 [DoD3] ---, "X.509 Certificate Policy for the United States 15440 Department of Defense", version 7, 18 December 2002. 15442 [DoD4] ---, "NSA Key Recovery Assessment Criteria", 8 June 1998. 15444 [DoD5] ---, Directive 5200.1, "DoD Information Security Program", 15445 13 December 1996. 15447 [DoD6] ---, "DoD Architecture Framework", Version 1, 30 August 15448 2003. 15450 [ElGa] El Gamal, T., "A Public-Key Cryptosystem and a Signature 15451 Scheme Based on Discrete Logarithms", in "IEEE Transactions 15452 on Information Theory", vol. IT-31, no. 4, 1985, pp. 469- 15453 472. 15455 [EMV1] Europay International S.A., MasterCard International 15456 Incorporated, and Visa International Service Association, 15457 "EMV '96 Integrated Circuit Card Specification for Payment 15458 Systems", version 3.1.1, 31 May 1998. 15460 [EMV2] ---, "EMV '96 Integrated Circuit Card Terminal Specification 15461 for Payment Systems", version 3.1.1, 31 May 1998. 15463 [EMV3] ---, "EMV '96 Integrated Circuit Card Application 15464 Specification for Payment Systems", version 3.1.1, 31 May 15465 1998. 15467 [F1037] U.S. General Services Administration, "Glossary of 15468 Telecommunications Terms", FED STD 1037C, 7 August 1996. 15470 [For94] Ford, W., "Computer Communications Security: Principles, 15471 Standard Protocols and Techniques", ISBN 0-13-799453-2, 15472 1994. 15474 [For97] --- and M. Baum, "Secure Electronic Commerce: Building the 15475 Infrastructure for Digital Signatures and Encryption", ISBN 15476 0-13-476342-4, 1994. 15478 [FP001] U.S. Department of Commerce, "Code for Information 15479 Interchange", Federal Information Processing Standards 15480 Publication (FIPS PUB) 1, 1 November 1968. 15482 [FP031] ---, "Guidelines for Automatic Data Processing Physical 15483 Security and Risk Management", FIPS PUB 31, June 1974. 15485 [FP039] ---, "Glossary for Computer Systems Security", FIPS PUB 39, 15486 15 February 1976. 15488 [FP041] ---, "Computer Security Guidelines for Implementing the 15489 Privacy Act of 1974", FIPS PUB 41, 30 May 1975. 15491 [FP046] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25 15492 October 1999. 15494 [FP074] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25 15495 October 1999. 15497 [FP081] ---, "DES Modes of Operation", FIPS PUB 81, 2 December 1980. 15499 [FP087] ---, "Guidelines for ADP Contingency Planning", FIPS PUB 87, 15500 27 March 1981. 15502 [FP102] ---, "Guideline for Computer Security Certification and 15503 Accreditation", FIPS PUB 102, 27 September 1983. 15505 [FP113] ---, "Computer Data Authentication", FIPS PUB 113, 30 May 15506 1985. 15508 [FP140] ---, "Security Requirements for Cryptographic Modules", FIPS 15509 PUB 140-2, 25 May 2001; with change notice 4, 3 December 15510 2002. 15512 [FP151] ---, "Portable Operating System Interface (POSIX) -- System 15513 Application Program Interface [C Language]", FIPS PUB 151-2, 15514 12 May 1993 15516 [FP180] ---, "Secure Hash Standard", FIPS PUB 180-2, August 2000; 15517 with change notice 1, 25 February 2004. 15519 [FP185] ---, "Escrowed Encryption Standard", FIPS PUB 185, 9 15520 February 1994. 15522 [FP186] ---, "Digital Signature Standard (DSS)", FIPS PUB 186-2, 27 15523 June 2000; with change notice 1, 5 October 2001. 15525 [FP188] ---, "Standard Security Label for Information Transfer", 15526 FIPS PUB 188, 6 September 1994. 15528 [FP191] ---, "Guideline for the Analysis of Local Area Network 15529 Security", FIPS PUB 191, 9 November 1994. 15531 [FP197] ---, "Advanced Encryption Standard", FIPS PUB 197, 26 15532 November 2001. 15534 [FP199] ---, "Standards for Security Categorization of Federal 15535 Information and Information Systems ", FIPS PUB 199, 15536 December 2003. 15538 [FPKI] ---, "Public Key Infrastructure (PKI) Technical 15539 Specifications: Part A -- Technical Concept of Operations", 15540 National Institute of Standards, 4 September 1998. 15542 [Gass] Gasser, M., "Building a Secure Computer System", Van 15543 Nostrand Reinhold Company, New York, 1988, ISBN 0-442-23022- 15544 2. 15546 [Gray] Gray, J. and A. Reuter, "Transaction Processing: Concepts 15547 and Techniques", Morgan Kaufmann Publishers, Inc., 1993. 15549 [Hafn] Hafner, K. and M. Lyon, "Where Wizards Stay Up Late: The 15550 Origins of the Internet", Simon & Schuster, New York, 1996. 15552 [Huff] Huff, G., "Trusted Computer Systems -- Glossary", MTR 8201, 15553 The MITRE Corporation, March 1981. 15555 [I3166] International Standards Organization, "Codes for the 15556 Representation of Names of Countries and Their Subdivisions, 15557 Part 1: Country Codes", ISO 3166-1:1997. 15559 ---, ---, "Part 2: Country Subdivision Codes", ISO/DIS 3166- 15560 2. 15562 ---, ---, "Part 3: Codes for Formerly Used Names of 15563 Countries", ISO/DIS 3166-3. 15565 [I7498] ---, "Information Processing Systems -- Open Systems 15566 Interconnection Reference Model, [Part 1:] Basic Reference 15567 Model", ISO/IEC 7498-1. (Equivalent to ITU-T Recommendation 15568 X.200.) 15570 ---, ---, "Part 2: Security Architecture", ISO/IEC 7499-2. 15572 ---, ---, "Part 4: Management Framework", ISO/IEC 7498-4. 15574 [I7812] ---, "Identification cards -- Identification of Issuers, 15575 Part 1: Numbering System", ISO/IEC 7812-1:1993 15577 ---, ---, "Part 2: Application and Registration Procedures", 15578 ISO/IEC 7812-2:1993. 15580 [I8073] ---, "Information Processing Systems -- Open Systems 15581 Interconnection, Transport Protocol Specification", ISO IS 15582 8073. 15584 [I8327] ---, ---, "Session Protocol Specification", ISO IS 8327. 15586 [I8473] ---, ---, "Protocol for Providing the Connectionless Network 15587 Service", ISO IS 8473. 15589 [I8802-2] ---, "Information Processing Systems -- Local Area 15590 Networks, Part 2: Logical Link Control", ISO IS 8802-2. 15591 (Equivalent to IEEE 802.2.) 15593 [I8802-3] ---, ---, "Part 3: Carrier Sense Multiple Access with 15594 Collision Detection (CSMA/CD) Access Method and Physical 15595 Layer Specifications", ISO IS 8802-3. (Equivalent to IEEE 15596 802.3.) 15598 [I8823] ---, "Information Processing Systems -- Open Systems 15599 Interconnection -- Connection-Oriented Presentation Protocol 15600 Specification", ISO IS 8823. 15602 [I9945] "Portable Operating System Interface for Computer 15603 Environments", ISO/IEC 9945-1: 1990. 15605 [IATF] NSA, "Information Assurance Technical Framework", Release 3, 15606 NSA, September 2000. (See: IATF.) 15608 [IDSAN] ---, "Intrusion Detection System Analyzer Protection 15609 Profile", version 1.1, NSA, 10 December 2001. 15611 [IDSSC] ---, "Intrusion Detection System Scanner Protection 15612 Profile", version 1.1, NSA, 10 December 2001. 15614 [IDSSE] ---, "Intrusion Detection System Sensor Protection Profile", 15615 version 1.1, NSA, 10 December 2001. 15617 [IDSSY] ---, "Intrusion Detection System", version 1.4, NSA, 4 15618 February 2002. 15620 [Ioan] Ioannidis, J. and M. Blaze, "The Architecture and 15621 Implementation of Network Layer Security in UNIX", in "UNIX 15622 Security IV Symposium", October 1993, pp. 29-39. 15624 [ITSEC] "Information Technology Security Evaluation Criteria 15625 (ITSEC): Harmonised Criteria of France, Germany, the 15626 Netherlands, and the United Kingdom", version 1.2, U.K. 15627 Department of Trade and Industry, June 1991. 15629 [JCSP1] U.S. DoD, "Dictionary of Military and Associated Terms", 15630 Joint Chiefs of Staff, JCS Pub. 1, 1 April 1984. 15632 [John] Johnson, N. and S. Jajodia, "Exploring Steganography; Seeing 15633 the Unseen", in "IEEE Computer", February 1998, pp. 26-34. 15635 [Kahn] Kahn, D., "The Codebreakers: The Story of Secret Writing", 15636 The Macmillan Company, New York, 1967. 15638 [Knut] Knuth, D., Chapter 3 ("Random Numbers") of Volume 2 15639 ("Seminumerical Algorithms") of "The Art of Computer 15640 Programming", Addison-Wesley, Reading, MA, 1969. 15642 [Kuhn] Kuhn, M. and R. Anderson, "Soft Tempest: Hidden Data 15643 Transmission Using Electromagnetic Emanations", in David 15644 Aucsmith, ed., "Information Hiding, Second International 15645 Workshop, IH'98", Portland, Oregon, USA, 15-17 April 1998, 15646 LNCS 1525, Springer-Verlag, ISBN 3-540-65386-4, pp. 124-142. 15648 [Land] Landwehr, C., "Formal Models for Computer Security", in "ACM 15649 Computing Surveys", vol. 13, no. 3, September 1981, pp. 247- 15650 278. 15652 [Larm] Larmouth, J., "ASN.1 Complete", Open System Solutions, 1999 15653 (a freeware book). 15655 [M0404] U.S. Office of Management and Budget, "E-Authentication 15656 Guidance for Federal Agencies", Memorandum M-04-04, 16 15657 December 2003. 15659 [Mene] Menezes, A. et al, "Some Key Agreement Protocols Providing 15660 Implicit Authentication", in "The 2nd Workshop on Selected 15661 Areas in Cryptography", 1995. 15663 [Moor] Moore, A. et al, "Attack Modeling for Information Security 15664 and Survivability", Carnegie-Mellon University / Software 15665 Engineering Institute, CMU/SEI-2001-TN-001, March 2001. 15667 [Murr] Murray, W., "Courtney's Laws of Security", in "Infosecurity 15668 News", March/April 1993, p. 65. 15670 [N4001] National Security Telecommunications and Information System 15671 Security Committee, "Controlled Cryptographic Items", 15672 NSTISSI No. 4001, 25 March 1985. 15674 [N4006] ---, "Controlled Cryptographic Items", NSTISSI No. 4006, 2 15675 December 1991. 15677 [N7003] ---, "Protective Distribution Systems", NSTISSI No. 7003, 13 15678 December 1996. 15680 [NCS01] National Computer Security Center, "A Guide to Understanding 15681 Audit in Trusted Systems", NCSC-TG-001, 1 June 1988. (See: 15682 Rainbow Series.) 15684 [NCS03] ---, "Information System Security Policy Guideline", I942- 15685 TR-003, version 1, July 1994. (See: Rainbow Series.) 15687 [NCS04] ---, "Glossary of Computer Security Terms", NCSC-TG-004, 15688 version 1, 21 October 1988. (See: Rainbow Series.) 15690 [NCS05] ---, "Trusted Network Interpretation of the Trusted Computer 15691 System Evaluation Criteria", NCSC-TG-005, version 1, 31 July 15692 1987. (See: Rainbow Series.) 15694 [NCS25] ---, "A Guide to Understanding Data Remanence in Automated 15695 Information Systems", NCSC-TG-025, version 2, September 15696 1991. (See: Rainbow Series.) 15698 [NCS25] ---, "A Guide to Understanding Data Remanence in Automated 15699 Information Systems", NCSC-TG-025, version 2, September 15700 1991. (See: Rainbow Series.) 15702 [NRC91] National Research Council, "Computers At Risk: Safe 15703 Computing in the Information Age", National Academy Press, 15704 1991. 15706 [NRC98] Schneider, F., ed., "Trust in Cyberspace", National Research 15707 Council, National Academy of Sciences, 1998. 15709 [Padl] Padlipsky, M., "The Elements of Networking Style", 1985, 15710 ISBN 0-13-268111-0. 15712 [Park] Parker, D., "Computer Security Management", ISBN 0-8359- 15713 0905-0, 1981 15715 [Perr] Perrine, T. et al, "An Overview of the Kernelized Secure 15716 Operating System (KSOS)", in "Proceedings of the 7th DoD/NBS 15717 Computer Security Conference", 24-26 September 1984. 15719 [PGP] Garfinkel, S.. "PGP: Pretty Good Privacy", O'Reilly & 15720 Associates, Inc., Sebastopol, CA, 1995. 15722 [PKCS] Kaliski Jr., B., "An Overview of the PKCS Standards", RSA 15723 Data Security, Inc., 3 June 1991. 15725 [PKC05] RSA Laboratories, "PKCS #5: Password-Based Encryption 15726 Standard ", version 1.5, RSA Laboratories Technical Note, 1 15727 November 1993. (See: [R2898].) 15729 [PKC07] ---, "PKCS #7: Cryptographic Message Syntax Standard", 15730 version 1.5, RSA Laboratories Technical Note, 1 November 15731 1993. 15733 [PKC10] ---, "PKCS #10: Certification Request Syntax Standard", 15734 version 1.0, RSA Laboratories Technical Note, 1 November 15735 1993. 15737 [PKC11] ---, "PKCS #11: Cryptographic Token Interface Standard", 15738 version 1.0, 28 April 1995. 15740 [R1108] Kent, S., "U.S. Department of Defense Security Options for 15741 the Internet Protocol", RFC 1108, November 1991. 15743 [R1135] Reynolds, J., "The Helminthiasis of the Internet", RFC 1135, 15744 December 1989 15746 [R1208] Jacobsen, O. and D. Lynch, "A Glossary of Networking Terms", 15747 RFC 1208, March 1991. 15749 [R1281] Pethia, R., Crocker, S., and B. Fraser, "Guidelines for 15750 Secure Operation of the Internet", RFC 1281, November 1991. 15752 [R1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, 15753 April 1992. 15755 [R1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, 15756 April 1992. 15758 [R1321] ---, "The MD5 Message-Digest Algorithm", RFC 1321, April 15759 1992. 15761 [R1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", 15762 RFC 1334, October 1992. 15764 [R1413] St. Johns, M., "Identification Protocol", RFC 1413, February 15765 1993. 15767 [R1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail, 15768 Part I: Message Encryption and Authentication Procedures", 15769 RFC 1421, February 1993. 15771 [R1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail, 15772 Part II: Certificate-Based Key Management", RFC 1422, 15773 February 1993. 15775 [R1455] Eastlake 3rd, D., "Physical Link Security Type of Service", 15776 RFC 1455, May 1993. 15778 [R1457] Housley, R., "Security Label Framework for the Internet", 15779 RFC 1457, May 1993. 15781 [R1492] Finseth, C., "An Access Control Protocol, Sometimes Called 15782 TACACS", RFC 1492, July 1993. 15784 [R1507] Kaufman, C., "DASS: Distributed Authentication Security 15785 Service", RFC 1507, September 1993. 15787 [R1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication 15788 Service (V5)", RFC 1510, September 1993 15790 [R1731] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, 15791 December 1994. 15793 [R1734] ---, "POP3 AUTHentication Command", RFC 1734, Dec, 1994. 15795 [R1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness 15796 Recommendations for Security", RFC 1750, December 1994. 15798 [R1760] Haller, N., "The S/KEY One-Time Password System", RFC 1760, 15799 February 1995. 15801 [R1824] Danisch, H., "The Exponential Security System TESS: An 15802 Identity-Based Cryptographic Protocol for Authenticated Key- 15803 Exchange (E.I.S.S.-Report 1995/4)", RFC 1824, August 1995. 15805 [R1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed 15806 MD5", RFC 1828, August 1995. 15808 [R1829] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC 15809 Transform", RFC 1829, August 1995. 15811 [R1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME 15812 Object Security Services", RFC 1848, October 1995. 15814 [R1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES 15815 Transform", RFC 1851, September 1995. 15817 [R1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. 15818 Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. 15820 [R1938] Haller, N. and C. Metz, "A One-Time Password System", RFC 15821 1938, May 1996. 15823 [R1958] Carpenter, B., ed., "Architectural Principles of the 15824 Internet", RFC 1958, June 1996. 15826 [R1983] Malkin, G., ed., "Internet Users' Glossary", FYI 18, RFC 15827 1983, August 1996. 15829 [R1994] Simpson, W., "PPP Challenge Handshake Authentication 15830 Protocol (CHAP)", RFC 1994, August 1996. 15832 [R2078] Linn, J., "Generic Security Service Application Program 15833 Interface, Version 2", RFC 2078, January 1997. 15835 [R2084] Bossert, G., Cooper, S., and W. Drummond, "Considerations 15836 for Web Transaction Security", RFC 2084, January 1997. 15838 [R2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 15839 Hashing for Message Authentication", RFC 2104, February 15840 1997. 15842 [R2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 15843 May 1997. 15845 [R2179] Gwinn, A., "Network Security For Trade Shows", RFC 2179, 15846 July 1997. 15848 [R2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 15849 AUTHorize Extension for Simple Challenge/Response", RFC 15850 2195, September 1997. 15852 [R2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 15853 September 1997. 15855 [R2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 15856 SHA-1", RFC 2202, Sep. 1997. 15858 [R2222] Myers, J., "Simple Authentication and Security Layer 15859 (SASL)", RFC 2222, October 1997. 15861 [R2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", 15862 RFC 2246, January 1999. 15864 [R2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax, Version 15865 1.5", RFC 2315, March 1998. 15867 [R2323] Ramos, A., "IETF Identification and Security Guidelines", 15868 RFC 2323, 1 April 1998. (Intended for humorous entertainment 15869 -- "please laugh loud and hard" -- and does not contain 15870 serious security information.) 15872 [R2350] Brownlee, N. and E. Guttman, "Expectations for Computer 15873 Security Incident Response", RFC 2350, June 1998. 15875 [R2356] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal 15876 for Mobile IP", RFC 2356, June 1998. 15878 [R2401] Kent, S. and R. Atkinson, "Security Architecture for the 15879 Internet Protocol", RFC 2401, November 1998. 15881 [R2402] ---, "IP Authentication Header", RFC 2402, November 1998. 15883 [R2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP 15884 and AH", RFC 2403, November 1998. 15886 [R2404] ---, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, 15887 November 1998. 15889 [R2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher 15890 Algorithm With Explicit IV", RFC 2405, November 1998. 15892 [R2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 15893 (ESP)", RFC 2406, November 1998. 15895 [R2407] Piper, D. "The Internet IP Security Domain of Interpretation 15896 for ISAKMP", RFC 2407, November 1998. 15898 [R2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 15899 "Internet Security Association and Key Management Protocol 15900 (ISAKMP)", RFC 2408, November 1998. 15902 [R2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 15903 (IKE)", RFC 2409, November 1998. 15905 [R2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 15906 Its Use With IPsec", RFC 2410, November 1998. 15908 [R2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 15909 2412, November 1998. 15911 [R2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 15912 Algorithms", RFC 2451, November 1998. 15914 [R2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security 15915 Handbook", RFC 2504, February 1999. 15917 [R2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 15918 Infrastructure Certificate Management Protocols", RFC 2510, 15919 March 1999. 15921 [R2535] Eastlake 3rd, D., Domain Name System Security Extensions, 15922 RFC 2535, March 1999. 15924 [R2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name 15925 System (DNS)", RFC 2536, March 1999. 15927 [R2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 15928 Adams, "X.509 Internet Public Key Infrastructure Online 15929 Certificate Status Protocol", RFC 2560, June 1999. 15931 [R2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption 15932 Algorithm", RFC 2612, June 1999. 15934 [R2628] Smyslov, V., "Simple Cryptographic Program Interface", RFC 15935 2628, June 1999. 15937 [R2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 15938 2631, June 1999. 15940 [R2634] Hoffman, P., ed., "Enhanced Security Services for S/MIME", 15941 RFC 2634, June 1999. 15943 [R2635] Hambridge, S. and A. Lunde, "Don't Spew: A Set of Guidelines 15944 for Mass Unsolicited Mailings and Postings", RFC 2635, June 15945 1999. 15947 [R2660] Rescorla, E. and A. Schiffman, "The Secure HyperText 15948 Transfer Protocol", RFC 2660, August 1999. 15950 [R2773] Housley, R., Yee, P., and W. Nace, "Encryption using KEA and 15951 SKIPJACK", RFC 2773, February 2000. 15953 [R2801] Burdett, D., "Internet Open Trading Protocol - IOTP, Version 15954 1.0", RFC 2801, April 2000. 15956 [R2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 15957 Defeating Denial of Service Attacks which employ IP Source 15958 Address Spoofing", BCP 38, RFC 2827, May 2000. 15960 [R2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 15961 Authentication Dial In User Service (RADIUS)", RFC 2865, 15962 June 2000. 15964 [R2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 15965 Specification, Version 2.0", RFC 2898, September 2000. (See: 15966 [PKC05].) 15968 [R3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 15969 Update", RFC 3007, November 2000. 15971 [R3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, 15972 "Policy Core Information Model -- Version 1 Specification", 15973 RFC 3060, February 2001. 15975 [R3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 15976 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 15977 J., and S. Waldbusser, "Terminology for Policy-Based 15978 Management", RFC 3198, November 2001. 15980 [R3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 15981 X.509 Public Key Infrastructure Certificate and Certificate 15982 Revocation List (CRL) Profile", RFC 3280, April 2002. 15984 [R3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 15985 "Introduction and Applicability Statements for Internet- 15986 Standard Management Framework", RFC 3410, December 2002. 15988 [R3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 15989 (USM) for version 3 of the Simple Network Management 15990 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 15992 [R3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "Group 15993 Domain of Interpretation", RFC 3547, July 2003. 15995 [R3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, 15996 "Internet X.509 Public Key Infrastructure Certificate Policy 15997 and Certification Practices Framework", RFC 3647, November 15998 2003. 16000 [R3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 16001 Public Key Infrastructure: Qualified Certificates Profile", 16002 RFC 3739, March 2004. 16004 [R3740] Hardjono, T. and B. Weis, "The Multicast Group Security 16005 Architecture", RFC 3740, March 2004. 16007 [R3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 16008 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 16009 3748, June 2004. 16011 [R3766] Orman, H. and P. Hoffman, "Determining Strengths For Public 16012 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 16013 April 2004. 16015 [R3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. 16016 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 16017 Proxy Certificate Profile", RFC 3820, June 2004. 16019 [R3851] Ramsdell, B., ed., "Secure/Multipurpose Internet Mail 16020 Extensions (S/MIME) Version 3.1 Message Specification", RFC 16021 3851, July 2004. 16023 [R3871] Jones, G., ed., "Operational Security Requirements for Large 16024 Internet Service Provider (ISP) IP Network Infrastructure", 16025 RFC 3871, September 2004. 16027 [Raym] Raymond, E., ed., "The On-Line Hacker Jargon File", version 16028 4.0.0, 24 July 1996. (See: http://www.tuxedo.org/jargon/ for 16029 the latest version. Also, "The New Hacker's Dictionary", 2nd 16030 edition, MIT Press, September 1993, ISBN 0-262-18154-1.) 16032 [Roge] Rogers, H., "An Overview of the Caneware Program", in 16033 "Proceedings of the 10th National Computer Security 16034 Conference", NIST and NCSC, September 1987. 16036 [RSCG] NSA, "Router Security Configuration Guide: Principles and 16037 Guidance for Secure Configuration of IP Routers, with 16038 Detailed Instructions for Cisco Systems Routers", version 16039 1.0g, C4-054R-00, 20 April 2001, available at 16040 http://www.nsa.gov. 16042 [Russ] Russell, D. et al, Chapter 10 ("TEMPEST") of "Computer 16043 Security Basics", ISBN 0-937175-71-4, 1991. 16045 [SAML] Organization for the Advancement of Structured Information 16046 Standards (OASIS), "Assertions and Protocol for the OASIS 16047 Security Assertion Markup Language (SAML)", version 1.1, 2 16048 September 2003. 16050 [Sand] Sandhu, R. et al, "Role-Based Access Control Models", in 16051 "IEEE Computer", vol. 29, no.2, February 1996, pp. 38-47. 16053 [Schn] Schneier, B., "Applied Cryptography Second Edition", John 16054 Wiley & Sons, Inc., New York, 1996. 16056 [SDNS3] U.S. DoD, NSA, "Secure Data Network Systems, Security 16057 Protocol 3 (SP3)", document SDN.301, Revision 1.5, 15 May 16058 1989. 16060 [SDNS4] ---, ---, "Security Protocol 4 (SP4)", document SDN.401, 16061 Revision 1.2, 12 July 1988. 16063 [SDNS7] ---, ---, "Secure data Network System, Message Security 16064 Protocol (MSP)", SDN.701, Revision 4.0, 7 June 1996, with 16065 "Corrections to Message Security Protocol, SDN.701, Rev 4.0, 16066 96-06-07", 30 Aug, 1996. 16068 [SET1] MasterCard and Visa, "SET Secure Electronic Transaction 16069 Specification, Book 1: Business Description", version 1.0, 16070 31 May 1997. 16072 [SET2] ---, "SET Secure Electronic Transaction Specification, Book 16073 2: Programmer's Guide", version 1.0, 31 May 1997. 16075 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 16076 Mechanism for Internet", in "Proceedings of the 1996 16077 Symposium on Network and Distributed Systems Security". 16079 [SKIP] "SKIPJACK and KEA Algorithm Specifications", version 2.0, 22 16080 May 1998, and "Clarification to the SKIPJACK Algorithm 16081 Specification", 9 May 2002 (available from NIST Computer 16082 Security Resource Center). 16084 [SP12] NIST, "An Introduction to Computer Security: The NIST 16085 Handbook", Special Publication 800-12. 16087 [SP14] Swanson, M. et al (NIST), "Generally Accepted Principles and 16088 Practices for Security Information Technology Systems", --- 16089 800-14, September 1996. 16091 [SP15] Burr, W. et al (NIST), "Minimum Interoperability 16092 Specification for PKI Components (MISPC), Version 1", --- 16093 800-15, September 1997. 16095 [SP22] Rukhin, A. et al (NIST), "A Statistical Test Suite for 16096 Random and Pseudorandom Number Generators for Cryptographic 16097 Applications", --- 800-15, 15 May 2001. 16099 [SP27] Stoneburner, G. et al (NIST), "Engineering Principles for 16100 Information Technology Security (A Baseline for Achieving 16101 Security)", --- 800-27 Rev A, June 2004. 16103 [SP28] Jansen, W. (NIST), "Guidelines on Active Content and Mobile 16104 Code", --- 800-28, October 2001. 16106 [SP30] Stoneburner, G. et al (NIST), "Risk Management Guide for 16107 Information Technology Systems", --- 800-30, October 2001. 16109 [SP31] Bace, R. et al (NIST), "Intrusion Detection Systems", --- 16110 800-31. 16112 [SP32] Kuhn, D. (NIST), "Introduction to Public Key Technology and 16113 the Federal PKI Infrastructure ", --- 800-32, 26 February 16114 2001. 16116 [SP33] Stoneburner, G. (NIST), "Underlying Technical Models for 16117 Information Technology Security", --- 800-33, December 2001. 16119 [SP37] Ross, R. et al (NIST), "Guide for the Security Certification 16120 and Accreditation of Federal Information Systems", --- 800- 16121 37, May 2004 16123 [SP41] Wack. J. et al (NIST), "Guidelines on Firewalls and Firewall 16124 Policy", --- 800-41, January 2002. 16126 [SP42] ---, "Guideline on Network Security Testing", --- 800-42, 16127 October 2003. 16129 [SP56] NIST, "Recommendations on Key Establishment Schemes", Draft 16130 2.0, --- 800-63, January 2003. 16132 [SP57] ---, "Recommendation for Key Management", Part 1 "General 16133 Guideline" and Part 2 "Best Practices for Key Management 16134 Organization", --- 800-57, DRAFT, January 2003. 16136 [SP61] Grance, T. et al (NIST), "Computer Security Incident 16137 Handling Guide", --- 800-57, January 2003. 16139 [SP63] Burr, W. et al (NIST), "Electronic Authentication 16140 Guideline", --- 800-63, June 2004 16142 [SP67] Barker, W. (NIST), "Recommendation for the Triple Data 16143 Encryption Algorithm (TDEA) Block Cipher", --- 800-67, May 16144 2004 16146 [Stal] Stallings, W., "Local Networks", 1987, ISBN 0-02-415520-9. 16148 [Stei] Steiner, J. et al, "Kerberos: An Authentication Service for 16149 Open Network Systems", in "Usenix Conference Proceedings", 16150 February 1988. 16152 [Weis] Weissman, C., "Blacker: Security for the DDN: Examples of A1 16153 Security Engineering Trades", in "Symposium on Security and 16154 Privacy", IEEE Computer Society Press, May 1992, pp. 286- 16155 292. 16157 [X400] International Telecommunications Union -- Telecommunication 16158 Standardization Sector (formerly "CCITT"), Recommendation 16159 X.400, "Message Handling Services: Message Handling System 16160 and Service Overview". 16162 [X419] ---, "Message Handling Systems: Protocol Specifications", 16163 ITU-T Recommendation X.419. (Equivalent to ISO 10021-6). 16165 [X420] ---, ---: "Interpersonal Messaging System", ITU-T 16166 Recommendation X.420. (Equivalent to ISO 10021-7.). 16168 [X500] ---, Recommendation X.500, "Information Technology -- Open 16169 Systems Interconnection -- The Directory: Overview of 16170 Concepts, Models, and Services". (Equivalent to ISO 9594-1.) 16172 [X501] ---, Recommendation X.501, ---: "Models". 16174 [X509] ---, Recommendation X.509, ---: "Authentication Framework", 16175 COM 7-250-E Revision 1, 23 February 2001. (Equivalent to ISO 16176 9594-8.) 16178 [X519] ---, Recommendation X.519, ---: "Protocol Specifications". 16180 [X520] ---, Recommendation X.520, ---: "Selected Attribute Types". 16182 [X680] ---, Recommendation X.680, "Information Technology -- 16183 Abstract Syntax Notation One (ASN.1) -- Specification of 16184 Basic Notation", 15 November 1994. (Equivalent to ISO/IEC 16185 8824-1.) 16187 [X690] ---, Recommendation X.690, "Information Technology -- ASN.1 16188 Encoding Rules -- Specification of Basic Encoding Rules 16189 (BER), Canonical Encoding Rules (CER) and Distinguished 16190 Encoding Rules (DER)", 15 November 1994. (Equivalent to 16191 ISO/IEC 8825-1.) 16193 6. Security Considerations 16195 This document mainly defines security terms and recommends how to use 16196 them. It also provides limited tutorial information about security 16197 aspects of Internet protocols, but it does not describe in detail the 16198 vulnerabilities of, or threats to, specific protocols and does not 16199 definitively describe mechanisms that protect specific protocols. 16201 7. Acknowledgments 16203 Funding for the RFC Editor function is currently provided by the 16204 Internet Society. 16206 George Huff had a good idea! [Huff] 16208 8. Author's Address 16210 Please address all comments to: 16212 Robert W. Shirey BBN Technologies 16213 E-mail: rshirey@bbn.com Suite 400, Mail Stop 30/6B1 16214 1300 Seventeenth Street North 16215 Arlington, VA 22209-3801 USA 16217 9. Full Copyright Statement 16219 Copyright (C) The Internet Society (2005). This document is subject 16220 to the rights, licenses and restrictions contained in BCP 78, and 16221 except as set forth therein, the authors retain all their rights. 16223 This document and the information contained herein are provided on an 16224 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE IS SPONSORED 16225 BY, THE INTERNET SOCIETY, AND THE INTERNET ENGINEERING TASK FORCE 16226 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 16227 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 16228 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 16229 OR FITNESS FOR A PARTICULAR PURPOSE. 16231 Expiration Date: 9 September 2005.