idnits 2.17.1 draft-shirey-security-glossary-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 190 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 191 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([R2026]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 156: '..."I" identifies a RECOMMENDED Internet ...' RFC 2119 keyword, line 157: '..."N" identifies a RECOMMENDED non-Inter...' RFC 2119 keyword, line 161: '... definition that SHOULD NOT be used in...' RFC 2119 keyword, line 171: '... that SHOULD be the first choice for...' RFC 2119 keyword, line 172: '...ons of this type MAY be used in ISPDs;...' (102 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 861 has weird spacing: '... was delib...' -- 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 (17 October 1999) is 8958 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: 'ABA96' is mentioned on line 1563, but not defined == Missing Reference: 'RFC2104' is mentioned on line 1627, but not defined == Missing Reference: 'R1108' is mentioned on line 4195, but not defined == Missing Reference: 'CSC001' is mentioned on line 8450, but not defined == Missing Reference: 'R1661' is mentioned on line 5908, but not defined == Missing Reference: 'IS9945-1' is mentioned on line 6021, but not defined == Missing Reference: 'IS7812' is mentioned on line 6073, but not defined == Missing Reference: 'R2138' is mentioned on line 6595, but not defined == Missing Reference: 'R1543' is mentioned on line 6645, but not defined == Missing Reference: 'RSA78' is mentioned on line 6723, but not defined == Missing Reference: 'I7498-4' is mentioned on line 7152, but not defined == Missing Reference: 'SET' is mentioned on line 7348, but not defined == Missing Reference: 'R1760' is mentioned on line 7457, but not defined == Missing Reference: 'FIPS31' is mentioned on line 7945, but not defined == Missing Reference: 'R2368' is mentioned on line 8620, but not defined == Unused Reference: 'I7498' is defined on line 9331, but no explicit reference was found in the text == Unused Reference: 'I7812' is defined on line 9340, but no explicit reference was found in the text == Unused Reference: 'I9945' is defined on line 9345, but no explicit reference was found in the text == Unused Reference: 'NCS01' is defined on line 9368, but no explicit reference was found in the text == Unused Reference: 'PKCS' is defined on line 9386, but no explicit reference was found in the text == Unused Reference: 'R1457' is defined on line 9456, but no explicit reference was found in the text == Unused Reference: 'R1885' is defined on line 9509, but no explicit reference was found in the text == Unused Reference: 'R2023' is defined on line 9531, but no explicit reference was found in the text == Unused Reference: 'R2196' is defined on line 9569, but no explicit reference was found in the text == Unused Reference: 'R2630' is defined on line 9659, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ABA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'A3092' -- Possible downref: Non-RFC (?) normative reference: ref. 'A9009' -- Possible downref: Non-RFC (?) normative reference: ref. 'A9017' -- Possible downref: Non-RFC (?) normative reference: ref. 'A9042' -- Possible downref: Non-RFC (?) normative reference: ref. 'A9052' -- Possible downref: Non-RFC (?) normative reference: ref. 'A9062' -- Possible downref: Non-RFC (?) normative reference: ref. 'B7799' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'CIPSO' -- Possible downref: Non-RFC (?) normative reference: ref. 'CSC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'DOD1' -- Possible downref: Non-RFC (?) normative reference: ref. 'CSC2' -- Possible downref: Non-RFC (?) normative reference: ref. 'CSC3' -- Possible downref: Non-RFC (?) normative reference: ref. 'CSOR' -- Possible downref: Non-RFC (?) normative reference: ref. 'Denn' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH76' -- Possible downref: Non-RFC (?) normative reference: ref. 'DOD2' -- Possible downref: Non-RFC (?) normative reference: ref. 'DOD3' -- Possible downref: Non-RFC (?) normative reference: ref. 'DOD98' -- Possible downref: Non-RFC (?) normative reference: ref. 'EMV1' -- Possible downref: Non-RFC (?) normative reference: ref. 'EMV2' -- Possible downref: Non-RFC (?) normative reference: ref. 'EMV3' -- Possible downref: Non-RFC (?) normative reference: ref. 'For94' -- Possible downref: Non-RFC (?) normative reference: ref. 'For97' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP031' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP039' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP046' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP081' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP102' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP113' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP140' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP151' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP185' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP186' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP188' -- Possible downref: Non-RFC (?) normative reference: ref. 'FPDAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'FPKI' -- Possible downref: Non-RFC (?) normative reference: ref. 'I3166' -- Possible downref: Non-RFC (?) normative reference: ref. 'I7498' -- Possible downref: Non-RFC (?) normative reference: ref. 'I7812' -- Possible downref: Non-RFC (?) normative reference: ref. 'I9945' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kahn' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kuhn' -- Possible downref: Non-RFC (?) normative reference: ref. 'MISPC' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCS01' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCS04' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCS05' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCS25' -- Possible downref: Non-RFC (?) normative reference: ref. 'PGP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKC07' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKC10' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKC11' ** Obsolete normative reference: RFC 1885 (ref. 'R0792') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Informational RFC: RFC 1208 ** Obsolete normative reference: RFC 1319 (Obsoleted by RFC 6149) ** Obsolete normative reference: RFC 1320 (Obsoleted by RFC 6150) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1334 (Obsoleted by RFC 1994) ** Downref: Normative reference to an Historic RFC: RFC 1421 ** Downref: Normative reference to an Historic RFC: RFC 1422 ** Obsolete normative reference: RFC 1455 (Obsoleted by RFC 2474) ** Downref: Normative reference to an Informational RFC: RFC 1457 ** Downref: Normative reference to an Informational RFC: RFC 1492 ** Downref: Normative reference to an Experimental RFC: RFC 1507 ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Possible downref: Non-RFC (?) normative reference: ref. 'R1591' ** Downref: Normative reference to an Informational RFC: RFC 1630 ** Obsolete normative reference: RFC 1734 (Obsoleted by RFC 5034) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. 'R1750' -- Possible downref: Non-RFC (?) normative reference: ref. 'R1777' ** Obsolete normative reference: RFC 1808 (Obsoleted by RFC 3986) ** Downref: Normative reference to an Informational RFC: RFC 1824 ** Downref: Normative reference to an Historic RFC: RFC 1828 ** Downref: Normative reference to an Historic RFC: RFC 1848 ** Downref: Normative reference to an Experimental RFC: RFC 1851 ** Obsolete normative reference: RFC 1866 (Obsoleted by RFC 2854) -- Duplicate reference: RFC1885, mentioned in 'R1885', was also mentioned in 'R0792'. ** Obsolete normative reference: RFC 1885 (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1938 (Obsoleted by RFC 2289) ** Downref: Normative reference to an Informational RFC: RFC 1958 ** Downref: Normative reference to an Informational RFC: RFC 1983 ** Obsolete normative reference: RFC 2023 (Obsoleted by RFC 2472) ** Obsolete normative reference: RFC 2060 (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) ** Obsolete normative reference: RFC 2078 (Obsoleted by RFC 2743) ** Downref: Normative reference to an Informational RFC: RFC 2084 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2137 (Obsoleted by RFC 3007) ** Downref: Normative reference to an Informational RFC: RFC 2179 ** Downref: Normative reference to an Informational RFC: RFC 2196 ** Downref: Normative reference to an Informational RFC: RFC 2202 ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Downref: Normative reference to an Informational RFC: RFC 2315 ** Downref: Normative reference to an Informational RFC: RFC 2323 ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 2504 ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2527 (Obsoleted by RFC 3647) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Downref: Normative reference to an Informational RFC: RFC 2612 ** Downref: Normative reference to an Informational RFC: RFC 2628 ** Obsolete normative reference: RFC 2630 (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2633 (Obsoleted by RFC 3851) ** Downref: Normative reference to an Informational RFC: RFC 2635 -- Possible downref: Non-RFC (?) normative reference: ref. 'Raym' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schn' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS4' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS7' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Stei' -- Possible downref: Non-RFC (?) normative reference: ref. 'X400' -- Possible downref: Non-RFC (?) normative reference: ref. 'X500' -- Possible downref: Non-RFC (?) normative reference: ref. 'X501' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509' -- Possible downref: Non-RFC (?) normative reference: ref. 'X519' -- Possible downref: Non-RFC (?) normative reference: ref. 'X520' -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 69 errors (**), 0 flaws (~~), 31 warnings (==), 80 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Shirey 2 INTERNET-DRAFT GTE / BBN Technologies 3 Expiration Date: 17 April 2000 17 October 1999 5 Internet Security Glossary 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of section 10 of RFC 2026 *except* that the right to 12 produce derivative works is *not* granted. (See GTE copyright notice 13 below. However, if and when this document is issued as an RFC, we 14 expect that it will instead carry the standard Internet Society 15 copyright notice.) 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) GTE / BBN Technologies (1999). All Rights Reserved. 37 This document and translations of it may be copied and furnished to 38 others, in whole, without restriction of any kind, provided that the 39 above copyright notice and this paragraph are included on all such 40 copies. However, this document itself may not be modified in any way, 41 such as by removing the copyright notice or removing references to 42 GTE or BBN. 44 (If and when this document is issued as an RFC, we expect this 45 copyright to be changed to the standard Internet Society copyright.) 47 Abstract 49 This Glossary provides definitions, abbreviations, explanations, and 50 recommendations for use of information system security terminology. 51 The intent of the Glossary is to improve the comprehensibility of 52 Internet Standards Process [R2026] documents (ISPDs). To be clear and 53 understandable, ISPDs should use the same term or definition whenever 54 and wherever the same concept is mentioned. To improve international 55 understanding, ISPDs should use terms in their plainest, dictionary 56 sense. ISPDs should use terms established in standards documents and 57 other well-founded publications and should avoid substituting private 58 or newly made-up terms. ISPDs should avoid terms that are proprietary 59 or otherwise favor a particular vendor, or that create a bias toward 60 a particular security technology or mechanism versus other, competing 61 techniques that already exist or might be developed in the future. 63 Table of Contents 65 Section Page 66 ------- ---- 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Explanation of Paragraph Markings . . . . . . . . . . . . . . 4 69 2.1 Recommended Terms with an Internet Basis ("I") . . . . . . 4 70 2.2 Recommended Terms with a Non-Internet Basis ("N") . . . . 5 71 2.3 Other Definitions ("O") . . . . . . . . . . . . . . . . . 5 72 2.4 Deprecated Terms, Definitions, and Uses ("D") . . . . . . 6 73 2.5 Commentary and Additional Guidance ("C") . . . . . . . . . 6 74 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 179 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 191 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 191 78 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 191 79 8. Expiration Date . . . . . . . . . . . . . . . . . . . . . . . 191 81 1. Introduction 83 This Glossary seeks to improve the comprehensibility of Internet 84 Standards Process [R2026] documents (ISPDs)--i.e., RFCs and Internet- 85 Drafts--by providing a consistent, self-supporting set of 86 definitions, abbreviations, explanations, and recommendations for use 87 of terminology related to information system security. A few non- 88 security, networking terms are included to make the Glossary self- 89 contained, but more complete glossaries of networking terms are 90 available elsewhere [R1208, R1983]. There are other glossaries of 91 computing terminology (including an extensive listing of hacker 92 jargon [Raym]) that list additional terms that apply to Internet 93 security. However, many of those terms are not appropriate for 94 standards documents and, thus, have not been included in this 95 dictionary. 97 To provide guidance for ISPDs, this Glossary marks term and 98 definitions as either endorsed or deprecated for use. The key words 99 "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in RFC 101 2119. (The key words "MUST", "MUST NOT", "SHALL", and "SHALL NOT" are 102 not used in this Glossary.) 104 This Glossary supports the goals of the Internet Standards Process: 106 o Clear, Concise, and Easily Understood Documentation 108 This Glossary seeks to improve comprehensibility of security- 109 related content of ISPDs. That requires the wording to be clear 110 and understandable, and requires the set of security-related terms 111 and definitions to be consistent and self-supporting. Also, the 112 terminology needs to be uniform and across all ISPDs; the same 113 term or definition needs to be used whenever and wherever the same 114 concept is mentioned. Harmonization of existing ISPDs need not be 115 done immediately, but is desirable to do when new versions are 116 issued in the normal course of standards development and 117 evolution. 119 o Technical Excellence 121 Just as Internet Standard protocols should operate effectively, 122 ISPDs should use terminology accurately, precisely, and 123 unambiguously to enable them to be implemented correctly. 125 o Prior Implementation and Testing 127 Just as Internet Standard protocols require experience and 128 stability before adoption, ISPDs need to use well-established 129 language. Using terms in their plainest, dictionary sense (when 130 appropriate) help to ensure international understanding. ISPDs 131 need to avoid using private, made-up terms in place of generally- 132 accepted terms from standards and other publications. ISPDs need 133 to avoid substituting new definitions that conflict with 134 established ones. ISPDs need to avoid using "cute" synonyms (e.g., 135 see: Green Book); no matter how popular a nickname may be in one 136 community, it is likely to cause confusion in another. 138 o Openness, Fairness, and Timeliness 140 ISPDs need to avoid terms that are proprietary or otherwise favor 141 a particular vendor, or that create a bias toward a particular 142 security technology or mechanism over other, competing techniques 143 that already exist or might be developed in the future. The set of 144 terminology used across the set of ISPDs needs to be flexible and 145 adaptable as the state of Internet security art evolves. 147 2. Explanation of Paragraph Markings 149 Section 3 marks terms and definitions as follows: 151 o Capitalization: Only terms that are proper nouns are capitalized. 153 o Paragraph Marking: Definitions and explanations are stated in 154 paragraphs that are marked as follows: 156 - "I" identifies a RECOMMENDED Internet definition. 157 - "N" identifies a RECOMMENDED non-Internet definition. 158 - "O" identifies a definition that is not recommended as the 159 first choice for Internet documents but is something that 160 authors of Internet documents need to know. 161 - "D" identifies a term or definition that SHOULD NOT be used in 162 Internet documents. 163 - "C" identifies commentary or additional usage guidance, 164 including identifying deprecated terms. 166 The rest of Section 2 further explains those four markings. 168 2.1 Recommended Terms with an Internet Basis ("I") 170 The paragraph marking "I" (as opposed to "O") indicates a definition 171 that SHOULD be the first choice for use in ISPDs. Most terms and 172 definitions of this type MAY be used in ISPDs; however, some "I" 173 definitions are accompanied by a "D" paragraph that recommends 174 against use of the term. Also, some "I" definitions are preceded by 175 an indication of a contextual usage limitation (e.g., see: 176 certification), and ISPDs should not the term and definition outside 177 that context 179 An "I" (as opposed to an "N") also indicates that the definition has 180 an Internet basis. That is, either the Internet Standards Process is 181 authoritative for the term, or the term is sufficiently generic that 182 the Directorate can freely state a definition without contradicting a 183 non-Internet authority (e.g., see: attack). 185 Many terms with "I" definitions are proper nouns (e.g., see: Internet 186 Protocol). For these terms, the "I" definition is intended only to 187 provide basic information; the authoritative definition is found 188 elsewhere. 190 For a proper noun identified as an "Internet protocol", please refer 191 to the current edition of the "Internet Official Protocol Standards" 192 (STD 1) for the standardization state and status of the protocol. 194 2.2 Recommended Terms with a Non-Internet Basis ("N") 196 The paragraph marking "N" (as opposed to "O") indicates a definition 197 that the Directorate recommends SHOULD be the first choice for the 198 term, if the term is used at all in Internet documents. Terms and 199 definitions of this type MAY be used in Internet documents (e.g., 200 see: X.509 public-key certificate). 202 However, an "N" (as opposed to an "I") also indicates a definition 203 that has a non-Internet basis or origin; that is, the Internet 204 Standards Process is not authoritative for the definition. Many such 205 definitions are preceded by an indication of a contextual usage 206 limitation, and the Directorate's endorsement does not apply outside 207 that context. Also, some contexts are rarely if ever expected to 208 occur in a Internet document (e.g., see: baggage). In those cases, 209 the listing exists to make Internet authors aware of the non-Internet 210 usage so that they can avoid conflicts with non-Internet documents. 212 Many terms with "N" definitions are proper nouns (e.g., see: Computer 213 Security Objects Register). For these terms, the "N" definition is 214 intended only to provide basic information; the authoritative 215 definition is found elsewhere. 217 2.3 Other Definitions ("O") 219 The paragraph marking "O" (as opposed to "D") indicates a definition 220 that has a non-Internet basis or origin and also indicates that the 221 Directorate recommends that the definition SHOULD NOT be used in 222 Internet documents *except* in cases where the term is specifically 223 identified as non-Internet. 225 For example, an ISPD might mention "BCA" (see: brand certification 226 authority) or "baggage" as an example to illustrate some concept; in 227 that case, the document should specifically say "SET(trademark) BCA" 228 or "SET(trademark) baggage" and state the definition of the term. 230 For some terms that have a definition published by a non-Internet 231 authority--government (see: object reuse), industry (see: Secure Data 232 Exchange), national (see: key authentication), or international (see: 233 data confidentiality)--this Glossary marks the definition "N", 234 recommending its use in Internet documents. In other cases, an 235 available non-Internet definitions is inadequate or inappropriate for 236 ISPDs. For example, it may be narrow or outdated, or it may need 237 clarification by substituting more careful wording or more 238 explanatory wording, based on other terms that are defined here. In 239 those cases, this Glossary provides an "I" definition (or sometimes a 240 different "N" definition), which precedes and supersedes the 241 definition marked "O". 243 In cases where this Glossary provides a definition to supersede one 244 that is some kind of standard, the substitute is intended to subsume 245 the meaning of the "O" definition and not conflict with it. For 246 "security service", for example, the "O" definition deals narrowly 247 with only communication services provided by layers in the OSI model 248 and is inadequate for the full range of ISPD usage; the "I" 249 definition can be used in more situations and for more kinds of 250 service. However, the "O" definition is provided to make authors of 251 ISPDs aware of situations in which the term is used narrowly. 253 This Glossary attempts to substitute understandable English that does 254 not contradict any non-Internet authority. Still, terminology differs 255 between the standards of the American Bar Association, OSI, SET, the 256 U.S. Department of Defense, and other authorities, and this Glossary 257 probably is not exactly aligned with all of them. 259 2.4 Deprecated Terms, Definitions, and Uses ("D") 261 If the Directorate recommends that a term or definition SHOULD NOT be 262 used, or SHOULD NOT be used in a certain way, in ISPDs, then either 263 the definition has the paragraph marking "D", or an additional "D" 264 paragraph states that restriction. Usually, a rationale is given for 265 the negative recommendation (e.g., see: Green Book). 267 2.5 Commentary and Additional Guidance ("C") 269 The paragraph marking "C" identifies text that is advisory or 270 tutorial. This text MAY be reused in other Internet documents. This 271 text is not intended to be authoritative, but is provided to clarify 272 the definitions and to enhance this Glossary so that Internet 273 security novices can use it as a tutorial. 275 3. Definitions 277 --------------------------------------------------------------------- 278 Note: Any acronym or other abbreviation (excluding items of common 279 English usage, such as e.g., i.e., vol., pp., etc.) that is used in 280 this Glossary, either in a definition or as a subpart of a defined 281 term, is also defined in this Glossary. 282 --------------------------------------------------------------------- 284 $ 3DES 285 See: triple DES. 287 $ *-property 288 (I) (Pronounced "star property".) See: "confinement property" 289 under Bell-LaPadula Model. 291 $ ABA Guidelines 292 (N) "American Bar Association (ABA) Digital Signature Guidelines" 293 [ABA], a framework of legal principles for using digital 294 signatures and digital certificates in electronic commerce. 296 $ Abstract Syntax Notation One (ASN.1) 297 (N) A standard for describing data objects [X680]. 299 (C) OSI standards use ASN.1 to specify data formats for protocols. 300 OSI defines functionality in layers, and information objects at 301 higher layers are abstractly defined to be implemented with 302 objects at lower layers. A higher layer may define transfers of 303 abstract objects between computers, and a lower layer may define 304 transfers concretely as strings of bits. Syntax is needed to 305 define abstract objects, and encoding rules (see: Basic Encoding 306 Rules) are needed to transform between abstract objects and bit 307 strings. 309 (C) In ASN.1, formal names are written without spaces, and 310 separate words in a name are indicated by capitalizing the first 311 letter of each word except the first word. For example, the name 312 of a CRL is "certificateRevocationList". 314 $ ACC 315 See: access control center. 317 $ access 318 (I) The ability and means to communicate with or otherwise 319 interact with a system in order to use system resources to either 320 handle information or gain knowledge of the information the system 321 contains. 323 (O) "A specific type of interaction between a subject and an 324 object that results in the flow of information from one to the 325 other." [NCS04] 326 (C) In this Glossary, "access" is intended to cover any ability to 327 communicate with a system, including one-way communication in 328 either direction. In actual practice, however, entities outside a 329 security perimeter that can receive output from the system but 330 cannot provide input or otherwise directly interact with the 331 system, might be treated as not having "access" and, therefore, be 332 exempt from security policy requirements, such as the need for a 333 security clearance. 335 $ access control 336 (I) Protection of system resources against unauthorized access; a 337 process by which use of system resources is regulated according to 338 a security policy and is permitted by only authorized entities 339 (users, programs, processes, or other systems) according to that 340 policy. (See: access, access control service.) 342 (O) "The prevention of unauthorized use of a resource, including 343 the prevention of use of a resource in an unauthorized manner." 344 [I7498 Part 2] 346 $ access control center (ACC) 347 (I) A computer containing a database with entries that define a 348 security policy for an access control service. 350 (C) An ACC is sometimes used in conjunction with a key center to 351 implement access control in a key distribution system for 352 symmetric cryptography. 354 $ access control list (ACL) 355 (I) A mechanism that implements access control for a system 356 resource by enumerating the identities of the system entities that 357 are permitted to access the resource. (Compare with: capability.) 359 $ access control service 360 (I) A security service that protects against a system entity using 361 a system resource in a way not authorized by the system's security 362 policy; in short, protection of system resources against 363 unauthorized access. (See: access control, discretionary access 364 control, identity-based security policy, mandatory access control, 365 rule-based security policy.) 367 (C) This service includes protecting against use of a resource in 368 an unauthorized manner by an entity that is authorized to use the 369 resource in some other manner. 371 $ access mode 372 (I) A distinct type of data processing operation--such as read, 373 write, append, or execute--that potentially can be performed on an 374 object in a computer system. 376 $ accountability 377 (I) The property of a system (including all of its system 378 resources) that ensures that the actions of a system entity may be 379 traced uniquely to that entity, which can be held responsible for 380 its actions. (See: audit service.) 382 (C) Accountability permits detection and subsequent investigation 383 of security breaches. 385 $ accredit 386 $ accreditation 387 (I) An administrative declaration (usually based on a technical 388 certification of system security mechanisms) by a designated 389 authority that an information system is approved to operate in a 390 particular security configuration with a prescribed set of 391 safeguards. [FP102] (See: certification.) 393 (C) The terms "certification" and "accreditation" are used more in 394 the U.S. Department of Defense and other government agencies than 395 in commercial organizations. However, the concepts apply any place 396 where managers are required to deal with and accept responsibility 397 for security risks, and the American Bar Association is developing 398 accreditation criteria specifically for CAs. 400 $ ACL 401 See: access control list. 403 $ acquirer 404 (N) SET usage: "The financial institution that establishes an 405 account with a merchant and processes payment card authorizations 406 and payments." [SET1] 408 (O) "The institution (or its agent) that acquires from the card 409 acceptor the financial data relating to the transaction and 410 initiates that data into an interchange system." [SET2, ANSI X9.8 411 and X9.24] 413 $ active attack 414 See: (secondary definition in) attack. 416 $ active wiretapping 417 See: (secondary definition in) wiretapping. 419 $ add-on security 420 (I) "The retrofitting of protection mechanisms, implemented by 421 hardware or software, after the [automatic data processing] system 422 has become operational." [FP039] 424 $ administrative security 425 (I) Management procedures and constraints to prevent unauthorized 426 access to a system. (See: security architecture.) 428 (O) "The management constraints, operational procedures, 429 accountability procedures, and supplemental controls established 430 to provide an acceptable level of protection for sensitive data." 431 [FP039] 433 (C) Examples include clear delineation and separation of duties, 434 and configuration control. 436 $ Advanced Encryption Standard (AES) 437 (N) A future FIPS publication being developed by NIST to succeed 438 DES. Intended to specify an unclassified, publicly-disclosed, 439 symmetric encryption algorithm, available royalty-free worldwide. 441 $ adversary 442 (I) An entity that attacks, or is a threat to, a system. 444 $ Affirm 445 (I) A circumstance in which a collection of information items is 446 required to be classified at a higher security level than any of 447 the individual items that comprise it. 449 $ aggregation 450 (I) A circumstance in which a collection of information items is 451 required to be classified at a higher security level than any of 452 the individual items that comprise it. 454 $ AH 455 See: Authentication Header 457 $ alias 458 (I) A name that an entity uses in place of its real name, usually 459 for the purpose of either anonymity or deception. 461 $ algorithm 462 (I) A finite set of step-by-step instructions for a problem- 463 solving or computation procedure, especially one that can be 464 implemented by a computer. (See: cryptographic algorithm.) 466 $ American National Standards Institute (ANSI) 467 (N) A private, not-for-profit association of users, manufacturers, 468 and other organizations, that administers U.S. private sector 469 voluntary standards. 471 (C) ANSI is the sole U.S. representative to the two major non- 472 treaty international standards organizations, ISO and, via the 473 U.S. National Committee (USNC), the International Electrotechnical 474 Commission (IEC). 476 $ anonymous 477 (I) The condition of having a name that is unknown or concealed. 478 (Compare with: anonymous login.) 480 (C) An application may require security services that maintain 481 anonymity of users or other system entities, perhaps to preserve 482 their privacy or shield them from attack. To hide an entity's real 483 name, an alias may be used. For example, a financial institution 484 may assign an account number. Parties to a transaction can thus 485 remain relatively anonymous, but can also accept the transaction 486 as legitimate. Real names of the parties cannot be easily 487 determined by observers of the transaction, but an authorized 488 third party may be able to map an alias to a real name, such as by 489 presenting the institution with a court order. In other 490 applications, anonymous entities may be completely untraceable. 492 $ anonymous login 493 (I) An access control feature (or, rather, an access control hole) 494 in many Internet hosts that enables users to gain access to 495 general-purpose or public services and resources on a host (such 496 as allowing any user to transfer data using File Transfer 497 Protocol) without having a pre-established, user-specific account 498 (i.e., user name and password). 500 (C) The user logs in using a special, publicly known user name 501 (such as "anonymous", "guest", or "ftp") and then either is not 502 asked for a password or is asked to provide a special, publicly 503 known password (such as RanonymousS) or provide an arbitrary e- 504 mail address as password. The user then has access to a set of 505 publicly accessible system resources. This feature exposes a 506 system to more threats than when all the users are pre-registered, 507 trusted entities, and, of course, no individual accountability is 508 possible. 510 $ APOP 511 See: POP3 APOP. 513 $ archive 514 $ archive management 515 (I) (1.) Noun: A collection of data that is stored for a 516 relatively long period of time for historical and other purposes, 517 such as to support audit service, availability service, or system 518 integrity service. (Compare with: backup.) (2.) Verb: To store 519 data in such a way. (Compare with: back up.) 521 (C) A digital signature may need to be verified many years after 522 the signing occurs. The CA--the one that issued the certificate 523 containing the public key needed to verify that signature--may not 524 stay in operation that long. So every CA needs to provide for 525 long-term storage of the information needed to verify the 526 signatures of those to whom it issues certificates. 528 $ ARPANET 529 (N) Advanced Research Projects Agency Network, a pioneer packet- 530 switched network that was built in the early 1970s under contract 531 to the U.S. Government led to the development of today's Internet, 532 and was decommissioned in June 1990. 534 $ ASN.1 535 See: Abstract Syntax Notation One. 537 $ association 538 (I) A cooperative relationship between system entities, usually 539 for the purpose of transferring information between them. (See: 540 security association.) 542 $ assurance 543 (I) (1.) An attribute of an information system that provides 544 grounds for having confidence that the system operates such that 545 the system security policy is enforced. (2.) A procedure that 546 ensures a system is developed and operated as intended by the 547 system's security policy. 549 $ assurance level 550 (I) Evaluation usage: A specific level on a hierarchical scale 551 representing successively increased confidence that a target of 552 evaluation adequately fulfills the requirements (e.g., see: 553 TCSEC). 555 $ asymmetric cryptography 556 (I) A modern branch of cryptography (popularly known as "public- 557 key cryptography") in which the algorithms employ a pair of keys 558 (a public key and a private key) and use a different component of 559 the pair for different steps of the algorithm. (See: key pair.) 561 (C) Asymmetric algorithms have key management advantages over 562 equivalently strong symmetric ones. First, one key of the pair 563 does not need to be known by anyone but its owner; so it can more 564 easily be kept secret. Second, although the other key of the pair 565 is shared by all entities that use the algorithm, that key does 566 not need to be kept secret from other, non-using entities; so the 567 key distribution part of key management can be done more easily. 569 (C) For encryption: In an asymmetric encryption algorithm (e.g., 570 see: RSA), when Alice wants to ensure confidentiality for data she 571 sends to Bob, she encrypts the information with a public key 572 provided by Bob. Only Bob has the matching private key that is 573 needed to decrypt the data. 575 (C) For signature: In an asymmetric digital signature algorithm 576 (e.g., see: DSA), when Alice wants to ensure data integrity or 577 provide authentication for data she sends to Bob, she uses her 578 private key to sign (create a digital signature from) the data. To 579 verify the signature, Bob uses the matching public key that Alice 580 has provided. 582 (C) For key agreement: In an asymmetric key agreement algorithm 583 (e.g., see: Diffie-Hellman), Alice and Bob each send their own 584 public key to the other person. Then each uses their own private 585 key and the other's public key to compute the new key value. 587 $ attack 588 (I) An assault on system security that derives from an intelligent 589 threat, i.e., an intelligent act that is a deliberate attempt 590 (especially in the sense of a method or approach) to evade 591 security services and violate the security policy of a system. 592 (See: penetration, violation, vulnerability.) 594 - Active vs. passive: An "active attack" attempts to alter system 595 resources or affect their operation. A "passive attack" 596 attempts to learn or make use of information (e.g., see: 597 wiretapping) does not affect system resources. 599 - Insider vs. outsider: An "inside attack" is an attack initiated 600 by an entity inside the security perimeter (an "insider"), 601 i.e., by an entity that is authorized to access system 602 resources but uses them in a way not approved by those who 603 granted the authorization. An "outside attack" is initiated 604 from outside the perimeter, by an unauthorized or illegitimate 605 user of the system (an "outsider"). In the Internet, potential 606 outside attackers range from amateur pranksters to organized 607 criminals, international terrorists, and hostile governments. 609 (C) The term "attack" relates to some other basic security terms 610 as shown in the following model: 612 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 613 | An Attack: | |Counter- | | A System Resource: | 614 | i.e., A Threat Action | | measure | | Target of the Attack | 615 | +----------+ | | | | +-----------------+ | 616 | | Attacker |<==================||<========= | | 617 | | i.e., | Passive | | | | | Vulnerability | | 618 | | A Threat |<=================>||<========> | | 619 | | Agent | or Active | | | | +-------|||-------+ | 620 | +----------+ Attack | | | | VVV | 621 | | | | | Threat Consequences | 622 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 624 $ attribute authority 625 (I) A CA that issues attribute certificates. 627 (O) "An authority, trusted by the verifier to delegate privilege, 628 which issues attribute certificates." [FPDAM] 630 $ attribute certificate 631 (I) A digital certificate that binds a set of descriptive data 632 items, other than a public key, either directly to a subject name 633 or to the identifier of another certificate that is a public-key 634 certificate. [X509] 636 (O) "A set of attributes of a user together with some other 637 information, rendered unforgeable by the digital signature created 638 using the private key of the CA which issued it." [X509] 640 (O) "A data structure that includes some attribute values and 641 identification information about the owner of the attribute 642 certificate, all digitally signed by an Attribute Authority. This 643 authority's signature serves as the guarantee of the binding 644 between the attributes and their owner." [FPDAM] 646 (C) A public-key certificate binds a subject name to a public key 647 value, along with information needed to perform certain 648 cryptographic functions. Other attributes of a subject, such as a 649 security clearance, may be certified in a separate kind of digital 650 certificate, called an attribute certificate. A subject may have 651 multiple attribute certificates associated with its name or with 652 each of its public-key certificates. 654 (C) An attribute certificate might be issued to a subject in the 655 following situations: 657 - Different lifetimes: When the lifetime of an attribute binding 658 is shorter than that of the related public-key certificate, or 659 when it is desirable not to need to revoke a subject's public 660 key just to revoke an attribute. 662 - Different authorities: When the authority responsible for the 663 attributes is different than the one that issues the public-key 664 certificate for the subject. (There is no requirement that an 665 attribute certificate be issued by the same CA that issues the 666 associated public-key certificate.) 668 $ audit service 669 (I) A security service that records information needed to 670 establish accountability for system events and the actions of 671 system entities that cause them. (See: security audit.) 673 $ audit trail 674 See: security audit trail. 676 $ authentic signature 677 (I) A signature (particularly a digital signature) that can be 678 trusted because it can be verified. (See: validate vs. verify.) 680 $ AUTH 681 See: POP3 AUTH. 683 $ authenticate 684 (I) Verify (i.e., establish the truth of) an identity claimed by 685 or for a system entity. (See: authentication.) 687 (C) This definition is narrower than in general English usage, 688 where this term usually means "to prove genuine"; for example, an 689 art expert authenticates a Michelangelo painting. 691 (D) Although we might be tempted to speak similarly of 692 authenticating a digital signature or digital certificate, ISPDs 693 SHOULD NOT use that language in the context of asymmetric 694 cryptography. Instead, we "sign" and then "verify" digital 695 signatures, and we "issue" and then "validate" digital 696 certificates. (See: validate vs. verify.) 698 $ authentication 699 (I) The process of verifying an identity claimed by or for a 700 system entity. (See: authentication exchange, authentication 701 information, data origin authentication, peer entity 702 authentication.) 704 (C) An authentication process consists of two steps: 706 - Identification step: Presenting an identifier to the security 707 system. (Identifiers should be assigned carefully, because 708 authenticated identities are the basis for other security 709 services, such as access control service.) 711 - Verification step: Presenting or generating authentication 712 information that corroborates the binding between the entity 713 and the identifier. (See: verification.) 715 (C) See: ("relationship between data integrity service and 716 authentication services" in) data integrity service. 718 $ authentication code 719 (D) ISPDs SHOULD NOT use this term because it is sometimes 720 misleading defined as a synonym for cryptographic checksum. The 721 word "authentication" is misleading because the mechanism involved 722 usually serves a data integrity function rather than an 723 authentication function. (See: message authentication code.) 725 $ Authentication Header (AH) 726 (I) An Internet IPsec protocol [R2402] designed to provide 727 connectionless data integrity service and data origin 728 authentication service for IP datagrams, and (optionally) to 729 provide protection against replay attacks. 731 (C) Replay protection may be selected by the receiver when a 732 security association is established. AH authenticates upper-layer 733 protocol data units and as much of the IP header as possible. 734 However, some IP header fields may change in transit, and the 735 value of these fields, when the packet arrives at the receiver, 736 may not be predictable by the sender. The values of such fields 737 cannot be protected by AH. Thus, protection of the IP header by AH 738 is only partial. 740 (C) AH may be used alone, or in combination with the IPsec ESP 741 protocol, or in a nested fashion with tunneling. Security services 742 can be provided between a pair of communicating hosts, between a 743 pair of communicating security gateways, or between a host and a 744 gateway. ESP can provide the same security services as AH, and ESP 745 can also provide data confidentiality service. The main difference 746 between authentication services provided by ESP and AH is the 747 extent of the coverage; ESP does not protect IP header fields 748 unless they are encapsulated by AH. 750 $ authentication exchange 751 (I) A mechanism to verify the identity of an entity by means of 752 information exchange. 754 (O) "A mechanism intended to ensure the identity of an entity by 755 means of information exchange." [I7498 Part 2] 757 $ authentication information 758 (I) Information used to verify an identity claimed by or for an 759 entity. (See: authentication, credential.) 761 (C) Authentication information may exist as, or be derived from, 762 one of the following: 764 - Something the entity knows. (See: password). 765 - Something the entity possesses. (See: token.) 766 - Something the entity is. (See: biometric authentication.) 768 $ authentication service 769 (I) A security service that verifies an identity claimed by or for 770 an entity. (See: authentication.) 772 (C) In a network, there are two general forms of authentication 773 service: data origin authentication service and peer entity 774 authentication service. 776 $ authenticity 777 (I) The property of being genuine and able to be verified and be 778 trusted. (See: authenticate, authentication, validate vs. verify) 780 $ authority 781 (D) "An entity, responsible for the issuance of certificates." 782 [FPDAM] 784 (C) ISPDs SHOULD NOT use this term as a synonym for either AA, CA, 785 RA, ORA, or similar terms, because it may cause confusion. 786 Instead, if it is necessary to shorten text, use abbreviations 787 defined in this Glossary. 789 (C) ISPDs SHOULD NOT use this definition for any PKI entity, 790 because the definition is ambiguous with regard to whether the 791 entity actually issues certificates (see: attribute authority, 792 certification authority) or just has responsibility for part of 793 the processes that precede or follow issuance (see: registration 794 authority). (See: issue.) 796 $ authority certificate 797 (D) "A certificate issued to an authority (e.g. either to a 798 certification authority or to an attribute authority)." [FPDAM] 799 (See: authority.) 801 (C) ISPDs SHOULD NOT use this term or definition because they are 802 with regard to which specific types of PKI entities they address. 804 $ authority revocation list (ARL) 805 (I) A data structure that enumerates digital certificates that 806 were issued to certification authorities but have been invalidated 807 by their issuer prior to when they were scheduled to expire (see: 808 certificate expiration). (See: X.509 authority revocation list.) 810 (O) "A revocation list containing a list of public-key 811 certificates issued to authorities, which are no longer considered 812 valid by the certificate issuer." [FPDAM] 814 $ authorize 815 $ authorization 816 (I) (1.) To "authorize" means to grant a right or permission to a 817 system entity to access a system resource. (2.) An "authorization" 818 is a right or a permission that is granted. (See: privilege.) (3.) 819 An "authorization process" is a procedure for granting such 820 rights. 822 (O) SET usage: "The process by which a properly appointed person 823 or persons grants permission to perform some action on behalf of 824 an organization. This process assesses transaction risk, confirms 825 that a given transaction does not raise the account holder's debt 826 above the account's credit limit, and reserves the specified 827 amount of credit. (When a merchant obtains authorization, payment 828 for the authorized amount is guaranteed--provided, of course, that 829 the merchant followed the rules associated with the authorization 830 process.)" [SET2] 832 $ automated information system 833 (I) An organized assembly of resources and procedures--i.e., 834 computing and communications equipment and services, with their 835 supporting facilities and personnel--that collect, record, 836 process, store, transport, retrieve, or display information to 837 accomplish a specified set of functions. 839 $ availability 840 (I) The property of a system or a system resource being accessible 841 and usable upon demand by an authorized system entity, according 842 to performance specifications for the system; i.e., a system is 843 available if it provides services according to the system design 844 whenever users request them. (See: critical, denial of service, 845 reliability, survivability.) 846 (O) "The property of being accessible and usable upon demand by an 847 authorized entity." [I7498 Part 2] 849 $ availability service 850 (I) A security service that protects a system to ensure its 851 availability. 853 (C) This service addresses the security concerns raised by denial- 854 of-service attacks. It depends on proper management and control of 855 system resources, and thus depends on access control service and 856 other security services. 858 $ back door 859 (I) A hardware or software mechanism that (a) provides access to a 860 system and its resources by other than the usual procedure, (b) 861 was deliberately left in place by the system's designers or 862 maintainers, and (c) usually is not publicly known. (See: trap 863 door.) 865 (C) For example, a way to access a computer other than through the 866 legitimate login procedure. Such security holes do not necessarily 867 have malicious intent; e.g., operating systems sometimes are 868 shipped by the manufacturer with privileged accounts intended for 869 use by field service technicians or the vendor's maintenance 870 programmers. (See: trap door.) 872 $ back up vs. backup 873 (I) Verb "back up": To store data for the purpose of creating a 874 backup copy. (Compare with: archive.) 876 (I) Noun/adjective "backup": (1.) A reserve copy of data that is 877 stored separately from the original, for use if the original 878 becomes lost or damaged. (Compare with: archive.) (2.) Alternate 879 means to permit performance of system functions despite a disaster 880 to system resources. (See: contingency plan.) 882 $ baggage 883 (D) ISPDs SHOULD NOT use this term to describe a data element 884 except when stated as "SET(trademark) baggage" with the following 885 meaning: 887 (O) SET usage: An "opaque encrypted tuple, which is included in a 888 SET message but appended as external data to the PKCS encapsulated 889 data. This avoids superencryption of the previously encrypted 890 tuple, but guarantees linkage with the PKCS portion of the 891 message." [SET2] 893 $ bandwidth 894 (I) Commonly used to mean the capacity of a communication channel 895 to pass data through the channel in a given amount of time. 896 (Usually expressed in bits per second.) 898 $ bank identification number (BIN) 899 (I) The digits of a credit card number that identify the issuing 900 bank. (See: primary account number.) 902 (O) SET usage: The first six digits of a primary account number. 904 $ Basic Encoding Rules (BER) 905 (I) A standard for representing ASN.1 data types as strings of 906 octets (eight-bit values) [X690]. (See: Distinguished Encoding 907 Rules.) 909 $ bastion host 910 (I) A strongly protected computer that is in a network protected 911 by a firewall (or is part of a firewall) and is the only host (or 912 one of only a few hosts) in the network that can be directly 913 accessed from networks on the other side of the firewall. 915 (C) Filtering routers in a firewall typically restrict traffic 916 from the outside network to reaching just one host, the bastion 917 host, which usually is part of the firewall. Since only this one 918 host can be directly attacked, only this one host needs to be very 919 strongly protected, so security can be maintained more easily and 920 less expensively. However, to allow legitimate internal and 921 external users to access application resources through the 922 firewall, higher layer protocols and services need to be relayed 923 and forwarded by the bastion host. Some services have forwarding 924 built in (like DNS or SMTP); other services (like TELNET and FTP) 925 require a proxy server on the bastion host. 927 $ BCA 928 See: brand certification authority. 930 $ BCI 931 See: brand CRL identifier. 933 $ Bell-LaPadula Model 934 (N) A formal, mathematical, state-transition model of security 935 policy for multilevel-secure computer systems, devised by David 936 Bell and Leonard LaPadula at The MITRE Corporation in 1973. 938 (C) The model separates computer system elements into a set of 939 subjects and a set of objects. To determine whether or not a 940 subject is authorized for a particular access mode on an object, 941 the clearance of the subject is compared to the classification of 942 the object. The model defines the notion of a "secure state", in 943 which the only permitted access modes of subjects to objects are 944 in accordance with a specified security policy. It is proven that 945 each state transition preserves security by moving from secure 946 state to secure state, thereby proving that the system is secure. 948 (C) In this model, a multilevel-secure system satisfies several 949 rules, including the following: 951 - "Confinement property" (also called "*-property", pronounced 952 "star property"): A subject has write access to an object only 953 if classification of the object dominates the clearance of the 954 subject. 956 - "Simple security property": A subject has read access to an 957 object only if the clearance of the subject dominates the 958 classification of the object. 960 - "Tranquillity property": The classification of an object does 961 not change while the object is being processed by the system. 963 $ BER 964 See: Basic Encoding Rules. 966 $ beyond A1 967 (O) A level of trust that is beyond the highest level of criteria 968 specified by the TCSEC. That is, a level of security that is so 969 high as not be verifiable by currently available formal methods. 971 $ BIN 972 See: bank identification number. 974 $ bind 975 (I) To inseparably associate by applying some mechanism, such as 976 when a CA uses a digital signature to bind together a subject and 977 a public key in a public-key certificate. 979 $ biometric authentication 980 (I) A method of generating authentication information for a person 981 by digitizing measurements of a physical characteristic, such as 982 fingerprint patterns, hand shape, retina pattern, speech sounds, 983 or handwriting pattern. 985 $ bit 986 (I) The smallest unit of information storage; a contraction of the 987 term "binary digit"; one of two symbols--"0" (zero) and "1" (one) 988 --that are used to represent binary numbers. 990 $ BLACK 991 (I) Designation for information system equipment or facilities 992 that handle (and for data that contains) only ciphertext (or, 993 depending on the context, only unclassified information), and for 994 such data itself. This term derives from U.S. Government COMSEC 995 terminology. (Compare with: RED. Also see: RED/BLACK separation.) 997 $ block cipher 998 (I) An encryption algorithm that breaks plaintext into fixed-size 999 segments and uses the same key to transform each plaintext segment 1000 into a fixed-size segment of ciphertext. (See: mode, stream 1001 cipher.) 1003 (C) For example, Blowfish, DEA, IDEA, RC2, and SKIPJACK. However, 1004 a block cipher can be adapted to have a different external 1005 interface, such as that of a stream cipher, by using a mode of 1006 operation to "package" the basic algorithm. 1008 $ Blowfish 1009 (N) A symmetric block cipher with variable-length key (32 to 448 1010 bits) designed in 1993 by Bruce Schneier [Schn] as an unpatented, 1011 license-free, royalty-free replacement for DES or IDEA. 1013 $ brand 1014 (I) A distinctive mark or name that identifies a product or 1015 business entity. 1017 (O) SET usage: The name of a payment card. Financial institutions 1018 and other companies have founded payment card brands, protect and 1019 advertise the brands, establish and enforce rules for use and 1020 acceptance of their payment cards, and provide networks to 1021 interconnect the financial institutions. These brands combine the 1022 roles of issuer and acquirer in interactions with cardholders and 1023 merchants. [SET1] 1025 $ brand certification authority (BCA) 1026 (O) SET usage: A CA owned by a payment card brand, such as 1027 MasterCard, Visa, or American Express. [SET2] (See: certification 1028 hierarchy, SET.) 1030 $ brand CRL identifier (BCI) 1031 (O) SET usage: A digitally signed list, issued by the BCA, of the 1032 names of CAs for which CRLs need to be processed when verifying 1033 signatures in SET messages. [SET2] 1035 $ break 1036 (I) Cryptographic usage: To successfully perform cryptanalysis and 1037 thus succeed in decrypting data or performing some other 1038 cryptographic function, without initially having knowledge of the 1039 key that the function requires. (This term applies to encrypted 1040 data or, more generally, to a cryptographic algorithm or 1041 cryptographic system.) 1043 $ bridge 1044 (I) A computer that is a gateway between two networks (usually two 1045 LANs) at OSI layer 2. (Compare with: router.) 1047 $ British Standard 7799 1048 (N) Part 1 is a standard code of practice and provides guidance on 1049 how to secure an information system; Part 2 specifies the 1050 management framework, objectives, and control requirements for 1051 information security management systems [B7799]. The certification 1052 scheme works like ISO 9000. It is in use in the UK, the 1053 Netherlands, Australia, and New Zealand and might be proposed as 1054 an ISO standard or adapted to be part of the Common Criteria. 1056 $ browser 1057 (I) An client computer program that can retrieve and display 1058 information from servers on the World Wide Web. 1060 (C) For example, Netscape's Navigator and Communicator, and 1061 Microsoft's Explorer. 1063 $ brute force 1064 (I) A cryptanalysis approach or other kind of attack method 1065 involving an exhaustive procedure that tries all possibilities, 1066 one-by-one. 1068 (C) For example, for ciphertext where the analyst already knows 1069 the decryption algorithm, a brute force approach to finding the 1070 original plaintext is to decrypt the message with every possible 1071 key. 1073 $ BS7799 1074 See: British Standard 7799. 1076 $ byte 1077 (I) A fundamental unit of computer storage; the smallest 1078 addressable unit in a computer's architecture. Usually holds one 1079 character of information; and, today, usually means eight bits. 1080 (See: octet.) 1082 (C) Larger than a "bit", but smaller than a "word". Although 1083 usually eight bits today, was other sizes (e.g., six bits, nine 1084 bits) in earlier computer architectures. 1086 $ CA 1087 See: certification authority. 1089 $ CA certificate 1090 (I) "A [digital] certificate for one CA issued by another CA." 1091 [X509] 1093 (C) That is, a digital certificate whose holder is able to issue 1094 digital certificates. A v3 X.509 public-key certificate may have a 1095 "basicConstraints" extension containing a "cA" value that 1096 specifically "indicates whether or not the public key may be used 1097 to verify certificate signatures." 1099 $ call back 1100 (I) An authentication technique for terminals that remotely access 1101 a computer via telephone lines; the host system disconnects the 1102 caller and then calls back on a telephone number that was 1103 previously authorized for that terminal. 1105 $ capability 1106 (I) A token, usually an unforgeable data value (sometimes called a 1107 "ticket") that gives the bearer or holder the right to access a 1108 system resource. Possession of the token is accepted by a system 1109 as proof that the holder has been authorized to access the 1110 resource named or indicated by the token. (Compare with: access 1111 control list.) 1113 (C) This concept can be implemented as a digital certificate. 1114 (See: attribute certificate.) 1116 $ CAPI 1117 See: cryptographic application programming interface. 1119 $ CAPSTONE chip 1120 (N) An integrated circuit (the Mykotronx, Inc. MYK-82) with a Type 1121 II cryptographic processor that implements SKIPJACK, KEA, DSA, 1122 SHA, and basic mathematical functions to support asymmetric 1123 cryptography, and includes the key escrow feature of the CLIPPER 1124 chip. (See: FORTEZZA card.) 1126 $ card 1127 See: cryptographic card, FORTEZZA card, payment card, PC card, 1128 smart card, token. 1130 $ card backup 1131 See: token backup. 1133 $ card copy 1134 See: token copy. 1136 $ card restore 1137 See: token restore. 1139 $ cardholder 1140 (I) An entity that has been issued a card. 1142 (O) SET usage: "The holder of a valid payment card account and 1143 user of software supporting electronic commerce." [SET2] A 1144 cardholder is issued a payment card by an issuer. SET ensures that 1145 in the cardholder's interactions with merchants, the payment card 1146 account information remains confidential. [SET1] 1148 $ cardholder certificate 1149 (O) SET usage: A digital certificate that is issued to a 1150 cardholder upon approval of the cardholder's issuing financial 1151 institution and that is transmitted to merchants with purchase 1152 requests and encrypted payment instructions, carrying assurance 1153 that the account number has been validated by the issuing 1154 financial institution and cannot be altered by a third party. 1155 [SET1] 1157 $ cardholder certification authority (CCA) 1158 (O) SET usage: A CA responsible for issuing digital certificates 1159 to cardholders and operated on behalf of a payment card brand, an 1160 issuer, or another party according to brand rules. A CCA maintains 1161 relationships with card issuers to allow for the verification of 1162 cardholder accounts. A CCA does not issue a CRL but does 1163 distribute CRLs issued by root CAs, brand CAs, geopolitical CAs, 1164 and payment gateway CAs. [SET2] 1166 $ CAST 1167 (N) A design procedure for symmetric encryption algorithms, and a 1168 resulting family of algorithms, invented by C(arlisle) A(dams) and 1169 S(tafford) T(avares). [R2612] 1171 $ category 1172 (I) A grouping of sensitive information items to which a non- 1173 hierarchical restrictive security label is applied to increase 1174 protection of the data. (See: compartment.) 1176 $ CAW 1177 See: certification authority workstation. 1179 $ CBC 1180 See: cipher block chaining. 1182 $ CCA 1183 See: cardholder certification authority. 1185 $ CCITT 1186 (N) Acronym for French translation of International Telephone and 1187 Telegraph Consultative Committee. Now renamed ITU-T. 1189 $ CERT 1190 See: computer emergency response team. 1192 $ certificate 1193 (I) In common English usage, a document that attests to the truth 1194 of something or the ownership of something. 1196 (C) Security usage, see: digital certificate, X.509 certificate. 1198 (C) PKI usage, see: public-key certificate. 1200 $ certificate authority 1201 (D) This term looks like imprecise use of a term standardized by 1202 X.509 and, therefore, ISPDs SHOULD NOT use this term as a synonym 1203 for "certification authority". 1205 $ certificate chain 1206 (D) ISPDs SHOULD NOT use this term because it duplicates the 1207 meaning of a standardized term. Instead, use "certification path". 1209 $ certificate chain validation 1210 (D) ISPDs SHOULD NOT use this term because it duplicates the 1211 meaning of standardized terms and mixes concepts in a potentially 1212 misleading way. Instead, use "certificate validation" or "path 1213 validation", depending on what is meant. (See: validate vs. 1214 verify.) 1216 $ certificate creation 1217 (I) The act or process by which a CA sets the values of a digital 1218 certificate's data fields and signs it. (See: issue.) 1220 $ certificate expiration 1221 (I) The event that occurs when a certificate ceases to be valid 1222 because its assigned lifetime has been exceeded. (See: certificate 1223 revocation, validity period.) 1225 $ certificate extension 1226 See: extension. 1228 $ certificate holder 1229 (I) A system entity named as the subject of a digital certificate. 1231 $ certificate management 1232 (I) The functions that a CA may perform during the life cycle of a 1233 digital certificate, including the following: 1235 - Acquire and verify data items to bind into the certificate. 1236 - Encode and sign the certificate. 1237 - Store the certificate in a directory or repository. 1238 - Renew, rekey, and update the certificate. 1239 - Revoke the certificate and issue a CRL. 1241 (See: archive management, key management, security architecture, 1242 token management, certificate management.) 1244 $ certificate policy 1245 (I) "A named set of rules that indicates the applicability of a 1246 certificate to a particular community and/or class of application 1247 with common security requirements." [X509] (Compare with: 1248 certification practice statement.) 1250 (C) A certificate policy can help a certificate user decide 1251 whether a certificate should be trusted in a particular 1252 application. "For example, a particular certificate policy might 1253 indicate applicability of a type of certificate for the 1254 authentication of electronic data interchange transactions for the 1255 trading goods within a given price range." [R2527] 1257 (C) A v3 X.509 public-key certificate may have a 1258 "certificatePolicies" extension that lists certificate policies, 1259 recognized by the issuing CA, that apply to the certificate and 1260 govern its use. Each policy is denoted by an object identifier and 1261 may optionally have certificate policy qualifiers. 1263 (C) SET usage: Every SET certificate specifies at least one 1264 certificate policy, that of the SET root CA. SET uses certificate 1265 policy qualifiers to point to the actual policy statement and to 1266 add qualifying policies to the root policy. (See: SET qualifier.) 1268 $ certificate policy qualifier 1269 (I) Information that pertains to a certificate policy and is 1270 included in a "certificatePolicies" extension in a v3 X.509 1271 public-key certificate. 1273 $ certificate reactivation 1274 (I) The act or process by which a digital certificate, which a CA 1275 has designated for revocation but not yet listed on a CRL, is 1276 returned to the valid state. 1278 $ certificate rekey 1279 (I) The act or process by which an existing public-key certificate 1280 has its public key value changed by issuing a new certificate with 1281 a different (usually new) public key. (See: certificate renewal, 1282 certificate update, rekey.) 1284 (C) For an X.509 public-key certificate, the essence of rekey is 1285 that the subject stays the same and a new public key is bound to 1286 that subject. Other changes are made, and the old certificate is 1287 revoked, only as required by the PKI and CPS in support of the 1288 rekey. If changes go beyond that, the process is a "certificate 1289 update". 1291 (O) MISSI usage: To rekey a MISSI X.509 public-key certificate 1292 means that the issuing authority creates a new certificate that is 1293 identical to the old one, except the new one has a new, different 1294 KEA key; or a new, different DSS key; or new, different KEA and 1295 DSS keys. The new certificate also has a different serial number 1296 and may have a different validity period. A new key creation date 1297 and maximum key lifetime period are assigned to each newly 1298 generated key. If a new KEA key is generated, that key is assigned 1299 a new KMID. The old certificate remains valid until it expires, 1300 but may not be further renewed, rekeyed, or updated. 1302 $ certificate renewal 1303 (I) The act or process by which the validity of the data binding 1304 asserted by an existing public-key certificate is extended in time 1305 by issuing a new certificate. (See: certificate rekey, certificate 1306 update.) 1308 (C) For an X.509 public-key certificate, this term means that the 1309 validity period is extended but the binding of the public key to 1310 the subject and to other data items stays the same. The other data 1311 items are changed, and the old certificate is revoked, only as 1312 required by the PKI and CPS to support the renewal. If changes go 1313 beyond that, the process is a "certificate rekey" or "certificate 1314 update". 1316 $ certificate request 1317 (D) ISPDs SHOULD NOT use this term because it looks like imprecise 1318 use of a term standardized by PKCS #10 and used in PKIX. Instead, 1319 use "certification request". 1321 $ certificate revocation 1322 (I) The event that occurs when a CA declares that a previously 1323 valid digital certificate issued by that CA has become invalid; 1324 usually stated with a revocation date. 1326 (C) In X.509, a revocation is announced to potential certificate 1327 users by a CRL that mentions the certificate. Revocation and 1328 listing on a CRL is only necessary before certificate expiration. 1330 $ certificate revocation list (CRL) 1331 (I) A data structure that enumerates digital certificates that 1332 have been invalidated by their issuer prior to when they were 1333 scheduled to expire (see: certificate expiration). (See: X.509 1334 certificate revocation list.) 1336 (O) "A signed list indicating a set of certificates that are no 1337 longer considered valid by the certificate issuer. After a 1338 certificate appears on a CRL, it is deleted from a subsequent CRL 1339 after the certificateUs expiry. CRLs may be used to identify 1340 revoked public-key certificates or attribute certificates and may 1341 represent revocation of certificates issued to authorities or to 1342 users. The term CRL is also commonly used as a generic term 1343 applying to all the different types of revocation lists, including 1344 CRLs, ARLs, ACRLs, etc." [FPDAM] 1346 $ certificate revocation tree 1347 (I) A mechanism for distributing notice of certificate revocations 1348 (as an alternative to issuing a CRL), using a tree of hash results 1349 that is signed by the tree's issuer. 1351 $ certificate serial number 1352 (I) An integer value that (1) is associated with, and may be 1353 carried in, a digital certificate; (2) is assigned to the 1354 certificate by the certificate's issuer; and (3) is unique among 1355 all the certificates produced by that issuer. 1357 (O) "An integer value, unique within the issuing CA, which is 1358 unambiguously associated with a certificate issued by that CA. 1359 [X509] 1361 $ certificate status responder 1362 (N) FPKI usage: A trusted on-line server that acts for a CA to 1363 provide authenticated certificate status information to 1364 certificate users. [FPKI] 1366 $ certificate update 1367 (I) The act or process by which data items bound in an existing 1368 public-key certificate, especially authorizations granted to the 1369 subject, are changed by issuing a new certificate. (See: 1370 certificate rekey, certificate renewal.) 1372 (C) For an X.509 public-key certificate, the essence of this 1373 process is that fundamental changes are made in the data that is 1374 bound to the public key, such that it is necessary to revoke the 1375 old certificate. (Otherwise, the process is only a "certificate 1376 rekey" or "certificate renewal".) 1378 $ certificate user 1379 (I) A system entity that depends on the validity of information 1380 (such as another entity's public key value) provided by a digital 1381 certificate. (See: relying party.) 1383 (O) "An entity that needs to know, with certainty, the public key 1384 of another entity." [X509] 1386 (C) The system entity may be a human being or an organization, or 1387 a device or process under the control of a human or an 1388 organization. 1390 (D) ISPDs SHOULD NOT use this term as a synonym for the "subject" 1391 of a certificate. 1393 $ certificate validation 1394 (I) An act or process by which a certificate user establishes that 1395 the assertions made by a digital certificate can be trusted. (See: 1396 valid certificate, validate vs. verify.) 1398 (O) "The process of ensuring that a certificate is valid including 1399 possibly the construction and processing of a certification path, 1400 and ensuring that all certificates in that path have not expired 1401 or been revoked." [FPDAM] 1403 (C) To validate a certificate, a certificate user checks that the 1404 certificate is properly formed and signed and currently in force: 1406 - Signature: Employs the issuer's public key to verify the 1407 digital signature of the CA who issued the certificate in 1408 question. If the key is obtained from the issuer's own public- 1409 key certificate, that certificate also should be validated. 1410 That validation may lead to yet another certificate to be 1411 validated, and so on. Thus, in general, certificate validation 1412 involves discovering and validating a certification path. 1414 - Syntax and semantics: Parses the certificate's syntax and 1415 interprets its semantics, applying rules specified for and by 1416 its data fields, such as for critical extensions in an X.509 1417 certificate. 1419 - Currency and revocation: Verifies that the certificate is 1420 currently in force by checking that the current date and time 1421 are within the validity period (if that is specified in the 1422 certificate) and that the certificate is not listed on a CRL or 1423 otherwise announced as in valid. (CRLs themselves require a 1424 similar validation process.) 1426 $ certification 1427 (I) Information system usage: Technical evaluation (usually made 1428 in support of an accreditation action) of an information system's 1429 security features and other safeguards to establish the extent to 1430 which the system's design and implementation meet specified 1431 security requirements. [FP102] (See: accreditation.) 1433 (I) Digital certificate usage: The act or process of vouching for 1434 the truth and accuracy of the binding between data items in the 1435 certificate. (See: certify.) 1437 (I) Public key usage: The act or process of vouching for the 1438 ownership of a public key by issuing a public-key certificate that 1439 binds the key to the name of the entity that owns the key. (In 1440 addition to binding a key with a name, a public-key certificate 1441 may bind those items with other restrictive or explanatory data 1442 items; e.g., see: X.509 public-key certificate.) 1444 (O) SET usage: "The process of ascertaining that a set of 1445 requirements or criteria has been fulfilled and attesting to that 1446 fact to others, usually with some written instrument. A system 1447 that has been inspected and evaluated as fully compliant with the 1448 SET protocol by duly authorized parties and process would be said 1449 to have been certified compliant." [SET2] 1451 $ certification authority (CA) 1452 (I) An entity that issues digital certificates (especially X.509 1453 certificates) and vouches for the binding between the data items 1454 in a certificate. 1456 (O) "An authority trusted by one or more users to create and 1457 assign certificates. Optionally the certification authority may 1458 create the user's keys." [X509] 1460 (C) Certificate users depend on the validity of information 1461 provided by a certificate. Thus, a CA should be someone that 1462 certificate users trust, and usually holds an official position 1463 created and granted power by a government, a corporation, or some 1464 other organization. A CA is responsible for managing the life 1465 cycle of certificates (see: certificate management) and, depending 1466 on the type of certificate and the CPS that applies, may be 1467 responsible for the life cycle of key pairs associated with the 1468 certificates (see: key management). 1470 $ certification authority workstation (CAW) 1471 (I) A computer system that enables a CA to issue digital 1472 certificates and supports other certificate management functions 1473 as required. 1475 $ certification hierarchy 1476 (I) A tree-structured (loop-free) topology of relationships among 1477 CAs and the entities to whom the authorities issue public-key 1478 certificates. (See: hierarchical PKI.) 1480 (C) In this structure, one CA is the top CA, the highest level of 1481 the hierarchy. (See: root, top CA.) The top CA may issue public- 1482 key certificates to one or more additional CAs that form the 1483 second highest level. Each of these CAs may issue certificates to 1484 more CAs at the third highest level, and so on. The CAs at the 1485 bottom of the hierarchy issue certificates only to entities that 1486 are not CAs (see: end entity). Thus, all certification paths begin 1487 at the top CA and descend through one or more levels of other CAs. 1488 All certificate users base path validations on the top CA's public 1489 key. 1491 (O) MISSI usage: A MISSI certification hierarchy has three or four 1492 levels: 1494 - A CA at the highest level, the top CA, is a "policy approving 1495 authority". 1496 - A CA at the second-highest level is a "policy creation 1497 authority". 1498 - A CA at the third-highest level is a local authority called a 1499 "certification authority". 1500 - A CA at the fourth-highest (optional) level is a "subordinate 1501 certification authority". 1503 (O) PEM usage: A PEM certification hierarchy has three levels 1504 [R1422]: 1506 - The highest level is the "Internet Policy Registration 1507 Authority". 1508 - A CA at the second-highest level is a "policy certification 1509 authority". 1510 - A CA at the third-highest level is a "certification authority". 1512 (O) SET usage: A SET certification hierarchy has three or four 1513 levels: 1515 - The highest level is a "SET root CA". 1516 - A CA at the second-highest level is a "brand certification 1517 authority". 1518 - A CA at the third-highest (optional) level is a "geopolitical 1519 certification authority". 1521 - A CA at the fourth-highest level is a "cardholder CA", a 1522 "merchant CA", or a "payment gateway CA". 1524 $ certification path 1525 (I) An ordered sequence of public-key certificates (or a sequence 1526 of public-key certificates followed by one attribute certificate) 1527 that enables a certificate user to verify the signature on the 1528 last certificate in the path, and thus enables the user to obtain 1529 a certified public key (or certified attributes) of the entity 1530 that is the subject of that last certificate. (See: certificate 1531 validation, valid certificate.) 1533 (O) "An ordered sequence of certificates of objects in the [X.500 1534 Directory Information Tree] which, together with the public key of 1535 the initial object in the path, can be processed to obtain that of 1536 the final object in the path." [X509, R2527] 1538 (C) The path is the "list of certificates needed to allow a 1539 particular user to obtain the public key of another." [X509] The 1540 list is "linked" in the sense that the digital signature of each 1541 certificate (except the first) is verified by the public key 1542 contained in the preceding certificate; i.e., the private key used 1543 to sign a certificate and the public key contained in the 1544 preceding certificate form a key pair owned by the entity that 1545 signed. 1547 (C) In the X.509 quotation in the previous "C" paragraph, the word 1548 "particular" points out that a certification path that can be 1549 validated by one certificate user might not be able to be 1550 validated by another. (See: certificate validation.) That is 1551 because either the first certificate should be a trusted 1552 certificate (it might be a root certificate) or the signature on 1553 the first certificate should be verified by a trusted key (it 1554 might be a root key), and that such trust is relative to the user. 1556 $ certification policy 1557 (D) ISPDs SHOULD NOT use this term. Instead, use either 1558 "certificate policy" or "certification practice statement", 1559 depending on what is meant. 1561 $ certification practice statement (CPS) 1562 (I) "A statement of the practices which a certification authority 1563 employs in issuing certificates." [ABA96, R2527] (Compare with: 1564 certificate policy.) 1566 (C) A CPS is a published security policy that can help a 1567 certificate user to decide whether a certificate issued by a 1568 particular CA can be trusted enough to use in a particular 1569 application. A CPS may be (a) a declaration by a CA of the details 1570 of the system and practices it employs in its certificate 1571 management operations, (b) part of a contract between the CA and 1572 an entity to whom a certificate is issued, (c) a statute or 1573 regulation applicable to the CA, or (d) a combination of these 1574 types involving multiple documents. [ABA] 1576 (C) A CPS is usually more detailed and procedurally oriented than 1577 a certificate policy. A CPS applies to a particular CA or CA 1578 community, while a certificate policy applies across CAs or 1579 communities. A CA with a single CPS may support multiple 1580 certificate policies, which may be used for different application 1581 purposes or by different user communities. Multiple CAs, each with 1582 a different CPS, may support the same certificate policy. [R2527] 1584 $ certification request 1585 (I) A algorithm-independent transaction format, defined by PCKS 1586 #10 and used in PKIX, that contains a DN, a public key, and 1587 optionally a set of attributes, collectively signed by the entity 1588 requesting certification, and sent to a CA, which transforms the 1589 request to an X.509 public-key certificate or another type of 1590 certificate. 1592 $ certify 1593 1. (I) Issue a digital certificate and thus vouch for the truth, 1594 accuracy, and binding between data items in the certificate (e.g., 1595 see: X.509 public key certificate), such as the identity of the 1596 certificate's subject and the ownership of a public key. (See: 1597 certification.) 1599 (C) To "certify a public key" means to issue a public-key 1600 certificate that vouches for the binding between the certificate's 1601 subject and the key. 1603 2. (I) The act by which a CA employs measures to verify the truth, 1604 accuracy, and binding between data items in a digital certificate. 1606 (C) A description of the measures used for verification should be 1607 included in the CA's CPS. 1609 $ CFB 1610 See: cipher feedback. 1612 $ Challenge Handshake Authentication Protocol (CHAP) 1613 (I) A peer entity authentication method for PPP, using a randomly- 1614 generated challenge and requiring a matching response that depends 1615 on a cryptographic hash of the challenge and a secret key. [R1994] 1616 (See: challenge-response, PAP.) 1618 $ challenge-response 1619 (I) An authentication process that verifies an identity by 1620 requiring correct authentication information to be provided in 1621 response to a challenge. In a computer system, the authentication 1622 information is usually a value that is required to be computed in 1623 response to an unpredictable challenge value. 1625 $ Challenge-Response Authentication Mechanism (CRAM) 1626 (I) IMAP4 usage: A mechanism [R2195], intended for use with IMAP4 1627 AUTHENTICATE, by which an IMAP4 client uses a keyed hash [RFC2104] 1628 to authenticate itself to an IMAP4 server. (See: POP3 APOP.) 1630 (C) The server includes a unique timestamp in its ready response 1631 to the client. The client replies with the client's name and the 1632 hash result of applying MD5 to a string formed from concatenating 1633 the timestamp with a shared secret that is known only to the 1634 client and the server. 1636 $ channel 1637 (I) An information transfer path within a system. (See: covert 1638 channel.) 1640 $ checksum 1641 (I) A value that (a) is computed by a function that is dependent 1642 on the contents of a data set and (b) is stored or transmitted 1643 together with the data, for the purpose of detecting changes in 1644 the data. (See: cyclic redundancy check, data integrity service, 1645 error detection code, hash, keyed hash, protected checksum.) 1647 (C) To gain confidence that a data set has not been changed, an 1648 entity that later uses the data can compute a checksum and compare 1649 it with the checksum that was stored or transmitted with the data. 1651 (C) Computer systems and networks employ checksums (and other 1652 mechanisms) to detect accidental changes in data. However, active 1653 wiretapping that changes data could also change an accompanying 1654 checksum to match the changed data. Thus, some checksum functions 1655 by themselves are not good countermeasures for active attacks. To 1656 protect against active attacks, the checksum function needs to be 1657 well-chosen (see: cryptographic hash), and the checksum result 1658 needs to be protected (see: digital signature, keyed hash). 1660 $ chosen-ciphertext attack 1661 (I) A cryptanalysis approach in which the analyst tries to 1662 determine the key from knowledge of plaintext that corresponds to 1663 ciphertext selected (dictated) by the analyst. 1665 $ chosen-plaintext attack 1666 (I) A cryptanalysis approach in which the analyst tries to 1667 determine the key from knowledge of ciphertext that corresponds to 1668 plaintext selected (dictated) by the analyst. 1670 $ CIAC 1671 See: Computer Incident Advisory Capability. 1673 $ CIK 1674 See: cryptographic ignition key. 1676 $ cipher 1677 (I) A cryptographic algorithm for encryption and decryption. 1679 $ cipher block chaining (CBC) 1680 (I) An block cipher mode that enhances electronic codebook mode by 1681 chaining together blocks of ciphertext it produces [FP081] (See: 1682 [R1829, R2451].) 1684 (C) This mode operates by combining (exclusive OR-ing) the 1685 algorithm's ciphertext output block with the next plaintext block 1686 to form the next input block for the algorithm. 1688 $ cipher feedback (CFB) 1689 (I) An block cipher mode that enhances electronic code book mode 1690 by chaining together the blocks of ciphertext it produces and 1691 operating on plaintext segments of variable length less than or 1692 equal to the block length [FP081]. 1694 (C) This mode operates by using the previously generated 1695 ciphertext segment as the algorithm's input (i.e., by "feeding 1696 back" the ciphertext) to generate an output block, and then 1697 combining (exclusive OR-ing) that output block with the next 1698 plaintext segment (block length or less) to form the next 1699 ciphertext segment. 1701 $ ciphertext 1703 (I) Data that has been transformed by encryption so that its 1704 semantic information content (i.e., its meaning) is no longer 1705 intelligible or directly available. (See: cleartext, plaintext.) 1707 (O) "Data produced through the use of encipherment. The semantic 1708 content of the resulting data is not available." [I7498 Part 2] 1710 $ ciphertext-only attack 1711 (I) A cryptanalysis approach in which the analyst tries to 1712 determine the key solely from knowledge of intercepted ciphertext 1713 (although the analyst may also know other clues, such as the 1714 cryptographic algorithm, the language in which the plaintext was 1715 written, the subject matter of the plaintext, and some probable 1716 plaintext words.) 1718 $ CIPSO 1719 See: Common IP Security Option. 1721 $ CKL 1722 See: compromised key list. 1724 $ class 2, 3, 4, or 5 1725 (O) U.S. Department of Defense usage: Levels of assurance based on 1726 risk and value of information to be protected [DOD3]: 1728 - Class 2: For handling low-value information (unclassified, not 1729 mission-critical, or low monetary value) or protection of 1730 system-high information in low- to medium-risk environment. 1732 - Class 3: For handling medium-value information in low- to 1733 medium-risk environment. Typically requires identification of a 1734 system entity as a legal person, rather than merely a member of 1735 an organization. 1737 - Class 4: For handling medium- to high-value information in any 1738 environment. Typically requires identification of an entity as 1739 a legal person, rather than merely a member of an organization, 1740 and a cryptographic hardware token for protection of keying 1741 material. 1743 - Class 5: For handling high-value information in a high-risk 1744 environment. 1746 $ classification 1747 $ classification level 1748 (I) (1.) A grouping of classified information to which a 1749 hierarchical, restrictive security label is applied to increase 1750 protection of the data. (2.) The level of protection that is 1751 required to be applied to that information. (See: security level.) 1753 $ classified 1754 (I) Refers to information (stored or conveyed, in any form) that 1755 is formally required by a security policy to receive data 1756 confidentiality service and to be marked with a security label 1757 (which in some cases might be implicit) to indicate its protected 1758 status. (See: unclassified.) 1760 (C) The term is mainly used in government, especially in the 1761 military, although the concept underlying the term also applies 1762 outside government. In the U.S. Department of Defense, for 1763 example, it means information that has been determined pursuant to 1764 Executive Order 12958 ("Classified National Security Information", 1765 13 December 1996) or any predecessor order to require protection 1766 against unauthorized disclosure and is marked to indicate its 1767 classified status when in documentary form. 1769 $ clean system 1770 (I) A computer system in which the operating system and 1771 application system software and files have just been freshly 1772 installed from trusted software distribution media. 1774 (C) A clean system is not necessarily in a secure state. 1776 $ clearance 1777 $ clearance level 1778 (I) The security level of information to which a security 1779 clearance authorizes a person to have access. 1781 $ cleartext 1782 (I) Data in which the semantic information content (i.e., the 1783 meaning) is intelligible or is directly available. (Compare with: 1784 plaintext.) 1786 (O) "Intelligible data, the semantic content of which is 1787 available." [I7498 Part 2] 1789 (D) ISPDs SHOULD NOT use this term loosely as a synonym for 1790 "plaintext", the input to an encryption operation, because the 1791 plaintext input to encryption may itself be ciphertext that was 1792 output from another operation. (See: superencryption.) 1794 $ client 1795 (I) A system entity that requests and makes use of a service 1796 provided by another system entity, which is called a server. 1798 (C) Usually, the requesting entity is a computer process, and it 1799 makes the request on behalf of a human user. In some cases, the 1800 server may itself be a client of some other server. 1802 $ CLIPPER chip 1803 (N) The Mykotronx, Inc. MYK-82, an integrated microcircuit with a 1804 cryptographic processor that implements the SKIPJACK encryption 1805 algorithm and supports key escrow. (See: CAPSTONE, Escrowed 1806 Encryption Standard.) 1808 (C) The key escrow scheme involves a SKIPJACK key common to all 1809 chips, a serial number unique to the chip, and a second SKIPJACK 1810 key that is unique to the chip and unlocks all data encrypted by 1811 the chip. The second key is escrowed as split key components held 1812 by NIST and the U.S. Treasury Department. 1814 $ closed security environment 1815 (O) DoD usage: A system environment that meets both of the 1816 following conditions: (a) Application developers (including 1817 maintainers) have sufficient clearances and authorizations to 1818 provide an acceptable presumption that they have not introduced 1819 malicious logic. (b) Configuration control provides sufficient 1820 assurance that system applications and the equipment they run on 1821 are protected against the introduction of malicious logic prior to 1822 and during the operation of applications. [NCS04] (See: open 1823 security environment.) 1825 $ code 1826 (I) noun: A system of symbols used to represent information, which 1827 might originally have some other representation. (See: encode.) 1829 (D) ISPDs SHOULD NOT use this term as synonym for the following: 1830 - Nouns: (1) "cipher" or other forms of "cryptographic 1831 algorithm", (2) "ciphertext". 1833 - Verbs: "encrypt". 1835 (D) ISPDs SHOULD NOT this word as an abbreviation for the 1836 following terms: authentication code, country code, cyclic 1837 redundancy code, source code, data authentication code, error 1838 detection code, hash code, manipulation detection code, message 1839 authentication code, message integrity code 1841 $ color change 1842 (I) In a system that is being operated in periods processing mode, 1843 the act of purging all information from one processing period and 1844 then changing over to the next processing period. 1846 $ Common Criteria 1847 $ Common Criteria for Information Technology Security 1848 (N) "The Common Criteria" is an ISO standard for evaluating 1849 information technology products and systems, such as operating 1850 systems, computer networks, distributed systems, and applications. 1851 It states requirements for security functions and for assurance 1852 measures. 1854 (C) Canada, France, Germany, the Netherlands, the United Kingdom, 1855 and the United States (NIST and NSA) began developing this 1856 standard in 1993, based on the European ITSEC, the Canadian 1857 Trusted Computer Product Evaluation Criteria (CTCPEC), and the 1858 U.S. "Federal Criteria for Information Technology Security" (FC) 1859 and its precursor, the TCSEC. The U.S. Government intends that 1860 this standard will supersede both the TCSEC and FIPS PUB 140-1. 1861 (See: NIAP.) 1863 (C) The standard addresses data confidentiality, data integrity, 1864 and availability and may apply to other aspects of security. It 1865 focuses on threats to information arising from human activities, 1866 malicious or otherwise, but may apply to non-human threats. It 1867 applies to security measures implemented in hardware, firmware, or 1868 software. It does not apply to (a) administrative security not 1869 related directly to technical security, (b) technical physical 1870 aspects of security such as electromagnetic emanation control, (c) 1871 evaluation methodology or administrative and legal framework under 1872 which the criteria may be applied, (d) procedures for use of 1873 evaluation results, or (e) assessment of inherent qualities of 1874 cryptographic algorithms. 1876 (C) Work was done in cooperation with ISO/IEC Joint Technical 1877 Committee 1 (Information Technology), Subcommittee 27 (Security 1878 Techniques), Working Group 3 (Security Criteria). Version 2.0 of 1879 the Criteria [CCIB] is equivalent to International Standard 15408. 1881 $ Common IP Security Option (CIPSO) 1882 See: (secondary definition in) Internet Protocol Security Option. 1884 $ common name 1885 (I) A character string that (a) may be a part of the X.500 DN of a 1886 Directory object ("commonName" attribute), (b) is a (possibly 1887 ambiguous) name by which the object is commonly known in some 1888 limited scope (such as an organization), and (c) conforms to the 1889 naming conventions of the country or culture with which it is 1890 associated. [X520] (See: ("subject" and "issuer" in) X.509 public- 1891 key certificate.) 1893 (C) For example, "Dr. Albert Einstein", "The United Nations", or 1894 "12-th Floor Laser Printer". 1896 $ communication security (COMSEC) 1897 (I) Measures that implement and assure security services in a 1898 communication system, particularly those that provide data 1899 confidentiality and data integrity and that authenticate 1900 communicating entities. 1902 (C) Usually understood to include cryptographic algorithms and key 1903 management methods and processes, devices that implement them, and 1904 the life cycle management of those keys and devices. 1906 $ community string 1907 (I) A community name in the form of an octet string that serves as 1908 a cleartext password in SNMP version 1 [R1157]. 1910 $ compartment 1911 (I) A grouping of sensitive information items that require special 1912 access controls beyond those normally provided for the basic 1913 classification level of the information. (See: category.) 1915 (C) The term is usually understood to include the special handling 1916 procedures to be used for the information. 1918 $ compromise 1919 See: data compromise, security compromise. 1921 $ compromised key list (CKL) 1922 (O) MISSI usage: A list that identifies keys for which 1923 unauthorized disclosure or alteration may have occurred. (See: 1924 data compromise.) 1926 $ COMPUSEC 1927 See: computer security. 1929 $ computer emergency response team (CERT) 1930 (I) An organization that studies computer and network INFOSEC in 1931 order to provide incident response services to victims of attacks, 1932 publish alerts concerning vulnerabilities and threats, and offer 1933 other information to help improve computer and network security. 1934 (See: CSIRT, security incident.) 1935 (C) For example, the CERT Coordination Center at Carnegie-Mellon 1936 University (sometimes called "the" CERT) and the Computer Incident 1937 Advisory Capability. 1939 $ Computer Incident Advisory Capability (CIAC) 1940 (N) A computer emergency response team in the U.S. Department of 1941 Energy. 1943 $ computer network 1944 (I) A collection of host computers together with the subnetwork or 1945 internetwork through which they can exchange data. 1947 (C) This definition is intended to cover systems of all sizes and 1948 types, ranging from the complex Internet to a simple system 1949 composed of a personal computer dialing in as a remote terminal of 1950 another computer. 1952 $ computer security (COMPUSEC) 1953 (I) Measures that implement and assure security services in a 1954 computer system, particularly those that assure access control 1955 service. 1957 (C) Usually understood to include functions, features, and 1958 technical characteristics of computer hardware and software, 1959 especially operating systems. 1961 $ computer security incident response team (CSIRT) 1962 (I) An organization "that coordinates and supports the response to 1963 security incidents that involve sites within a defined 1964 constituency." [R2350] (See: CERT, FIRST, security incident.) 1966 (C) To be considered a CSIRT, an organization must do as follows: 1968 - Provide a (secure) channel for receiving reports about 1969 suspected security incidents. 1970 - Provide assistance to members of its constituency in handling 1971 the incidents. 1972 - Disseminate incident-related information to its constituency 1973 and other involved parties. 1975 $ computer security object 1976 (I) The definition or representation of a resource, tool, or 1977 mechanism used to maintain a condition of security in computerized 1978 environments. Includes many elements referred to in standards that 1979 are either selected or defined by separate user communities. 1980 [CSOR] (See: object identifier, Computer Security Objects 1981 Register.) 1983 $ Computer Security Objects Register (CSOR) 1984 (N) A service operated by NIST is establishing a catalog for 1985 computer security objects to provide stable object definitions 1986 identified by unique names. The use of this register will enable 1987 the unambiguous specification of security parameters and 1988 algorithms to be used in secure data exchanges. 1990 (C) The CSOR follows registration guidelines established by the 1991 international standards community and ANSI. Those guidelines 1992 establish minimum responsibilities for registration authorities 1993 and assign the top branches of an international registration 1994 hierarchy. Under that international registration hierarchy the 1995 CSOR is responsible for the allocation of unique identifiers under 1996 the branch: {joint-iso-ccitt(2) country(16) us(840) gov(101) 1997 csor(3)}. 1999 $ COMSEC 2000 See: communication security. 2002 $ confidentiality 2003 See: data confidentiality. 2005 $ configuration control 2006 (I) The process of regulating changes to hardware, firmware, 2007 software, and documentation throughout the development and 2008 operational life of a system. (See: administrative security.) 2010 (C) Configuration control helps protect against unauthorized or 2011 malicious alteration of a system and thus provides assurance of 2012 system integrity. (See: malicious logic.) 2014 $ confinement property 2015 See: (secondary definition in) Bell-LaPadula Model. 2017 $ connectionless data integrity service 2018 (I) A security service that provides data integrity service for an 2019 individual IP datagram, by detecting modification of the datagram, 2020 without regard to the ordering of the datagram in a stream of 2021 datagrams. 2023 (C) A connection-oriented data integrity service would be able to 2024 detect lost or reordered datagrams within a stream of datagrams. 2026 $ contingency plan 2027 (I) A plan for emergency response, backup operations, and post- 2028 disaster recovery in a system as part of a security program to 2029 ensure availability of critical system resources and facilitate 2030 continuity of operations in a crisis. [NCS04] (See: availability.) 2032 $ controlled security mode 2033 (D) ISPDs SHOULD NOT use this term. It was defined in an earlier 2034 version of the U.S. Department of Defense policy that regulates 2035 system accreditation, but was subsumed by "partitioned security 2036 mode" in the current version. [DOD2] 2038 (C) The term refers to a mode of operation of an information 2039 system, wherein at least some users with access to the system have 2040 neither a security clearance nor a need-to-know for all classified 2041 material contained in the system; however, separation and control 2042 of users and classified material on the basis, respectively, of 2043 clearance and classification level are not essentially under 2044 operating system control as they are in "multilevel security 2045 mode". 2047 (C) This mode was intended to encourage ingenuity in meeting the 2048 security requirements of Defense policy in ways less restrictive 2049 than dedicated security mode and system high security mode, but at 2050 a level of risk lower than that generally associated with the true 2051 multilevel security mode. This was to be accomplished by 2052 implementation of explicit augmenting measures to reduce or remove 2053 a substantial measure of system software vulnerability together 2054 with specific limitation of the security clearance levels of users 2055 permitted concurrent access to the system. 2057 $ cookie 2058 (I) access control usage: A synonym for "capability" or "ticket" 2059 in an access control system. 2061 (I) IPsec usage: Data exchanged by ISAKMP to prevent certain 2062 denial of service attacks at the establishment of a security 2063 association. 2065 (I) HTTP usage: Data exchanged between an HTTP server and a 2066 browser (a client of the server) to store state information on the 2067 client side and retrieve it later for server use. 2069 (C) An HTTP server, when sending data to a client, may send along 2070 a cookie, which the client retains after the HTTP connection 2071 closes. A server can use this mechanism to maintain persistent 2072 client-side state information for HTTP-based applications, 2073 retrieving the state information in later connections. A cookie 2074 includes a description of the range of URLs for which the state is 2075 valid. Future requests made by the client in that range will also 2076 send the current value of the cookie to the server. Cookies can be 2077 used to generate profiles of web usage habits, and thus may 2078 infringe on personal privacy. 2080 $ Coordinated Universal Time (UTC) 2081 (N) UTC is derived from International Atomic Time (TAI) by adding 2082 a number of leap seconds. The International Bureau of Weights and 2083 Measures computes TAI once each month by averaging data from many 2084 laboratories. (See: GeneralizedTime, UTCTime.) 2086 $ copy 2087 See: card copy. 2089 $ correctness integrity 2090 (I) Accuracy and consistency of the information that data values 2091 represent, rather than of the data itself. Closely related to 2092 issues of accountability and error handling. (See: data integrity, 2093 source integrity.) 2095 $ correctness proof 2096 (I) A mathematical proof of consistency between a specification 2097 for system security and the implementation of that specification. 2098 (See: formal specification.) 2100 $ countermeasure 2101 (I) An action, device, procedure, or technique that reduces a 2102 threat, a vulnerability, or an attack by eliminating or preventing 2103 it, by minimizing the harm it can cause, or by discovering and 2104 reporting it so that corrective action can be taken. 2106 (C) In an Internet protocol, a countermeasure may take the form of 2107 a protocol feature, an element function, or a usage constraint. 2109 $ country code 2110 (I) An identifier that is defined for a nation by ISO. [I3166] 2112 (C) For each nation, ISO Standard 3166 defines a unique two- 2113 character alphabetic code, a unique three-character alphabetic 2114 code, and a 3-digit code. Among many uses of these codes, the two- 2115 character codes are used as top-level domain names. 2117 $ covert channel 2118 (I) A intra-system channel that permits two cooperating entities, 2119 without exceeding their access authorizations, to transfer 2120 information in a way that violates the system's security policy. 2121 (See: channel, out of band.) 2123 (O) "A communications channel that allows two cooperating 2124 processes to transfer information in a manner that violates the 2125 system's security policy." [NCS04] 2127 (C) The cooperating entities can be either two insiders or an 2128 insider and an outsider. Of course, an outsider has no access 2129 authorization at all. A covert channel is a system feature that 2130 the system architects neither designed nor intended for 2131 information transfer: 2133 - "Timing channel": A system feature that enable one system 2134 entity to signal information to another by modulating its own 2135 use of a system resource in such a way as to affect system 2136 response time observed by the second entity. 2138 - "Storage channel": A system feature that enables one system 2139 entity to signal information to another entity by directly or 2140 indirectly writing a storage location that is later directly or 2141 indirectly read by the second entity. 2143 $ CPS 2144 See: certification practice statement. 2146 $ cracker 2147 (I) Someone who tries to break the security of, and gain access 2148 to, someone else's system without being invited to do so. (See: 2149 hacker and intruder.) 2151 $ CRAM 2152 See: Challenge-Response Authentication Mechanism. 2154 $ CRC 2155 See: cyclic redundancy check. 2157 $ credential(s) 2158 (I) Data that is transferred or presented to establish either a 2159 claimed identity or the authorizations of a system entity. (See: 2160 authentication information.) 2162 (O) "Data that is transferred to establish the claimed identity of 2163 an entity." [I7498 Part 2] 2165 $ critical 2166 1. (I) "Critical" system resource: A condition of a service or 2167 other system resource such that denial of access to that resource 2168 would jeopardize a system user's ability to perform a primary 2169 function or would result in other serious consequences. (See: 2170 availability, sensitive.) 2172 2. (N) "Critical" extension: Each extension of an X.509 2173 certificate (or CRL) is marked as being either critical or non- 2174 critical. If an extension is critical and a certificate user (or 2175 CRL user) does not recognize the extension type or does not 2176 implement its semantics, then the user is required to treat the 2177 certificate (or CRL) as invalid. If an extension is non-critical, 2178 a user that does not recognize or implement that extension type is 2179 permitted to ignore the extension and process the rest of the 2180 certificate (or CRL). 2182 $ CRL 2183 See: certificate revocation list. 2185 $ CRL distribution point 2186 See: distribution point. 2188 $ CRL extension 2189 See: extension. 2191 $ cross-certificate 2192 See: cross-certification. 2194 $ cross-certification 2195 (I) The act or process by which two CAs each certify a public key 2196 of the other, issuing a public-key certificate to that other CA. 2198 (C) Cross-certificates enable two certificate users to validate 2199 each other's certificate, even when the users are certified under 2200 different certification hierarchies. 2202 $ cryptanalysis 2203 (I) The mathematical science that deals with analysis of a 2204 cryptographic system in order to gain knowledge needed to break or 2205 circumvent the protection that the system is designed to provide. 2206 (See: cryptology.) 2208 (O) "The analysis of a cryptographic system and/or its inputs and 2209 outputs to derive confidential variables and/or sensitive data 2210 including cleartext." [I7498 Part 2] 2212 (C) The "O" definition states the traditional goal of 2213 cryptanalysis--convert the ciphertext to plaintext (which usually 2214 is cleartext) without knowing the key--but that definition applies 2215 only to encryption systems. Today, the term is used with reference 2216 to all kinds of cryptographic algorithms and key management, and 2217 the "I" definition reflects that. In all cases, however, a 2218 cryptanalyst tries to uncover or reproduce someone else's 2219 sensitive data, such as cleartext, a key, or an algorithm. The 2220 basic cryptanalytic attacks on encryption systems are ciphertext- 2221 only, known-plaintext, chosen-plaintext, and chosen-ciphertext; 2222 and these generalize to the other kinds of cryptography. 2224 $ crypto 2225 (D) Except as part of certain long-established terms listed in 2226 this Glossary, ISPDs SHOULD NOT use this abbreviated term because 2227 it may be misunderstood. Instead, use "cryptography" or 2228 "cryptographic". 2230 $ cryptographic algorithm 2231 (I) An algorithm that employs the science of cryptography, 2232 including encryption algorithms, cryptographic hash algorithms, 2233 digital signature algorithms, and key agreement algorithms. 2235 $ cryptographic application programming interface (CAPI) 2236 (I) The source code formats and procedures through which an 2237 application program accesses cryptographic services, which are 2238 defined abstractly compared to their actual implementation. For 2239 example, see: PKCS #11, [R2628]. 2241 $ cryptographic card 2242 (I) A cryptographic token in the form of a smart card or a PC 2243 card. 2245 $ cryptographic component 2246 (I) A generic term for any system component that involves 2247 cryptography. (Compare with: cryptographic module.) 2249 $ cryptographic hash 2250 See: (secondary definition in) hash function. 2252 $ cryptographic ignition key (CIK) 2253 (I) A physical (usually electronic) token used to store, 2254 transport, and protect cryptographic keys. (Sometimes abbreviated 2255 as "crypto ignition key".) 2257 (C) A typical use is to divide a split key between a CIK and a 2258 cryptographic module, so that it is necessary to combine the two 2259 to regenerate a key-encrypting key and thus activate the module 2260 and other keys it contains. 2262 $ cryptographic key 2263 (I) Usually shortened to just "key". An input parameter that 2264 varies the transformation performed by a cryptographic algorithm. 2266 (O) "A sequence of symbols that controls the operations of 2267 encipherment and decipherment." [I7498 Part 2] 2269 (C) If a key value needs to be kept secret, the sequence of 2270 symbols (usually bits) that comprise it should be random, or at 2271 least pseudo-random, because that makes the key hard for an 2272 adversary to guess. (See: cryptanalysis, brute force attack.) 2274 $ Cryptographic Message Syntax (DMS) 2275 (I) A encapsulation syntax (R2630] for digital signatures, hashes, 2276 and encryption of arbitrary messages. 2278 (C) The syntax was derived from PKCS #7. CMS values are specified 2279 with ASN.1 and use BER encoding. The syntax permits multiple 2280 encapsulation with nesting, permits arbitrary attributes to be 2281 signed along with message content, and supports a variety of 2282 architectures for digital certificate-based key management. 2284 $ cryptographic module 2285 (I) A set of hardware, software, firmware, or some combination 2286 thereof that implements cryptographic logic or processes, 2287 including cryptographic algorithms, and is contained within the 2288 module's cryptographic boundary, which is an explicitly defined 2289 contiguous perimeter that establishes the physical bounds of the 2290 module. [FP140] 2292 $ cryptographic system 2293 (I) A set of cryptographic algorithms together with the key 2294 management processes that support the use of the algorithms in 2295 some application context. 2297 (C) This definition covers a wider range of algorithms than the 2298 following definition from X.509: 2300 (O) "A collection of transformations from plaintext into 2301 ciphertext and vice versa [which would exclude digital signature, 2302 cryptographic hash, and key agreement algorithms], the particular 2303 transformation(s) to be used being selected by keys. The 2304 transformations are normally defined by a mathematical algorithm." 2305 [X509] 2307 $ cryptographic token 2308 (I) A portable, user-controlled, physical device used to store 2309 cryptographic information and possibly perform cryptographic 2310 functions. (See: cryptographic card, token.) 2312 (C) A smart token may implement some set of cryptographic 2313 algorithms and may implement related algorithms and key management 2314 functions, such as a random number generator. A smart 2315 cryptographic token may contain a cryptographic module or may not 2316 be explicitly designed that way. 2318 $ cryptography 2319 (I) The mathematical science that deals with transforming data to 2320 render its meaning unintelligible (i.e., to hide its semantic 2321 content), prevent its undetected alteration, or prevent its 2322 unauthorized use. If the transformation is reversible, 2323 cryptography also deals with restoring encrypted data to 2324 intelligible form. (See: cryptology. Compare with: steganography.) 2326 (O) "The discipline which embodies principles, means, and methods 2327 for the transformation of data in order to hide its information 2328 content, prevent its undetected modification and/or prevent its 2329 unauthorized use. . . . Cryptography determines the methods used 2330 in encipherment and decipherment." [I7498 Part 2] 2332 $ Cryptoki 2333 See: (secondary definition in) PKCS #11. 2335 $ cryptology 2336 (I) The science that includes both cryptography and cryptanalysis, 2337 and sometimes is said to include steganography. 2339 $ cryptonet 2340 (I) A group of system entities that share a secret cryptographic 2341 key for a symmetric algorithm. 2343 $ cryptoperiod 2344 (I) The time span during which a particular key is authorized to 2345 be used in a cryptographic system. (See: key management.) 2347 (C) A cryptoperiod is usually stated in terms of calendar or clock 2348 time, but sometimes is stated in terms of the maximum amount of 2349 data permitted to be processed by a cryptographic algorithm using 2350 the key. Specifying a cryptoperiod involves a tradeoff between the 2351 cost of rekeying and the risk of successful cryptoanalysis. 2353 (C) Although we deprecate its prefix, this term is long- 2354 established in COMPUSEC usage. (See: crypto) In the context of 2355 certificates and public keys, "key lifetime" and "validity period" 2356 are often used instead. 2358 $ cryptosystem 2359 (D) ISPDs SHOULD NOT use this term as an abbreviation for 2360 cryptographic system. (For rationale, see: crypto.) 2362 $ CSIRT 2363 See: computer security incident response team. 2365 $ CSOR 2366 See: Computer Security Objects Register. 2368 $ cut-and-paste attack 2369 (I) An active attack on the data integrity of ciphertext, effected 2370 by replacing sections of ciphertext with other ciphertext, such 2371 that the result appears to decrypt correctly but actually decrypts 2372 to plaintext that is forged to the satisfaction of the attacker. 2374 $ cyclic redundancy check (CRC) 2375 (I) Sometimes called "cyclic redundancy code". A type of checksum 2376 algorithm that is not a cryptographic hash but is used to 2377 implement data integrity service where accidental changes to data 2378 are expected. 2380 $ DAC 2381 See: Data Authentication Code, discretionary access control. 2383 $ DASS 2384 See: Distributed Authentication Security Service. 2386 $ data 2387 (I) Information in a specific physical representation, usually a 2388 sequence of symbols that have meaning; especially a representation 2389 of information that can be processed or produced by a computer. 2391 $ Data Authentication Algorithm 2392 (N) A keyed hash function equivalent to DES cipher block chaining 2393 with IV = 0 [A9009]. 2395 (D) ISPDs SHOULD NOT use this term in an uncapitalized (i.e., 2396 lower case) form as a general synonym for other kinds of 2397 checksums. 2399 $ data authentication code vs. Data Authentication Code (DAC) 2400 1. (N) Capitalized: "The Data Authentication Code" refers to a 2401 U.S. Government standard [FP113] for a checksum that is computed 2402 by the Data Authentication Algorithm. (Also known as the ANSI 2403 standard Message Authentication Code [A9009].) 2405 2. (D) Not capitalized: ISPDs SHOULD NOT use "data authentication 2406 code" as a general synonym for other kinds of checksums, because 2407 this term mixes concepts in a potentially misleading way. Instead, 2408 use "checksum", "error detection code", "hash", "keyed hash", 2409 "Message Authentication Code", or "protected checksum", depending 2410 on what is meant. 2412 $ data compromise 2413 (I) A security incident in which information is exposed to 2414 potential unauthorized access, such that unauthorized disclosure, 2415 alteration, or use of the information may have occurred. (See: 2416 compromise.) 2418 $ data confidentiality 2419 (I) "The property that information is not made available or 2420 disclosed to unauthorized individuals, entities, or processes 2421 [i.e., to any unauthorized system entity]." [I7498 Part 2]. (See: 2422 data confidentiality service.) 2424 (D) ISPDs SHOULD NOT use this term as a synonym for "privacy", 2425 which is a different concept. 2427 $ data confidentiality service 2428 (I) A security service that protects data against unauthorized 2429 disclosure. (See: data confidentiality.) 2431 (D) ISPDs SHOULD NOT use this term as a synonym for "privacy", 2432 which is a different concept. 2434 $ Data Encryption Algorithm (DEA) 2435 (N) A symmetric (see: symmetric cryptography) block cipher that 2436 uses a 64-bit key, of which 56 bits are independently chosen and 8 2437 are parity bits. It maps a 64-bit block into another 64-bit block. 2438 [FP046] 2440 (C) This algorithm is usually referred to as "DES". (See: Data 2441 Encryption Standard.) The algorithm has also been adopted in 2442 standards outside the Government (e.g., [A3092]). 2444 $ data encryption key (DEK) 2445 (I) A cryptographic key that is used to encipher application data. 2446 (See: key-encrypting key.) 2448 $ Data Encryption Standard (DES) 2449 (N) A U.S. Government standard [FP046] that specifies the Data 2450 Encryption Algorithm and states policy for using the algorithm to 2451 protect unclassified, sensitive data. (See: AES.) 2453 $ data integrity 2454 (I) The property that data has not been changed, destroyed, or 2455 lost in an unauthorized or accidental manner. 2457 (O) "The property that information has not been modified or 2458 destroyed in an unauthorized manner." [I7498 Part 2] 2460 (C) Deals with constancy of and confidence in data values, not 2461 with the information that the values represent (see: correctness 2462 integrity) or the trustworthiness of the source of the values 2463 (see: source integrity). 2465 $ data integrity service 2466 (I) A security service that protects against unauthorized changes 2467 to data, including both intentional change or destruction and 2468 accidental change or loss, by ensuring that changes to data are 2469 detectable. (See: data integrity.) 2471 (C) A data integrity service can only detect a change and report 2472 it to an appropriate system entity; changes cannot be prevented 2473 unless the system is perfect (error-free) and no malicious user 2474 has access. However, a system that offers data integrity service 2475 might also attempt to correct and recover from changes. 2477 (C) Relationship between data integrity service and authentication 2478 services. Although data integrity service is defined separately 2479 from data origin authentication service and peer entity 2480 authentication service, it is closely related to them. 2481 Authentication services depend, by definition, on companion data 2482 integrity services. Data origin authentication service provides 2483 verification that the identity of the original source of a 2484 received data unit is as claimed; there can be no such 2485 verification if the data unit has been altered. Peer entity 2486 authentication service provides verification that the identity of 2487 a peer entity in a current association is as claimed; there can be 2488 no such verification if the claimed identity has been altered. 2490 $ data origin authentication 2491 (I) "The corroboration that the source of data received is as 2492 claimed." [I7498 Part 2] (See: authentication.) 2494 $ data origin authentication service 2495 (I) A security service that verifies the identity of a system 2496 entity that is claimed to be the original source of received data. 2497 (See: authentication, authentication service.) 2499 (C) This service is provided to any system entity that receives or 2500 holds the data. Unlike peer entity authentication service, this 2501 service is independent of any association between the originator 2502 and the recipient, and the data in question may have originated at 2503 any time in the past. 2505 (C) A digital signature mechanism can be used to provide this 2506 service, because an adversary, who does not know the private key 2507 of the signer, cannot forge the correct signature. However, by 2508 using the signer's public key, anyone can verify the origin of 2509 correctly signed data. 2511 (C) This service is usually bundled with connectionless data 2512 integrity service. (See: "relationship between data integrity 2513 service and authentication services" under data integrity service. 2515 $ data privacy 2516 (D) ISPDs SHOULD NOT use this term because it mix concepts in a 2517 potentially misleading way. Instead, use "data confidentiality" or 2518 "privacy", depending on what is meant. 2520 $ data security 2521 (I) The protection of data from disclosure, alteration, 2522 destruction, or loss that either is accidental or is intentional 2523 but unauthorized. 2525 (C) Both data confidentiality service and data integrity service 2526 are needed to achieve data security. 2528 $ datagram 2529 (I) "A self-contained, independent entity of data carrying 2530 sufficient information to be routed from the source to the 2531 destination." [R1983] 2533 $ DEA 2534 See: Data Encryption Algorithm. 2536 $ deception 2537 See: (secondary definition in) threat consequence. 2539 $ decipher 2540 (D) ISPDs SHOULD NOT use this term as a synonym for "decrypt". 2541 However, see the usage note under "encryption". 2543 $ decipherment 2544 (D) ISPDs SHOULD NOT use this term as a synonym for "decryption", 2545 except in special circumstances. (See: (usage discussion under) 2546 encryption.) 2548 $ decode 2549 (I) Convert encoded data back to its original form of 2550 representation. (Compare with: decrypt.) 2552 (D) ISPDs SHOULD NOT use this term as a synonym for "decrypt", 2553 because that would mix concepts in a potentially misleading way. 2555 $ decrypt 2556 (I) Cryptographically restore ciphertext to the plaintext form it 2557 had before encryption. 2559 $ decryption 2560 See: (secondary definition in) encryption. 2562 $ dedicated security mode 2563 (I) A mode of operation of an information system, wherein all 2564 users have the clearance or authorization, and the need-to-know, 2565 for all data handled by the system. In this mode, the system may 2566 handle either a single classification level or category of 2567 information or a range of levels and categories. 2569 (C) This mode is defined formally in U.S. Department of Defense 2570 policy regarding system accreditation [DOD2], but the term is also 2571 used outside the Defense Department and outside the Government. 2573 $ default account 2574 (I) A system login account (user name and password) that has been 2575 predefined in a manufactured system to permit initial access when 2576 the system is first put into service. 2578 (C) Sometimes, the default user name and password are the same in 2579 each copy of the system. In any case, when the system is put into 2580 service, the default password should immediately be changed or the 2581 default account should be disabled. 2583 $ degauss 2584 (N) Apply a magnetic field to permanently remove, erase, or clear 2585 data from a magnetic storage medium, such as a tape or disk 2586 [NCS25]. Reduce magnetic flux density to zero by applying a 2587 reversing magnetic field. 2589 $ degausser 2590 (N) An electrical device that can degauss magnetic storage media. 2592 $ DEK 2593 See: data encryption key. 2595 $ delta CRL 2596 (I) A partial CRL that only contains entries for X.509 2597 certificates that have been revoked since the issuance of a prior, 2598 base CRL. This method can be used to partition CRLs that become 2599 too large and unwieldy. 2601 $ denial of service 2602 (I) The prevention of authorized access to a system resource or 2603 the delaying of system operations and functions. (See: 2604 availability, critical (resource of a system), flooding.) 2606 $ DES 2607 See: Data Encryption Standard. 2609 $ dictionary attack 2610 (I) An attack that uses a brute-force approach of successively 2611 trying all the words in some large, exhaustive list. 2613 (C) For example, an attack on an authentication service by trying 2614 all possible passwords; or an attack on encryption by encrypting 2615 some known plaintext phrase with all possible keys so that the key 2616 for any given encrypted message containing that phrase may be 2617 obtained by lookup. 2619 $ Diffie-Hellman 2620 (N) A key agreement algorithm published in 1976 by Whitfield 2621 Diffie and Martin Hellman [DH76, R2631]. 2623 (C) Diffie-Hellman does key establishment, not encryption. 2624 However, the key that it produces may be used for encryption, for 2625 further key management operations, or for any other cryptography. 2627 (C) The difficulty of breaking Diffie-Hellman is considered to be 2628 equal to the difficulty of computing discrete logarithms modulo a 2629 large prime. The algorithm is described in [R2631] and [Schn]. In 2630 brief, Alice and Bob together pick large integers that satisfy 2631 certain mathematical conditions, and then use the integers to each 2632 separately compute a public-private key pair. They send each other 2633 their public key. Each person uses their own private key and the 2634 other person's public key to compute a key, k, that, because of 2635 the mathematics of the algorithm, is the same for each of them. 2636 Passive wiretapping cannot learn the shared k, because k is not 2637 transmitted, and neither are the private keys needed to compute k. 2638 However, without additional mechanisms to authenticate each party 2639 to the other, a protocol based on the algorithm may be vulnerable 2640 to a man-in-the-middle attack. 2642 $ digest 2643 See: message digest. 2645 $ digital certificate 2646 (I) A certificate document in the form of a digital data set (a 2647 data object used by a computer) to which is appended a computed 2648 digital signature value that depends on the data set. (See: 2649 attribute certificate, public-key certificate.) 2651 (D) ISPDs SHOULD NOT use this term to refer to a signed CRL or 2652 CKL. Although the recommended definition can be interpreted to 2653 include those items, the security community does not use the term 2654 with those meanings. 2656 $ digital certification 2657 (D) ISPDs use this term as a synonym for "certification", unless 2658 the context is not sufficient to distinguish between digital 2659 certification and another kind of certification, in which case it 2660 would be better to use "public-key certification" or another 2661 phrase that indicates what is being certified. 2663 $ digital document 2664 (I) An electronic data set that represents the information 2665 originally written in a document in a different medium (usually 2666 paper) or is an analogue of documents of that type. 2668 $ digital envelope 2669 (I) A digital envelope for a recipient is a combination of (a) 2670 encrypted content data (of any kind) and (b) the content 2671 encryption key in an encrypted form that has been prepared for the 2672 use of the recipient. 2674 (C) In ISPDs, this term should be defined at the point of first 2675 use because, although the term is defined in PKCS #7 and used in 2676 S/MIME, it is not yet widely-established. 2678 (C) Digital enveloping is not simply a synonym for implementing 2679 data confidentiality with encryption; digital enveloping is a 2680 hybrid encryption scheme to "seal" a message or other data, by 2681 encrypting the data and sending both it and a protected form of 2682 the key to the intended recipient, so that no one other than the 2683 intended recipient can "open" the message. In PCKS #7, it means 2684 first encrypting the data using a symmetric encryption algorithm 2685 and a secret key, and then encrypting the secret key using an 2686 asymmetric encryption algorithm and the public key of the intended 2687 recipient. In S/MIME, additional methods are defined for 2688 encrypting the content encryption key. 2690 $ Digital ID(service mark) 2691 (D) ISPDs SHOULD NOT use this term as a synonym for "digital 2692 certificate" because (a) it is the service mark of commercial 2693 firm, (b) it unnecessarily duplicates the meaning of other, well- 2694 established terms, and (c) a certificate is not always used as 2695 authentication information. In some contexts, however, it may be 2696 useful to explain that the key conveyed in a public-key 2697 certificate can be used to verify an identity and thus the 2698 certificate can be thought of as digital identification 2699 information. (See: identification information.) 2701 $ digital key 2702 (C) The adjective "digital" need not be used with "key" or 2703 "cryptographic key", unless the context is insufficient to 2704 distinguish the key from another kind of key, such as a metal key 2705 for a door lock. 2707 $ digital notary 2708 (I) Analogous to a notary public; provides a trusted date-and-time 2709 stamp for a document that proves the document existed at a point 2710 in time, and may also verify the signatures on a signed document. 2711 (See: notarization.) 2713 $ digital signature 2714 (I) A value computed with a cryptographic algorithm and appended 2715 to a data set in such a way that any recipient of the data can use 2716 the signature to verify the data's origin and integrity. (See: 2717 data origin authentication service, data integrity service, 2718 digitized signature, electronic signature, signer.) 2720 (I) "Data appended to, or a cryptographic transformation of, a 2721 data unit that allows a recipient of the data unit to prove the 2722 source and integrity of the data unit and protect against forgery, 2723 e.g. by the recipient." [I7498 Part 2] 2725 (C) Typically, the data set is first input to a hash function, and 2726 then the hash result is cryptographically transformed using a 2727 private key of the signer. The final resulting value is called the 2728 digital signature of the data set. The signature value is a 2729 protected checksum, because the properties of a cryptographic hash 2730 ensure that if the data set is changed, the digital signature will 2731 no longer match it. The digital signature is unforgeable because 2732 one cannot be certain of correctly creating or changing the 2733 signature without knowing the private key of the supposed signer. 2735 (C) Some digital signature schemes use an asymmetric encryption 2736 algorithms (e.g., see: RSA) to transform the hash result. Thus, 2737 when Alice needs to sign a message to send to Bob, she can encrypt 2738 the hash result using her private key. Bob receives both the 2739 message and the digital signature. Bob decrypts the signature 2740 using Alice's public key and compares the plaintext result to the 2741 hash result that he computes by hashing the message himself. If 2742 the values are equal, Bob accepts the message because he is 2743 certain that it is from Alice and has arrived unchanged. If the 2744 values are not equal, Bob rejects the message because either the 2745 message or the signature was altered in transit. 2747 (C) Other digital signature schemes (e.g., see: DSS) transform the 2748 hash result with an algorithm (e.g., see: DSA, El Gamal) that 2749 cannot be directly used to encrypt data. Such a scheme creates a 2750 signature value from the hash, and provides a way to verify the 2751 signature value, but does not provide a way to recover the hash 2752 result from the signature value. In some countries, such a scheme 2753 may improve exportability and avoid other legal constraints on 2754 usage. Alice sends the signature value to Bob along with both the 2755 message and its hash result. The algorithm enables Bob to use 2756 Alice's public signature key and the signature value to verify the 2757 hash result he receives. Then, as before, he compares that hash 2758 result she sent to the one that he computes by hashing the message 2759 himself. 2761 $ Digital Signature Algorithm (DSA) 2762 (N) An asymmetric cryptographic algorithm that produces a digital 2763 signature in the form of a pair of large numbers. The signature is 2764 computed using rules and parameters such that the identity of the 2765 signer and the integrity of the signed data can be verified. (See: 2766 Digital Signature Standard.) 2768 $ Digital Signature Standard (DSS) 2769 (N) The U.S. Government standard [FP186] that specifies the 2770 Digital Signature Algorithm (DSA), which involves asymmetric 2771 cryptography. 2773 $ digital watermarking 2774 (I) Computing techniques for inseparably embedding unobtrusive 2775 marks or labels as bits in digital data--text, graphics, images, 2776 video, or audio--and for detecting or extracting the marks later. 2778 (C) The set of embedded bits (the digital watermark) is sometimes 2779 hidden, usually imperceptible, and always intended to be 2780 unobtrusive. Depending on the particular technique that is used, 2781 digital watermarking can assist in proving ownership, controlling 2782 duplication, tracing distribution, ensuring data integrity, and 2783 performing other functions to protect intellectual property 2784 rights. [ACM] 2786 $ digitized signature 2787 (D) ISPDs SHOULD NOT use this term because there is no current 2788 consensus on its definition. Although it appears to be used mainly 2789 to refer to various forms of digitized images of handwritten 2790 signatures, the term should be avoided because it might be 2791 confused with "digital signature". 2793 $ directory 2794 $ Directory 2795 See: directory vs. Directory. 2797 $ Directory Access Protocol (DAP) 2798 (N) An OSI protocol [X519] for communication between a Directory 2799 User Agent (a client) and a Directory System Agent (a server). 2800 (See: Lightweight Directory Access Protocol.) 2802 $ directory vs. Directory 2803 1. (I) Not capitalized: The term "directory" refers generically to 2804 a database server or other system that provides information--such 2805 as a digital certificate or CRL--about an entity whose name is 2806 known. 2808 2. (I) Capitalized: "Directory" refers specifically to the X.500 2809 Directory. (See: repository.) 2811 $ disaster plan 2812 (D) A synonym for "contingency plan". In the interest of 2813 consistency, ISPDs SHOULD use "contingency plan" instead of 2814 "disaster plan". 2816 $ disclosure (i.e., unauthorized disclosure) 2817 See: (secondary definition in) threat consequence. 2819 $ discretionary access control (DAC) 2820 (I) An access control service that enforces a security policy 2821 based on the identity of system entities and their authorizations 2822 to access system resources. (See: access control list, identity- 2823 based security policy, mandatory access control.) 2825 (C) This service is termed "discretionary" because an entity might 2826 have access rights that permit the entity, by its own volition, to 2827 enable another entity to access some resource. 2829 (O) "A means of restricting access to objects based on the 2830 identity of subjects and/or groups to which they belong. The 2831 controls are discretionary in the sense that a subject with a 2832 certain access permission is capable of passing that permission 2833 (perhaps indirectly) on to any other subject." [DOD1] 2835 $ disruption 2836 See: (secondary definition in) threat consequence. 2838 $ Distinguished Encoding Rules (DER) 2839 (N) A subset of the Basic Encoding Rules, which gives exactly one 2840 way to represent any ASN.1 value as an octet string [X690]. 2842 (C) Since there is more than one way to encode ASN.1 in BER, DER 2843 is used in applications in which a unique encoding is needed, such 2844 as when a digital signature is computed on an ASN.1 value. 2846 $ distinguished name (DN) 2847 (I) An identifier that uniquely represents an object in the X.500 2848 Directory Information Tree (DIT) [X501]. (See: domain name.) 2850 (C) A DN is a set of attribute values that identify the path 2851 leading from the base of the DIT to the object that is named. An 2852 X.509 public-key certificate or CRL contains a DN that identifies 2853 its issuer, and an X.509 attribute certificate contains a DN or 2854 other form of name that identifies its subject. 2856 $ Distributed Authentication Security Service (DASS) 2857 (I) An experimental Internet protocol [R1507] that uses 2858 cryptographic mechanisms to provide strong, mutual authentication 2859 services in a distributed environment. 2861 $ distribution point 2862 (I) An X.500 Directory entry or other information source that is 2863 named in a v3 X.509 public-key certificate extension as a location 2864 from which to obtain a CRL that may list the certificate. 2866 (C) A v3 X.509 public-key certificate may have a 2867 "cRLDistributionPoints" extension that names places to get CRLs on 2868 which the certificate might be listed. A CRL obtained from a 2869 distribution point may cover either all reasons for which a 2870 certificate might be revoked or only some of that reasons, may be 2871 issued by either the authority that signed the certificate or some 2872 other authority, and may contain revocation entries for only a 2873 subset of the full set of certificates issued by one CA or may 2874 contain revocation entries for multiple CAs. 2876 $ DN 2877 See: distinguished name. 2879 $ DNS 2880 See: Domain Name System. 2882 $ DOI 2883 See: Domain of Interpretation. 2885 $ domain 2886 (I) General security usage: An environment or context that defines 2887 the set of system resources that a set entities (perhaps defined 2888 by a security policy, or security model, or security architecture) 2889 has the right to access. (See: domain of interpretation, security 2890 perimeter.) 2892 (I) Internet usage: That part of the Internet domain name space 2893 tree [R1034] that is at or below the name the specifies the 2894 domain. A domain is a subdomain of another domain if it is 2895 contained within that domain. For example, D.C.B.A is a subdomain 2896 of C.B.A. (See: Domain Name System.) 2898 (O) MISSI usage: The domain of a MISSI certification authority is 2899 the set of MISSI users whose certificates are signed by the 2900 authority. 2902 (O) OSI usage: An administrative partition of a complex 2903 distributed OSI system. 2905 $ domain name 2906 (I) The style of identifier--a sequence of case-insensitive ASCII 2907 labels separated by dots ("bbn.com.")--defined for subtrees in the 2908 Internet Domain Name System [R1034] and used in other Internet 2909 identifiers, such as host names ("rosslyn.bbn.com."), mailbox 2910 names ("rshirey@bbn.com."), and URLs 2911 ("http://www.rosslyn.bbn.com/foo"). (See: domain and distinguished 2912 name.) 2914 (C) The domain name space of the DNS is a tree structure in which 2915 each node and leaf holds records describing a resource. Each node 2916 has a label. The domain name of a node is the list of labels on 2917 the path from the node to the root of the tree. The labels in a 2918 domain name are printed or read left to right, from the most 2919 specific (lowest, farthest from the root) to the least specific 2920 (highest, closest to the root). The root's label is the null 2921 string, so a complete domain name ends in a dot. The top-level 2922 domains, those immediately below the root, include COM, EDU, GOV, 2923 INT, MIL, NET, ORG, and two-letter country codes (such as US) from 2924 ISO-3166. [R1591] (Also see: country code.) 2926 $ Domain Name System (DNS) 2927 (I) The main Internet operations database, which is distributed 2928 over a collection of servers and used by client software for 2929 purposes such as translating a domain name-style host name into an 2930 IP address (for example, "rosslyn.bbn.com" is "192.1.7.10") and 2931 locating a host that accepts mail for some mailbox address. 2932 [R1034] 2934 (C) The DNS has three major components: 2936 - Domain name space and resource records: Specifications for the 2937 tree-structured domain name space, and data associated with the 2938 names. 2940 - Name servers: Programs that hold information about a subset of 2941 the tree's structure and data holdings, and also hold pointers 2942 to other name servers that can provide information from any 2943 part of the tree. 2945 - Resolvers: Programs that extract information from name servers 2946 in response to client requests; typically, system routines 2947 directly accessible to user programs. 2949 (C) Extensions to the DNS [R2065, R2137] support key distribution 2950 for public keys needed for the DNS and for other protocols, data 2951 origin authentication service and data integrity service for 2952 resource records, data origin authentication service for 2953 transactions between resolvers and servers, and access control of 2954 records. 2956 $ domain of interpretation (DOI) 2957 (I) IPsec usage: An IPsec ISAKMP/IKE domain of interpretation 2958 (DOI) defines payload formats, exchange types, and conventions for 2959 naming security-relevant information such as security policies or 2960 cryptographic algorithms and modes. 2962 (C) For example, see [R2407]. The DOI concept is based on work by 2963 the TSIG CIPSO Working Group. 2965 $ dominate 2966 (I) Security level A is said to "dominate" security level B if the 2967 hierarchical classification level of A is greater (higher) than or 2968 equal to that of B and the nonhierarchical categories of A include 2969 all of those of B. 2971 $ dongle 2972 (I) A portable, physical, electronic device that is required to be 2973 attached to a computer to enable a particular software program to 2974 run. (See: token.) 2976 (C) A dongle is essentially a physical key used for copy 2977 protection of software, because the program will not run unless a 2978 matching dongle is attached. When the software runs, it 2979 periodically queries the dongle and quits if the dongle does not 2980 reply with the proper authentication information. Dongles were 2981 originally constructed as an EPROM to be connected to a serial I/O 2982 port of a personal computer. 2984 $ downgrade 2985 (I) Reduce the classification level of information in an 2986 authorized manner. 2988 $ draft RFC 2989 (D) ISPDs SHOULD NOT use this term, because the Request for 2990 Comment series is archival in nature and does not have a "draft" 2991 category. Instead, use "Internet Draft". 2993 $ DSA 2994 See: Digital Signature Algorithm. 2996 $ DSS 2997 See: Digital Signature Standard. 2999 $ dual control 3000 (I) A procedure that uses two or more entities (usually persons), 3001 operating in concert, to protect a system resource such that no 3002 single entity acting alone can access that resource. (See: no-lone 3003 zone, separation of duties, split knowledge.) 3005 $ dual signature 3006 (D) ISPDs SHOULD NOT use this term except when stated as 3007 "SET(trademark) dual signature" with the following meaning: 3009 (O) SET usage: A single digital signature that protects two 3010 separate messages by including the hash results for both sets in a 3011 single encrypted value. [SET2] 3013 (C) Generated by hashing each message separately, concatenating 3014 the two hash results, and then hashing that value and encrypting 3015 the result with the signer's private key. Done to reduce the 3016 number of encryption operations and to allow verification of data 3017 integrity without complete disclosure of the data. 3019 $ EAP 3020 See: Extensible Authentication Protocol 3022 $ eavesdropping 3023 (I) Passive wiretapping done secretly, i.e., without the knowledge 3024 of the originator or the intended recipients of the communication. 3026 $ ECB 3027 See: electronic codebook. 3029 $ ECDSA 3030 See: Elliptic Curve Digital Signature Algorithm. 3032 $ economy of mechanism 3033 (I) The principle that security mechanism should be designed to be 3034 as simple as possible, so that it can be correctly implemented and 3035 so that it can be verified that its operation enforces the 3036 security policy. (See: least privilege.) 3038 $ EDI 3039 See: electronic data interchange. 3041 $ EDIFACT 3042 See: (secondary definition in) electronic data interchange. 3044 $ EE 3045 (D) ISPDs SHOULD NOT use this abbreviation because of possible 3046 confusion among "end entity", "end-to-end encryption", "escrowed 3047 encryption standard", and other terms. 3049 $ EES 3050 See: Escrowed Encryption Standard. 3052 $ El Gamal algorithm 3053 (N) An algorithm for asymmetric cryptography, invented in 1985 by 3054 Taher El Gamal, that is based on the difficulty of calculating 3055 discrete logarithms and can be used for both encryption and 3056 digital signatures. 3058 $ electronic codebook (ECB) 3059 (I) An block cipher mode in which a plaintext block is used 3060 directly as input to the encryption algorithm and the resultant 3061 output block is used directly as ciphertext [FP081]. 3063 $ electronic commerce 3064 (I) General usage: Business conducted through paperless exchanges 3065 of information, using electronic data interchange, electronic 3066 funds transfer (EFT), electronic mail, computer bulletin boards, 3067 facsimile, and other paperless technologies. 3069 (O) SET usage: "The exchange of goods and services for payment 3070 between the cardholder and merchant when some or all of the 3071 transaction is performed via electronic communication." [SET2] 3073 $ electronic data interchange (EDI) 3074 (I) Computer-to-computer exchange, between trading partners, of 3075 business data in standardized document formats. 3077 (C) EDI formats have been standardized primarily by ANSI X12 and 3078 by EDIFACT (EDI for Administration, Commerce, and Transportation), 3079 an international, UN-sponsored standard primarily used in Europe 3080 and Asia. These two are aligning to create a single global EDI 3081 standard. 3083 $ electronic signature 3084 (D) ISPDs SHOULD NOT use this term because there is no current 3085 consensus on its definition. (Instead, see: digital signature.) 3087 $ elliptic curve cryptography (ECC) 3088 (I) A type of asymmetric cryptography based on mathematics of 3089 groups defined by the points on a curve. 3091 (C) The most efficient implementation of ECC is claimed to be 3092 stronger per bit of key (against cryptanalysis that uses a brute 3093 force attack) than any other known form of asymmetric 3094 cryptography. ECC is based on mathematics different than the kinds 3095 originally used to define the Diffie-Hellman algorithm and the 3096 Digital Signature Algorithm. ECC is based on the mathematics of 3097 groups defined by the points on a curve, where the curve is 3098 defined by a quadratic equation in a finite field. ECC can be used 3099 to define an algorithm for key agreement that is an analog of 3100 Diffie-Hellman and an algorithm for digital signature that is an 3101 analog of DSA. (See: ECDSA.) 3103 $ Elliptic Curve Digital Signature Algorithm (ECDSA) 3104 (N) A standard [A9062] that is the elliptic curve cryptography 3105 analog of the Digital Signature Algorithm. 3107 $ emanation 3108 (I) An signal (electromagnetic, acoustical, or other byproduct) 3109 that is emitted by a system (through radiation or conductance) as 3110 a consequence of its operation, and that may contain information. 3111 (See: TEMPEST.) 3113 $ emanations security (EMSEC) 3114 (I) Physical constraints to prevent information compromise through 3115 signals emanated by a system, particular the application of 3116 TEMPEST technology to block electromagnetic radiation. 3118 $ emergency plan 3119 (D) A synonym for "contingency plan". In the interest of 3120 consistency, ISPD SHOULD use "contingency plan" instead of 3121 "emergency plan". 3123 $ EMSEC 3124 See: emanations security. 3126 $ EMV 3127 (I) An acronym for "Europay, MasterCard, Visa". Refers to a 3128 specification for smart cards that are used as payment cards, and 3129 for related terminals and applications. [EMV1, EMV2, EMV3] 3131 $ Encapsulating Security Payload (ESP) 3132 (I) An Internet IPsec protocol [R2406] designed to provide a mix 3133 of security services--especially data confidentiality service--in 3134 the Internet Protocol. (See: Authentication Header.) 3136 (C) ESP may be used alone, or in combination with the IPsec AH 3137 protocol, or in a nested fashion with tunneling. Security services 3138 can be provided between a pair of communicating hosts, between a 3139 pair of communicating security gateways, or between a host and a 3140 gateway. The ESP header is inserted after the IP header and before 3141 either the upper layer protocol header (transport mode) or an 3142 encapsulated IP header (tunnel mode). ESP can provide data 3143 confidentiality service, data origin authentication service, 3144 connectionless data integrity service, an anti-replay service, and 3145 limited traffic flow confidentiality. The set of services depends 3146 on the placement of the implementation and on options selected 3147 when the security association is established. 3149 $ encipher 3150 (D) ISPDs SHOULD NOT use this term as a synonym for "encrypt". 3151 However, see the usage note under "encryption". 3153 $ encipherment 3154 (D) ISPDs SHOULD NOT use this term as a synonym for "encryption", 3155 except in special circumstances that are explained in the usage 3156 discussion under "encryption". 3158 $ encode 3159 (I) Use a system of symbols to represent information, which might 3160 originally have some other representation. (See: decode.) 3162 (C) Examples include Morse code, ASCII, and BER. 3164 (D) ISPDs SHOULD NOT use this term as a synonym for "encrypt", 3165 because encoding is not usually intended to conceal meaning. 3167 $ encrypt 3168 (I) Cryptographically transform data to produce ciphertext. (See: 3169 encryption.) 3171 $ encryption 3172 (I) The cryptographic transformation of data (called "plaintext") 3173 into a form (called "ciphertext") that conceals the data's 3174 original meaning to prevent it from being known or used. If the 3175 transformation is reversible, then corresponding reversal process 3176 is called "decryption", which is a transformation that restores 3177 encrypted data to its original state. (See: cryptography.) 3179 (C) Usage note: For this concept, ISPDs should use the verb "to 3180 encrypt" (and related variations: encryption, decrypt, and 3181 decryption). Because of cultural biases, however, some 3182 international usage, particularly ISO and CCITT standards, avoid 3183 "to encrypt" and instead use the verb "to encipher" (and related 3184 variations: encipherment, decipher, decipherment). 3186 (O) "The cryptographic transformation of data (see: cryptography) 3187 to produce ciphertext." [I7498 Part 2] 3189 (C) Usually, the plaintext input to an encryption operation is 3190 cleartext. But in some cases, the plaintext may be ciphertext that 3191 was output from another encryption operation. (See: 3192 superencryption.) 3194 (C) Encryption and decryption involve a mathematical algorithm for 3195 transforming data. In addition to the data to be transformed, the 3196 algorithm has one or more inputs that are control parameters: (a) 3197 a key value that varies the transformation and, in some cases, (b) 3198 an initialization value that establishes the starting state of the 3199 algorithm. 3201 $ encryption certificate 3202 (I) A public-key certificate that contains a public key that is 3203 intended to be used for encrypting data, rather than for verifying 3204 digital signatures or performing other cryptographic functions. 3206 C) A v3 X.509 public-key certificate may have a "keyUsage" 3207 extension that indicates the purpose for which the certified 3208 public key is intended. 3210 $ end entity 3211 (I) A system entity that is the subject of a public-key 3212 certificate and that is using, or is permitted and able to use, 3213 the matching private key only for a purpose or purposes other than 3214 signing a digital certificate; i.e., an entity that is not a CA. 3216 (D) "A certificate subject which uses its public [sic] key for 3217 purposes other than signing certificates." [X509] 3219 (C) ISPDs SHOULD NOT use the X.509 definition, because it is 3220 misleading and incomplete. First, the X.509 definition should say 3221 "private key" rather than "public key" because certificates are 3222 not usefully signed with a public key. Second, the X.509 3223 definition is weak regarding whether an end entity may or may not 3224 use the private key to sign a certificate, i.e., whether the 3225 subject may be a CA. The intent of X.509's authors was that an end 3226 entity certificate is not valid for use in verifying a signature 3227 on an X.509 certificate or X.509 CRL. Thus, it would have been 3228 better for the X.509 definition to have said "only for purposes 3229 other than signing certificates". 3231 (C) Despite the problems in the X.509 definition, the term itself 3232 is useful in describing applications of asymmetric cryptography. 3233 The way the term is used in X.509 implies that it was meant to be 3234 defined, as we have done here, relative to roles that an entity 3235 (which is associated with an OSI end system) is playing or is 3236 permitted to play in applications of asymmetric cryptography other 3237 than the PKI that supports applications. 3239 (C) Whether a subject can play both CA and non-CA roles, with 3240 either the same or different certificates, is a matter of policy. 3241 (See: certification practice statement.) A v3 X.509 public-key 3242 certificate may have a "basicConstraints" extension containing a 3243 "cA" value that specifically "indicates whether or not the public 3244 key may be used to verify certificate signatures". 3246 $ end system 3247 (I) An OSI term for a computer that implements all seven layers of 3248 the OSIRM and may attach to a subnetwork. (In the context of the 3249 Internet Protocol Suite, usually called a "host".) 3251 $ end-to-end encryption 3252 (I) Continuous protection of data that flows between two points in 3253 a network, provided by encrypting data when it leaves its source, 3254 leaving it encrypted while it passes through any intermediate 3255 computers (such as routers), and decrypting only when the data 3256 arrives at the intended destination. (See: link encryption, 3257 wiretapping.) 3259 (C) When two points are separated by multiple communication links 3260 that are connected by one or more intermediate relays, end-to-end 3261 encryption enables the source and destination systems to protect 3262 their communications without depending on the intermediate systems 3263 to provide the protection. 3265 $ end user 3266 (I) General usage: A system entity, usually a human individual, 3267 that makes of system resources, primarily for application purposes 3268 as opposed to system management purposes. 3270 (I) PKI usage: A synonym for "end entity". But the term "end 3271 entity" is preferred. 3273 $ entity 3274 See: system entity. 3276 $ entrapment 3277 (I) "The deliberate planting of apparent flaws in a system for the 3278 purpose of detecting attempted penetrations or confusing an 3279 intruder about which flaws to exploit." [FP039] (See: honey pot.) 3281 $ ephemeral key 3282 (I) A public key or a private key that is relatively short-lived. 3284 $ error detection code 3285 (I) A checksum designed to detect, but not correct, accidental 3286 (i.e., unintentional) changes in data. 3288 $ Escrowed Encryption Standard (EES) 3289 (N) A U.S. Government standard [FP185] that specifies use of a 3290 symmetric encryption algorithm (SKIPJACK) and a Law Enforcement 3291 Access Field (LEAF) creation method to implement part of a key 3292 escrow system that provides for decryption of encrypted 3293 telecommunications when interception is lawfully authorized. 3295 (C) Both SKIPJACK and the LEAF are to be implemented in equipment 3296 used to encrypt and decrypt unclassified, sensitive 3297 telecommunications data. 3299 $ ESP 3300 See: Encapsulating Security Payload. 3302 $ Estelle 3303 (N) A language (ISO 9074-1989) for formal specification of 3304 computer network protocols. 3306 $ evaluated products list 3307 (O) General usage: A list of information system equipment items 3308 that have been evaluated against, and found to be compliant with, 3309 at particular set of criteria: 3311 (O) NSA usage: (http://www.radium.ncsc.mil/tpep/epl/) The 3312 Evaluated Products List contains items that have been evaluated 3313 against the TCSEC by the NCSC, or against the Common Criteria by 3314 the NCSC or one of its partner agencies in another county. The 3315 List forms Chapter 4 of NSA's "Information Systems Security 3316 Products and Services Catalogue". 3318 $ evaluated system 3319 (I) Refers to a system that has been evaluated against security 3320 criteria such as the TCSEC, or the Common Criteria for Information 3321 Technology Security Evaluation. 3323 $ expire 3324 See: certificate expiration. 3326 $ exposure 3327 See: (secondary definition in) threat consequence. 3329 $ Extensible Authentication Protocol 3330 (I) A framework that supports multiple, optional authentication 3331 mechanisms for PPP, including cleartext passwords, challenge- 3332 response, and arbitrary dialog sequences. [R2284] 3333 (C) This protocol is intended for use primarily by a host or 3334 router that connects to a PPP network server via switched circuits 3335 or dial-up lines. 3337 $ extension 3338 (I) A data item defined for optional inclusion in a v3 X.509 3339 public-key certificate or a v2 X.509 CRL. 3341 (C) The formats defined in X.509 can be extended to provide 3342 methods for associating additional attributes with subjects and 3343 public keys and for managing a certification hierarchy: 3345 - "Certificate extension": X.509 defines standard extensions that 3346 may be included in v3 certificates to provide additional key 3347 and security policy information, subject and issuer attributes, 3348 and certification path constraints. 3350 - "CRL extension": X.509 defines extensions that may be included 3351 in v2 CRLs to provide additional issuer key and name 3352 information, revocation reasons and constraints, and 3353 information about distribution points and delta CRLs. 3355 - "Private extension": Additional extensions, each named by an 3356 OID, can be locally defined as needed by applications or 3357 communities. (See: PKIX private extension, SET private 3358 extensions.) 3360 $ extranet 3361 (I) A computer network that an organization uses to carry 3362 application data traffic between the organization and its business 3363 partners. (See: Intranet.) 3365 (C) An extranet can be implemented securely, either on the 3366 Internet or using Internet technology, by constructing the 3367 extranet as a VPN. 3369 $ failure control 3370 (I) A methodology used to provide fail-safe or fail-soft 3371 termination and recovery of functions and processes when failures 3372 are detected or occur in a system. [FP039] 3374 $ fail safe 3375 (I) A mode of system termination that automatically leaves system 3376 processes and components in a secure state when a failure occurs 3377 or is detected in the system. 3379 $ fail soft 3380 (I) Selective termination of affected non-essential system 3381 functions and processes when a failure occurs or is detected in 3382 the system. 3384 $ Federal Information Processing Standards (FIPS) 3385 (N) The Federal Information Processing Standards Publication (FIPS 3386 PUB) series issued by the U.S. National Institute of Standards and 3387 Technology as technical guidelines for U.S. Government 3388 procurements of information processing system equipment and 3389 services. [FP031, FP039, FP046, FP081, FP113, FP140, FP151, FP180, 3390 FP185, FP186, FP188] 3392 (C) Issued under the provisions of section 111(d) of the Federal 3393 Property and Administrative Services Act of 1949 as amended by the 3394 Computer Security Act of 1987, Public Law 100-235. 3396 $ Federal Public-key Infrastructure (FPKI) 3397 (N) A PKI being planned to establish facilities, specifications, 3398 and policies needed by the U.S. Federal Government to use public- 3399 key certificates for INFOSEC, COMSEC, and electronic commerce 3400 involving unclassified but sensitive applications and interactions 3401 between Federal agencies as well as with entities of other 3402 branches of the Federal Government, state, and local governments, 3403 business, and the public. [FPKI] 3405 $ Federal Standard 1027 3406 (N) An obsolete document defining emanation, anti-tamper, security 3407 fault analysis, and manual key management criteria for DES 3408 encryption devices, primary for OSI layer 2. Renamed "FIPS PUB 3409 140" when responsibility for protecting unclassified, sensitive 3410 information was transferred from NSA to NIST, and then replaced by 3411 FIPS PUB 140-1. 3413 $ File Transfer Protocol (FTP) 3414 (I) A TCP-based, application-level, Internet Standard protocol for 3415 moving data files from one computer to another. [R0959] 3417 $ filtering router 3418 (I) An internetwork router that selectively prevents the passage 3419 of data packets according to a security policy. 3421 (C) A filtering router may be used as a firewall or part of a 3422 firewall. A router usually receives a packet from a network and 3423 decides where to forward it on a second network. A filtering 3424 router does the same, but first decides whether the packet should 3425 be forwarded at all, according to some security policy. The policy 3426 is implemented by rules (packet filters) loaded into the router. 3427 The rules mostly involve values of data packet control fields 3428 (especially IP source and destination addresses and TCP port 3429 numbers). [R2179] 3431 $ financial institution 3432 (N) "An establishment responsible for facilitating customer- 3433 initiated transactions or transmission of funds for the extension 3434 of credit or the custody, loan, exchange, or issuance of money." 3435 [SET2] 3437 $ fingerprint 3438 (I) A pattern of curves formed by the ridges on a fingertip. (See: 3439 biometric authentication, thumbprint.) 3441 (D) ISPDs SHOULD NOT use this term as a synonym for "hash result" 3442 because it mixes concepts in a potentially misleading way. 3444 (D) ISPDs SHOULD NOT use this term with the following PGP 3445 definition, because the term and definition mix concepts in a 3446 potentially misleading way and duplicate the meaning of "hash 3447 result": 3449 (C) PGP usage: A hash result used to authenticate a public key 3450 (key fingerprint) or other data. [PGP] 3452 $ FIPS 3453 See: Federal Information Processing Standards. 3455 $ FIPS PUB 140-1 3456 (N) A U.S. Government standard [FP140] for security requirements 3457 to be met by a cryptographic module used to protect unclassified 3458 information in computer and communication systems. (To be 3459 superseded by the Common Criteria. Also see: Federal Information 3460 Processing Standards.) 3462 (C) The standard specifies four increasing levels (from "Level 1" 3463 to "Level 4") of requirements to cover a wide range of potential 3464 applications and environments. The requirements address basic 3465 design and documentation, module interfaces, authorized roles and 3466 services, physical security, software security, operating system 3467 security, key management, cryptographic algorithms, 3468 electromagnetic interference and electromagnetic compatibility 3469 (EMI/EMC), and self-testing. NIST and the Canadian Communication 3470 Security Establishment jointly certify modules. 3472 $ firewall 3473 (I) An internetwork gateway that restricts data communication 3474 traffic to and from a computer network to protect that network's 3475 system resources against threats from other networks that are 3476 outside the firewall. (See: guard.) 3478 (C) A firewall typically separates a smaller, secure network (such 3479 as a corporate LAN) from a larger network (such as the Internet). 3480 Installed at the point where the networks connect, the firewall 3481 applies security policy rules to control traffic that flows in and 3482 out of the protected network. 3484 (C) A firewall is not always a single computer. For example, a 3485 firewall may consist of a pair of filtering routers and one or 3486 more proxy servers running on one or more bastion hosts, all 3487 connected to a small, dedicated LAN between the two routers. The 3488 external router blocks attacks that use IP to break security (IP 3489 address spoofing, source routing, packet fragments), while proxy 3490 servers block attacks that would exploit a vulnerability in a 3491 higher layer protocol or service. The internal router blocks 3492 traffic from leaving the protected network except through the 3493 proxy servers. The difficult part is defining criteria by which 3494 packets are denied passage through the firewall, because a 3495 firewall not only needs to keep intruders out, but usually also 3496 needs to let authorized users in and out. 3498 $ firmware 3499 (I) Computer programs and data stored in hardware (typically in 3500 read-only memory or programmable read-only memory) such that the 3501 programs and data cannot be dynamically written or modified during 3502 execution of the programs. (Compare with: hardware, software.) 3504 $ FIRST 3505 See: Forum of Incident Response and Security Teams. 3507 $ flaw hypothesis methodology 3508 (I) An evaluation or attack technique in which specifications and 3509 documentation for a system are analyzed to hypothesize flaws in 3510 the system. The list of hypothetical flaws is prioritized on the 3511 basis of the estimated probability that a flaw exists and, 3512 assuming it does, on the ease of exploiting it and the extent of 3513 control or compromise it would provide. The prioritized list is 3514 used to direct a penetration test or attack against the system. 3515 [NCS04] 3517 $ flooding 3518 (I) An attack that attempts to cause a failure in (especially, in 3519 the security of) a computer system or other data processing entity 3520 by providing more input than the entity can process properly. 3521 (See: denial of service.) 3523 $ flow analysis 3524 (I) An analysis performed on a nonprocedural formal system 3525 specification that locates potential flows of information between 3526 system variables. By assigning security levels to the variables, 3527 the analysis can find some types of covert channels. 3529 $ flow control 3530 (I) A procedure or technique to ensure that information transfers 3531 within a system are not made from a higher security level to a 3532 lower security level. (See: covert channel, simple security 3533 property, confinement property.) 3535 $ formal specification 3536 (I) A specification of hardware or software functionality in a 3537 computer-readable language; usually a precise mathematical 3538 description of the behavior of the system with the providing a 3539 correctness proof. 3541 $ formulary 3542 (I) A technique for enabling a decision to grant or deny access to 3543 be made dynamically at the time the access is attempted, rather 3544 than earlier when an access control list or ticket is created. 3546 $ FORTEZZA(trademark) 3547 (N) A registered trademark of the U.S. National Security Agency 3548 (NSA), used for a family of interoperable security products that 3549 implement a NIST/NSA-approved suite of cryptographic algorithms 3550 for digital signature, hash, encryption, and key exchange. The 3551 products include a PC card that contains a CAPSTONE chip, serial 3552 port modems, server boards, smart cards, and software 3553 implementations. 3555 $ Forum of Incident Response and Security Teams (FIRST) 3556 (N) An international consortium of CSIRTs that work together to 3557 handle computer security incidents and promote preventive 3558 activities. (See: CSIRT, security incident.) 3560 (C) FIRST was founded in 1990 and, as of September 1999, had 3561 nearly 70 members spanning the globe. It mission includes: 3563 - Provide members with technical information, tools, methods, 3564 assistance, and guidance. 3565 - Coordinate proactive liaison activities and analytical support. 3566 - Encourage development of quality products and services. 3567 - Improve national and international information security for 3568 government, private industry, academia, and the individual. 3569 - Enhance the image and status of the CSIRT community. 3571 $ forward secrecy 3572 See: public-key forward secrecy. 3574 $ FPKI 3575 See: Federal Public-Key Infrastructure. 3577 $ FTP 3578 See: File Transfer Protocol. 3580 $ gateway 3581 (I) A relay mechanism that attaches to two (or more) computer 3582 networks that have similar functions but dissimilar 3583 implementations and that enables host computers on one network to 3584 communicate with hosts on the other; an intermediate system that 3585 is the interface between two computer networks. (See: bridge, 3586 firewall, guard, internetwork, proxy server, router, and 3587 subnetwork.) 3589 (C) Gateways are conceivable at any OSI layer, but actual gateways 3590 operate at OSI layer 3 (see: bridge, router) or OSI layer 7 (see: 3591 proxy server). When the two networks differ in the protocol by 3592 which they offer service to hosts, the gateway may translate one 3593 protocol into another or otherwise facilitate interoperation of 3594 hosts (see: Internet Protocol). 3596 $ GCA 3597 See: geopolitical certificate authority. 3599 $ GeneralizedTime 3600 (N) The ASN.1 data type "GeneralizedTime" (specified in ISO 8601) 3601 contains a calendar date (YYYYMMDD) and a time of day, which is 3602 either (a) the local time, (b) the Coordinated Universal Time, or 3603 (c) both the local time and an offset allowing Coordinated 3604 Universal Time to be calculated. (See: Coordinated Universal Time, 3605 UTCTime.) 3607 $ Generic Security Service Application Program Interface (GSS-API) 3608 (I) An Internet Standard protocol [R2078] that specifies calling 3609 conventions by which an application (typically another 3610 communication protocol) can obtain authentication, integrity, and 3611 confidentiality security services independently of the underlying 3612 security mechanisms and technologies, thus allowing the 3613 application source code to be ported to different environments. 3615 (C) "A GSS-API caller accepts tokens provided to it by its local 3616 GSS-API implementation and transfers the tokens to a peer on a 3617 remote system; that peer passes the received tokens to its local 3618 GSS-API implementation for processing. The security services 3619 available through GSS-API in this fashion are implementable (and 3620 have been implemented) over a range of underlying mechanisms based 3621 on [symmetric] and [asymmetric cryptography]." [R2078] 3623 $ geopolitical certificate authority (GCA) 3624 (O) SET usage: In a SET certification hierarchy, an optional level 3625 that is certified by a brand certification authority and that may 3626 certify cardholder CAs, merchant CAs, and payment gateway CAs. 3627 Using GCAs enables a brand to distribute responsibility for 3628 managing certificates to geographic or political regions, so that 3629 brand policies can vary between regions as needed. 3631 $ Green Book 3632 (D) Except as an explanatory appositive, ISPDs SHOULD NOT use this 3633 term as a synonym for "Defense Password Management Guideline" 3634 [CSC2]. Instead, use the full proper name of the document or, in 3635 subsequent references, a conventional abbreviation. (See: Rainbow 3636 Series.) 3638 (D) Usage note: To improve international comprehensibility of 3639 Internet Standards and the Internet Standards Process, ISPDs 3640 SHOULD NOT use "cute" synonyms for document titles. No matter how 3641 popular and clearly understood a nickname may be in one community, 3642 it is likely to cause confusion in others. For example, in 3643 addition to the meaning given above, there are several other 3644 information system standards called "the Green Book". The 3645 following are just a few examples: 3647 - Any 1992 standard issued by the ITU-T (then CCITT). 3648 - "PostScript Language Program Design", Adobe Systems, Addison- 3649 Wesley, 1988. 3650 - IEEE 1003.1 POSIX Operating Systems Interface. 3651 - "Smalltalk-80: Bits of History, Words of Advice", Glenn 3652 Krasner, Addison-Wesley, 1983. 3653 - "X/Open Compatibility Guide". 3654 - A particular CD-ROM format developed by Phillips. 3656 $ GRIP 3657 (I) A contraction of "Guidelines and Recommendations for Security 3658 Incident Processing", the name of the IETF working group that 3659 seeks to facilitate consistent handling of security incidents in 3660 the Internet community. (See: security incident.) 3662 (C) Guidelines to be produced by the WG will address technology 3663 vendors, network service providers, and response teams in their 3664 roles assisting organizations in resolving security incidents. 3665 These relationships are functional and can exist within and across 3666 organizational boundaries. 3668 $ GSS-API 3669 See: Generic Security Service Application Program Interface. 3671 $ guard 3672 (I) A gateway that is interposed between two networks (or 3673 computers, or other information systems) operating at different 3674 security levels (one is usually higher than the other) and is 3675 trusted to mediate all information transfers between the two 3676 levels, to either ensure that no sensitive information from the 3677 first (higher) level can leak to the second (lower) level, or to 3678 protect against destruction of data on the first (higher) level. 3679 (See: firewall.) 3681 $ GULS 3682 (I) Generic Upper Layer Security service element (ISO 11586), a 3683 five-part standard for the exchange of security information and 3684 security-transformation functions that support the integrity and 3685 confidentiality of application data. 3687 $ guest login 3688 See: anonymous login. 3690 $ hacker 3691 (I) Someone with a strong interest in computers, who enjoys 3692 learning about them and experimenting with them. (See: cracker.) 3694 (C) The recommended definition is the original meaning of the term 3695 (circa 1960), which then had a neutral or positive connotation. 3697 Today, the term is frequently misused, especially by journalists, 3698 to have the pejorative meaning of cracker. 3700 $ handle 3701 (I) (1.) Verb: Perform processing operations on data, such as 3702 receive and transmit, collect and disseminate, create and delete, 3703 store and retrieve, read and write, and compare. (2.) A on-line 3704 pseudonym, such as those used by crackers; derived from citizens 3705 band radio usage. 3707 $ hardware 3708 (I) The physical, material components of a computer system. 3709 (Compare with: firmware, software.) 3711 $ hardware token 3712 See: token. 3714 (O) SET usage: "A portable device (for example, smart card, and 3715 PCMCIA cards) specifically designed to store cryptographic 3716 information and possibly perform cryptographic functions in a 3717 secure manner." [SET2] 3719 $ hash code 3720 (D) ISPDs SHOULD NOT use this term as a synonym for "hash result" 3721 because it unnecessarily duplicates the meaning of the other term 3722 and mixes concepts in a potentially misleading way. A hash result 3723 is not a "code" in the sense defined in this glossary. (See: hash 3724 value, message digest.) 3726 $ hash function 3727 (I) An algorithm that computes a value based on a data set (such 3728 as a message or file; usually variable-length; possibly very 3729 large), thereby mapping the data set to a smaller data object 3730 (called the hash result) which is usually a fixed-size value. 3731 (See: checksum, keyed hash.) 3733 (O) "A (mathematical) function which maps values from a large 3734 (possibly very large) domain into a smaller range. A 'good' hash 3735 function is such that the results of applying the function to a 3736 (large) set of values in the domain will be evenly distributed 3737 (and apparently at random) over the range." [X509] 3739 (C) The kind of hash function needed for security applications is 3740 a one-way function called a cryptographic hash function, an 3741 algorithm for which it is computationally infeasible (because no 3742 attack is significantly more efficient than brute force) to find 3743 either (a) a data set that maps to a pre-specified hash result 3744 (the "one-way" property) or (b) two data sets that map to the same 3745 hash result (the "collision-free" property). (See: MD2, MD4, MD5, 3746 SHA-1.) 3748 (C) A cryptographic hash is "good" in the sense stated above by 3749 X.509. Any change to an input data set will, with high 3750 probability, result in a different hash result, so that the result 3751 of a cryptographic hash makes a good checksum for a data set. 3753 $ hash result 3754 (I) The output of a hash function. 3756 (O) "The output produced by a hash function upon processing a 3757 message" (where "message" is broadly defined as "a digital 3758 representation of data"). [ABA] (The recommended definition is 3759 compatible with this ABA definition, but we avoid the unusual 3760 definition of "message".) 3762 $ hash value 3763 (D) ISPDs SHOULD NOT use this term as a synonym for "hash result" 3764 (the output of a hash function) because it might be confused with 3765 "hashed" value (the input to a hash function). (See: hash code, 3766 message digest.) 3768 $ hierarchical PKI 3769 (I) A PKI architecture based on a certification hierarchy. (See: 3770 mesh PKI, trust-file PKI.) 3772 $ hierarchy management 3773 (I) The process of generating configuration data and issuing 3774 public-key certificates to build and operate a certification 3775 hierarchy. 3777 $ hierarchy of trust 3778 (D) ISPDs SHOULD NOT use this term as a synonym for "certification 3779 hierarchy" because this term mixes concepts in a potentially 3780 misleading way and duplicates the meaning of another, standardized 3781 term. (See: trust, web of trust.) 3783 $ hijack attack 3784 (I) A form of active wiretapping in which the attacker seizes 3785 control of a previously established communication association. 3786 (See: man-in-the-middle attack, pagejacking, piggyback attack.) 3788 $ HMAC 3789 (I) A keyed hash [R2104] that can be based on any interactive 3790 cryptographic hash (e.g., MD5 or SHA-1), so that the cryptographic 3791 strength of HMAC depends on the properties of the selected 3792 cryptographic hash. (See: [R2202, R2403, R2404].) 3794 (C) Assume that H is a generic cryptographic hash in which a basic 3795 compression function is interated on data blocks of length B 3796 bytes. L is the length of the of hash result of H. K is a secret 3797 key of length L <= K <= B. The values IPAD and OPAD are fixed 3798 strings used as inner and outer padding and defined as follows: 3799 IPAD = the byte 0x36 repeated B times, OPAD = the byte 0x5C 3800 repeated B times. HMAC is computed by H(K XOR OPAD, H(K XOR IPAD, 3801 inputdata)). 3803 (C) The goals of HMAC are as follows: 3805 - To use available cryptographic hash functions without 3806 modification, particularly those that perform well in software 3807 and for which software is freely and widely available. 3808 - To preserve the original performance of the selected hash 3809 without significant degradation. 3810 - To use and handle keys in a simple way. 3811 - To have a well-understood cryptographic analysis of the 3812 strength of the mechanism based on reasonable assumptions about 3813 the underlying hash function. 3814 - To enable easy replacement of the hash function in case a 3815 faster or stronger hash is found or required. 3817 $ honey pot 3818 (I) A system (e.g., a web server) or a system resource (e.g., a 3819 file on a server), that is designed to be attractive to potential 3820 crackers and intruders, like honey is attractive to bears. (See: 3821 entrapment.) 3823 (D) It is likely that other cultures have different metaphors for 3824 this concept. To ensure international understanding, this term 3825 SHOULD NOT be used unless it is locally accompanied by this 3826 definition. (See: (usage note under) Green Book.) 3828 $ host 3829 (I) A computer that is attached to a communication subnetwork or 3830 internetwork and can use services provided by the network to 3831 exchange data with other attached systems. (Compare with: end 3832 system.) In the context of the Internet protocol suite, a term for 3833 a networked computer that does not forward Internet Protocol 3834 packets that are not addressed to the computer itself. (Compare 3835 with: router.) 3837 (C) Derivation: As viewed by its users, a host "entertains" 3838 guests, providing application layer services or access to other 3839 computers attached to the network. Although some traditional 3840 peripheral service devices, such as printers, can now be 3841 independently connected to networks, they are not usually called 3842 hosts. 3844 $ HTML 3845 See: Hypertext Markup Language. 3847 $ HTTP 3848 See: Hypertext Transfer Protocol. 3850 $ https 3851 (I) When used in the first part of a URL (the part that precedes 3852 the colon and that specifies an access scheme or protocol), this 3853 term specifies the use of HTTP enhanced by a security mechanism, 3854 normally SSL. (Compare with: S-HTTP.) 3856 $ hybrid encryption 3857 (I) An application of cryptography that combines two or more 3858 encryption algorithms, particularly a combination of symmetric and 3859 asymmetric encryption (e.g., see: digital envelope). 3861 (C) Asymmetric algorithms require more computation than 3862 equivalently strong symmetric ones. Thus, asymmetric encryption is 3863 not normally used for data confidentiality except in distributing 3864 symmetric keys in applications where the key data is usually short 3865 (in terms of bits) compared to the data it protects. (For example, 3866 see: MSP, PEM, PGP.) 3868 $ hyperlink 3869 (I) In hypertext or hypermedia, an information object (such as a 3870 word, a phrase, or an image; usually highlighted by color or 3871 underscoring) that points (indicates how to connect) to related 3872 information that is located elsewhere and can be retrieved by 3873 activating the link (such as by selecting the object with a mouse 3874 pointer and clicking). 3876 $ hypermedia 3877 (I) A generalization of hypertext; any media that contain 3878 hyperlinks, which point to additional material in the same or 3879 another data object. 3881 $ hypertext 3882 (I) A computer document, or part of a document, that contains 3883 hyperlinks to other documents; i.e., text that contains active 3884 pointers to other text. Usually written in Hypertext Markup 3885 Language and accessed using a web browser. (See: hypermedia.) 3887 $ Hypertext Markup Language (HTML) 3888 (I) A platform-independent system of syntax and semantics for 3889 adding characters to data files (particularly text files) to 3890 represent the data's structure and to point to related data, thus 3891 creating hypertext for use in the World Wide Web and other 3892 applications. [R1866] 3894 $ Hypertext Transfer Protocol (HTTP) 3895 (I) An application-level, client-server, Internet protocol used to 3896 carry data requests and responses in the World Wide Web [R2068]. 3897 (See: hypertext.) 3899 $ IAB 3900 See: Internet Architecture Board. 3902 $ IANA 3903 See: Internet Assigned Numbers Authority. 3905 $ ICMP 3906 See: Internet Control Message Protocol. 3908 $ ICMP flood 3909 (I) A denial of service attack that sends a host more ICMP echo 3910 request ("ping") packets than the protocol implementation can 3911 handle. (See: flooding, smurf.) 3913 $ ICRL 3914 See: indirect certificate revocation list. 3916 $ IDEA 3917 See: International Data Encryption Algorithm. 3919 $ identification 3920 (I) An act or process that presents an identifier to a system so 3921 that the system can recognize a system entity and distinguish it 3922 from other entities. (See: authentication.) 3924 $ Identification Protocol 3925 (I) An client-server Internet protocol [R1413] for learning the 3926 identity of a user of a particular TCP connection. 3928 (C) Given a TCP port number pair, the server returns a character 3929 string that identifies the owner of that connection on the 3930 server's system. The protocol is not intended for authorization or 3931 access control. At best, it provides additional auditing 3932 information with respect to TCP. 3934 $ identity-based security policy 3935 (I) "A security policy based on the identities and/or attributes 3936 of users, a group of users, or entities acting on behalf of the 3937 users and the resources/objects being accessed." [I7498 Part 2] 3938 (See: rule-based security policy.) 3940 $ IEEE 3941 See: Institute of Electrical and Electronics Engineers, Inc. 3943 $ IEEE 802.10 3944 (N) An IEEE committee developing security standards for local area 3945 networks; see: SILS. 3947 $ IEEE P1363 3948 (N) An IEEE working group, Standard for Public-Key Cryptography, 3949 developing a comprehensive reference standard for asymmetric 3950 cryptography; covering discrete logarithm (e.g., DSA), elliptic 3951 curve, and integer factorization (e.g., RSA); and covering key 3952 agreement, digital signature, and encryption. 3954 $ IESG 3955 See: Internet Engineering Steering Group. 3957 $ IETF 3958 See: Internet Engineering Task Force. 3960 $ IKE 3961 See: IPsec Key Exchange. 3963 $ IMAP4 3964 See: Internet Message Access Protocol, version 4. 3966 $ IMAP4 AUTHENTICATE 3967 (I) A IMAP4 "command" (better described as a transaction type, or 3968 a protocol-within-a-protocol) by which an IMAP4 client optionally 3969 proposes a mechanism to an IMAP4 server to authenticate the client 3970 to the server and provide other security services. (See: POP3.) 3972 (C) If the server accepts the proposal, the command is followed by 3973 performing a challenge-response authentication protocol and, 3974 optionally, negotiating a protection mechanism for subsequent POP3 3975 interactions. The security mechanisms used by IMAP4 AUTHENTICATE-- 3976 including Kerberos, GSSAPI, and S/Key--are described in [R1731]. 3978 $ in the clear 3979 (I) Not encrypted. (See: cleartext.) 3981 $ indirect certificate revocation list (ICRL) 3982 (I) In X.509, a CRL that may contain certificate revocation 3983 notifications for certificates issued by CAs other than the issuer 3984 of the list. 3986 $ indistinguishability 3987 (I) An attribute of an encryption algorithm that is a 3988 formalization of the notion that the encryption of some string is 3989 indistinguishable from the encryption of an equal-length string of 3990 nonsense. 3992 (C) Under certain conditions, this notion is equivalent to 3993 semantic security. 3995 $ information 3996 (I) Facts and ideas, which can be represented (encoded) as various 3997 forms of data. 3999 $ Information Technology Security Evaluation Criteria (ITSEC) 4000 (N) Standard developed for use in the European Union; accommodates 4001 a wider range of security assurance and functionality combinations 4002 than the TCSEC. Superseded by the Common Criteria. [ITSEC] 4004 $ INFOSEC 4005 (I) Abbreviation for "information security", referring to security 4006 measures that implement and assure security services in computer 4007 systems (i.e., COMPUSEC) and communication systems (i.e., COMSEC). 4009 $ initialization value (IV) 4010 (I) An input parameter that sets the starting state of a 4011 cryptographic algorithm or mode. (Sometimes called "initialization 4012 vector" or "message indicator".) 4014 (C) An IV can be used to introduce cryptographic variance in 4015 addition to that provided by a key (see: salt), and to synchronize 4016 one cryptographic process with another. For an example of the 4017 latter, cipher block chaining mode requires an IV [R2405]. 4019 $ initialization vector 4020 (D) A synonym for "initialization value". In the interest of 4021 consistency, ISPDs SHOULD use initialization value" instead of 4022 "initialization vector". 4024 $ insider attack 4025 See: (secondary definition in) attack. 4027 $ Institute of Electrical and Electronics Engineers, Inc. (IEEE) 4028 (N) The IEEE is a not-for-profit association of more than 330,000 4029 individual members in 150 countries. The IEEE produces 30 percent 4030 of the world's published literature in electrical engineering, 4031 computers, and control technology; holds annually more than 300 4032 major conferences; and has more than 800 active standards with 700 4033 under development. (See: Standards for Interoperable LAN/MAN 4034 Security.) 4036 $ integrity 4037 See: data integrity, correctness integrity, source integrity, 4038 system integrity. 4040 $ integrity check 4041 (D) ISPDs SHOULD NOT use this term as a synonym for "cryptographic 4042 hash" or "protected checksum", because this term unnecessarily 4043 duplicates the meaning of other, well-established terms. 4045 $ intelligent threat 4046 (I) A circumstance in which an adversary has the technical and 4047 operational capability to detect and exploit a vulnerability and 4048 also has the demonstrated, presumed, or inferred intent to do so. 4049 (See: threat.) 4051 $ International Data Encryption Algorithm (IDEA) 4052 (N) A patented, symmetric (see: symmetric cryptography) block 4053 cipher that uses a 128-bit key and operates on 64-bit blocks. 4054 [Schn] 4056 $ International Standard 4057 See: (secondary definition in) ISO. 4059 $ International Traffic in Arms Regulations (ITAR) 4060 (N) Rules issued by the U.S. State Department, by authority of the 4061 Arms Export Control Act (22 U.S.C. 2778), to control export and 4062 import of defense articles and defense services, including 4063 information security systems, such as cryptographic systems, and 4064 TEMPEST suppression technology. (See: Wassenaar Arrangement.) 4066 $ internet 4067 $ Internet 4068 See: internet vs. Internet. 4070 $ Internet Architecture Board (IAB) 4071 (I) A technical advisory group of the ISOC, chartered by the ISOC 4072 Trustees to provide oversight of Internet architecture and 4073 protocols and, in the context of Internet Standards, a body to 4074 which decisions of the IESG may be appealed. Responsible for 4075 approving appointments to the IESG from among nominees submitted 4076 by the IETF nominating committee. [R2026] 4078 $ Internet Assigned Numbers Authority (IANA) 4079 (I) Since the early days of the Internet, the IANA has been 4080 chartered by the ISOC and the Federal Network Council to be the 4081 central coordination, allocation, and registration body for 4082 parameters for Internet protocols. Now, a new not-for-profit 4083 organization is being proposed, with an international board of 4084 directors to oversee the operations of the necessary central 4085 coordinating functions of the Internet. 4087 (C) The Internet protocol suite, as defined by the IETF and the 4088 IESG, contains numerous parameters, such as internet addresses, 4089 domain names, autonomous system numbers, protocol numbers, port 4090 numbers, management information base object identifiers, including 4091 private enterprise numbers, and many others. The Internet 4092 community requires that the values used in these parameter fields 4093 be assigned uniquely. The IANA makes those assignments as 4094 requested and maintains a registry of the current values. 4096 $ Internet Control Message Protocol (ICMP) 4097 (I) An Internet Standard protocol [R0792] that is used to report 4098 error conditions during IP datagram processing and to exchange 4099 other information concerning the state of the IP network. 4101 $ Internet Draft 4102 (I) A working document of the IETF, its areas, and its working 4103 groups. (Other groups may also distribute working documents as 4104 Internet Drafts.) An Internet Draft is not an archival document 4105 like an RFC is. Instead, an Internet Draft is a preliminary or 4106 working document that is valid for a maximum of six months and may 4107 be updated, replaced, or made obsolete by other documents at any 4108 time. It is inappropriate to use an Internet Draft as reference 4109 material or to cite it other than as "work in progress." 4111 $ Internet Engineering Steering Group (IESG) 4112 (I) The part of the ISOC responsible for technical management of 4113 IETF activities and administration of the Internet Standards 4114 Process according to procedures approved by the ISOC Trustees. 4115 Directly responsible for actions along the "standards track", 4116 including final approval of specifications as Internet Standards. 4117 Composed of IETF Area Directors and the IETF chairperson, who also 4118 chairs the IESG. [R2026] 4120 $ Internet Engineering Task Force (IETF) 4121 (I) A self-organized group of people who make contributions to the 4122 development of Internet technology. The principal body engaged in 4123 developing Internet Standards, although not itself a part of the 4124 ISOC. Composed of Working Groups, which are arranged into Areas 4125 (such as the Security Area), each coordinated by one or more Area 4126 Directors. Nominations to the IAB and the IESG are made by a 4127 committee selected at random from regular IETF meeting attendees 4128 who have volunteered. [R2026, R2323] 4130 $ Internet Message Access Protocol, version 4 (IMAP4) 4131 (I) A Internet protocol [R2060] by which a client workstation can 4132 dynamically access a mailbox on a server host to manipulate and 4133 retrieve mail message that the server has received and is holding 4134 for the client. (See: POP3.) 4136 (C) IMAP4 has mechanisms for optionally authenticating a client to 4137 a server and providing other security services. (See: IMAP4 4138 AUTHENTICATE.) 4140 $ Internet Policy Registration Authority (IPRA) 4141 (I) An X.509-compliant CA that is the top CA of the Internet 4142 certification hierarchy operated under the auspices of the ISOC 4143 [R1422]. (See: (PEM usage under) certification hierarchy.) 4145 $ Internet Protocol (IP) 4146 (I) A TCP/IP protocol that moves datagrams (discrete sets of bits) 4147 from one computer to another across an internetwork but does not 4148 provide reliable delivery, flow control, sequencing, or other end- 4149 to-end services that TCP provides. (Includes both version 4 4150 [R0791] and version 6 [R2460].) (See: IP address.) 4152 (C) In the OSIRM, IP would be placed at the top of the layer 3. 4154 $ Internet Protocol security (IPsec) 4155 (I) (1.) The name of the IETF working group that is specifying a 4156 security architecture [R2401] and protocols to provide security 4157 services for Internet Protocol traffic. (Implementation is 4158 optional for IP version 4, mandatory for version 6.) (2.) A 4159 collective name for that architecture and set of protocols. (See: 4160 Internet Protocol Security Option.) 4162 (C) Note that the letters "sec" are lower-case. 4164 (C) The IPsec architecture specifies (a) security protocols (AH 4165 and ESP), (b) security associations (what they are, how they work, 4166 how they are managed, and associated processing), (c) key 4167 management (IKE), and (d) algorithms for authentication, and 4168 encryption. The set of security services include access control 4169 service, connectionless data integrity service, data origin 4170 authentication service, protection against replays (detection of 4171 the arrival of duplicate datagrams, within a constrained window), 4172 data confidentiality service, and limited traffic flow 4173 confidentiality. 4175 $ Internet Protocol Security Option (IPSO) 4176 (I) Refers to one of three types of optional additions to IP 4177 datagrams. ISPDs SHOULD NOT use this term without a modifier to 4178 identify which type is meant. (See: IPsec.) 4180 - "DoD Basic Security Option" (IP option type 130): Defined for 4181 use on U.S. Department of Defense common user data networks. 4182 Identifies the U.S. classification level at which the datagram 4183 is to be protected and the protection authorities whose rules 4184 apply to the datagram. [R1108] 4186 A "protection authority" is a National Access Program (e.g., 4187 GENSER, SIOP-ESI, SCI, NSA, Department of Energy) or Special 4188 Access Program that specifies protection rules for transmission 4189 and processing of the information contained in the datagram. 4190 [R1108] 4192 - "DoD Extended Security Option" (IP option type 133): Permits 4193 additional security labeling information, beyond that present 4194 in the Basic Security Option, to be supplied in the datagram to 4195 meet the needs of registered authorities. [R1108] 4197 - "Common IP Security Option" (CIPSO) (IP option type 134): 4198 Designed by TSIG to carry hierarchic and non-hierarchic 4199 security labels. (Formerly called "Commercial IP Security 4200 Option".) Was published as Internet-Draft [CIPSO]; not advanced 4201 to RFC. 4203 $ Internet protocol suite 4204 See: (secondary definition in) Internet. 4206 $ Internet Security Association and Key Management Protocol (ISAKMP) 4207 (I) An Internet IPsec protocol [R2408] to negotiate, establish, 4208 modify, and delete security associations, and to exchange key 4209 generation and authentication data, independent of the details of 4210 any specific key generation technique, key establishment protocol, 4211 encryption algorithm, or authentication mechanism. 4213 (C) ISAKMP supports negotiation of security associations for 4214 protocols at all TCP/IP layers. By centralizing management of 4215 security associations, ISAKMP reduces duplicated functionality 4216 within each protocol. ISAKMP can also reduce connection setup 4217 time, by negotiating a whole stack of services at once. Strong 4218 authentication is required on ISAKMP exchanges, and a digital 4219 signature algorithm based on asymmetric cryptography is used 4220 within ISAKMP's authentication component. 4222 $ Internet Society (ISOC) 4223 (I) A professional society concerned with Internet development 4224 (including technical Internet Standards); with how the Internet is 4225 and can be used; and with social, political, and technical issues 4226 that result. The ISOC Board of Trustees approves appointments to 4227 the IAB from among nominees submitted by the IETF nominating 4228 committee. [R2026] 4230 $ Internet Standard 4231 (I) A specification, approved by the IESG and published as an RFC, 4232 that is stable and well-understood, is technically competent, has 4233 multiple, independent, and interoperable implementations with 4234 substantial operational experience, enjoys significant public 4235 support, and is recognizably useful in some or all parts of the 4236 Internet. [R2026] (See: RFC.) 4238 (C) The Internet Standards Process is an activity of the ISOC and 4239 is organized and managed by the IAB and the IESG. The process is 4240 concerned with all protocols, procedures, and conventions used in 4241 or by the Internet, whether or not they are part of the Internet 4242 Protocol Suite. (See: (secondary definition in) Internet.) The 4243 "Internet Standards Track" has three levels of increasing 4244 maturity: Proposed Standard, Draft Standard, and Standard. 4245 (Compare with: (levels in) ISO.) 4247 $ Internet Standards Process document (ISPD) 4248 (C) For convenience, this Glossary uses this term to refer to an 4249 RFC or an Internet-Draft that is produced as part of that process. 4250 However, neither the term nor the abbreviation is widely accepted 4251 and, therefore, SHOULD NOT be used in an ISPD unless it is locally 4252 accompanied by a definition equivalent to this one. (See: Internet 4253 Standard.) 4255 $ internet vs. Internet 4256 1. (I) Not capitalized: The term "internet" is a popular short 4257 synonym for "internetwork". 4259 2. (I) Capitalized: "The Internet" is the single, interconnected, 4260 worldwide system of commercial, government, educational, and other 4261 computer networks that share the protocol suite and the name and 4262 address spaces that are specified by the IAB [R2026]. 4264 (C) The suite is called the "Internet protocol suite" (IPS), but 4265 also is popularly know as "TCP/IP", because TCP and IP are two of 4266 its fundamental protocols. The IPS makes it possible for users of 4267 any one of the networks in the Internet to communicate with, or 4268 use the services located on, any of the other networks. 4270 (C) Although the Internet does have architectural principles 4271 [R1958], no Internet Standard defines a layered reference model 4272 for the IPS that is similar to the OSIRM. However, Internet 4273 community documents do refer (inconsistently) to layers: 4274 application, socket, transport, internetwork, network, data link, 4275 and physical. In this Glossary, Internet layers are referred to by 4276 name to avoid confusing them with OSIRM layers, which are referred 4277 to by number. 4279 $ internetwork 4280 (I) A system of interconnected networks; a network of networks. 4281 Usually shortened to "internet". (See: internet vs. Internet.) 4283 (C) An internet is usually built using OSI layer 3 gateways to 4284 connect a set of subnetworks. When the subnetworks differ in the 4285 OSI layer 3 protocol service they provide, the gateways sometimes 4286 implement a uniform internetwork protocol (e.g., IP) that operates 4287 at the top of layer 3 and hides the underlying heterogeneity from 4288 hosts that use communication services provided by the internet. 4289 (See: router.) 4291 $ intranet 4292 (I) A computer network, especially one based on Internet 4293 technology, that an organization uses for its own internal, and 4294 usually private, purposes and that is closed to outsiders. (See: 4295 extranet, virtual private network.) 4297 $ intruder 4298 (I) An entity that gains, or attempts to gain, access to a system 4299 (or system resource) without having authorization to do so. (See: 4300 cracker.) 4302 $ intrusion 4303 See: security intrusion. 4305 $ intrusion detection 4306 (I) A security service that monitors and analyzes system events 4307 for the purpose of noticing, and providing real-time or near real- 4308 time warning of, attempts to access system resources in an 4309 unauthorized manner. 4311 $ invalidity date 4312 (N) An X.509 CRL entry extension that "indicates the date at which 4313 it is known or suspected that the [revoked certificate's private 4314 key] was compromised or that the certificate should otherwise be 4315 considered invalid" [X509]. 4317 (C) This date may be earlier than the revocation date in the CRL 4318 entry, and may even be earlier than the date of issue of earlier 4319 CRLs. However, the invalidity date is not, by itself, sufficient 4320 for purposes of non-repudiation service. For example, to 4321 fraudulently repudiate a validly-generated signature, a private 4322 key holder may falsely claim that the key was compromised some 4323 time in the past. 4325 $ IP 4326 See: Internet Protocol. 4328 $ IP address 4329 (I) The (internetwork) address assigned to a networked computer 4330 for use by the Internet Protocol. 4332 (C) An IP version 4 [R0791] address is written as a series of four 4333 8-bit numbers separated by periods. For example, the address of 4334 the host named "rosslyn.bbn.com" is 192.1.7.10. For IP version 6 4335 [R2373], the preferred form is x:x:x:x:x:x:x:x, where the "x"s are 4336 the hexadecimal values of the eight 16-bit parts of the address. 4337 For example, FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 and 4338 1080:0:0:0:8:800:200C:417A. 4340 $ IP Security Option 4341 See: Internet Protocol Security Option. 4343 $ IPRA 4344 See: Internet Policy Registration Authority. 4346 $ IPsec 4347 See: Internet Protocol security. 4349 $ IPSO 4350 See: Internet Protocol Security Option. 4352 $ IPsec Key Exchange (IKE) 4353 (I) An Internet, IPsec, key-establishment protocol [R2409] (partly 4354 based on OAKLEY) that is intended for obtaining authenticated 4355 keying material for use with ISAKMP and for other security 4356 associations, such as in AH and ESP. 4358 $ ISAKMP 4359 See: Internet Security Association and Key Management Protocol. 4361 $ ISO 4362 (I) International Organization for Standardization, a voluntary, 4363 non-treaty, non-government organization, established in 1947, with 4364 voting members that are designated standards bodies of 4365 participating nations and non-voting observer organizations. (See: 4366 ANSI, ITU-T.) 4368 (C) Legally, ISO is a Swiss, non-profit, private organization. ISO 4369 and the IEC (the International Electrotechnical Commission) form 4370 the specialized system for worldwide standardization. (ISO is a 4371 class D member of ITU-T.) National bodies that are members of ISO 4372 or IEC participate in developing international standards through 4373 ISO and IEC technical committees that deal with particular fields 4374 of activity. (ANSI is the U.S. voting member of ISO.) Other 4375 international organizations, governmental and non-governmental, in 4376 liaison with ISO and IEC, also take part. In information 4377 technology, ISO and IEC have a joint technical committee, ISO/IEC 4378 JTC 1. 4380 (C) The ISO standards development process has four levels of 4381 increasing maturity: Working Draft (WD), Committee Draft (CD), 4382 Draft International Standard (DIS), and International Standard 4383 (IS). DISs adopted by JTC 1 are circulated to national bodies for 4384 voting, and publication as an IS requires approval by at least 75% 4385 of the national bodies casting a vote. (Compare with: (levels in) 4386 Internet Standard.) 4388 $ ISOC 4389 See: Internet Society. 4391 $ ISPD 4392 See: Internet Standards Process document. 4394 $ issue (a digital certificate or CRL) 4395 (I) Generate and sign a digital certificate (or CRL) and, usually, 4396 distribute it and make it available to potential certificate users 4397 (or CRL users). (See: certificate creation.) 4399 (C) The ABA Guidelines [ABA] explicitly limit this term to 4400 certificate creation, and exclude the act of publishing. In 4401 general usage, however, "issuing" a digital certificate (or CRL) 4402 includes not only certificate creation but also making it 4403 available to potential users, such as by storing it in a 4404 repository or other directory or otherwise publishing it. 4406 $ issuer 4407 1. (I) "Issuer" of a certificate or CRL: The CA that signs a 4408 digital certificate or CRL. 4410 (C) An X.509 certificate always includes the issuer's name. The 4411 name may include a common name value. 4413 2. (N) "Issuer" of a payment card: SET usage: "The financial 4414 institution or its agent that issues the unique primary account 4415 number to the cardholder for the payment card brand." [SET2] 4417 (C) The institution that establishes the account for a cardholder 4418 and issues the payment card also guarantees payment for authorized 4419 transactions that use the card in accordance with card brand 4420 regulations and local legislation. [SET1] 4422 $ ITAR 4423 See: International Traffic in Arms Regulations. 4425 $ ITSEC 4426 See: Information Technology System Evaluation Criteria. 4428 $ ITU-T 4429 (N) International Telecommunications Union--Telecommunication 4430 Standardization Sector (formerly "CCITT"), a United Nations treaty 4431 organization that is composed mainly of postal, telephone, and 4432 telegraph authorities of the member countries and that publishes 4433 standards called "Recommendations". (See: X.400, X.500.) 4435 (C) The Department of State represents the United States. ITU-T 4436 works on many kinds of communication systems. ITU-T cooperates 4437 with ISO on communication protocol standards, and many 4438 Recommendations in that area are also published as an ISO standard 4439 with and ISO name and number. 4441 $ IV 4442 See: initialization value. 4444 $ KDC 4445 See: Key Distribution Center. 4447 $ KEA 4448 See: Key Exchange Algorithm. 4450 $ KEK 4451 See: key-encrypting key. 4453 $ Kerberos 4454 (N) A system developed at the Massachusetts Institute of 4455 Technology that depends on passwords and symmetric cryptography 4456 (DES) to implement a ticket-based, peer entity authentication 4457 service and access control service distributed in a client-server 4458 network environment. [R1510, Stei] 4460 (C) Kerberos was developed by Project Athena and is named for the 4461 three-headed dog guarding Hades. 4463 $ key 4464 See: cryptographic key. 4466 $ key agreement (algorithm or protocol) 4467 (I) A key establishment method (especially one involving 4468 asymmetric cryptography) by which two or more entities, without 4469 prior arrangement except a public exchange of data (such as public 4470 keys), can each compute the same value, i.e., each independently 4471 generate the same secret key, that becomes known to both of them 4472 but cannot be computed by other entities. (Compare with: key 4473 transport. Also see: Diffie-Hellman, Key Exchange Algorithm.) 4475 (O) "A method for negotiating a key value on line without 4476 transferring the key, even in an encrypted form, e.g., the Diffie- 4477 Hellman technique." [X509] 4479 (O) "The procedure whereby two different parties generate shared 4480 symmetric keys such that any of the shared symmetric keys is a 4481 function of the information contributed by all legitimate 4482 participants, so that no party can predetermine the value of the 4483 key." [A9042] 4485 $ key authentication 4486 (N) "The assurance of the legitimate participants in a key 4487 agreement that no non-legitimate party possesses the shared 4488 symmetric key." [A9042] 4490 $ key center 4491 (I) A centralized key distribution process (used in symmetric 4492 cryptography), usually a separate computer system, that uses key- 4493 encrypting keys (master keys) to encrypt and distribute session 4494 keys needed in a community of users. 4496 (C) An ANSI standard [A9017] defines two types of key center: key 4497 distribution center and key translation center. 4499 $ key confirmation 4500 (N) "The assurance of the legitimate participants in a key 4501 establishment protocol that the intended parties sharing the 4502 symmetric key actually possess the shared symmetric key." [A9042] 4504 $ key distribution 4505 (I) A process that delivers a cryptographic key from the location 4506 where it is generated to the locations where it is used in a 4507 cryptographic algorithm. (See: key management.) 4509 $ key distribution center (KDC) 4510 (I) A type of key center (used in symmetric cryptography) that 4511 implements a key distribution protocol to provide keys (usually, 4512 session keys) to two (or more) entities that wish to communicate 4513 securely. (See: key translation center.) 4515 (C) A KDC distributes keys to Alice and Bob, who (a) wish to 4516 communicate with each other but do not currently share keys, (b) 4517 each share a KEK with the KDC, and (c) may not be able to generate 4518 or acquire keys by themselves. Alice requests the keys from the 4519 KDC. The KDC generates or acquires the keys and makes two 4520 identical sets. The KDC encrypts one set in the KEK it shares with 4521 Alice, and sends that encrypted set to Alice. The KDC encrypts the 4522 second set in the KEK it shares with Bob, and either sends that 4523 encrypted set to Alice for her to forward to Bob, or sends it 4524 directly to Bob (although the latter option is not supported in 4525 the ANSI standard [A9017]). 4527 $ key encapsulation 4528 See: (secondary definition in) key recovery. 4530 $ key-encrypting key (KEK) 4531 (I) A cryptographic key that is used to encrypt other keys, either 4532 DEKs or other KEKs, but usually is not used to encrypt application 4533 data. 4535 $ key escrow 4536 See: (secondary definition in) key recovery. 4538 $ key establishment (algorithm or protocol) 4539 (I) A process that combines the key generation and key 4540 distribution steps needed to set up or install a secure 4541 communication association. (See: key agreement, key transport.) 4543 (O) "The procedure to share a symmetric key among different 4544 parties by either key agreement or key transport." [A9042] 4546 (C) Key establishment involves either key agreement or key 4547 transport. In key transport, one entity does the key generation 4548 and then securely sends the secret key to the other entity. (Or 4549 each entity can generate a key and send it to the other entity, 4550 where the two keys are combined to form a session key.) For 4551 example, a message originator can generate a random session key 4552 and then use the Rivest-Shamir-Adleman algorithm to encrypt that 4553 key with the public key of the intended recipient. In key 4554 agreement, the session key is not sent from one entity to another. 4555 Instead, both entities, without prior arrangement except a public 4556 exchange of data, each compute the same value; i.e., each 4557 independently generates the same secret value, which cannot be 4558 computed by third parties. For example, a message originator and 4559 the intended recipient can each use their own private key and the 4560 other's public key in the Diffie-Hellman algorithm to compute a 4561 shared secret value, which then is used to derive a key to encrypt 4562 the message. 4564 $ Key Exchange Algorithm (KEA) 4565 (N) A key agreement algorithm that is similar to the Diffie- 4566 Hellman algorithm, uses 1024-bit asymmetric keys, and was 4567 developed and formerly classified at the "Secret" level by NSA. 4568 (See: CAPSTONE, CLIPPER, FORTEZZA, SKIPJACK.) 4570 (C) On 23 June 1998, the NSA announced that KEA had been 4571 declassified. 4573 $ key generator 4574 (I) A device or algorithm that uses mathematical rules to 4575 deterministically produce a pseudo-random sequence of 4576 cryptographic keys. 4578 $ key generation 4579 (I) A process that creates the sequence of symbols that comprise a 4580 cryptographic key. (See: key management.) 4582 $ key length 4583 (I) The number of symbols (usually bits) needed to be able to 4584 represent any of the possible values of a cryptographic key. 4586 $ key lifetime 4587 (N) MISSI usage: An attribute of a MISSI key pair that specifies a 4588 time span that bounds the validity period of any MISSI X.509 4589 public-key certificate that contains the public component of the 4590 pair. (See: cryptoperiod.) 4592 $ key management 4593 (I) The process of handling and controlling cryptographic keys and 4594 related material (such as initialization values) during their life 4595 cycle in a cryptographic system, including ordering, generating, 4596 distributing, storing, loading, escrowing, archiving, auditing, 4597 and destroying the material. (See: key distribution, key escrow, 4598 public-key infrastructure.) 4600 (O) "The generation, storage, distribution, deletion, archiving 4601 and application of keys in accordance with a security policy." 4602 [I7498 Part 2] 4604 (O) "The activities involving the handling of cryptographic keys 4605 and other related security parameters (e.g., IVs, counters) during 4606 the entire life cycle of the keys, including their generation, 4607 storage, distribution, entry and use, deletion or destruction, and 4608 archiving." [FP140] 4610 $ Key Management Protocol (KMP) 4611 (N) A protocol to establish a shared symmetric key between a pair 4612 (or a group) of users. (One version of KMP was developed by SDNS, 4613 and another by SILS.) 4615 $ key material identifier (KMID) 4616 (N) MISSI usage: A 64-bit identifier that is assigned to a key 4617 pair when the public key is bound in a MISSI X.509 public-key 4618 certificate. 4620 $ key pair 4621 (I) A set of mathematically related keys--a public key and a 4622 private key--that are used for asymmetric cryptography and are 4623 generated in a way that makes it computationally infeasible to 4624 derive the private key from knowledge of the public key (e.g., 4625 see: Diffie-Hellman, Rivest-Shamir-Adleman). 4627 (C) A key pair's owner discloses the public key to other system 4628 entities so they can use the key to encrypt data, verify a digital 4629 signature, compute a protected checksum, or generate a key in a 4630 key agreement algorithm. The matching private key is kept secret 4631 by the owner, who uses it to decrypt data, generate a digital 4632 signature, verify a protected checksum, or generate a key in a key 4633 agreement algorithm. 4635 $ key recovery 4636 1. (I) A process for learning the value of a cryptographic key 4637 that was previously used to perform some cryptographic operation. 4638 (See: cryptanalysis.) 4640 2. (I) Techniques that provide an intentional alternate (or 4641 secondary) means to access the key used for data confidentiality 4642 service in an encrypted association. [DOD98] 4644 (C) We assume that the encryption mechanism has a primary means of 4645 obtaining the key through a key establishment algorithm or 4646 protocol. For the secondary means, there are two classes of key 4647 recovery techniques--key escrow and key encapsulation: 4649 - "Key escrow": A key recovery technique for storing knowledge of 4650 a cryptographic key or parts thereof in the custody of one or 4651 more third parties called "escrow agents", so that the key can 4652 be recovered and used in specified circumstances. 4654 Key escrow is typically implemented with split knowledge 4655 techniques. For example, the Escrowed Encryption Standard 4656 [FP185] entrusts two components of a device-unique split key to 4657 separate escrow agents. The agents provide the components only 4658 to someone legally authorized to conduct electronic 4659 surveillance of telecommunications encrypted by that specific 4660 device. The components are used to reconstruct the device- 4661 unique key, and it is used to obtain the session key needed to 4662 decrypt communications. 4664 - "Key encapsulation": A key recovery technique for storing 4665 knowledge of a cryptographic key by encrypting it with another 4666 key and ensuring that that only certain third parties called 4667 "recovery agents" can perform the decryption operation to 4668 retrieve the stored key. 4670 Key encapsulation typically allows direct retrieval of the 4671 secret key used to provide data confidentiality. 4673 $ key space 4674 (I) The range of possible values of a cryptographic key; or the 4675 number of distinct transformations supported by a particular 4676 cryptographic algorithm. (See: key escrow.) 4678 $ key translation center 4679 (I) A type of key center (used in a symmetric cryptography) that 4680 implements a key distribution protocol to convey keys between two 4681 (or more) parties who wish to communicate securely. (See: key 4682 distribution center.) 4684 (C) A key translation center translates keys for future 4685 communication between Bob and Alice, who (a) wish to communicate 4686 with each other but do not currently share keys, (b) each share a 4687 KEK with the center, and (c) have the ability to generate or 4688 acquire keys by themselves. Alice generates or acquires a set of 4689 keys for communication with Bob. Alice encrypts the set in the KEK 4690 she shares with the center and sends the encrypted set to the 4691 center. The center decrypts the set, reencrypts the keys in the 4692 KEK it shares with Bob, and either sends that encrypted set to 4693 Alice for her to forward to Bob, or sends it directly to Bob 4694 (although this direct distribution is not supported in the ANSI 4695 standard [A9017]). 4697 $ key transport (algorithm or protocol) 4698 (I) A key establishment method by which a secret key is generated 4699 by one entity in a communication association and securely sent to 4700 another entity in the association. (Compare with: key agreement.) 4702 (O) "The procedure to send a symmetric key from one party to other 4703 parties. As a result, all legitimate participants share a common 4704 symmetric key in such a way that the symmetric key is determined 4705 entirely by one party." [A9042] 4707 $ key update 4708 (I) Derive a new key from an existing key. (See: certificate 4709 rekey.) 4711 $ key validation 4712 (N) "The procedure for the receiver of a public key to check that 4713 the key conforms to the arithmetic requirements for such a key in 4714 order to thwart certain types of attacks." [A9042] 4716 $ keyed hash 4717 (I) A cryptographic hash in which the mapping to a hash result is 4718 varied by a second input parameter that is a cryptographic key. 4719 (For example, see [R1828].) (See: checksum.) 4721 (C) If the input data set is changed, a new hash result cannot be 4722 correctly computed without knowledge of the secret key. Thus, the 4723 secret key protects the hash result so it can be used as a 4724 checksum even when there is a threat of an active attack on the 4725 data. 4727 (C) There are least two forms of keyed hash: (a) A function based 4728 on a keyed encryption algorithm. (For example, see: Data 4729 Authentication Code.) (b) A keyless hash that is enhanced by 4730 combining (for example, by concatenating) the input data set 4731 parameter with a key parameter before mapping to the hash result. 4733 $ keying material 4734 (I) Data (such as key pairs and initialization values) needed to 4735 establish and maintain a cryptographic security association. 4737 $ KMID 4738 See: key material identifier. 4740 $ known-plaintext attack 4741 (I) A cryptanalysis approach in which the analyst tries to 4742 determine the key from knowledge of some plaintext-ciphertext 4743 pairs (although the analyst may also know other clues, such as the 4744 cryptographic algorithm). 4746 $ L2F 4747 See: Layer 2 Forwarding Protocol. 4749 $ L2TP 4750 See: Layer 2 Tunneling Protocol. 4752 $ Language of Temporal Ordering Specification (LOTOS) 4753 (N) A language (ISO 8807-1990) for formal specification of 4754 computer network protocols; describes the order in which events 4755 occur. 4757 $ label 4758 See: security label. 4760 $ lattice model 4761 (I) A security model for flow control in a system, based on the 4762 "lattice" that is formed by the finite security levels in a system 4763 and their partial ordering. [Denn] (See: flow control, security 4764 level, security model.) 4766 $ Law Enforcement Access Field (LEAF) 4767 (N) A data item that is automatically embedded in data encrypted 4768 by devices (e.g., see: CLIPPER chip) that implement the Escrowed 4769 Encryption Standard. 4771 $ Layer 2 Forwarding Protocol (L2F) 4772 (N) An Internet protocol (originally developed by Cisco 4773 Corporation) that uses tunneling of PPP over IP to create a 4774 virtual extension of a dial-up link across a network, initiated by 4775 the dial-up server and transparent to the dial-up user. (See: 4776 L2TP.) 4778 $ Layer 2 Tunneling Protocol (L2TP) 4779 (N) An Internet client-server protocol that combines aspects of 4780 PPTP and L2F and supports tunneling of PPP over an IP network or 4781 over frame relay or other switched network. (See: virtual private 4782 network.) 4784 (C) PPP can in turn encapsulate any OSI layer 3 protocol. Thus, 4785 L2TP does not specify security services; it depends on protocols 4786 layered above and below it to provide any needed security. 4788 $ LDAP 4789 See: Lightweight Directory Access Protocol. 4791 $ least privilege 4792 (I) The principle that a security architecture should be designed 4793 so that each system entity is granted the minimum system resources 4794 and authorizations that the entity needs to do its work. (See: 4795 economy of mechanism.) 4797 (C) This principle tends to limit damage that can be caused by an 4798 accident, error, or unauthorized act. 4800 $ Lightweight Directory Access Protocol (LDAP) 4801 (N) A client-server protocol that supports basic use of the X.500 4802 Directory (or other directory servers) without incurring the 4803 resource requirements of the full Directory Access Protocol (DAP). 4804 [R1777] 4806 (C) Designed for simple management and browser applications that 4807 provide simple read/write interactive directory service. Supports 4808 both simple authentication and strong authentication of the client 4809 to the directory server. 4811 $ link 4812 (I) Subnetwork usage: A point-to-point communication channel 4813 connecting two computers, especially one between two subnetwork 4814 packet switches that is implemented at OSI layer 2. (See: link 4815 encryption.) 4817 (C) Switches assume that links are logically passive. If a switch 4818 at one end of a link sends a sequence of bits, the sequence simply 4819 arrives at the other end after a finite time, although some bits 4820 may have been changed either accidentally (errors) or by active 4821 wiretapping. 4823 (I) World Wide Web usage: See: hyperlink. 4825 $ link encryption 4826 $ link-by-link encryption 4827 (I) Stepwise protection of data that flows between two points in a 4828 network, provided by encrypting data separately on each network 4829 link--i.e., by encrypting data when it leaves a host or subnetwork 4830 switch and decrypting when it arrives at the next host or switch. 4831 Each link may use a different key or even a different algorithm. 4832 [R1455] (See: end-to-end encryption.) 4834 $ logic bomb 4835 (I) Malicious logic that activates when specified conditions are 4836 met and causes denial of service or damage to system resources. 4837 (See: Trojan horse, virus, worm.) 4839 $ login 4840 (I) The act of a system entity gaining access to a session of 4841 using system resources; usually accomplished by providing a user 4842 name and password to an access control system that authenticates 4843 the user. 4845 (C) Derives from "log" file", a security audit trail that records 4846 security events, such as the beginning of sessions, and who 4847 initiates them. 4849 $ LOTOS 4850 See: Language of Temporal Ordering Specification. 4852 $ MAC 4853 See: mandatory access control, Message Authentication Code. 4855 $ malicious logic 4856 (I) Hardware, software, or firmware that is intentionally included 4857 or inserted in a system for a harmful purpose. (See: logic bomb, 4858 Trojan horse, virus, worm.) 4860 $ malware 4861 (I) A contraction of "malicious software". (See: malicious logic.) 4863 (D) ISPDs SHOULD NOT use this term because it is not listed in 4864 most dictionaries and could confuse international readers. 4866 $ man-in-the-middle 4867 (I) A form of active wiretapping attack in which the attacker 4868 intercepts and selectively modifies communicated data in order to 4869 masquerade as one or more of the entities involved in a 4870 communication association. (See: hijack attack, piggyback attack.) 4872 (C) For example, suppose Alice and Bob try to establish a session 4873 key by using the Diffie-Hellman algorithm without data origin 4874 authentication service. A "man in the middle" could block direct 4875 communication between Alice and Bob--and then masquerade as Alice 4876 sending data to Bob, masquerade as Bob sending data to Alice, 4877 establish separate session keys with each of them, and function as 4878 a clandestine proxy server between them in order to capture or 4879 modify sensitive information that Alice and Bob think they are 4880 sending only to each other. 4882 $ mandatory access control (MAC) 4883 (I) An access control service that enforces a security policy 4884 based on comparing (a) security labels that indicate how sensitive 4885 or critical system resources are with (b) security clearances that 4886 authorize system entities to access certain resources. (See: 4887 discretionary access control, rule-based security policy.) 4889 (C) This kind of access control is called "mandatory" because an 4890 entity that has clearance to access a resource may not, just by 4891 its own volition, enable another entity to access that resource. 4893 (O) "A means of restricting access to objects based on the 4894 sensitivity (as represented by a label) of the information 4895 contained in the objects and the formal authorization (i.e., 4896 clearance) of subjects to access information of such sensitivity." 4897 [DOD1] 4899 $ manipulation detection code 4900 (D) ISPDs SHOULD NOT use this term as a synonym for "checksum" 4901 because the word "manipulation" implies protection against active 4902 attacks, which an ordinary checksum might not provide. Instead, if 4903 such protection is intended, use "protected checksum" or some 4904 particular type thereof, depending on which is meant. If such 4905 protection is not intended, use "error detection code" or some 4906 specific type of checksum that is not protected. 4908 $ masquerade attack 4909 (I) A type of attack in which one system entity illegitimately 4910 poses as (assumes the identity of) another entity. (See: spoofing 4911 attack.) 4913 $ MCA 4914 See: merchant certificate authority. 4916 $ MD2 4917 (N) A cryptographic hash [R1319] that produces a 128-bit hash 4918 result, was designed by Ron Rivest, and is similar to MD4 and MD5 4919 but slower. (See: message digest.) 4921 $ MD4 4922 (N) A cryptographic hash [R1320] that produces a 128-bit hash 4923 result and was designed by Ron Rivest. (See: message digest and 4924 SHA-1.) 4926 $ MD5 4927 (N) A cryptographic hash [R1321] that produces a 128-bit hash 4928 result and was designed by Ron Rivest to be an improved version of 4929 MD4. 4931 $ merchant 4932 (O) SET usage: "A seller of goods, services, and/or other 4933 information who accepts payment for these items electronically." 4934 [SET2] A merchant may also provide electronic selling services 4935 and/or electronic delivery of items for sale. With SET, the 4936 merchant can offer its cardholders secure electronic interactions, 4937 but a merchant that accepts payment cards is required to have a 4938 relationship with an acquirer. [SET1, SET2] 4940 $ merchant certificate 4941 (O) SET usage: A public-key certificate issued to a merchant. 4942 Sometimes used to refer to a pair of such certificates where one 4943 is for digital signature use and the other is for encryption. 4945 $ merchant certification authority (MCA) 4946 (O) SET usage: A CA that issues digital certificates to merchants 4947 and is operated on behalf of a payment card brand, an acquirer, or 4948 another party according to brand rules. Acquirers verify and 4949 approve requests for merchant certificates prior to issuance by 4950 the MCA. An MCA does not issue a CRL, but does distribute CRLs 4951 issued by root CAs, brand CAs, geopolitical CAs, and payment 4952 gateway CAs. [SET2] 4954 $ mesh PKI 4955 (I) A non-hierarchical PKI architecture in which there are several 4956 trusted CAs rather than a single root. Each certificate user bases 4957 path validations on the public key of one of the trusted CAs, 4958 usually the one that issued that user's own public-key 4959 certificate. Rather than having superior-to-subordinate 4960 relationships between CAs, the relationships are peer-to-peer, and 4961 CAs issue cross-certificates to each other. (See: hierarchical 4962 PKI, trust-file PKI.) 4964 $ message authentication code vs. Message Authentication Code (MAC) 4965 1. (N) Capitalized: "(The) Message Authentication Code" refers to 4966 an ANSI standard [A9009] for a checksum that is computed by a 4967 keyed hash that is based on DES. (Also known as the U.S. 4968 Government standard Data Authentication Code [FP113].) 4970 (C) The ANSI standard MAC algorithm is equivalent to cipher block 4971 chaining with IV = 0. MAC is also known as the U.S. Government 4972 standard Data Authentication Code [FP113]. 4974 2. (D) Not capitalized: ISPDs SHOULD NOT use "message 4975 authentication code", because this term mixes concepts in a 4976 potentially misleading way. Instead, use "checksum", "error 4977 detection code", "hash", "keyed hash", "Message Authentication 4978 Code", or "protected checksum", depending on what is meant. 4980 (C) The uncapitalized form is often misleadingly used as a synonym 4981 for keyed hash. The word "message" is misleading because it 4982 implies that the mechanism is particularly suitable for or limited 4983 to electronic mail (see: Message Handling Systems). The word 4984 "authentication" is misleading because the mechanism primarily 4985 serves a data integrity function rather than an authentication 4986 function. The word "code" is misleading because it implies that 4987 either encoding or encryption is involved, or that the term refers 4988 to computer software. 4990 $ message digest 4991 (D) ISPDs SHOULD NOT use this term as a synonym for "hash result" 4992 because it unnecessarily duplicates the meaning of the other, more 4993 general term and mixes concepts in a potentially misleading way. 4994 (See: cryptographic hash, Message Handling System.) 4996 $ Message Handling Systems ` 4997 (I) A ITU-T/ISO system concept, which encompasses the notion of 4998 electronic mail but defines more comprehensive OSI systems and 4999 services that enable users to exchange messages on a store-and- 5000 forward basis. (The ISO equivalent is "Message Oriented Text 5001 Interchange System".) (See: X.400.) 5003 $ message indicator 5004 (D) ISPDs SHOULD NOT use this term as a synonym for 5005 "initialization value" because it mixes concepts in a potentially 5006 misleading way. 5008 $ message integrity check 5009 $ message integrity code 5010 (D) ISPDs SHOULD NOT use these terms because they mix concepts in 5011 a potentially misleading way. (The word "message" is misleading 5012 because it suggests that the mechanism is particularly suitable 5013 for or limited to electronic mail. The word "code" is misleading 5014 because it suggests that either encoding or encryption is 5015 involved, or that the term refers to computer software.) Instead, 5016 use "checksum", "error detection code", "hash", "keyed hash", 5017 "Message Authentication Code", or "protected checksum", depending 5018 on what is meant. 5020 $ Message Security Protocol (MSP) 5021 (N) A secure message handling protocol [SDNS7] for use with X.400 5022 and Internet mail protocols. Developed by NSA's SDNS program and 5023 used in the U.S. Defense Message System. 5025 $ MHS 5026 See: message handling system. 5028 $ MIME 5029 See: Multipurpose Internet Mail Extensions. 5031 $ MIME Object Security Services (MOSS) 5032 (I) An Internet protocol [R1848] that applies end-to-end 5033 encryption and digital signature to MIME message content, using 5034 symmetric cryptography for encryption and asymmetric cryptography 5035 for key distribution and signature. MOSS is based on features and 5036 specifications of PEM. (See: S/MIME.) 5038 $ Minimum Interoperability Specification for PKI Components (MISPC) 5039 (N) A technical description to provide a basis for interoperation 5040 between PKI components from different vendors; consists primarily 5041 of a profile of certificate and CRL extensions and a set of 5042 transactions for PKI operation. [MISPC] 5044 $ MISPC 5045 See: Minimum Interoperability Specification for PKI Components. 5047 $ MISSI 5048 (N) Multilevel Information System Security Initiative, an NSA 5049 program to encourage development of interoperable, modular 5050 products for constructing secure network information systems in 5051 support of a wide variety of Government missions. (See: MSP.) 5053 $ MISSI user 5054 (O) MISSI usage: A system entity that is the subject of one or 5055 more MISSI X.509 public-key certificates issued under a MISSI 5056 certification hierarchy. (See: personality.) 5058 (C) MISSI users include both end users and the authorities that 5059 issue certificates. A MISSI user is usually a person but may be a 5060 machine or other automated process. Some machines are required to 5061 operate non-stop. To avoid downtime needed to exchange the 5062 FORTEZZA cards of machine operators at shift changes, the machines 5063 may be issued their own cards, as if they were persons. 5065 $ mode 5066 $ mode of operation 5067 (I) Encryption usage: A technique for enhancing the effect of a 5068 cryptographic algorithm or adapting the algorithm for an 5069 application, such as applying a block cipher to a sequence of data 5070 blocks or a data stream. (See: electronic codebook, cipher block 5071 chaining, cipher feedback, output feedback.) 5073 (I) System operation usage: A type of security policy that states 5074 the range of classification levels of information that a system is 5075 permitted to handle and the range of clearances and authorizations 5076 of users who are permitted to access the system. (See: dedicated 5077 security mode, multilevel security mode, partitioned security 5078 mode, system high security mode.) 5080 $ modulus 5081 (I) The defining constant in modular arithmetic, and usually a 5082 part of the public key in asymmetric cryptography that is based on 5083 modular arithmetic. (See: Diffie-Hellman, Rivest-Shamir-Adleman.) 5085 $ Morris Worm 5086 (I) A worm program written by Robert T. Morris, Jr. that flooded 5087 the ARPANET in November, 1988, causing problems for thousands of 5088 hosts. (See: worm.) 5090 $ MOSS 5091 See: MIME Object Security Services. 5093 $ MSP 5094 See: Message Security Protocol. 5096 $ multilevel secure (MLS) 5097 (I) A class of system that has system resources (particularly 5098 stored information) at more than one security level (i.e., has 5099 different types of sensitive resources) and that permits 5100 concurrent access by users who differ in security clearance and 5101 need-to-know, but is able to prevent the users from accessing 5102 resources for which they lack authorization. 5104 $ multilevel security mode 5105 (I) A mode of operation of an information system, that allows two 5106 or more classification levels of information to be processed 5107 concurrently within the same system when not all users have a 5108 clearance or formal access authorization for all data handled by 5109 the AIS. 5111 (C) This mode is defined formally in U.S. Department of Defense 5112 policy regarding system accreditation [DOD2], but the term is also 5113 used outside the Defense Department and outside the Government. 5115 $ Multipurpose Internet Mail Extensions (MIME) 5116 (I) An Internet protocol [R2045] that enhances the basic format of 5117 Internet electronic mail messages [R0822] to be able to use 5118 character sets other than US-ASCII for textual headers and text 5119 content, and to carry non-textual and multi-part content. (See: 5120 S/MIME.) 5122 $ mutual suspicion 5123 (I) The state that exists between two interacting system entities 5124 in which neither entity can trust the other to function correction 5125 with regard to some security requirement. 5127 $ National Computer Security Center (NCSC) 5128 (N) A U.S. Department of Defense organization, housed in NSA, that 5129 has responsibility for encouraging widespread availability of 5130 trusted computer systems throughout the Federal Government. It has 5131 established criteria for, and performs evaluations of, computer 5132 and network systems that have a trusted computing base. (See: 5133 Evaluated Products List, Rainbow Series, TCSEC.) 5135 $ National Information Assurance Partnership (NIAP) 5136 (N) An organization created by NIST and NSA to enhance the quality 5137 of commercial products for information security and increase 5138 consumer confidence in those products through objective evaluation 5139 and testing methods. 5141 (C) NIAP is registered, through the U.S. Department of Defense, as 5142 a National Performance Review Reinvention Laboratory. NIAP 5143 functions include the following: 5145 - Developing tests, test methods, and other tools that developers 5146 and testing laboratories may use to improve and evaluate 5147 security products. 5148 - Collaborating with industry and others on research and testing 5149 programs. 5150 - Using the Common Criteria to develop protection profiles and 5151 associated test sets for security products and systems. 5152 - Cooperating with the NIST National Voluntary Laboratory 5153 Accreditation Program to develop a program to accredit private- 5154 sector laboratories for the testing of information security 5155 products using the Common Criteria. 5156 - Working to establish a formal, international mutual recognition 5157 scheme for a Common Criteria-based evaluation. 5159 $ National Institute of Standards and Technology (NIST) 5160 (N) A U.S. Department of Commerce agency that promotes U.S. 5161 economic growth by working with industry to develop and apply 5162 technology, measurements, and standards. Has primary Government 5163 responsibility for INFOSEC standards for unclassified but 5164 sensitive information. (See: ANSI, DES, DSA, DSS, FIPS, NIAP, 5165 NSA.) 5167 $ National Security Agency (NSA) 5168 (N) A U.S. Department of Defense intelligence agency that has 5169 primary Government responsibility for INFOSEC for classified 5170 information and for unclassified but sensitive information handled 5171 by national security systems. (See: FORTEZZA, KEA, MISSI, NIAP, 5172 NIST, SKIPJACK.) 5174 $ need-to-know 5175 (I) The necessity for access to, knowledge of, or possession of 5176 specific information required to carry out official duties. 5178 (C) This criterion is used in security procedures that require a 5179 custodian of sensitive information, prior to disclosing the 5180 information to someone else, to establish that the intended 5181 recipient has proper authorization to access the information. 5183 $ network 5184 See: computer network. 5186 $ NIAP 5187 See: National Information Assurance Partnership. 5189 $ NIST 5190 See: National Institute of Standards and Technology. 5192 $ NLSP 5193 Network Layer Security Protocol. An OSI protocol (IS0 11577) for 5194 end-to-end encryption services at the top of OSI layer 3. NLSP is 5195 derived from an SDNS protocol, SP3, but is much more complex. 5197 $ no-lone zone 5198 (I) A room or other space to which no person may have 5199 unaccompanied access and that, when occupied, is required to be 5200 occupied by two or more appropriately authorized persons. (See: 5201 dual control.) 5203 $ nonce 5204 (I) A random or non-repeating value that is included in data 5205 exchanged by a protocol, usually for the purpose of guaranteeing 5206 liveness and thus detecting and protecting against replay attacks. 5208 $ non-critical 5209 See: critical (extension of certificate). 5211 $ non-repudiation service 5212 (I) A security service that provide protection against false 5213 denial of involvement in a communication. (See: repudiation.) 5215 (C) Non-repudiation service does not and cannot prevent an entity 5216 from repudiating a communication. Instead, the service provides 5217 evidence that can be stored and later presented to a third party 5218 to resolve disputes that arise if and when a communication is 5219 repudiated by one of the entities involved. There are two basic 5220 kinds of non-repudiation service: 5222 - "Non-repudiation with proof of origin" provides the recipient 5223 of data with evidence that proves the origin of the data, and 5224 thus protects the recipient against an attempt by the 5225 originator to falsely deny sending the data. This service can 5226 be viewed as a stronger version of an data origin 5227 authentication service, in that it proves authenticity to a 5228 third party. 5230 - "Non-repudiation with proof of receipt" provides the originator 5231 of data with evidence that proves the data was received as 5232 addressed, and thus protects the originator against an attempt 5233 by the recipient to falsely deny receiving the data. 5235 (C) Phases of a Non-Repudiation Service: Ford [For94, For97] uses 5236 the term "critical action" to refer to the act of communication 5237 that is the subject of the service: 5239 -------- -------- -------- -------- -------- . -------- 5240 Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6: 5241 Request Generate Transfer Verify Retain . Resolve 5242 Service Evidence Evidence Evidence Evidence . Dispute 5243 -------- -------- -------- -------- -------- . -------- 5245 Service Critical Evidence Evidence Archive . Evidence 5246 Request => Action => Stored => Is => Evidence . Is 5247 Is Made Occurs For Later Tested In Case . Verified 5248 and Use | ^ Critical . ^ 5249 Evidence v | Action Is . | 5250 Is +-------------------+ Repudiated . | 5251 Generated |Verifiable Evidence|------> ... . ----+ 5252 +-------------------+ 5254 1. Before the critical action, the service requester asks, either 5255 implicitly or explicitly, to have evidence of the action be 5256 generated. 5257 2. When the critical action occurs, evidence is generated by a 5258 process involving the potential repudiator and possibly also a 5259 trusted third party. 5260 3. The evidence is transferred to the requester, or stored by a 5261 third party, for later use if needed. 5262 4. The entity that holds the evidence tests to be sure that it 5263 will suffice if a dispute arises. 5264 5. The evidence is retained for possible future retrieval and use. 5266 6. In this phase, which occurs only if the critical action is 5267 repudiated, the evidence is retrieved from storage, presented, 5268 and verified to resolve the dispute. 5270 $ no-PIN ORA (NORA) 5271 (O) MISSI usage: An organizational RA that operates in a mode in 5272 which the ORA performs no card management functions and, 5273 therefore, does not require knowledge of either the SSO PIN or 5274 user PIN for an end user's FORTEZZA PC card. 5276 $ NORA 5277 See: no-PIN ORA. 5279 $ notarization 5280 (I) Registration of data under the authority or in the care of a 5281 trusted third party, thus making it possible to provide subsequent 5282 assurance of the accuracy of characteristics claimed for the data, 5283 such as content, origin, time, and delivery. [I7498 Part 2] (See: 5284 digital notary.) 5286 $ NULL encryption algorithm 5287 (I) An algorithm [R2410] that does nothing to alter plaintext 5288 data. It originated because of IPsec ESP, which always specifies 5289 the use of an encryption algorithm to provide confidentiality. The 5290 NULL encryption algorithm is a convenient way to represent the 5291 option of not applying encryption in ESP (or in any other context 5292 where this is needed). 5294 $ OAKLEY 5295 (I) An key establishment protocol [R2412] (proposed for IPsec but 5296 superseded by IPsec Key Exchange) that is based on the Diffie- 5297 Hellman algorithm and designed to be a compatible component of 5298 ISAKMP. In addition to securely sharing a secret key between two 5299 entities, OAKLEY provides authentication service to ensure the 5300 entities of each other's identity, even if the exchange is 5301 attacked by active wiretapping. 5303 (C) Establishes a shared key with an assigned identifier and 5304 associated authenticated identities for two parties. Each key is 5305 associated with algorithms used for authentication, 5306 confidentiality, and one-way functions. Related to STS, sharing 5307 the similarity of authenticating the Diffie-Hellman exponentials 5308 and using them for determining a shared session key, and also of 5309 achieving public-key forward secrecy for the shared key. Supports 5310 key updates, incorporation of keys distributed by out-of-band 5311 mechanisms, and user-defined abstract group structures for use 5312 with Diffie-Hellman. 5314 $ object 5315 (I) Trusted computer system modeling usage: A system element that 5316 contains or receives information. (See: Bell-LaPadula Model, 5317 trusted computer system.) 5319 $ object identifier (OID) 5320 (I) An official, globally unique name for a thing, written as a 5321 sequence of integers formed and assigned as defined in the ASN.1 5322 standard and used to reference the thing in abstract 5323 specifications and during the negotiation of security services in 5324 a protocol. 5326 (O) "A value (distinguishable from all other such values) which is 5327 associated with an object." [X680] 5329 (C) Objects named by OIDs are leaves of the object identifier tree 5330 (which is similar to but different from the X.500 Directory 5331 Information Tree). Each arc (i.e., each branch of the tree) is 5332 labeled with a non-negative integer. An OID is the sequence of 5333 integers on the path leading from the root of the tree to a named 5334 object. 5336 (C) The OID tree has three arcs immediately below the root: {0} 5337 for use by ITU-T, {1} for use by ISO, and {2} for use by both 5338 jointly. Below ITU-T are four arcs, where {0 0} is for ITU-T 5339 recommendations. Below {0 0} are 26 arcs, one for each series of 5340 recommendations starting with the letters A to Z, and below these 5341 are arcs for each recommendation. Thus, the OID for ITU-T 5342 Recommendation X.509 is {0 0 24 509}. Below ISO are four arcs, 5343 where {1 0 }is for ISO standards, and below these are arcs for 5344 each ISO standard. Thus, the OID for ISO/IEC 9594-8 (the ISO 5345 number for X.509) is {1 0 9594 8}. 5347 (C) The following are additional examples: ANSI registers 5348 organization names below the branch {joint-iso-ccitt(2) 5349 country(16) US(840) organization(1)}. The NIST CSOR records PKI 5350 objects below the branch {joint-iso-ccitt(2) country(16) us(840) 5351 gov(101) csor(3) pki(4)}. The U.S. Department of Defense registers 5352 INFOSEC objects below the branch {joint-iso-ccitt(2) country(16) 5353 us(840) organization(1) gov(101) dod(2) infosec(1)}. The OID for 5354 the PKIX private extension is defined in an arc below the arc for 5355 the PKIX name space, as {iso(1) identified-organization(3) dod(6) 5356 internet(1) security(5) mechanisms(5) pkix(7) 1 1}. 5358 $ object reuse 5359 (N) "The reassignment and reuse of a storage medium (e.g., page 5360 frame, disk sector, magnetic tape) that once contained one or more 5361 [information] objects. To be securely reused and assigned to a new 5362 subject, storage media must contain no residual data (magnetic 5363 remanence) from the object(s) previously contained in the media." 5364 [NCS04] 5366 $ OCSP 5367 See: On-line Certificate Status Protocol. 5369 $ octet 5370 (I) A data unit of eight bits. (See: byte.) 5372 (c) This term is used in networking (especially in OSI standards) 5373 in preference to "byte", because some systems use "byte" for data 5374 storage units of a size other than eight. 5376 $ OFB 5377 See: output feedback. 5379 ohnosecond 5380 (C) That minuscule fraction of time in which you realize that your 5381 private key has been compromised. 5383 $ OID 5384 See: object identifier. 5386 $ On-line Certificate Status Protocol (OCSP) 5387 (I) An Internet protocol used by a client to obtain from a server 5388 the validity status and other information concerning a digital 5389 certificate. 5391 (C) In some applications, such as those involving high-value 5392 commercial transactions, it may be necessary to obtain certificate 5393 revocation status that is more timely than is possible with CRLs 5394 or to obtain other kinds of status information. OCSP may be used 5395 to determine the current revocation status of a digital 5396 certificate, in lieu of or as a supplement to checking against a 5397 periodic CRL. An OCSP client issues a status request to an OCSP 5398 server and suspends acceptance of the certificate in question 5399 until the server provides a response. 5401 $ one-time pad 5402 (I) An encryption algorithm in which the key is a random sequence 5403 of symbols and each symbol is used for encryption only one time-- 5404 to encrypt only one plaintext symbol to produce only one 5405 ciphertext symbol--and a copy of the key is used similarly for 5406 decryption. 5408 (C) To ensure one-time use, the copy of the key used for 5409 encryption is destroyed after use, as is the copy used for 5410 decryption. This is the only encryption algorithm that is truly 5411 unbreakable, even given unlimited resources for cryptanalysis 5412 [Schn], but key management costs and synchronization problems make 5413 it impractical except in special situations. 5415 $ one-time password 5416 $ One-Time Password (OTP) 5417 1. Not capitalized: A "one-time password" is a simple 5418 authentication technique in which each password is used only once 5419 as authentication information that verifies an identity. This 5420 technique counters the threat of a replay attack that uses 5421 passwords captured by wiretapping. 5423 2. Capitalized: "One-Time Password" is an Internet protocol that 5424 is based on S/KEY and uses a cryptographic hash function to 5425 generate one-time passwords for use as authentication information 5426 in system login and other processes that need protection against 5427 replay attacks. [R1938] 5429 $ one-way encryption 5430 (I) Irreversible transformation of plaintext to ciphertext, such 5431 that the plaintext cannot be recovered from the ciphertext by 5432 other than exhaustive procedures even if the cryptographic key is 5433 known. (See: encryption.) 5435 $ one-way function 5436 (I) "A (mathematical) function, f, which is easy to compute, but 5437 which for a general value y in the range, it is computationally 5438 difficult to find a value x in the domain such that f(x) = y. 5439 There may be a few values of y for which finding x is not 5440 computationally difficult." [X509] 5442 (D) ISPDs SHOULD NOT use this term as a synonym for "cryptographic 5443 hash". 5445 $ open security environment 5446 (O) DoD usage: A system environment that meets at least one of the 5447 following conditions: (a) Application developers (including 5448 maintainers) do not have sufficient clearance or authorization to 5449 provide an acceptable presumption that they have not introduced 5450 malicious logic. (b) Configuration control does not provide 5451 sufficient assurance that applications and the equipment are 5452 protected against the introduction of malicious logic prior to and 5453 during the operation of system applications. [NCS04] (See: closed 5454 security environment.) 5456 $ Open Systems Interconnection (OSI) Reference Model (OSIRM) 5457 (N) A joint ISO/ITU-T standard [I7498 Part 1] for a seven-layer, 5458 architectural communication framework for interconnection of 5459 computers in networks. 5461 (C) OSI-based standards include communication protocols that are 5462 mostly incompatible with the Internet Protocol Suite, but also 5463 include security models, such as X.509, that are used in the 5464 Internet. 5466 (C) The OSIRM layers, from highest to lowest, are (7) Application, 5467 (6) Presentation, (5) Session, (4) Transport, (3) Network, (2) 5468 Data Link, and (1) Physical. In this Glossary, these layers are 5469 referred to by number to avoid confusing them with Internet 5470 Protocol Suite layers, which are referred to by name. 5472 (C) Some unknown person described how the OSI layers correspond to 5473 the seven deadly sins: 5475 7. Wrath: Application is always angry at the mess it sees below 5476 itself. (Hey! Who is it to be pointing fingers?) 5477 6. Sloth: Presentation is too lazy to do anything productive by 5478 itself. 5479 5. Lust: Session is always craving and demanding what truly 5480 belongs to Application's functionality. 5481 4. Avarice: Transport wants all of the end-to-end functionality. 5482 (Of course, it deserves it, but life isn't fair.) 5483 3. Gluttony: (Connection-Oriented) Network is overweight and 5484 overbearing after trying too often to eat Transport's lunch. 5485 2. Envy: Poor Data Link is always starved for attention. (With 5486 ATM, maybe now it is feeling less neglected.) 5487 1. Pride: Physical has managed to avoid much of the controversy, 5488 and nearly all of the embarrassment, suffered by the others. 5490 (C) John G. Fletcher described how the OSI layers also correspond 5491 to Snow White's dwarf friends: 5493 7. Doc: Application acts as if it is in charge, but sometimes 5494 muddles its syntax. 5495 6. Sleepy: Presentation is indolent, being guilty of the sin of 5496 Sloth. 5497 5. Dopey: Session is confused because its charter is not very 5498 clear. 5499 4. Grumpy: Transport is irritated because Network has encroached 5500 on Transport's turf. 5501 3. Happy: Network smiles for the same reason that Transport is 5502 irritated. 5503 2. Sneezy: Data Link makes loud noises in the hope of attracting 5504 attention. 5505 1. Bashful: Physical quietly does its work, unnoticed by the 5506 others. 5508 $ operational integrity 5509 (I) A synonym for "system integrity"; emphasizes the actual 5510 performance of system functions rather than just the ability to 5511 perform them. 5513 $ operations security (OPSEC) 5514 (I) A process to identify, control, and protect evidence of the 5515 planning and execution of sensitive activities and operations, and 5516 thereby prevent potential adversaries from gaining knowledge of 5517 capabilities and intentions. 5519 $ OPSEC 5520 See: operations security. 5522 $ ORA 5523 See: organizational registration authority. 5525 $ Orange Book 5526 (D) ISPDs SHOULD NOT use this term as a synonym for "Trusted 5527 Computer System Evaluation Criteria" [CSC001, DOD1]. Instead, use 5528 the full, proper name of the document or, in subsequent 5529 references, the conventional abbreviation "TCSEC". (See: (usage 5530 note under) Green Book.) 5532 $ organizational certificate 5533 (O) MISSI usage: A type of MISSI X.509 public-key certificate that 5534 is issued to support organizational message handling for the U.S. 5535 Government's Defense Message System. 5537 $ organizational registration authority (ORA) 5538 (I) General usage: An RA for an organization. 5540 (O) MISSI usage: The MISSI implementation of RA. A MISSI end 5541 entity that assists a PCA, CA, or SCA to register other end 5542 entities, by gathering, verifying, and entering data and 5543 forwarding it to the signing authority, and may also assist with 5544 card management functions. An ORA is a local administrative 5545 authority, and the term refers both to the office or role, and to 5546 the person who fills that office. An ORA does not sign 5547 certificates, CRLs, or CKLs. (See: no-PIN ORA, SSO-PIN ORA, user- 5548 PIN ORA.) 5550 $ origin authentication 5551 $ origin authenticity 5552 (D) ISPDs SHOULD NOT use these terms because they look like 5553 careless use of an internationally standardized term. Instead, use 5554 "data origin authentication" or "data origin authentication 5555 service". 5557 $ OSI 5558 $ OSIRM 5559 See: Open Systems Interconnection Reference Model. 5561 $ OTP 5562 See: One-Time Password. 5564 $ out of band 5565 (I) Transfer of information using a channel that is outside (i.e., 5566 separate from) the channel that is normally used. (See: covert 5567 channel.) 5569 (C) Out-of-band mechanisms are often used to distribute shared 5570 secrets (e.g., a symmetric key) or other sensitive information 5571 items (e.g., a root key) that are needed to initialize or 5572 otherwise enable the operation of cryptography or other security 5573 mechanisms. (See: key distribution.) 5575 $ output feedback (OFB) 5576 (N) A block cipher mode [FP081] that modifies electronic codebook 5577 mode to operate on plaintext segments of variable length less than 5578 or equal to the block length. 5580 (C) This mode operates by directly using the algorithm's 5581 previously generated output block as the algorithm's next input 5582 block (i.e., by "feeding back" the output block) and combining 5583 (exclusive OR-ing) the output block with the next plaintext 5584 segment (of block length or less) to form the next ciphertext 5585 segment. 5587 $ outside attack 5588 $ outsider attack 5589 See: (secondary definition in) attack. 5591 $ P1363 5592 See: IEEE P1363. 5594 $ PAA 5595 See: policy approving authority. 5597 $ packet filter 5598 See: (secondary definition in) filtering router. 5600 $ pagejacking 5601 (I) A contraction (of Web PAGE hiJACKING); a masquerade attack in 5602 which the attacker copies (steals) a home page or other material 5603 from the target server, rehosts the page on a server the attacker 5604 controls, and causes the rehosted page to be indexed by the major 5605 Web search services, thereby diverting browsers from the target 5606 server to the attacker's server. 5608 (D) ISPDs SHOULD NOT use this term because it is not listed in 5609 most dictionaries and might confuse international readers. 5611 $ PAN 5612 See: primary account number. 5614 $ PAP 5615 See: Password Authentication Protocol. 5617 $ partitioned security mode 5618 (N) A mode of operation of an information system, wherein all 5619 users have the clearance, but not necessarily formal access 5620 authorization and need-to-know, for all information handled by the 5621 system. (This mode is defined formally in U.S. Department of 5622 Defense policy regarding system accreditation [DOD2].) 5624 $ passive attack 5625 See: (secondary definition in) attack. 5627 $ passive wiretapping 5628 See: (secondary definition in) wiretapping. 5630 $ password 5631 (I) A secret data value, usually a character string, that is used 5632 as authentication information. (See: challenge-response.) 5634 (C) A password is usually matched with a user identifier that is 5635 explicitly presented in the authentication process, but in some 5636 cases the identity may be implicit. 5638 (C) Using a password as authentication information assumes that 5639 the password is known only by the system entity whose identity is 5640 being authenticated. Therefore, in a network environment where 5641 wiretapping is possible, simple authentication that relies on 5642 transmission of static (repetitively used) passwords as cleartext 5643 is inadequate. (See: one-time password, strong authentication.) 5645 $ Password Authentication Protocol (PAP) 5646 (I) A simple authentication mechanism in PPP, in which a user 5647 identifier and password are transmitted in cleartext. [R1334] 5648 (See: CHAP.) 5650 $ password sniffing 5651 (I) Passive wiretapping, usually on local area network, to gain 5652 knowledge of passwords. (See: (usage note in) sniffing.) 5654 $ path discovery 5655 (I) For a given digital certificate, the process of finding a set 5656 of public-key certificates that comprise a certification path from 5657 a trusted key to that digital certificate. 5659 $ path validation 5660 (I) The process of validating all of the digital certificates in a 5661 certification path and the required relationships between those 5662 certificates, thus validating the contents of the last certificate 5663 on the path. (See: certificate validation.) 5665 $ payment card 5666 (N) SET usage: Collectively refers "to credit cards, debit cards, 5667 charge cards, and bank cards issued by a financial institution and 5668 which reflects a relationship between the cardholder and the 5669 financial institution." [SET2] 5671 $ payment gateway 5672 (O) SET usage: A system operated by an acquirer, or a third party 5673 designated by an acquirer, for the purpose of providing electronic 5674 commerce services to the merchants in support of the acquirer, and 5675 which interfaces to the acquirer to support the authorization, 5676 capture, and processing of merchant payment messages, including 5677 payment instructions from cardholders. [SET1, SET2] 5679 $ payment gateway certification authority (SET PCA) 5680 (O) SET usage: A CA that issues digital certificates to payment 5681 gateways and is operated on behalf of a payment card brand, an 5682 acquirer, or another party according to brand rules. A SET PCA 5683 issues a CRL for compromised payment gateway certificates. [SET2] 5684 (See: PCA.) 5686 $ PC card 5687 (N) A plug-in peripheral device, originally developed for portable 5688 computers, that provides for functional expansion--such as 5689 removable storage, modems, device interface adapters, and 5690 cryptographic modules--in an internationally standardized, non- 5691 proprietary form factor about the size of a credit card. (See: 5692 FORTEZZA, PCMCIA.) 5694 (C) The PC Card Standard defines a 68-pin interface between the 5695 peripheral and the socket and defines three standard sizes, Types 5696 I, II and III. All three have the same length and width, roughly 5697 the size of a credit card, but differ in their thickness from 3.3 5698 to 10.5 mm. 5700 $ PCA 5701 (D) ISPDs SHOULD NOT use this acronym without a qualifying 5702 adjective because that would be ambiguous. (See: Internet policy 5703 certification authority, (MISSI) policy creation authority, (SET) 5704 payment gateway certification authority.) 5706 $ PCMCIA 5707 (N) Personal Computer Memory Card International Association, an 5708 international group of manufacturers, developers, and vendors, 5709 founded in 1989 to standardize plug-in peripheral memory cards for 5710 personal computers and now extended to deal with any technology 5711 that works in the PC Card form factor. 5713 $ peer entity authentication 5714 (I) "The corroboration that a peer entity in an association is the 5715 one claimed." [I7498 Part 2] (See: authentication.) 5717 $ peer entity authentication service 5718 (I) A security service that verifies an identity claimed by or for 5719 a system entity in an association. (See: authentication, 5720 authentication service.) 5722 (C) This service is used at the establishment of, or at times 5723 during, an association to confirm the identity of one entity to 5724 another, thus protecting against a masquerade by the first entity. 5725 However, unlike data origin authentication service, this service 5726 requires an association to exist between the two entities, and the 5727 corroboration provided by the service is valid only at the current 5728 time that the service is provided. 5730 (C) See: "relationship between data integrity service and 5731 authentication services" under data integrity service. 5733 $ PEM 5734 See: Privacy Enhanced Mail. 5736 $ penetration 5737 (I) Successful, repeatable, unauthorized access to a protected 5738 system resource. (See: attack, violation.) 5740 $ penetration test 5741 (I) A system test, often part of system certification, in which 5742 evaluators attempt to circumvent the security features of the 5743 system. [NCS04] 5745 (C) Penetration testing may be performed under various constraints 5746 and conditions. However, for a TCSEC evaluation, testers are 5747 assumed to have all system design and implementation 5748 documentation, including source code, manuals, and circuit 5749 diagrams, and to work under no greater constraints than those 5750 applied to ordinary users. 5752 $ perfect forward secrecy 5753 See: (discussion under) public-key forward secrecy. 5755 $ perimeter 5756 See: security perimeter. 5758 $ periods processing 5759 (I) A mode of system operation in which information of different 5760 sensitivities is processed at distinctly different times by the 5761 same system, with the system being properly purged or sanitized 5762 between periods. (See: color change.) 5764 $ permission 5765 (I) A synonym for "authorization", but "authorization" is 5766 preferred in the PKI context. 5768 $ personal identification number (PIN) 5769 (I) A character string used as a password to gain access to a 5770 system resource. (See: authentication information.) 5771 (C) Despite the words "identification" and "number", a PIN seldom 5772 serves as a user identifier, and a PIN's characters are not 5773 necessarily all numeric. A better name for this concept would have 5774 been "personal authentication system string (PASS)". 5776 (C) Retail banking applications commonly use 4-character PINs. 5777 FORTEZZA PC card's use up to 12 characters for user or SSO PINs. 5779 $ personality 5780 $ personality label 5781 (O) MISSI usage: A set of MISSI X.509 public-key certificates that 5782 have the same subject DN, together with their associated private 5783 keys and usage specifications, that is stored on a FORTEZZA PC 5784 card to support a role played by the card's user. 5786 (C) When a card's user selects a personality to use in a FORTEZZA- 5787 aware application, the data determines behavior traits (the 5788 personality) of the application. A card's user may have multiple 5789 personalities on the card. Each has a personality label, a user- 5790 friendly character string that applications can display to the 5791 user for selecting or changing the personality to be used. For 5792 example, a military user's card might contain three personalities: 5793 GENERAL HALFTRACK, COMMANDER FORT SWAMPY, and NEW YEAR'S EVE BALL 5794 CHAIRMAN. Each personality includes one or more certificates of 5795 different types (such as DSA versus RSA), for different purposes 5796 (such as digital signature versus encryption), or with different 5797 authorizations. 5799 $ personnel security 5800 (I) Procedures to ensure that persons who access a system have 5801 proper authorization, clearance, and need-to-know as required by 5802 the system's security policy. 5804 $ PGP(trademark) 5805 See: Pretty Good Privacy. 5807 $ Photuris 5808 (I) A UDP-based, key establishment protocol for session keys, 5809 designed for use with the IPsec protocols AH and ESP. Superseded 5810 by IKE. 5812 $ phreak 5813 $ phreaking 5814 (I) A contraction (of "telePHone bREAKing"); penetration of a 5815 telephone system or, by extension, of any other communication or 5816 information system [Raym]. 5818 (D) ISPDs SHOULD NOT use this term because it is not listed in 5819 most dictionaries and might confuse international readers. 5821 $ physical security 5822 (I) Fences, walls, locks, vaults, human guards and guard dogs, 5823 sensors and alarms, and other tangible means of preventing 5824 unauthorized physical access to a system. [FP031, R1455] 5826 $ piggyback attack 5827 (I) A form of active wiretapping in which the attacker gains 5828 access to a system via intervals of inactivity in another user's 5829 legitimate communication connection. Sometimes called a "between- 5830 the-lines" attack. (See: hijack attack, man-in-the-middle attack.) 5832 $ PIN 5833 See: personal identification number. 5835 $ ping of death 5836 (I) An attack that sends an improperly large ICMP [R0792] echo 5837 request packet (a "ping") with the intent of overflowing the input 5838 buffers of the destination machine and causing it to crash. 5840 $ ping sweep 5841 (I) An attack that sends ICMP [R0792] echo requests ("pings") to 5842 range of IP addresses, with the goal of finding hosts that can be 5843 probed for vulnerabilities. 5845 $ PKCS 5846 See: Public-Key Cryptography Standards. 5848 $ PKCS #7 5849 (N) A standard [PKC07, R2315] from the PKCS series; defines a 5850 syntax for data that may have cryptography applied to it, such as 5851 for digital signatures and digital envelopes. 5853 $ PKCS #10 5854 (N) A standard [PKC10] from the PKCS series; defines a syntax for 5855 requests for public-key certificates. (See: certification 5856 request.) 5858 (C) A PKCS #10 request contains a DN and a public key, and may 5859 contain other attributes, and is signed by the entity making the 5860 request. The request is sent to a CA, who converts it to an X.509 5861 public-key certificate (or some other form), and returns it, 5862 possibly in PKCS #7 format. 5864 $ PKCS #11 5865 (N) A standard [PKC11] from the PKCS series; defines a software 5866 CAPI called Cryptoki (pronounced "crypto-key"; short for 5867 "cryptographic token interface") for devices that hold 5868 cryptographic information and perform cryptographic functions. 5870 $ PKI 5871 See: public-key infrastructure. 5873 $ PKIX 5874 (I) (1.) A contraction of "Public-Key Infrastructure (X.509)", the 5875 name of the IETF working group that is specifying an architecture 5876 and set of protocols needed to support an X.509-based PKI for the 5877 Internet. (2.) A collective name for that architecture and set of 5878 protocols. 5880 (C) The goal of PKIX is to facilitate the use of X.509 public-key 5881 certificates in multiple Internet applications and to promote 5882 interoperability between different implementations that use those 5883 certificates. The resulting PKI is intended to provide a framework 5884 that supports a range of trust and hierarchy environments and a 5885 range of usage environments. PKIX specifies (a) profiles of the v3 5886 X.509 public-key certificate standards and the v2 X.509 CRL 5887 standards for the Internet, (b) operational protocols used by 5888 relying parties to obtain information such as certificates or 5889 certificate status; (c) management protocols used by system 5890 entities to exchange information needed for proper management of 5891 the PKI; and (d) information about certificate policies and CPSs, 5892 covering the areas of PKI security not directly addressed in the 5893 rest of PKIX. 5895 $ PKIX private extension 5896 (I) PKIX defines a private extension to identify an on-line 5897 verification service supporting the issuing CA. 5899 $ plaintext 5900 (I) Data that is input to and transformed by an encryption 5901 process, or that is output by a decryption process. 5903 (C) Usually, the plaintext input to an encryption operation is 5904 cleartext. But in some cases, the input is ciphertext that was 5905 output from another encryption operation. (See: superencryption.) 5907 $ Point-to-Point Protocol (PPP) 5908 (I) An Internet protocol [R1661] for encapsulation and full-duplex 5909 transportation of network layer protocol (mainly OSI layer 3) data 5910 packets over a link between two peers, and for multiplexing 5911 different network layer protocols over the same link. Includes 5912 optional negotiation to select and use a peer entity 5913 authentication protocol to authenticate the peer to each other 5914 before they exchange network layer data. (See: CHAP, EAP, PAP.) 5916 $ Point-to-Point Tunneling Protocol (PPTP) 5917 (I) An Internet client-server protocol (originally developed by 5918 Ascend and Microsoft) that enables a dial-up user to create a 5919 virtual extension of the dial-up link across a network by 5920 tunneling PPP over IP. (See: L2TP.) 5922 (C) PPP can in turn encapsulate any or IPS network layer protocol 5923 (or OSI layer 3 protocol). Therefore, PPTP does not specify 5924 security services; it depends on protocols above and below it to 5925 provide any needed security. PPTP makes it possible to divorce the 5926 location of the initial dial-up server (the PPTP Access 5927 Concentrator, the client, which runs on a special-purpose host) 5928 from the location at which the dial-up protocol (PPP) connection 5929 is terminated and access to the network is provided (the PPTP 5930 Network Server, which runs on a general-purpose host). 5932 $ policy 5933 (D) ISPDs SHOULD NOT this word as an abbreviation for either 5934 "security policy", "certificate policy", or other kinds of policy. 5935 Instead, to avoid misunderstanding, use the fully qualified term, 5936 at least at the point of first usage. 5938 $ policy approving authority (PAA) 5939 (O) MISSI usage: The top-level signing authority of a MISSI 5940 certification hierarchy. The term refers both that authoritative 5941 office or role, and to the person who fills that office. (See: 5942 root registry.) 5944 (C) A PAA registers MISSI PCAs and signs their X.509 public-key 5945 certificates. A PAA issues CRLs but does not issue a CKL. A PAA 5946 may issue cross-certificates to other PAAs. 5948 $ policy certification authority (Internet PCA) 5949 (I) An X.509-compliant CA at the second level of the Internet 5950 certification hierarchy, under the Internet Policy Registration 5951 Authority (IPRA). Each PCA operates in accordance with its 5952 published security policy (see: certification practice statement) 5953 and within constraints established by the IPRA for all PCAs. 5954 [R1422]. (See: policy creation authority.) 5956 $ policy creation authority (MISSI PCA) 5957 (O) MISSI usage: The second level of a MISSI certification 5958 hierarchy; the administrative root of a security policy domain of 5959 MISSI users and other, subsidiary authorities. The term refers 5960 both that authoritative office or role, and to the person who 5961 fills that office. (See: policy certification authority.) 5963 (C) A MISSI PCA's certificate is issued by a policy approving 5964 authority. The PCA registers the CAs in its domain, defines their 5965 configurations, and issues their X.509 public-key certificates. 5966 (The PCA may also issue certificates for SCAs, ORAs, and other end 5967 entities, but a PCA does not usually do this.) The PCA 5968 periodically issues CRLs and CKLs for its domain. 5970 $ Policy Management Authority 5971 (N) Canadian usage: An organization responsible for the oversight 5972 and policy management of the Government of Canada. 5974 $ policy mapping 5975 (I) "Recognizing that, when a CA in one domain certifies a CA in 5976 another domain, a particular certificate policy in the second 5977 domain may be considered by the authority of the first domain to 5978 be equivalent (but not necessarily identical in all respects) to a 5979 particular certificate policy in the first domain." [X509] 5981 $ POP3 5982 See: Post Office Protocol, version 3. 5984 $ POP3 APOP 5985 (I) A "command" (better described as a transaction type, or a 5986 protocol-within-a-protocol) in POP3 [R1939], by which a POP3 5987 client optionally uses a keyed hash (based on MD5) to authenticate 5988 itself to a POP3 server and, depending on the server 5989 implementation, also to protect against replay attacks. (See: 5990 CRAM, POP3 AUTH, IMAP4 AUTHENTICATE.) 5992 (C) The server includes a unique timestamp in its greeting to the 5993 client. The subsequent APOP command sent by the client to the 5994 server contains the client's name and the hash result of applying 5995 MD5 to a string formed from the timestamp and a shared secret that 5996 is known only to the client and the server. APOP was designed as 5997 an alternative to using POP3's USER and PASS (i.e., password) 5998 command pair, in which the client sends a cleartext password to 5999 the server. 6001 $ POP3 AUTH 6002 (I) A "command" [R1734] (better described as a transaction type, 6003 or a protocol-within-a-protocol) in POP3, by which a POP3 client 6004 optionally proposes a mechanism to a POP3 server to authenticate 6005 the client to the server and provide other security services. 6006 (See: POP3 APOP, IMAP4 AUTHENTICATE.) 6008 (C) If the server accepts the proposal, the command is followed by 6009 performing a challenge-response authentication protocol and, 6010 optionally, negotiating a protection mechanism for subsequent POP3 6011 interactions. The security mechanisms used by POP3 AUTH are those 6012 used by IMAP4. 6014 $ port scan 6015 (I) An attack that sends client requests to a range of server port 6016 addresses on a host, with the goal of finding an active port and 6017 exploiting a known vulnerability of that service. 6019 $ POSIX 6020 (N) Portable Operating System Interface for Computer Environments, 6021 a standard [FP151, IS9945-1] (originally IEEE Standard P1003.1) 6022 that defines an operating system interface and environment to 6023 support application portability at the source code level. It is 6024 intended to be used by both application developers and system 6025 implementers. 6027 (C) P1003.1 supports security functionality like those on most 6028 UNIX systems, including discretionary access control and 6029 privilege. IEEE Draft Standard P1003.6.1 specifies additional 6030 functionality not provided in the base standard, including (a) 6031 discretionary access control, (b) audit trail mechanisms, (c) 6032 privilege mechanisms, (d) mandatory access control, and (e) 6033 information label mechanisms. 6035 $ Post Office Protocol, version 3 (POP3) 6036 (I) An Internet protocol [R1939] by which a client workstation can 6037 dynamically access a mailbox on a server host to retrieve mail 6038 messages that the server has received and is holding for the 6039 client. (See: IMAP4.) 6041 (C) POP3 has mechanisms for optionally authenticating a client to 6042 a server and providing other security services. (See: POP3 APOP, 6043 POP3 AUTH.) 6045 $ PPP 6046 See: Point-to-Point Protocol. 6048 $ PPTP 6049 See: Point-to-Point Tunneling Protocol. 6051 $ pre-authorization 6052 (I) A capability of a CA that enable certification requests to be 6053 automatically validated against data provided in advance to the CA 6054 by an authorizing entity. 6056 $ Pretty Good Privacy(trademark) (PGP(trademark)) 6057 (O) Trademarks of Network Associates, Inc., referring to a 6058 computer program and related protocols, that use cryptography to 6059 provide data security for electronic mail and other applications 6060 on the Internet. (See: MOSS, PEM, S/MIME.) 6062 (C) PGP encrypts messages with IDEA in CFB mode, distributes the 6063 IDEA keys by encrypting them with RSA, and creates digital 6064 signatures on messages with MD5 and RSA. To establish ownership of 6065 public keys, PGP depends on the web of trust. (Compare with: 6066 Privacy Enhanced Mail.) 6068 $ primary account number (PAN) 6069 (O) SET usage: "The assigned number that identifies the card 6070 issuer and cardholder. This account number is composed of an 6071 issuer identification number (see: bank identification number), an 6072 individual account number identification, and an accompanying 6073 check digit as defined by ISO 7812-1985." [SET2, IS7812] 6075 (C) The PAN is embossed, encoded, or both on a magnetic-strip- 6076 based credit card. The PAN identifies the issuer to which a 6077 transaction is to be routed and the account to which it is to be 6078 applied unless specific instructions indicate otherwise. The 6079 authority that assigns the bank identification number part of the 6080 PAN is the American Bankers Association. 6082 $ privacy 6083 (I) The right of an entity (normally a person), acting in its own 6084 behalf, to determine the degree to which it will interact with its 6085 environment, including the degree to which the entity is willing 6086 to share information about itself with others. (See: anonymity.) 6088 (O) "The right of individuals to control or influence what 6089 information related to them may be collected and stored and by 6090 whom and to whom that information may be disclosed." [I7498 Part 6091 2] 6093 (D) ISPDs SHOULD NOT use this term as a synonym for "data 6094 confidentiality" or "data confidentiality service", which are 6095 different concepts. Privacy is a reason for security rather than a 6096 kind of security. For example, a system that stores personal data 6097 needs to protect the data to prevent harm, embarrassment, 6098 inconvenience, or unfairness to any person about whom data is 6099 maintained, and to protect the person's privacy. For that reason, 6100 the system may need to provide data confidentiality service. 6102 $ Privacy Enhanced Mail (PEM) 6103 (I) An Internet protocol to provide data confidentiality, data 6104 integrity, and data origin authentication for electronic mail. 6105 [R1421, R1422]. (See: MOSS, MSP, PGP, S/MIME.) 6107 (C) PEM encrypts messages with DES in CBC mode; provides key 6108 distribution of DES keys by encrypting them with RSA; and signs 6109 messages with RSA and either MD2 or MD5. To establish ownership of 6110 public keys, PEM uses a certification hierarchy, with X.509 6111 public-key certificates and X.509 CRLs that are signed with RSA 6112 and MD2. (Compare with: Pretty Good Privacy.) 6114 (C) PEM is designed to be compatible with a wide range of key 6115 management methods, but is limited by specifying security services 6116 only for text messages and, like MOSS, has not been widely 6117 implemented in the Internet. 6119 $ private component 6120 (I) A synonym for "private key". 6122 (D) In most cases, ISPDs SHOULD NOT use this term; to avoid 6123 confusing readers, use "private key" instead. However, the term 6124 MAY be used when specifically discussing a key pair; e.g., "A key 6125 pair has a public component and a private component." 6127 $ private extension 6128 See: (secondary definition in) extension. 6130 $ private key 6131 (I) The secret component of a pair of cryptographic keys used for 6132 asymmetric cryptography. (See: key pair, public key.) 6133 (O) "(In a public key cryptosystem) that key of a user's key pair 6134 which is known only by that user." [X509] 6136 $ privilege 6137 (I) An authorization or set of authorizations to perform security- 6138 relevant functions, especially in the context of a computer 6139 operating system. 6141 $ privilege management infrastructure 6142 (N) "The complete set of processes required to provide an 6143 authorization service" [i.e., processes concerned with attribute 6144 certificates]. [FPDAM] 6146 (D) ISPDs SHOULD NOT use this term and its definition because the 6147 definition is vague, and there is no consensus on an alternate 6148 definition. 6150 $ privileged process 6151 (I) An computer process that is authorized (and, therefore, 6152 trusted) to perform some security-relevant functions that ordinary 6153 processes are not. (See: privilege, trusted process.) 6155 $ procedural security 6156 (D) ISPDs SHOULD NOT use this term as a synonym for 6157 "administrative security". Any type of security may involve 6158 procedures; therefore, the term may be misleading. Instead, use 6159 "administrative security", "communication security", "computer 6160 security", "emanations security", "personnel security", "physical 6161 security", or whatever specific type is meant. (See: security 6162 architecture.) 6164 $ proprietary 6165 (I) Refers to information (or other property) that is owned by an 6166 individual or organization and for which the use is restricted by 6167 that entity. 6169 $ protected checksum 6170 (I) A checksum that is computed for a data set by means that 6171 protect against active attacks that would attempt to change the 6172 checksum to make it match changes made to the data set. (See: 6173 digital signature, keyed hash, (discussion under) checksum. 6175 $ protected distribution system 6176 (I) A wireline or fiber-optic system that includes sufficient 6177 safeguards (acoustic, electric, electromagnetic, and physical) to 6178 permit its use for unencrypted transmission of (cleartext) data. 6180 $ protection authority 6181 See: (secondary definition in) Internet Protocol Security Option. 6183 $ protection ring 6184 (I) One of a hierarchy of privileged operation modes of a system 6185 that gives certain access rights to processes authorized to 6186 operate in that mode. 6188 $ protocol 6189 (I) A set of rules (i.e., formats and procedures) to implement and 6190 control some type of association (e.g., communication) between 6191 systems. (For example, see: Internet Protocol.) 6193 (C) In particular, a series of ordered steps involving computing 6194 and communication that are performed by two or more system 6195 entities to achieve a joint objective. [A9042] 6197 $ protocol suite 6198 (I) A complementary collection of communication protocols used in 6199 a computer network. (See: Internet, OSI.) 6201 $ proxy server 6202 (I) A computer process--often used as, or as part of, a firewall-- 6203 that relays a protocol between client and server computer systems, 6204 by appearing to the client to be the server and appearing to the 6205 server to be the client. (See: SOCKS.) 6207 (C) In a firewall, a proxy server usually runs on a bastion host, 6208 which may support proxies for several protocols (e.g., FTP, HTTP, 6209 and TELNET). Instead of a client in the protected enclave 6210 connecting directly to an external server, the client connects to 6211 the proxy server which in turn connects to the external server. 6212 The proxy server waits for a request from inside the firewall, 6213 forwards the request to the remote server outside the firewall, 6214 gets the response, then sends the response back to the client. The 6215 proxy may be transparent to the clients, or they may need to 6216 connect first to the proxy server, and then use that association 6217 to also initiate a connection to the real server. 6219 (C) Proxies are generally preferred over SOCKS for their ability 6220 to perform caching, high-level logging, and access control. A 6221 proxy can provide security service beyond that which is normally 6222 part of the relayed protocol, such as access control based on peer 6223 entity authentication of clients, or peer entity authentication of 6224 servers when clients do not have that capability. A proxy at OSI 6225 layer 7 can also provide finer-grained security service than can a 6226 filtering router at OSI layer 3. For example, an FTP proxy could 6227 permit transfers out of, but not into, a protected network, or 6228 vice versa. 6230 $ pseudo-random 6231 (I) A sequence of values that appears to be random (i.e., 6232 unpredictable) but is actually generated by a deterministic 6233 algorithm. 6235 $ pseudo-random number generator 6236 (I) A process used to deterministically generate a series of 6237 numbers (usually integers) that appear to be random according to 6238 certain statistical tests, but actually are pseudo-random. 6240 (C) Pseudo-random number generators are usually implemented in 6241 software. 6243 $ public component 6244 (D) ISPDs SHOULD NOT use this term as a synonym for "public key" 6245 except when discussing a key pair. 6247 $ public key 6248 (I) The publicly-disclosable component of a pair of cryptographic 6249 keys used for asymmetric cryptography. (See: key pair, private 6250 key.) 6252 (O) "(In a public key cryptosystem) that key of a user's key pair 6253 which is publicly known." [X509] 6255 $ public-key certificate 6256 (I) A digital certificate that binds a system entity's identity to 6257 a public key value, and possibly to additional data items; a 6258 digitally-signed data structure that attests to the ownership of a 6259 public key. (See: X.509 public-key certificate.) 6261 (C) The digital signature on a public-key certificate is 6262 unforgeable. Thus, the certificate can be published, such as by 6263 posting it in a directory, without the directory having to protect 6264 the certificate's data integrity. 6266 (O) "The public key of a user, together with some other 6267 information, rendered unforgeable by encipherment with the private 6268 key of the certification authority which issued it." [X509] 6270 $ public-key cryptography 6271 (I) The popular synonym for "asymmetric cryptography". 6273 $ Public-Key Cryptography Standards (PKCS) 6274 (I) A series of specifications published by RSA Laboratories for 6275 data structures and algorithm usage for basic applications of 6276 asymmetric cryptography. (See: PKCS #7, PKCS #10, PKCS #11.) 6278 (C) The PKCS were begun in 1991 in cooperation with industry and 6279 academia, originally including Apple, Digital, Lotus, Microsoft, 6280 Northern Telecom, Sun, and MIT. Today, these specifications are 6281 widely used, but they are not sanctioned by an official standards 6282 organizations, such as ANSI and ITU-T. RSA Laboratories retains 6283 sole decision-making authority over the PKCS. 6285 $ public-key forward secrecy (PFS) 6286 (I) For a key agreement protocol based on asymmetric cryptography, 6287 the property that ensures that a session key derived from a set of 6288 long-term public and private keys will not be compromised if one 6289 of the private keys is compromised in the future. 6291 (C) Some existing RFCs use the term "perfect forward secrecy" but 6292 either do not define it or do not define it precisely. While 6293 preparing this Glossary, we tried to find a good definition for 6294 that term, but found this to be a muddled area. Experts did not 6295 agree. For all practical purposes, the literature defines "perfect 6296 forward secrecy" by stating the Diffie-Hellman algorithm. The term 6297 "public-key forward secrecy" (suggested by Hilarie Orman) and the 6298 "I" definition stated for it here were crafted to be compatible 6299 with current Internet documents, yet be narrow and leave room for 6300 improved terminology. 6302 (C) Challenge to the Internet security community: We need a 6303 taxonomy--a family of mutually exclusive and collectively 6304 exhaustive terms and definitions to cover the basic properties 6305 discussed here--for the full range of cryptographic algorithms and 6306 protocols used in Internet Standards: 6308 (C) Involvement of session keys vs. long-term keys: Experts 6309 disagree about the basic ideas involved. 6311 - One concept of "forward secrecy" is that, given observations of 6312 the operation of a key establishment protocol up to time t, and 6313 given some of the session keys derived from those protocol runs, 6314 you cannot derive unknown past session keys or future session 6315 keys. 6317 - A related property is that, given observations of the protocol 6318 and knowledge of the derived session keys, you cannot derive one 6319 or more of the long-term private keys. 6321 - The "I" definition presented above involves a third concept of 6322 "forward secrecy" that refers to the effect of the compromise of 6323 long-term keys. 6325 - All three concepts involve the idea that a compromise of "this" 6326 encryption key is not supposed to compromise the "next" one. There 6327 also is the idea that compromise of a single key will compromise 6328 only the data protected by the single key. In Internet literature, 6329 the focus has been on protection against decryption of back 6330 traffic in the event of a compromise of secret key material held 6331 by one or both parties to a communication. 6333 (C) Forward vs. backward: Experts are unhappy with the word 6334 "forward", because compromise of "this" encryption key also is not 6335 supposed to compromise the "previous" one. In S/KEY, if the key 6336 used at time t is compromised, then all keys used prior to that 6337 are compromised. If the "long-term" key (i.e., the base of the 6338 hashing scheme) is compromised, then all keys past and future are 6339 compromised; thus, you could say that S/KEY has neither forward 6340 nor backward secrecy. 6342 (C) Asymmetric cryptography vs. symmetric: Experts disagree about 6343 forward secrecy in the context of symmetric cryptographic systems. 6344 In the absence of asymmetric cryptography, compromise of any long- 6345 term key seems to compromise any session key derived from the 6346 long-term key. For example, Kerberos isn't forward secret, because 6347 compromising a client's password (thus compromising the key shared 6348 by the client and the authentication server) compromises future 6349 session keys shared by the client and the ticket-granting server. 6351 (C) Ordinary forward secrecy vs. "perfect" forward secret: Experts 6352 disagree about the difference between these two. Some say there is 6353 no difference. Others say that the initial naming was unfortunate 6354 and suggest dropping the word "perfect". Some suggest using 6355 "forward secrecy" for the case where one long-term private key is 6356 compromised, and adding "perfect" for when both private keys (or, 6357 when the protocol is multi-party, all private keys) are 6358 compromised. 6360 (C) Acknowledgements: Bill Burr, Burt Kaliski, Steve Kent, Paul 6361 Van Oorschot, Michael Wiener, and, especially, Hilarie Orman 6362 contributed ideas to this discussion. 6364 $ public-key infrastructure (PKI) 6365 (I) A system of CAs (and, optionally, RAs and other supporting 6366 servers and agents) that perform some set of certificate 6367 management, archive management, key management, and token 6368 management functions for a community of users in an application of 6369 asymmetric cryptography. (See: hierarchical PKI, mesh PKI, 6370 security management infrastructure, trust-file PKI.) 6372 (O) PKIX usage: The set of hardware, software, people, policies, 6373 and procedures needed to create, manage, store, distribute, and 6374 revoke digital certificates based on asymmetric cryptography. 6376 (C) The core PKI functions are to register users and issue their 6377 public-key certificates, revoke certificates when required, and 6378 archive data needed to validate certificates at a much later time. 6379 Key pairs may be generated by CAs or RAs, but requiring a PKI 6380 client to generate its own digital signature key pair helps 6381 maintain system integrity of the cryptographic system, because 6382 then only the client ever possesses the private key it uses. Also, 6383 an authority may be established to approve or coordinate CPSs, 6384 which are security policies under which components of a PKI 6385 operate. 6387 (C) A number of other servers and agents may support the core PKI, 6388 and PKI clients may obtain services from them. The full range of 6389 such services is not yet fully understood and is evolving, but 6390 supporting roles may include archive agent, certified delivery 6391 agent, confirmation agent, digital notary, directory, key escrow 6392 agent, key generation agent, naming agent who ensures that issuers 6393 and subjects have unique identifiers within the PKI, repository, 6394 ticket-granting agent, and time stamp agent. 6396 $ RA 6397 See: registration authority. 6399 $ RA domains 6400 (I) A capability of a CAW that allows a CA to divide the 6401 responsibility for certificate requests among multiple RAs. 6403 (C) This capability might be used to restrict access to private 6404 authorization data that is provided with a certificate request; 6405 and distribute the responsibility to review and approve 6406 certificate requests in high volume environments among multiple 6407 RAs. RA domains might segregate certificate requests according to 6408 an attribute of the certificate subject, such as an organizational 6409 unit 6411 $ RADIUS 6412 See: Remote Authentication Dial-In User Service. 6414 $ Rainbow Series 6415 (O) A set of more than 30 technical and policy documents with 6416 colored covers, issued by the NCSC, that discuss in detail the 6417 TCSEC and provide guidance for meeting and applying the criteria. 6418 (See: Green Book, Orange Book, Red Book, Yellow Book.) 6420 $ random 6421 (I) In essence, random means unpredictable. A sequence of values 6422 is called random if each successive value is obtained merely by 6423 chance and does not depend on the preceding values of the 6424 sequence, and each individual value is called random if each of 6425 the values in the total population of possibilities has equal 6426 probability of being selected. (See: cryptographic key, pseudo- 6427 random.) 6429 $ random number generator 6430 (I) A process used to generate an unpredictable, uniformly 6431 distributed series of numbers (usually integers). (See: pseudo- 6432 random, random.) 6434 (C) True random number generators are hardware-based devices that 6435 depend on the output of a "noisy diode" or other physical 6436 phenomena. [R1750] 6438 $ RBAC 6439 See: Role-Based Access Control. 6441 $ RC2 6442 $ RC4 6443 See: Rivest Cipher #2, Rivest Cipher #4. 6445 $ realm 6446 (O) Kerberos usage: The domain of authority of a Kerberos server 6447 (consisting of an authentication server and a ticket-granting 6448 server), including the Kerberized clients and the Kerberized 6449 application servers 6451 $ RED 6452 (I) Designation for information system equipment or facilities 6453 that handle (and for data that contains) only plaintext (or, 6454 depending on the context, classified information), and for such 6455 data itself. This term derives from U.S. Government COMSEC 6456 terminology. (Compare with: BLACK. Also see: RED/BLACK 6457 separation.) 6459 $ Red Book 6460 (D) ISPDs SHOULD NOT use this term as a synonym for "Trusted 6461 Network Interpretation of the Trusted Computer System Evaluation 6462 Criteria" [NCS05]. Instead, use the full proper name of the 6463 document or, in subsequent references, a more conventional 6464 abbreviation. (See: TCSEC, Rainbow Series, (usage note under) 6465 Green Book.) 6467 $ RED/BLACK separation 6468 (I) An architectural concept for cryptographic systems that 6469 strictly separates the parts of a system that handle plaintext 6470 (RED information) from the parts that handle ciphertext (BLACK 6471 information). This term derives from U.S. Government COMSEC 6472 terminology. (See: BLACK, RED.) 6474 $ reference monitor 6475 (I) "An access control concept that refers to an abstract machine 6476 that mediates all accesses to objects by subjects." [NCS04] 6478 (C) A reference monitor should be (1) complete (i.e., it mediates 6479 every access), (2) isolated (i.e., it cannot be modified by other 6480 system entities), and (3) verifiable. (See: security kernel.) 6482 $ reflection attack 6483 (I) A type of replay attack in which transmitted data is sent back 6484 to its originator. 6486 $ register 6487 $ registration 6488 (I) An administrative act or process whereby an entity's name and 6489 other attributes are established for the first time at a CA, prior 6490 to the CA issuing a digital certificate that has the entity's name 6491 as the subject. (See: registration authority.) 6493 (C) Registration can be accomplished either directly, by the CA, 6494 or indirectly, by a separate RA. An entity is presented to the CA 6495 or RA, and the authority either records the name(s) claimed for 6496 the entity or assigns the entity's name(s). The authority also 6497 determines and records other attributes of the entity that are to 6498 be bound in a certificate (such as a public key or authorizations) 6499 or maintained in the authority's database (such as street address 6500 and telephone number). The authority is responsible, possibly 6501 assisted by an RA, for authenticating the entity's identity and 6502 verifying the correctness of the other attributes, in accordance 6503 with the CA's CPS. 6505 (C) Among the registration issues that a CPS may address are the 6506 following [R2527]: 6508 - How a claimed identity and other attributes are verified. 6509 - How organization affiliation or representation is verified. 6510 - What forms of names are permitted, such as X.500 DN, domain 6511 name, or IP address. 6512 - Whether names are required to be meaningful or unique, and 6513 within what domain. 6514 - How naming disputes are resolved, including the role of 6515 trademarks. 6516 - Whether certificates are issued to entities that are not 6517 persons. 6518 - Whether a person is required to appear before the CA or RA, or 6519 can instead be represented by an agent. 6520 - Whether and how an entity proves possession of the private key 6521 matching a public key. 6523 $ registration authority (RA) 6524 (I) An optional PKI entity (separate from the CAs) that does not 6525 sign either digital certificates or CRLs but has responsibility 6526 for recording or verifying some or all of the information 6527 (particularly the identities of subjects) needed by a CA to issue 6528 certificates and CRLs and to perform other certificate management 6529 functions. (See: organizational registration authority, 6530 registration.) 6532 (C) Sometimes, a CA may perform all certificate management 6533 functions for all end users for which the CA signs certificates. 6534 Other times, such as in a large or geographically dispersed 6535 community, it may be necessary or desirable to offload secondary 6536 CA functions and delegate them to an assistant, while the CA 6537 retains the primary functions (signing certificates and CRLs). The 6538 talks that are delegated to an RA by a CA may include personal 6539 authentication, name assignment, token distribution, revocation 6540 reporting, key generation, and archiving. An RA is an optional PKI 6541 component, separate from the CA, that is assigned secondary 6542 functions. The duties assigned to RAs vary from case to case but 6543 may include the following: 6545 - Verifying a subject's identity, i.e., performing personal 6546 authentication functions. 6547 - Assigning a name to a subject. (See: distinguished name.) 6548 - Verifying that a subject is entitled to have the attributes 6549 requested for a certificate. 6550 - Verifying that a subject possesses the private key that matches 6551 the public key requested for a certificate. 6552 - Performing functions beyond mere registration, such as 6553 generating key pairs, distributing tokens, and handling 6554 revocation reports. Such functions may also be assigned to a 6555 PKI element that is separate from both the CA and the RA. 6557 (I) PKIX usage: An optional PKI component, separate from the 6558 CA(s). The functions which the RA may carry out will vary from 6559 case to case but may include personal authentication, token 6560 distribution, revocation reporting, name assignment, key 6561 generation, and archiving of key pairs. [R2510] 6563 (O) SET usage: "An independent third-party organization that 6564 processes payment card applications for multiple payment card 6565 brands and forwards applications to the appropriate financial 6566 institutions." [SET2] 6568 $ regrade 6569 (I) Deliberately change the classification level of information in 6570 an authorized manner. 6572 $ rekey 6573 (I) Change the value of a cryptographic key that is being used in 6574 an application of a cryptographic system. (See: certificate 6575 rekey.) 6577 (C) For example, rekey is required at the end of a cryptoperiod or 6578 key lifetime. 6580 $ reliability 6581 (I) The ability of a system to perform a required function under 6582 stated conditions for a specified period of time. (See: 6583 availability, survivability.) 6585 $ relying party 6586 (I) A synonym for "certificate user". Used in a legal context 6587 (see: ABA Guidelines) to mean a recipient of a certificate who 6588 acts in reliance on that certificate. 6590 $ Remote Authentication Dial-In User Service (RADIUS) 6591 (I) An Internet protocol for carrying dial-in users' 6592 authentication information and configuration information between a 6593 shared, centralized authentication server (the RADIUS server) and 6594 a network access server (the RADIUS client) that needs to 6595 authenticate the users of its network access ports. [R2138] (See: 6596 TACACS.) 6598 (C) A user of the RADIUS client presents authentication 6599 information to the client, and the client passes that information 6600 to the RADIUS server. The server authenticates the client using a 6601 shared secret value, then checks the user's authentication 6602 information, and finally returns to the client all authorization 6603 and configuration information needed by the client to deliver 6604 service to the user. 6606 $ renew 6607 See: certificate renewal. 6609 $ replay attack 6610 (I) An attack in which a valid data transmission is maliciously or 6611 fraudulently repeated, either by the originator or by an adversary 6612 who intercepts the data and retransmits it, possibly as part of a 6613 masquerade attack. (See: active wiretapping.) 6615 $ repository 6616 (I) A system for storing and distributing digital certificates and 6617 related information (including CRLs, CPSs, and certificate 6618 policies) to certificate users. (See: directory.) 6620 (O) "A trustworthy system for storing and retrieving certificates 6621 or other information relevant to certificates." [ABA] 6623 (C) A certificate is published to those who might need it by 6624 putting it in a repository. The repository usually is a publicly 6625 accessible, on-line server. In the Federal Public-key 6626 Infrastructure, for example, the expected repository is a 6627 directory that uses LDAP, but also may be the X.500 Directory that 6628 uses DAP, or an HTTP server, or an FTP server that permits 6629 anonymous login. 6631 $ repudiation 6632 (I) Denial by a system entity that was involved in an association 6633 (especially an association that transfers information) of having 6634 participated in the relationship. (See: accountability, non- 6635 repudiation service.) 6637 (O) "Denial by one of the entities involved in a communication of 6638 having participated in all or part of the communication." [I7498 6639 Part 2] 6641 $ Request for Comment (RFC) 6642 (I) One of the documents in the archival series that is the 6643 official channel for ISPDs and other publications of the Internet 6644 Engineering Steering Group, the Internet Architecture Board, and 6645 the Internet community in general. [R1543] 6647 (C) This term does not mean the same as "Internet Standard". 6649 $ residual risk 6650 (I) The risk that remains after countermeasures have been applied. 6652 $ restore 6653 See: card restore. 6655 $ revocation 6656 See: certificate revocation. 6658 $ revocation date 6659 (N) In an X.509 CRL entry, a date-time field that states when the 6660 certificate revocation occurred, i.e., when the CA declared the 6661 digital certificate to be invalid. (See: invalidity date.) 6663 (C) The revocation date may not resolve some disputes because, in 6664 the worst case, all signatures made during the validity period of 6665 the certificate may have to be considered invalid. However, it may 6666 be desirable to treat a digital signature as valid even though the 6667 private key used to sign was compromised after the signing. If 6668 more is known about when the compromise actually occurred, a 6669 second date-time, an "invalidity date", can be included in an 6670 extension of the CRL entry. 6672 $ revocation list 6673 See: certificate revocation list. 6675 $ revoke 6676 See: certificate revocation. 6678 $ RFC 6679 See: Request for Comment. 6681 $ risk 6682 (I) An expectation of loss expressed as the probability that a 6683 particular threat will exploit a particular vulnerability with a 6684 particular harmful result. 6686 (O) SET usage: "The possibility of loss because of one or more 6687 threats to information (not to be confused with financial or 6688 business risk)." [SET2] 6690 $ risk analysis 6691 $ risk assessment 6692 (I) A process that systematically identifies valuable system 6693 resources and threats to those resources, quantifies loss 6694 exposures (i.e., loss potential) based on estimated frequencies 6695 and costs of occurrence, and (optionally) recommends how to 6696 allocate resources to countermeasures so as to minimize total 6697 exposure. 6699 (C) The analysis lists risks in order of cost and criticality, 6700 thereby determining where countermeasures should be applied first. 6701 It is usually financially and technically infeasible to counteract 6702 all aspects of risk, and so some residual risk will remain, even 6703 after all available countermeasures have been deployed. [FP031, 6704 R2196] 6706 $ risk management 6707 (I) The process of identifying, controlling, and eliminating or 6708 minimizing uncertain events that may affect system resources. 6709 (See: risk analysis.) 6711 $ Rivest Cipher #2 (RC2) 6712 (N) A proprietary, variable-key-length block cipher invented by 6713 Ron Rivest for RSA Data Security, Inc. (now a wholly-owned 6714 subsidiary of Security Dynamics, Inc.). 6716 $ Rivest Cipher #4 (RC4) 6717 (N) A proprietary, variable-key-length stream cipher invented by 6718 Ron Rivest for RSA Data Security, Inc. (now a wholly-owned 6719 subsidiary of Security Dynamics, Inc.). 6721 $ Rivest-Shamir-Adleman (RSA) 6722 (N) An algorithm for asymmetric cryptography, invented in 1977 by 6723 Ron Rivest, Adi Shamir, and Leonard Adleman [RSA78]. 6725 (C) RSA uses exponentiation modulo the product of two large prime 6726 numbers. The difficulty of breaking RSA is believed to be 6727 equivalent to the difficulty of factoring integers that are the 6728 product of two large prime numbers of approximately equal size. 6730 (C) To create an RSA key pair, randomly choose two large prime 6731 numbers, p and q, and compute the modulus, n = pq. Randomly choose 6732 a number e, the public exponent, that is less than n and 6733 relatively prime to (p-1)(q-1). Choose another number d, the 6734 private exponent, such that ed-1 evenly divides (p-1)(q-1). The 6735 public key is the set of numbers (n,e), and the private key is the 6736 set (n,d). 6738 (C) It is assumed to be difficult to compute the private key (n,d) 6739 from the public key (n,e). However, if n can be factored into p 6740 and q, then the private key d can be computed easily. Thus, RSA 6741 security depends on the assumption that it is computationally 6742 difficult to factor a number that is the product of two large 6743 prime numbers. (Of course, p and q are treated as part of the 6744 private key, or else destroyed after computing n.) 6746 (C) For encryption of a message, m, to be sent to Bob, Alice uses 6747 Bob's public key (n,e) to compute m**e (mod n) = c. She sends c to 6748 Bob. Bob computes c**d (mod n) = m. Only Bob knows d, so only Bob 6749 can compute c**d (mod n) = m to recover m. 6751 (C) To provide data origin authentication of a message, m, to be 6752 sent to Bob, Alice computes m**d (mod n) = s, where (d,n) is 6753 Alice's private key. She sends m and s to Bob. To recover the 6754 message that only Alice could have sent, Bob computes s**e (mod n) 6755 = m, where (e,n) is Alice's public key. 6757 (C) To ensure data integrity in addition to data origin 6758 authentication requires extra computation steps in which Alice and 6759 Bob use a cryptographic hash function h (as explained for digital 6760 signature). Alice computes the hash value h(m) = v, and then 6761 encrypts v with her private key to get s. She sends m and s. Bob 6762 receives m' and s', either of which might have been changed from 6763 the m and s that Alice sent. To test this, he decrypts s' with 6764 Alice's public key to get v'. He then computes h(m') = v". If v' 6765 equals v", Bob is assured that m' is the same m that Alice sent. 6767 $ role-based access control (RBAC) 6768 (I) A form of identity-based access control where the system 6769 entities that are identified and controlled are functional 6770 positions in an organization or process. 6772 $ root 6773 (I) A CA that is directly trusted by an end entity. Acquiring the 6774 value of a root CA's public key requires an out-of-band procedure. 6776 (I) Hierarchical PKI usage: The CA that is the highest level (most 6777 trusted) CA in a certification hierarchy; i.e., the authority upon 6778 whose public key all certificate users base their trust. (See: top 6779 CA.) 6781 (C) In a hierarchical PKI, a root issues public-key certificates 6782 to one or more additional CAs that form the second highest level. 6783 Each of these CAs may issue certificates to more CAs at the third 6784 highest level, and so on. To initialize operation of a 6785 hierarchical PKI, the root's initial public key is securely 6786 distributed to all certificate users in a way that does not depend 6787 on the PKI's certification relationships. The root's public key 6788 may be distributed simply as a numerical value, but typically is 6789 distributed in a self-signed certificate in which the root is the 6790 subject. The root's certificate is signed by the root itself 6791 because there is no higher authority in a certification hierarchy. 6792 The root's certificate is then the first certificate in every 6793 certification path. 6795 (O) MISSI usage: A name previously used for a MISSI Policy 6796 Creation Authority, which is not a root as defined above for 6797 general usage, but is a CA at the second level of the MISSI 6798 hierarchy, immediately subordinate to a MISSI root called a Policy 6799 Approving Authority. 6801 (O) UNIX usage: A system user account (also called "superuser") 6802 that has all privileges (including all security-related 6803 privileges) and thus can manage the system and its other user 6804 accounts. 6806 $ root certificate 6807 (I) A certificate for which the subject is a root. 6809 (I) Hierarchical PKI usage: The self-signed public-key certificate 6810 at the top of a certification hierarchy. 6812 $ root key 6813 (I) A public key for which the matching private key is held by a 6814 root. 6816 $ root registry 6817 (O) MISSI usage: A name previously used for a MISSI policy 6818 approving authority. 6820 $ router 6821 (I) A computer that is a gateway between two networks at OSI layer 6822 3 and that relays and directs data packets through that 6823 internetwork. The most common form of router operates on IP 6824 packets. (See: bridge.) 6826 (I) Internet usage: In the context of the Internet protocol suite, 6827 a networked computer that forwards Internet Protocol packets that 6828 are not addressed to the computer itself. (Compare with: host.) 6830 $ RSA 6831 See: Rivest-Shamir-Adleman. 6833 $ rule-based security policy 6834 (I) "A security policy based on global rules imposed for all 6835 users. These rules usually rely on comparison of the sensitivity 6836 of the resource being accessed and the possession of corresponding 6837 attributes of users, a group of users, or entities acting on 6838 behalf of users." [I7498 Part 2] (See: identity-based security 6839 policy.) 6841 $ safety 6842 (I) The property of a system being free from risk of causing harm 6843 to system entities and outside entities. 6845 $ SAID 6846 See: security association identifier. 6848 $ salt 6849 (I) A random value that is concatenated with a password before 6850 applying the one-way encryption function used to protect passwords 6851 that are stored in the database of an access control system. (See: 6852 initialization value.) 6854 (C) Salt protects a password-based access control system against a 6855 dictionary attack. 6857 $ sanitize 6858 (I) Delete sensitive data from a file, a device, or a system; or 6859 modify data so as to be able to downgrade its classification 6860 level. 6862 $ SASL 6863 See: Simple Authentication and Security Layer. 6865 $ SCA 6866 See: subordinate certification authority. 6868 $ scavenging 6869 See: (secondary threat action definition in) threat consequence. 6871 $ screening router 6872 (I) A synonym for "filtering router". 6874 $ SDE 6875 See: Secure Data Exchange. 6877 $ SDNS 6878 See: Secure Data Network System. 6880 $ seal 6881 (D) To use cryptography to provide data integrity service for a 6882 data set. (See: checksum, sign, wrap.) 6884 (C) ISPDs SHOULD NOT use this definition; instead, use language 6885 that is more specific with regard to the mechanism(s) used. 6887 $ secrecy 6888 $ secret 6889 (I) The condition of information being protected from being known 6890 by any system entities except those who are intended to know it; 6891 an item of information that is so protected. 6893 (C) This term applies to symmetric keys, private keys, and 6894 passwords. 6896 $ secret-key cryptography 6897 (I) A synonym for "symmetric cryptography". 6899 $ Secure Data Exchange (SDE) 6900 (N) A local area network security protocol defined by the IEEE 6901 802.10 standard. 6903 $ Secure Data Network System (SDNS) 6904 (N) An NSA program that developed security a for electronic mail 6905 (Message Security Protocol), OSI layer 3 (SP3), OSI layer 4 (SP4), 6906 and key management (KMP). 6908 $ Secure Hash Standard (SHS) 6909 (N) The U.S. Government standard [FP180] that specifies the Secure 6910 Hash Algorithm (SHA-1), a cryptographic hash function that 6911 produces a 160-bit output (hash result) for input data of any 6912 length < 2**64 bits. 6914 $ Secure Hypertext Transfer Protocol (Secure-HTTP, S-HTTP) 6915 (I) A Internet protocol for providing client-server security 6916 services for HTTP communications. (Compare with: https.) 6918 (C) S-HTTP was originally specified by CommerceNet, a coalition of 6919 businesses interested in developing the Internet for commercial 6920 uses. Several message formats may be incorporated into S-HTTP 6921 clients and servers, particularly CMS and MOSS. S-HTTP supports 6922 choice of security policies, key management mechanisms, and 6923 cryptographic algorithms through option negotiation between 6924 parties for each transaction. S-HTTP supports both asymmetric and 6925 symmetric key operation modes. S-HTTP attempts to avoid presuming 6926 a particular trust model, but it attempts to facilitate multiply- 6927 rooted hierarchical trust and anticipates that principals may have 6928 many public key certificates. 6930 $ Secure/MIME (S/MIME) 6931 (I) Secure/Multipurpose Internet Mail Extensions, an Internet 6932 protocol developed by an industry consortium led by RSA Data 6933 Security, Inc. (which is now a subsidiary of Security Dynamics 6934 Technologies, Inc.). [R2633] 6936 $ Secure Sockets Layer (SSL) 6937 (N) An Internet protocol (originally developed by Netscape 6938 Communications, Inc.) that uses connection-oriented end-to-end 6939 encryption to provide data confidentiality service and data 6940 integrity service for traffic between a client (often a web 6941 browser) and a server, and that can optionally provide peer entity 6942 authentication between the client and the server. (See: Transport 6943 Layer Security.) 6945 (C) SSL is layered below HTTP (other Internet applications, such 6946 as FTP, would be better served by IPsec) and above a reliable 6947 transport protocol (TCP). SSL is independent of the application it 6948 encapsulates, and a higher level protocol can layer on top of SSL 6949 transparently. SSL itself has two layers: (a) SSL's lower layer, 6950 the SSL Record Protocol, is layered on top of the transport 6951 protocol and encapsulates higher level protocols. One such 6952 encapsulated protocol is SSL Handshake Protocol. (b) SSL's upper 6953 layer provides asymmetric cryptography for server authentication 6954 (verifying the server's identity to the client) and optional 6955 client authentication (verifying the client's identity to the 6956 server), and also enables them to negotiate a symmetric encryption 6957 algorithm and secret session key (to use for data confidentiality) 6958 before the application protocol transmits or receives data. A 6959 keyed hash provides data integrity service for encapsulated data. 6961 $ secure state 6962 (I) A system condition in which no subject can access any object 6963 in an unauthorized manner. (See: (secondary definition in) Bell- 6964 LaPadula Model, clean system.) 6966 $ security 6967 (I) (1.) Measures taken to protect a system. (2.) The condition of 6968 a system that results from the establishment and maintenance of 6969 measures to protect the system. (3.) The condition of system 6970 resources being free from unauthorized access and from 6971 unauthorized or accidental change, destruction, or loss. 6973 $ security architecture 6974 (I) A plan and set of principles that describe (a) the security 6975 services that a system is required to provide to meet the needs of 6976 its users, (b) the system elements required to implement the 6977 services, and (c) the performance levels required in the elements 6978 to deal with the threat environment. (See: (discussion under) 6979 security policy.) 6981 (C) A security architecture is the result of applying the system 6982 engineering process. A complete system security architecture 6983 includes administrative security, communication security, computer 6984 security, emanations security, personnel security, and physical 6985 security (e.g., see: [R2179]). A complete security architecture 6986 needs to deal with both intentional, intelligent threats and 6987 accidental kinds of threats. 6989 $ security association 6990 (I) A relationship defined between two or more entities to enable 6991 them to protect data they exchange. The relationship is used to 6992 negotiate characteristics of protection mechanisms, but does not 6993 include the mechanisms themselves. (See: association.) 6995 (C) A security association describes how entities will use 6996 security services. The relationship is represented by a set of 6997 information that is shared between the entities and is agreed upon 6998 and considered a contract between them. 7000 (O) IPsec usage. A simplex (uni-directional) logical connection 7001 created for security purposes and implemented with either AH or 7002 ESP (but not both), which provide security services to data 7003 carried by a connection. The security services offered by a 7004 security association depend on the protocol selected, the IPsec 7005 mode (transport or tunnel), the endpoints, and the election of 7006 optional services within the protocol. A security association is 7007 identified by a triple consisting of a destination IP address, a 7008 protocol (AH or ESP) identifier, and a Security Parameter Index. 7010 $ security association identifier (SAID) 7011 (I) A data field in a security protocol (such as NLSP or SDE), 7012 used to identify the security association to which a protocol data 7013 unit is bound. The SAID value is usually used to select a key to 7014 use for decryption or authentication at the destination. (See: 7015 Security Parameter Index.) 7017 $ security audit 7018 (I) An independent review and examination of a system's records 7019 and activities to determine the adequacy of system controls, 7020 ensure compliance with established security policy and procedures, 7021 detect breaches in security services, and recommend any changes 7022 that are indicated for countermeasures. [I7498 Part 2, NCS01] 7024 (C) The basic audit objective is to establish accountability for 7025 system entities that initiate or participate in security-relevant 7026 events and actions. Thus, means are needed to generate and record 7027 a security audit trail and to review and analyze the audit trail 7028 to discover and investigate attacks and security compromises. 7030 $ security audit trail 7031 (I) A chronological record of system activities that is sufficient 7032 to enable the reconstruction and examination of the sequence of 7033 environments and activities surrounding or leading to an 7034 operation, procedure, or event in a security-relevant transaction 7035 from inception to final results. [NCS04] (See: security audit.) 7037 $ security class 7038 (D) A synonym for "security level". In the interest of 7039 consistency, ISPDs SHOULD use "security level" instead of 7040 "security class". 7042 $ security clearance 7043 (I) A determination that a person is eligible, under the standards 7044 of a specific security policy, for authorization to access 7045 sensitive information or other system resources. (See: clearance 7046 level.) 7048 $ security compromise 7049 (I) A security violation in which a system resource is exposed, or 7050 is potentially exposed, to unauthorized access. (See: data 7051 compromise, violation.) 7053 $ security environment 7054 (I) The set of external entities, procedures, and conditions that 7055 affect secure development, operation, and maintenance of a system. 7057 $ security event 7058 (I) A occurrence in a system that is relevant to the security of 7059 the system. 7061 (C) The term includes both events that are security incidents and 7062 those that are not. In a CA workstation, for example, a list of 7063 security events might include the following: 7065 - Performing a cryptographic operation, e.g., signing a digital 7066 certificate or CRL. 7067 - Performing a cryptographic card operation: creation, insertion, 7068 removal, or backup. 7069 - Performing a digital certificate lifecycle operation: rekey, 7070 renewal, revocation, or update. 7071 - Posting information to an X.500 Directory. 7072 - Receiving a key compromise notification. 7073 - Receiving an improper certification request. 7074 - Detecting an alarm condition reported by a cryptographic 7075 module. 7076 - Logging the operator in or out. 7077 - Failing a built-in hardware self-test or a software system 7078 integrity check. 7080 $ security fault analysis 7081 (I) A security analysis, usually performed on hardware at a logic 7082 gate level, gate-by-gate, to determine the security properties of 7083 a device when a hardware fault is encountered. 7085 $ security gateway 7086 (I) A gateway that separates trusted (or relatively more trusted) 7087 hosts on the internal network side from untrusted (or less 7088 trusted) hosts on the external network side. (See: firewall and 7089 guard.) 7091 (O) IPsec usage: "An intermediate system that implements IPsec 7092 protocols." [R2401] Normally, AH or ESP is implemented to serve a 7093 set of internal hosts, providing security services for the hosts 7094 when they communicate with other, external hosts or gateways that 7095 also implement IPsec. 7097 $ security incident 7098 (I) A security event that involves a security violation. (See: 7099 CERT, GRIP, security event, security violation.) 7101 (C) In other words, a security-relevant event in a system in which 7102 the system's security policy is disobeyed or otherwise breached. 7104 (O) "Any adverse event which compromises some aspect of computer 7105 or network security." [R2350] 7107 (D) ISPDs SHOULD NOT use this "O" definition because (a) a 7108 security incident may occur without actually being harmful (i.e., 7109 adverse) and (b) this Glossary defines "compromise" more narrowly 7110 in relation to unauthorized access. 7112 $ security intrusion 7113 (I) A security event, or a combination of multiple security 7114 events, that constitutes a security incident in which an intruder 7115 gains, or attempts to gain, access to a system (or system 7116 resource) without having authorization to do so. 7118 $ security kernel 7119 (I) "The hardware, firmware, and software elements of a trusted 7120 computing base that implement the reference monitor concept. It 7121 must mediate all accesses, be protected from modification, and be 7122 verifiable as correct." [NCS04] (See: reference monitor.) 7124 (C) That is, a security kernel is an implementation of a reference 7125 monitor for a given hardware base. 7127 $ security label 7128 (I) A marking that is bound to a system resource and that names or 7129 designates the security-relevant attributes of that resource. 7130 [I7498 Part 2, R1457] 7132 (C) The recommended definition is usefully broad, but usually the 7133 term is understood more narrowly as a marking that represents the 7134 security level of an information object, i.e., a marking that 7135 indicates how sensitive an information object is. [NCS04] 7137 (C) System security mechanisms interpret security labels according 7138 to applicable security policy to determine how to control access 7139 to the associated information, otherwise constrain its handling, 7140 and affix appropriate security markings to visible (printed and 7141 displayed) images thereof. [FP188] 7143 $ security level 7144 (I) The combination of a hierarchical classification level and a 7145 set of non-hierarchical category designations that represents how 7146 sensitive information is. (See: dominate, lattice model.) 7148 $ security management infrastructure (SMI) 7149 (I) System elements and activities that support security policy by 7150 monitoring and controlling security services and mechanisms, 7151 distributing security information, and reporting security events. 7152 The associated functions are as follows [I7498-4]: 7154 - Controlling (granting or restricting) access to system 7155 resources: This includes verifying authorizations and 7156 identities, controlling access to sensitive security data, and 7157 modifying access priorities and procedures in the event of 7158 attacks. 7160 - Retrieving (gathering) and archiving (storing) security 7161 information: This includes logging security events and 7162 analyzing the log, monitoring and profiling usage, and 7163 reporting security violations. 7165 - Managing and controlling the encryption process: This includes 7166 performing the functions of key management and reporting on key 7167 management problems. (See: public-key infrastructure.) 7169 $ security mechanism 7170 (I) A process (or a device incorporating such a process) that can 7171 be used in a system to implement a security service that is 7172 provided by or within the system. (See: (discussion under) 7173 security policy.) 7175 (C) Some examples of security mechanisms are encryption, digital 7176 signature, authentication exchange, and traffic padding. 7178 $ security model 7179 (I) A schematic description of a set of entities and relationships 7180 by which a specified set of security services are provided by or 7181 within a system. (See: (discussion under) security policy.) 7183 (C) An example is the Bell-LaPadula Model. 7184 $ security parameters index (SPI) 7185 (I) IPsec usage: The type of security association identifier used 7186 in IPsec protocols. A 32-bit value used to distinguish among 7187 different security associations terminating at the same 7188 destination (IP address) and using the same IPsec security 7189 protocol (AH or ESP). Carried in AH and ESP to enable the 7190 receiving system to determine under which security association to 7191 process a received packet. 7193 $ security perimeter 7194 (I) The boundary of the domain in which a security policy or 7195 security architecture applies; i.e., the boundary of the space in 7196 which security services protect system resources. 7198 $ security policy 7199 (I) A set of rules and practices that specify or regulate how a 7200 system or organization provides security services to protect 7201 sensitive and critical system resources. (See: identity-based 7202 security policy, rule-based security policy, security 7203 architecture, security mechanism, security model.) 7205 (O) "The set of rules laid down by the security authority 7206 governing the use and provision of security services and 7207 facilities." [X509] 7209 (C) Ravi Sandhu notes (as shown in the following diagram) that 7210 security policy is one of four layers of the security engineering 7211 process. Each provides a different view of security, ranging from 7212 what security services are needed to how services are implemented. 7214 What Security Services Should Be Provided? 7215 ^ 7216 | + - - - - - - - - - - - + 7217 | | Security Policy | 7218 | + - - - - - - - - - - - + |A "top-level specification" 7219 | | Security Model | |is generally understood to 7220 | + - - - - - - - - - - - + <- |be at a level below "model" 7221 | | Security Architecture | |but above "architecture". 7222 | + - - - - - - - - - - - + 7223 | | Security Mechanism | 7224 | + - - - - - - - - - - - + 7225 v 7226 How Are Security Services Implemented? 7228 $ Security Protocol 3 (SP3) 7229 (O) A protocol [SDNS3] developed by SDNS to provide connectionless 7230 data security at the top of OSI layer 3. (See: NLSP.) 7232 $ Security Protocol 4 (SP4) 7233 (O) A protocol [SDNS4] developed by SDNS to provide either 7234 connectionless or end-to-end connection-oriented data security at 7235 the bottom of OSI layer 4. (See: TLSP.) 7237 $ security-relevant event 7238 See: security event. 7240 $ security service 7241 (I) A processing or communication service that is provided by a 7242 system to give a specific kind of protection to system resources. 7243 (See: access control service, audit service, availability service, 7244 data confidentiality service, data integrity service, data origin 7245 authentication service, non-repudiation service, peer entity 7246 authentication service, system integrity service.) 7248 (O) "A service, provided by a layer of communicating open systems, 7249 which ensures adequate security of the systems or the data 7250 transfers." [I7498 Part 2] 7252 (C) Security services implement security policies, and are 7253 implemented by security mechanisms. 7255 $ security situation 7256 (I) ISAKMP usage: The set of all security-relevant information 7257 (e.g., network addresses, security classifications, manner of 7258 operation--normal or emergency) that is needed to decide the 7259 security services that are required to protect the association 7260 that is being negotiated. 7262 $ security token 7263 See: token. 7265 $ security violation 7266 (I) An act or event that disobeys or otherwise breaches security 7267 policy. (See: compromise, penetration, security incident.) 7269 $ self-signed certificate 7270 (I) A public-key certificate for which the public key bound by the 7271 certificate and the private key used to sign the certificate are 7272 components of the same key pair, which belongs to the signer. 7274 (C) In a self-signed X.509 public-key certificate, the issuer's DN 7275 is the same as the subject's DN. 7277 $ semantic security 7278 (I) An attribute of a encryption algorithm that is a formalization 7279 of the notion that the algorithm not only hides the plaintext but 7280 also reveals no partial information about the plaintext. Whatever 7281 is efficiently computable about the plaintext when given the 7282 ciphertext, is also efficiently computable without the ciphertext. 7283 (See: indistinguishability.) 7285 $ sensitive (information) 7286 (I) Information is sensitive if disclosure, alteration, 7287 destruction, or loss of the information would adversely affect the 7288 interests or business of its owner or user. (See: critical.) 7290 $ separation of duties 7291 (I) The practice of dividing the steps in a system function among 7292 different individuals, so as to keep a single individual from 7293 subverting the process. (See: dual control, administrative 7294 security.) 7296 $ serial number 7297 See: certificate serial number. 7299 $ server 7300 (I) A system entity that provides a service in response to 7301 requests from other system entities called clients. 7303 $ session key 7304 (I) In the context of symmetric encryption, a key that is 7305 temporary or is used for a relatively short period of time. (See: 7306 key distribution center, master key.) 7308 (C) Usually, a session key is used for a defined period of 7309 communication between two computers, such as for the duration of a 7310 single connection or transaction set, or the key is used in an 7311 application that protects relatively large amounts of data and, 7312 therefore, needs to be rekeyed frequently. 7314 $ SET 7315 See: SET Secure Electronic Transaction(trademark). 7317 $ SET private extension 7318 (O) One of the private extensions for X.509 that are defined by 7319 SET to carry information about a hashed root key, certificate 7320 types, merchant data, cardholder certificate requirements, 7321 encryption support for tunneling, or message support for payment 7322 instructions. 7324 $ SET qualifier 7325 (O) A certificate policy qualifier that provides information about 7326 the location and content of a SET certificate policy. 7328 (C) In addition to the policies and qualifiers inherited from its 7329 own certificate, each CA in the SET certification hierarchy may 7330 add one qualifying statement to the root policy when the CA issues 7331 a certificate. The additional qualifier is a certificate policy 7332 for that CA. Each policy in a SET certificate may have these 7333 qualifiers: 7335 - A URL where a copy of the policy statement may be found. 7336 - An electronic mail address where a copy of the policy statement 7337 may be found. 7338 - A hash result of the policy statement, computed using the 7339 indicated algorithm. 7340 - A statement declaring any disclaimers associated with the 7341 issuing of the certificate. 7343 $ SET Secure Electronic Transaction(trademark) or SET(trademark) 7344 (N) A protocol developed jointly by MasterCard International and 7345 Visa International and published as an open standard to provide 7346 confidentiality of transaction information, payment integrity, and 7347 authentication of transaction participants for payment card 7348 transactions over unsecured networks, such as the Internet. [SET] 7349 (See: acquirer, brand, cardholder, dual signature, electronic 7350 commerce, issuer, merchant, payment gateway, third party.) 7352 (C) This term and acronym are trademarks of SETCo. MasterCard and 7353 Visa announced the standard on February 1, 1996. On December 19, 7354 1997, MasterCard and Visa formed SET Secure Electronic Transaction 7355 LLC (commonly referred to as "SETCo") to implement the SET 1.0 7356 specification. A memorandum of understanding also has been signed 7357 that will eventually add American Express and JCB Credit Card 7358 Company as co-owners of SETCo. 7360 $ SETCo 7361 See: (secondary definition in) SET Secure Electronic Transaction. 7363 $ SHA-1 7364 See: Secure Hash Standard. 7366 $ shared secret 7367 (I) A synonym for "keying material" or "cryptographic key". 7369 $ S-HTTP 7370 See: Secure HTTP. 7372 $ sign 7373 (I) Create a digital signature for a data set. 7375 $ signature 7376 See: digital signature, electronic signature. 7378 $ signer 7379 (N) A human being or an organization entity that creates a digital 7380 signature for a data set. [ABA] 7382 $ SILS 7383 See: Standards for Interoperable LAN/MAN Security. 7385 $ simple authentication 7386 (I) An authentication process that uses a password as the 7387 information that verifies an identity claimed for an entity. (See: 7388 strong authentication.) 7390 (O) "Authentication by means of simple password arrangements." 7391 [X509] 7393 $ Simple Authentication and Security Layer (SASL) 7394 (I) A specification [R2222] for adding authentication service to 7395 connection-based protocols. To use SASL, a protocol includes a 7396 command for authenticating a user to a server and for optionally 7397 negotiating protection of subsequent protocol interactions. The 7398 command names a registered security mechanism. SASL mechanisms 7399 include Kerberos, GSSAPI, S/KEY, and others. Some protocols that 7400 use SASL are IMAP4 and POP3. 7402 $ Simple Key-management for Internet Protocols (SKIP) 7403 (I) A key distribution protocol that uses hybrid encryption to 7404 convey session keys that are used to encrypt data in IP packets. 7406 (C) SKIP uses the Diffie-Hellman algorithm (or could use another 7407 key agreement algorithm) to generate a key-encrypting key for use 7408 between two entities. A session key is used with a symmetric 7409 algorithm to encrypt data in one or more IP packets that are to be 7410 sent from one of the entities to the other. The KEK is used with a 7411 symmetric algorithm to encrypt the session key, and the encrypted 7412 session key is placed in a SKIP header that is added to each IP 7413 packet that is encrypted with that session key. 7415 $ Simple Mail Transfer Protocol (SMTP) 7416 (I) A TCP-based, application-level, Internet Standard protocol for 7417 moving electronic mail messages from one computer to another. 7418 [R0821]. 7420 $ Simple Network Management Protocol (SNMP) 7421 (I) A TCP-based, application-level, Internet Standard protocol for 7422 conveying management information between managers and agents. 7423 [R2570, R2574]. 7425 $ simple security property 7426 See: (secondary definition in) Bell-LaPadula Model. 7428 $ single sign-on 7429 (I) A system that enables a user to access multiple computer 7430 platforms (usually a set of hosts on the same network) or 7431 application systems after being authenticated just one time. (See: 7432 Kerberos.) 7434 (C) Typically, a user logs in just once, and then is transparently 7435 granted access to a variety of permitted resources with no further 7436 login being required until after the user logs out. Such a system 7437 has the advantages of being user friendly and enabling 7438 authentication to be managed consistently across an entire 7439 enterprise, and has the disadvantage of requiring all hosts to 7440 trust the same authentication mechanism. 7442 $ signature certificate 7443 (I) A public-key certificate that contains a public key that is 7444 intended to be used for verifying digital signatures, rather than 7445 for encrypting data or performing other cryptographic functions. 7447 (C) A v3 X.509 public-key certificate may have a "keyUsage" 7448 extension which indicates the purpose for which the certified 7449 public key is intended. 7451 $ situation 7452 See: security situation. 7454 $ S/Key 7455 (I) A system that uses a cryptographic hash function to generate a 7456 sequence of 64-bit, one-time passwords for remote user login. 7457 [R1760]. 7459 (C) The client generates a one-time password by applying MD4, a 7460 cryptographic hash function, to the user's secret key multiple 7461 times. For each successive authentication of the user, the number 7462 of hash applications is reduced by one. (Thus, an intruder using 7463 wiretapping cannot compute a valid password from knowledge of one 7464 previously used.) The server verifies a password by hashing the 7465 currently presented password (or initialization value) one time 7466 and comparing the hash result with the previously presented 7467 password. 7469 $ SKIP 7470 See: Simple Key-management for IP. 7472 $ SKIPJACK 7473 (O) A Type II block cipher with a block size of 64 bits and a key 7474 size of 80 bits, that was developed by NSA and formerly classified 7475 at the "Secret" level. (See: CAPSTONE, CLIPPER, FORTEZZA, Key 7476 Exchange Algorithm.) 7478 (C) On 23 June 1998, NSA announced that SKIPJACK had been 7479 declassified. 7481 $ slot 7482 (O) MISSI usage: One of the FORTEZZA PC card storage areas that 7483 are each able to hold an X.509 certificate and additional data 7484 that is associated with the certificate, such as the matching 7485 private key. 7487 $ smart card 7488 (I) A credit-card sized device containing one or more integrated 7489 circuit chips, which perform the functions of a computer's 7490 microprocessor, memory, and input/output interface. (See: PC 7491 card.) 7493 (C) Sometimes this term is used rather strictly to mean a card 7494 that closely conforms to the dimensions and appearance of the kind 7495 of plastic credit card issued by banks and merchants. At other 7496 times, the term is used loosely to include cards that are large, 7497 especially cards that are much thicker, such as PC cards. 7499 (C) A "smart token" is a device that conforms to the definition of 7500 smart card, except that it is not have standard credit dimensions, 7501 but is packaged in some other form convenient to be carried on 7502 one's person, such as a dog tag or door key shape. 7504 $ smart token 7505 See: (secondary definition in) smart card. 7507 $ SMI 7508 See: security management infrastructure. 7510 $ S/MIME 7511 See: Secure/MIME. 7513 $ SMTP 7514 See: Simple Mail Transfer Protocol. 7516 $ smurf 7517 (I) Software that mounts a denial-of-service attack ("smurfing") 7518 by exploiting IP broadcast addressing and ICMP ping packets to 7519 cause flooding. (See: flood, ICMP flood.) 7521 (D) ISPDs SHOULD NOT use this term because it is not listed in 7522 most dictionaries and might confuse international readers. 7524 (C) A smurf program builds a network packet that appears to 7525 originate from another address, that of the "victim", either a 7526 host or an IP router. The packet contains an ICMP ping message 7527 that is addressed to an IP broadcast address, i.e., to all IP 7528 addresses in a given network. The echo responses to the ping 7529 message return to the victim's address. The goal of smurfing may 7530 be either to deny service at a particular host or to flood all or 7531 part of an IP network. 7533 $ sniffing 7534 (C) A synonym for "passive wiretapping". (See: password sniffing.) 7536 (D) ISPDs SHOULD NOT use this term because it unnecessarily 7537 duplicates the meaning of a term that is better established. (See: 7538 (usage note under) Green Book. 7540 $ SNMP 7541 See: Simple Network Management Protocol. 7543 $ social engineering 7544 (I) A euphemism for non-technical or low-technology means--such as 7545 lies, impersonation, tricks, bribes, blackmail, and threats--used 7546 to attack information systems. (See: masquerade attack.) 7548 (D) ISPDs SHOULD NOT use this term because it is vague; instead, 7549 use a term that is specific with regard to the means of attack. 7551 $ SOCKS 7552 (I) A protocol [R1928] that provides a generalized proxy server 7553 that enables client-server applications--such as TELNET, FTP, and 7554 HTTP; running over either TCP or UDP--to use the services of a 7555 firewall. 7557 (C) SOCKS is layered under the application layer and above the 7558 transport layer. When a client inside a firewall wishes to 7559 establish a connection to an object that is reachable only through 7560 the firewall, it uses TCP to connect to the SOCKS server, 7561 negotiates with the server for the authentication method to be 7562 used, authenticates with the chosen method, then sends a relay 7563 request. The SOCKS server evaluates the request, typically based 7564 on source and destination addresses, and either establishes the 7565 appropriate connection or denies it. 7567 $ soft TEMPEST 7568 (O) The use of software techniques to reduce the radio frequency 7569 information leakage from computer displays and keyboards. [Kuhn] 7570 (See: TEMPEST.) 7572 $ software 7573 (I) Computer programs (which are stored in and executed by 7574 computer hardware) and associated data (which is stored in the 7575 hardware) that may be dynamically written or modified during 7576 execution. (Compare with: firmware, hardware.) 7578 $ SORA 7579 See: SSO-PIN ORA. 7581 $ source integrity 7582 (I) The degree of confidence that can be placed in information 7583 based on the trustworthiness of its sources. (See: integrity.) 7585 $ SP3 7586 See: Security Protocol 3. 7588 $ SP4 7589 See: Security Protocol 4. 7591 $ spam 7592 (I) (1.) Verb: To indiscriminately send unsolicited, unwanted, 7593 irrelevant, or inappropriate messages, especially commercial 7594 advertising in mass quantities. (2.) Noun: electronic "junk mail". 7595 [R2635] 7597 (D) This term SHOULD NOT be written in upper-case letters, because 7598 SPAM(trademark) is a trademark of Hormel Foods Corporation. Hormel 7599 says, "We do not object to use of this slang term [spam] to 7600 describe [unsolicited commercial email (UCE)], although we do 7601 object to the use of our product image in association with that 7602 term. Also, if the term is to be used, it should be used in all 7603 lower-case letters to distinguish it from our trademark SPAM, 7604 which should be used with all uppercase letters." 7606 (C) In sufficient volume, spam can cause denial of service. (See: 7607 flooding.) According to the SPAM Web site, the term was adopted as 7608 a result of the Monty Python skit in which a group of Vikings sang 7609 a chorus of 'SPAM, SPAM, SPAM . . .' in an increasing crescendo, 7610 drowning out other conversation. Hence, the analogy applied 7611 because UCE was drowning out normal discourse on the Internet. 7613 $ SPC 7614 See: software publisher certificate. 7616 $ SPI 7617 See: Security Parameters Index. 7619 $ split key 7620 (I) A cryptographic key that is divided into two or more separate 7621 data items that individually convey no knowledge of the whole key 7622 that results from combining the items. (See: dual control, split 7623 knowledge.) 7625 $ split knowledge 7626 (I) A security technique in which two or more entities separately 7627 hold data items that individually convey no knowledge of the 7628 information that results from combining the items. (See: dual 7629 control, split key.) 7631 (O) "A condition under which two or more entities separately have 7632 key components which individually convey no knowledge of the 7633 plaintext key which will be produced when the key components are 7634 combined in the cryptographic module." [FP140] 7636 $ spoofing attack 7637 (I) A synonym for "masquerade attack". 7639 $ SSH 7640 (I) A protocol for secure remote login and other secure network 7641 services over an insecure network. 7643 (C) Consists of three major components: 7645 - Transport layer protocol provides server authentication, 7646 confidentiality, and integrity. It may optionally also provide 7647 compression. The transport layer will typically be run over a 7648 TCP/IP connection, but might also be used on top of any other 7649 reliable data stream. 7651 - User authentication protocol authenticates the client-side user 7652 to the server. It runs over the transport layer protocol. 7654 - Connection protocol multiplexes the encrypted tunnel into 7655 several logical channels. It runs over the user authentication 7656 protocol. 7658 $ SSL 7659 See: Secure Sockets Layer, Standard Security Label. 7661 $ SSO 7662 See: system security officer. 7664 $ SSO PIN 7665 (O) MISSI usage: One of two personal identification numbers that 7666 control access to the functions and stored data of a FORTEZZA PC 7667 card. Knowledge of the SSO PIN enables the card user to perform 7668 the FORTEZZA functions intended for use by an end user and also 7669 the functions intended for use by a MISSI certification authority. 7670 (See: user PIN.) 7672 $ SSO-PIN ORA (SORA) 7673 (O) MISSI usage: A MISSI organizational RA that operates in a mode 7674 in which the ORA performs all card management functions and, 7675 therefore, requires knowledge of the SSO PIN for an end user's 7676 FORTEZZA PC card. 7678 $ Standards for Interoperable LAN/MAN Security (SILS) 7679 (N) (1.) The IEEE 802.10 standards committee. (2.) A developing 7680 set of IEEE standards, which has eight parts: (a) Model, including 7681 security management, (b) Secure Data Exchange protocol, (c) Key 7682 Management, (d) [has been incorporated in (a)], (e) SDE Over 7683 Ethernet 2.0, (f) SDE Sublayer Management, (g) SDE Security 7684 Labels, and (h) SDE PICS Conformance. Parts b, e, f, g, and h are 7685 incorporated in IEEE Standard 802.10-1998. 7687 $ star property 7688 (I) See: "confinement property" under Bell-LaPadula Model. 7690 $ Star Trek attack 7691 (C) An attack that penetrates your system where no attack has ever 7692 gone before. 7694 $ steganography 7695 (I) Methods of hiding the existence of a message or other data. 7696 This is different than cryptography, which hides the meaning in a 7697 message but does not hide the message itself. (See: cryptology.) 7699 (C) An example of a steganographic method is "invisible" ink. 7700 (See: digital watermark.) 7702 $ storage channel 7703 See: (secondary definition in) covert channel. 7705 $ stream cipher 7706 (I) An encryption algorithm that breaks plaintext into a stream of 7707 successive bits (or characters) and encrypts the n-th plaintext 7708 bit with the n-th element of a parallel key stream, thus 7709 converting the plaintext bit stream into a ciphertext bit stream. 7710 [Schn] (Compare with: block cipher.) 7712 $ strong authentication 7713 (I) An authentication process that uses cryptography--particularly 7714 public-key certificates--to verify the identity claimed for an 7715 entity. (See: X.509.) 7717 (O) "Authentication by means of cryptographically derived 7718 credentials." [X509] 7720 $ subject 7721 1. (I) In a computer system: A system entity that causes 7722 information to flow among objects or changes the system state; 7723 technically, a process-domain pair. (See: Bell-LaPadula Model.) 7725 2. (I) Of a certificate: The entity name that is bound to the data 7726 items in a digital certificate, and particularly a name that is 7727 bound to a key value in a public-key certificate. 7729 $ subnetwork 7730 (N) An OSI term for a system of packet relays and connecting links 7731 that implement the lower three protocol layers of the OSIRM to 7732 provide a communication service that interconnects attached end 7733 systems. Usually the switches operate at OSI layer 3 and are all 7734 of the same type (e.g., all X.25 packet switches, or all interface 7735 units in an IEEE 802.3 LAN). (See: gateway, internet, router.) 7737 $ subordinate certification authority (SCA) 7738 (I) A CA whose public-key certificate is issued by another 7739 (superior) CA. 7741 (O) MISSI usage: The fourth-highest (bottom) level of a MISSI 7742 certification hierarchy; a MISSI certification authority whose 7743 public-key certificate is signed by a MISSI CA rather than by a 7744 MISSI PCA. A MISSI SCA is the administrative authority for a 7745 subunit of an organization, established when it is desirable to 7746 organizationally distribute or decentralize the CA service. The 7747 term refers both to that authoritative office or role, and to the 7748 person who fills that office A MISSI SCA registers end users and 7749 issues their certificates and may also register ORAs, but may not 7750 register other CAs. An SCA periodically issues a CRL. 7752 $ subordinate distinguished name 7753 (I) An X.500 DN is subordinate to another if it begins with a set 7754 of attributes that is the same as the entire second DN except for 7755 the terminal attribute of the second DN (which is usually the name 7756 of a CA). For example, the DN is subordinate to the DN . 7760 $ superencryption 7761 (I) An encryption operation for which the plaintext input to be 7762 transformed is the ciphertext output of a previous encryption 7763 operation. 7765 $ survivability 7766 (I) The ability of a system to remain in operation or existence 7767 despite adverse conditions, including both natural occurrences, 7768 accidental actions, and attacks on the system. (See: availability, 7769 reliability.) 7771 $ symmetric cryptography 7772 (I) A branch of cryptography involving algorithms that use the 7773 same key for two different steps of the algorithm (such as 7774 encryption and decryption, or signature creation and signature 7775 verification). 7777 (C) Symmetric cryptography has been used for thousands of years 7778 [Kahn]. A modern example of is the U.S. Government's Data 7779 Encryption Standard. Symmetric cryptography is sometimes called 7780 "secret-key cryptography" (also see: public-key cryptography) 7781 because the entities that share the key, such as the originator 7782 and the recipient of a message, need to keep the key secret. For 7783 example, when Alice wants to ensure confidentiality for data she 7784 sends to Bob, she encrypts the data with a secret key, and Bob 7785 uses the same key to decrypt. Keeping the shared key secret 7786 entails both cost and risk when the key is distributed to both 7787 Alice and Bob. Thus, symmetric cryptography has a key management 7788 disadvantage compared to asymmetric cryptography. (See: key 7789 agreement.) 7791 $ symmetric key 7792 (I) A cryptographic key that is used in a symmetric cryptographic 7793 algorithm. 7795 $ SYN flood 7796 (I) A denial of service attack that sends a host more TCP SYN 7797 packets (request to synchronize sequence numbers, used when 7798 opening a connection) than the protocol implementation can handle. 7799 (See: flooding.) 7801 $ system 7802 (C) In this Glossary, the term is mainly used as an abbreviation 7803 for "automated information system". 7805 $ system entity 7806 (I) An active element of a system--an automated process, a 7807 subsystem, a person or group of persons--that incorporates some 7808 specific set of capabilities. 7810 $ system high 7811 (I) The highest security level supported by a system at a 7812 particular time or in a particular environment. 7814 $ system high security mode 7815 (I) A mode of operation of an information system, wherein all 7816 users having access to the system possess a security clearance or 7817 authorization, but not necessarily a need-to-know, for all data 7818 handled by the system. 7820 (C) This mode is defined formally in U.S. Department of Defense 7821 policy regarding system accreditation [DOD2], but the term is 7822 widely used outside the Defense Department and outside the 7823 Government. 7825 $ system integrity 7826 (I) "The quality that a system has when it can perform its 7827 intended function in a unimpaired manner, free from deliberate or 7828 inadvertent unauthorized manipulation." [NCS04] (See: system 7829 integrity service.) 7831 $ system integrity service 7832 (I) A security service that protects system resources in a 7833 verifiable manner against unauthorized or accidental change, loss, 7834 or destruction. (See: system integrity.) 7836 $ system low 7837 (I) The lowest security level supported by a system at a 7838 particular time or in a particular environment. 7840 $ system resource 7841 (I) Data contained in an information system; or a service provided 7842 by a system; or a system capability, such as processing power or 7843 communication bandwidth; or an item of system equipment (i.e., a 7844 system component--hardware, firmware, software, or documentation); 7845 or a facility that houses system operations and equipment. 7847 $ system verification 7848 See: (secondary definition in) verification. 7850 $ TACACS 7851 $ TACACS+ 7852 See: Terminal Access Controller (TAC) Access Control System. 7854 $ tamper 7855 (I) Make an unauthorized modification in a system that alters the 7856 system's functioning in a way that degrades the security services 7857 that the system was intended to provide. 7859 $ TCB 7860 See: trusted computing base. 7862 $ TCP 7863 See: Transmission Control Protocol. 7865 $ TCP/IP 7866 (I) A synonym for "Internet Protocol Suite", in which the 7867 Transmission Control Protocol (TCP) and the Internet Protocol (IP) 7868 are important parts. 7870 $ TCSEC 7871 See: Trusted Computer System Evaluation Criteria. 7873 $ TELNET 7874 (I) A TCP-based, application-level, Internet Standard protocol for 7875 remote login from one host to another. [R0854] 7877 $ TEMPEST 7878 (O) A nickname for specifications and standards for limiting the 7879 strength of electromagnetic emanations from electrical and 7880 electronic equipment and thus reducing vulnerability to 7881 eavesdropping. This term originated in the U.S. Department of 7882 Defense. (See: emanation security, soft tempest.) 7884 (D) ISPDs SHOULD NOT use this term as a synonym for 7885 "electromagnetic emanations security". 7887 $ Terminal Access Controller (TAC) Access Control System (TACACS) 7888 (I) A UDP-based authentication and access control protocol [R1492] 7889 in which a network access server receives an identifier and 7890 password from a remote terminal and passes them to a separate 7891 authentication server for verification. Originally developed for 7892 ARPANET and now evolved for use in commercial equipment: 7894 - "XTACACS": The name of Cisco Corporation's implementation, 7895 which enhances and extends the original TACACS. 7897 - "TACACS+": A TCP-based protocol that improves on TACACS and 7898 XTACACS by separating the functions of authentication, 7899 authorization, and accounting and by encrypting all traffic 7900 between the network access server and authentication server. It 7901 is extensible to allow any authentication mechanism to be used 7902 with TACACS+ clients. 7904 (C) TACACS can provide service not only for network access servers 7905 but also routers and other networked computing devices via one or 7906 more centralized authentication servers. 7908 $ TESS 7909 See: The Exponential Encryption System. 7911 $ The Exponential Encryption System (TESS) 7912 (I) A system of separate by cooperation cryptographic mechanisms 7913 and functions for the secure authenticated exchange of 7914 cryptographic keys, the generation of digital signatures, and the 7915 distribution of public keys. TESS employs asymmetric cryptography, 7916 based on discrete exponentiation, and a structure of self- 7917 certified public keys. [R1824] 7919 $ threat 7920 (I) A potential for violation of security, which exists when there 7921 is a circumstance, capability, action, or event that could breach 7922 security and cause harm. (See: attack, threat action, threat 7923 consequence.) 7925 (C) That is, a threat is a possible danger that might exploit a 7926 vulnerability. A threat can be either "intentional" (i.e., 7927 intelligent; e.g., an individual cracker or a criminal 7928 organization) or "accidental" (e.g., the possibility of a computer 7929 malfunctioning, or the possibility of an "act of God" such as an 7930 earthquake, a fire, or a tornado). 7932 (C) In some contexts, the term is used narrowly to refer only to 7933 intelligent threats; for example: 7935 (N) U. S. Government usage: The technical and operational 7936 capability of a hostile entity to detect, exploit, or subvert 7937 friendly information systems and the demonstrated, presumed, or 7938 inferred intent of that entity to conduct such activity. 7940 $ threat action 7941 (I) An assault on system security. (See: attack, threat, threat 7942 consequence.) 7944 (C) A complete security architecture deals with both intentional 7945 acts (i.e. attacks) and accidental events [FIPS31]. Various kinds 7946 of threat actions are defined as subentries under "threat 7947 consequence". 7949 $ threat analysis 7950 (I) An analysis of the probability of occurrences and consequences 7951 of damaging actions to a system. 7953 $ threat consequence 7954 (I) A security violation that results from a threat action. 7955 Includes disclosure, deception, disruption, and usurpation. (See: 7956 attack, threat, threat action.) 7958 (C) The following subentries describe four kinds of threat 7959 consequences, and also list and describe the kinds of threat 7960 actions that cause each consequence. Threat actions that are 7961 accidental events are marked by "*". 7963 1. "(Unauthorized) Disclosure" (a threat consequence): A 7964 circumstance or event whereby an entity gains access to data 7965 for which the entity is not authorized. (See: data 7966 confidentiality.) The following threat actions can cause 7967 unauthorized disclosure: 7969 A. "Exposure": A threat action whereby sensitive data is 7970 directly released to an unauthorized entity. This includes: 7972 a. "Deliberate Exposure: Intentional release of sensitive 7973 data to an unauthorized entity. 7975 b. "Scavenging": Searching through data residue in a system 7976 to gain unauthorized knowledge of sensitive data. 7978 c* "Human error": Human action or inaction that 7979 unintentionally results in an entity gaining unauthorized 7980 knowledge of sensitive data. 7982 d* "Hardware/software error". System failure that results in 7983 an entity gaining unauthorized knowledge of sensitive 7984 data. 7986 B. "Interception": A threat action whereby an unauthorized 7987 entity directly accesses sensitive data traveling between 7988 authorized sources and destinations. This includes: 7990 a. "Theft": Gaining access to sensitive data by stealing a 7991 shipment of a physical medium, such as a magnetic tape or 7992 disk, that holds the data. 7994 b. "Wiretapping (passive): Monitoring and recording data 7995 that is flowing between two points in a communication 7996 system. (See: wiretapping.) 7998 c. "Emanations analysis": Gaining direct knowledge of 7999 communicated data by monitoring and resolving a signal 8000 that is emitted by a system and that contains the data 8001 but is not intended to communicate the data. (See: 8002 emanation.) 8004 C. "Inference": A threat action whereby an unauthorized entity 8005 indirectly accesses sensitive data (but not necessarily the 8006 data contained in the communication) by reasoning from 8007 characteristics or byproducts of communications. This 8008 includes: 8010 a. Traffic analysis: Gaining knowledge of data by observing 8011 the characteristics of communications that carry the 8012 data. (See: (main Glossary entry for) traffic analysis.) 8014 b. "Signals analysis": Gaining indirect knowledge of 8015 communicated data by monitoring and analyzing a signal 8016 that is emitted by a system and that contains the data 8017 but is not intended to communicate the data. (See: 8018 emanation.) 8020 D. "Intrusion": A threat action whereby an unauthorized entity 8021 gains access to sensitive data by circumventing a system's 8022 security protections. This includes: 8024 a. "Trespass": Gaining unauthorized physical access to 8025 sensitive data by circumventing a system's protections. 8027 b. "Penetration": Gaining unauthorized logical access to 8028 sensitive data by circumventing a system's protections. 8030 c. "Reverse engineering": Acquiring sensitive data by 8031 disassembling, and analyzing the design, of a system 8032 component. 8034 d. Cryptanalysis: Transforming encrypted data into plaintext 8035 without having prior knowledge of variables or algorithms 8036 used in the encipherment process. (See: (main Glossary 8037 entry for) cryptanalysis.) 8039 2. "Deception" (a threat consequence): A circumstance or event 8040 that may result in an authorized entity receiving false data 8041 and believing it to be true. The following threat actions can 8042 cause deception: 8044 A. "Masquerade": A threat action whereby an unauthorized entity 8045 gains access to a system or performs a malicious act by 8046 posing as an authorized entity.(See: (main Glossary entry 8047 for) masquerade attack.) 8049 a. "Spoof": Attempt by an unauthorized entity to gain access 8050 to a system by posing as an authorized user. 8052 b. "Malicious logic": In context of masquerade, any 8053 hardware, firmware, or software (e.g., Trojan horse) that 8054 appears to perform a useful or desirable function, but 8055 actually gains unauthorized access to system resources or 8056 tricks a user into executing other malicious logic. (See: 8057 (main Glossary entry for) malicious logic.) 8059 B. "Falsification": A threat action whereby false data deceives 8060 an authorized entity. (See: active wiretapping.) 8062 a. "Substitution": Altering or replacing valid data with 8063 false data that serves to deceive an authorized entity. 8065 b. "Insertion": Introducing or adding valid data with false 8066 data that serves to deceive an authorized entity. 8068 C. "Repudiation": Action whereby an entity deceives another by 8069 falsely denying responsibility for an act. (See: non- 8070 repudiation service, (main Glossary entry for) repudiation.) 8072 a. "False denial of origin": A threat action whereby the 8073 originator of data denies responsibility for its 8074 generation. 8076 b. "False denial of receipt": A threat action whereby the 8077 recipient of data denies receiving and possessing the 8078 data. 8080 3. "Disruption" (a threat consequence): A circumstance or event 8081 that interrupts or prevents the correct operation of system 8082 services and functions. (See: denial of service.) The following 8083 threat actions that can cause disruption: 8085 A. "Incapacitation": A threat action that prevents or 8086 interrupts system operation by disabling a system component. 8088 a. "Malicious logic": In context of incapacitation, any 8089 hardware, firmware, or software (e.g., logic bomb) 8090 intentionally introduced into a system to destroy system 8091 functions or resources. (See: (main Glossary entry for) 8092 malicious logic.) 8094 b. "Physical destruction": Deliberate destruction of a 8095 system component to interrupt or prevent system 8096 operation. 8098 c* "Human error": Action or inaction that disables a system 8099 component. 8101 d* "Hardware or software error": Error that causes failure 8102 of a system component and leads to disruption of system 8103 operation. 8105 e* "Natural disaster": Any "act of God" (e.g., fire, flood, 8106 earthquake, lightning, or wind) that disables a system 8107 component. [FP031 section 2] 8109 B. "Corruption": A threat action that undesirably alters system 8110 operation by adversely modifying system functions or data. 8112 a. "Tamper": In context of corruption, deliberate alteration 8113 of a system's logic, data, or control information to 8114 interrupt or prevent correct operation of system 8115 functions. 8117 b. "Malicious logic": In context of corruption, any 8118 hardware, firmware, or software (e.g., a computer virus) 8119 intentionally introduced into a system to modify system 8120 functions or data. (See: (main Glossary entry for) 8121 malicious logic.) 8123 c* "Human error": Human action or inaction that results in 8124 the alteration of system functions or data. 8126 d* "Hardware or software error": Error that results in the 8127 alteration of system functions or data. 8129 e* "Natural disaster": Any "act of God" (e.g., power surge 8130 caused by lightning) that alters system functions or 8131 data. [FP031 section 2] 8133 C. "Obstruction": A threat action that interrupts delivery of 8134 system services by hindering system operations. 8136 a. "Interference": Disruption of system operations by 8137 blocking communications or user data or control 8138 information. 8140 b. "Overload": Hindrance of system operation by placing 8141 excess burden on the performance capabilities of a system 8142 component. (See: flooding.) 8144 4. "Usurpation" (a threat consequence): A circumstance or event 8145 that results in control of system services or functions by an 8146 unauthorized entity. The following threat actions can cause 8147 usurpation: 8149 A. "Misappropriation": A threat action whereby an entity 8150 assumes unauthorized logical or physical control of a system 8151 resource. 8153 a. "Theft of service": Unauthorized use of service by an 8154 entity. 8156 b. "Theft of functionality": Unauthorized acquisition of 8157 actual hardware, software, or firmware of a system 8158 component. 8160 c. "Theft of data": Unauthorized acquisition and use of 8161 data. 8163 B. "Misuse": A threat action that causes a system component to 8164 perform a function or service that is detrimental to system 8165 security. 8167 a. "Tamper": In context of misuse, deliberate alteration of 8168 a system's logic, data, or control information to cause 8169 the system to perform unauthorized functions or services. 8171 b. "Malicious logic": In context of misuse, any hardware, 8172 software, or firmware intentionally introduced into a 8173 system to perform or control execution of an unauthorized 8174 function or service. 8176 c. "Violation of permissions": Action by an entity that 8177 exceeds the entity's system privileges by executing an 8178 unauthorized function. 8180 $ thumbprint 8181 (I) A pattern of curves formed by the ridges on the tip of a 8182 thumb. (See: biometric authentication, fingerprint.) 8184 (D) ISPDs SHOULD NOT use this term as a synonym for "hash result" 8185 because that meaning concepts in a potentially misleading way. 8187 $ ticket 8188 (I) A synonym for "capability". 8190 (C) A ticket is usually granted by a centralized access control 8191 server (ticket-granting agent) to authorize access to a system 8192 resource for a limited time. Tickets have been implemented with 8193 symmetric cryptography (see: Kerberos), but can also be 8194 implemented as attribute certificates using asymmetric 8195 cryptography. In effect, an RA that does not issue digital 8196 certificates itself, but vouches for the identity of prospective 8197 certificate holders to a CA, is a ticket-granting agent. [FPKI] 8199 $ timing channel 8200 See: (secondary definition in) covert channel. 8202 $ TLS 8203 See: Transport Layer Security. (See: TLSP.) 8205 $ TLSP 8206 See: Transport Layer Security Protocol. (See: TLS.) 8208 $ token 8209 1. (I) General usage: An object that is used to control access and 8210 is passed between cooperating entities in a protocol that 8211 synchronizes use of a shared resource. Usually, the entity that 8212 currently holds the token has exclusive access to the resource. 8214 2. (I) Authentication usage: A data object or a portable, user- 8215 controlled, physical device used to verify an identity in an 8216 authentication process. (See: authentication information, dongle.) 8218 3. (I) Cryptographic usage: See: cryptographic token. 8220 $ token backup 8221 (I) A token management operation that stores sufficient 8222 information in a database (e.g., in a CAW) to recreate or restore 8223 a security token (e.g., a smart card) if it is lost or damaged. 8225 $ token copy 8226 (I) A token management operation that copies all the personality 8227 information from one security token to another. However, unlike in 8228 card restore, the second card is initialized with its own, 8229 different local security values such as PINs and card storage 8230 keys. 8232 $ token management 8233 (I) The process of initializing security tokens (e.g., see: smart 8234 card), loading data into the tokens, and controlling the tokens 8235 during their life cycle. May include performing key management and 8236 certificate management functions; generating and installing PINs; 8237 loading user personality data; performing card backup, card copy, 8238 and card restore operations; and updating firmware. 8240 $ token restore 8241 (I) A token management operation that loads a token with data for 8242 the purpose of recreating (duplicating) the contents previously 8243 held by that or another token. 8245 $ token storage key 8246 (I) A cryptography key used to protect data that is stored on a 8247 security token. 8249 $ top CA 8250 (I) A CA that is the highest level (i.e., is the most trusted CA) 8251 in a certification hierarchy. (See: root.) 8253 $ top-level specification 8254 (I) "A non-procedural description of system behavior at the most 8255 abstract level; typically a functional specification that omits 8256 all implementation details." [NCS04] (See: (discussion under) 8257 security policy.) 8259 (C) A top-level specification may be descriptive or formal: 8261 - "Descriptive top-level specification": One that is written in a 8262 natural language like English or an informal design notation. 8264 - "Formal top-level specification": One that is written in a 8265 formal mathematical language to allow theorems to be proven 8266 showing that the specification correctly implements a set of 8267 formal requirements or a formal security model. (See: correctness 8268 proof.) 8270 $ traffic analysis 8271 (I) Inference of information from observable characteristics of 8272 data flow(s), even when the data is encrypted or otherwise not 8273 directly available. Such characteristics include the identities 8274 and locations of the source(s) and destination(s), and the 8275 presence, amount, frequency, and duration of occurrence. (See: 8276 wiretapping.) 8278 (O) "The inference of information from observation of traffic 8279 flows (presence, absence, amount, direction, and frequency)." 8280 [I7498 Part 2] 8282 $ traffic flow confidentiality 8283 (I) A data confidentiality service to protect against traffic 8284 analysis. 8286 (O) "A confidentiality service to protect against traffic 8287 analysis." [I7498 Part 2] 8289 $ traffic padding 8290 (I) "The generation of spurious instances of communication, 8291 spurious data units, and/or spurious data within data units." 8292 [I7498 Part 2] 8294 $ tranquillity property 8295 See: (secondary definition in) Bell-LaPadula Model. 8297 $ Transmission Control Protocol (TCP) 8298 (I) An Internet Standard protocol [R0793] that reliably delivers a 8299 sequence of datagrams (discrete sets of bits) from one computer to 8300 another in a computer network. 8302 (C) TCP is designed to fit into a layered hierarchy of protocols 8303 that support internetwork applications. TCP assumes it can obtain 8304 a simple, potentially unreliable datagram service (such as the 8305 Internet Protocol) from the lower level protocols. 8307 $ Transport Layer Security (TLS) 8308 (I) TLS Version 1.0 is an Internet protocol based-on and very 8309 similar to SSL Version 3.0. (Compare with: TLSP.) 8311 (C) The TLS protocol is misnamed, because it operates well above 8312 OSI layer 4. 8314 $ Transport Layer Security Protocol (TLSP) 8315 (I) An end-to-end encryption (ISO 10736) protocol that provides 8316 security services at the bottom of OSI layer 4, i.e., directly 8317 above OSI layer 3. (Compare with: TLS.) 8319 (C) TLSP evolved directly from the SP4 protocol of SDNS. 8321 $ transport mode vs. tunnel mode 8322 (I) IPsec usage: Two ways to apply IPsec protocols (AH and ESP) to 8323 protect communications: 8325 - "Transport mode": The protection applies mainly to the packets 8326 of upper layer protocols, the ones that are carried above IP. 8328 - "Tunnel mode": The protection applies to tunneled IP packets. 8330 (C) A transport mode security association is always between two 8331 hosts. A tunnel mode security association is one that is applied 8332 to an IP tunnel, but the each end may be either a host or a 8333 gateway; and, whenever either end of a security association is a 8334 security gateway, the association is required to be in tunnel 8335 mode. 8337 $ trap door 8338 (I) A hidden computer flaw known to an intruder, or hidden 8339 computer mechanism (usually software) installed by an intruder, 8340 who can activate the mechanism to gain access to the computer 8341 without being blocked by security mechanisms. (See: back door, 8342 Trojan horse.) 8344 $ triple DES 8345 (I) An block cipher, based on DES, that transforms each 64-bit 8346 plaintext block by applying the Data Encryption Algorithm three 8347 successive times, using either two or three different keys, for an 8348 key length of 112 or 168 bits. [A9052] (See: DES.) 8350 (C) IPsec usage: The algorithm variation proposed for ESP uses a 8351 168-bit key, consisting of three independent 56-bit quantities 8352 used by the Data Encryption Algorithm, and a 64-bit initialization 8353 vector. Each datagram contains an IV to ensure that each received 8354 datagram can be decrypted, even if other datagrams are dropped or 8355 datagrams are reordered in transit. [R1851] 8357 $ triple-wrapped 8358 (I) S/MIME usage: Data that has been signed with a digital 8359 signature, and then encrypted, and then signed again. [R2634] 8361 $ Trojan horse 8362 (I) A computer program that appears to have a useful function, but 8363 also has a hidden and potentially malicious function that evades 8364 security mechanisms, sometimes by exploiting legitimate 8365 authorizations of a system entity that invokes the program. 8367 $ trust 8368 1. (I) Information system usage: The extent to which someone who 8369 relies on a system can have confidence that the system meets its 8370 specifications, i.e., that the system does what it claims to do 8371 and does not perform unwanted functions. (See: trust level.) 8373 (C) "trusted vs. trustworthy": In discussing a system or system 8374 process or object, this Glossary (and industry usage) prefers the 8375 term "trusted" to describe a system that operates as expected, 8376 according to design and policy. When the trust can also be 8377 guaranteed in some convincing way, such as through formal analysis 8378 or code review, the system is termed "trustworthy"; this differs 8379 from the ABA Guidelines definition (see: trustworthy system). 8381 2. (I) PKI usage: A relationship between a certificate user and a 8382 CA in which the user acts according to the assumption that the CA 8383 creates only valid digital certificates. 8385 (O) "Generally, an entity can be said to 'trust' a second entity 8386 when it (the first entity) makes the assumption that the second 8387 entity will behave exactly as the first entity expects. This trust 8388 may apply only for some specific function. The key role of trust 8389 in [X.509] is to describe the relationship between an entity and a 8390 [certification] authority; an entity shall be certain that it can 8391 trust the certification authority to create only valid and 8392 reliable certificates." [X509] 8394 $ trust chain 8395 (D) ISPDs SHOULD NOT use this term as a synonym for "certification 8396 path" because it mixes concepts (see: trust) in a potentially 8397 misleading way. 8399 $ trust-file PKI 8400 (I) A non-hierarchical PKI in which a each certificate user has a 8401 local file (used by application software) of public-key 8402 certificates that the user trusts as starting points (see: root) 8403 for certification paths. (See: hierarchical PKI, mesh PKI, web of 8404 trust.) 8406 (C) For example, popular browsers are distributed with an initial 8407 file of trusted certificates, which often are self-signed 8408 certificates. Users can add certificates to the file or delete 8409 from it. The file may be directly managed by the user, or the 8410 user's organization may manage it from a centralized server. 8412 $ trust hierarchy 8413 (D) ISPDs SHOULD NOT use this term as a synonym for "certification 8414 hierarchy" because this term mixes concepts (see: trust) in a 8415 potentially misleading way and duplicates the meaning of another, 8416 standardized term. (See: web of trust.) 8418 $ trust level 8419 (I) A characterization of a standard of security protection to be 8420 met by a computer system. 8422 (C) The TCSEC defines eight trust levels. From the lowest to the 8423 highest, they are D, C1, C2, B1, B2, B3, and A1. A trust level is 8424 based not only on the presence of security mechanisms but also on 8425 the use of systems engineering discipline to properly structure 8426 the system and on implementation analysis to ensure that the 8427 system provides the appropriate degree of trust. 8429 $ trusted 8430 See: (discussion under) trust. 8432 $ trusted certificate 8433 (I) A certificate that is trusted a priori by a certificate user, 8434 such as a public-key certificate that can be used to provide the 8435 first public key in a certification path. 8437 (C) A trusted public-key certificate might be the root certificate 8438 in a hierarchical PKI, or the certificate of the CA that issued 8439 the user's own certificate in a mesh PKI, or any certificate 8440 accepted by the user in a trust-file PKI. 8442 $ trusted computer system 8443 (I) "A system that employs sufficient hardware and software 8444 assurance measures to allow its use for simultaneous processing of 8445 a range of sensitive or classified information." [NCS04] (See: 8446 (discussion under) trust.) 8448 $ Trusted Computer System Evaluation Criteria (TCSEC) 8449 (N) A standard for evaluating the security provided by operating 8450 systems [CSC001, DOD1]. Informally called the "Orange Book" 8451 because of the color of its cover; first document in the Rainbow 8452 Series. (See: (usage note under) Green Book, Orange Book, trust 8453 level.) 8455 (C) To be superseded by the Common Criteria. 8457 $ trusted computing base (TCB) 8458 (I) "The totality of protection mechanisms within a computer 8459 system, including hardware, firmware, and software, the 8460 combination of which is responsible for enforcing a security 8461 policy." [NCS04] (See: (discussion of "trusted" under) trust.) 8463 $ trusted distribution 8464 (I) "A trusted method for distributing the TCB hardware, software, 8465 and firmware components, both originals and updates, that provides 8466 methods for protecting the TCB for modification during 8467 distribution and for detection of any changes to the TCB that may 8468 occur." [NCS04] 8470 $ trusted key 8471 (I) A public key that is trusted a priori by a user, such as a key 8472 that can be used as the first public key in a certification path. 8474 (C) A trusted public key can be (a) the root key in a hierarchical 8475 PKI, (b) the key of the CA that issued the user's own certificate 8476 in a mesh PKI, or (c) any key accepted by the user in a trust-file 8477 PKI. 8479 $ trusted path 8480 (I) COMPUSEC usage: A mechanism by which a computer system user 8481 can communicate directly and reliably with the trusted computing 8482 base (TCB) and that can only be activated by the user or the TCB 8483 and cannot be imitated by untrusted software within the computer. 8484 [NCS04] 8486 (I) COMSEC usage: A mechanism by which a person or process can 8487 communicate directly with a cryptographic module and that can only 8488 be activated by the person, process, or module, and cannot be 8489 imitated by untrusted software within the module. [FP140] 8491 $ trusted process 8492 (I) A system process that has privileges that enable it to affect 8493 the state of system security and that can, therefore, through 8494 incorrect or malicious execution, violate the system's security 8495 policy. (See: privileged process, (discussion of "trusted" under) 8496 trust.) 8498 $ trusted subnetwork 8499 (I) A subnetwork containing hosts and routers that trust each 8500 other not to engage in active or passive attacks. (There also is 8501 an assumption that the underlying communication channel--for 8502 example, a LAN--is not being attacked by other means.) 8504 $ trusted system 8505 See: (discussion under) trust, trusted computer system, 8506 trustworthy system. 8508 $ Trusted Systems Interoperability Group (TSIG) 8509 (N) A forum of computer vendors, system integrators, and users 8510 devoted to promoting interoperability of trusted computer systems. 8512 TSIG meetings are open to all persons who are working in the 8513 INFOSEC area. 8515 $ trustworthy system 8516 (O) ABA usage: "Computer hardware, software, and procedures that: 8517 (a) are reasonably secure from intrusion and misuse; (b) provide a 8518 reasonably reliable level of availability, reliability, and 8519 correct operation; (c) are reasonably suited to performing their 8520 intended functions; and (d) adhere to generally accepted security 8521 principles." [ABA] This differs somewhat from other industry usage 8522 (see: (discussion of "trusted vs. trustworthy" under) trust). 8524 $ TSIG 8525 See: Trusted System Interoperability Group. 8527 $ tunnel 8528 (I) A communication channel created in a computer network by 8529 encapsulating (carrying, layering; i.e., "tunneling") a 8530 communication protocol's data packets in (on top of) a second 8531 protocol that normally would be carried above, or at the same 8532 layer as, the first one. (See: L2TP, VPN.) 8534 (C) Tunneling can involve almost any OSI or TCP/IP protocol 8535 layers; for example, a TCP connection between two hosts could 8536 conceivably be tunneled through email messages across the 8537 Internet. Usually, a tunnel is a logical point-to-point link-- 8538 i.e., an OSI layer 2 connection--created by encapsulating the 8539 layer 2 protocol in a n protocol (such as TCP), or in a OSI layer 8540 3 internetwork protocol (such as IP), or in another layer 2 8541 protocol. Often, encapsulation is accomplished with an 8542 intermediate protocol (a tunneling protocol), such as L2TP, 8543 layered between the tunneled layer 2 protocol and the 8544 encapsulating protocol. 8546 (C) Tunneling can move data between computers that use a protocol 8547 not supported by the network connecting them. Tunneling also can 8548 enable a computer network to use the services of a second network 8549 as though the second network were a set of point-to-point links 8550 between the first network's nodes. (See: virtual private network.) 8552 (O) SET usage: The name of a SET private extension that indicates 8553 whether the CA or the payment gateway supports passing encrypted 8554 messages to the cardholder through the merchant. If so, the 8555 extension lists OIDs of symmetric encryption algorithms that are 8556 supported. 8558 $ tunnel mode 8559 (I) IPsec usage: See: transport mode vs. tunnel mode. 8561 $ two-person control 8562 (I) The close surveillance and control of a system, process, or 8563 materials (especially with regard to cryptography) at all times by 8564 a minimum of two appropriately authorized persons, each capable of 8565 detecting incorrect and unauthorized procedures with respect to 8566 the tasks to be performed and each familiar with established 8567 security requirements. (See: dual control, no-lone zone.) 8569 $ Type I cryptography 8570 (O) A cryptographic algorithm or device approved by the U.S. 8571 National Security Agency for protecting classified information. 8573 $ Type II cryptography 8574 (O) A cryptographic algorithm or device approved by the U.S. 8575 National Security Agency for protecting sensitive unclassified 8576 information in systems (as specified in section 2315 of Title 10 8577 United States Code, or section 3502(2) of Title 44, United States 8578 Code.) 8580 $ Type III cryptography 8581 (O) A cryptographic algorithm or device approved as a Federal 8582 Information Processing Standard. 8584 $ UDP 8585 See: User Datagram Protocol. 8587 $ unclassified 8588 (I) Not classified. 8590 $ unencrypted 8591 (I) Not encrypted. 8593 $ unforgeable 8594 (I) Cryptographic usage: The property of a cryptographic data 8595 structure (i.e., a data structure that is computed using one more 8596 cryptographic functions) that makes it computationally infeasible 8597 to construct (i.e., compute) an unauthorized but correct value of 8598 the structure without having knowledge of one of more keys. (E.g., 8599 see: digital certificate.) 8601 (C) This definition is narrower than general English usage, in 8602 which "unforgeable" means unable to be fraudulently created or 8603 duplicated. In that broader sense, anyone can forge a digital 8604 certificate containing any set of data items whatsoever by 8605 generating the to-be-signed certificate and signing it with any 8606 private key whatsoever. But for PKI purposes, the forged data 8607 structure is invalid if it is not signed with the true private key 8608 of the claimed issuer; thus, the forgery will be detected when a 8609 certificate user uses the true public key of the claimed issuer to 8610 verify the signature. 8612 $ uniform resource identifier (URI) 8613 (I) A type of formatted identifier that encapsulates the name of 8614 an Internet object, and labels it with an identification of the 8615 name space, thus producing a member of the universal set of names 8616 in registered name spaces and of addresses referring to registered 8617 protocols or name spaces. [R1630] 8619 (C) URIs are used in HTML to identify the target of hyperlinks. in 8620 common practice, URIs include uniform resource locators [R2368] 8621 and relative URLs. [R1808]. 8623 $ uniform resource locator (URL) 8624 (I) A type of formatted identifier that describes the access 8625 method and location of an information resource object on the 8626 Internet. [R1738] 8628 (C) A URL is a URI that provides explicit instructions on how to 8629 access the named object. For example, 8630 "ftp://bbnarchive.bbn.com/foo/bar/picture/cambridge.zip" is a URL. 8631 The part before the colon specifies the access scheme or protocol, 8632 and the part after the colon is interpreted according to that 8633 access method. Usually, two slashes after the colon indicate the 8634 host name of a server (written as a domain name). In an FTP or 8635 HTTP URL, the host name is followed by a path name of a file on 8636 the server. The last (optional) part of a URL may be either a 8637 fragment identifier that indicates a position in the file, or a 8638 query string. 8640 $ uniform resource name (URN) 8641 (I) A URI that has an institutional commitment to persistence and 8642 availability. 8644 $ untrusted process 8645 (I) A system process that is not able to affect the state of 8646 system security through incorrect or malicious operation, usually 8647 because its operation is confined by a security kernel. (See: 8648 trusted process.) 8650 $ UORA 8651 See: user-PIN ORA. 8653 $ update 8654 See: certificate update and key update. 8656 $ URI 8657 See: uniform resource identifier. 8659 $ URL 8660 See: uniform resource locator. 8662 $ URN 8663 See: uniform resource name. 8665 $ user 8666 (I) A person (or organization entity) or an automated process 8667 (usually acting on behalf of a person) that accesses a system, 8668 whether authorized to do so or not. 8670 (C) Because this term can be understood in many ways, any ISPD 8671 that uses it SHOULD provide an explicit definition. [R2504] 8673 $ User Datagram Protocol (UDP) 8674 (I) An Internet Standard [R0768] protocol that provides a datagram 8675 mode of packet-switched computer communication in an internetwork. 8677 (C) UDP assumes that IP is the underlying protocol. UDP enables 8678 application programs to send transaction-oriented data to other 8679 programs with minimal protocol mechanism. UDP does not provide 8680 reliable delivery, flow control, sequencing, or other end-to-end 8681 services that TCP provides. 8683 $ user identifier 8684 (I) A character string or symbol that is used in a system to 8685 uniquely name a specific user or group of users. 8687 (C) Often verified by a password in an authentication process. 8689 $ user PIN 8690 (O) MISSI usage: One of two personal identification numbers that 8691 control access to the functions and stored data of a FORTEZZA PC 8692 card. Knowledge of the user PIN enables the card user to perform 8693 the FORTEZZA functions that are intended for use by an end user. 8694 (See: SSO PIN.) 8696 $ user-PIN ORA (UORA) 8697 (O) A MISSI organizational RA that operates in a mode in which the 8698 ORA performs only the subset of card management functions that are 8699 possible with knowledge of the user PIN for a FORTEZZA PC card. 8700 (See: no-PIN ORA, SSO-PIN ORA.) 8702 $ usurpation 8703 See: (secondary definition in) threat consequence. 8705 $ UTCTime 8706 (N) The ASN.1 data type "UTCTime" contains a calendar date 8707 (YYMMDD) and a time to a precision of either one minute (HHMM) or 8708 one second (HHMMSS), where the time is either (a) Coordinated 8709 Universal Time or (b) the local time followed by an offset that 8710 enables Coordinated Universal Time to be calculated. Note: UTCTime 8711 has the Year 2000 problem. (See: Coordinated Universal Time, 8712 GeneralizedTime.) 8714 $ v1 certificate 8715 (C) Ambiguously refers to either an X.509 public-key certificate 8716 in its version 1 format, or an X.509 attribute certificate in its 8717 version 1 format. However, many people who use this term are not 8718 aware that X.509 specifies attribute certificates that do not 8719 contain a public key. ISPDs MAY use this term as an abbreviation 8720 for "version 1 X.509 public-key certificate", but only after using 8721 the full term at the first instance. 8723 (D) ISPDs SHOULD NOT use this term as an abbreviation to mean 8724 "version 1 X.509 attribute certificate". 8726 $ v1 CRL 8727 (I) A synonym for and "X.509 CRL" in version 1 format. 8729 $ v2 certificate 8730 (I) A synonym for an "X.509 public-key certificate" in version 2 8731 format. 8733 $ v2 CRL 8734 (I) A synonym for an "X.509 CRL" in version 2 format. 8736 $ v3 certificate 8737 (I) A synonym for an "X.509 public-key certificate" in version 3 8738 format. 8740 $ valid certificate 8741 (I) A digital certificate for which the binding of the data items 8742 can be trusted; one that can be validated successfully. (See: 8743 validate vs. verify.) 8745 $ valid signature 8746 (D) ISPDs SHOULD NOT use this term; instead, use "authentic 8747 signature". This Glossary recommends saying "validate the 8748 certificate" and "verify the signature" (see: validate vs. 8749 verify); therefore, it would be inconsistent to say that a 8750 signature is "valid". 8752 $ validate vs. verify 8753 (C) The PKI community uses words inconsistently when describing 8754 what a certificate user does to make certain that a digital 8755 certificate can be trusted. Usually, we say "verify the signature" 8756 but say "validate the certificate"; i.e., we "verify" atomic 8757 truths but "validate" data structures, relationships, and systems 8758 that are composed of or depend on verified items. Too often, 8759 however, verify and validate are used interchangeably. 8761 ISPDs SHOULD follow the following two rules to ensure consistency 8762 and align Internet security terminology with ordinary English: 8764 - Rule 1: Use "validate" when referring to a process intended to 8765 establish the soundness or correctness of a construct, like a 8766 public-key certificate or a certification path. 8768 - Rule 2: Use "verify" when referring to a process intended to 8769 test or prove the truth or accuracy of a fact or value. 8771 The rationale for Rule 1 is that "valid" derives from a word that 8772 means "strong" in Latin. Thus, to validate means to make sure that 8773 a construction is sound. A certificate user validates a public-key 8774 certificate to establish trust in the binding that the certificate 8775 asserts between an identity and a key. (To validate can also mean 8776 to officially approve something; thus NIST validates cryptographic 8777 modules for conformance with FIPS PUB 140-1.) 8779 The rationale for Rule 2 is that "verify" derives from a word that 8780 means "true" in Latin. Thus, to verify means to prove the truth of 8781 an assertion by examining evidence or performing tests. To verify 8782 an identity, an authentication process examines identification 8783 information that is presented or generated. To validate a 8784 certificate, a certificate user verifies the digital signature on 8785 the certificate by performing calculations; verifies that the 8786 current time is within the certificate's validity period; and may 8787 need to validate a certification path involving additional 8788 certificates. 8790 $ validation 8791 See: validate vs. verify. 8793 $ validity period 8794 (I) A data item in a digital certificate that specifies the time 8795 period for which the binding between data items (especially 8796 between the subject name and the public key value in a public-key 8797 certificate) is valid, except if the certificate appears on a CRL 8798 or the key appears on a CKL. 8800 $ value-added network (VAN) 8801 (I) A computer network or subnetwork (which is usually a 8802 commercial enterprise) that transmits, receives, and stores EDI 8803 transactions on behalf of its customers. 8805 (C) A VAN may also provide additional services, ranging from EDI 8806 format translation, to EDI-to-FAX conversion, to integrated 8807 business systems. 8809 $ VAN 8810 See: value-added network. 8812 $ verification 8813 1. System verification: The process of comparing two levels of 8814 system specification for proper correspondence, such as comparing 8815 a security policy with a top-level specification, a top-level 8816 specification with source code, or source code with object code. 8817 [NCS04] 8819 2. Identification verification: Presenting information to 8820 establish the truth of a claimed identity. 8822 $ verify 8823 See: validate vs. verify. 8825 $ violation 8826 See: security violation. 8828 $ virtual private network (VPN) 8829 (I) A restricted-use, logical (i.e., artificial or simulated) 8830 computer network that is constructed from the system resources of 8831 a relatively public, physical (i.e., real) network (such as the 8832 Internet), often by using encryption (located at hosts or 8833 gateways), and often by tunneling links of the virtual network 8834 across the real network. 8836 (C) For example, if a corporation has LANs at several different 8837 sites, each connected to the Internet by a firewall, the 8838 corporation could create a VPN by using encrypted tunnels to 8839 connect from firewall to firewall across the Internet and not 8840 allowing any other traffic through the firewalls. A VPN is 8841 generally less expensive to build and operate than a dedicated 8842 real network, because the virtual network shares the cost of 8843 system resources with other users of the real network. 8845 $ virus 8846 (I) A hidden, self-replicating section of computer software, 8847 usually malicious logic, that propagates by infecting--i.e., 8848 inserting a copy of itself into and becoming part of--another 8849 program. A virus cannot run by itself; it requires that its host 8850 program be run to make it active. 8852 $ VPN 8853 See: virtual private network. 8855 $ vulnerability 8856 (I) A flaw or weakness in a system's design, implementation, or 8857 operation and management that could be exploited to violate the 8858 system's security policy. 8860 (C) Most systems have vulnerabilities of some sort, but this does 8861 not mean that the systems are too flawed to use. Not every threat 8862 results in an attack, and not every attack succeeds. Success 8863 depends on the degree of vulnerability, the strength of attacks, 8864 and the effectiveness of any countermeasures in use. If the 8865 attacks needed to exploit a vulnerability are very difficult to 8866 carry out, then the vulnerability may be tolerable. If the 8867 perceived benefit to an attacker is small, then even an easily 8868 exploited vulnerability may be tolerable. However, if the attacks 8869 are well understood and easily made, and if the vulnerable system 8870 is employed by a wide range of users, then it is likely that there 8871 will be enough benefit for someone to make an attack. 8873 $ W3 8874 See: World Wide Web. 8876 $ war dialer 8877 (I) A computer program that automatically dials a series of 8878 telephone numbers to find lines connected to computer systems, and 8879 catalogs those numbers so that a cracker can try to break into the 8880 systems. 8882 $ Wassenaar Arrangement 8883 (N) The Wassenaar Arrangement on Export Controls for Conventional 8884 Arms and Dual-Use Goods and Technologies is a global, multilateral 8885 agreement approved by 33 countries in July 1996 to contribute to 8886 regional and international security and stability, by promoting 8887 information exchange concerning, and greater responsibility in 8888 transfers, thus preventing destabilizing accumulations. (See: 8889 International Traffic in Arms Regulations.) 8891 (C) The Arrangement began operations in September 1996. The 8892 participating countries are Argentina, Australia, Austria, 8893 Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, 8894 France, Germany, Greece, Hungary, Ireland, Italy, Japan, 8895 Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, 8896 Republic of Korea, Romania, Russian Federation, Slovak Republic, 8897 Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom, and 8898 United States. Participants meet on a regular basis in Vienna, 8899 where the Arrangement has its headquarters. 8901 Participating countries seek through their national policies to 8902 ensure that transfers do not contribute to the development or 8903 enhancement of military capabilities that undermine the goals of 8904 the arrangement, and are not diverted to support such 8905 capabilities. The countries maintain effective export controls for 8906 items on the agreed lists, which are reviewed periodically to 8907 account for technological developments and experience gained. 8908 Through transparency and exchange of views and information, 8909 suppliers of arms and dual-use items can develop common 8910 understandings of the risks associated with their transfer and 8911 assess the scope for coordinating national control policies to 8912 combat these risks. Members provide semi-annual notification of 8913 arms transfers, covering seven categories derived from the UN 8914 Register of Conventional Arms. Members also report transfers or 8915 denials of transfers of certain controlled dual-use items. 8916 However, the decision to transfer or deny transfer of any item is 8917 the sole responsibility of each participating country. All 8918 measures undertaken with respect to the arrangement will be in 8919 accordance with national legislation and policies and will be 8920 implemented on the basis of national discretion. 8922 $ watermarking 8923 See: digital watermarking. 8925 $ web vs. Web 8926 1. (I) Capitalized: ISPDs SHOULD capitalize "the Web" when using 8927 the term (usually as a noun) to refer specifically to the World 8928 Wide Web. (Similarly, see: internet vs. Internet.) 8930 2. (C) Not capitalized: ISPD SHOULD NOT capitalize "web" when 8931 using the term (usually as an adjective) to refer generically to 8932 technology--such as web browsers, web servers, HTTP, and HTML-- 8933 that is used in the Web or similar networks. 8935 (C) IETF documents SHOULD spell out "World Wide Web" fully at the 8936 first instance of usage and SHOULD Use "Web" and "web" especially 8937 carefully where confusion with the PGP web of trust is possible. 8939 $ web of trust 8940 (O) PGP usage: A trust-file PKI technique used in PGP for building 8941 a file of validated public keys by making personal judgments about 8942 being able to trust certain people to be holding properly 8943 certified keys of other people. (Compare with: certification 8944 hierarchy, mesh PKI.) 8946 $ web server 8947 (I) A software process that runs on a host computer connected to 8948 the Internet to respond to HTTP requests for documents from client 8949 web browsers. 8951 $ wiretapping 8952 (I) An attack that intercepts and accesses data flowing between 8953 two points in a communication system. 8955 (C) Although the term originally referred to making a mechanical 8956 connection to an electrical conductor, it is now used to refer to 8957 reading information from any sort of medium used for a link, or 8958 even from a gateway or a subnetwork switch.) 8960 (C) "Active wiretapping" (see: active attack) attempts to alter 8961 the data or otherwise affect the flow; "passive wiretapping" (see: 8962 passive attack) only attempts to observe and gain knowledge of the 8963 data. (See: end-to-end encryption.) 8965 $ work factor 8966 (I) General security usage: The estimated amount of effort or time 8967 that can be expected to be expended by a potential intruder to 8968 penetrate a system, or defeat a particular countermeasure, when 8969 using specified amounts of expertise and resources. 8971 (I) Cryptography usage: The estimated amount of computing time and 8972 power needed to break a cryptographic system. 8974 $ World Wide Web ("the Web", WWW, W3) 8975 (N) The global, hypermedia-based collection of information and 8976 services that is available on Internet servers and is accessed by 8977 browsers using Hypertext Transfer Protocol and other information 8978 retrieval mechanisms. (See: web vs. Web, [R2084].) 8980 $ worm 8981 (I) A computer program that can run independently, can propagate a 8982 complete working version of itself onto other hosts on a network, 8983 and may consume computer resources destructively. (See: Morris 8984 Worm, virus.) 8986 $ wrap 8987 (I) To use cryptography to provide data confidentiality service 8988 for a data set. (See: encrypt, seal.) 8990 (D) ISPDs SHOULD NOT use this term with this definition because it 8991 duplicates the meaning of other, standard terms. Instead, use 8992 "encrypt" or use a term that is specific with regard to the 8993 mechanism used. 8995 $ WWW 8996 See: World Wide Web. 8998 $ X.400 8999 (N) An ITU-T Recommendation [X400] that is one part of a joint 9000 ITU-T/ISO multi-part standard (X.400-X.421) that defines the 9001 Message Handling Systems. (The ISO equivalent is IS 10021, parts 9002 1-7.) (See: Message Handling Systems.) 9004 $ X.500 9005 $ X.500 Directory 9006 (N) An ITU-T Recommendation [X500] that is one part of a joint 9007 ITU-T/ISO multi-part standard that defines the X.500 Directory, a 9008 conceptual collection of systems that provide distributed 9009 directory capabilities for OSI entities, processes, applications, 9010 and services. (The ISO equivalent is IS 9594-1 and related 9011 standards, IS 9594-x.) (See: directory vs. Directory, X.509.) 9013 (C) The X.500 Directory is structured as a tree (the Directory 9014 Information Tree), and information is stored in directory entries. 9015 Each entry is a collection of information about one object, and 9016 each object has a unique DN. An entry is composed of attributes, 9017 each with a type and one or more values. For example, if a PKI 9018 uses the Directory to distribute certificates, then an X.509 9019 public-key certificate of an end user is normally stored as a 9020 value of an attribute of type "userCertificate" in the Directory 9021 entry that has the DN that is the subject of the certificate. 9023 $ X.509 9024 (N) An ITU-T Recommendation [X509] that is one part of a joint 9025 ITU-T/ISO multi-part standard (see: X.500). X.509 defines a 9026 framework to provide and support data origin authentication and 9027 peer entity authentication, including formats for X.509 public-key 9028 certificates, X.509 attribute certificates, and X.509 CRLs. (The 9029 ISO equivalent is IS 9498-4.) (See: X.500.) 9031 (C) X.509 describes two levels of authentication: simple 9032 authentication based on a password, and strong authentication 9033 based on a public-key certificate. (See: X.509 public-key 9034 certificate.) 9036 $ X.509 attribute certificate 9037 (N) An attribute certificate in the version 1 (v1) format defined 9038 by X.509. (The v1 designation for an X.509 attribute certificate 9039 is disjoint from the v1 designation for an X.509 public-key 9040 certificate, and from the v1 designation for an X.509 CRL.) 9042 (C) An X.509 attribute certificate has a subject field, but the 9043 attribute certificate is a separate data structure from that 9044 subject's public-key certificate. A subject may have multiple 9045 attribute certificates associated with each of its public-key 9046 certificates, and an attribute certificate may be issued by a 9047 different CA than the one that issued the associated public-key 9048 certificate. 9050 (C) An X.509 attribute certificate contains a sequence of data 9051 items and has a digital signature is computed on that sequence. In 9052 addition to the signature, an attribute certificate contains items 9053 1 through 9 listed below: 9055 1. version Identifies v1. 9056 2. subject Is one of the following: 9057 2a. baseCertificateID - Issuer and serial number of an 9058 X.509 public-key certificate. 9059 2b. subjectName - DN of the subject. 9060 3. issuer DN of the issuer (the CA who signed). 9061 4. signature OID of algorithm that signed the cert. 9062 5. serialNumber Certificate serial number; 9063 an integer assigned by the issuer. 9064 6. attCertValidityPeriod Validity period; a pair of UTCTime 9065 values: "not before" and "not after". 9066 7. attributes Sequence of attributes describing the 9067 subject. 9068 8. issuerUniqueId Optional, when a DN is not sufficient. 9069 9. extensions Optional. 9071 $ X.509 authority revocation list 9072 (N) An ARL in one of the formats defined by X.509--version 1 (v1) 9073 or version 2 (v2). A specialized kind of certificate revocation 9074 list. 9076 $ X.509 certificate 9077 (N) Either an X.509 public-key certificate or an X.509 attribute 9078 certificate. 9080 (C) This Glossary uses the term with the precise meaning 9081 recommended here. However, some who use the term may not be aware 9082 that X.509 specifies attribute certificates that do not contain a 9083 public key. Even among those who are aware, this term is commonly 9084 used as an abbreviation to mean "X.509 public-key certificate". 9085 ISPDs MAY use the term as an abbreviation for "X.509 public-key 9086 certificate", but only after using the full term at the first 9087 instance. 9089 (D) ISPDs SHOULD NOT use this term as an abbreviation to mean 9090 "X.509 attribute certificate". 9092 $ X.509 certificate revocation list (CRL) 9093 (N) A CRL in one of the formats defined by X.509--version 1 (v1) 9094 or version 2 (v2). (The v1 and v2 designations for an X.509 CRL 9095 are disjoint from the v1 and v2 designations for an X.509 public- 9096 key certificate, and from the v1 designation for an X.509 9097 attribute certificate.) 9099 (C) ISPDs SHOULD NOT refer to an X.509 CRL as a digital 9100 certificate, but note that an X.509 CRL does meet this Glossary's 9101 definition of "digital certificate". Like a digital certificate, 9102 an X.509 CRL makes an assertion and is signed by a CA. But instead 9103 of binding a key or other attributes to a subject, an X.509 CRL 9104 asserts that certain previously-issued X.509 certificates have 9105 been revoked (see: certificate revocation). 9107 (R) An X.509 CRL contains a sequence of data items and has a 9108 digital signature computed on that sequence. In addition to the 9109 signature, both v1 and v2 contain items 2 through 6b listed below. 9110 Version 2 may optionally contain items 1, 6b, and 7. 9112 1. version Optional. If present, identifies v2. 9113 2. signature OID of the algorithm that signed CRL. 9114 3. issuer DN of the issuer (the CA who signed). 9115 4. thisUpdate A UTCTime value. 9116 5. nextUpdate A UTCTime value..br 9117 6. revokedCertificates 3-tuples of 6a, 6b, and (optional) 6c: 9118 6a. userCertificate A certificate's serial number. 9119 6b. revocationDate UTCTime value for the revocation date. 9120 6c. crlEntryExtensions Optional. 9121 7. crlExtensions Optional. 9123 $ X.509 public-key certificate 9124 (N) A public-key certificate in one of the formats defined by 9125 X.509--version 1 (v1), version 2 (v2), or version 3 (v3). (The v1 9126 and v2 designations for an X.509 public-key certificate are 9127 disjoint from the v1 and v2 designations for an X.509 CRL, and 9128 from the v1 designation for an X.509 attribute certificate.) 9130 (C) An X.509 public-key certificate contains a sequence of data 9131 items and has a digital signature computed on that sequence. In 9132 addition to the signature, all three versions contain items 1 9133 through 7 listed below. Only v2 and v3 certificates may also 9134 contain items 8 and 9, and only v3 may contain item 10. 9136 1. version Identifies v1, v2, or v3. 9137 2. serialNumber Certificate serial number; 9138 an integer assigned by the issuer. 9139 3. signature OID of algorithm that was used to 9140 sign the certificate. 9141 4. issuer DN of the issuer (the CA who signed). 9142 5. validity Validity period; a pair of UTCTime 9143 values: "not before" and "not after". 9144 6. subject DN of entity who owns the public key. 9145 7. subjectPublicKeyInfo Public key value and algorithm OID. 9146 8. issuerUniqueIdentifier Defined for v2, v3; optional. 9147 9. subjectUniqueIdentifier Defined for v2, v2; optional. 9148 10. extensions Defined only for v3; optional. 9150 $ XTACACS 9151 See: (secondary definition in) Terminal Access Controller (TAC) 9152 Access Control System. 9154 $ Yellow Book 9155 (D) ISPDs SHOULD NOT use this term as a synonym for "Computer 9156 Security Requirements: Guidance for Applying the Department of 9157 Defense Trusted Computer System Evaluation Criteria in Specific 9158 Environments" [CSC3]. Instead, use the full proper name of the 9159 document or, in subsequent references, a conventional 9160 abbreviation. (See: (usage note under) Green Book, Rainbow 9161 Series.) 9163 $ zeroize 9164 (I) Use erasure or other means to render stored data--particularly 9165 a key stored in a cryptographic module or other device--unusable 9166 and unrecoverable. 9168 (O) Erase electronically stored data by altering the contents of 9169 the data storage so as to prevent the recovery of the data. 9170 [FP140] 9172 4. References 9174 [ABA] American Bar Association, "Digital Signature Guidelines: 9175 Legal Infrastructure for Certification Authorities and 9176 Secure Electronic Commerce", Chicago, IL, 1 Aug 1996. 9178 [ACM] Association for Computing Machinery, "Communications of the 9179 ACM", Jul 1998 issue with: Minerva M. Yeung, "Digital 9180 Watermarking"; Nasir Memom and Ping Wah Wong, "Protecting 9181 Digital Media Content"; and Scott Craver, Boon-Lock Yeo, and 9182 Minerva Yeung, "Technical Trials and Legal Tribulations". 9184 [A3092] American National Standards Institute, "American National 9185 Standard Data Encryption Algorithm", ANSI X3.92-1981, 30 Dec 9186 1980. 9188 [A9009] ---, "Financial Institution Message Authentication 9189 (Wholesale)", ANSI X9.9-1986, 15 Aug 1986. 9191 [A9017] ---, "Financial Institution Key Management (Wholesale)", 9192 X9.17, 4 Apr 1985. [Defines procedures for the manual and 9193 automated management of keying material and uses DES to 9194 provide key management for a variety of operational 9195 environments.] 9197 [A9042] ---, "Public key Cryptography for the Financial Service 9198 Industry: Agreement of Symmetric Keys Using Diffie-Hellman 9199 and MQV Algorithms", X9.42, 29 Jan 1999. 9201 [A9052] ---, "Triple Data Encryption Algorithm Modes of Operation", 9202 X9.52-1998, ANSI approval 9 Nov 1998. 9204 [A9062] ---, "Public Key Cryptography for the Financial Services 9205 Industry: The Elliptic Curve Digital Signature Algorithm 9206 (ECDSA)", X9.62-1998, ANSI approval 7 Jan 1999. 9208 [B7799] British Standards Institution, "Information Security 9209 Management, Part 1: Code of Practice for Information 9210 Security Management", BS 7799-1:1999. 9211 ---, ---, "Part 2: Specification for Information Security 9212 Management Systems", BS 7799-2:1999. 9214 [CCIB] Common Criteria Implementation Board, "Common Criteria for 9215 Information Technology Security Evaluation, Part 1: 9216 Introduction and General Model", ver. 2.0, CCIB-98-026, May 9217 1998. 9219 [CIPSO] Trusted Systems Interoperability Working Group, "Common IP 9220 Security Option", ver. 2.3, 9 Mar 1993. 9222 [CSC1] [U.S.]Department of Defense Computer Security Center, 9223 "Department of Defense Trusted Computer System Evaluation 9224 Criteria", CSC-STD-001-83, 15 Aug 1983. (Superseded by 9225 [DOD1].) 9227 [CSC2] ---, "Department of Defense Password Management Guideline", 9228 CSC-STD-002-85, 12 Apr 1985. 9230 [CSC3] ---, "Computer Security Requirements: Guidance for Applying 9231 the Department of Defense Trusted Computer System Evaluation 9232 Criteria in Specific Environments", CSC-STD-003-85, 25 Jun 9233 1985. 9235 [CSOR] U.S. Department of Commerce, "General Procedures for 9236 Registering Computer Security Objects", National Institute 9237 of Standards Interagency Report 5308, Dec 1993. 9239 [Denn] D. E. Denning, "A Lattice Model of Secure Information Flow", 9240 in "Communications of the ACM", vol. 19, no. 5, May 1976, 9241 pp. 236-243. 9243 [DH76] W. Diffie and M. H. Hellman, "New Directions in Cryptography" 9244 in "IEEE Transactions on Information Theory", vol. IT-22, 9245 no. 6, Nov 1976, pp. 644-654. 9247 [DOD1] U.S. Department of Defense, "Department of Defense Trusted 9248 Computer System Evaluation Criteria", DoD 5200.28-STD, 26 9249 Dec 1985. (Supersedes [CSC1].) 9251 [DOD2] ---, Directive 5200.28, "Security Requirements for Automated 9252 Information Systems (AISs)", 21 Mar 1988. 9254 [DOD3] ---, "X.509 Certificate Policy", ver. 2, Mar 1999. 9256 [DOD98] ---, "NSA Key Recovery Assessment Criteria", 8 Jun 1998. 9258 [EMV1] Europay International S.A., MasterCard International 9259 Incorporated, and Visa International Service Association, 9260 "EMV '96 Integrated Circuit Card Specification for Payment 9261 Systems", ver. 3.1.1, 31 May 1998. 9263 [EMV2] ---, "EMV '96 Integrated Circuit Card Terminal Specification 9264 for Payment Systems", ver. 3.1.1, 31 May 1998. 9266 [EMV3] ---, EMV '96 Integrated Circuit Card Application 9267 Specification for Payment Systems", ver. 3.1.1, 31 May 1998. 9269 [For94] W. Ford, "Computer Communications Security: Principles, 9270 Standard Protocols and Techniques", ISBN 0-13-799453-2, 9271 1994. 9273 [For97] W. Ford and M. Baum, "Secure Electronic Commerce: Building 9274 the Infrastructure for Digital Signatures and Encryption", 9275 ISBN 0-13-476342-4, 1994. 9277 [FP031] U.S. Department of Commerce, "Guidelines for Automatic Data 9278 Processing Physical Security and Risk Management", Federal 9279 Information Processing Standards Publication (FIPS PUB) 31, 9280 Jun 1974. 9282 [FP039] ---, "Glossary for Computer Systems Security", Federal 9283 Information Processing Standards Publication (FIPS PUB) 39, 9284 15 Feb 1976. 9286 [FP046] ---, "Data Encryption Standard (DES)", FIPS PUB 46-2, 30 Dec 9287 1993. 9289 [FP081] ---, "DES Modes of Operation", FIPS PUB 81, 2 Dec 1980. 9291 [FP102] ---, "Guideline for Computer Security Certification and 9292 Accreditation", FIPS PUB 102, 27 Sep 1983. 9294 [FP113] ---, "Computer Data Authentication", FIPS PUB 113, 30 May 9295 1985. 9297 [FP140] ---, "Security Requirements for Cryptographic Modules", FIPS 9298 PUB 140-1, 11 Jan 1994. 9300 [FP151] ---, "Portable Operating System Interface (POSIX)--System 9301 Application Program Interface [C Language]", FIPS PUB 151-2, 9302 12 May 1993 9304 [FP180] ---, "Secure Hash Standard", FIPS PUB 180-1, 17 Apr 1995. 9306 [FP185] ---, "Escrowed Encryption Standard", FIPS PUB 185, 9 Feb 9307 1994. 9309 [FP186] ---, "Digital Signature Standard (DSS)", FIPS PUB 186, 19 May 9310 1994. 9312 [FP188] ---, "Standard Security Label for Information Transfer", FIPS 9313 PUB 188, 6 Sep 1994. 9315 [FPDAM] Collaborative ITU and ISO/IEC meeting on the Directory, 9316 "Final Proposed Draft Amendment on Certificate Extensions", 9317 April 1999. (This draft proposes changes to [X.509].) 9318 [FPKI] U.S. Department of Commerce, "Public Key Infrastructure (PKI) 9319 Technical Specifications: Part A--Technical Concept of 9320 Operations", National Institute of Standards, 4 Sep 1998. 9322 [I3166] International Standards Organization, "Codes for the 9323 Representation of Names of countries and Their Subdivisions 9324 --Part 1: Country Codes", ISO 3166-1:1997. 9326 ---, --- "Part 2: Country Subdivision Codes", ISO/DIS 3166-2. 9328 ---, --- "Part 3: Codes for formerly Used Names of 9329 Countries", ISO/DIS 3166-3. 9331 [I7498] ---, "Information Processing Systems--Open Systems 9332 Interconnection Reference Model--[Part 1:] Basic Reference 9333 Model", ISO/IEC 7498-1. (Equivalent to ITU-T Recommendation 9334 X.200.) 9336 ---, --- "Part 2: Security Architecture", ISO/IEC 7499-2. 9338 ---, --- "Part 4: Management Framework", ISO/IEC 7498-4. 9340 [I7812] ---, "Identification cards--Identification of issuers--Part 9341 1: Numbering system, ISO/IEC 7812-1:1993, and Identification 9342 cards--Identification of issuers--Part 2: Application and 9343 registration procedures", ISO/IEC 7812-2:1993. 9345 [I9945] "Portable Operating System Interface for Computer 9346 Environments", ISO/IEC 9945-1: 1990. 9348 [ITSEC] "Information Technology Security Evaluation Criteria (ITSEC): 9349 Harmonised Criteria of France, Germany, the Netherlands, and 9350 the United Kingdom", ver. 1.2, U.K. Department of Trade and 9351 Industry, Jun 1991. 9353 [Kahn] David Kahn, "The Codebreakers: The Story of Secret Writing", 9354 The Macmillan Company, New York, 1967. 9356 [Kuhn] Markus G. Kuhn and Ross J. Anderson, "Soft Tempest: Hidden 9357 Data Transmission Using Electromagnetic Emanations", in 9358 David Aucsmith, ed., "Information Hiding, Second 9359 International Workshop, IH'98", Portland, Oregon, USA, 15-17 9360 Apr 1998, LNCS 1525, Springer-Verlag, ISBN 3-540-65386-4, 9361 pp. 124-142. 9363 [MISPC] U.S. Department of Commerce, "Minimum Interoperability 9364 Specification for PKI Components (MISPC), Version 1", 9365 National Institute of Standards Special Publication 800-15, 9366 Sep 1997. 9368 [NCS01] National Computer Security Center, "A Guide to Understanding 9369 Audit in Trusted Systems", NCSC-TG-001, 1 Jun 1988. (Part of 9370 the Rainbow Series.) 9372 [NCS04] ---, "Glossary of Computer Security Terms", NCSC-TG-004, ver. 9373 1, 21 Oct 1988. (Part of the Rainbow Series.) 9375 [NCS05] ---, "Trusted Network Interpretation of the Trusted Computer 9376 System Evaluation Criteria", NCSC-TG-005, ver. 1, 31 Jul 9377 1987. (Part of the Rainbow Series.) 9379 [NCS25] ---, "A Guide to Understanding Data Remanence in Automated 9380 Information Systems", NCSC-TG-025, ver. 2, Sep 1991. (Part 9381 of the Rainbow Series.) 9383 [PGP] Simson Garfinkel, "PGP: Pretty Good Privacy", O'Reilly & 9384 Associates, Inc., Sebastopol, California, 1995. 9386 [PKCS] Burton S. Kaliski, Jr., "An Overview of the PKCS Standards", 9387 RSA Data Security, Inc., 3 Jun 1991. 9389 [PKC07] RSA Laboratories, "PKCS #7: Cryptographic Message Syntax 9390 Standard", ver. 1.5, RSA Laboratories Technical Note, 1 Nov 9391 1993. 9393 [PKC10] ---, "PKCS #10: Certification Request Syntax Standard", ver. 9394 1.0, RSA Laboratories Technical Note, 1 Nov 1993 9396 [PKC11] ---, "PKCS #11: Cryptographic Token Interface Standard", ver. 9397 1.0, 28 Apr 1995. 9399 [R0768] J. Postel, "User Datagram Protocol", STD 6, RFC 768, 28 Aug 9400 1980. 9402 [R0791] ---, "Internet Protocol", STD 5, RFC 791, 1 Sep 1981. 9404 [R0792] ---, "Internet Control Message Protocol", STD 5, RFC 792, Sep 9405 1981. [See: RFC 1885.] 9407 [R0793] ---, ed., "Transmission Control Protocol", STD 7, RFC 793, 9408 Sep 1981. 9410 [R0821] ---, "Simple Mail Transfer Protocol", STD 10, RFC 821, Aug 9411 1982. 9413 [R0822] D. H. Crocker, "Standard for the Format of ARPA Internet Text 9414 Messages", STD 11, RFC 822, 13 Aug 1982. 9416 [R0854] J. Postel and J. Reynolds, "TELNET Protocol Specification", 9417 STD 8, RFC 854, May 1983. 9419 [R0959] ---, "File Transfer Protocol (FTP)", STD 9, RFC 959, Oct 9420 1985. 9422 [R1034] P. Mockapetris, "Domain Names--Concepts and Facilities", STD 9423 13, RFC 1034, Nov 1987. 9425 [R1157] J. Case, M. Fedor, M. Schoffstall, and J. Davin, "A Simple 9426 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 9427 1990. 9429 [R1208] O. Jacobsen and D. Lynch, "A Glossary of Networking Terms", 9430 RFC 1208, Mar 1991. 9432 [R1319] B. Kaliski, "The MD2 Message-Digest Algorithm", RFC 1319, Apr 9433 1992. 9435 [R1320] R. Rivest, "The MD4 Message-Digest Algorithm", RFC 1320, Apr 9436 1992. 9438 [R1321] ---, "The MD5 Message-Digest Algorithm", RFC 1321, Apr 1992. 9440 [R1334] B. Lloyd, W. Simpson, "PPP Authentication Protocols", RFC 9441 1334, Oct 1992. 9443 [R1413] M. St. Johns, "Identification Protocol", RFC 1413, Feb 1993. 9445 [R1421] J. Linn, "Privacy Enhancement for Internet Electronic Mail, 9446 Part I: Message Encryption and Authentication Procedures", 9447 RFC 1421, Feb 1993. 9449 [R1422] S. Kent, "Privacy Enhancement for Internet Electronic Mail, 9450 Part II: Certificate-Based Key Management", RFC 1422, Feb 9451 1993. 9453 [R1455] D. Eastlake, III, "Physical Link Security Type of Service", 9454 RFC 1455, May 1993. 9456 [R1457] R. Housley, "Security Label Framework for the Internet", RFC 9457 1457, May 1993. 9459 [R1492] C. Finseth, "An Access Control Protocol, Sometimes Called 9460 TACACS", RFC 1492, Jul 1993. 9462 [R1507] C. Kaufman, "DASS: Distributed Authentication Security 9463 Service", RFC 1507, Sep 1993. 9465 [R1510] J. Kohl and C. Neuman, "The Kerberos Network Authentication 9466 Service (V5)", RFC 1510, Sep 1993 9468 [R1591] ---, "Domain Name System Structure and Delegation", Mar 1994. 9470 [R1630] T. Berners-Lee, "Universal Resource Identifiers in WWW", RFC 9471 1630, Jun 1994. 9473 [R1731] J. Myers, "IMAP4 Authentication Mechanisms", RFC 1731, Dec 9474 1994. 9476 [R1734] ---, "POP3 AUTHentication Command", RFC 1734, Dec, 1994. 9478 [R1738] ---, L. Masinter, and M. McCahill, ed's., "Uniform Resource 9479 Locators (URL)", RFC 1738, Dec 1994. 9481 [R1750] D. Eastlake, 3rd, S. Crocker, and J. Schiller, "Randomness 9482 Recommendations for Security", Dec 1994. 9484 [R1777] W. Yeong, T. Howes, and S. Kille, "Lightweight Directory 9485 Access Protocol", Mar 1995 9487 [R1808] R. Fielding, "Relative Uniform Resource Locators", RFC 1808, 9488 Jun 1995 9490 [R1824] H. Danisch, "The Exponential Security System TESS: An 9491 Identity-Based Cryptographic Protocol for Authenticated Key- 9492 Exchange (E.I.S.S.-Report 1995/4)", RFC 1824, Aug 1995. 9494 [R1828] P. Metzger and W. Simpson, "IP Authentication using Keyed 9495 MD5", RFC 1828, Aug 1995. 9497 [R1829] P. Karn, P. Metzger, and W. Simpson, "The ESP DES-CBC 9498 Transform", RFC 1829, Aug 1995. 9500 [R1848] S. Crocker, N. Freed, J. Galvin, and S. Murphy, "MIME Object 9501 Security Services", RFC 1848, Oct 1995. 9503 [R1851] P. Karn, P. Metzger, and W. Simpson, "The ESP Triple DES 9504 Transform", RFC 1851, Sep 1995. 9506 [R1866] T. Berners-Lee, "Hypertext Markup Language--2.0", RFC 1866, 9507 Nov 1995. 9509 [R1885] A. Conta and S. Deering, "Internet Control Message Protocol 9510 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 9511 Specification", RFC 1885, Dec 1995. 9513 [R1928] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. 9514 Jones, "SOCKS Protocol Version 5", RFC 1928, Mar 1996. 9516 [R1938] N. Haller and C. Metzion, "A One-Time Password System", RFC 9517 1938, May 1996. 9519 [R1939] J. Myers and M. Rose, "Post Office Protocol - Version 3", RFC 9520 1939, May 1996. 9522 [R1958] B. Carpenter, ed., "Architectural Principles of the 9523 Internet", RFC 1958, Jun 1996. 9525 [R1983] G. Malkin, ed., "Internet Users' Glossary", RFC 1983, FYI 18, 9526 Aug 1996. 9528 [R1994] W. Simpson, "PPP Challenge Handshake Authentication Protocol 9529 (CHAP)", RFC 1994, Aug 1996. 9531 [R2023] J. Postel and J. Reynolds, "Instructions to RFC Authors", RFC 9532 2023, Oct 1997. 9534 [R2026] S. Bradner, "The Internet Standards Process--Revision 3", 9535 BCP009, RFC 2026, Mar 1994. 9537 [R2045] N. Freed and N. Borenstein, "Multipurpose Internet Mail 9538 Extensions (MIME) Part One: Format of Internet Message 9539 Bodies", RFC 2045, Nov 1996. 9541 [R2060] M. Crispin, "Internet Message Access Protocol--Version 4 9542 Revision 1", RFC 2060, Dec 1996. 9544 [R2065] D. Eastlake, 3rd, "Domain Name System Security Extensions", 9545 RFC 2065, Jan 1997. 9547 [R2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 9548 "Hypertext Transfer Protocol--HTTP/1.1", RFC 2068, Jan 1997. 9550 [R2078] J. Linn, "Generic Security Service Application Program 9551 Interface, Version 2", RFC 2078, Jan 1997. 9553 [R2084] G. Bossert, S. Cooper, and W. Drummond, "Considerations for 9554 Web Transaction Security", RFC 2084, Jan 1997. 9556 [R2104] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-Hashing 9557 for Message Authentication", RFC 2104, Feb 1997. 9559 [R2137] D. Eastlake, 3rd, "Secure Domain Name System Dynamic Update", 9560 RFC 2137, Apr 1997. 9562 [R2179] A. Gwinn, "Network Security For Trade Shows", RFC 2179, Jul 9563 1997. 9565 [R2195] J. Klensin, R. Catoe, and P. Krumviede, "IMAP/POP AUTHorize 9566 Extension for Simple Challenge/Response", RFC 2195, Sep 9567 1997. 9569 [R2196] B. Fraser, "Site Security Handbook", RFC 2196, Sep 1997. 9571 [R2202] P. Cheng and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 9572 SHA-1", RFC 2202, Sep. 1997. 9574 [R2222] J. Myers, "Simple Authentication and Security Layer (SASL)", 9575 RFC 2222, Oct 1997. 9577 [R2284] L. Blunk and J. Vollbrecht, "PPP Extensible Authentication 9578 Protocol (EAP)", RFC 2284, Mar 1998. 9580 [R2315] B. Kaliski, "PKCS #7: Cryptographic Message Syntax, Version 9581 1.5", RFC 2315, Mar 1998. 9583 [R2323] A. Ramos, "IETF Identification and Security Guidelines", RFC 9584 2323, 1 Apr 1998. [Intended for humorous entertainment 9585 ("please laugh loud and hard"); does not contain serious 9586 security information.] 9588 [R2350] N. Brownlee and E. Guttman, "Expectations for Computer 9589 Security Incident Response", RFC 2350, Jun 1998. 9591 [R2373] R. Hinden and S. Deering, "IP Version 6 Addressing 9592 Architecture", RFC 2373. 9594 [R2401] S. Kent and R. Atkinson, "Security Architecture for the 9595 Internet Protocol", RFC 2401, Nov 1998. 9597 [R2402] S. Kent and R. Atkinson, "IP Authentication Header", RFC 9598 2402, Nov 1998. 9600 [R2403] C. Madson and R. Glenn, "The Use of HMAC-MD5-96 within ESP 9601 and AH", RFC 2403, Nov 1998. 9603 [R2404] C. Madson and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 9604 and AH", RFC 2404, Nov 1998. 9606 [R2405] C. Madson and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm 9607 With Explicit IV", RFC 2405, Nov 1998. 9609 [R2406] S. Kent and R. Atkinson, "IP Encapsulating Security Payload 9610 (ESP)", RFC 2406, Nov 1998. 9612 [R2407] D. Piper, "The Internet IP Security Domain of Interpretation 9613 for ISAKMP", RFC 2407, Nov 1998. 9615 [R2408] D. Maughan, M. Schertler, M. Schneider, and J. Turner, 9616 "Internet Security Association and Key Management Protocol 9617 (ISAKMP)", RFC 2408, Nov 1998. 9619 [R2409] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", 9620 RFC 2409, Nov 1998. 9622 [R2410] R. Glenn and S. Kent, "The NULL Encryption Algorithm and Its 9623 Use With IPsec", RFC 2410, Nov 1998. 9625 [R2412] H. Orman, "The OAKLEY Key Determination Protocol", RFC 2412, 9626 Nov 1998. 9628 [R2451] R. Pereira and R. Adams, "The ESP CBC-Mode Cipher 9629 Algorithms", RFC 2451, Nov 1998. 9631 [R2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 9632 Specification", RFC 2460, Dec 1998. 9634 [R2504] E. Guttman, L. Leong, and G. Malkin, "Users' Security 9635 Handbook", RFC 2504, Feb 1999. 9637 [R2510] C. Adams and S. Farrell, "Internet X.509 Public Key 9638 Infrastructure Certificate Management Protocols", RFC 2510, 9639 Mar 1999. 9641 [R2527] S. Chokhani and W. Ford, "Internet X.509 Public Key 9642 Infrastructure, Certificate Policy and Certification 9643 Practices Framework", RFC 2527, Mar 1999. 9645 [R2570] J. Case, R. Mundy, D. Partain, B. Stewart, "Introduction to 9646 Version 3 of the Internet-Standard Network Management 9647 Framework", RFC 2570, Apr 1999. 9649 [R2574] U. Blumenthal and B. Wijnen, "User-based Security Model (USM) 9650 for Version 3 of the Simple Network Management Protocol 9651 (SNMPv3)", RFC 2574, Apr 1999. 9653 [R2612] C. Adams and J. Gilchrist, "The CAST-256 Encryption 9654 Algorithm", RFC 2612, Jun 1999. 9656 [R2628] V. Smyslov, "Simple Cryptographic Program Interface", RFC 9657 2628, Jun 1999. 9659 [R2630] R. Housley, "Cryptographic Message Syntax", RFC 2630, Jun 9660 1999. 9662 [R2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631, 9663 Jun 1999 9665 [R2633] B. Ramsdell, ed., "S/MIME Version 3 Message Specification", 9666 RFC 2633, Jun 1999 9668 [R2634] P. Hoffman, ed., "Enhanced Security Services for S/MIME", RFC 9669 2634, Jun 1999 9671 [R2635] S. Hambridge and A. Lunde, "Don't Spew: A Set of Guidelines 9672 for Mass Unsolicited Mailings and Postings", RFC 2635, Jun 9673 1999. 9675 [Raym] E. S. Raymond, ed., "The On-Line Hacker Jargon File", ver. 9676 4.0.0, 24 JUL 1996. (See: http://www.tuxedo.org/jargon/ for 9677 the latest version. Also, ver. 3.0.0 is available as "The 9678 New Hacker's Dictionary", 2nd edition, MIT Press, Sep 1993, 9679 ISBN 0-262-18154-1.) 9681 [Schn] B. Schneier, "Applied Cryptography", John Wiley & Sons, Inc., 9682 New York, 1994. 9684 [SDNS3] National Security Agency, "Secure Data Network Systems, 9685 Security Protocol 3 (SP3)", document SDN.301, Revision 1.5, 9686 15 May 1989. 9688 [SDNS4] ---, ---, "Security Protocol 4 (SP4)", document SDN.401, 9689 Revision 1.2, 12 Jul 1988. 9691 [SDNS7] ---, ---, "Secure data Network System, Message Security 9692 Protocol (MSP)", document SDN.701, Revision 4.0, 7 Jun 1996, 9693 with Corrections to Message Security Protocol, SDN.701, Rev 9694 4.0", 96-06-07, 30 Aug, 1996. 9696 [SET1] MasterCard and Visa, "SET Secure Electronic Transaction 9697 Specification, Book 1: Business Description", ver. 1.0, 31 9698 May 1997. 9700 [SET2] ---, "SET Secure Electronic Transaction Specification, Book 9701 2: Programmer's Guide", ver. 1.0, 31 May 1997. 9703 [Stei] J. Steiner, C. Neuman, and J. Schiller, "Kerberos: An 9704 Authentication Service for Open Network Systems" in "Usenix 9705 Conference Proceedings", Feb 1988. 9707 [X400] International Telecommunications Union--Telecommunication 9708 Standardization Sector (formerly "CCITT"), Recommendation 9709 X.400, "Message Handling Services: Message Handling System 9710 and Service Overview". 9712 [X500] ---, Recommendation X.500, "Information Technology--Open 9713 Systems Interconnection--The Directory: Overview of 9714 Concepts, Models, and Services". (Equivalent to ISO 9594-1.) 9716 [X501] ---, Recommendation X.501, "Information Technology--Open 9717 Systems Interconnection--The Directory: Models". 9719 [X509] ---, Recommendation X.509, "Information Technology--Open 9720 Systems Interconnection--The Directory: Authentication 9721 Framework". (AKA ISO 9594-8.) 9723 [X519] ---, Recommendation X.519, "Information Technology--Open 9724 Systems Interconnection--The Directory: Protocol 9725 Specifications". 9727 [X520] ---, Recommendation X.520, "Information Technology--Open 9728 Systems Interconnection--The Directory: Selected Attribute 9729 Types". 9731 [X680] ---, Recommendation X.680, "Information Technology--Abstract 9732 Syntax Notation One (ASN.1)--Specification of Basic 9733 Notation", 15 Nov 1994. (Equivalent to ISO/IEC 8824-1.) 9735 [X690] ---, Recommendation X.690, "Information Technology--ASN.1 9736 Encoding Rules--Specification of Basic Encoding Rules (BER), 9737 Canonical Encoding Rules (CER) and Distinguished Encoding 9738 Rules (DER)", 15 Nov 1994. (Equivalent to ISO/IEC 8825-1.) 9740 5. Security Considerations 9742 The focus of this document is security terminology, but this document 9743 does not discuss security issues in the sense of describing or 9744 analyzing threats to, vulnerabilities of, or countermeasures to 9745 protect, any specific Internet Standard protocol. 9747 6. Acknowledgments 9749 Pat Cain, Mike Kong, and Charles Lynn provided meticulous comments on 9750 an initial version of this document. 9752 7. Author's Address 9754 Please address all comments to: 9756 Robert W. Shirey 9757 GTE / BBN Technologies 9758 Suite 1200, Mail Stop 30/12B2 9759 1300 Seventeenth Street North, 9760 Arlington, VA 22209-3801 USA 9762 Phone: +1 (703) 284-4641 9763 Fax: +1 (703) 284-2766 9764 Email: rshirey@bbn.com 9766 8. Expiration Date 9768 This Internet Draft expires on 17 April 2000.