idnits 2.17.00 (12 Aug 2021) /tmp/idnits32205/draft-shirey-secgloss-v2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 15011), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 149: '... the SHOULD NOTs -- so that readers ...' RFC 2119 keyword, line 166: '... that are RECOMMENDED for use in ...' RFC 2119 keyword, line 194: '... - "I" for a RECOMMENDED term or d...' RFC 2119 keyword, line 195: '... - "N" if RECOMMENDED but not of...' RFC 2119 keyword, line 199: '...tion that is deprecated and SHOULD NOT...' (197 more instances...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2828, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 10592 has weird spacing: '...dentity v ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 August 2004) is 6482 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Government' is mentioned on line 915, but not defined == Missing Reference: 'R1401' is mentioned on line 1799, but not defined == Missing Reference: 'R2144' is mentioned on line 1994, but not defined == Missing Reference: 'ABA96' is mentioned on line 2468, but not defined == Missing Reference: 'It' is mentioned on line 3279, but not defined == Missing Reference: 'RFC 2167' is mentioned on line 4282, but not defined == Missing Reference: 'DGSA' is mentioned on line 11079, but not defined == Missing Reference: 'CORBA' is mentioned on line 4656, but not defined == Missing Reference: 'R1034' is mentioned on line 4680, but not defined == Missing Reference: 'R3573' is mentioned on line 7679, but not defined == Missing Reference: 'SP-28' is mentioned on line 8136, but not defined == Missing Reference: 'NS4009' is mentioned on line 8389, but not defined == Missing Reference: 'CSC001' is mentioned on line 13167, but not defined == Missing Reference: 'R3280' is mentioned on line 9863, but not defined == Missing Reference: 'IS9945-1' is mentioned on line 9536, but not defined == Missing Reference: 'IS7812' is mentioned on line 9610, but not defined == Missing Reference: 'C4008' is mentioned on line 9785, but not defined == Missing Reference: 'EU-ESDIR' is mentioned on line 10061, but not defined == Missing Reference: 'RSA78' is mentioned on line 10511, but not defined == Missing Reference: 'Constraints' is mentioned on line 10595, but not defined == Missing Reference: 'R1760' is mentioned on line 10713, but not defined == Missing Reference: 'I7498-4' is mentioned on line 11356, but not defined == Missing Reference: 'DoDAF1' is mentioned on line 12413, but not defined == Missing Reference: 'N4009' is mentioned on line 12612, but not defined == Missing Reference: 'FIPS31' is mentioned on line 12731, but not defined == Missing Reference: 'CA' is mentioned on line 13082, but not defined == Missing Reference: 'NIST' is mentioned on line 13360, but not defined == Missing Reference: 'FIPS' is mentioned on line 13361, but not defined == Unused Reference: 'Army' is defined on line 14209, but no explicit reference was found in the text == Unused Reference: 'DoD6' is defined on line 14321, but no explicit reference was found in the text == Unused Reference: 'ElGa' is defined on line 14323, but no explicit reference was found in the text == Unused Reference: 'FP041' is defined on line 14358, but no explicit reference was found in the text == Unused Reference: 'FP191' is defined on line 14396, but no explicit reference was found in the text == Unused Reference: 'I7498' is defined on line 14428, but no explicit reference was found in the text == Unused Reference: 'I7812' is defined on line 14437, but no explicit reference was found in the text == Unused Reference: 'I9945' is defined on line 14443, but no explicit reference was found in the text == Unused Reference: 'Knut' is defined on line 14476, but no explicit reference was found in the text == Unused Reference: 'N4006' is defined on line 14511, but no explicit reference was found in the text == Unused Reference: 'NCS01' is defined on line 14517, but no explicit reference was found in the text == Unused Reference: 'NCS03' is defined on line 14521, but no explicit reference was found in the text == Unused Reference: 'PKCS' is defined on line 14556, but no explicit reference was found in the text == Unused Reference: 'R1208' is defined on line 14581, but no explicit reference was found in the text == Unused Reference: 'R1750' is defined on line 14628, but no explicit reference was found in the text == Unused Reference: 'R1885' is defined on line 14647, but no explicit reference was found in the text == Unused Reference: 'R2356' is defined on line 14720, but no explicit reference was found in the text == Unused Reference: 'R3820' is defined on line 14825, but no explicit reference was found in the text == Unused Reference: 'SP27' is defined on line 14894, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'A1523' -- 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. 'A9063' -- Possible downref: Non-RFC (?) normative reference: ref. 'ABA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ande' -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI' -- Possible downref: Non-RFC (?) normative reference: ref. 'Army' -- Possible downref: Non-RFC (?) normative reference: ref. 'B1822' -- Possible downref: Non-RFC (?) normative reference: ref. 'B4799' -- Possible downref: Non-RFC (?) normative reference: ref. 'BS7799' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bell' -- Possible downref: Non-RFC (?) normative reference: ref. 'Biba' -- Possible downref: Non-RFC (?) normative reference: ref. 'BN89' -- Possible downref: Non-RFC (?) normative reference: ref. 'C4009' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'Chau' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cheh' -- Possible downref: Non-RFC (?) normative reference: ref. 'Chris' -- Possible downref: Non-RFC (?) normative reference: ref. 'CIPSO' -- Possible downref: Non-RFC (?) normative reference: ref. 'Clark' -- Possible downref: Non-RFC (?) normative reference: ref. 'CSC1' -- 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. 'Daem' -- Possible downref: Non-RFC (?) normative reference: ref. 'Denn' -- Possible downref: Non-RFC (?) normative reference: ref. 'Denns' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH76' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD1' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD2' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD3' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD4' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD5' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD6' -- Possible downref: Non-RFC (?) normative reference: ref. 'ElGa' -- 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. 'F1037' -- 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. 'FP041' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP046' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP074' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP081' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP087' -- 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. 'FP191' -- Possible downref: Non-RFC (?) normative reference: ref. 'FP197' -- Possible downref: Non-RFC (?) normative reference: ref. 'FPKI' -- Possible downref: Non-RFC (?) normative reference: ref. 'Gass' -- Possible downref: Non-RFC (?) normative reference: ref. 'Gray' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hafn' -- Possible downref: Non-RFC (?) normative reference: ref. 'Huff' -- 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. 'IATF' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDSAN' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDSSC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDSSE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDSSY' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ioan' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'JCSP1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kahn' -- Possible downref: Non-RFC (?) normative reference: ref. 'Knut' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kuhn' -- Possible downref: Non-RFC (?) normative reference: ref. 'Land' -- Possible downref: Non-RFC (?) normative reference: ref. 'Larm' -- Possible downref: Non-RFC (?) normative reference: ref. 'M0404' -- Possible downref: Non-RFC (?) normative reference: ref. 'Mene' -- Possible downref: Non-RFC (?) normative reference: ref. 'Moor' -- Possible downref: Non-RFC (?) normative reference: ref. 'Murr' -- Possible downref: Non-RFC (?) normative reference: ref. 'N4001' -- Possible downref: Non-RFC (?) normative reference: ref. 'N4006' -- Possible downref: Non-RFC (?) normative reference: ref. 'N7003' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCS01' -- Possible downref: Non-RFC (?) normative reference: ref. 'NCS03' -- 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. 'NRC91' -- Possible downref: Non-RFC (?) normative reference: ref. 'NRC98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Park' -- Possible downref: Non-RFC (?) normative reference: ref. 'Perr' -- Possible downref: Non-RFC (?) normative reference: ref. 'PGP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKC05' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKC07' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKC10' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKC11' ** Downref: Normative reference to an Historic RFC: RFC 1108 ** Downref: Normative reference to an Informational RFC: RFC 1135 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Informational RFC: RFC 1208 ** Downref: Normative reference to an Informational RFC: RFC 1281 ** 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) ** Obsolete normative reference: RFC 1734 (Obsoleted by RFC 5034) -- Possible downref: Non-RFC (?) normative reference: ref. 'R1750' ** 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 1885 (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1938 (Obsoleted by RFC 2289) ** Downref: Normative reference to an Informational RFC: RFC 1983 ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** 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) ** Obsolete normative reference: RFC 2138 (Obsoleted by RFC 2865) ** 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 2223 (Obsoleted by RFC 7322) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2267 (Obsoleted by RFC 2827) ** Downref: Normative reference to an Informational RFC: RFC 2315 ** Downref: Normative reference to an Informational RFC: RFC 2323 ** Downref: Normative reference to an Informational RFC: RFC 2356 ** 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 2459 (Obsoleted by RFC 3280) ** 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 2560 (Obsoleted by RFC 6960) ** 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 ** Downref: Normative reference to an Informational RFC: RFC 2635 ** Downref: Normative reference to an Experimental RFC: RFC 2773 ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) ** Downref: Normative reference to an Informational RFC: RFC 3198 ** Obsolete normative reference: RFC 3547 (Obsoleted by RFC 6407) ** Downref: Normative reference to an Informational RFC: RFC 3740 ** Obsolete normative reference: RFC 3280 (ref. 'R3820') (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'Raym' -- Possible downref: Non-RFC (?) normative reference: ref. 'Roge' -- Possible downref: Non-RFC (?) normative reference: ref. 'Russ' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAML' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sand' -- 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. 'SKEME' -- Possible downref: Non-RFC (?) normative reference: ref. 'SKIP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP12' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP14' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP15' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP22' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP27' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP28' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP30' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP31' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP32' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP33' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP37' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP41' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP42' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP56' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP57' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP61' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP63' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP67' -- Possible downref: Non-RFC (?) normative reference: ref. 'Stei' -- Possible downref: Non-RFC (?) normative reference: ref. 'Weis' -- 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: 79 errors (**), 0 flaws (~~), 53 warnings (==), 155 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. W. Shirey 2 Obsoletes: RFC 2828 (if approved) BBN Technologies 3 Expiration Date: 20 February 2004 20 August 2004 5 Internet Security Glossary, Version 2 6 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 This document may not be modified, and derivative works of it may 16 not be created, except to publish it as an RFC and to translate it 17 into languages other than English. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than a "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html" 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This Glossary has 1,500 entries that give definitions, abbreviations, 42 and explanations for terminology concerning information system 43 security. It makes recommendations to improve the clarity of Internet 44 Standards documents (ISDs) and the ease with which international 45 readers can understand ISDs. Its follow the principles that ISDs 46 should (a) use the same term or definition whenever the same concept 47 is mentioned; (b) use terms in their plainest, dictionary sense; (c) 48 use terms that are already well-established in open publications; and 49 (d) avoid terms that are proprietary, favor a particular vendor, or 50 create a bias toward a particular technology or mechanism versus 51 other, competing techniques that already exist or might be developed. 53 Table of Contents 55 Section Page 56 ------- ---- 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Format of Entries . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1 Presentation Order . . . . . . . . . . . . . . . . . . . . 4 60 2.2 Capitalization and Abbreviation . . . . . . . . . . . . . 4 61 2.3 Support for Automated Searching . . . . . . . . . . . . . 5 62 2.4 Definition Type and Context . . . . . . . . . . . . . . . 5 63 2.5 Explanatory Notes . . . . . . . . . . . . . . . . . . . . 5 64 2.6 Cross-References . . . . . . . . . . . . . . . . . . . . . 5 65 2.7 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.8 The New Punctuation . . . . . . . . . . . . . . . . . . . 6 67 3. Types of Definitions . . . . . . . . . . . . . . . . . . . . . 6 68 3.1 Type "I": Recommended Definition with Internet Basis . . . 6 69 3.2 Type "N": Recommended Definition with Non-Internet Basis . 7 70 3.3 Type "O": Other Definitions. . . . . . . . . . . . . . . . 7 71 2.4 Type "D": Deprecated Definitions . . . . . . . . . . . . . 7 72 2.5 Definition Substitutions . . . . . . . . . . . . . . . . . 7 73 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Informative References . . . . . . . . . . . . . . . . . . . 276 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 293 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 293 77 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 293 78 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 293 80 1. Introduction 82 This Glossary provides an internally consistent and self-contained 83 set of terms, abbreviations, and definitions -- supported by 84 explanations, recommendations, and references -- for terminology that 85 concerns information system security. The intent of this Glossary is 86 to improve the comprehensibility of Internet Standards documents 87 (ISDs) -- i.e., RFCs, Internet-Drafts, and other material produced as 88 part of the Internet Standards Process [R2026] -- and of all other 89 Internet-related material, too. A few non-security, networking terms 90 are included to make the Glossary self-contained, but more complete 91 glossaries of networking terms are available elsewhere [A1523, F1037, 92 R1208, R1983]. 94 This Glossary supports the goals of the Internet Standards Process: 96 o Clear, Concise, Easily Understood Documentation 98 This Glossary seeks to improve comprehensibility of security- 99 related content of ISDs. That requires wording to be clear and 100 understandable, and requires the set of security-related terms and 101 definitions to be consistent and self-supporting. Also, 102 terminology needs to be uniform across all ISDs; i.e., the same 103 term or definition needs to be used whenever and wherever the same 104 concept is mentioned. Harmonization of existing ISDs need not be 105 done immediately, but it is desirable to correct and standardize 106 terminology when new versions are issued in the normal course of 107 standards development and evolution. 109 o Technical Excellence 111 Just as Internet Standard (STD) protocols should operate 112 effectively, ISDs should use terminology accurately, precisely, 113 and unambiguously to enable standards to be implemented correctly. 115 o Prior Implementation and Testing 117 Just as STD protocols require demonstrated experience and 118 stability before adoption, ISDs need to use well-established 119 language. Using terms in their plainest, dictionary sense (when 120 appropriate) helps to ensure international understanding. ISDs 121 need to avoid using private, made-up terms in place of generally- 122 accepted terms from open publications. ISDs need to avoid 123 substituting new definitions that conflict with established ones. 124 ISDs need to avoid using "cute" synonyms (e.g., see: Green Book), 125 because no matter how popular a nickname may be in one community, 126 it is likely to cause confusion in another. 128 o Openness, Fairness, and Timeliness 130 ISDs need to avoid terms that are proprietary or otherwise favor a 131 particular vendor, or that create a bias toward a particular 132 security technology or mechanism over other, competing techniques 133 that already exist or might be developed in the future. The set of 134 terminology used across the set of ISDs needs to be flexible and 135 adaptable as the state of Internet security art evolves. 137 In support of those goals, this Glossary provides guidance by marking 138 terms and definitions as being either endorsed or deprecated for use 139 in ISDs. The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 140 and "OPTIONAL" are intended to be interpreted the same way as in an 141 Internet Standard (i.e., as specified in RFC 2119). Other glossaries 142 (e.g., [Raym]) list additional terms that deal with Internet security 143 but have not been included in this Glossary because they are not 144 appropriate for ISDs. 146 This Glossary is not an Internet standard, and its guidance 147 represents only the recommendations of this author. However, this 148 Glossary provides reasons for its recommendations -- particularly for 149 the SHOULD NOTs -- so that readers can judge for themselves whether 150 to follow the guidance. 152 2. Format of Entries 154 Section 4 presents Glossary entries in the following manner: 156 2.1 Order of Entries 158 Entries are sorted in lexicographic order, without regard to 159 capitalization. Numeric digits are treated as preceding alphabetic 160 characters; special characters are treated as preceding digits; 161 blanks are treated as preceding all other characters; and a hyphen 162 or slash between two parts of an entry is treated like a blank. 164 If an entry has multiple definitions (e.g., "domain"), they are 165 numbered beginning with "1", and any of those multiple definitions 166 that are RECOMMENDED for use in ISDs are presented before other 167 definitions for that entry. If definitions are closely related 168 (e.g., "threat"), they are denoted by adding letters to a number, 169 such as "1a" and "1b". 171 2.2 Capitalization and Abbreviations 173 Entries that are proper nouns are capitalized (e.g., "Data 174 Encryption Algorithm"), as are other words derived from proper 175 nouns (e.g., "Caesar cipher"). All other entries are not 176 capitalized (e.g., "certification authority"). Each acronym or 177 other abbreviation that appears in this Glossary, either as an 178 entry or in a definition or explanation, is defined in this 179 Glossary, except items of common English usage, such as "e.g.", 180 "etc.", "i.e.", "vol.", "pp.", and "U.S.". 182 2.3 Support for Automated Searching 184 Each entry is preceded by a dollar sign ($) and a space. This 185 makes it possible to find the defining entry for an item "X" by 186 searching for the character string "$ X", without stopping at 187 entries in which "X" is used in explanations. 189 2.4 Definition Type and Context 191 Each entry is preceded by a character -- I, N, O, or D -- enclosed 192 in parentheses, to indicate the type of definition (as is 193 explained further in Section 3): 194 - "I" for a RECOMMENDED term or definition of Internet origin. 195 - "N" if RECOMMENDED but not of Internet origin. 196 - "O" for a term or definition that is NOT recommended for use in 197 ISDs but is something that authors of Internet documents need 198 to know about. 199 - "D" for a term or definition that is deprecated and SHOULD NOT 200 be used in Internet documents. 202 If a definition is valid only in a specific context (e.g., 203 "baggage"), that context is shown immediately following the 204 definition type and is enclosed by a pair of slash symbols (/). If 205 the definition is valid only for specific parts of speech, that is 206 shown in the same way (e.g., "archive). 208 2.5 Explanatory Notes 210 Some entries have explanatory text that is introduced by one or 211 more of the following keywords: 212 - Deprecated Abbreviation (e.g., "EE", "H field", "W3") 213 - Deprecated Definition (e.g., "digital certification") 214 - Deprecated Usage (e.g., "authenticate") 215 - Deprecated Term (e.g., "certificate authority") 216 - Pronunciation (e.g., "*-property") 217 - Derivation (e.g., "discretionary access control") 218 - Tutorial (e.g., "accreditation") 219 - Example (e.g., "back door") 220 - Usage (e.g., "access") 222 Explanatory text in this Glossary MAY be reused in other ISDs. 223 However, such text is not intended to authoritatively supersede 224 text of an ISD in which the Glossary entry is already used. 226 2.6 Cross-References 228 Some entries contain a parenthetical remark of the form "(See: 229 X)", where X is a list one of more related Glossary entries. Some 230 entries contain a remark of the form "(Compare: X)", where X is a 231 list of other entries that either are antonyms or differ in some 232 other manner worth observing. 234 2.7 Trademarks 236 All servicemarks and trademarks that appear in this Glossary are 237 used in an editorial fashion and to the benefit of the mark owner, 238 without any intention of infringement. 240 2.8 The New Punctuation 242 This Glossary uses the "new" or "logical" punctuation style that 243 is favored by computer programmers, as described in [Raym]: 244 Programmers use pairs of quotation marks the same way they use 245 pairs of parentheses, i.e., as balanced delimiters. For example, 246 if " Alice sends" is a phrase, and so are "Bill receives" and "Eve 247 listens", then a programmer would write the following sentence: 249 "Alice sends", "Bill receives", and "Eve listens". 251 According to standard American usage, the punctuation in that 252 sentence is incorrect; the continuation commas and the final 253 period should go inside the string quotes, like this: 255 "Alice sends," "Bill receives," and "Eve listens." 257 However, a programmer would not include a character in a literal 258 string if the character did not belong there, because that could 259 cause an error. For example, suppose a sentence in a draft of a 260 tutorial on the vi editing language looked like this: 262 Then delete one line from the file by typing "dd". 264 A book editor following standard usage might change the sentence 265 to look like this: 267 Then delete one line from the file by typing "dd." 269 However, in the vi language, the dot character repeats the last 270 command accepted. So, if a reader entered "dd.", two lines would 271 be deleted instead of one. 273 Similarly, use of standard American punctuation might cause 274 misunderstanding in entries in this Glossary. Thus, the new 275 punctuation is used here, and we recommend it for ISDs. 277 3. Types of Definition 279 Each entry in this Glossary is marked as type I, N, O, or D: 281 3.1 Type "I": Recommended Term or Definition with Internet Basis 283 The marking "I" indicates two things: 284 - Origin: "I" (as opposed to "N") means either that the Internet 285 Standards Process or Internet community is authoritative for 286 the definition *or* that the term is sufficiently generic that 287 this Glossary can freely state a definition without 288 contradicting a non-Internet authority (e.g., "attack"). 289 - Recommendation: "I" (as opposed to "O") means that the term and 290 definition are RECOMMENDED for use in ISDs. However, some "I" 291 entries may be accompanied by a "Usage" note that states a 292 limitation (e.g., "certification"), and ISDs SHOULD NOT use the 293 defined term outside that limited context. 295 Many "I" entries are proper nouns (e.g., "Internet Protocol") for 296 which the definition is intended only to provide basic 297 information; i.e., the authoritative definition of such terms is 298 found elsewhere. For a proper noun described as an "Internet 299 protocol", please refer to the current edition of "Internet 300 Official Protocol Standards" (STD 1) for the standardization 301 status of the protocol. 303 3.2 Type "N": Recommended Term or Definition with Non-Internet Basis 305 The marking "N" indicates two things: 306 - Origin: "N" (as opposed to "I") means that the entry has a non- 307 Internet basis or origin. 308 - Recommendation: "N" (as opposed to "O") means that the term and 309 definition are RECOMMENDED for use in ISDs, if they are needed 310 at all in ISDs. Many of these entries are accompanied by a 311 label that states a context (e.g., "package") or a note that 312 states a limitation (e.g., "data integrity"), and ISDs SHOULD 313 NOT use the defined term outside that context or limit. Some of 314 the contexts are rarely if ever expected to occur in an ISD 315 (e.g., see: baggage). In those cases, the listing exists to 316 make Internet authors aware of the non-Internet usage so that 317 they can avoid conflicts with non-Internet documents. 319 3.3 Type "O": Other Terms and Definitions To Be Noted 321 The marking "O" means that the definition has a non-Internet basis 322 and SHOULD NOT be used in ISDs *except* in cases where the term is 323 specifically identified as non-Internet. 325 For example, an ISD might mention "BCA" (see: brand certification 326 authority) or "baggage" as an example of some concept; in that 327 case, the document should specifically say "SET(trademark) BCA" or 328 "SET(trademark) baggage" and include the definition of the term. 330 3.4 Type "D": Deprecated Terms and Definitions 332 If this Glossary recommends that an term or definition SHOULD NOT 333 be used in ISDs, then the entry is marked as type "D", and a 334 "Deprecated Term", "Deprecated Definition", or "Deprecated Usage" 335 explanatory note is provided. 337 3.5 Definition Substitutions 339 Some terms have a definition published by a non-Internet authority 340 -- government (e.g., "object reuse"), industry (e.g., "Secure Data 341 Exchange"), national authority (e.g., "Data Encryption Standard"), 342 or international body (e.g., "data confidentiality") -- that is 343 suitable for use in ISDs. In those cases, this Glossary marks the 344 definition "N", recommending its use in Internet documents. 346 Other such terms have definitions that are inadequate or 347 inappropriate for ISDs. For example, a definition might be 348 outdated or too narrow, or it might need clarification by 349 substituting more careful wording (e.g., "authentication 350 exchange") or explanations, using other terms that are defined in 351 this Glossary. In those cases, this Glossary marks the entry "O", 352 and provides an "I" or "N" entry that precedes, and is intended to 353 supersede, the "O" entry. 355 In some cases where this Glossary provides a definition to 356 supersede an "O" definition, the substitute is intended to subsume 357 the meaning of the "O" entry and not conflict with it. For the 358 term "security service", for example, the "O" definition deals 359 narrowly with only communication services provided by layers in 360 the OSI model and is inadequate for the full range of ISD usage, 361 while the new "I" definition provided by this Glossary can be used 362 in more situations and for more kinds of service. However, the "O" 363 definition is also listed so that ISD authors will be aware of the 364 context in which the term is used more narrowly. 366 When making substitutions, this Glossary attempts to avoid 367 contradicting any non-Internet authority. Still, terminology 368 differs between the standards of the American Bar Association, 369 OSI, SET, the U.S. DoD, and other authorities; and this Glossary 370 probably is not exactly aligned with any of them. 372 4. Definitions 374 $ *-property 375 (N) Synonym for "confinement property" in the context of the Bell- 376 LaPadula model. Pronunciation: star property. 378 $ 3DES 379 See: Triple Data Encryption Algorithm. 381 $ A1 computer system 382 (O) See: TCSEC. 384 $ AA 385 See: attribute authority. 387 $ ABA Guidelines 388 (N) "American Bar Association (ABA) Digital Signature Guidelines" 389 [ABA], a framework of legal principles for using digital 390 signatures and digital certificates in electronic commerce. 392 $ Abstract Syntax Notation One (ASN.1) 393 (N) A standard for describing data objects. [Larm, X680] (See: 394 CMS.) 396 Usage: This term is often incorrectly used to refer to BER. 398 Tutorial: OSIRM defines computer network functionality in layers. 399 Protocols and data objects at higher layers are abstractly defined 400 to be implemented using protocols and data objects from lower 401 layers. A higher layer may define transfers of abstract objects 402 between computers, and a lower layer may define those transfers 403 concretely as strings of bits. Syntax is needed to specify data 404 formats of abstract objects, and encoding rules are needed to 405 transform abstract objects into bit strings at lower layers. OSI 406 standards use ASN.1 for those specifications and use various 407 encoding rules for those transformations. (See: BER.) 409 In ASN.1, formal names are written without spaces, and separate 410 words in a name are indicated by capitalizing the first letter of 411 each word except the first word. For example, the name of a CRL is 412 "certificateRevocationList". 414 $ ACC 415 (I) See: access control center. 417 $ acceptable risk 418 (I) A risk that is understood and tolerated by a system's 419 accreditor, usually because the cost or difficulty of implementing 420 an effective countermeasure for the associated vulnerability 421 exceeds the expectation of loss. (See: adequate security, (second 422 law under) Courtney's laws.) 424 $ access 425 1. (I) The ability and means to communicate with or otherwise 426 interact with a system to use system resources either to handle 427 information or to gain knowledge of the information the system 428 contains. (Compare: handle.) 430 Usage: The definition is intended to include all types of 431 communication with a system, including one-way communication in 432 either direction. In actual practice, however, entities that are 433 outside a security perimeter and can receive output from the 434 system but cannot provide input or otherwise directly interact 435 with the system, might be treated as not having "access" (and, 436 therefore, be exempt from security policy requirements, such as 437 the need for a security clearance). 439 2. (O) /formal model/ "A specific type of interaction between a 440 subject and an object that results in the flow of information from 441 one to the other." [NCS04] 443 $ Access Certificate for Electronic Services (ACES) 444 (O) A PKI operated by the U.S. Government's General Services 445 Administration in cooperation with industry partners. (See: CAM.) 447 $ access control 448 1. (I) Protection of system resources against unauthorized access. 450 2. (I) A process by which use of system resources is regulated 451 according to a security policy and is permitted only by authorized 452 entities (users, programs, processes, or other systems) according 453 to that policy. (See: access, access control service, computer 454 security, discretionary access control, mandatory access control, 455 role-based access control.) 457 3. (I) /formal model/ Limitations on interactions between subjects 458 and objects in an information system. 460 4. (O) "The prevention of unauthorized use of a resource, 461 including the prevention of use of a resource in an unauthorized 462 manner." [I7498 Part 2] 464 5. (O) /U.S. Government/ A system using physical, electronic, or 465 human controls to identify or admit personnel with properly 466 authorized access to a SCIF. 468 $ access control center (ACC) 469 (I) A computer that maintains a database (possibly in the form of 470 an access control matrix) defining the security policy for an 471 access control service, and that acts as a server for clients 472 requesting access control decisions. 474 Tutorial: An ACC is sometimes used in conjunction with a key 475 center to implement access control in a key distribution system 476 for symmetric cryptography. (See: BLACKER, Kerberos.) 478 $ access control list (ACL) 479 (I) /information system/ A mechanism that implements access 480 control for a system resource by enumerating the system entities 481 that are permitted to access the resource and, either implicitly 482 or explicitly, the types of access granted to each. (Compare: 483 access control matrix, access list, access profile, capability.) 485 $ access control matrix 486 (I) A rectangular array of cells, with one row per subject and one 487 column per object. The entry in a cell -- that is, the entry for a 488 particular subject-object pair -- indicates the access mode that 489 the subject is permitted to exercise on the object. Each column is 490 equivalent to an "access control list" for the object; and each 491 row is equivalent to an "access profile" for the subject. 493 $ access control service 494 (I) A security service that protects against a system entity using 495 a system resource in a way not authorized by the system's security 496 policy. (See: access control, discretionary access control, 497 identity-based security policy, mandatory access control, rule- 498 based security policy.) 500 Tutorial: This service includes protecting against use of a 501 resource in an unauthorized manner by an entity (i.e., a 502 principal) that is authorized to use the resource in some other 503 manner. (See: insider.) The two basic mechanisms for implementing 504 this service are ACLs and tickets. 506 $ access level 507 (D) Synonym for the hierarchical "classification level" in a 508 security level. [C4009] (See: security level.) 510 Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts 511 in a potentially misleading way. Access control may be based on 512 attributes other than classification level. 514 $ access list 515 (I) /physical security/ Roster of persons who are authorized to 516 enter a controlled area. (Compare: access control list.) 518 $ access mode 519 (I) A distinct type of data processing operation -- e.g., read, 520 write, append, or execute -- that a subject can potentially 521 perform on an object in an information system. [Huff] 523 $ access policy 524 (I) A kind of "security policy". (See: access, access control.) 526 $ access profile 527 (O) /information system/ A mechanism that implements access 528 control for a system entity by enumerating the system resources 529 that the entity is authorized to access and, either implicitly or 530 explicitly, the types of access granted to each. (Compare: access 531 control matrix, access control list, access list, capability.) 533 Usage: The definition is not widely known; therefore, ISDs that 534 use this term SHOULD state a definition for it. 536 $ access right 537 (I) Synonym for "authorization"; emphasizes the possession of the 538 authorization by a system entity. 540 $ accountability 541 (I) The property of a system or system resource that ensures that 542 the actions of a system entity may be traced uniquely to that 543 entity, which can then be held responsible for its actions. [Huff] 544 (See: audit service.) 546 Tutorial: Accountability (also known as "individual 547 accountability") typically involves a system capability to 548 positively associate the identity of a user with the time, method, 549 and mode of the user's access to the system. This capability 550 supports detection and subsequent investigation of security 551 breaches. Individual persons who are system users are held 552 accountable for their actions after being notified of the rules of 553 behavior for using the system and the penalties associated with 554 violating those rules. 556 $ accounting 557 See: COMSEC accounting. 559 $ accounting legend code (ALC) 560 (O) /U.S. Government/ Numeric system used to indicate the minimum 561 accounting controls required for items of COMSEC material within 562 the CMCS. [C4009] (See: COMSEC accounting.) 564 $ accreditation 565 (N) An administrative action by which a designated authority 566 declares that an information system is approved to operate in a 567 particular security configuration with a prescribed set of 568 safeguards. [FP102, SP37] (See: certification.) 570 Tutorial: An accreditation is usually based on a technical 571 certification of the system's security mechanisms. To accredit a 572 system, the approving authority must determine that any residual 573 risk is an acceptable risk. Although the terms "certification" and 574 "accreditation" are used more in the U.S. DoD and other government 575 agencies than in commercial organizations, the concepts apply any 576 place where managers are required to deal with and accept 577 responsibility for security risks. For example, the American Bar 578 Association is developing accreditation criteria for CAs. 580 $ accreditation boundary 581 (O) Synonym for "security perimeter". [C4009] 583 $ accreditor 584 (N) A management official who has been designated to have the 585 formal authority to "accredit" an information system, i.e., to 586 authorize the operation of, and the processing of sensitive data 587 in, the system and to accept the residual risk associated with the 588 system. (See: accreditation, residual risk.) 590 $ ACES 591 (O) See: Access Certificate for Electronic Services. 593 $ ACL 594 (I) See: access control list. 596 $ acquirer 597 1. (O) /SET/ "The financial institution that establishes an 598 account with a merchant and processes payment card authorizations 599 and payments." [SET1] 601 2. (O) /SET/ "The institution (or its agent) that acquires from 602 the card acceptor the financial data relating to the transaction 603 and initiates that data into an interchange system." [SET2] 605 $ activation data 606 (N) Secret data, other than keys, that is required to access a 607 cryptographic module. 609 $ active attack 610 (I) See: (secondary definition under) attack. 612 $ active content 613 (O) "Electronic documents that can carry out or trigger actions 614 automatically on a computer platform without the intervention of a 615 user. [This technology enables] mobile code associated with a 616 document to execute as the document is rendered." [SP28] 618 $ active wiretapping 619 (I) A wiretapping attack that attempts to alter data being 620 communicated or otherwise affect data flow. (See: wiretapping. 621 Compare: active attack, passive wiretapping.) 623 $ add-on security 624 (N) The retrofitting of protection mechanisms, implemented by 625 hardware or software, in an information system after the system 626 has become operational. [FP039] (Compare: baked-in security.) 628 $ adequate security 629 (O) /U.S. DoD/ "Security commensurate with the risk and magnitude 630 of harm resulting from the loss, misuse, or unauthorized access to 631 or modification of information." (See: acceptable risk, residual 632 risk.) 634 $ administrative security 635 1. (I) Management procedures and constraints to prevent 636 unauthorized access to a system. (See: (third law under) 637 Courtney's laws, operational security, procedural security, 638 security architecture. Compare: technical security.) 640 Examples: Clear delineation and separation of duties; 641 configuration control. 643 Usage: Administrative security is usually understood to consist of 644 methods and mechanisms that are implemented and executed primarily 645 by people, rather than by automated systems. 647 2. (O) "The management constraints, operational procedures, 648 accountability procedures, and supplemental controls established 649 to provide an acceptable level of protection for sensitive data." 650 [FP039] 652 $ administrator 653 1. (O) /Common Criteria/ A person that is responsible for 654 configuring, maintaining, and administering the TOE in a correct 655 manner for maximum security. (See: administrative security.) 657 2. (O) /ITSEC/ A person in contact with the TOE, who is 658 responsible for maintaining its operational capability. 660 $ Advanced Encryption Standard (AES) 661 (N) A U.S. Government standard [FP197] (the successor to DES) that 662 (a) specifies the "the AES algorithm", which is a symmetric block 663 cipher that is based on Rijndael and uses key sizes of 128, 192, 664 or 256 bits to operate on a 128-bit block, and (b) states policy 665 for using that algorithm to protect unclassified, sensitive data. 667 Tutorial: Rijndael was designed to handle additional block sizes 668 and key lengths that were not adopted in the AES. Rijndael was 669 selected by NIST through a public competition that was held to 670 find a successor to the DEA; the other finalists were MARS, RC6, 671 Serpent, and Twofish. 673 $ adversary 674 1. (I) An entity that attacks a system. (Compare: intruder.) 676 2. (I) An entity that is a threat to a system. 678 $ AES 679 (N) See: Advanced Encryption Standard. 681 $ Affirm 682 (O) A formal methodology, language, and integrated set of software 683 tools developed at the University of Southern California's 684 Information Sciences Institute for specifying, coding, and 685 verifying software to produce correct and reliable programs. 686 [Cheh] 688 $ aggregation 689 (I) A circumstance in which a collection of information items is 690 required to be classified at a higher security level than any of 691 the items is classified individually. 693 $ AH 694 (I) See: Authentication Header 696 $ air gap 697 (I) An interface between two systems at which (a) they are not 698 connected physically and (b) any logical connection is not 699 automated (i.e., data is transferred through the interface only 700 manually, under human control). (See: sneaker net.) 702 Example: Computer A and computer B are on opposite sides of a 703 room. To move data from A to B, a person carries a floppy disk 704 across the room. If A and B operate in different security domains, 705 than moving data across the air gap may involve an upgrade or 706 downgrade operation. 708 $ ALC 709 (O) See: accounting legend code. 711 $ algorithm 712 (I) A finite set of step-by-step instructions for a problem- 713 solving or computation procedure, especially one that can be 714 implemented by a computer. (See: cryptographic algorithm.) 716 $ alias 717 (I) A name that an entity uses in place of its real name, usually 718 for the purpose of either anonymity or masquerade. 720 $ Alice and Bob 721 (I) The parties that are most often called upon to illustrate the 722 operation of bipartite security protocols. These and other 723 dramatis personae are listed by Schneier [Schn]. 725 $ American National Standards Institute (ANSI) 726 (N) A private, not-for-profit association that administers U.S. 727 private sector voluntary standards. 729 Tutorial: ANSI has approximately 1,000 member organizations, 730 including equipment users, manufacturers, and others. These 731 include commercial firms, government agencies, and other 732 institutions and international entities. 734 ANSI is the sole U.S. representative to the two major non-treaty 735 international standards organizations, ISO and, via the U.S. 737 National Committee (USNC), the International Electrotechnical 738 Commission (IEC). 740 ANSI provides a forum for ANSI-accredited standards development 741 groups. Among those groups, the following are especially relevant 742 to Internet security: 743 - International Committee for Information Technology 744 Standardization (INCITS) (formerly X3): Primary U.S. focus of 745 standardization in information and communications technologies, 746 encompassing storage, processing, transfer, display, 747 management, organization, and retrieval of information. 748 Example: [A3092]. 749 - Accredited Standards Committee X9: Develops, establishes, 750 maintains, and promotes standards for the financial services 751 industry. Example: [A9009]. 752 - Alliance for Telecommunications Industry Solutions (ATIS): 753 Develops standards, specifications, guidelines, requirements, 754 technical reports, industry processes, and verification tests 755 for interoperability and reliability of telecommunications 756 networks, equipment, and software. Example: [A1523]. 758 $ Anderson report 759 (O) A 1972 study of computer security that was written by James P. 760 Anderson for the U.S. Air Force [Ande]. 762 Tutorial: Anderson collaborated with a panel of experts to study 763 Air Force requirements for multilevel security. The study 764 recommended research and development that was urgently needed to 765 provide secure information processing for command and control 766 systems and support systems. The report introduced the reference 767 monitor concept and provided development impetus for computer and 768 network security technology. However, many of the security 769 problems that the 1972 report called "current" still plague 770 information systems today. 772 $ anomaly detection 773 (I) A intrusion detection method that searches for activity that 774 is different from the normal behavior of system entities and 775 system resources. (Compare: misuse detection. See: IDS.) 777 $ anonymity 778 (I) The condition of having a name that is unknown or concealed. 779 (Compare: privacy. See: alias, anonymizer, anonymous credential, 780 anonymous login, persona certificate.) 782 Tutorial: An application may require security services that 783 maintain anonymity of users or other system entities, perhaps to 784 preserve their privacy or hide them from attack. To hide an 785 entity's real name, an alias may be used. For example, a financial 786 institution may assign an account number. Parties to a transaction 787 can thus remain relatively anonymous, but can also accept the 788 transaction as legitimate. Real names of the parties cannot be 789 easily determined by observers of the transaction, but an 790 authorized third party may be able to map an alias to a real name, 791 such as by presenting the institution with a court order. In other 792 applications, anonymous entities may be completely untraceable. 794 $ anonymizer 795 (I) A internetwork service, usually provided via a proxy server, 796 that provides anonymity and privacy for clients. That is, the 797 service enables a client to access servers without allowing the 798 anyone to gather information about which servers the client 799 accesses and without allowing the accessed servers to gather 800 information about the client, such as its IP address. 802 $ anonymous credential 803 (D) /U.S. Government/ An credential that (a) can be used to 804 authenticate a person as having a specific attribute or being a 805 member of a specific group (e.g., military veterans or U.S. 806 citizens) but (b) does not reveal the individual identity of the 807 person that presents the credential. [M0404] 809 Deprecated term: ISDs SHOULD NOT use this term; it mixes concepts 810 in a potentially misleading way. For example, when the credential 811 is an X.509 certificate, the term could be misunderstood to mean 812 that the certificate was signed by a CA that has a persona 813 certificate. Instead, use "attribute certificate", "organizational 814 certificate", or "persona" certificate" depending on what is 815 meant, with additional explanations as needed. 817 $ anonymous login 818 (I) An access control feature (actually, an access control 819 vulnerability) in many Internet hosts that enables users to gain 820 access to general-purpose or public services and resources of a 821 host (such as allowing any user to transfer data using File 822 Transfer Protocol) without having a pre-established, identity- 823 specific account (i.e., user name and password). 825 Tutorial: This feature exposes a system to more threats than when 826 all the users are known, pre-registered entities that are 827 individually accountable for their actions. A user logs in using a 828 special, publicly known user name (e.g., "anonymous", "guest", or 829 "ftp"). To use the public login name, the user is not required to 830 know a secret password and may not be required to input anything 831 at all except the name. In other cases, to complete the normal 832 sequence of steps in a login protocol, the system may require the 833 user to input a matching, publicly known password (such as 834 "anonymous") or may ask the user for an e-mail address or some 835 other arbitrary character string. 837 $ ANSI 838 (I) See: American National Standards Institute. 840 $ anti-jam 841 (N) "Measures ensuring that transmitted information can be 842 received despite deliberate jamming attempts." [C4009] (See: 843 electronic security, frequency hopping, jam, spread spectrum.) 845 $ API 846 (I) See: application programming interface. 848 $ APOP 849 (I) See: POP3 APOP. 851 $ application layer 852 (I) See: Open Systems Interconnection Reference Model (OSIRM). 854 $ application program 855 (I) A computer program that performs a specific function directly 856 for a user (as opposed to a program that is part of a computer 857 operating system and exists to perform functions in support of 858 application programs). 860 $ archive 861 1a. (I) /noun/ A collection of data that is stored for a 862 relatively long period of time for historical and other purposes, 863 such as to support audit service, availability service, or system 864 integrity service. (Compare: backup, repository.) 866 1b. (I) /verb/ To store data in such a way as to create an 867 archive. (Compare: back up.) 869 Tutorial: A digital signature may need to be verified many years 870 after the signing occurs. The CA -- the one that issued the 871 certificate containing the public key needed to verify that 872 signature -- may not stay in operation that long. So every CA 873 needs to provide for long-term storage of the information needed 874 to verify the signatures of those to whom it issues certificates. 876 $ ARPANET 877 (N) Advanced Research Projects Agency (ARPA) Network, a pioneer 878 packet-switched network that was designed, implemented, operated, 879 and maintained by BBN from January 1969 until July 1975 under 880 contract to the U.S. Government; led to the development of today's 881 Internet; and was decommissioned in June 1990. [B4799, Hafn] 883 $ ASCII 884 (I) American Standard Code for Information Interchange, a scheme 885 that encodes 128 specified characters -- the numbers 0-9, the 886 letters a-z and A-Z, some basic punctuation symbols, some control 887 codes that originated with Teletype machines, and a blank space -- 888 into the 7-bit binary numbers. Forms the basis of the character 889 set representations used in most computers and many Internet 890 standards. (See: code.) 892 $ ASN.1 893 (I) See: Abstract Syntax Notation One. 895 $ asset 896 (I) A system resource that is (a) required to be protected by an 897 information system's security policy, (b) intended to be protected 898 by a countermeasure, or (c) required for a system's mission. 900 $ association 901 (I) A cooperative relationship between system entities, usually 902 for the purpose of transferring information between them. (See: 903 security association.) 905 $ assurance 906 See: security assurance. 908 $ assurance level 909 (I) A rank on a hierarchical scale of confidence that a TOE 910 adequately fulfills stated security requirements. (See: assurance, 911 certificate policy, EAL, TCSEC.) 913 Example: U.S. Government guidance [M0404] describes four assurance 914 levels for identity authentication, where each level "describes 915 the [Government] agency~Os degree of certainty that the user has 916 presented [a credential] that refers to [the user's] identity." In 917 that guidance, "assurance is defined as (a) "the degree of 918 confidence in the vetting process used to establish the identity 919 of the individual to whom the credential was issued" and (b) "the 920 degree of confidence that the individual who uses the credential 921 is the individual to whom the credential was issued." The four 922 levels are described as follows: 923 - Level 1: Little or no confidence in the asserted identity. 924 - Level 2: Some confidence in the asserted identity. 925 - Level 3: High confidence in the asserted identity. 926 - Level 4: Very high confidence in the asserted identity. 928 Standards for determining these levels are provided in a NIST 929 publication [SP12]. However, as noted there, an assurance level is 930 "a degree of confidence, not a true measure of how secure the 931 system actually is. This distinction is necessary because it is 932 extremely difficult -- and in many cases virtually impossible -- 933 to know exactly how secure a system is." 935 $ asymmetric cryptography 936 (I) A modern branch of cryptography (popularly known as "public- 937 key cryptography") in which the algorithms use a pair of keys (a 938 public key and a private key) and use a different component of the 939 pair for each of two counterpart cryptographic operations (e.g., 940 encryption and decryption, or signature creation and signature 941 verification). (See: key pair, symmetric cryptography.) 943 Tutorial: Asymmetric algorithms have key management advantages 944 over equivalently strong symmetric ones. First, one key of the 945 pair need not be known by anyone but its owner; so it can more 946 easily be kept secret. Second, although the other key is shared by 947 all entities that use the algorithm, that key need not be kept 948 secret from other, non-using entities; thus, the key distribution 949 part of key management can be done more easily. 951 Asymmetric cryptography can be used to create algorithms for 952 encryption, digital signature, and key agreement: 953 - In an asymmetric encryption algorithm (e.g., see: RSA), when 954 Alice wants to ensure confidentiality for data she sends to 955 Bob, she encrypts the data with a public key provided by Bob. 956 Only Bob has the matching private key that is needed to decrypt 957 the data. (Compare: seal.) 958 - In an asymmetric digital signature algorithm (e.g., see: DSA), 959 when Alice wants to ensure data integrity or provide 960 authentication for data she sends to Bob, she uses her private 961 key to sign the data (i.e., create a digital signature based on 962 the data). To verify the signature, Bob uses the matching 963 public key that Alice has provided. 964 - In an asymmetric key agreement algorithm (e.g., see: Diffie- 965 Hellman), Alice and Bob each send their own public key to the 966 other party. Then each uses their own private key and the 967 other's public key to compute the new key value. 969 $ ATIS 970 (N) See: (Alliance for Telecommunications Industry Solutions 971 under) ANSI. 973 $ attack 974 1. (I) An intentional act by which an entity attempts to evade 975 security services and violate the security policy of a system. 976 That is, an actual assault on system security that derives from an 977 intelligent threat. (See: penetration, violation, vulnerability.) 979 2. (I) A method or technique used in an assault (e.g., 980 masquerade). (See: distributed attack.) 982 Tutorial: Attacks can be characterized according to intent: 983 - An "active attack" attempts to alter system resources or affect 984 their operation. 985 - A "passive attack" attempts to learn or make use of information 986 from the system but does not affect system resources. (E.g., 987 see: wiretapping.) 989 The object of a passive attack might be to obtain data that is 990 needed for an off-line attack. 991 - An "off-line attack" is one in which the attacker obtains data 992 from the target system and then analyzes the data on a 993 different system of the attacker's own choosing, possibly in 994 preparation for a second stage of attack on the target. 996 Attacks can be characterized according to point of initiation: 997 - An "inside attack" is one that is initiated by an entity inside 998 the security perimeter (an "insider"), i.e., an entity that is 999 authorized to access system resources but uses them in a way 1000 not approved by those who granted the authorization. 1001 - An "outside attack" is initiated from outside the perimeter, by 1002 an unauthorized or illegitimate user of the system (an 1003 "outsider"). In the Internet, potential outside attackers range 1004 from amateur pranksters to organized criminals, international 1005 terrorists, and hostile governments. 1007 The term "attack" relates to some other basic security terms as 1008 shown in the following diagram: 1010 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 1011 | An Attack: | |Counter- | | A System Resource: | 1012 | i.e., A Threat Action | | measure | | Target of the Attack | 1013 | +----------+ | | | | +-----------------+ | 1014 | | Attacker |<==================||<========= | | 1015 | | i.e., | Passive | | | | | Vulnerability | | 1016 | | A Threat |<=================>||<========> | | 1017 | | Agent | or Active | | | | +-------|||-------+ | 1018 | +----------+ Attack | | | | VVV | 1019 | | | | | Threat Consequences | 1020 + - - - - - - - - - - - - + + - - - - + + - - - - - - - - - - -+ 1022 $ attack potential 1023 (I) The perceived likelihood of success should an attack be 1024 launched, expressed in terms of the attacker's capability (i.e., 1025 expertise and resources) and motivation. (Compare: threat, risk.) 1027 $ attack sensing, warning, and response 1028 (I) A set of security services that cooperate with audit service 1029 to detect and react to indications of threat actions, including 1030 both inside and outside attacks. (See: indicator.) 1032 $ attack tree 1033 (I) A branching, hierarchical data structure that represents a set 1034 of potential approaches to achieving an event in which system 1035 security is penetrated or compromised in a specified way. [Moor] 1037 Tutorial: Attack trees are special cases of fault trees. The 1038 security incident that is the goal of the attack is represented as 1039 the root node of the tree, and the ways that an attacker could 1040 reach that goal are iteratively and incrementally represented as 1041 branches and subnodes of the tree. Each subnode defines a subgoal, 1042 and each subgoal may have its own set of further subgoals, etc. 1043 The final nodes on the paths outward from the root, i.e., the leaf 1044 nodes, represent different ways to initiate an attack. Each node 1045 other than a leaf is either an AND-node or an OR-node. To achieve 1046 the goal represented by an AND-node, the subgoals represented by 1047 all of that node's subnodes must be achieved; and for an OR-node, 1048 at least one of the subgoals must be achieved. Branches can be 1049 labeled with values representing difficulty, cost, or other attack 1050 attributes, so that alternative attacks can be compared. 1052 $ attribute 1053 1. (N) The information of a particular type concerning an 1054 identifiable system entity or object. An "attribute type" is the 1055 component of an attribute that indicates the class of information 1056 given by the attribute; and an "attribute value" is a particular 1057 instance of the class of information indicated by an attribute 1058 type. (See: attribute certificate.) 1060 $ attribute authority (AA) 1061 1. (I) A CA that issues attribute certificates. 1063 2. (O) "An authority [that] assigns privileges by issuing 1064 attribute certificates." [X509] 1066 Usage: The abbreviation "AA" should not be used in an ISD unless 1067 it is first defined in the ISD. 1069 $ attribute certificate 1070 1. (I) A digital certificate that binds a set of descriptive data 1071 items, other than a public key, either directly to a subject name 1072 or to the identifier of another certificate that is a public-key 1073 certificate. 1075 2. (N) "A data structure, digitally signed by an [a]ttribute 1076 [a]uthority, that binds some attribute values with identification 1077 information about its holder." [X509] 1079 Tutorial: A public-key certificate binds a subject name to a 1080 public key value, along with information needed to perform certain 1081 cryptographic functions. Other attributes of a subject, such as a 1082 security clearance, may be certified in a separate kind of digital 1083 certificate, called an attribute certificate. A subject may have 1084 multiple attribute certificates associated with its name or with 1085 each of its public-key certificates. 1087 An attribute certificate might be issued to a subject in the 1088 following situations: 1089 - Different lifetimes: When the lifetime of an attribute binding 1090 is shorter than that of the related public-key certificate, or 1091 when it is desirable not to need to revoke a subject's public 1092 key just to revoke an attribute. 1093 - Different authorities: When the authority responsible for the 1094 attributes is different than the one that issues the public-key 1095 certificate for the subject. (There is no requirement that an 1096 attribute certificate be issued by the same CA that issued the 1097 associated public-key certificate.) 1099 $ audit 1100 See: security audit. 1102 $ audit log 1103 (I) Synonym for "security audit trail". 1105 $ audit service 1106 (I) A security service that records information needed to 1107 establish accountability for system events and for the actions of 1108 system entities that cause them. (See: security audit.) 1110 $ audit trail 1111 (I) See: security audit trail. 1113 $ AUTH 1114 (I) See: POP3 AUTH. 1116 $ authentic signature 1117 (I) A signature (especially a digital signature) that can be 1118 trusted because it can be verified. (See: validate vs. verify.) 1120 $ authenticate 1121 (I) Verify (i.e., establish the truth of) an identity claimed by 1122 or for a system entity. (See: authentication, validate vs. verify, 1123 ("relationship between data integrity service and authentication 1124 services" under) data integrity service.).) 1126 Deprecated Usage: In general English usage, this term is used with 1127 the meaning "to prove genuine" (e.g., an art expert authenticates 1128 a Michelangelo painting); but this Internet definition restricts 1129 usage as follows: 1130 - ISDs SHOULD NOT use this term to refer to proving or checking 1131 that data has not been changed, destroyed or lost in an 1132 unauthorized or accidental manner. Instead use "verify". 1133 - ISDs SHOULD NOT use this term to refer to proving the truth or 1134 accuracy of a fact or value such as a digital signature. 1135 Instead, use "verify". 1136 - ISDs SHOULD NOT use this term to refer to establishing the 1137 soundness or correctness of a construct, such as a digital 1138 certificate. Instead, use "validate". 1140 $ authentication 1141 (I) The process of verifying an identity claimed by or for a 1142 system entity. (See: authenticate, authentication exchange, 1143 authentication information, credential, data origin 1144 authentication, peer entity authentication, simple authentication, 1145 strong authentication, X.509. Also see: ("relationship between 1146 data integrity service and authentication services" under) data 1147 integrity service.) 1149 Tutorial: An authentication process consists of two steps: 1150 - Identification step: Presenting an identifier to the security 1151 system. (Identifiers should be assigned carefully, because 1152 authenticated identities are the basis for other security 1153 services, such as access control service.) 1154 - Verification step: Presenting or generating authentication 1155 information that acts as evidence to prove the binding between 1156 the claimant and the identifier. (See: verification.) 1158 $ authentication code 1159 (D) Synonym for a checksum based on cryptography. (Compare: 1160 Message Authentication Code.) 1162 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 1163 any form of checksum, cryptographic or not; the term mixes 1164 concepts in a potentially misleading way. Instead, use "checksum", 1165 "error detection code", "hash", "keyed hash", "Message 1166 Authentication Code", or "protected checksum", depending on what 1167 is meant. 1169 The word "authentication" is misleading because the checksum may 1170 be used to perform a data integrity function rather than a data 1171 origin authentication function. The word "code" is misleading 1172 because it suggests either that encoding or encryption is involved 1173 or that the term refers to computer software. 1175 $ authentication exchange 1176 1. (I) A mechanism to verify the identity of an entity by means of 1177 information exchange. 1179 2. (O) "A mechanism intended to ensure the identity of an entity 1180 by means of information exchange." [I7498 Part 2] 1182 $ Authentication Header (AH) 1183 (I) An Internet protocol [R2402] designed to provide 1184 connectionless data integrity service and connectionless data 1185 origin authentication service for IP datagrams, and (optionally) 1186 to provide partial sequence integrity and protection against 1187 replay attacks. (See: IPsec. Compare: ESP.) 1189 Tutorial: Replay protection may be selected by the receiver when a 1190 security association is established. AH authenticates upper-layer 1191 protocol data units and as much of the IP header as possible. 1192 However, some IP header fields may change in transit, and the 1193 value of these fields, when the packet arrives at the receiver, 1194 may not be predictable by the sender. Thus, the values of such 1195 fields cannot be protected end-to-end by AH; protection of the IP 1196 header by AH is only partial when such fields are present. 1198 AH may be used alone, or in combination with the ESP, or in a 1199 nested fashion with tunneling. Security services can be provided 1200 between a pair of communicating hosts, between a pair of 1201 communicating security gateways, or between a host and a gateway. 1202 ESP can provide nearly the same security services as AH, and ESP 1203 can also provide data confidentiality service. The main difference 1204 between authentication services provided by ESP and AH is the 1205 extent of the coverage; ESP does not protect IP header fields 1206 unless they are encapsulated by AH. 1208 $ authentication information 1209 (I) Information used to verify an identity claimed by or for an 1210 entity. (See: authentication, credential, user. Compare: 1211 identification information.) 1213 Tutorial: Authentication information may exist as, or be derived 1214 from, one of the following: (a) Something the entity knows (see: 1215 password); (b) something the entity possesses (see: token); (c) 1216 something the entity is (see: biometric authentication). 1218 $ authentication service 1219 (I) A security service that verifies an identity claimed by or for 1220 an entity. (See: authentication.) 1222 Tutorial: In a network, there are two general forms of 1223 authentication service: data origin authentication service and 1224 peer entity authentication service. 1226 $ authenticity 1227 (I) The property of being genuine and able to be verified and be 1228 trusted. (See: authenticate, authentication, validate vs. verify.) 1230 $ authority 1231 (D) "An entity, responsible for the issuance of certificates." 1232 [X509] 1234 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 1235 attribute authority, certification authority, registration 1236 authority, or similar terms; the shortened form may cause 1237 confusion. Instead, use the full term at the first instance of 1238 usage and then, if it is necessary to shorten text, use AA, CA, 1239 RA, and other abbreviations defined in this Glossary. 1241 $ authority certificate 1242 (D) "A certificate issued to an authority (e.g. either to a 1243 certification authority or to an attribute authority)." [X509] 1244 (See: authority.) 1246 Deprecated Term: ISDs SHOULD NOT use this term as defined here; it 1247 is ambiguous. Instead, use the full term "certification authority 1248 certificate", "attribute authority certificate", "registration 1249 authority certificate", etc. at the first instance of usage and 1250 then, if it is necessary to shorten text, use AA, CA, RA, and 1251 other abbreviations defined in this Glossary. 1253 $ authorization 1254 1a. (I) An approval that is granted to a system entity to access a 1255 system resource. (Compare: permission, privilege.) 1257 Usage: Some synonyms are "permission" and "privilege". Specific 1258 terms are preferred in certain contexts: 1259 - /PKI/ "Authorization" SHOULD be used, to align with 1260 "certification authority" in the standard [X509]. 1261 - /role-based access control/ "Permission" SHOULD be used, to 1262 align with the standard [ANSI]. 1263 - /computer operating systems/ "Privilege" SHOULD be used, to 1264 align with the literature. 1266 Tutorial: The semantics and granularity of authorizations depend 1267 on the application and implementation (see: (first law under) 1268 Courtney's laws). An authorization may specify a particular access 1269 mode -- such as read, write, or execute -- for one or more system 1270 resources. 1272 1b. (I) A process for granting approval to a system entity to 1273 access a system resource. 1275 2. (O) /SET/ "The process by which a properly appointed person or 1276 persons grants permission to perform some action on behalf of an 1277 organization. This process assesses transaction risk, confirms 1278 that a given transaction does not raise the account holder's debt 1279 above the account's credit limit, and reserves the specified 1280 amount of credit. (When a merchant obtains authorization, payment 1281 for the authorized amount is guaranteed -- provided, of course, 1282 that the merchant followed the rules associated with the 1283 authorization process.)" [SET2] 1285 $ authorization credential 1286 (I) See: ("access control" context under) "credential". 1288 $ authorize 1289 (I) Grant an authorization to a system entity. 1291 $ authorized user 1292 (I) /access control/ A system entity that accesses a system 1293 resource for which the entity has received an authorization. 1294 (Compare: insider, outsider, unauthorized user.) 1296 Usage: The term is used in many ways and could easily be 1297 misunderstood; ISD that use this term SHOULD state a definition 1298 for it. 1300 $ automated information system 1301 See: information system. 1303 $ availability 1304 1. (I) The property of a system or a system resource being 1305 accessible, or usable or operational upon demand, by an authorized 1306 system entity, according to performance specifications for the 1307 system; i.e., a system is available if it provides services 1308 according to the system design whenever users request them. (See: 1309 critical, denial of service. Compare: precedence, reliability, 1310 survivability.) 1312 2. (O) "The property of being accessible and usable upon demand by 1313 an authorized entity." [I7498 Part 2] 1315 $ availability service 1316 (I) A security service that protects a system to ensure its 1317 availability. 1319 Tutorial: This service addresses the security concerns raised by 1320 denial-of-service attacks. It depends on proper management and 1321 control of system resources, and thus depends on access control 1322 service and other security services. 1324 $ B1 computer system, B2 computer system, B3 computer system 1325 (O) See: TCSEC. 1327 $ back door 1328 1. (I) /computer security/ A computer system feature -- which may 1329 be (a) an unintentional flaw, (b) a mechanism deliberately 1330 installed by the system's creator, or (c) a mechanism 1331 surreptitiously installed by an intruder -- that provides access 1332 to a system resource by other than the usual procedure and usually 1333 is hidden or otherwise not well-known. (Compare: Trojan Horse. 1334 See: maintenance hook.) 1336 Example: A way to access a computer other than through a normal 1337 login. Such an access path is not necessarily designed with 1338 malicious intent; operating systems sometimes are shipped by the 1339 manufacturer with hidden accounts intended for use by field 1340 service technicians or the vendor's maintenance programmers. 1342 2. (I) /cryptography/ A feature of a cryptographic system that 1343 makes it easily possible to break or circumvent the protection 1344 that the system is designed to provided. 1346 Example: A feature that makes it possible to decrypt cipher text 1347 much more quickly than by brute force cryptanalysis, without 1348 having prior knowledge of the decryption key. 1350 $ back up 1351 (I) /verb/ Create a reserve copy of data (compare: archive) or, 1352 more generally, provide alternate means to perform system 1353 functions despite loss of system resources. (See: contingency 1354 plan.) 1356 $ backup 1357 (I) /noun or adjective/ Refers to alternate means of performing 1358 system functions despite loss of system resources. (See: 1360 contingency plan). 1362 Example: A reserve copy of data, preferably one that is stored 1363 separately from the original, for use if the original becomes lost 1364 or damaged. (Compare: archive.) 1366 $ baggage 1367 (O) /SET/ An "opaque encrypted tuple, which is included in a SET 1368 message but appended as external data to the PKCS encapsulated 1369 data. This avoids superencryption of the previously encrypted 1370 tuple, but guarantees linkage with the PKCS portion of the 1371 message." [SET2] 1373 Deprecated Usage: ISDs SHOULD NOT use this term to describe a data 1374 element, except in the form "SET(trademark) baggage" with the 1375 meaning given above. 1377 $ baked-in security 1378 (I) The inclusion of security mechanisms in an information system 1379 beginning at an early point in the system's life cycle, i.e., 1380 during the design phase, or at least early in the implementation 1381 phase. (Compare: add-on security.) 1383 Deprecated Term: It is likely that other cultures have different 1384 metaphors for this concept. Therefore, to ensure international 1385 understanding, ISDs SHOULD NOT use this term. (See: (Deprecated 1386 Usage under) Green Book.) 1388 $ bandwidth 1389 (I) The total width of the frequency band that is available to or 1390 used by a communication channel; usually expressed in Hertz (Hz). 1391 [R3753] (Compare: channel capacity.) 1393 $ bank identification number (BIN) 1394 1. (O) The digits of a credit card number that identify the 1395 issuing bank. (See: primary account number.) 1397 2. (O) /SET/ The first six digits of a primary account number. 1399 $ Basic Encoding Rules (BER) 1400 (I) A standard for representing ASN.1 data types as strings of 1401 octets. [X690] (See: Distinguished Encoding Rules.) 1403 Usage: Sometimes incorrectly included under the term ASN.1, which 1404 properly refers only to the syntax description language, and not 1405 to the encoding rules for the language. 1407 $ Basic Security Option 1408 (I) See: (secondary definition under) IPSO. 1410 $ bastion host 1411 (I) A strongly protected computer that is in a network protected 1412 by a firewall (or is part of a firewall) and is the only host (or 1413 one of only a few) in the network that can be directly accessed 1414 from networks on the other side of the firewall. (See: firewall.) 1416 Tutorial: Filtering routers in a firewall typically restrict 1417 traffic from the outside network to reaching just one host, the 1418 bastion host, which usually is part of the firewall. Since only 1419 this one host can be directly attacked, only this one host needs 1420 to be very strongly protected, so security can be maintained more 1421 easily and less expensively. However, to allow legitimate internal 1422 and external users to access application resources through the 1423 firewall, higher layer protocols and services need to be relayed 1424 and forwarded by the bastion host. Some services (e.g., DNS and 1425 SMTP) have forwarding built in; other services (e.g., TELNET and 1426 FTP) require a proxy server on the bastion host. 1428 $ BBN Technologies 1429 (O) The research-and-development company (originally called Bolt 1430 Baranek and Newman, Inc.) that built the ARPANET. 1432 $ BCA 1433 (O) See: brand certification authority. 1435 $ BCR (black/crypto/red) 1436 (N) An experimental, end-to-end, network packet encryption system 1437 developed in a working prototype form by BBN and the Collins Radio 1438 division of Rockwell Corporation in the 1975-1980 time frame for 1439 the U.S. DoD. BCR was the first network security system to support 1440 TCP/IP traffic, and it incorporated the first DES chips that were 1441 validated by the U.S. National Bureau of Standards (now called 1442 NIST). BCR also was the first to use a KDC and an ACC to manage 1443 connections. 1445 $ BCI 1446 (O) See: brand CRL identifier. 1448 $ Bell-LaPadula model 1449 (N) A formal, mathematical, state-transition model of 1450 confidentiality policy for multilevel-secure computer systems 1451 [Bell]. (Compare: Biba model, Brewer-Nash model.) 1453 Tutorial: The model, devised by David Bell and Leonard LaPadula at 1454 The MITRE Corporation in 1973, characterizes computer system 1455 elements as subjects and objects. To determine whether or not a 1456 subject is authorized for a particular access mode on an object, 1457 the clearance of the subject is compared to the classification of 1458 the object. The model defines the notion of a "secure state", in 1459 which the only permitted access modes of subjects to objects are 1460 in accordance with a specified security policy. It is proven that 1461 each state transition preserves security by moving from secure 1462 state to secure state, thereby proving that the system is secure. 1463 In this model, a multilevel-secure system satisfies several rules, 1464 including the "confinement property" (also called "*-property", 1465 pronounced "star property"), the "simple security property", and 1466 the "tranquillity property". 1468 $ benign 1469 (N) "Condition of cryptographic data [such] that [it] cannot be 1470 compromised by human access [to the data]." [C4009] 1472 $ benign fill 1473 (N) Process by which keying material is generated, distributed, 1474 and placed into an ECU without exposure to any human or other 1475 system entity, except the cryptographic module that consumes and 1476 uses the material. 1478 $ BER 1479 (I) See: Basic Encoding Rules. 1481 $ beyond A1 1482 1. (O) /formal/ A level of security assurance that is beyond the 1483 highest level (level A1) of criteria specified by the TCSEC. 1485 2. (O) /informal/ A level of trust so high that it is beyond 1486 state-of-the-art technology; i.e., it cannot be provided or 1487 verified by currently available assurance methods, and especially 1488 not by currently available formal methods. 1490 $ Biba model 1491 (N) A formal, mathematical, state-transition model of integrity 1492 policy for multilevel-secure computer systems [Biba]. (Compare: 1493 Bell-LaPadula model.) 1495 Tutorial: This model for integrity control is analogous to the 1496 Bell-LaPadula model for confidentiality control. Each subject and 1497 object is assigned an integrity level and, to determine whether or 1498 not a subject is authorized for a particular access mode on an 1499 object, the integrity level of the subject is compared to that of 1500 the object. The model prohibits the changing of information in an 1501 object by a subject with a lesser or incomparable level. The rules 1502 of the Biba model are duals of the corresponding rules in the 1503 Bell-LaPadula model. 1505 $ billet 1506 (N) A position or assignment that can be filled by one system 1507 entity at a time. [JCSP1] (Compare: principal, role, user.) 1509 Tutorial: In an organization, a "billet" is a populational 1510 position, of which there is exactly one instance; but a "role" is 1511 functional position, of which there can be multiple instances. 1512 System entities are in one-to-one relationships with their 1513 billets, but may be in many-to-one and one-to-many relationships 1514 with their roles. 1516 $ BIN 1517 (O) See: bank identification number. 1519 $ bind 1520 (I) To inseparably associate by applying some mechanism. 1522 Example: A CA uses a digital signature to bind together (a) a 1523 subject and (b) a public key, and possibly some additional, 1524 secondary data items, to create a public-key certificate. 1526 $ biometric authentication 1527 (I) A method of generating authentication information for a person 1528 by digitizing measurements of a physical or behavioral 1529 characteristic, such as a fingerprint, hand shape, retina pattern, 1530 voiceprint, handwriting style, or face. 1532 $ birthday attack 1533 (I) A class of attacks against cryptographic functions, including 1534 both encryption functions and hash functions. The attacks take 1535 advantage of a statistical property: Given a cryptographic 1536 function having an N-bit output, the probability is greater than 1537 1/2 that for 2**(N/2) randomly chosen inputs, the function will 1538 produce at least two outputs that are identical. (See: (discussion 1539 under) hash function.) 1541 Derivation: From the somewhat surprising fact (often called the 1542 "birthday paradox") that although there are 365 days in a year, 1543 the probability is greater than 1/2 that two of more people share 1544 the same birthday in any randomly chosen group of 23 people. 1546 $ bit 1547 (I) A contraction of the term "binary digit", the smallest unit of 1548 information storage, which has two possible states or values that 1549 are usually represented by the symbols "0" (zero) and "1" (one). 1550 (See: block, byte, word.) 1552 $ bit string 1553 (I) A sequence of bits, each of which is either "0" or "1". 1555 $ BLACK 1556 1. (I) Designation for data that consists only of cipher text, and 1557 for information system equipment items or facilities that handle 1558 only cipher text. Example: "BLACK key".(Compare: RED. See: color 1559 change, RED/BLACK separation.) 1561 2. (O) /U.S. Government/ "Designation applied to information 1562 systems, and to associated areas, circuits, components, and 1563 equipment, in which national security information is encrypted or 1564 is not processed. [C4009] 1566 $ BLACK key 1567 (I) A key that is protected with a key-encrypting key and that 1568 must be decrypted before use. (Compare: RED key. See: BLACK.) 1570 $ BLACKER 1571 (N) An end-to-end encryption system for computer data networks 1572 that was developed by the U.S. DoD in the 1980s to provide host- 1573 to-host data confidentiality service for datagrams at OSIRM layer 1574 3. [Weis] (Compare: Caneware, IPsec.) 1576 Tutorial: Each user host connects to its own bump-in-the-wire 1577 encryption device called a BLACKER Front End (BFE, TSEC/KI-111), 1578 through which the host connects to the subnetwork. The system also 1579 includes two types of centralized devices: one or more KDCs 1580 connect to the subnetwork and communicate with assigned sets of 1581 BFEs, and one or more ACCs connect to the subnetwork and 1582 communicate with assigned KDCs. BLACKER uses only symmetric 1583 encryption. A KDC distributes session keys to BFE pairs as 1584 authorized by an ACC. Each ACC maintains a database for a set of 1585 BFEs, and the database determines which pairs from that set (i.e., 1586 which pairs of user hosts behind the BFEs) are authorized to 1587 communicate and at what security levels. 1589 The BLACKER system is MLS in three ways: (a) The BFEs form a 1590 security perimeter around a subnetwork, separating user hosts from 1591 the subnetwork, so that the subnetwork can operate at a different 1592 security level (possibly a lower, less expensive level) than the 1593 hosts. (b) The BLACKER components are trusted to separate 1594 datagrams of different security levels, so that each datagram of a 1595 given security level can be received only by a host that is 1596 authorized for that security level; and thus BLACKER can separate 1597 host communities that operate at different security levels. (c) 1598 The host side of a BFE is itself MLS and can recognize a security 1599 label on each packet, so that an MLS user host can be authorized 1600 to successively transmit datagrams that are labeled with different 1601 security levels. 1603 $ block 1604 (I) A bit string or bit vector of finite length. (See: block 1605 cipher. Compare: byte, word.) 1607 Usage: An "N-bit block" contains N bits, which usually are 1608 numbered from left to right as 1, 2, 3, ..., N. 1610 $ block cipher 1611 (I) An encryption algorithm that breaks plain text into fixed-size 1612 segments and uses the same key to transform each plaintext segment 1613 into a fixed-size segment of cipher text. Examples: Blowfish, DEA, 1614 IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream 1615 cipher.) 1617 Tutorial: A block cipher can be adapted to have a different 1618 external interface, such as that of a stream cipher, by using a 1619 mode of operation to "package" the basic algorithm. 1621 $ Blowfish 1622 (N) A symmetric block cipher with variable-length key (32 to 448 1623 bits) designed in 1993 by Bruce Schneier as an unpatented, 1624 license-free, royalty-free replacement for DES or IDEA. [Schn] 1626 $ brand 1627 1. (I) A distinctive mark or name that identifies a product or 1628 business entity. 1630 2. (O) /SET/ The name of a payment card. 1632 Tutorial: Financial institutions and other companies have founded 1633 payment card brands, protect and advertise the brands, establish 1634 and enforce rules for use and acceptance of their payment cards, 1635 and provide networks to interconnect the financial institutions. 1636 These brands combine the roles of issuer and acquirer in 1637 interactions with cardholders and merchants. [SET1] 1639 $ brand certification authority (BCA) 1640 (O) /SET/ A CA owned by a payment card brand, such as MasterCard, 1641 Visa, or American Express. [SET2] (See: certification hierarchy, 1642 SET.) 1644 $ brand CRL identifier (BCI) 1645 (O) /SET/ A digitally signed list, issued by a BCA, of the names 1646 of CAs for which CRLs need to be processed when verifying 1647 signatures in SET messages. [SET2] 1649 $ break 1650 (I) /cryptography/ To successfully perform cryptanalysis and thus 1651 succeed in decrypting data or performing some other cryptographic 1652 function, without initially having knowledge of the key that the 1653 function requires. (See: penetrate.) 1655 Usage: This term applies to encrypted data or, more generally, to 1656 a cryptographic algorithm or cryptographic system. 1658 $ Brewer-Nash model 1659 (N) A security model [BN89] to enforce the Chinese wall policy. 1660 (Compare: Bell-LaPadula model, Clark-Wilson model.) 1662 Tutorial: All proprietary information in the set of commercial 1663 firms F(1), F(2), ..., F(N) is categorized into mutually exclusive 1664 conflict-of-interest classes I(1), I(2), ..., I(M) that apply 1665 across all firms. Each firm belongs to exactly one class. The 1666 Brewer-Nash model has the following mandatory rules: 1667 - Brewer-Nash Read Rule: Subject S can read information object O 1668 from firm F(i) only if either (a) O is from the same firm as 1669 some object previously read by S *or* (b) O belongs to a class 1670 I(i) from which S has not previously read any object. (See: 1671 object, subject.) 1673 - Brewer-Nash Write Rule: Subject S can write information object 1674 O to firm F(i) only if (a) S can read O by the Brewer-Nash Read 1675 Rule *and* (b) no object can be read by S from a different firm 1676 F(j), no matter whether F(j) belongs to the same class as F(i) 1677 or to a different class. 1679 $ bridge 1680 (I) A gateway for traffic flowing at OSIRM layer 2 between two 1681 networks (usually two LANs). (Compare: router, bridge CA.) 1683 $ bridge CA 1684 (I) A PKI consisting of only a CA that cross-certifies with CAs of 1685 some other PKIs. (See: cross-certification. Compare: bridge.) 1687 Tutorial: A bridge CA functions as a hub that enables a 1688 certificate user in any of the PKIs that attach to the bridge, to 1689 validate certficates issued in the other attached PKIs. 1691 For example, a bridge CA (BCA) CA1 1692 could cross-certify with four ^ 1693 PKIs that have the roots CA1, | 1694 CA2, CA3, and CA4. The cross- v 1695 certificates that the roots CA2 <-> BCA <-> CA3 1696 exchange with the BCA enable an ^ 1697 end entity EE1 certified under | 1698 under CA1 in PK1 to construct v 1699 a certification path needed to CA4 1700 validate the certificate of 1701 end entity EE2 under CA2, CA1 -> BCA -> CA2 -> EE2 1702 or vice versa. CA2 -> BCA -> CA1 -> EE1 1704 $ British Standard 7799 1705 (N) Part 1 of the standard is a code of practice for how to secure 1706 an information system. Part 2 specifies the management framework, 1707 objectives, and control requirements for information security 1708 management systems. [BS7799] (See: ISO 17799.) 1710 $ browser 1711 (I) An client computer program that can retrieve and display 1712 information from servers on the World Wide Web. Examples: 1713 Netscape's Navigator and Microsoft's Internet Explorer. 1715 $ brute force 1716 (I) A cryptanalysis technique or other kind of attack method 1717 involving an exhaustive procedure that tries a large number of 1718 possible solutions to the problem, one-by-one. 1720 Tutorial: In some cases, brute force involves trying all of the 1721 possibilities. For example, for cipher text where the analyst 1722 already knows the decryption algorithm, a brute force technique 1723 for finding matching plain text is to decrypt the message with 1724 every possible key. In other cases, brute force involves trying a 1725 large number of possibilities but substantially fewer than all of 1726 them. For example, given a hash function that produces a N-bit 1727 hash result, the probability is greater than 1/2 that the analyst 1728 will find two inputs that have the same hash result after trying 1729 only 2**(N/2) random chosen inputs. (See: birthday attack.) 1731 $ BS7799 1732 (N) See: British Standard 7799. 1734 $ buffer overflow 1735 (I) Any attack technique that exploits a vulnerability resulting 1736 from computer software or hardware that does not check for 1737 exceeding the bounds of a storage area when data is written into a 1738 sequence of storage locations beginning in that area. 1740 Tutorial: By causing a normal system operation to write data 1741 beyond the bounds of a storage area, the attacker seeks to either 1742 disrupt system operation or cause the system to execute malicious 1743 software inserted by the attacker. 1745 $ buffer zone 1746 (I) A neutral internetwork segment used to connect other segments 1747 that each operate under a different security policy. 1749 Tutorial: To connect a private network to the Internet or some 1750 other relatively public network, one could construct a small, 1751 separate, isolated LAN and connect it to both the private network 1752 and the public network; one or both of the connections would 1753 implement a firewall to limit the traffic that could pass through 1754 the buffer zone. 1756 $ bulk encryption 1757 (N) "Simultaneous encryption of all channels of a multichannel 1758 telecommunications link." [C4009] (Compare: bulk keying material.) 1760 $ bulk key 1761 (D) In a few published descriptions of hybrid encryption for SSH, 1762 Windows 2000, and other applications, this term refers to a 1763 symmetric key that (a) is used to encrypt a relatively large 1764 amount of data and (b) is itself encrypted with a public key. 1765 Example: To send a large file to Bob, Alice (a) generates a 1766 symmetric key and uses it to encrypt the file (i.e., encrypt the 1767 bulk of the information that is to be sent) and then (b) encrypts 1768 that symmetric key (the "bulk key") with Bob's public key. 1770 Deprecated Term: ISDs SHOULD NOT use this term or definition; they 1771 are not well-established and could be confused with the 1772 established term "bulk keying material". Instead, use "symmetric 1773 key" and carefully explain how the key is applied. 1775 $ bulk keying material 1776 (O) Refers to handling keying material in large quantities, e.g., 1777 as a dataset that contains many items of keying material. (See: 1778 type 0. Compare: bulk key, bulk encryption.) 1780 $ bump-in-the-stack 1781 (I) An implementation approach that places a network security 1782 mechanism inside the system that is to be protected. (Compare: 1783 bump-in-the-wire.) 1785 Example: IPsec can be implemented inboard, in the protocol stack 1786 of an existing system or existing system design, by placing a new 1787 layer placed between the existing IP layer and the OSIRM layer 3 1788 drivers. Source code access for the existing stack is not 1789 required, but the system that contains the stack does need to be 1790 modified [R1401]. 1792 $ bump-in-the-wire 1793 (I) An implementation approach that places a network security 1794 mechanism outside of the system that is to be protected. (Compare: 1795 bump-in-the-stack.) 1797 Example: IPsec can be implemented outboard, in a physically 1798 separate device, so that the system that receives the IPsec 1799 protection does not need to be modified at all [R1401]. Military- 1800 grade link encryption has mainly been implemented as bump-in-the- 1801 wire devices. 1803 $ byte 1804 (I) A fundamental unit of computer storage; the smallest 1805 addressable unit in a computer's architecture. Usually holds one 1806 character of information and, today, usually means eight bits. 1807 (Compare: octet.) 1809 Usage: Understood to be larger than a "bit", but smaller than a 1810 "word". Although "byte" almost always means "octet" today, some 1811 computer architectures have had bytes in other sizes (e.g., six 1812 bits, nine bits). Therefore, an STD SHOULD state the number of 1813 bits in a byte where the term is first used in the STD. 1815 $ C field 1816 (D) See: Compartments field. 1818 $ C1 computer system, C2 computer system 1819 (O) See: TCSEC. 1821 $ CA 1822 (I) See: certification authority. 1824 $ CA certificate 1825 (D) "A [digital] certificate for one CA issued by another CA." 1826 [X509] 1828 Deprecated Definition: An ISD that uses the term SHOULD state 1829 precisely how the certificate is constructed and how it is 1830 intended to be used; the X.509 definition is ambiguous with regard 1831 to those details. (See: certificate profile.) 1833 - Constraints: A v3 X.509 public-key certificate may have a 1834 "basicConstraints" extension containing a "cA" value of "TRUE" 1835 that specifically indicates that "the certified public key may 1836 be used to verify certificate signatures." 1837 - Key Usage: A v3 X.509 public-key certificate also may have a 1838 "key Usage" extension which indicates the purposes for which 1839 the public key may be used. One purpose is "keyCertSign", for 1840 verifying a CA's signature on certificates; and if this value 1841 is present, than "cA" is also set to "TRUE" if the certificate 1842 also has a "basicConstraints" extension. 1844 However, a CA could be issued a certificate in which "keyCertSign" 1845 is asserted without "basicConstraints" being present; and an 1846 entity that acts as a CA could be issued a certificate with 1847 "keyUsage" set to other values, either with or without 1848 "keyCertSign". 1850 $ Caesar cipher 1851 (I) A cipher that, given an alphabet of N characters, A(1), A(2), 1852 character A(i) by A(i+K, mod N) for some 0 One-To-Many, <=> Many-to-Many. 6210 +- - - - - - - - - - - - - - - - - - - - - - - - - - + 6211 | PKI System | 6212 + - - - - + | +------------------+ +-------------------------+ | 6213 | User | | | Subscriber, i.e. | | Subscriber Identity | | 6214 | +-----+ | | | Registered User | | | | 6215 | |Human| | | |(Is System-Unique)| | (Is System-Unique) | | 6216 | |Being| | | | +--------------+ | | +---------------------+ | | 6217 | +-----+ | | | | User's Core | | | | Subscriber | | | 6218 | ^ |===| | Registration | |==>| | Identity's | | | 6219 | | | | | | Data, i.e., | | | | Registration Data | | | 6220 | | | | | | An Entity's | | | |+-------------------+| | | 6221 | v | | | |Distinguishing|========| Same Core Data || | | 6222 | +-----+ | | | | Attribute | | | ||For All Identities || | | 6223 | | Set | | | | | Values | | +===|| Of The Same User || | | 6224 | +-----+ | | | +--------------+ | | | |+-------------------+| | | 6225 | ^ | | +------------------+ | | +---------------------+ | | 6226 | | | | | +=======+ +------------|------------+ | 6227 | | | | +-------v----|----------------------|------------+ | 6228 | v | | | +----------v-----+ +------------v----------+ | | 6229 | +-----+ | | | | Authentication |<=>| Subscriber Identifier | | | 6230 | |Auto-| | | | | Information | | (Is System Unique) | | | 6231 | |mated| | | | +----------------+ +-----------------------+ | | 6232 | |Pro- | | | | Identity Credential | | 6233 | |cess | | | |(Associates Authentication Info. and Identifier)| | 6234 | +-----+ | | +------------------------------------------------+ | 6235 + - - - - + + - - - - - - - - - - - - - - - - - - - - - - - - - -+ 6237 An ISD may apply this term to a user that is an individual entity 6238 or one that is a set. If an ISD involves both meanings, the ISD 6239 SHOULD use the following definitions to avoid ambiguity: 6240 - "Singular identity": An identity that is registered for a user 6241 that is exactly one person or one process. 6242 - "Shared identity": An identity that is registered for a user 6243 that is a set of entities of which each member is authorized to 6244 assume the identity individually and for which the registering 6245 system maintains a record of the singular entities that 6246 comprise the set. In this case, we would expect each member 6247 entity to be registered with a singular identity. 6248 - "Group identity": An identity that is registered for a user 6249 that is a set of entities for which the registering system does 6250 not maintain a record of the singular entities that comprise 6251 the set. 6253 $ identity-based security policy 6254 (I) "A security policy based on the identities and/or attributes 6255 of users, a group of users, or entities acting on behalf of the 6256 users and the resources/objects being accessed." [I7498 Part 2] 6257 (See: rule-based security policy.) 6259 $ identity credential 6260 1. (I) See: ("authentication" context under) "credential". 6262 2. (I) Synonym for "signature certificate. 6264 Usage: The term is used in many ways and could easily be 6265 misunderstood; therefore, ISDs that use this term SHOULD state a 6266 definition for it. 6268 $ identity proofing 6269 (I) A process that vets and verifies the information that is used 6270 to establish the identity of a system entity. 6272 $ IDS 6273 (I) See: intrusion detection system. 6275 $ IEEE 6276 (N) See: Institute of Electrical and Electronics Engineers, Inc. 6278 $ IEEE 802.10 6279 (N) An IEEE committee developing security standards for local area 6280 networks. (See: SILS.) 6282 $ IEEE P1363 6283 (N) An IEEE working group, Standard for Public-Key Cryptography, 6284 engaged in developing a comprehensive reference standard for 6285 asymmetric cryptography. Covers discrete logarithm (e.g., DSA), 6286 elliptic curve, and integer factorization (e.g., RSA); and covers 6287 key agreement, digital signature, and encryption. 6289 $ IESG 6290 (I) See: Internet Engineering Steering Group. 6292 $ IETF 6293 (I) See: Internet Engineering Task Force. 6295 $ IKE 6296 (I) See: IPsec Key Exchange. 6298 $ IMAP4 6299 (I) See: Internet Message Access Protocol, version 4. 6301 $ IMAP4 AUTHENTICATE 6302 (I) A IMAP4 "command" (better described as a transaction type, or 6303 a protocol-within-a-protocol) by which an IMAP4 client optionally 6304 proposes a mechanism to an IMAP4 server to authenticate the client 6305 to the server and provide other security services. (See: POP3.) 6307 Tutorial: If the server accepts the proposal, the command is 6308 followed by performing a challenge-response authentication 6309 protocol and, optionally, negotiating a protection mechanism for 6310 subsequent POP3 interactions. The security mechanisms that are 6311 used by IMAP4 AUTHENTICATE -- including Kerberos, GSSAPI, and 6312 S/Key -- are described in [R1731]. 6314 $ in the clear 6315 (I) Not encrypted. (See: clear text.) 6317 $ Ina Jo 6318 (O) A methodology, language, and integrated set of software tools 6319 developed at the System Development Corporation for specifying, 6320 coding, and verifying software to produce correct and reliable 6321 programs. Also known as the Formal Development Methodology. [Cheh] 6323 $ incapacitation 6324 (I) A type of threat action that prevents or interrupts system 6325 operation by disabling a system component. (See: disruption.) 6327 Usage: This type includes the following subtypes: 6328 - "Malicious logic": In context of incapacitation, any hardware, 6329 firmware, or software (e.g., logic bomb) intentionally 6330 introduced into a system to destroy system functions or 6331 resources. (See: (main entry for) malicious logic.) 6332 - "Physical destruction": Deliberate destruction of a system 6333 component to interrupt or prevent system operation. 6334 - "Human error": In context of incapacitation, action or inaction 6335 that unintentionally disables a system component. 6336 - "Hardware or software error": In context of incapacitation, 6337 error that unintentionally causes failure of a system component 6338 and leads to disruption of system operation. 6339 - "Natural disaster": In context of incapacitation, any "act of 6340 God" (e.g., fire, flood, earthquake, lightning, or wind) that 6341 disables a system component. [FP031 section 2] 6343 $ incident 6344 See: security incident. 6346 $ INCITS 6347 See: (International Committee for Information Technology 6348 Standardization under) ANSI. 6350 $ indicator 6351 (N) An action -- either specific, generalized, or theoretical -- 6352 that an adversary might be expected to take in preparation for an 6353 attack. [C4009] (See: attack sensing, warning, and response.) 6355 $ indirect certificate revocation list (ICRL) 6356 (N) In X.509, a CRL that may contain certificate revocation 6357 notifications for certificates issued by CAs other than the issuer 6358 (i.e., signer) of the ICRL. 6360 $ indistinguishability 6361 (I) An attribute of an encryption algorithm that is a 6362 formalization of the notion that the encryption of some string is 6363 indistinguishable from the encryption of an equal-length string of 6364 nonsense. (Compare: semantic security.) 6366 $ inference 6367 1. (I) A type of threat action that reasons from characteristics 6368 or byproducts of communication and thereby indirectly accesses 6369 sensitive data, but not necessarily the data contained in the 6370 communication. (See: traffic analysis, signal analysis.) 6372 2. (I) A type of threat action that indirectly gains unauthorized 6373 access to sensitive information in a database management system by 6374 correlating query responses with information that is already 6375 known. 6377 $ inference control 6378 (I) Protection of data confidentiality against inference attack. 6379 (See: traffic-flow confidentiality.) 6381 Tutorial: A database management system containing N records about 6382 individuals may be required to provide statistical summaries about 6383 subsets of the population, while not revealing sensitive 6384 information about a single individual. An attacker may try to 6385 obtain sensitive information about an individual by isolating a 6386 desired record at the intersection of a set of overlapping 6387 queries. A system can attempt to prevent this by restricting the 6388 size and overlap of query sets, distorting responses by rounding 6389 or otherwise perturbing database values, and limiting queries to 6390 random samples. However, these techniques may be impractical to 6391 implement or use, and no technique is totally effective. For 6392 example, restricting the minimum size of a query set -- that is, 6393 not responding to queries for which there are fewer than K or more 6394 than N-K records that satisfy the query -- usually cannot prevent 6395 unauthorized disclosure. An attacker can pad small query sets with 6396 extra records, and then remove the effect of the extra records. 6397 The formula for identifying the extra records is called the 6398 "tracker". [Denns] 6400 $ INFOCON 6401 (O) See: information operations condition 6403 $ informal 6404 (N) Expressed in natural language. [CCIB] (Compare: formal, 6405 semiformal.) 6407 $ information 6408 (I) Facts and ideas, which can be represented (encoded) as various 6409 forms of data. 6411 $ information assurance 6412 (N) /U.S. Government/ "Measures that protect and defend 6413 information and information systems by ensuring their availability 6414 integrity, authentication, confidentiality, and non-repudiation. 6415 These measures include providing for restoration of information 6416 systems by incorporating protection, detection, and reaction 6417 capabilities." [C4009] 6419 $ Information Assurance Technical Framework (IATF) 6420 (O) A publicly available document [IATF], developed through a 6421 collaborative effort by organizations in the U.S. Government and 6422 industry, and issued by NSA. Intended for security managers and 6423 system security engineers as a tutorial and reference document 6424 about security problems in information systems and networks, to 6425 improve awareness of tradeoffs among available technology 6426 solutions and of desired characteristics of security approaches 6427 for particular problems. (See: ISO 17799, [SP14].) 6429 $ information domain 6430 (O) See: (secondary definition under) domain. 6432 $ information domain security policy 6433 (O) See: (secondary definition under) domain. 6435 $ information flow policy 6436 (N) /formal model/ A triple consisting of a set of security 6437 levels (or their equivalent security labels), a binary operator 6438 that maps each pair of security levels into a security level, and 6439 a binary relation on the set that selects a set of pairs of levels 6440 such that information is permitted to flow from an object of the 6441 first level to an object of the second level. (See: flow control, 6442 lattice model.) 6444 $ information operations condition (INFOCON) 6445 (O) /U.S. DoD/ A comprehensive defense posture and response based 6446 on the status of information systems, military operations, and 6447 intelligence assessments of adversary capabilities and intent. 6448 (See: threat) 6450 Derivation: From DEFCON, i.e., defense condition. 6452 Tutorial: The U.S. DoD INFOCON levels are: NORMAL (normal 6453 activity), ALPHA (increased risk of attack), BRAVO (specific risk 6454 of attack), CHARLIE (limited attack), and DELTA (general attack). 6456 $ information security (INFOSEC) 6457 (N) Measures that implement and assure security services in 6458 information systems, including in computer systems (see: COMPUSEC) 6459 and in communication systems (see: COMSEC). 6461 $ information system 6462 (I) An organized assembly of computing and communication resources 6463 and procedures -- i.e., equipment and services, together with 6464 their supporting infrastructure, facilities, and personnel -- that 6465 collect, record, process, store, transport, retrieve, display, 6466 disseminate, or dispose of information to accomplish a specified 6467 set of functions. (See: system entity, system resource.) 6469 $ Information Technology Security Evaluation Criteria (ITSEC) 6470 (N) A Standard [ITSEC] jointly developed by France, Germany, the 6471 Netherlands, and the United Kingdom for use in the European Union; 6472 accommodates a wider range of security assurance and functionality 6473 combinations than the TCSEC. Superseded by the Common Criteria. 6475 $ INFOSEC 6476 (I) See: information security. 6478 $ ingress filtering 6479 (I) A method [R2267] for countering attacks that use packets with 6480 false IP source addresses, by blocking such packets at the 6481 boundary between connected networks. 6483 Tutorial: Suppose network A of an internet service provider (ISP) 6484 includes a filtering router that is connected to customer network 6485 B, and an attacker in B at IP source address "foo" attempts to 6486 send packets with false source address "bar" into A. The false 6487 address may be either fixed or randomly changing, and it may 6488 either be unreachable or be a forged address that legitimately 6489 exists within either B or some other network C. In ingress 6490 filtering, the ISP's router blocks all inbound packet that arrive 6491 from B with a source address that is not within the range of 6492 legitimately advertised addresses for B. This method does not 6493 prevent all attacks that can originate from B, but the actual 6494 source of such attacks can be more easily traced because the 6495 originating network is known. 6497 $ initialization value (IV) 6498 (I) An input parameter that sets the starting state of a 6499 cryptographic algorithm or mode. 6501 Usage: Sometimes called "initialization vector" or "message 6502 indicator", but ISDs SHOULD NOT use these synonyms because they 6503 mix concepts in potentially confusing ways. 6505 Tutorial: An IV can be used to synchronize one cryptographic 6506 process with another; e.g., CBC, CFB, and OFB use IVs. An IV also 6507 can be used to introduce cryptographic variance (see: salt) in 6508 addition to that provided by a key. 6510 $ initialization vector 6511 (D) /cryptographic function/ Synonym for "initialization value". 6513 Deprecated Term: For consistency, ISDs SHOULD NOT use this term in 6514 the context of cryptographic functions. 6516 $ inside attack 6517 (I) See: (secondary definition under) attack. Compare: insider.) 6519 $ insider 6520 1. (I) A user (usually a person) that accesses a system from a 6521 position that is inside the system's security perimeter. (Compare: 6522 authorized user, outsider, unauthorized user.) 6524 Tutorial: An insider has been assigned a role that has more 6525 privileges to access system resources than do some other types of 6526 users, or can access those resources without being constrained by 6527 some access controls that are applied to outside users. For 6528 example, a salesclerk is an insider who has access to the cash 6529 register, but a store customer is an outsider. 6531 The actions performed by an insider in accessing the system may be 6532 either authorized or unauthorized; i.e., an insider may act either 6533 as an authorized user or as an unauthorized user. 6535 2. (O) A person with authorized physical access to the system. 6536 Example: In this sense, an office janitor is an insider, but a 6537 burglar or casual visitor is not. [NRC98] 6539 3. (O) A person with an organizational status that causes the 6540 system or members of the organization to view access requests as 6541 being authorized. Example: In this sense, a purchasing agent is an 6542 insider but a vendor is not. [NRC98] 6544 $ inspectable space 6545 (O) /EMSEC/ "Three-dimensional space surrounding equipment that 6546 process classified and/or sensitive information within which 6547 TEMPEST exploitation is not considered practical or where legal 6548 authority to identify and/or remove a potential TEMPEST 6549 exploitation exists." [C4009] 6551 $ Institute of Electrical and Electronics Engineers, Inc. (IEEE) 6552 (N) The IEEE is a not-for-profit association of approximately 6553 300,000 individual members in 150 countries. The IEEE produces 6554 nearly one third of the world's published literature in electrical 6555 engineering, computers, and control technology; holds hundreds of 6556 major, annual conferences; and maintains more than 800 active 6557 standards, with many more under development. (See: SILS.) 6559 $ integrity 6560 See: data integrity, correctness integrity, source integrity, 6561 system integrity. 6563 $ integrity check 6564 (D) A computation that is part of a mechanism to provide data 6565 integrity service or data origin authentication service. (Compare: 6566 checksum.) 6568 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 6569 "cryptographic hash" or "protected checksum. This term 6570 unnecessarily duplicates the meaning of other, well-established 6571 terms; this term only mentions integrity, even though the intended 6572 service may be data origin authentication; and not every checksum 6573 is cryptographically protected. 6575 $ integrity label 6576 (I) A security label that tells the degree of confidence that may 6577 be placed in the data, and may also tell what countermeasures are 6578 required to be applied to protect the data against from alteration 6579 and destruction. (See: integrity. Compare: classification label.) 6581 $ intelligent threat 6582 (I) A circumstance in which an adversary has the technical and 6583 operational capability to detect and exploit a vulnerability and 6584 also has the demonstrated, presumed, or inferred intent to do so. 6585 (See: threat.) 6587 $ interception 6588 (I) A type of threat action whereby an unauthorized entity 6589 directly accesses sensitive data while the data is traveling 6590 between authorized sources and destinations. (See: unauthorized 6591 disclosure.) 6593 Usage: This type includes the following subtypes: 6594 - "Theft": Gaining access to sensitive data by stealing a 6595 shipment of a physical medium, such as a magnetic tape or disk, 6596 that holds the data. 6597 - "Wiretapping (passive)": Monitoring and recording data that is 6598 flowing between two points in a communication system. (See: 6599 wiretapping.) 6600 - "Emanations analysis": Gaining direct knowledge of communicated 6601 data by monitoring and resolving a signal that is emitted by a 6602 system and that contains the data but is not intended to 6603 communicate the data. (See: emanation.) 6605 $ interference 6606 See: (secondary definition under) obstruction. 6608 $ intermediate CA 6609 (D) The CA that issues a cross-certificate to another CA. [X509] 6610 (See: cross-certification.) 6612 Deprecated Term: ISDs SHOULD NOT use this term because it is not 6613 widely known and mixes concepts in a potentially misleading way. 6614 For example, suppose that end entity 1 ("EE1) is in one PKI 6615 ("PKI1"), end entity 2 ("EE2) is in another PKI ("PKI2"), and the 6616 root in PKI1 ("CA1") cross-certifies the root CA in PKI2 ("CA2"). 6617 Then if EE1 constructs the certification path CA1-to-CA2-to-EE2 to 6618 validate a certificate of EE2, conventional English usage would 6619 describe CA2 as being in the "intermediate" position in that path, 6620 not CA1. 6622 $ internal controls 6623 (I) /computer security/ Functions, features, and technical 6624 characteristics of computer hardware and software, especially of 6625 operating systems. Includes mechanisms to regulate the operation 6626 of a computer system with regard to access control, flow control, 6627 and inference control. (Compare: external controls.) 6629 $ International Data Encryption Algorithm (IDEA) 6630 (N) A patented, symmetric block cipher that uses a 128-bit key and 6631 operates on 64-bit blocks. [Schn] (See: symmetric cryptography.) 6633 $ International Standard 6634 (N) See: (secondary definition under) ISO. 6636 $ International Traffic in Arms Regulations (ITAR) 6637 (O) Rules issued by the U.S. State Department, by authority of the 6638 Arms Export Control Act (22 U.S.C. 2778), to control export and 6639 import of defense articles and defense services, including 6640 information security systems, such as cryptographic systems, and 6641 TEMPEST suppression technology. (See: type 1 product, Wassenaar 6642 Arrangement.) 6644 $ internet, Internet 6645 1. (I) /not capitalized/ The term "internet" is a popular short 6646 synonym for "internetwork". 6648 2. (I) /capitalized/ "The Internet" is the single, interconnected, 6649 worldwide system of commercial, government, educational, and other 6650 computer networks that share the protocol suite specified by the 6651 IAB [R2026] and the name and address spaces managed by the ICANN. 6653 Tutorial: The set of protocols is called the "Internet Protocol 6654 Suite" (IPS). It also is popularly known as "TCP/IP", because TCP 6655 and IP are two of its most important protocols. The IPS makes it 6656 possible for users of any one of the networks in the Internet to 6657 communicate with, or use services located on, any of the other 6658 networks. 6660 Although the Internet does have architectural principles 6661 (described in RFC 1958), no Internet Standard defines a layered 6662 reference model for the IPS that is similar to the OSIRM. However, 6663 Internet community documents do refer (inconsistently) to layers: 6664 application, socket, transport, internetwork, network, data link, 6665 and physical. 6667 Usage: In this Glossary, Internet protocol layers are referred to 6668 by name to avoid confusing them with OSIRM layers, which are 6669 referred to by number. (See: OSI.) 6671 $ Internet Architecture Board (IAB) 6672 (I) A technical advisory group of the ISOC, chartered by the ISOC 6673 Trustees to provide oversight of Internet architecture and 6674 protocols and, in the context of Internet Standards, a body to 6675 which decisions of the IESG may be appealed. Responsible for 6676 approving appointments to the IESG from among nominees submitted 6677 by the IETF nominating committee. [R2026] 6679 $ Internet Assigned Numbers Authority (IANA) 6680 (I) From the early days of the Internet, the IANA was chartered by 6681 the ISOC and the U.S. Government's Federal Network Council to be 6682 the central coordination, allocation, and registration body for 6683 parameters for Internet protocols. Superseded by ICANN. 6685 $ Internet Control Message Protocol (ICMP) 6686 (I) An Internet Standard protocol (RFC 792) that is used to report 6687 error conditions during IP datagram processing and to exchange 6688 other information concerning the state of the IP network. 6690 $ Internet Corporation for Assigned Names and Numbers (ICANN) 6691 (I) The non-profit, private corporation that has assumed 6692 responsibility for the IP address space allocation, protocol 6693 parameter assignment, DNS management, and root server system 6694 management functions formerly performed under U.S. Government 6695 contract by IANA and other entities. 6697 Tutorial: The IPS, as defined by the IETF and the IESG, contains 6698 numerous parameters, such as internet addresses, domain names, 6699 autonomous system numbers, protocol numbers, port numbers, 6700 management information base OIDs, including private enterprise 6701 numbers, and many others. The Internet community requires that the 6702 values used in these parameter fields be assigned uniquely. ICANN 6703 makes those assignments as requested and maintains a registry of 6704 the current values. 6706 ICANN was formed in October 1998, by a coalition of the Internet's 6707 business, technical, and academic communities. The U.S. Government 6708 designated ICANN to serve as the global consensus entity with 6709 responsibility for coordinating four key functions for the 6710 Internet: the allocation of IP address space, the assignment of 6711 protocol parameters, and the management of the DNS and the DNS 6712 root server system. 6714 $ Internet Draft 6715 (I) A working document of the IETF, its areas, and its working 6716 groups. (Other groups may also distribute working documents as 6717 Internet Drafts.) An Internet Draft is not an archival document 6718 like an RFC is. Instead, an Internet Draft is a preliminary or 6719 working document that is valid for a maximum of six months and may 6720 be updated, replaced, or made obsolete by other documents at any 6721 time. It is inappropriate to use an Internet Draft as reference 6722 material or to cite it other than as "work in progress". 6724 $ Internet Engineering Steering Group (IESG) 6725 (I) The part of the ISOC responsible for technical management of 6726 IETF activities and administration of the Internet Standards 6727 Process according to procedures approved by the ISOC Trustees. 6728 Directly responsible for actions along the "standards track", 6729 including final approval of specifications as Internet Standards. 6730 Composed of IETF Area Directors and the IETF chairperson, who also 6731 chairs the IESG. [R2026] 6733 $ Internet Engineering Task Force (IETF) 6734 (I) A self-organized group of people who make contributions to the 6735 development of Internet technology. The principal body engaged in 6736 developing Internet Standards, although not itself a part of the 6737 ISOC. Composed of Working Groups, which are arranged into Areas 6738 (such as the Security Area), each coordinated by one or more Area 6739 Directors. Nominations to the IAB and the IESG are made by a 6740 committee selected at random from regular IETF meeting attendees 6741 who have volunteered. [R2026, R2323] 6743 $ Internet Message Access Protocol, version 4 (IMAP4) 6744 (I) An Internet protocol (RFC 2060) by which a client workstation 6745 can dynamically access a mailbox on a server host to manipulate 6746 and retrieve mail messages that the server has received and is 6747 holding for the client. (See: POP3.) 6749 Tutorial: IMAP4 has mechanisms for optionally authenticating a 6750 client to a server and providing other security services. (See: 6751 IMAP4 AUTHENTICATE.) 6753 $ Internet Open Trading Protocol (IOTP) 6754 (I) An Internet protocol (RFC 2801) proposed as a general 6755 framework for Internet commerce, able to encapsulate transactions 6756 of various proprietary payment systems (e.g., GeldKarte, Mondex, 6757 SET, VisaCash). Provides optional security services by 6758 incorporating various Internet security mechanisms (e.g., MD5) and 6759 protocols (e.g., TLS). 6761 $ Internet Policy Registration Authority (IPRA) 6762 (I) An X.509-compliant CA that is the top CA of the Internet 6763 certification hierarchy operated under the auspices of the ISOC 6764 [R1422]. (See: (PEM usage under) certification hierarchy.) 6766 $ Internet Private Line Interface (IPLI) 6767 (I) A successor to the PLI, updated to use TCP/IP and newer 6768 military-grade COMSEC equipment (TSEC/KG-84). The IPLI was a 6769 portable, modular system that was developed for use in tactical, 6770 packet-radio networks. 6772 $ Internet Protocol (IP) 6773 (I) A Internet Standard protocol (version 4 is specified in RFC 6774 791, and version 6 in RFC 2460) that moves datagrams (discrete 6775 sets of bits) from one computer to another across an internetwork 6776 but does not provide reliable delivery, flow control, sequencing, 6777 or other end-to-end services that TCP provides. (See: IP address, 6778 TCP/IP.) 6780 Tutorial: In the OSIRM, IP would be located at the top of layer 3. 6782 $ Internet Protocol security 6783 See: IPsec. 6785 $ Internet Protocol Security Option (IPSO) 6786 (I) Refers to one of three types of IP security options, which are 6787 fields that may be added to an IP datagram for the purpose of 6788 carrying security information about the datagram. (Compare: 6789 IPsec.) 6791 Deprecated Usage: ISDs SHOULD NOT use this term without a modifier 6792 to indicate which of the following three types is meant. 6793 - "DoD Basic Security Option" (IP option type 130): Defined for 6794 use on U.S. DoD common-use data networks. Identifies the DoD 6795 classification level at which the datagram is to be protected 6796 and the protection authorities whose rules apply to the 6797 datagram. (A "protection authority" is a National Access 6798 Program (e.g., GENSER, SIOP-ESI, SCI, NSA, Department of 6799 Energy) or Special Access Program that specifies protection 6800 rules for transmission and processing of the information 6801 contained in the datagram.) [R1108] 6802 - "DoD Extended Security Option" (IP option type 133): Permits 6803 additional security labeling information, beyond that present 6804 in the Basic Security Option, to be supplied in the datagram to 6805 meet the needs of registered authorities. [R1108] 6806 - "Common IP Security Option" (CIPSO) (IP option type 134): 6807 Designed by TSIG to carry hierarchic and non-hierarchic 6808 security labels. (Formerly called "Commercial IP Security 6809 Option"; a version 2.3 draft was published 9 Mar 1993 as an 6810 Internet-Draft but did not advance to RFC form.) [CIPSO] 6812 $ Internet Protocol Suite (IPS) 6813 (I) See: (secondary definition under) Internet. 6815 $ Internet Security Association and Key Management Protocol (ISAKMP) 6816 (I) An Internet IPsec protocol [R2408] to negotiate, establish, 6817 modify, and delete security associations, and to exchange key 6818 generation and authentication data, independent of the details of 6819 any specific key generation technique, key establishment protocol, 6820 encryption algorithm, or authentication mechanism. 6822 Tutorial: ISAKMP supports negotiation of security associations for 6823 protocols at all TCP/IP layers. By centralizing management of 6824 security associations, ISAKMP reduces duplicated functionality 6825 within each protocol. ISAKMP can also reduce connection setup 6826 time, by negotiating a whole stack of services at once. Strong 6827 authentication is required on ISAKMP exchanges, and a digital 6828 signature algorithm based on asymmetric cryptography is used 6829 within ISAKMP's authentication component. 6831 ISAKMP includes two "phases" of negotiation: the phase 1 6832 negotiation establishes a basic security association to be used 6833 for ISAKMP operations. Then, protected by the phase 1 association, 6834 phase 2 negotiations are used to establish security associations 6835 for other protocols, such as ESP. 6837 $ Internet Society (ISOC) 6838 (I) A professional society concerned with Internet development 6839 (including technical Internet Standards); with how the Internet is 6840 and can be used; and with social, political, and technical issues 6841 that result. The ISOC Board of Trustees approves appointments to 6842 the IAB from among nominees submitted by the IETF nominating 6843 committee. [R2026] 6845 $ Internet Standard 6846 (I) A specification, approved by the IESG and published as an RFC, 6847 that is stable and well-understood, is technically competent, has 6848 multiple, independent, and interoperable implementations with 6849 substantial operational experience, enjoys significant public 6850 support, and is recognizably useful in some or all parts of the 6851 Internet. [R2026] (See: RFC.) 6853 Tutorial: The "Internet Standards Process" is an activity of the 6854 ISOC and is organized and managed by the IAB and the IESG. The 6855 process is concerned with all protocols, procedures, and 6856 conventions used in or by the Internet, whether or not they are 6857 part of the IPS. The "Internet Standards Track" has three levels 6858 of increasing maturity: Proposed Standard, Draft Standard, and 6859 Standard. (Compare: ISO, W3C.) 6861 $ Internet Standards document (ISD) 6862 (I) An RFC or an Internet-Draft that is produced as part of the 6863 Internet Standards Process [R2026]. (See: Internet Standard.) 6865 Deprecated Usage: Neither the term nor the abbreviation is widely 6866 accepted; therefore, ISDs that use this term SHOULD state a 6867 definition for it. 6869 $ internetwork 6870 (I) A system of interconnected networks; a network of networks. 6871 Usually shortened to "internet". (See: internet.) 6873 Tutorial: An internet is usually built using OSIRM layer 3 6874 gateways to connect a set of subnetworks. When the subnetworks 6875 differ in the layer 3 protocol service they provide, the gateways 6876 sometimes implement a uniform internetwork protocol (e.g., IP) 6877 that operates at the top of layer 3 and hides the underlying 6878 heterogeneity from hosts that use communication services provided 6879 by the internet. (See: router.) 6881 $ intranet 6882 (I) A computer network, especially one based on Internet 6883 technology, that an organization uses for its own internal, and 6884 usually private, purposes and that is closed to outsiders. (See: 6886 extranet, virtual private network.) 6888 $ intruder 6889 (I) An entity that gains or attempts to gain access to a system or 6890 system resource without having authorization to do so. (See: 6891 intrusion. Compare: adversary, cracker.) 6893 $ intrusion 6894 1. (I) A security event, or a combination of multiple security 6895 events, that constitutes a security incident in which an intruder 6896 gains, or attempts to gain, access to a system or system resource 6897 without having authorization to do so. (See: IDS.) 6899 2. (I) A type of threat action whereby an unauthorized entity 6900 gains access to sensitive data by circumventing a system's 6901 security protections. (See: unauthorized disclosure.) 6903 Usage: This type includes the following subtypes: 6904 - "Trespass": Gaining physical access to sensitive data by 6905 circumventing a system's protections. 6906 - "Penetration": Gaining logical access to sensitive data by 6907 circumventing a system's protections. 6908 - "Reverse engineering": Acquiring sensitive data by 6909 disassembling and analyzing the design of a system component. 6910 - "Cryptanalysis": Transforming encrypted data into plain text 6911 without having prior knowledge of encryption parameters or 6912 processes. (See: (main Glossary entry for) cryptanalysis.) 6914 $ intrusion detection 6915 (I) Sensing and analyzing system events for the purpose of 6916 noticing (i.e., becoming aware of) attempts to access system 6917 resources in an unauthorized manner. (See: anomaly detection, IDS, 6918 misuse detection.) [IDSAN, IDSSC, IDSSE, IDSSY] 6920 Usage: This includes the following subtypes: 6921 - "Active detection": Real-time or near-real-time analysis of 6922 system event data to detect current intrusions, which result in 6923 an immediate protective response. 6924 - "Passive detection": Off-line analysis of audit data to detect 6925 past intrusions, which are reported to the system security 6926 officer for corrective action. (Compare: security audit.) 6928 $ intrusion detection system (IDS) 6929 1. (N) A process or subsystem, implemented in software or 6930 hardware, that automates the tasks of (a) monitoring events that 6931 occur in a computer network and (b) analyzing them for signs of 6932 security problems. [SP31] (See: intrusion detection.) 6934 2. (N) A security alarm system to detect unauthorized entry. 6935 [DC6/9]. 6937 Tutorial: Active intrusion detection processes can be either host- 6938 based or network-based: 6939 - "Host-based": Intrusion detection components -- traffic sensors 6940 and analyzers -- run directly on the hosts that they are 6941 intended to protect. 6942 - "Network-based": Sensors are placed on subnetwork components, 6943 and analysis components run either on subnetwork components or 6944 hosts. 6946 $ invalidity date 6947 (N) An X.509 CRL entry extension that "indicates the date at which 6948 it is known or suspected that the [revoked certificate's private 6949 key] was compromised or that the certificate should otherwise be 6950 considered invalid." [X509]. 6952 Tutorial: This date may be earlier than the revocation date in the 6953 CRL entry, and may even be earlier than the date of issue of 6954 earlier CRLs. However, the invalidity date is not, by itself, 6955 sufficient for purposes of non-repudiation service. For example, 6956 to fraudulently repudiate a validly-generated signature, a private 6957 key holder may falsely claim that the key was compromised at some 6958 time in the past. 6960 $ IOTP 6961 (I) See: Internet Open Trading Protocol. 6963 $ IP 6964 (I) See: Internet Protocol. 6966 $ IP address 6967 (I) A computer's internetwork address that is assigned for use by 6968 IP and other protocols. 6970 Tutorial: An IP version 4 address (RFC 791) is written as a series 6971 of four 8-bit numbers separated by periods. For example, the 6972 address of the host named "rosslyn.bbn.com" is 192.1.7.10. 6974 An IP version 6 address (RFC 2373) is written as x:x:x:x:x:x:x:x, 6975 where each "x" is the hexadecimal value of one of the eight 16-bit 6976 parts of the address. For example, 1080:0:0:0:8:800:200C:417A and 6977 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210. 6979 $ IP Security Option 6980 (I) See: Internet Protocol Security Option. 6982 $ IPLI 6983 (I) See: Internet Private Line Interface. 6985 $ IPRA 6986 (I) See: Internet Policy Registration Authority. 6988 $ IPS 6989 (I) See: Internet Protocol Suite. 6991 $ IPsec 6992 1a. (I) A contraction of "Internet Protocol security", the name of 6993 the IETF working group that is specifying an architecture [R2401] 6994 and set of protocols to provide security services for IP traffic. 6995 (See: AH, ESP, IKE, SAD, SPD. Compare: IPSO.) 6997 1b. (I) A collective name for that IP security architecture and 6998 associated set of protocols. 7000 Usage: Note that the letters "sec" are in lower case in "IPsec". 7002 Tutorial: The security services provided by IPsec include access 7003 control service, connectionless data integrity service, data 7004 origin authentication service, protection against replays 7005 (detection of the arrival of duplicate datagrams, within a 7006 constrained window), data confidentiality service, and limited 7007 traffic-flow confidentiality. IPsec specifies (a) security 7008 protocols (AH and ESP), (b) security associations (what they are, 7009 how they work, how they are managed, and associated processing), 7010 (c) key management (IKE), and (d) algorithms for authentication 7011 and encryption. Implementation of IPsec is optional for IP version 7012 4, but mandatory for IP version 6. 7014 $ IPsec Key Exchange (IKE) 7015 (I) An Internet, IPsec, key-establishment protocol [R2409] for 7016 putting in place authenticated keying material (a) for use with 7017 ISAKMP and (b) for other security associations, such as in AH and 7018 ESP. 7020 Tutorial: IKE is based on three earlier protocol designs: ISAKMP, 7021 OAKLEY, and SKEME. 7023 $ IPSO 7024 (I) See: Internet Protocol Security Option. 7026 $ ISAKMP 7027 (I) See: Internet Security Association and Key Management 7028 Protocol. 7030 $ ISD 7031 (I) See: Internet Standards document. 7033 $ ISO 7034 (I) International Organization for Standardization, a voluntary, 7035 non-treaty, non-government organization, established in 1947, with 7036 voting members that are designated standards bodies of 7037 participating nations and non-voting observer organizations. 7038 (Compare: ANSI, IETF, ITU-T, W3C.) 7040 Tutorial: Legally, ISO is a Swiss, non-profit, private 7041 organization. ISO and the IEC (the International Electrotechnical 7042 Commission) form the specialized system for worldwide 7043 standardization. National bodies that are members of ISO or IEC 7044 participate in developing international standards through ISO and 7045 IEC technical committees that deal with particular fields of 7046 activity. Other international governmental and non-governmental 7047 organizations, in liaison with ISO and IEC, also take part. (ANSI 7048 is the U.S. voting member of ISO. ISO is a class D member of 7049 ITU-T.) 7051 The ISO standards development process has four levels of 7052 increasing maturity: Working Draft (WD), Committee Draft (CD), 7053 Draft International Standard (DIS), and International Standard 7054 (IS). (Compare: (standards track levels under) Internet Standard.) 7055 In information technology, ISO and IEC have a joint technical 7056 committee, ISO/IEC JTC 1. DISs adopted by JTC 1 are circulated to 7057 national bodies for voting, and publication as an IS requires 7058 approval by at least 75% of the national bodies casting a vote. 7060 $ ISO 17799 7061 (N) An International Standard that is a code of practice, derived 7062 from Part 1 of British Standard 7799, for managing the security of 7063 information systems in an organization. This standard does not 7064 provide definitive or specific material on any security topic. It 7065 provides general guidance on a wide variety of topics, but 7066 typically does not go into depth. (See: IATF, [SP14].) 7068 $ ISOC 7069 (I) See: Internet Society. 7071 $ issue (a digital certificate or CRL) 7072 (I) Generate and sign a digital certificate (or CRL) and, usually, 7073 distribute it and make it available to potential certificate users 7074 (or CRL users). (See: certificate creation.) 7076 Usage: The ABA Guidelines [ABA] explicitly limit this term to 7077 certificate creation, and exclude the act of publishing. In 7078 general usage, however, "issuing" a digital certificate (or CRL) 7079 includes not only certificate creation but also making it 7080 available to potential users, such as by storing it in a 7081 repository or other directory or otherwise publishing it. 7083 $ issuer 7084 1. (I) /certificate, CRL/ The CA that signs a digital certificate 7085 or CRL. 7087 Tutorial: An X.509 certificate always includes the issuer's name. 7088 The name may include a common name value. 7090 2. (O) /payment card, SET/ "The financial institution or its agent 7091 that issues the unique primary account number to the cardholder 7092 for the payment card brand." [SET2] 7093 Tutorial: The institution that establishes the account for a 7094 cardholder and issues the payment card also guarantees payment for 7095 authorized transactions that use the card in accordance with card 7096 brand regulations and local legislation. [SET1] 7098 $ ITAR 7099 (O) See: International Traffic in Arms Regulations. 7101 $ ITSEC 7102 (N) See: Information Technology System Evaluation Criteria. 7104 $ ITU-T 7105 (N) International Telecommunications Union, Telecommunication 7106 Standardization Sector (formerly "CCITT"), a United Nations treaty 7107 organization that is composed mainly of postal, telephone, and 7108 telegraph authorities of the member countries and that publishes 7109 standards called "Recommendations". (See: X.400, X.500.) 7111 Tutorial: The Department of State represents the United States. 7112 ITU-T works on many kinds of communication systems. ITU-T 7113 cooperates with ISO on communication protocol standards, and many 7114 Recommendations in that area are also published as an ISO standard 7115 with an ISO name and number. 7117 $ IV 7118 (I) See: initialization value. 7120 $ jamming 7121 (I) An attack that attempts to interfere with the reception of 7122 broadcast communications. (See: anti-jam, denial of service. 7123 Compare: flooding.) 7125 Tutorial: Jamming uses "interference" as a type of "obstruction" 7126 intended to cause "disruption". Jamming a broadcast signal is 7127 typically done by broadcasting a second signal that receivers 7128 cannot separate from the first one. Jamming is mainly thought of 7129 in the context of wireless communication, but also can be done in 7130 some wired technologies, such as LANs that use contention 7131 techniques to share a broadcast medium. 7133 $ KAK 7134 (D) See: key-auto-key. (Compare: KEK.) 7136 $ KDC 7137 (I) See: Key Distribution Center. 7139 $ KEA 7140 (N) See: Key Exchange Algorithm. 7142 $ KEK 7143 (I) See: key-encrypting key. (Compare: KAK.) 7145 $ Kerberos 7146 (N) A system developed at the Massachusetts Institute of 7147 Technology that depends on passwords and symmetric cryptography 7148 (DES) to implement ticket-based, peer entity authentication 7149 service and access control service distributed in a client-server 7150 network environment. [R1510, Stei] 7152 Tutorial: Kerberos was developed by Project Athena and is named 7153 for the three-headed dog guarding Hades. The system architecture 7154 includes servers that function as an ACC and a KDC. 7156 $ kernel 7157 (I) A small, trusted part of a system that provides services on 7158 which the other parts of the system depend. (See: security 7159 kernel.) 7161 $ Kernelized Secure Operating System (KSOS) 7162 (O) An MLS computer operating system, designed to be a provably 7163 secure replacement for UNIX Version 6, and consisting of a 7164 security kernel, non-kernel security-related utility programs, and 7165 optional UNIX application development and support environments. 7166 [Perr] 7168 Tutorial: KSOS-6 was the implementation on a SCOMP. KSOS-11 was 7169 the implementation by Ford Aerospace and Communications 7170 Corporation on the DEC PDP-11/45 and PDP-111/70 computers. 7172 $ key 7173 1. (I) /cryptography/ An input parameter used to vary a 7174 transformation function performed by a cryptographic algorithm. 7175 (Compare: initialization value.) 7177 2. (I) /anti-jam/ An input parameter used to vary a process that 7178 determines patterns for an anti-jam measure. (See: frequency 7179 hopping, spread spectrum.) 7181 Tutorial: A key is usually specified as a sequence of bits or 7182 other symbols. If a key value needs to be kept secret, the 7183 sequence of symbols that comprise it should be random, or at least 7184 pseudorandom, because that makes the key hard for an adversary to 7185 guess. (See: cryptanalysis, brute force attack.) 7187 $ key agreement (algorithm or protocol) 7188 1. (I) A key establishment method (especially one involving 7189 asymmetric cryptography) by which two or more entities, without 7190 prior arrangement except a public exchange of data (such as public 7191 keys), each can generate the same key value. That is, the method 7192 does not send a secret from one entity to the other (compare: key 7193 transport); instead, both entities, without prior arrangement 7194 except a public exchange of data, can compute the same secret 7195 value, but that value cannot be computed by other, unauthorized 7196 entities. (See: Diffie-Hellman, key establishment, KEA, MQV.) 7197 2. (O) "A method for negotiating a key value on line without 7198 transferring the key, even in an encrypted form, e.g., the Diffie- 7199 Hellman technique." [X509] 7201 3. (O) "The procedure whereby two different parties generate 7202 shared symmetric keys such that any of the shared symmetric keys 7203 is a function of the information contributed by all legitimate 7204 participants, so that no party [alone] can predetermine the value 7205 of the key." [A9042] 7207 Example: A message originator and the intended recipient can each 7208 use their own private key and the other's public key with the 7209 Diffie-Hellman algorithm to first compute a shared secret value 7210 and, from that value, derive a session key to encrypt the message. 7212 $ key authentication 7213 (N) "The assurance of the legitimate participants in a key 7214 agreement that no non-legitimate party possesses the shared 7215 symmetric key." [A9042] 7217 $ key-auto-key (KAK) 7218 (D) "Cryptographic logic using previous key to produce key." 7219 [C4009, A1523] (See: CTAK.) 7221 Deprecated Term: IDS should not use this term; it is neither well- 7222 known nor precisely defined. Instead, use terms associated with 7223 modes that are defined in standards, such as CBC, CFB, and OFB. 7225 $ key center 7226 (I) A centralized key distribution process (used in symmetric 7227 cryptography), usually a separate computer system, that uses 7228 master keys (i.e., KEKs) to encrypt and distribute session keys 7229 needed in a community of users. 7231 Tutorial: An ANSI standard [A9017] defines two types of key 7232 center: key distribution center and key translation center. 7234 $ key confirmation 7235 (N) "The assurance [provided to] the legitimate participants in a 7236 key establishment protocol that the [parties that are intended to 7237 share] the symmetric key actually possess the shared symmetric 7238 key." [A9042] 7240 $ key distribution 7241 (I) A process that delivers a cryptographic key from the location 7242 where it is generated to the locations where it is used in a 7243 cryptographic algorithm. (See: key management.) 7245 $ key distribution center (KDC) 7246 1. (I) A type of key center (used in symmetric cryptography) that 7247 implements a key distribution protocol to provide keys (usually, 7248 session keys) to two (or more) entities that wish to communicate 7249 securely. (Compare: key translation center.) 7251 2. (N) "COMSEC facility generating and distributing key in 7252 electrical form." [C4009] 7254 Tutorial: A KDC distributes keys to Alice and Bob, who (a) wish to 7255 communicate with each other but do not currently share keys, (b) 7256 each share a KEK with the KDC, and (c) may not be able to generate 7257 or acquire keys by themselves. Alice requests the keys from the 7258 KDC. The KDC generates or acquires the keys and makes two 7259 identical sets. The KDC encrypts one set in the KEK it shares with 7260 Alice, and sends that encrypted set to Alice. The KDC encrypts the 7261 second set in the KEK it shares with Bob, and either (a) sends 7262 that encrypted set to Alice for her to forward to Bob or (b) sends 7263 it directly to Bob (although the latter option is not supported in 7264 the ANSI standard [A9017]). 7266 $ key encapsulation 7267 (N) A key recovery technique for storing knowledge of a 7268 cryptographic key by encrypting it with another key and ensuring 7269 that that only certain third parties called "recovery agents" can 7270 perform the decryption operation to retrieve the stored key. Key 7271 encapsulation typically permits direct retrieval of a secret key 7272 used to provide data confidentiality. (Compare: key escrow.) 7274 $ key-encrypting key (KEK) 7275 (I) A cryptographic key that (a) is used to encrypt other keys 7276 (either DEKs or other TEKs) for transmission or storage but (b) 7277 usually is not used to encrypt application data. Usage: Sometimes 7278 called "key-encryption key". 7280 $ key escrow 7281 (N) A key recovery technique for storing knowledge of a 7282 cryptographic key or parts thereof in the custody of one or more 7283 third parties called "escrow agents", so that the key can be 7284 recovered and used in specified circumstances. (Compare: key 7285 encapsulation.) 7287 Tutorial: Key escrow is typically implemented with split knowledge 7288 techniques. For example, the Escrowed Encryption Standard [FP185] 7289 entrusts two components of a device-unique split key to separate 7290 escrow agents. The agents provide the components only to someone 7291 legally authorized to conduct electronic surveillance of 7292 telecommunications encrypted by that specific device. The 7293 components are used to reconstruct the device-unique key, and it 7294 is used to obtain the session key needed to decrypt 7295 communications. 7297 $ key establishment (algorithm or protocol) 7298 1. (I) A procedure that combines the key generation and key 7299 distribution steps needed to set up or install a secure 7300 communication association. 7302 2. (I) A procedure that results in keying material being shared 7303 among two or more system entities. [A9042, SP56] 7305 Tutorial: The two basic techniques for key establishment are "key 7306 agreement" and "key transport". 7308 $ Key Exchange Algorithm (KEA) 7309 (N) A key-agreement method [SKIP, R2773] based on the Diffie- 7310 Hellman algorithm and uses 1024-bit asymmetric keys. (See: 7311 CAPSTONE, CLIPPER, FORTEZZA, SKIPJACK.) 7313 Tutorial: KEA was developed by NSA and formerly classified at the 7314 U.S. DoD "Secret" level. On 23 June 1998, the NSA announced that 7315 KEA had been declassified. 7317 $ key generation 7318 (I) A process that creates the sequence of symbols that comprise a 7319 cryptographic key. (See: key management.) 7321 $ key generator 7322 1. (I) An algorithm that uses mathematical rules to 7323 deterministically produce a pseudorandom sequence of cryptographic 7324 key values. 7326 2. (I) An encryption device that incorporates a key generation 7327 mechanism and applies the key to plain text to produce cipher text 7328 (e.g., by exclusive OR-ing (a) a bit string representation of the 7329 key with (b) a bit string representation of the plaintext). 7331 $ key length 7332 (I) The number of symbols (usually stated as a number of bits) 7333 needed to be able to represent any of the possible values of a 7334 cryptographic key. (See: key space.) 7336 $ key lifetime 7337 (N) /MISSI/ An attribute of a MISSI key pair that specifies a time 7338 span that bounds the validity period of any MISSI X.509 public-key 7339 certificate that contains the public component of the pair. (See: 7340 cryptoperiod.) 7342 $ key loader 7343 (N) Synonym for "fill device". 7345 $ key management 7346 1a. (I) The process of handling keying material during its life 7347 cycle in a cryptographic system; and the supervision and control 7348 of that process. (See: key distribution, key escrow, keying 7349 material, public-key infrastructure.) 7351 Usage: Usually understood to include ordering, generating, 7352 storing, archiving, escrowing, distributing, loading, destroying, 7353 auditing, and accounting for the material. 7355 1b. (O) /NIST/ "The activities involving the handling of 7356 cryptographic keys and other related security parameters (e.g., 7357 IVs, counters) during the entire life cycle of the keys, including 7358 their generation, storage, distribution, entry and use, deletion 7359 or destruction, and archiving." [FP140, SP57] 7361 2. (O) /OSIRM/ "The generation, storage, distribution, deletion, 7362 archiving and application of keys in accordance with a security 7363 policy." [I7498 Part 2] 7365 $ Key Management Protocol (KMP) 7366 (N) A protocol to establish a shared symmetric key between a pair 7367 (or a group) of users. (One version of KMP was developed by SDNS, 7368 and another by SILS.) Superseded by ISAKMP and IKE. 7370 $ key material 7371 (D) A synonym for "keying material". 7373 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 7374 "keying material". 7376 $ key pair 7377 (I) A set of mathematically related keys -- a public key and a 7378 private key -- that are used for asymmetric cryptography and are 7379 generated in a way that makes it computationally infeasible to 7380 derive the private key from knowledge of the public key. (See: 7381 Diffie-Hellman, RSA.) 7383 Tutorial: A key pair's owner discloses the public key to other 7384 system entities so they can use the key to (a) encrypt data, (b) 7385 verify a digital signature, (c) compute a protected checksum, or 7386 (d) generate a key in a key agreement algorithm. The matching 7387 private key is kept secret by the owner, who uses it to (a') 7388 decrypt data, (b') generate a digital signature, (c') verify a 7389 protected checksum, or (d') generate a key in a key agreement 7390 algorithm. 7392 $ key recovery 7393 1. (I) /cryptanalysis/ A process for learning the value of a 7394 cryptographic key that was previously used to perform some 7395 cryptographic operation. (See: cryptanalysis, recovery.) 7397 2. (I) /backup/ Techniques that provide an intentional, alternate, 7398 means to access the key used for data confidentiality service in 7399 an encrypted association. [DoD4] (Compare: recovery.) 7401 Tutorial: It is assumed that the cryptographic system includes a 7402 primary means of obtaining the key through a key establishment 7403 algorithm or protocol. For the secondary means, there are two 7404 classes of key recovery techniques: key encapsulation and key 7405 escrow. 7407 $ key space 7408 (I) The range of possible values of a cryptographic key; or the 7409 number of distinct transformations supported by a particular 7410 cryptographic algorithm. (See: key length.) 7412 $ key translation center 7413 (I) A type of key center that implements a key distribution 7414 protocol (based on symmetric cryptography) to convey keys between 7415 two (or more) parties who wish to communicate securely. (Compare: 7416 key distribution center.) 7418 Tutorial: A key translation center transfers keys for future 7419 communication between Bob and Alice, who (a) wish to communicate 7420 with each other but do not currently share keys, (b) each share a 7421 KEK with the center, and (c) have the ability to generate or 7422 acquire keys by themselves. Alice generates or acquires a set of 7423 keys for communication with Bob. Alice encrypts the set in the KEK 7424 she shares with the center and sends the encrypted set to the 7425 center. The center decrypts the set, reencrypts the set in the KEK 7426 it shares with Bob, and either (a) sends that reencrypted set to 7427 Alice for her to forward to Bob or (b) sends it directly to Bob 7428 (although direct distribution is not supported in the ANSI 7429 standard [A9017]). 7431 $ key transport (algorithm or protocol) 7432 1. (I) A key establishment method by which a secret key is 7433 generated by a system entity in a communication association and 7434 securely sent to another entity in the association. (Compare: key 7435 agreement.) 7437 Tutorial: Either (a) one entity generates a secret key and 7438 securely sends it to the other entity, or (b) each entity 7439 generates a secret value and securely sends it to the other 7440 entity, where the two values are combined to form a secret key. 7441 For example, a message originator can generate a random session 7442 key and then use the RSA algorithm to encrypt that key with the 7443 public key of the intended recipient. 7445 2. (O) "The procedure to send a symmetric key from one party to 7446 other parties. As a result, all legitimate participants share a 7447 common symmetric key in such a way that the symmetric key is 7448 determined entirely by one party." [A9042] 7450 $ key update 7451 1. (I) Derive a new key from an existing key. (Compare: rekey.) 7453 2. (O) Irreversible cryptographic process that modifies a key to 7454 produce a new key. [C4009] 7456 $ key validation 7457 1. (I) "The procedure for the receiver of a public key to check 7458 that the key conforms to the arithmetic requirements for such a 7459 key in order to thwart certain types of attacks." [A9042] (See: 7460 weak key) 7462 2. (D) A synonym for "certificate validation". 7464 Deprecated Usage: ISDs SHOULD NOT use the term as a synonym for 7465 "certificate validation"; that would unnecessarily duplicate the 7466 meaning of the latter term and mix concepts in a potentially 7467 misleading way. In validating an X.509 public-key certificate, the 7468 public key contained in the certificate is normally treated as an 7469 opaque data object. 7471 $ keyed hash 7472 (I) A cryptographic hash (e.g., [R1828]) in which the mapping to a 7473 hash result is varied by a second input parameter that is a 7474 cryptographic key. (See: checksum.) 7476 Tutorial: If the input data object is changed, a new, 7477 corresponding hash result cannot be correctly computed without 7478 knowledge of the secret key. Thus, the secret key protects the 7479 hash result so it can be used as a checksum even when there is a 7480 threat of an active attack on the data. There are two basic types 7481 of keyed hash: 7482 - A function based on a keyed encryption algorithm. Example: Data 7483 Authentication Code. 7484 - A function based on a keyless hash that is enhanced by 7485 combining (e.g., by concatenating) the input data object 7486 parameter with a key parameter before mapping to the hash 7487 result. Example: HMAC. 7489 $ keying material 7490 (I) Data that is needed to establish and maintain a cryptographic 7491 security association, such as keys, key pairs, and IVs. 7493 (O) "Key, code, or authentication information in physical or 7494 magnetic form." [C4009] (Compare: COMSEC material.) 7496 $ keying material identifier (KMID) 7498 1. (I) An identifier assigned to an item of keying material. 7500 2. (O) /MISSI/ A 64-bit identifier that is assigned to a key pair 7501 when the public key is bound in a MISSI X.509 public-key 7502 certificate. 7504 $ Khafre 7505 (N) A patented, symmetric block cipher designed by Ralph C. Merkle 7506 as a plug-in replacement for DES. [Schn] 7507 Tutorial: Khafre was designed for efficient encryption of small 7508 amounts of data. However, because Khafre does not precompute 7509 tables used for encryption, it is slower than Khufu for large 7510 amounts of data. 7512 $ Khufu 7513 (N) A patented, symmetric block cipher designed by Ralph C. Merkle 7514 as a plug-in replacement for DES. [Schn] 7516 Tutorial: Khufu was designed for fast encryption of large amounts 7517 of data. However, because Khufu precomputes tables used in 7518 encryption, it is less efficient that Khafre for small amounts of 7519 data. 7521 $ KMID 7522 (I) See: keying material identifier. 7524 $ known-plaintext attack 7525 (I) A cryptanalysis technique in which the analyst tries to 7526 determine the key from knowledge of some plaintext-ciphertext 7527 pairs (although the analyst may also have other clues, such as the 7528 knowing the cryptographic algorithm). 7530 $ KSOS, KSOS-6, KSOS-11 7531 (O) See: Kernelized Secure Operating System. 7533 $ L2F 7534 (N) See: Layer 2 Forwarding Protocol. 7536 $ L2TP 7537 (N) See: Layer 2 Tunneling Protocol. 7539 $ label 7540 See: time stamp, security label. 7542 $ laboratory attack 7543 (O) "Use of sophisticated signal recovery equipment in a 7544 laboratory environment to recover information from data storage 7545 media." [C4009] 7547 $ LAN 7548 (I) Local area network. 7550 $ land attack 7551 (I) A denial-of-service attack that sends an IP packet that (a) 7552 has the same address in both the Source Address and Destination 7553 Address fields and (b) contains a TCP SYN packet that has the same 7554 port number in both the Source Port and Destination Port fields. 7556 Derivation: This single-packet attack was named for "land", the 7557 program originally published by the cracker who invented this 7558 exploit. Perhaps that name was chosen because the inventor thought 7559 of multi-packet (i.e., flooding) attacks as arriving by "sea". 7561 $ Language of Temporal Ordering Specification (LOTOS) 7562 (N) A language (ISO 8807-1990) for formal specification of 7563 computer network protocols; describes the order in which events 7564 occur. 7566 $ lattice 7567 (I) A finite set together with a partial ordering on its elements 7568 such that for every pair of elements there is a least upper bound 7569 and a greatest lower bound. 7571 Example: A lattice is formed by a finite set S of security levels 7572 -- i.e., a set S of all ordered pairs (x,c), where x is one of a 7573 finite set X of hierarchically ordered classification levels X(1), 7574 non-hierarchical categories C(1), ..., C(M) -- together with the 7575 "dominate" relation. Security level (x,c) is said to "dominate" 7576 (x',c') if and only if (a) x is greater (higher) than or equal to 7577 x' and (b) c includes at least all of the elements of c'. (See: 7578 dominate, lattice model.) 7580 $ lattice model 7581 1. (I) A description of the semantic structure formed by a finite 7582 set of security levels, such as those used in military 7583 organizations. (See: dominate, security model.) 7585 2. (I) /formal model/ A model for flow control in a system, based 7586 on the lattice that is formed by the finite security levels in a 7587 system and their partial ordering. [Denn] 7589 $ Law Enforcement Access Field (LEAF) 7590 (N) A data item that is automatically embedded in data encrypted 7591 by devices (e.g., CLIPPER chip) that implement the Escrowed 7592 Encryption Standard. 7594 $ layer 1, 2, 3, 4, 5, 6, 7 7595 (N) See: OSIRM. 7597 $ Layer 2 Forwarding Protocol (L2F) 7598 (N) An Internet protocol (originally developed by Cisco 7599 Corporation) that uses tunneling of PPP over IP to create a 7600 virtual extension of a dial-up link across a network, initiated by 7601 the dial-up server and transparent to the dial-up user. (See: 7602 L2TP.) 7604 $ Layer 2 Tunneling Protocol (L2TP) 7605 (N) An Internet client-server protocol that combines aspects of 7606 PPTP and L2F and supports tunneling of PPP over an IP network or 7607 over frame relay or other switched network. (See: virtual private 7608 network.) 7609 Tutorial: PPP can in turn encapsulate any OSIRM layer 3 protocol. 7610 Thus, L2TP does not specify security services; it depends on 7611 protocols layered above and below it to provide any needed 7612 security. 7614 $ LDAP 7615 (I) See: Lightweight Directory Access Protocol. 7617 $ least common mechanism 7618 (I) The principle that a security architecture should minimize 7619 reliance on mechanisms that are shared by many users. 7621 Tutorial: Shared mechanisms may include cross-talk paths that 7622 permit a breach of data security, and it is difficult to make a 7623 single mechanism operate in a correct and trusted manner to the 7624 satisfaction of a wide range of users. 7626 $ least privilege 7627 (I) The principle that a security architecture should be designed 7628 so that each system entity is granted the minimum system resources 7629 and authorizations that the entity needs to do its work. (Compare: 7630 economy of mechanism, least trust.) 7632 Tutorial: This principle tends to limit damage that can be caused 7633 by an accident, error, or unauthorized act. This principle also 7634 tends to reduce complexity and promote modularity, which can make 7635 certification easier and more effective. This principle is similar 7636 to the principle of protocol layering, wherein each layer provides 7637 specific, limited communication services, and the functions in one 7638 layer are independent of those in other layers. 7640 $ least trust 7641 (I) The principle that a security architecture should be designed 7642 in a way that minimizes (a) the number of components that require 7643 trust and (b) the extent to which each component is trusted. 7644 (Compare: least privilege, trust level.) 7646 $ legacy system 7647 (I) A system that is in operation but will not be improved or 7648 expanded while a new system is being developed to supersede it. 7650 $ legal non-repudiation 7651 (I) See: (secondary definition under) non-repudiation. 7653 $ level of concern 7654 (N) /U.S. DoD/ A rating assigned to an information system that 7655 indicates the extent to which protective measures, techniques, and 7656 procedures must be applied. (See: level of robustness.) 7658 $ level of robustness 7659 (N) /U.S. DoD/ A characterization of the strength of a security 7660 function, mechanism, service, or solution, and the assurance (or 7661 confidence) that is implemented and functioning correctly to 7662 support the level of concern assigned to a particular information 7663 system. 7665 $ Lightweight Directory Access Protocol (LDAP) 7666 (I) An Internet client-server protocol (RFC 3377) that supports 7667 basic use of the X.500 Directory (or other directory servers) 7668 without incurring the resource requirements of the full Directory 7669 Access Protocol (DAP). 7671 Tutorial: Designed for simple management and browser applications 7672 that provide simple read/write interactive directory service. 7673 Supports both simple authentication and strong authentication of 7674 the client to the directory server. 7676 $ link 7677 1a. (I) A communication facility or physical medium that can 7678 sustain data communications between multiple network nodes, in the 7679 protocol layer immediately below IP. [R3573] 7681 1b. (I) /subnetwork/ A communication channel connecting subnetwork 7682 relays (especially one between two packet switches) that is 7683 implemented at OSIRM layer 2. (See: link encryption.) 7685 Tutorial: The relay computers assume that links are logically 7686 passive. If a computer at one end of a link sends a sequence of 7687 bits, the sequence simply arrives at the other end after a finite 7688 time, although some bits may have been changed either accidentally 7689 (errors) or by active wiretapping. 7691 2. (I) /World Wide Web/ See: hyperlink. 7693 $ link encryption 7694 (I) Stepwise (link-by-link) protection of data that flows between 7695 two points in a network, provided by encrypting data separately on 7696 each network link, i.e., by encrypting data when it leaves a host 7697 or subnetwork relay and decrypting when it arrives at the next 7698 host or relay. Each link may use a different key or even a 7699 different algorithm. [R1455] (Compare: end-to-end encryption.) 7701 $ logic bomb 7702 (I) Malicious logic that activates when specified conditions are 7703 met. Usually intended to cause denial of service or otherwise 7704 damage system resources. (See: Trojan horse, virus, worm.) 7706 $ login 7707 (I) The act by which a system entity establishes a session in 7708 which the entity can use system resources. (See: principal, 7709 session.) 7711 Usage: Usually understood to be accomplished by providing a user 7712 name and password to an access control system that authenticates 7713 the user, but sometimes refers to establishing a connection with a 7714 server when no authentication or specific authorization is 7715 involved. 7717 Derivation: Refers to "log" file", a security audit trail that 7718 records (a) security events, such as the beginning of a session, 7719 and (b) the names of the system entities that initiate events. 7721 $ long title 7722 (O) /U.S. Government/ "Descriptive title of [an item of COMSEC 7723 material]." [C4009] (Compare: short title.) 7725 $ low probability of detection 7726 (I) Result of TRANSEC measures used to hide or disguise a 7727 communication. 7729 $ low probability of intercept 7730 (I) Result of TRANSEC measures used to prevent interception of a 7731 communication. 7733 $ LOTOS 7734 (N) See: Language of Temporal Ordering Specification. 7736 $ MAC 7737 (N) See: mandatory access control, Message Authentication Code. 7739 Deprecated Usage: This abbreviation is ambiguous; therefore, ISDs 7740 that use it SHOULD state a definition for it. 7742 $ magnetic remanence 7743 (N) Magnetic representation of residual information remaining on a 7744 magnetic medium after the medium has been cleared. [NCS25] (See: 7745 clear, degauss, purge.) 7747 $ maintenance hook 7748 (N) "Special instructions (trapdoors) in software allowing easy 7749 maintenance and additional feature development. Since maintenance 7750 hooks frequently allow entry into the code without the usual 7751 checks, they are a serious security risk if they are not removed 7752 prior to live implementation." [C4009] (See: back door.) 7754 $ malicious logic 7755 (I) Hardware, software, or firmware that is intentionally included 7756 or inserted in a system for a harmful purpose. (See: logic bomb, 7757 Trojan horse, spyware, virus, worm. Compare: (secondary 7758 definitions under) corruption, incapacitation, masquerade, and 7759 misuse.) 7761 $ malware 7762 (D) A contraction of "malicious software". (See: malicious logic.) 7764 Deprecated Term: ISDs SHOULD NOT use this term; it is not listed 7765 in most dictionaries and could confuse international readers. 7767 $ MAN 7768 (I) metropolitan area network. 7770 $ man-in-the-middle attack 7771 (I) A form of active wiretapping attack in which the attacker 7772 intercepts and selectively modifies communicated data in order to 7773 masquerade as one or more of the entities involved in a 7774 communication association. (See: hijack attack, piggyback attack.) 7776 Tutorial: For example, suppose Alice and Bob try to establish a 7777 session key by using the Diffie-Hellman algorithm without data 7778 origin authentication service. A "man in the middle" could (a) 7779 block direct communication between Alice and Bob and then (b) 7780 masquerade as Alice sending data to Bob, (c) masquerade as Bob 7781 sending data to Alice, (d) establish separate session keys with 7782 each of them, and (e) function as a clandestine proxy server 7783 between them in order to capture or modify sensitive information 7784 that Alice and Bob think they are sending only to each other. 7786 $ manager 7787 (I) A person who controls the service configuration of a system or 7788 the functional privileges of operators and other users. 7790 $ mandatory access control 7791 1. (I) An access control service that enforces a security policy 7792 based on comparing (a) security labels, which indicate how 7793 sensitive or critical system resources are, with (b) security 7794 clearances, which indicate that system entities are eligible to 7795 access certain resources. (See: discretionary access control, MAC, 7796 rule-based security policy.) 7798 Derivation: This kind of access control is called "mandatory" 7799 because an entity that has clearance to access a resource is not 7800 permitted, just by its own volition, to enable another entity to 7801 access that resource. 7803 2. (O) "A means of restricting access to objects based on the 7804 sensitivity (as represented by a label) of the information 7805 contained in the objects and the formal authorization (i.e., 7806 clearance) of subjects to access information of such sensitivity." 7807 [DoD1] 7809 $ manipulation detection code 7810 (D) Synonym for "checksum". 7812 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 7813 "checksum"; the word "manipulation" implies protection against 7814 active attacks, which an ordinary checksum might not provide. 7815 Instead, if such protection is intended, use "protected checksum" 7816 or some particular type thereof, depending on which is meant. If 7817 such protection is not intended, use "error detection code" or 7818 some specific type of checksum that is not protected. 7820 $ marking 7821 See: time stamp, security marking. 7823 $ Martian 7824 (D) A packet that arrives unexpectedly at the wrong address or on 7825 the wrong network because of incorrect routing or because it has a 7826 non-registered or ill-formed IP address. 7828 Deprecated Term: It is likely that other cultures have different 7829 metaphors for this concept. Therefore, to ensure international 7830 understanding, ISDs SHOULD NOT use this term. (See: (Deprecated 7831 Usage under) Green Book.) 7833 $ masquerade 7834 (I) A type of threat action whereby an unauthorized entity gains 7835 access to a system or performs a malicious act by illegitimately 7836 posing as an authorized entity. (See: deception.) 7838 Usage: This type includes the following subtypes: 7839 - "Spoof": Attempt by an unauthorized entity to gain access to a 7840 system by posing as an authorized user. 7841 - "Malicious logic": In context of masquerade, any hardware, 7842 firmware, or software (e.g., Trojan horse) that appears to 7843 perform a useful or desirable function, but actually gains 7844 unauthorized access to system resources or tricks a user into 7845 executing other malicious logic. (See: (main entry for) 7846 malicious logic.) 7848 $ MCA 7849 (O) See: merchant certification authority. 7851 $ MD2 7852 (N) A cryptographic hash [R1319] that produces a 128-bit hash 7853 result, was designed by Ron Rivest, and is similar to MD4 and MD5 7854 but slower. 7856 Derivation: Apparently an abbreviation of "message digest", but 7857 that term is deprecated by this Glossary. 7859 $ MD4 7860 (N) A cryptographic hash [R1320] that produces a 128-bit hash 7861 result and was designed by Ron Rivest. (See: SHA-1, (Derivation 7862 under) MD2.) 7864 $ MD5 7865 (N) A cryptographic hash [R1321] that produces a 128-bit hash 7866 result and was designed by Ron Rivest to be an improved version of 7867 MD4. (See: (Derivation under) MD2.) 7869 $ merchant 7870 (O) /SET/ "A seller of goods, services, and/or other information 7871 who accepts payment for these items electronically." [SET2] A 7872 merchant may also provide electronic selling services and/or 7873 electronic delivery of items for sale. With SET, the merchant can 7874 offer its cardholders secure electronic interactions, but a 7875 merchant that accepts payment cards is required to have a 7876 relationship with an acquirer. [SET1, SET2] 7878 $ merchant certificate 7879 (O) /SET/ A public-key certificate issued to a merchant. Sometimes 7880 used to refer to a pair of such certificates where one is for 7881 digital signature use and the other is for encryption. 7883 $ merchant certification authority (MCA) 7884 (O) /SET/ A CA that issues digital certificates to merchants and 7885 is operated on behalf of a payment card brand, an acquirer, or 7886 another party according to brand rules. Acquirers verify and 7887 approve requests for merchant certificates prior to issuance by 7888 the MCA. An MCA does not issue a CRL, but does distribute CRLs 7889 issued by root CAs, brand CAs, geopolitical CAs, and payment 7890 gateway CAs. [SET2] 7892 $ mesh PKI 7893 (I) A non-hierarchical PKI architecture in which there are several 7894 trusted CAs rather than a single root. Each certificate user bases 7895 path validations on the public key of one of the trusted CAs, 7896 usually the one that issued that user's own public-key 7897 certificate. Rather than having superior-to-subordinate 7898 relationships between CAs, the relationships are peer-to-peer, and 7899 CAs issue cross-certificates to each other. (Compare: hierarchical 7900 PKI, trust-file PKI.) 7902 $ Message Authentication Code, message authentication code 7903 (N) /capitalized/ A specific ANSI standard for a checksum that is 7904 computed with a keyed hash that is based on DES. [A9009] Also 7905 known as the U.S. Government standard Data Authentication Code. 7906 [FP113] (See: MAC.) 7908 (D) /not capitalized/ Synonym for "error detection code". 7910 Deprecated Term: ISDs SHOULD NOT use the uncapitalized form 7911 "message authentication code"; that form mixes concepts in a 7912 potentially misleading way. Instead, use "checksum", "error 7913 detection code", "hash", "keyed hash", "Message Authentication 7914 Code", or "protected checksum", depending on what is meant. (See: 7915 authentication code.) 7917 In the uncapitalized form, the word "message" is misleading 7918 because it implies that the mechanism is particularly suitable for 7919 or limited to electronic mail (see: Message Handling Systems), the 7920 word "authentication" is misleading because the mechanism 7921 primarily serves a data integrity function rather than an 7922 authentication function, and the word "code" is misleading because 7923 it implies that either encoding or encryption is involved or that 7924 the term refers to computer software. 7926 $ message digest 7927 (D) Synonym for "hash result". (See: cryptographic hash.) 7929 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 7930 "hash result"; the term unnecessarily duplicates the meaning of 7931 the other, more general term and mixes concepts in a potentially 7932 misleading way. The word "message" is misleading because it 7933 implies that the mechanism is particularly suitable for or limited 7934 to electronic mail (see: Message Handling Systems). 7936 $ message handling system 7937 (D) A synonym for the Internet electronic mail system. 7939 Deprecated Term: ISDs SHOULD NOT use this term, because it could 7940 be confused with Message Handling System. Instead, use "Internet 7941 electronic mail" or some other, more specific term. 7943 $ Message Handling System 7944 (O) A ITU-T system concept that encompasses the notion of 7945 electronic mail but defines more comprehensive OSI systems and 7946 services that enable users to exchange messages on a store-and- 7947 forward basis. (The ISO equivalent is "Message Oriented Text 7948 Interchange System".) (See: X.400.) 7950 $ message indicator 7951 1. (D) /cryptographic function/ Synonym for "initialization 7952 value". 7954 2. (D) "Sequence of bits transmitted over a communications system 7955 for synchronizing cryptographic equipment." [C4009] 7957 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 7958 "initialization value"; the term mixes concepts in a potentially 7959 misleading way. The word "message" is misleading because it 7960 suggests that the mechanism is limited to electronic mail. (See: 7961 Message Handling System.) 7963 $ message integrity check 7964 $ message integrity code (MIC) 7965 (D) Synonyms for some form of "checksum". 7967 Deprecated Term: ISDs SHOULD NOT use these terms for any form of 7968 checksum. Instead, use "checksum", "error detection code", "hash", 7969 "keyed hash", "Message Authentication Code", or "protected 7970 checksum", depending on what is meant. 7972 The terms mix concepts in potentially misleading ways. The word 7973 "message" is misleading because it suggests that the mechanism is 7974 particularly suitable for or limited to electronic mail. The word 7975 "integrity" is misleading because the checksum may be used to 7976 perform a data origin authentication function rather than an 7977 integrity function. The word "code" is misleading because it 7978 suggests either that either encoding or encryption is involved or 7979 that the term refers to computer software. 7981 $ Message Security Protocol (MSP) 7982 (N) A secure message handling protocol [SDNS7] for use with X.400 7983 and Internet mail protocols. Developed by NSA's SDNS program and 7984 used in the U.S. DoD's Defense Message System. 7986 $ meta-data 7987 (I) Descriptive information about a data object; i.e., data about 7988 data, or data labels that describe other data. (See: security 7989 label. Compare: metadata) 7991 Tutorial: Meta-data can serve various management purposes: 7992 - System management: File name, type, size, creation date. 7993 - Application management: Document title, version, author. 7994 - Usage management: Data categories, keywords, classifications. 7996 Meta-data can be associated with a data object in two basic ways: 7997 - Explicitly: Be part of the data object (e.g., a header field of 7998 a data file or packet) or be linked to the object. 7999 - Implicitly: Be associated with the data object because of some 8000 other, explicit attribute of the object. 8002 $ metadata, Metadata(trademark), METADATA(trademark) 8003 (O) A proprietary variant of "meta-data". (See: SPAM(trademark).) 8005 Deprecated Usage: The terms "Metadata" and "METADATA" are claimed 8006 as registered trademarks (numbers 1,409,260 and 2,185,504) owned 8007 by The Metadata Company, originally known as Metadata Information 8008 Partners, a company founded by Jack Myers. To avoid litigation, 8009 this Glossary recommends a hyphenated form, "meta-data". 8011 $ MHS 8012 (N) See: message handling system. 8014 $ MIC 8015 (D) See: message integrity code. 8017 $ MIME 8018 (I) See: Multipurpose Internet Mail Extensions. 8020 $ MIME Object Security Services (MOSS) 8021 (I) An Internet protocol [R1848] that applies end-to-end 8022 encryption and digital signature to MIME message content, using 8023 symmetric cryptography for encryption and asymmetric cryptography 8024 for key distribution and signature. MOSS is based on features and 8025 specifications of PEM. (See: S/MIME.) 8027 $ Minimum Interoperability Specification for PKI Components (MISPC) 8028 (N) A technical description to provide a basis for interoperation 8029 between PKI components from different vendors; consists primarily 8030 of a profile of certificate and CRL extensions and a set of 8031 transactions for PKI operation. [SP15] 8033 $ misappropriation 8034 (I) A type of threat action whereby an entity assumes unauthorized 8035 logical or physical control of a system resource. (See: 8036 usurpation.) 8038 Usage: This type includes the following subtypes: 8039 - Theft of data: Unauthorized acquisition and use of data 8040 contained in a system. 8041 - Theft of service: Unauthorized use of a system service. 8042 - Theft of functionality: Unauthorized acquisition of actual 8043 hardware, software, or firmware of a system component. 8045 $ MISPC 8046 (N) See: Minimum Interoperability Specification for PKI 8047 Components. 8049 $ MISSI 8050 (N) Multilevel Information System Security Initiative, an NSA 8051 program to encourage development of interoperable, modular 8052 products for constructing secure network information systems in 8053 support of a wide variety of Government missions. (See: MSP, SP3, 8054 SP4.) 8056 $ MISSI user 8057 (O) /MISSI/ A system entity that is the subject of one or more 8058 MISSI X.509 public-key certificates issued under a MISSI 8059 certification hierarchy. (See: personality.) 8061 Tutorial: MISSI users include both end users and the authorities 8062 that issue certificates. A MISSI user is usually a person but may 8063 be a machine or other automated process. Some machines are 8064 required to operate non-stop. To avoid downtime needed to exchange 8065 the FORTEZZA cards of machine operators at shift changes, the 8066 machines may be issued their own cards, as if they were persons. 8068 $ mission 8069 (I) A statement of a (relatively long-term) duty or (relatively 8070 short-term) task that is assigned to an organization or system, 8071 indicates the purpose and objectives of the duty or task, and may 8072 indicate the actions to be taken to achieve it. 8074 $ mission critical 8075 (I) A condition of a system service or other system resource such 8076 that denial of access to, or lack of availability of, the resource 8077 would jeopardize a system user~Os ability to perform a primary 8078 mission function or would result in other serious consequences. 8079 (Compare: mission essential.) 8081 $ mission essential 8082 (O) /DoD/ Refers to materiel that is authorized and available to 8083 combat, combat support, combat service support, and combat 8084 readiness training forces to accomplish their assigned missions. 8085 [JCSP1] (Compare: mission critical.) 8087 $ misuse 8088 1. (I) The intentional use (by authorized users) of system 8089 resources for other than authorized purposes. Example: An 8090 authorized system administrator creates an unauthorized account 8091 for a friend. 8093 2. (I) A type of threat action that causes a system component to 8094 perform a function or service that is detrimental to system 8095 security. (See: usurpation.) 8097 Usage: This type includes the following subtypes: 8098 - "Tampering": In context of misuse, deliberately altering a 8099 system's logic, data, or control information to cause the 8100 system to perform unauthorized functions or services. (See: 8101 (main entry for) tampering.) 8102 - "Malicious logic": In context of misuse, any hardware, 8103 software, or firmware intentionally introduced into a system to 8104 perform or control execution of an unauthorized function or 8105 service. (See: (main entry for) malicious logic.) 8106 - "Violation of authorizations": Action by an entity that exceeds 8107 the entity's system privileges by executing an unauthorized 8108 function. (See: authorization.) 8110 $ misuse detection 8111 (I) An intrusion detection method that is based on rules that 8112 specify system events, sequences of events, or observable 8113 properties of a system that are believed to be symptomatic of 8114 security incidents. (See: IDS. Compare: anomaly detection.) 8116 $ MLS 8117 (I) See: multilevel secure 8119 $ mobile code 8120 1a. (I) Software that originates from a remote server or is 8121 embedded in a document or other application file, is transmitted 8122 across a network, and is loaded onto and executed on a local 8123 client system. 8125 1b. (O) /U.S. DoD/ "Software obtained from remote systems outside 8126 the enclave boundary, transferred across a network, and then 8127 downloaded and executed on a local system without explicit 8128 installation or execution by the recipient." 8129 2a. (O) /U.S. DoD/ "Technology that enables the creation of 8130 executable information that can be delivered to an information 8131 system and directly executed on any hardware/software architecture 8132 that has an appropriate host execution environment." 8134 2b. (O) "Programs (e.g., script, macro, or other portable 8135 instruction) that can be shipped unchanged to a heterogeneous 8136 collection of platforms and execute with identical semantics" [SP- 8137 28]. (See: active content.) 8139 Tutorial: Mobile code might be malicious. Using techniques such as 8140 "code signing" and a "sandbox" can reduce the risks of receiving 8141 and executing mobile code. 8143 $ mode 8144 $ mode of operation 8145 1. (I) /encryption/ A technique for enhancing the effect of a 8146 cryptographic algorithm or adapting the algorithm for an 8147 application, such as applying a block cipher to a sequence of data 8148 blocks or a data stream. (See: ECB, CBC, CFB, OFB.) 8150 2. (I) /system operation/ A type of security policy that states 8151 the range of classification levels of information that a system is 8152 permitted to handle and the range of clearances and authorizations 8153 of users who are permitted to access the system. (See: dedicated 8154 security mode, multilevel security mode, partitioned security 8155 mode, system high security mode.) 8157 $ modulus 8158 (I) The defining constant in modular arithmetic, and usually a 8159 part of the public key in asymmetric cryptography that is based on 8160 modular arithmetic. (See: Diffie-Hellman, RSA.) 8162 $ Mondex 8163 (O) A smartcard-based electronic money system that incorporates 8164 cryptography and can be used to make payments via the Internet. 8165 (See: IOTP.) 8167 $ Morris Worm 8168 (I) A worm program that flooded the ARPANET in November, 1988, 8169 causing problems for thousands of hosts. [R1135] (See: worm.) 8171 $ MOSS 8172 (I) See: MIME Object Security Services. 8174 $ MQV 8175 (N) A key-agreement protocol [Mene] that was proposed by A.J. 8176 Menezes, M. Qu, and S.A. Vanstone in 1995 and is based on the 8177 Diffie-Hellman algorithm. 8179 $ MSP 8180 (N) See: Message Security Protocol. 8182 $ multicast security 8183 See: secure multicast 8185 $ Multics 8186 (N) MULTiplexed Information and Computing Service, an MLS computer 8187 timesharing system designed and implemented during 1965-69 by a 8188 consortium including Massachusetts Institute of Technology, 8189 General Electric, and Bell Laboratories, and later offered 8190 commercially by Honeywell. 8192 Tutorial: Multics was one of the first large, general-purpose, 8193 operating systems to include security as a primary goal from the 8194 inception of the design and development and was rated in TCSEC 8195 Class B2. Its many innovative hardware and software security 8196 mechanisms (e.g., protection ring) were adopted by later systems. 8198 $ multilevel secure (MLS) 8199 (I) Describes an information system that is trusted to contain, 8200 and maintain separation between, resources (particularly stored 8201 data) of different security levels. (Examples: BLACKER, CANEWARE, 8202 KSOS, Multics, SCOMP.) 8204 Usage: Usually understood to mean that the system permits 8205 concurrent access by users who differ in their access 8206 authorizations, while denying users access to resources for which 8207 they lack authorization. 8209 $ multilevel security mode 8210 1. (N) A mode of system operation that allows two or more security 8211 levels of information to be handled concurrently within the same 8212 system when not all users have a clearance or specific access 8213 authorization for all data handled by the system. [DoD2] 8215 Usage: This term was defined in U.S. DoD policy regarding system 8216 accreditation [DoD2], but the term is also used outside the 8217 Defense Department and outside government. This term can be 8218 defined more precisely as follows: 8220 2. (N) A mode of system operation in which all three of the 8221 following statements are true: (a) Some authorized users do not 8222 have a security clearance for all the information handled in the 8223 system. (b) All authorized users have the proper security 8224 clearance and appropriate specific access approval for the 8225 information to which they have access. (c) All authorized users 8226 have a need-to-know only for information to which they have 8227 access. [C4009] 8229 $ Multipurpose Internet Mail Extensions (MIME) 8230 (I) An Internet protocol (RFC 2045) that enhances the basic format 8231 of Internet electronic mail messages (RFC 822) to be able to use 8232 character sets other than U.S. ASCII for textual headers and text 8233 content, and to carry non-textual and multi-part content. (See: 8234 S/MIME.) 8236 $ mutual suspicion 8237 (I) The state that exists between two interacting system entities 8238 in which neither entity can trust the other to function correctly 8239 with regard to some security requirement. 8241 $ name 8242 (I) Synonym for "identifier". 8244 $ National Computer Security Center (NCSC) 8245 (O) A U.S. DoD organization, housed in NSA, that has 8246 responsibility for encouraging widespread availability of trusted 8247 computer systems throughout the Federal Government. It has 8248 established criteria for, and performed evaluations of, computer 8249 and network systems that have a TCB. (See: Evaluated Products 8250 List, Rainbow Series, TCSEC.) 8252 $ National Information Assurance Partnership (NIAP) 8253 (N) An joint initiative of NIST and NSA to enhance the quality of 8254 commercial products for information security and increase consumer 8255 confidence in those products through objective evaluation and 8256 testing methods. 8258 Tutorial: NIAP is registered, through the U.S. DoD, as a National 8259 Performance Review Reinvention Laboratory. NIAP functions include 8260 the following: 8261 - Developing tests, test methods, and other tools that developers 8262 and testing laboratories may use to improve and evaluate 8263 security products. 8264 - Collaborating with industry and others on research and testing 8265 programs. 8266 - Using the Common Criteria to develop protection profiles and 8267 associated test sets for security products and systems. 8268 - Cooperating with the NIST National Voluntary Laboratory 8269 Accreditation Program to develop a program to accredit private- 8270 sector laboratories for the testing of information security 8271 products using the Common Criteria. 8272 - Working to establish a formal, international mutual recognition 8273 scheme for a Common Criteria-based evaluation. 8275 $ National Institute of Standards and Technology (NIST) 8276 (N) A U.S. Department of Commerce organization that promotes U.S. 8277 economic growth by working with industry to develop and apply 8278 technology, measurements, and standards. Has primary Government 8279 responsibility for INFOSEC standards for unclassified but 8280 sensitive information. (See: ANSI, DES, DSA, DSS, FIPS, NIAP, 8281 NSA.) 8283 $ National Security Agency (NSA) 8284 (N) A U.S. DoD organization that has primary Government 8285 responsibility for INFOSEC standards for classified information 8286 and for unclassified but sensitive information handled by national 8287 security systems. (See: FORTEZZA, KEA, MISSI, NIAP, NIST, 8288 SKIPJACK.) 8290 $ national security information 8291 (N) /U.S. Government/ Information that has been determined, 8292 pursuant to Executive Order 12958 or any predecessor order, to 8293 require protection against unauthorized disclosure. [C4009] 8295 $ national security system 8296 (O) /U.S. Government/ Any Government-operated information system 8297 for which the function, operation, or use (a) involves 8298 intelligence activities; (b) involves cryptologic activities 8299 related to national security; (c) involves command and control of 8300 military forces; (d) involves equipment that is an integral part 8301 of a weapon or weapon system; or (c) is critical to the direct 8302 fulfillment of military or intelligence missions and does not 8303 include a system that is to be used for routine administrative and 8304 business applications (including payroll, finance, logistics, and 8305 personnel management applications). [Title 40 U.S.C. Section 1552, 8306 Information Technology Management Reform Act of 1996.] (See: type 8307 2 product.) 8309 $ NCSC 8310 (O) See: National Computer Security Center. 8312 $ need to know 8313 (I) The necessity for access to, knowledge of, or possession of 8314 specific information required to carry out official duties. 8316 Tutorial: The need-to-know criterion is used in security 8317 procedures that require a custodian of sensitive information, 8318 prior to disclosing the information to someone else, to establish 8319 that the intended recipient has proper authorization to access the 8320 information. 8322 $ network 8323 (I) An information system comprised of a collection of 8324 interconnected modes. (See: computer network.) 8326 $ Network Layer Security Protocol (NLSP). 8327 (N) An OSI protocol (IS0 11577) for end-to-end encryption services 8328 at the top of OSIRM layer 3. NLSP is derived from SP3 but is more 8329 complex. (Compare: IPsec.) 8331 $ network weaving 8332 (I) A penetration technique in which an intruder avoids detection 8333 and traceback by using multiple linked communication networks to 8334 access and attack a system. [C4009] 8336 $ NIAP 8337 (N) See: National Information Assurance Partnership. 8339 $ nibble 8340 (D) Half of a byte (i.e., usually, 4 bits). 8342 Deprecated Term: To ensure international understanding, ISDs 8343 SHOULD NOT use this term; instead, state the size of the block 8344 explicitly (e.g., "4-bit block"). (See: (Deprecated Usage under) 8345 Green Book.) 8347 $ NIPRNET 8348 (O) The U.S. DoD~Os common-use Non-Classified Internet Protocol 8349 Router Network; the part of the Internet that is wholly controlled 8350 by the U.S. DoD and is used for official DoD business. 8352 $ NIST 8353 (N) See: National Institute of Standards and Technology. 8355 $ NLSP 8356 (N) See: Network Layer Security Protocol 8358 $ no-lone zone 8359 (I) A room or other space or area to which no person may have 8360 unaccompanied access and that, when occupied, is required to be 8361 occupied by two or more appropriately authorized persons. [C4009] 8362 (See: dual control.) 8364 $ no-PIN ORA (NORA) 8365 (O) /MISSI/ An organizational RA that operates in a mode in which 8366 the ORA performs no card management functions and, therefore, does 8367 not require knowledge of either the SSO PIN or user PIN for an end 8368 user's FORTEZZA PC card. 8370 $ node 8371 (I) A collection of related subsystems located on one or more 8372 computer platforms at a single system site. 8374 $ nonce 8375 (I) A random or non-repeating value that is included in data 8376 exchanged by a protocol, usually for the purpose of guaranteeing 8377 liveness and thus detecting and protecting against replay attacks. 8379 $ non-critical 8380 See: critical. 8382 $ non-repudiation service 8383 1. (I) A security service that provide protection against false 8384 denial of involvement in a communication. (See: repudiation, time 8385 stamp.) 8386 2. (O) "Assurance [that] the sender of data is provided with proof 8387 of delivery and the recipient is provided with proof of the 8388 sender's identity, so neither can later deny having processed the 8389 data." [NS4009] 8391 Deprecated Definition: ISDs SHOULD NOT use the "O" definition 8392 because it bundles two security services -- non-repudiation with 8393 proof of origin, and non-repudiation with proof of receipt -- that 8394 can be provided independently of each other. 8396 Usage: ISDs SHOULD distinguish between the technical aspects and 8397 the legal aspects of a non-repudiation service: 8398 - "Technical non-repudiation": Refers to the assurance a relying 8399 party has that if a public key is used to validate a digital 8400 signature, that signature had to have been made by the 8401 corresponding private signature key. [SP32] 8402 -"Legal non-repudiation": Refers to how well possession or 8403 control of the private signature key can be established. [SP32] 8405 Tutorial: Non-repudiation service does not prevent an entity from 8406 repudiating a communication. Instead, the service provides 8407 evidence that can be stored and later presented to a third party 8408 to resolve disputes that arise if and when a communication is 8409 repudiated by one of the entities involved. 8411 Ford describes the six phases of a complete non-repudiation 8412 service and uses "critical action" to refer to the act of 8413 communication that is the subject of the service [For94, For97]: 8415 -------- -------- -------- -------- -------- . -------- 8416 Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6: 8417 Request Generate Transfer Verify Retain . Resolve 8418 Service Evidence Evidence Evidence Evidence . Dispute 8419 -------- -------- -------- -------- -------- . -------- 8421 Service Critical Evidence Evidence Archive . Evidence 8422 Request => Action => Stored => Is => Evidence . Is 8423 Is Made Occurs For Later Tested In Case . Verified 8424 and Use | ^ Critical . ^ 8425 Evidence v | Action Is . | 8426 Is +-------------------+ Repudiated . | 8427 Generated |Verifiable Evidence|------> ... . ----+ 8428 +-------------------+ 8430 Phase / Explanation 8431 ------------------- 8432 1. Request service: Before the critical action, the service 8433 requester asks, either implicitly or explicitly, to have 8434 evidence of the action be generated. 8435 2. Generate evidence: When the critical action occurs, evidence is 8436 generated by a process involving the potential repudiator and 8437 possibly also a trusted third party. 8439 3. Transfer evidence: The evidence is transferred to the requester 8440 or stored by a third party, for later use (if needed.) 8441 4. Verify evidence: The entity that holds the evidence tests it to 8442 be sure that it will suffice if a dispute arises. 8443 5. Retain evidence: The evidence is retained for possible future 8444 retrieval and use. 8445 6. Resolve dispute: In this phase, which occurs only if the 8446 critical action is repudiated, the evidence is retrieved from 8447 storage, presented, and verified to resolve the dispute. 8449 $ non-repudiation with proof of origin 8450 (I) A security service that provides the recipient of data with 8451 evidence that proves the origin of the data, and thus protects the 8452 recipient against an attempt by the originator to falsely deny 8453 sending the data. This service can be viewed as a strong version 8454 of data origin authentication service, in that it proves 8455 authenticity to a third party. (See: non-repudiation service.) 8457 $ non-repudiation with proof of receipt 8458 (I) A security service that provides the originator of data with 8459 evidence that proves the data was received as addressed, and thus 8460 protects the originator against an attempt by the recipient to 8461 falsely deny receiving the data. (See: non-repudiation service.) 8463 $ non-volatile media 8464 (I) Storage media that, once written into, provide stable storage 8465 of information without an external power supply. (Compare: 8466 volatile media, permanent storage.) 8468 $ NORA 8469 (O) See: no-PIN ORA. 8471 $ notarization 8472 (I) Registration of data under the authority or in the care of a 8473 trusted third party, thus making it possible to provide subsequent 8474 assurance of the accuracy of characteristics claimed for the data, 8475 such as content, origin, time of existence, and delivery. [I7498 8476 Part 2] (See: digital notary.) 8478 $ NSA 8479 (N) See: National Security Agency 8481 $ null 8482 (N) /encryption/ "Dummy letter, letter symbol, or code group 8483 inserted into an encrypted message to delay or prevent its 8484 decryption or to complete encrypted groups for transmission or 8485 transmission security purposes." [C4009] 8487 $ NULL encryption algorithm 8488 (I) An algorithm [R2410] that is specified as doing nothing to 8489 transform plaintext data; i.e., a no-op. It originated because ESP 8490 always specifies the use of an encryption algorithm for 8491 confidentiality. The NULL encryption algorithm is a convenient way 8492 to represent the option of not applying encryption in ESP (or in 8493 any other context where a no-op is needed). (Compare: null.) 8495 $ OAKLEY 8496 (I) A key establishment protocol (proposed for IPsec but 8497 superseded by IKE) based on the Diffie-Hellman algorithm and 8498 designed to be a compatible component of ISAKMP. [R2412] 8500 Tutorial: OAKLEY establishes a shared key with an assigned 8501 identifier and associated authenticated identities for parties; 8502 i.e., OAKLEY provides authentication service to ensure the 8503 entities of each other's identity, even if the Diffie-Hellman 8504 exchange is threatened by active wiretapping. Also, it provides 8505 public-key forward secrecy for the shared key and supports key 8506 updates, incorporation of keys distributed by out-of-band 8507 mechanisms, and user-defined abstract group structures for use 8508 with Diffie-Hellman. 8510 $ object 8511 (I) /formal model/ Trusted computer system modeling usage: A 8512 system component that contains or receives information. (See: 8513 Bell-LaPadula model, trusted computer system.) 8515 $ object identifier (OID) 8516 1. (N) An official, globally unique name for a thing, written as a 8517 sequence of integers (which are formed and assigned as defined in 8518 the ASN.1 standard) and used to reference the thing in abstract 8519 specifications and during negotiation of security services in a 8520 protocol. 8522 2. (O) "A value (distinguishable from all other such values) which 8523 is associated with an object." [X680] 8525 Tutorial: Objects named by OIDs are leaves of the object 8526 identifier tree (which is similar to but different from the X.500 8527 Directory Information Tree). Each arc (i.e., each branch of the 8528 tree) is labeled with a non-negative integer. An OID is the 8529 sequence of integers on the path leading from the root of the tree 8530 to a named object. 8532 The OID tree has three arcs immediately below the root: {0} for 8533 use by ITU-T, {1} for use by ISO, and {2} for use by both jointly. 8534 Below ITU-T are four arcs, where {0 0} is for ITU-T 8535 recommendations. Below {0 0} are 26 arcs, one for each series of 8536 recommendations starting with the letters A to Z, and below these 8537 are arcs for each recommendation. Thus, the OID for ITU-T 8538 Recommendation X.509 is {0 0 24 509}. Below ISO are four arcs, 8539 where {1 0 }is for ISO standards, and below these are arcs for 8540 each ISO standard. Thus, the OID for ISO/IEC 9594-8 (the ISO 8541 number for X.509) is {1 0 9594 8}. 8543 ANSI registers organization names below the branch {joint-iso- 8544 ccitt(2) country(16) US(840) organization(1) gov(101) csor(3)}. 8545 The NIST CSOR records PKI objects below the branch {joint-iso-itu- 8546 t(2) country(16) us(840) organization (1) gov(101) csor(3)}. The 8547 U.S. DoD registers INFOSEC objects below the branch {joint-iso- 8548 itu-t(2) country(16) us(840) organization(1) gov(101) dod(2) 8549 infosec(1)}. 8551 The IETF's Public-Key Infrastructure (pkix) Working Group 8552 registers PKI objects below the branch {iso(1) identified- 8553 organization(3) dod(6) internet(1) security(5) mechanisms(5) 8554 pkix(7)}. [R2459] 8556 $ object reuse 8557 (N) /COMPUSEC/ Reassignment and reuse of an area of a storage 8558 medium (e.g., random-access memory, floppy disk, magnetic tape) 8559 that once contained sensitive data objects. Before being 8560 reassigned for use by a new subject, the area must erased or, in 8561 some cases, purged. [NCS04] 8563 $ obstruction 8564 (I) A type of threat action that interrupts delivery of system 8565 services by hindering system operations. (See: disruption.) 8567 Tutorial: This type includes the following subtypes: 8568 - "Interference": Disruption of system operations by blocking 8569 communications or user data or control information. (See: 8570 jamming.) 8571 - "Overload": Hindrance of system operation by placing excess 8572 burden on the performance capabilities of a system component. 8573 (See: flooding.) 8575 $ OCSP 8576 (I) See: On-line Certificate Status Protocol. 8578 $ octet 8579 (I) A data unit of eight bits. (Compare: byte.) 8581 Usage: This term is used in networking (especially in OSI 8582 standards) in preference to "byte", because some systems use 8583 "byte" for data storage units of a size other than eight bits. 8585 $ OFB 8586 (N) See: output feedback. 8588 $ off-line attack 8589 (I) See: (secondary definition under) attack. 8591 $ ohnosecond 8592 (D) That minuscule fraction of time in which you realize that your 8593 private key has been compromised. 8595 Deprecated Usage: This is a joke for English speakers. (See: 8596 (Deprecated Usage under) Green Book.) 8598 $ OID 8599 (N) See: object identifier. 8601 $ On-line Certificate Status Protocol (OCSP) 8602 (I) An Internet protocol [R2560] used by a client to obtain from a 8603 server the validity status and other information concerning a 8604 digital certificate. 8606 Tutorial: In some applications, such as those involving high-value 8607 commercial transactions, it may be necessary either (a) to obtain 8608 certificate revocation status that is more timely than is possible 8609 with CRLs or (b) to obtain other kinds of status information. OCSP 8610 may be used to determine the current revocation status of a 8611 digital certificate, in lieu of or as a supplement to checking 8612 against a periodic CRL. An OCSP client issues a status request to 8613 an OCSP server and suspends acceptance of the certificate in 8614 question until the server provides a response. 8616 $ one-time pad 8617 1. (N) A manual encryption system in the form of a paper pad for 8618 one-time use. 8620 2. (I) An encryption algorithm in which the key is a random 8621 sequence of symbols and each symbol is used for encryption only 8622 one time -- to encrypt only one plaintext symbol to produce only 8623 one ciphertext symbol -- and a copy of the key is used similarly 8624 for decryption. 8626 Tutorial: To ensure one-time use, the copy of the key used for 8627 encryption is destroyed after use, as is the copy used for 8628 decryption. This is the only encryption algorithm that is truly 8629 unbreakable, even given unlimited resources for cryptanalysis 8630 [Schn], but key management costs and synchronization problems make 8631 it impractical except in special situations. 8633 $ one-time password, One-Time Password (OTP) 8634 1. (I) /not capitalized/ A "one-time password" is a simple 8635 authentication technique in which each password is used only once 8636 as authentication information that verifies an identity. This 8637 technique counters the threat of a replay attack that uses 8638 passwords captured by wiretapping. 8640 2. (I) /capitalized/ "One-Time Password" is an Internet protocol 8641 [R1938] that is based on S/KEY and uses a cryptographic hash 8642 function to generate one-time passwords for use as authentication 8643 information in system login and in other processes that need 8644 protection against replay attacks. 8646 $ one-way encryption 8647 (I) Irreversible transformation of plain text to cipher text, such 8648 that the plain text cannot be recovered from the cipher text by 8649 other than exhaustive procedures even if the cryptographic key is 8650 known. (See: encryption.) 8652 $ one-way function 8653 (I) "A (mathematical) function, f, which is easy to compute, but 8654 which for a general value y in the range, it is computationally 8655 difficult to find a value x in the domain such that f(x) = y. 8656 There may be a few values of y for which finding x is not 8657 computationally difficult." [X509] 8659 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 8660 "cryptographic hash". 8662 $ onion routing 8663 (I) A system that can be used to provide both (a) data 8664 confidentiality and (b) traffic-flow confidentiality for network 8665 packets, and also provide (c) anonymity for the source of the 8666 packets. 8668 Tutorial: The source, instead of sending a packet directly to the 8669 intended destination, sends it to an "onion routing proxy" that 8670 builds an anonymous connection through several other "onion 8671 routers" to the destination. The proxy defines a route through the 8672 "onion routing network" by encapsulating the original payload in a 8673 layered data packet called an "onion", in which each layer defines 8674 the next hop in the route and each layer is also encrypted. Along 8675 the route, each onion router that receives the onion peels off one 8676 layer; decrypts that layer and reads from it the address of the 8677 next onion router on the route; pads the remaining onion to some 8678 constant size; and sends the padded onion to that next router. 8680 $ open security environment 8681 (O) /U.S. DoD/ A system environment that meets at least one of the 8682 following two conditions: (a) Application developers (including 8683 maintainers) do not have sufficient clearance or authorization to 8684 provide an acceptable presumption that they have not introduced 8685 malicious logic. (b) Configuration control does not provide 8686 sufficient assurance that applications and the equipment are 8687 protected against the introduction of malicious logic prior to and 8688 during the operation of system applications. [NCS04] (See: (first 8689 law under) Courtney's laws. Compare: closed security environment.) 8691 $ open storage 8692 (N) /U.S. Government/ "Storage of classified information within an 8693 accredited facility, but not in General Services Administration 8694 approved secure containers, while the facility is unoccupied by 8695 authorized personnel." [C4009] 8697 $ Open Systems Interconnection (OSI) Reference Model (OSIRM) 8698 (N) A joint ISO/ITU-T standard [I7498 Part 1] for a seven-layer, 8699 architectural communication framework for interconnection of 8700 computers in networks. 8702 Tutorial: OSIRM-based standards include communication protocols 8703 that are mostly incompatible with the IPS, but also include 8704 security models, such as X.509, that are used in the Internet. 8706 The OSIRM layers, from highest to lowest, are (7) Application, (6) 8707 Presentation, (5) Session, (4) Transport, (3) Network, (2) Data 8708 Link, and (1) Physical. 8710 Usage: In other Glossary entries, OSIRM layers are referred to by 8711 number to avoid confusing them with IPS layers, which are referred 8712 to by name. 8714 Some unknown person described how the OSIRM layers correspond to 8715 the seven deadly sins: 8717 7. Wrath: Application is always angry at the mess it sees below 8718 itself. (Hey! Who is it to be pointing fingers?) 8719 6. Sloth: Presentation is too lazy to do anything productive by 8720 itself. 8721 5. Lust: Session is always craving and demanding what truly 8722 belongs to Application's functionality. 8723 4. Avarice: Transport wants all of the end-to-end functionality. 8724 (Of course, it deserves it, but life isn't fair.) 8725 3. Gluttony: (Connection-Oriented) Network is overweight and 8726 overbearing after trying too often to eat Transport's lunch. 8727 2. Envy: Poor Data Link is always starved for attention. (With 8728 Asynchronous Transfer Mode, maybe now it is feeling less 8729 neglected.) 8730 1. Pride: Physical has managed to avoid much of the controversy, 8731 and nearly all of the embarrassment, suffered by the others. 8733 John G. Fletcher described how the OSIRM layers correspond to Snow 8734 White's dwarf friends: 8736 7. Doc: Application acts as if it is in charge, but sometimes 8737 muddles its syntax. 8738 6. Sleepy: Presentation is indolent, being guilty of the sin of 8739 Sloth. 8740 5. Dopey: Session is confused because its charter is not very 8741 clear. 8742 4. Grumpy: Transport is irritated because Network has encroached 8743 on Transport's turf. 8744 3. Happy: Network smiles for the same reason that Transport is 8745 irritated. 8746 2. Sneezy: Data Link makes loud noises in the hope of attracting 8747 attention. 8748 1. Bashful: Physical quietly does its work, unnoticed by the 8749 others. 8751 $ operational integrity 8752 (I) Synonym for "system integrity"; this synonym emphasizes the 8753 actual performance of system functions rather than just the 8754 ability to perform them. 8756 $ operational security 8757 (D) Synonym for "administrative security". (Compare: OPSEC.) 8759 Deprecated Definition: ISDs SHOULD NOT use this term as a synonym 8760 for "administrative security". Any type of security may affect 8761 system operations; therefore, the term may be misleading. Instead, 8762 use "administrative security", "communication security", "computer 8763 security", "emanations security", "personnel security", "physical 8764 security", or whatever specific type is meant. (Compare: OPSEC. 8765 See: security architecture.) 8767 $ operations security (OPSEC) 8768 (I) A process to identify, control, and protect evidence of the 8769 planning and execution of sensitive activities and operations, and 8770 thereby prevent potential adversaries from gaining knowledge of 8771 capabilities and intentions. (See: communications cover. Compare: 8772 operational security.) 8774 $ operator 8775 (I) A person who has been authorized to direct selected functions 8776 of a system. (Compare: manager.) 8778 Usage: A system operator may or may not be treated as a "user"; 8779 therefore, ISDs that use this term SHOULD state a definition for 8780 it. 8782 $ OPSEC 8783 (I) See: operations security. 8785 $ ORA 8786 See: organizational registration authority. 8788 $ Orange Book 8789 (D) Synonym for "Trusted Computer System Evaluation Criteria" 8790 [CSC001, DoD1]. 8792 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 8793 "Trusted Computer System Evaluation Criteria" [CSC001, DoD1]. 8794 Instead, use the full, proper name of the document or, in 8795 subsequent references, the abbreviation "TCSEC". (See: (Deprecated 8796 Usage under) Green Book.) 8798 $ organizational certificate 8799 (I) A X.509 certificate in which the "subject" field contains the 8800 name of an institution or set (e.g., a business, government, 8801 school, labor union, club, ethnic group, nationality, system, or 8802 group of individuals playing the same role), rather than the name 8803 of an individual person or device. (Compare: persona certificate, 8804 role certificate.) 8806 Tutorial: Such a certificate might be issued for one of the 8807 following purposes: 8808 - To enable an individual to prove membership in the 8809 organization. 8810 - To enable an individual to represent the organization, i.e., to 8811 act in its name and with it powers or permissions. 8813 (O) /MISSI/ A type of MISSI X.509 public-key certificate that is 8814 issued to support organizational message handling for the U.S. 8815 DoD's Defense Message System. 8817 $ organizational registration authority (ORA) 8818 1. (I) /PKI/ An RA for an organization. 8820 2. (O) /MISSI/ An end entity that (a) assists a PCA, CA, or SCA to 8821 register other end entities, by gathering, verifying, and entering 8822 data and forwarding it to the signing authority and (b) may also 8823 assist with card management functions. An ORA is a local 8824 administrative authority, and the term refers both to the role and 8825 to the person who plays that role. An ORA does not sign 8826 certificates, CRLs, or CKLs. (See: no-PIN ORA, SSO-PIN ORA, user- 8827 PIN ORA.) 8829 $ origin authentication 8830 Deprecated Term: ISDs SHOULD NOT use this term; it looks like 8831 careless use of the internationally standardized term "data origin 8832 authentication", and also could be confused with "peer entity 8833 authentication." (See: authentication.) 8835 $ origin authenticity 8836 Deprecated Term: ISDs SHOULD NOT use this term; it looks like 8837 careless use of the internationally standardized term "data origin 8838 authentication", and mixes concepts in a potentially misleading 8839 way. (See: authenticity, origin authentication.) 8841 $ OSI 8842 $ OSIRM 8843 (N) See: Open Systems Interconnection Reference Model. 8845 $ OTAR 8846 (N) See: over-the-air rekeying. 8848 $ OTP 8849 (I) See: One-Time Password. 8851 $ out of band 8852 1a. (I) Transfer of information using a channel that is outside 8853 (i.e., separate from) the main or normal channel. 8855 1b. (I) Transfer of information using a means or method that 8856 differs from the main or normal method of communication.(See: 8857 covert channel.) 8859 Tutorial: Out-of-band mechanisms are often used to distribute 8860 shared secrets (e.g., a symmetric key) or other sensitive 8861 information items (e.g., a root key) that are needed to initialize 8862 or otherwise enable the operation of cryptography or other 8863 security mechanisms. Example: Using postal mail to distribute 8864 printed or magnetic media containing symmetric cryptographic keys 8865 for use in Internet encryption devices. (See: key distribution.) 8867 $ output feedback (OFB) 8868 (N) A block cipher mode [FP081] that modifies ECB mode to operate 8869 on plaintext segments of variable length less than or equal to the 8870 block length. 8872 Tutorial: This mode operates by directly using the algorithm's 8873 previously generated output block as the algorithm's next input 8874 block (i.e., by "feeding back" the output block) and combining 8875 (exclusive OR-ing) the output block with the next plaintext 8876 segment (of block length or less) to form the next ciphertext 8877 segment. 8879 $ outside attack 8880 (I) See: (secondary definition under) attack. Compare: outsider.) 8882 $ outsider 8883 (I) A user (usually a person) that accesses a system from a 8884 position that is outside the system's security perimeter. 8885 (Compare: authorized user, insider, unauthorized user.) 8887 Tutorial: The actions performed by an outsider in accessing the 8888 system may be either authorized or unauthorized; i.e., an outsider 8889 may act either as an authorized user or as an unauthorized user. 8891 $ over-the-air rekeying (OTAR) 8892 (N) Changing a key in a remote cryptographic device by sending a 8893 new key directly to the device via a channel that the device is 8894 protecting. [C4009] 8896 $ overload 8897 (I) See: (secondary definition under) obstruction. 8899 $ P1363 8900 (N) See: IEEE P1363. 8902 $ PAA 8903 (O) See: policy approving authority. 8905 $ package 8906 (N) /Common Criteria/ A reusable set of either functional or 8907 assurance components (e.g. an EAL), combined in a single unit to 8908 satisfy a set of identified security objectives. 8910 Tutorial: A package is a combination of security requirement 8911 components and is intended to be reusable in the construction of 8912 either more complex packages or protection profiles and security 8913 targets. A package expresses a set of either functional or 8914 assurance requirements that meet some particular need, expressed 8915 as a set of security objectives. Example: The seven EALs defined 8916 in Part 3 of the Common Criteria are predefined assurance 8917 packages. 8919 $ packet filter 8920 (I) See: (secondary definition under) filtering router. 8922 $ packet monkey 8923 (D) Someone who floods a system with packets, creating a denial- 8924 of-service condition for the system's users.(See: cracker.) 8926 $ pagejacking 8927 (D) A contraction of "Web page hijacking". A masquerade attack in 8928 which the attacker copies (steals) a home page or other material 8929 from the target server, rehosts the page on a server the attacker 8930 controls, and causes the rehosted page to be indexed by the major 8931 Web search services, thereby diverting browsers from the target 8932 server to the attacker's server. 8934 Deprecated Term: ISDs SHOULD NOT use this contraction. The term is 8935 not listed in most dictionaries and could confuse international 8936 readers. (See: (Deprecated Usage under) Green Book.) 8938 $ PAN 8939 (O) See: primary account number. 8941 $ PAP 8942 (I) See: Password Authentication Protocol. 8944 $ parity bit 8945 (I) A checksum that is computed on a block of bits by computing 8946 the binary sum of the individual bits in the block and then 8947 discarding all but the low-order bit of the sum. 8949 $ partitioned security mode 8950 (N) A mode of operation of an information system, wherein all 8951 users have the clearance, but not necessarily formal access 8952 authorization and need-to-know, for all data handled by the 8953 system. This mode is defined in U.S. DoD policy regarding system 8954 accreditation. [DoD2] 8956 $ PASS 8957 (N) See: personnel authentication system string. 8959 $ passive attack 8960 (I) See: (secondary definition under) attack. 8962 $ passive wiretapping 8963 (I) A wiretapping attack that attempts only to observer 8964 communication flow and gain knowledge of the data it contains, but 8965 does not alter or otherwise affect that flow. (See: wiretapping. 8966 Compare: passive attack, active wiretapping.) 8968 $ password 8969 (I) A secret data value, usually a character string, that is 8970 presented to a system by a user to authenticate the user's 8971 identity. (See: challenge-response, PIN, simple authentication.) 8973 (O) "A character string used to authenticate an identity." [CSC2] 8975 (O) "A string of characters (letters, numbers, and other symbols) 8976 used to authenticate an identity or to verify access 8977 authorization." [FP140] 8979 (O) "A secret that a claimant memorizes and uses to authenticate 8980 his or her identity. Passwords are typically character strings." 8981 [SP63] 8983 Tutorial: A password is usually paired with a user identifier that 8984 is explicit in the authentication process, although in some cases 8985 the identifier may be implicit. A password is usually verified by 8986 matching it to a stored value held by the access control system 8987 for that identifier. 8989 Using a password as authentication information is based on 8990 assuming that the password is known only by the system entity for 8991 which the identity is being authenticated. Therefore, in a network 8992 environment where wiretapping is possible, simple authentication 8993 that relies on transmission of static (i.e., repetitively used) 8994 passwords in cleartext form is inadequate. (See: one-time 8995 password, strong authentication.) 8997 $ Password Authentication Protocol (PAP) 8998 (I) A simple authentication mechanism in PPP. In PAP, a user 8999 identifier and password are transmitted in cleartext form. [R1334] 9000 (See: CHAP.) 9002 $ password sniffing 9003 (I) Passive wiretapping, usually on a LAN, to gain knowledge of 9004 passwords. (See: (Deprecated Usage note under) sniffing.) 9006 $ path discovery 9007 (I) For a digital certificate, the process of finding a set of 9008 public-key certificates that comprise a certification path from a 9009 trusted key to that specific certificate. 9011 $ path validation 9012 (I) The process of validating (a) all of the digital certificates 9013 in a certification path and (b) the required relationships between 9014 those certificates, thus validating the contents of the last 9015 certificate on the path. (See: certificate validation.) 9017 Tutorial: To promote interoperable PKI applications in the 9018 Internet, RFC 3280 specifies a detailed algorithm for validation 9019 of a certification path. 9021 $ payment card 9022 (N) /SET/ Collectively refers "to credit cards, debit cards, 9023 charge cards, and bank cards issued by a financial institution and 9024 which reflects a relationship between the cardholder and the 9025 financial institution." [SET2] 9027 $ payment gateway 9028 (O) /SET/ A system operated by an acquirer, or a third party 9029 designated by an acquirer, for the purpose of providing electronic 9030 commerce services to the merchants in support of the acquirer, and 9031 which interfaces to the acquirer to support the authorization, 9032 capture, and processing of merchant payment messages, including 9033 payment instructions from cardholders. [SET1, SET2] 9035 $ payment gateway certification authority (SET PCA) 9036 (O) /SET/ A CA that issues digital certificates to payment 9037 gateways and is operated on behalf of a payment card brand, an 9038 acquirer, or another party according to brand rules. A SET PCA 9039 issues a CRL for compromised payment gateway certificates. [SET2] 9040 (See: PCA.) 9042 $ PC card 9043 (N) A type of credit card-sized, plug-in peripheral device that 9044 was originally developed to provide memory expansion for portable 9045 computers, but is also used for other kinds of functional 9046 expansion. (See: FORTEZZA, PCMCIA.) 9048 Tutorial: The international PC Card Standard defines a non- 9049 proprietary form factor in three sizes -- Types I, II and III -- 9050 each of which have a 68-pin interface between the card and the 9051 socket into which it plugs. All three types have the same length 9052 and width, roughly the size of a credit card, but differ in their 9053 thickness from 3.3 to 10.5 mm. Examples include storage modules, 9054 modems, device interface adapters, and cryptographic modules. 9056 $ PCA 9057 Deprecated Term: ISDs SHOULD NOT use this acronym without a 9058 qualifying adjective; that would be ambiguous. (See: Internet 9059 policy certification authority, (MISSI) policy creation authority, 9060 (SET) payment gateway certification authority.) 9062 $ PCMCIA 9063 (N) Personal Computer Memory Card International Association, a 9064 group of manufacturers, developers, and vendors, founded in 1989 9065 to standardize plug-in peripheral memory cards for personal 9066 computers and now extended to deal with any technology that works 9067 in the PC Card form factor. (See: PC card.) 9069 $ PDS 9070 (N) See: protective distribution system. 9072 $ peer entity authentication 9073 (I) "The corroboration that a peer entity in an association is the 9074 one claimed." [I7498 Part 2] (See: authentication.) 9076 $ peer entity authentication service 9077 (I) A security service that verifies an identity claimed by or for 9078 a system entity in an association. (See: authentication, 9079 authentication service.) 9081 Tutorial: This service is used at the establishment of, or at 9082 times during, an association to confirm the identity of one entity 9083 to another, thus protecting against a masquerade by the first 9084 entity. However, unlike data origin authentication service, this 9085 service requires an association to exist between the two entities, 9086 and the corroboration provided by the service is valid only at the 9087 current time that the service is provided. (See: ("relationship 9088 between data integrity service and authentication services" under) 9089 data integrity service). 9091 $ PEM 9092 (I) See: Privacy Enhanced Mail. 9094 $ penetrate 9095 1a. Circumvent a system's security protections. (See: attack, 9096 break, violation.) 9098 1b. (I) Successfully and repeatedly gain unauthorized access to a 9099 protected system resource. [Huff] 9101 $ penetration test 9102 (I) A system test, often part of system certification, in which 9103 evaluators attempt to circumvent the security features of a 9104 system. [NCS04, SP42] (See: tiger team.) 9106 Tutorial: Penetration testing evaluates the relative vulnerability 9107 of a system to attacks and identifies methods of gaining access to 9108 a system by using tools and techniques that are available to 9109 adversaries. Testing may be performed under various constraints 9110 and conditions, including a specified level of knowledge of the 9111 system design and implementation. For a TCSEC evaluation, testers 9112 are assumed to have all system design and implementation 9113 documentation, including source code, manuals, and circuit 9114 diagrams, and to work under no greater constraints than those 9115 applied to ordinary users. 9117 $ perfect forward secrecy 9118 (I) See: (usage discussion under) public-key forward secrecy. 9120 $ perimeter 9121 See: security perimeter. 9123 $ periods processing 9124 (I) A mode of system operation in which information of different 9125 sensitivities is processed at distinctly different times by the 9126 same system, with the system being properly purged or sanitized 9127 between periods. (See: color change.) 9129 Tutorial: The security mode of operation and maximum 9130 classification of data handled by the system is established for an 9131 interval of time and then is changed for the following interval of 9132 time. A period extends from the secure initialization of the 9133 system to the completion of any purging of sensitive data handled 9134 by the system during the period. 9136 $ permanent storage 9137 (I) Non-volatile media that, once written into, can never be 9138 completely erased. 9140 $ permission 9141 1a. (I) A synonym for "authorization". (Compare: privilege.) 9143 1b. (I) An authorization or set of authorizations to perform 9144 security-relevant functions in the context of role-based access 9145 control. [ANSI] 9147 Tutorial: A permission is a positively-stated authorization for 9148 access that (a) can be associated with one or more roles and (b) 9149 enables a user in a role to access a specified set of system 9150 resources by causing a specific set of system actions to be 9151 performed on the resources. 9153 $ persona certificate 9154 (I) An X.509 certificate issued to a system entity that wishes to 9155 use a persona to conceal its true identity when using PEM or other 9156 Internet services that depend on PKI support. (See: anonymity.) 9157 [R1422] 9159 Tutorial: PEM designers intended that (a) a CA issuing persona 9160 certificates would explicitly not be vouching for the identity of 9161 the system entity to whom the certificate is issued, (b) such 9162 certificates would be issued only by CAs subordinate to a policy 9163 CA having a policy stating that purpose (i.e., that would warn 9164 relying parties that the "subject" field DN represented only a 9165 persona and not a true, vetted user identity), and (c) the CA 9166 would not need to maintain records binding the true identity of 9167 the subject to the certificate. 9169 However, the PEM designers also intended that a CA issuing persona 9170 certificates would establish procedures (d) to enable "the holder 9171 of a PERSONA certificate to request that his certificate be 9172 revoked" and (e) to ensure that it did not issue the same subject 9173 DN to multiple users. The latter condition implies that a persona 9174 certificate is not an organizational certificate unless the 9175 organization has just one member or representative. 9177 $ personal identification number (PIN) 9178 1a. (I) A character string used as a password to gain access to a 9179 system resource. (See: authentication information.) 9181 1b. (O) An alphanumeric code or password used to authenticate an 9182 identity. 9184 Tutorial: Despite the words "identification" and "number", a PIN 9185 seldom serves as a user identifier, and a PIN's characters are not 9186 necessarily all numeric. Retail banking applications use 4-digit 9187 numeric user PINs, but the FORTEZZA PC card uses 12-character 9188 alphanumeric SSO PINs. 9190 Thus, a better name for this concept would have been "personnel 9191 authentication system string" (PASS), in which case an 9192 alphanumeric character string for this purpose would have been 9193 called, obviously, a "PASSword". 9195 $ personality 9196 1. (I) Synonym for "principal". 9198 2. (O) /MISSI/ A set of MISSI X.509 public-key certificates that 9199 have the same subject DN, together with their associated private 9200 keys and usage specifications, that is stored on a FORTEZZA PC 9201 card to support a role played by the card's user. 9203 Tutorial: When a card's user selects a personality to use in a 9204 FORTEZZA-aware application, the data determines behavior traits 9205 (the personality) of the application. A card's user may have 9206 multiple personalities on the card. Each has a "personality 9207 label", a user-friendly character string that applications can 9208 display to the user for selecting or changing the personality to 9209 be used. For example, a military user's card might contain three 9210 personalities: GENERAL HALFTRACK, COMMANDER FORT SWAMPY, and NEW 9211 YEAR'S EVE PARTY CHAIRMAN. Each personality includes one or more 9212 certificates of different types (such as DSA versus RSA), for 9213 different purposes (such as digital signature versus encryption), 9214 or with different authorizations. 9216 $ personnel authentication system string (PASS) 9217 (N) See: (Tutorial under) personal identification number. 9219 $ personnel security 9220 (I) Procedures to ensure that persons who access a system have 9221 proper clearance, authorization, and need-to-know as required by 9222 the system's security policy. 9224 $ PGP(trademark) 9225 (O) See: Pretty Good Privacy(trademark). 9227 $ Photuris 9228 (I) A UDP-based, key establishment protocol for session keys, 9229 designed for use with the IPsec protocols AH and ESP. Superseded 9230 by IKE. 9232 $ phreaking 9233 (D) A contraction of "telephone breaking". An attack on or 9234 penetration of a telephone system or, by extension, any other 9235 communication or information system. [Raym] 9237 Deprecated Term: ISDs SHOULD NOT use this contraction; it is not 9238 listed in most dictionaries and could confuse international 9239 readers. 9241 $ physical security 9242 (I) Tangible means of preventing unauthorized physical access to a 9243 system. Examples: Fences, walls, and other barriers; locks, safes, 9244 and vaults; dogs and armed guards; sensors and alarm bells. 9245 [FP031, R1455] 9247 $ piggyback attack 9248 (I) A form of active wiretapping in which the attacker gains 9249 access to a system via intervals of inactivity in another user's 9250 legitimate communication connection. Sometimes called a "between- 9251 the-lines" attack. (See: hijack attack, man-in-the-middle attack.) 9253 Deprecated Usage: This term could confuse international readers; 9254 therefore, ISDs that use it SHOULD state a definition for it. 9256 $ PIN 9257 (I) See: personal identification number. 9259 $ ping of death 9260 (D) A denial-of-service attack that sends an improperly large ICMP 9261 echo request packet (a "ping") with the intent of causing the 9262 destination system to fail. (See: ping sweep, teardrop.) 9264 Deprecated Term: ISDs SHOULD NOT use this term; instead, use "ping 9265 packet overflow attack" or some other term that is specific with 9266 regard to the attack mechanism. 9268 Tutorial: This attack seeks to exploit an implementation 9269 vulnerability. The IP specification requires hosts to be prepared 9270 to accept datagrams of up to 576 octets, but also permits IP 9271 datagrams to be up to 65,535 octets long. If an IP implementation 9272 does not properly handle very long IP packets, the ping packet may 9273 overflow the input buffer and cause a fatal system error. 9275 $ ping sweep 9276 (I) An attack that sends ICMP echo requests ("pings") to a range 9277 of IP addresses, with the goal of finding hosts that can be probed 9278 for vulnerabilities. (See: ping of death. Compare: port scan.) 9280 $ PKCS 9281 (N) See: Public-Key Cryptography Standards. 9283 $ PKCS #5 9284 (N) A standard [PKC05, R2898] from the PKCS series; defines a 9285 method for encrypting an octet string with a secret key derived 9286 from a password. 9288 Tutorial: Although the method can be used for arbitrary octet 9289 strings, its intended primary application in public-key 9290 cryptography is for encrypting private keys when transferring them 9291 from one computer system to another, as described in PKCS #8. 9293 $ PKCS #7 9294 (N) A standard [PKC07, R2315] from the PKCS series; defines a 9295 syntax for data that may have cryptography applied to it, such as 9296 for digital signatures and digital envelopes. (See: CMS.) 9298 $ PKCS #10 9299 (N) A standard [PKC10] from the PKCS series; defines a syntax for 9300 requests for public-key certificates. (See: certification 9301 request.) 9303 Tutorial: A PKCS #10 request contains a DN and a public key, and 9304 may contain other attributes, and is signed by the entity making 9305 the request. The request is sent to a CA, who converts it to an 9306 X.509 public-key certificate (or some other form), and returns it, 9307 possibly in PKCS #7 format. 9309 $ PKCS #11 9310 (N) A standard [PKC11] from the PKCS series; defines a software 9311 CAPI called Cryptoki (an abbreviation of "cryptographic token 9312 interface", pronounced "CRYPTO-key") for devices that hold 9313 cryptographic information and perform cryptographic functions. 9315 $ PKI 9316 (I) See: public-key infrastructure. 9318 $ PKIX 9319 1a. (I) A contraction of "Public-Key Infrastructure (X.509)", the 9320 name of the IETF working group that is specifying an architecture 9321 [R3280] and set of protocols [R2510] to provide X.509-based PKI 9322 services for the Internet. 9324 1b. (I) A collective name for that Internet PKI architecture and 9325 associated set of protocols. 9327 Tutorial: The goal of PKIX is to facilitate the use of X.509 9328 public-key certificates in multiple Internet applications and to 9329 promote interoperability between different implementations that 9330 use those certificates. The resulting PKI is intended to provide a 9331 framework that supports a range of trust and hierarchy 9332 environments and a range of usage environments. PKIX specifies (a) 9333 profiles of the v3 X.509 public-key certificate standards and the 9334 v2 X.509 CRL standards for the Internet, (b) operational protocols 9335 used by relying parties to obtain information such as certificates 9336 or certificate status, (c) management protocols used by system 9337 entities to exchange information needed for proper management of 9338 the PKI, and (d) information about certificate policies and CPSs, 9339 covering the areas of PKI security not directly addressed in the 9340 rest of PKIX. 9342 $ PKIX private extension 9343 (I) PKIX defines an private extension to identify an on-line 9344 verification service supporting the issuing CA. 9346 $ plain text 9347 (I) /noun/ Data that is input to and transformed by an encryption 9348 process, or that is output from a decryption process. (Compare: 9349 plaintext.) 9351 Tutorial: Usually, the plain text that is the input to an 9352 encryption operation is clear text. But in some cases, the input 9353 is cipher text that was output from another encryption operation. 9354 (See: superencryption.) 9356 $ plaintext 9357 1a. (I) /adjective/ Referring to plain text. (See: plain text.) 9359 1b. (D) /noun/ A synonym for plain text. 9361 Deprecated Usage: To avoid ambiguity, ISDs SHOULD differentiate 9362 between the noun phrase "plain text" and adjective "plaintext". 9364 $ PLI 9365 (I) See: Private Line Interface. 9367 $ Point-to-Point Protocol (PPP) 9368 (I) An Internet Standard protocol (RFC 1661) for encapsulation and 9369 full-duplex transportation of protocol data packets in OSIRM layer 9370 3 over an OSIRM layer 2 link between two peers, and for 9371 multiplexing different layer 3 protocols over the same link. 9373 Includes optional negotiation to select and use a peer entity 9374 authentication protocol to authenticate the peers to each other 9375 before they exchange layer 3 data. (See: CHAP, EAP, PAP.) 9377 $ Point-to-Point Tunneling Protocol (PPTP) 9378 (I) An Internet client-server protocol (RFC 2637) (originally 9379 developed by Ascend and Microsoft) that enables a dial-up user to 9380 create a virtual extension of the dial-up link across a network by 9381 tunneling PPP over IP. (See: L2TP.) 9383 Tutorial: PPP can encapsulate any IPS network layer protocol or 9384 OSIRM layer 3 protocol. Therefore, PPTP does not specify security 9385 services; it depends on protocols above and below it to provide 9386 any needed security. PPTP makes it possible to divorce the 9387 location of the initial dial-up server (i.e., the PPTP Access 9388 Concentrator, the client, which runs on a special-purpose host) 9389 from the location at which the dial-up protocol (PPP) connection 9390 is terminated and access to the network is provided (i.e., at the 9391 PPTP Network Server, which runs on a general-purpose host). 9393 $ policy 9394 1a. (I) A plan or course of action that is stated for a system or 9395 organization and is intended to affect and direct the decisions 9396 and deeds of that entity's components or members. (See: security 9397 policy.) 9399 1b. (O) A definite goal, course, or method of action to guide and 9400 determine present and future decisions, that is implemented or 9401 executed within a particular context, such as within a business 9402 unit. [R3198] 9404 Deprecated Usage: ISDs SHOULD NOT use "policy" as an abbreviation 9405 for either "security policy" or "certificate policy". Instead, to 9406 avoid misunderstanding, use a fully qualified term, at least at 9407 the point of first usage. 9409 Tutorial: The introduction of new technology to replace 9410 traditional systems can result in new systems being deployed 9411 without adequate policy definition and before the implications of 9412 the new technology are fully understand. In some cases, it can be 9413 difficult to establish policies for new technology before the 9414 technology has been operationally tested and evaluated. Thus, 9415 policy changes tend to lag behind technological changes, such that 9416 either old policies impede the technical innovation, or the new 9417 technology is deployed without adequate policies to govern its 9418 use. 9420 When new technology changes the ways that things are done, new 9421 "procedures" must be defined to establish operational guidelines 9422 for using the technology and achieving satisfactory results, and 9423 new "practices" must be established for managing new systems and 9424 monitoring results. Practices and procedures are more directly 9425 coupled to actual systems and business operations than are 9426 polices, which tend to be more abstract. 9427 - "Practices" define how a system is to be managed and what 9428 controls are in place to monitor the system and detect abnormal 9429 behavior or quality problems. Practices are established to 9430 ensure that a system is managed in compliance with stated 9431 policies. System audits are primarily concerned with whether or 9432 not practices are being followed. Auditors evaluate the 9433 controls to make sure they conform to accepted industry 9434 standards, and then confirm that controls are in place and that 9435 control measurements are being gathered. Audit trails are 9436 examples of control measurements that are recorded as part of 9437 system operations. 9438 - "Procedures" define how a system is operated, and relate 9439 closely to issues of what technology is used, who the operators 9440 are, and how the system is deployed physically. Procedures 9441 define both normal and abnormal operating circumstances. 9442 For every control defined by a practice statement, there should be 9443 corresponding procedures to implement the control and provide 9444 ongoing measurement of the control parameters. Conversely, 9445 procedures require management practices to insure consistent and 9446 correct operational behavior. 9448 $ policy approving authority (PAA) 9449 (O) /MISSI/ The top-level signing authority of a MISSI 9450 certification hierarchy. The term refers both to that 9451 authoritative office or role and to the person who plays that 9452 role. (See: root registry.) 9454 Tutorial: A PAA registers MISSI PCAs and signs their X.509 public- 9455 key certificates. A PAA issues CRLs but does not issue a CKL. A 9456 PAA may issue cross-certificates to other PAAs. 9458 $ policy certification authority (Internet PCA) 9459 (I) An X.509-compliant CA at the second level of the Internet 9460 certification hierarchy, under the IPRA. Each PCA operates in 9461 accordance with its published security policy (see: certificate 9462 policy, CPS) and within constraints established by the IPRA for 9463 all PCAs. [R1422]. (See: policy creation authority.) 9465 $ policy creation authority (MISSI PCA) 9466 (O) /MISSI/ The second level of a MISSI certification hierarchy; 9467 the administrative root of a security policy domain of MISSI users 9468 and other, subsidiary authorities. The term refers both to that 9469 authoritative office or role and to the person who fills that 9470 office. (See: policy certification authority.) 9472 Tutorial: A MISSI PCA's certificate is issued by a PAA. The PCA 9473 registers the CAs in its domain, defines their configurations, and 9474 issues their X.509 public-key certificates. (The PCA may also 9475 issue certificates for SCAs, ORAs, and other end entities, but a 9476 PCA does not usually do this.) The PCA periodically issues CRLs 9477 and CKLs for its domain. 9479 $ Policy Management Authority 9480 (N) Canadian usage: An organization responsible for PKI oversight 9481 and policy management in the Government of Canada. 9483 $ policy mapping 9484 (I) "Recognizing that, when a CA in one domain certifies a CA in 9485 another domain, a particular certificate policy in the second 9486 domain may be considered by the authority of the first domain to 9487 be equivalent (but not necessarily identical in all respects) to a 9488 particular certificate policy in the first domain." [X509] 9490 $ POP3 9491 (I) See: Post Office Protocol, version 3. 9493 $ POP3 APOP 9494 (I) A POP3 command (i.e., a transaction type, or a protocol- 9495 within-a-protocol) by which a POP3 client optionally uses a keyed 9496 hash (based on MD5) to authenticate itself to a POP3 server and, 9497 depending on the server implementation, to protect against replay 9498 attacks. (See: CRAM, POP3 AUTH, IMAP4 AUTHENTICATE.) 9500 Tutorial: The server includes a unique timestamp in its greeting 9501 to the client. The subsequent APOP command sent by the client to 9502 the server contains the client's name and the hash result of 9503 applying MD5 to a string formed from both the timestamp and a 9504 shared secret that is known only to the client and the server. 9505 APOP was designed to provide an alternative to using POP3's USER 9506 and PASS (i.e., password) command pair, in which the client sends 9507 a cleartext password to the server. 9509 $ POP3 AUTH 9510 (I) A POP3 command [R1734] (i.e., a transaction type, or a 9511 protocol-within-a-protocol) by which a POP3 client optionally 9512 proposes a mechanism to a POP3 server to authenticate the client 9513 to the server and provide other security services. (See: POP3 9514 APOP, IMAP4 AUTHENTICATE.) 9516 Tutorial: If the server accepts the proposal, the command is 9517 followed by performing a challenge-response authentication 9518 protocol and, optionally, negotiating a protection mechanism for 9519 subsequent POP3 interactions. The security mechanisms used by POP3 9520 AUTH are those used by IMAP4. 9522 $ port scan 9523 (I) An attack that sends client requests to a range of server port 9524 addresses on a host, with the goal of finding an active port and 9525 exploiting a known vulnerability of that service. (Compare: ping 9526 sweep.) 9528 $ positive authorization 9529 (I) The principle that a security architecture should be designed 9530 so that access to system resources is granted only in a positive 9531 way; i.e., in the absence of an explicit authorization that grants 9532 access, the default action shall be to refuse access. 9534 $ POSIX 9535 (N) Portable Operating System Interface for Computer Environments, 9536 a standard [FP151, IS9945-1] (originally IEEE Standard P1003.1) 9537 that defines an operating system interface and environment to 9538 support application portability at the source code level. It is 9539 intended to be used by both application developers and system 9540 implementers. 9542 Tutorial: P1003.1 supports security functionality like that on 9543 most UNIX systems, including discretionary access control and 9544 privileges. IEEE Draft Standard P1003.6 specifies additional 9545 functionality not provided in the base standard, including (a) 9546 discretionary access control, (b) audit trail mechanisms, (c) 9547 privilege mechanisms, (d) mandatory access control, and (e) 9548 information label mechanisms. 9550 $ Post Office Protocol, version 3 (POP3) 9551 (I) An Internet Standard protocol (RFC 1939) by which a client 9552 workstation can dynamically access a mailbox on a server host to 9553 retrieve mail messages that the server has received and is holding 9554 for the client. (See: IMAP4.) 9556 Tutorial: POP3 has mechanisms for optionally authenticating a 9557 client to a server and providing other security services. (See: 9558 POP3 APOP, POP3 AUTH.) 9560 $ PPP 9561 (I) See: Point-to-Point Protocol. 9563 $ PPTP 9564 (I) See: Point-to-Point Tunneling Protocol. 9566 $ preauthorization 9567 (I) A CAW capability that enables certification requests to be 9568 automatically validated against data provided in advance to the CA 9569 by an authorizing entity. 9571 $ precedence 9572 (N) A designation assigned to a communication (i.e., packet, 9573 message, data stream, connection, etc.) by the originator to state 9574 the importance or urgency of that communication versus other 9575 communications, and thus indicate to the transmission system the 9576 relative order of handling, and indicate to the receiver the order 9577 in which the communication is to be noted. [F1037] (See: 9578 availability, critical, preemption.) 9580 Example: The "Precedence" subfield of the "Type of Service" field 9581 of the IPv4 header supports the following designations (in 9582 descending order of importance): 111 Network Control, 110 9583 Internetwork Control, 101 CRITIC/ECP (Critical Intelligence 9584 Communication/Emergency Command Precedence), 100 Flash Override, 9585 011 Flash, 010 Immediate, 001 Priority, and 000 Routine. These 9586 designations were adopted from U.S. DoD systems that existed 9587 before ARPANET. 9589 $ preemption 9590 (N) The seizure, usually automatic, of system resources that are 9591 being used to serve a lower precedence communication, in order to 9592 serve immediately a higher precedence communication. [F1037] 9594 $ Pretty Good Privacy(trademark) (PGP(trademark)) 9595 (O) Trademarks of Network Associates, Inc., referring to a 9596 computer program (and related protocols) that uses cryptography to 9597 provide data security for electronic mail and other applications 9598 on the Internet. (Compare: MOSS, MSP, PEM, S/MIME.) 9600 Tutorial: PGP encrypts messages with IDEA in CFB mode, distributes 9601 the IDEA keys by encrypting them with RSA, and creates digital 9602 signatures on messages with MD5 and RSA. To establish ownership of 9603 public keys, PGP depends on the web of trust. 9605 $ primary account number (PAN) 9606 (O) /SET/ "The assigned number that identifies the card issuer and 9607 cardholder. This account number is composed of an issuer 9608 identification number, an individual account number 9609 identification, and an accompanying check digit as defined by ISO 9610 7812-1985." [SET2, IS7812] (See: bank identification number.) 9612 Tutorial: The PAN is embossed, encoded, or both on a magnetic- 9613 strip-based credit card. The PAN identifies the issuer to which a 9614 transaction is to be routed and the account to which it is to be 9615 applied unless specific instructions indicate otherwise. The 9616 authority that assigns the BIN part of the PAN is the American 9617 Bankers Association. 9619 $ principal 9620 (I) A specific identity claimed by a user when accessing a system. 9622 Usage: Usually understood to be an identity that is registered in 9623 and authenticated by the system; equivalent to the notion of login 9624 account identifier. Each principal is normally assigned to a 9625 single user, but a single user may be assigned (or attempt to use) 9626 more than one principal. Each principal can spawn one or more 9627 subjects, but each subject is associated with only one principal. 9628 (Compare: role, subject, user.) 9630 (N) /Kerberos/ A uniquely named client or server instance that 9631 participates in a network communication. 9633 $ privacy 9634 1. (I) The right of an entity (normally a person), acting in its 9635 own behalf, to determine the degree to which it will interact with 9636 its environment, including the degree to which the entity is 9637 willing to share information about itself with others. (See: 9638 HIPAA, Privacy Act of 1974. Compare: anonymity, data 9639 confidentiality.) 9641 2. (O) "The right of individuals to control or influence what 9642 information related to them may be collected and stored and by 9643 whom and to whom that information may be disclosed." [I7498 Part 9644 2] 9646 3. (D) Synonym for "data confidentiality". 9648 Deprecated Definition: ISDs SHOULD NOT use this term as a synonym 9649 for "data confidentiality" or "data confidentiality service", 9650 which are different concepts. Privacy is a reason for security 9651 rather than a kind of security. For example, a system that stores 9652 personal data needs to protect the data to prevent harm, 9653 embarrassment, inconvenience, or unfairness to any person about 9654 whom data is maintained, and to protect the person's privacy. For 9655 that reason, the system may need to provide data confidentiality 9656 service. 9658 $ Privacy Act of 1974 9659 (O) A U.S. Federal law (Section 552a of Title 5, United States 9660 Code) that seeks to balance the U.S. Government's need to maintain 9661 data about individuals with the rights of individuals to be 9662 protected against unwarranted invasions of their privacy stemming 9663 from federal agencies' collection, maintenance, use, and 9664 disclosure of personal data. (See: privacy.) 9666 Tutorial: In 1974, the U.S. Congress was concerned with the 9667 potential for abuses that could arise from the Government's 9668 increasing use of computers to store and retrieve personal data. 9669 Therefore, the Act has four basic policy objectives: 9670 - To restrict disclosure of personally identifiable records 9671 maintained by Federal agencies. 9672 - To grant individuals increased rights of access to Federal 9673 agency records maintained on themselves. 9674 - To grant individuals the right to seek amendment of agency 9675 records maintained on themselves upon a showing that the 9676 records are not accurate, relevant, timely, or complete. 9677 - To establish a code of "fair information practices" that 9678 requires agencies to comply with statutory norms for 9679 collection, maintenance, and dissemination of records. 9681 $ Privacy Enhanced Mail (PEM) 9682 (I) An Internet protocol to provide data confidentiality, data 9683 integrity, and data origin authentication for electronic mail. 9684 [R1421, R1422]. (Compare: MOSS, MSP, PGP, S/MIME.) 9685 Tutorial: PEM encrypts messages with DES in CBC mode, provides key 9686 distribution of DES keys by encrypting them with RSA, and signs 9687 messages with RSA over either MD2 or MD5. To establish ownership 9688 of public keys, PEM uses a certification hierarchy, with X.509 9689 public-key certificates and X.509 CRLs that are signed with RSA 9690 and MD2. 9692 PEM is designed to be compatible with a wide range of key 9693 management methods, but is limited to specifying security services 9694 only for text messages and, like MOSS, has not been widely 9695 implemented in the Internet. 9697 $ private component 9698 (I) Synonym for "private key". 9700 Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; 9701 instead, to avoid confusing readers, use "private key". However, 9702 the term MAY be used when discussing a key pair; e.g., "A key pair 9703 has a public component and a private component." 9705 $ private extension 9706 (I) See: (secondary definition under) extension. 9708 $ private key 9709 1. (I) The secret component of a pair of cryptographic keys used 9710 for asymmetric cryptography. (See: key pair, public key.) 9712 2. (O) In a public key cryptosystem, "that key of a user's key 9713 pair which is known only by that user." [X509] 9715 $ Private Line Interface (PLI) 9716 (I) The first end-to-end packet encryption system for a computer 9717 network, developed by BBN starting in 1975 for the U.S. DoD, 9718 incorporating Government-furnished, military-grade COMSEC 9719 equipment (TSEC/KG-34). [B1822] (Compare: IPLI.) 9721 $ privilege 9722 1a. (I) A synonym for "authorization". (Compare: permission.) 9724 1b. (I) An authorization or set of authorizations to perform 9725 security-relevant functions in the context of computer operating 9726 systems. 9728 Tutorial: A privilege can be modeled as (a) an action acting upon 9729 (b) an object that contains (c) attributes that can be constrained 9730 by (d) domains. 9732 $ privilege management infrastructure 9733 (O) "The infrastructure able to support the management of 9734 privileges in support of a comprehensive authorization service and 9735 in relationship with a" PKI; i.e., processes concerned with 9736 attribute certificates. [X509] 9738 Deprecated Usage: ISDs SHOULD NOT use this term; this definition 9739 is vague and there is no consensus on a more specific definition. 9741 $ privileged process 9742 (I) An computer process that is authorized (and, therefore, 9743 trusted) to perform some security-relevant functions that ordinary 9744 processes are not. (See: privilege, trusted process.) 9746 $ probe 9747 (I) /verb/ To access an information system in an attempt to gather 9748 information about the system for the purpose of circumventing the 9749 system's security measures. 9751 $ procedural security 9752 (I) Synonym for "administrative security". 9754 Deprecated Definition: ISDs SHOULD NOT use this term as a synonym 9755 for "administrative security". Any type of security may involve 9756 procedures; therefore, the term may be misleading. Instead, use 9757 "administrative security", "communication security", "computer 9758 security", "emanations security", "personnel security", "physical 9759 security", or whatever specific type is meant. (See: security 9760 architecture.) 9762 $ profile 9763 See: certificate profile, protection profile. 9765 $ proof-of-possession protocol 9766 (I) A protocol whereby a system entity proves to another that it 9767 possesses and controls a cryptographic key or other secret 9768 information. (See: zero-knowledge proof.) 9770 $ proprietary 9771 (I) Refers to information (or other property) that is owned by an 9772 individual or organization and for which the use is restricted by 9773 that entity. 9775 $ protected checksum 9776 (I) A checksum that is computed for a data object by means that 9777 protect against active attacks that would attempt to change the 9778 checksum to make it match changes made to the data object. (See: 9779 digital signature, keyed hash, (discussion under) checksum. 9781 $ protective packaging 9782 (N) Packaging techniques for COMSEC material that discourage 9783 penetration, reveal a penetration has occurred or was attempted, 9784 or inhibit viewing or copying of keying material prior to the time 9785 it is exposed for use. [C4008] (Compare: QUADRANT. See: tamper 9786 evident, tamper resistant.) 9788 $ protection authority 9789 (I) See: (secondary definition under) Internet Protocol Security 9790 Option. 9792 $ protection profile 9793 (N) /Common Criteria/ An implementation-independent set of 9794 security requirements for a category of targets of evaluation that 9795 meet specific consumer needs. [CCIB] Example: [IDSAN]. 9797 Tutorial: A protection profile (PP) is intended to be a reusable 9798 statement of product security needs, which are known to be useful 9799 and effective, for a set of information technology security 9800 products that could be built. A PP contains a set of security 9801 requirements, preferably taken from the catalogs in Parts 2 and 3 9802 of the Common Criteria, and should include an EAL. A PP could be 9803 developed by user communities, product developers, or any other 9804 parties interested in defining a common set of requirements. 9806 $ protection ring 9807 (I) One of a hierarchy of privileged operation modes of a system 9808 that gives certain access rights to processes authorized to 9809 operate in that mode. (See: Multics.) 9811 $ protective distribution system (PDS) 9812 (N) A wireline or fiber-optic communication system used to 9813 transmit cleartext classified information through an area of 9814 lesser classification or control. [N7003] 9816 $ protocol 9817 1a. (I) A set of rules (i.e., formats and procedures) to implement 9818 and control some type of association (e.g., communication) between 9819 systems. Example: Internet Protocol. 9821 1b. (I) A series of ordered computing and communication steps that 9822 are performed by two or more system entities to achieve a joint 9823 objective. [A9042] 9825 $ protocol suite 9826 (I) A complementary collection of communication protocols used in 9827 a computer network. (See: Internet, OSI.) 9829 $ proxy 9830 1. (I) A computer process that acts on behalf of a user or client. 9832 2. (I) A computer process -- often used as, or as part of, a 9833 firewall -- that relays a protocol between client and server 9834 computer systems, by appearing to the client to be the server and 9835 appearing to the server to be the client. (See: SOCKS.) 9837 Tutorial: In a firewall, a proxy server usually runs on a bastion 9838 host, which may support proxies for several protocols (e.g., FTP, 9839 HTTP, and TELNET). Instead of a client in the protected enclave 9840 connecting directly to an external server, the internal client 9841 connects to the proxy server which in turn connects to the 9842 external server. The proxy server waits for a request from inside 9843 the firewall, forwards the request to the server outside the 9844 firewall, gets the response, then sends the response back to the 9845 client. The proxy may be transparent to the clients, or they may 9846 need to connect first to the proxy server, and then use that 9847 association to also initiate a connection to the real server. 9849 Proxies are generally preferred over SOCKS for their ability to 9850 perform caching, high-level logging, and access control. A proxy 9851 can provide security service beyond that which is normally part of 9852 the relayed protocol, such as access control based on peer entity 9853 authentication of clients, or peer entity authentication of 9854 servers when clients do not have that capability. A proxy at OSIRM 9855 layer 7 can also provide finer-grained security service than can a 9856 filtering router at layer 3. For example, an FTP proxy could 9857 permit transfers out of, but not into, a protected network. 9859 $ proxy certificate 9860 (I) An X.509 public-key certificate derived from a end-entity 9861 certificate, or from another proxy certificate, for the purpose of 9862 establishing proxies and delegating authorizations in the context 9863 of a PKI-based authentication system. [R3280] 9865 Tutorial: A proxy certificate has the following properties: 9866 - It contains an critical extension that (a) identifies it as a 9867 proxy certificate and (b) may contain a certification path 9868 length constraint and policy constraints. 9869 - It contains the public component of a key pair that is distinct 9870 from that associated with any other certificate. 9871 - It is signed by the private component of a key pair that is 9872 associated with an end-entity certificate or another proxy 9873 certificate. 9874 - Its associated private key can be used to sign only other proxy 9875 certificates (not end-entity certificates). 9876 - Its "subject" DN is derived from its "issuer" DN and is unique. 9877 - Its "issuer" DN is the "subject" DN of an end-entity 9878 certificate or another proxy certificate. 9880 $ pseudorandom 9881 (I) A sequence of values that appears to be random (i.e., 9882 unpredictable) but is actually generated by a deterministic 9883 algorithm. (See: compression, random, random number generator.) 9885 $ pseudorandom number generator 9886 See: random number generator. 9888 $ public component 9889 (I) Synonym for "public key". 9891 Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; to 9892 avoid confusing readers, use "private key" instead. However, the 9893 term MAY be used when discussing a key pair; e.g., "A key pair has 9894 a public component and a private component." 9896 $ public key 9897 1. (I) The publicly-disclosable component of a pair of 9898 cryptographic keys used for asymmetric cryptography. (See: key 9899 pair, private key.) 9901 2. (O) In a public key cryptosystem, "that key of a user's key 9902 pair which is publicly known." [X509] 9904 $ public-key certificate 9905 1. (I) A digital certificate that binds a system entity's identity 9906 to a public key value, and possibly to additional, secondary data 9907 items; i.e., a digitally-signed data structure that attests to the 9908 ownership of a public key. (See: X.509 public-key certificate.) 9910 2. (O) "The public key of a user, together with some other 9911 information, rendered unforgeable by encipherment with the private 9912 key of the certification authority which issued it." [X509] 9914 Tutorial: The digital signature on a public-key certificate is 9915 unforgeable. Thus, the certificate can be published, such as by 9916 posting it in a directory, without the directory having to protect 9917 the certificate's data integrity. 9919 $ public-key cryptography 9920 (I) The popular synonym for "asymmetric cryptography". 9922 $ Public-Key Cryptography Standards (PKCS) 9923 (N) A series of specifications published by RSA Laboratories for 9924 data structures and algorithm used in basic applications of 9925 asymmetric cryptography. (See: PKCS #5 through PKCS #11.) 9927 Tutorial: The PKCS were begun in 1991 in cooperation with industry 9928 and academia, originally including Apple, Digital, Lotus, 9929 Microsoft, Northern Telecom, Sun, and MIT. Today, the 9930 specifications are widely used, but they are not sanctioned by an 9931 official standards organization, such as ANSI, ITU-T, or IETF. RSA 9932 Laboratories retains sole decision-making authority over the PKCS. 9934 $ public-key forward secrecy (PFS) 9935 (I) For a key agreement protocol based on asymmetric cryptography, 9936 the property that ensures that a session key derived from a set of 9937 long-term public and private keys will not be compromised if one 9938 of the private keys is compromised in the future. 9940 Usage: Some existing RFCs use the term "perfect forward secrecy" 9941 but either do not define it or do not define it precisely. While 9942 preparing this Glossary, we tried to find a good definition for 9943 that term, but found this to be a muddled area. Experts did not 9944 agree. For all practical purposes, the literature defines "perfect 9945 forward secrecy" by stating the Diffie-Hellman algorithm. The term 9946 "public-key forward secrecy" (suggested by Hilarie Orman) and the 9947 "I" definition stated for it here were crafted to be compatible 9948 with current Internet documents, yet be narrow and leave room for 9949 improved terminology. 9951 Challenge to the Internet security community: We need a taxonomy 9952 -- a family of mutually exclusive and collectively exhaustive 9953 terms and definitions to cover the basic properties discussed here 9954 -- for the full range of cryptographic algorithms and protocols 9955 used in Internet Standards: 9957 Involvement of session keys vs. long-term keys: Experts disagree 9958 about the basic ideas involved: 9959 - One concept of "forward secrecy" is that, given observations of 9960 the operation of a key establishment protocol up to time t, and 9961 given some of the session keys derived from those protocol 9962 runs, you cannot derive unknown past session keys or future 9963 session keys. 9964 - A related property is that, given observations of the protocol 9965 and knowledge of the derived session keys, you cannot derive 9966 one or more of the long-term private keys. 9967 - The "I" definition presented above involves a third concept of 9968 "forward secrecy" that refers to the effect of the compromise 9969 of long-term keys. 9970 - All three concepts involve the idea that a compromise of "this" 9971 encryption key is not supposed to compromise the "next" one. 9972 There also is the idea that compromise of a single key will 9973 compromise only the data protected by the single key. In 9974 Internet literature, the focus has been on protection against 9975 decryption of back traffic in the event of a compromise of 9976 secret key material held by one or both parties to a 9977 communication. 9979 Forward vs. backward: Experts are unhappy with the word "forward", 9980 because compromise of "this" encryption key also is not supposed 9981 to compromise the "previous" one, which is "backward" rather than 9982 forward. In S/KEY, if the key used at time t is compromised, then 9983 all keys used prior to that are compromised. If the "long-term" 9984 key (i.e., the base of the hashing scheme) is compromised, then 9985 all keys past and future are compromised; thus, you could say that 9986 S/KEY has neither forward nor backward secrecy. 9988 Asymmetric cryptography vs. symmetric: Experts disagree about 9989 forward secrecy in the context of symmetric cryptographic systems. 9990 In the absence of asymmetric cryptography, compromise of any long- 9991 term key seems to compromise any session key derived from the 9992 long-term key. For example, Kerberos isn't forward secret, because 9993 compromising a client's password (thus compromising the key shared 9994 by the client and the authentication server) compromises future 9995 session keys shared by the client and the ticket-granting server. 9997 Ordinary forward secrecy vs. "perfect" forward secret: Experts 9998 disagree about the difference between these two. Some say there is 9999 no difference, and some say that the initial naming was 10000 unfortunate and suggest dropping the word "perfect". Some suggest 10001 using "forward secrecy" for the case where one long-term private 10002 key is compromised, and adding "perfect" for when both private 10003 keys (or, when the protocol is multi-party, all private keys) are 10004 compromised. 10006 Acknowledgements: Bill Burr, Burt Kaliski, Steve Kent, Paul Van 10007 Oorschot, Michael Wiener, and, especially, Hilarie Orman 10008 contributed ideas to this discussion. 10010 $ public-key infrastructure (PKI) 10011 1. (I) A system of CAs (and, optionally, RAs and other supporting 10012 servers and agents) that perform some set of certificate 10013 management, archive management, key management, and token 10014 management functions for a community of users in an application of 10015 asymmetric cryptography. (See: hierarchical PKI, mesh PKI, 10016 security management infrastructure, trust-file PKI.) 10018 2. (I) /PKIX/ The set of hardware, software, people, policies, and 10019 procedures needed to create, manage, store, distribute, and revoke 10020 digital certificates based on asymmetric cryptography. 10022 Tutorial: The core PKI functions are (a) to register users and 10023 issue their public-key certificates, (b) to revoke certificates 10024 when required, and (c) to archive data needed to validate 10025 certificates at a much later time. Key pairs for data 10026 confidentiality may be generated (and perhaps escrowed) by CAs or 10027 RAs, but requiring a PKI client to generate its own digital 10028 signature key pair helps maintain system integrity of the 10029 cryptographic system, because then only the client ever possesses 10030 the private key it uses. Also, an authority may be established to 10031 approve or coordinate CPSs, which are security policies under 10032 which components of a PKI operate. 10034 A number of other servers and agents may support the core PKI, and 10035 PKI clients may obtain services from them. The full range of such 10036 services is not yet fully understood and is evolving, but 10037 supporting roles may include archive agent, certified delivery 10038 agent, confirmation agent, digital notary, directory, key escrow 10039 agent, key generation agent, naming agent who ensures that issuers 10040 and subjects have unique identifiers within the PKI, repository, 10041 ticket-granting agent, and time stamp agent. 10043 $ purge 10044 (I) Use degaussing or other means to render (magnetically) stored 10045 data unusable and unrecoverable by any means, including laboratory 10046 methods. [C4009] (See: zeroize. Compare: erase, sanitize.) 10048 $ QUADRANT 10049 (O) /U.S. Government/ Short name for technology and methods that 10050 protect cryptographic equipment by making the equipment tamper- 10051 resistant. [C4009] (Compare: protective packaging, TEMPEST.) 10053 Tutorial: Equipment cannot be made completely tamper-proof, but it 10054 can be made tamper-resistant or tamper-evident. 10056 $ qualified certificate 10057 (I) A public-key certificate that has the primary purpose of 10058 identifying a person with a high level of assurance, where the 10059 certificate meets some qualification requirements defined by an 10060 applicable legal framework, such as the European Directive on 10061 Electronic Signature [EU-ESDIR]. [R3739]. 10063 $ RA 10064 (I) See: registration authority. 10066 $ RA domains 10067 (I) A capability of a CAW that allows a CA to divide the 10068 responsibility for certificate requests among multiple RAs. 10070 Tutorial: This capability might be used to restrict access to 10071 private authorization data that is provided with a certificate 10072 request, and to distribute the responsibility to review and 10073 approve certificate requests in high volume environments. RA 10074 domains might segregate certificate requests according to an 10075 attribute of the certificate subject, such as an organizational 10076 unit. 10078 $ RADIUS 10079 (I) See: Remote Authentication Dial-In User Service. 10081 $ Rainbow Series 10082 (O) A set of more than 30 technical and policy documents with 10083 colored covers, issued by the NCSC, that discuss in detail the 10084 TCSEC and provide guidance for meeting and applying the criteria. 10085 (See: Green Book, Orange Book, Red Book, Yellow Book.) 10087 $ random 10088 (I) In essence, "random" means "unpredictable". [SP22, Knut, 10089 R1750] (See: cryptographic key, pseudorandom.) 10090 - "Random sequence": A sequence in which each successive value is 10091 obtained merely by chance and does not depend on the preceding 10092 values of the sequence. In a random sequence of bits, each bit 10093 is unpredictable; i.e., (a) the probability of each bit being a 10094 "0" or "1" is 1/2, and (b) the value of each bit is independent 10095 of any other bit in the sequence. 10096 - "Random value": A individual value that is unpredictable; i.e., 10097 each value in the total population of possibilities has equal 10098 probability of being selected. 10100 $ random number generator 10101 (I) A process that is invoked to generate a random sequence of 10102 values (usually a sequence of bits) or an individual random value. 10104 Tutorial: There are two basic types of generators. [SP22] 10105 - (True) random number generator: Uses one or more non- 10106 deterministic bit sources (usually physical phenomena; e.g., 10107 electrical circuit noise, timing of user processes such as key 10108 strokes or mouse movements, semiconductor quantum effects) and 10109 some processing function that formats the bits; and outputs an 10110 sequence of values that is unpredictable and uniformly 10111 distributed. 10112 - Pseudorandom number generator: Uses a deterministic 10113 computational process (usually implemented by software) that 10114 has one or more inputs called "seeds"; and outputs a sequence 10115 of values that appears to be random according to specified 10116 statistical tests. 10118 $ RBAC 10119 (N) See: role-based access control, rule-based access control. 10121 Deprecated Usage: This abbreviation is ambiguous; therefore, ISDs 10122 that use it SHOULD state a definition for it. 10124 $ RC2, RC4, RC6 10125 (N) See: Rivest Cipher #2, #4, #6. 10127 $ read 10128 (I) A fundamental operation in an information system that results 10129 only in the flow of information from an object to a subject. (See: 10130 access mode.) 10132 $ realm 10133 (O) /Kerberos/ The domain of authority of a Kerberos server 10134 (consisting of an authentication server and a ticket-granting 10135 server), including the Kerberized clients and the Kerberized 10136 application servers 10138 $ recovery 10139 1. (I) /cryptography/ The process of learning or obtaining 10140 cryptographic data or plain text through cryptanalysis. (See: key 10141 recovery, data recovery.) 10143 2a. (I) /system integrity/ The process of restoring a secure state 10144 in a system after there has been an accidental failure or a 10145 successful attack. (See: system integrity.) 10147 2b. (I) /system integrity/ The process of restoring an information 10148 system's assets and operation following damage or destruction. 10149 (See: contingency plan.) 10151 $ RED 10152 1. (I) Designation for data that consists only of clear text, and 10153 for information system equipment items and facilities that handle 10154 only clear text. Example: "RED key". (Compare: BLACK. See: color 10155 change, RED/BLACK separation.) 10157 Derivation: From the practice of marking equipment with colors to 10158 prevent operational errors. 10160 2. (O) /U.S. Government/ Designation applied to information 10161 systems, and to associated areas, circuits, components, and 10162 equipment, "in which unencrypted national security information is 10163 being processed." [C4009] 10165 $ RED/BLACK separation 10166 (I) An architectural concept for cryptographic systems that 10167 strictly separates the parts of a system that handle plain text 10168 (i.e., RED information) from the parts that handle cipher text 10169 (i.e., BLACK information). (See: BLACK, RED.) 10171 $ Red Book 10172 (D) Synonym for "Trusted Network Interpretation of the Trusted 10173 Computer System Evaluation Criteria" [NCS05]. 10175 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 10176 "Trusted Network Interpretation of the Trusted Computer System 10177 Evaluation Criteria". Instead, use the full proper name of the 10178 document or, in subsequent references, a more conventional 10179 abbreviation. (See: TCSEC, Rainbow Series, (Deprecated Usage 10180 under) Green Book.) 10182 $ RED key 10183 (I) A key that is usable in its present form without any 10184 additional decryption. (Compare: BLACK key. See: RED.) 10186 $ reference monitor 10187 (I) "An access control concept that refers to an abstract machine 10188 that mediates all accesses to objects by subjects." [NCS04] (See: 10189 security kernel.) 10191 Tutorial: This concept was described in the Anderson report. A 10192 reference monitor should be (a) complete (i.e., it mediates every 10193 access), (b) isolated (i.e., it cannot be modified by other system 10194 entities), and (c) verifiable (i.e., small enough to be subjected 10195 to analysis and tests to ensure that it is correct). 10197 $ reflection attack 10198 (I) An attack in which a valid data transmission is maliciously or 10199 fraudulently retransmitted, either by an adversary who intercepts 10200 the data or by its originator. (Compare: replay attack.) 10202 $ registration 10203 1. (I) A system process that (a) initializes an identity in the 10204 system, (b) establishes an identifier for that identity, (c) may 10205 associate authentication information with that identifier, and (d) 10206 may issue an identifier credential (depending on the type of 10207 authentication mechanism being used). (See: authentication 10208 information, credential, identifier, identity.) 10210 2. (I) /PKI/ An administrative act or process whereby an entity's 10211 name and other attributes are established for the first time at a 10212 CA, prior to the CA issuing a digital certificate that has the 10213 entity's name as the subject. (See: registration authority.) 10215 Tutorial: Registration may be accomplished either directly, by the 10216 CA, or indirectly, by a separate RA. An entity is presented to the 10217 CA or RA, and the authority either records the name(s) claimed for 10218 the entity or assigns the entity's name(s). The authority also 10219 determines and records other attributes of the entity that are to 10220 be bound in a certificate (such as a public key or authorizations) 10221 or maintained in the authority's database (such as street address 10222 and telephone number). The authority is responsible, possibly 10223 assisted by an RA, for verifying the entity's identity and vetting 10224 the other attributes, in accordance with the CA's CPS. 10226 Among the registration issues that a CPS may address are the 10227 following [R2527]: 10228 - How a claimed identity and other attributes are verified. 10229 - How organization affiliation or representation is verified. 10230 - What forms of names are permitted, such as X.500 DN, domain 10231 name, or IP address. 10232 - Whether names are required to be meaningful or unique, and 10233 within what domain. 10234 - How naming disputes are resolved, including the role of 10235 trademarks. 10236 - Whether certificates are issued to entities that are not 10237 persons. 10238 - Whether a person is required to appear before the CA or RA, or 10239 can instead be represented by an agent. 10240 - Whether and how an entity proves possession of the private key 10241 matching a public key. 10243 $ registration authority (RA) 10244 1. (I) An optional PKI entity (separate from the CAs) that does 10245 not sign either digital certificates or CRLs but has 10246 responsibility for recording or verifying some or all of the 10247 information (particularly the identities of subjects) needed by a 10248 CA to issue certificates and CRLs and to perform other certificate 10249 management functions. (See: ORA, registration.) 10251 2. (I) /PKIX/ An optional PKI component, separate from the CA(s). 10252 The functions that the RA performs will vary from case to case but 10253 may include identity authentication and name assignment, key 10254 generation and archiving of key pairs, token distribution, and 10255 revocation reporting. [R2510] 10257 Tutorial: Sometimes, a CA may perform all certificate management 10258 functions for all end users for which the CA signs certificates. 10259 Other times, such as in a large or geographically dispersed 10260 community, it may be necessary or desirable to offload secondary 10261 CA functions and delegate them to an assistant, while the CA 10262 retains the primary functions (signing certificates and CRLs). The 10263 tasks that are delegated to an RA by a CA may include personal 10264 authentication, name assignment, token distribution, revocation 10265 reporting, key generation, and archiving. An RA is an optional PKI 10266 component, separate from the CA, that is assigned secondary 10267 functions. The duties assigned to RAs vary from case to case but 10268 may include the following: 10269 - Verifying a subject's identity, i.e., performing personal 10270 authentication functions. 10271 - Assigning a name to a subject. (See: distinguished name.) 10272 - Verifying that a subject is entitled to have the attributes 10273 requested for a certificate. 10274 - Verifying that a subject possesses the private key that matches 10275 the public key requested for a certificate. 10276 - Performing functions beyond mere registration, such as 10277 generating key pairs, distributing tokens, and handling 10278 revocation reports. (Such functions may be assigned to a PKI 10279 component that is separate from both the CA and the RA.) 10281 3. (O) /SET/ "An independent third-party organization that 10282 processes payment card applications for multiple payment card 10283 brands and forwards applications to the appropriate financial 10284 institutions." [SET2] 10286 $ regrade 10287 (I) Deliberately change the classification level of information in 10288 an authorized manner. (See: downgrade, upgrade.) 10290 $ rekey 10291 (I) Change the value of a cryptographic key that is being used in 10292 an application of a cryptographic system. (See: certificate 10293 rekey.) 10295 Tutorial: Rekey is required at the end of a cryptoperiod or key 10296 lifetime. 10298 $ reliability 10299 (I) The ability of a system to perform a required function under 10300 stated conditions for a specified period of time. (Compare: 10301 availability, survivability.) 10303 $ reliable human review 10304 (I) Any manual, automated, or hybrid process or procedure for 10305 opening and reviewing a digital object, such as text or an image, 10306 to determine whether the object may be permitted, according to 10307 some security policy, to be transferred across a controlled 10308 interface. (See: guard.) 10310 $ relying party 10311 (I) Synonym for "certificate user". 10313 Usage: Used in a legal context to mean a recipient of a 10314 certificate who acts in reliance on that certificate. (See: ABA 10315 Guidelines.) 10317 $ remanence 10318 (I) Residual information that can be recovered from a storage 10319 medium after clearing. (See: clear, magnetic remanence, purge.) 10321 $ Remote Authentication Dial-In User Service (RADIUS) 10322 (I) An Internet protocol [R2138] for carrying dial-in users' 10323 authentication information and configuration information between a 10324 shared, centralized authentication server (the RADIUS server) and 10325 a network access server (the RADIUS client) that needs to 10326 authenticate the users of its network access ports. (See: TACACS.) 10328 Tutorial: A user of the RADIUS client presents authentication 10329 information to the client, and the client passes that information 10330 to the RADIUS server. The server authenticates the client using a 10331 shared secret value, then checks the user's authentication 10332 information, and finally returns to the client all authorization 10333 and configuration information needed by the client to deliver 10334 service to the user. 10336 $ renew 10337 See: certificate renewal. 10339 $ replay attack 10340 (I) An attack in which a valid data transmission is maliciously or 10341 fraudulently repeated, either by the originator or by an adversary 10342 who intercepts the data and retransmits it, possibly as part of a 10343 masquerade attack. (See: active wiretapping. Compare: reflection 10344 attack.) 10346 $ repository 10347 1. (I) A system for storing and distributing digital certificates 10348 and related information (including CRLs, CPSs, and certificate 10349 policies) to certificate users. (See: archive, directory.) 10351 2. (O) "A trustworthy system for storing and retrieving 10352 certificates or other information relevant to certificates." [ABA] 10354 Tutorial: A certificate is published to those who might need it by 10355 putting it in a repository. The repository usually is a publicly 10356 accessible, on-line server. In the Federal Public-key 10357 Infrastructure, for example, the expected repository is a 10358 directory that uses LDAP, but also may be the X.500 Directory that 10359 uses DAP, or an HTTP server, or an FTP server that permits 10360 anonymous login. 10362 $ repudiation 10363 1. (I) Denial by a system entity that was involved in an 10364 association (especially an association that transfers information) 10365 of having participated in the relationship. (See: accountability, 10366 non-repudiation service.) 10368 2. (I) A type of threat action whereby an entity deceives another 10369 by falsely denying responsibility for an act. (See: deception.) 10371 Usage: This type of threat action includes the following subtypes: 10372 - False denial of origin: Action whereby an originator denies 10373 responsibility for sending data. 10374 - False denial of receipt: Action whereby a recipient denies 10375 receiving and possessing data. 10377 3. (O) /OSIRM/ "Denial by one of the entities involved in a 10378 communication of having participated in all or part of the 10379 communication." [I7498 Part 2] 10381 $ Request for Comment (RFC) 10382 (I) One of the documents in the archival series that is the 10383 official channel for ISDs and other publications of the Internet 10384 Engineering Steering Group, the Internet Architecture Board, and 10385 the Internet community in general. [R2026, R2223] (See: Internet 10386 Standard.) 10388 Deprecated Usage: This term is NOT a synonym for "Internet 10389 Standard". 10391 $ residual risk 10392 (I) The portion of an original risk or set of risks that remains 10393 after countermeasures have been applied. (Compare: acceptable 10394 risk, risk analysis.) 10396 $ restore 10397 See: card restore. 10399 $ revocation 10400 See: certificate revocation. 10402 $ revocation date 10403 (N) /X.509/ In a CRL entry, a date-time field that states when the 10404 certificate revocation occurred, i.e., when the CA declared the 10405 digital certificate to be invalid. (See: invalidity date.) 10407 Tutorial: The revocation date may not resolve some disputes 10408 because, in the worst case, all signatures made during the 10409 validity period of the certificate may have to be considered 10410 invalid. However, it may be desirable to treat a digital signature 10411 as valid even though the private key used to sign was compromised 10412 after the signing. If more is known about when the compromise 10413 actually occurred, a second date-time, an "invalidity date", can 10414 be included in an extension of the CRL entry. 10416 $ revocation list 10417 See: certificate revocation list. 10419 $ revoke 10420 (I) See: certificate revocation. 10422 $ RFC 10423 (I) See: Request for Comment. 10425 $ Rijndael 10426 (I) A block cipher, designed by Joan Daemen and Vincent Rijmen as 10427 a candidate algorithm for the AES. [Daem] 10429 $ risk 10430 1. (I) An expectation of loss expressed as the probability that a 10431 particular threat will exploit a particular vulnerability with a 10432 particular harmful result. 10434 2. (O) /SET/ "The possibility of loss because of one or more 10435 threats to information (not to be confused with financial or 10436 business risk)." [SET2] 10438 $ risk analysis 10439 (I) An assessment process that systematically (a) identifies 10440 valuable system resources and threats to those resources, (b) 10441 quantifies loss exposures (i.e., loss potential) based on 10442 estimated frequencies and costs of occurrence, and (c) 10443 (optionally) recommends how to allocate resources to 10444 countermeasures so as to minimize total exposure. (See: risk 10445 management.) 10447 Tutorial: There are four basic options for dealing with a risk 10448 [SP30]: 10449 - Risk avoidance: Eliminate the risk either by countering the 10450 threat or removing the vulnerability. 10451 - Risk transference: Shift the risk to another system or system 10452 entity, such as by buying insurance to compensate for loss. 10453 - Risk limitation: Limit the risk by implementing controls that 10454 minimize the resulting loss. 10455 - Risk assumption: Accept the potential for loss and continue 10456 operating the system. 10458 Usually, it is financially and technically infeasible to avoid or 10459 transfer all risks (see: (first corollary of second law under) 10460 Courtney's laws), and so some residual risk will remain, even 10461 after all available countermeasures have been deployed (see: 10463 (second corollary of second law under) Courtney's laws). Thus, a 10464 risk analysis typically lists risks in order of cost and 10465 criticality, thereby determining where countermeasures should be 10466 applied first. [FP031, R2196] 10468 In some contexts, it is infeasible to do a risk analysis because 10469 needed data and resources are not available, or it is inadvisable. 10470 Instead, answers to questions about threats and risks may be 10471 already built into basic institutional security policies. For 10472 example, U.S. DoD policies for data confidentiality "do not 10473 explicitly itemize the range of expected threats" but instead 10474 "reflect an operational approach ... by stating the particular 10475 management controls that must be used to achieve [confidentiality] 10476 severe risk in itself, and avoid the risk of poor security design 10477 implicit in taking a fresh approach to each new problem". [NRC91] 10479 $ risk management 10480 1. (I) The process of identifying, measuring, and controlling 10481 (i.e., mitigating) risks in information systems so as to reduce 10482 the risks to a level commensurate with the value of the assets 10483 protected. (See: risk analysis.) 10485 2. (I) The process of controlling uncertain events that may affect 10486 information system resources. 10488 3. (O) "The total process of identifying, controlling, and 10489 mitigating information system-Drelated risks. It includes risk 10490 assessment; cost-benefit analysis; and the selection, 10491 implementation, test, and security evaluation of safeguards. This 10492 overall system security review considers both effectiveness and 10493 efficiency, including impact on the mission and constraints due to 10494 policy, regulations, and laws." [SP30] 10496 $ Rivest Cipher #2 (RC2) 10497 (N) A proprietary, variable-key-length block cipher invented by 10498 Ron Rivest for RSA Data Security, Inc. 10500 $ Rivest Cipher #4 (RC4) 10501 (N) A proprietary, variable-key-length stream cipher invented by 10502 Ron Rivest for RSA Data Security, Inc. 10504 $ Rivest Cipher #6 (RC6) 10505 (N) A block cipher with 128-bit or higher key size; invented by 10506 Ron Rivest for RSA Data Security, Inc. A finalist in the 10507 competition for AES. 10509 $ Rivest-Shamir-Adleman (RSA) 10510 (N) An algorithm for asymmetric cryptography, invented in 1977 by 10511 Ron Rivest, Adi Shamir, and Leonard Adleman [RSA78]. 10513 Tutorial: RSA uses exponentiation modulo the product of two large 10514 prime numbers. The difficulty of breaking RSA is believed to be 10515 equivalent to the difficulty of factoring integers that are the 10516 product of two large prime numbers of approximately equal size. 10518 To create an RSA key pair, randomly choose two large prime 10519 numbers, p and q, and compute the modulus, n = pq. Randomly choose 10520 a number e, the public exponent, that is less than n and 10521 relatively prime to (p-1)(q-1). Choose another number d, the 10522 private exponent, such that ed-1 evenly divides (p-1)(q-1). The 10523 public key is the set of numbers (n,e), and the private key is the 10524 set (n,d). 10526 It is assumed to be difficult to compute the private key (n,d) 10527 from the public key (n,e). However, if n can be factored into p 10528 and q, then the private key d can be computed easily. Thus, RSA 10529 security depends on the assumption that it is computationally 10530 difficult to factor a number that is the product of two large 10531 prime numbers. (Of course, p and q are treated as part of the 10532 private key, or else are destroyed after computing n.) 10534 For encryption of a message, m, to be sent to Bob, Alice uses 10535 Bob's public key (n,e) to compute m**e (mod n) = c. She sends c to 10536 Bob. Bob computes c**d (mod n) = m. Only Bob knows d, so only Bob 10537 can compute c**d (mod n) to recover m. 10539 To provide data origin authentication of a message, m, to be sent 10540 to Bob, Alice computes m**d (mod n) = s, where (d,n) is Alice's 10541 private key. She sends m and s to Bob. To recover the message that 10542 only Alice could have sent, Bob computes s**e (mod n) = m, where 10543 (e,n) is Alice's public key. 10545 To ensure data integrity in addition to data origin authentication 10546 requires extra computation steps in which Alice and Bob use a 10547 cryptographic hash function h (see: digital signature). Alice 10548 computes the hash value h(m) = v, and then encrypts v with her 10549 private key to get s. She sends m and s. Bob receives m' and s', 10550 either of which might have been changed from the m and s that 10551 Alice sent. To test this, he decrypts s' with Alice's public key 10552 to get v'. He then computes h(m') = v". If v' equals v", Bob is 10553 assured that m' is the same m that Alice sent. 10555 $ robustness 10556 (N) See: level of robustness. 10558 $ role 10559 1. (I) A job function (or a job title that implies a set of 10560 functions) to which people or other system entities are assigned, 10561 within an organization or other system. (Compare: duty, billet, 10562 principal, user. See: role-based access control.) 10564 2. (O) /Common Criteria/ A pre-defined set of rules establishing 10565 the allowed interactions between a user and the TOE. 10567 $ role-based access control 10568 (I) A form of identity-based access control wherein the system 10569 entities that are identified and controlled are functional 10570 positions in an organization or process. [Sand] (See: 10571 authorization, constraint, identity, principal, role.) 10573 Tutorial: Administrators assign permissions to roles as needed to 10574 perform functions in the system. Administrators separately assign 10575 user identities to roles. When a user accesses the system in an 10576 identity (for which the user has been registered) and initiates a 10577 session using a role (to which the user has been assigned), then 10578 the permissions that have been assigned to the role are available 10579 to be exercised by the user. 10581 The following diagram shows that role-based access control 10582 involves five types relationships. Administrators assign (a) 10583 identities to roles, (b) permissions to roles, and (c) roles to 10584 roles; and users select (d) identities in sessions, and (e) roles 10585 in sessions. Security policies may define constraints on these 10586 assignments and selections. 10588 (c) Permission Inheritance Assignments (i.e., Role Hierarchy) 10589 [Constraints] 10590 +=====+ 10591 | | 10592 (a) Identity v v (b) Permission 10593 +----------+ Assignments +-------+ Assignments +----------+ 10594 |Identities|<=============>| Roles |<=============>|Permissions| 10595 +----------+ [Constraints] +-------+ [Constraints] +----------+ 10596 | | ^ ^ 10597 | | +-----------+ | | +---------------------+ 10598 | | | +-------+ | | | | Legend | 10599 | +====>|Session|=====+ | | | 10600 | | +-------+ | | | One-to-One | 10601 | | ... | | | =================== | 10602 | | +-------+ | | | | 10603 +========>|Session|=========+ | One-to-Many | 10604 (d) Identity | +-------+ | (e) Role | ==================> | 10605 Selections | | Selections | | 10606 [Constraints]| Access |[Constraints] | Many-to-Many | 10607 | Sessions | | <=================> | 10608 +-----------+ +---------------------+ 10610 $ role certificate 10611 (I) An organizational certificate that is issued to a system 10612 entity that is a member of the set of users that have identities 10613 that are assigned to a particular role. (See: role-based access 10614 control.) 10616 $ root 10617 1. (I) A CA that is directly trusted by an end entity. 10619 2. (I) /hierarchical PKI/ The CA that is the highest level (most 10620 trusted) CA in a certification hierarchy; i.e., the authority upon 10621 whose public key all certificate users base their validation of 10622 certificates, CRLs, certification paths, and other constructs. 10623 (See: top CA.) 10625 Tutorial: The root CA in a certification hierarchy issues public- 10626 key certificates to one or more additional CAs that form the 10627 second highest level. Each of these CAs may issue certificates to 10628 more CAs at the third highest level, and so on. To initialize 10629 operation of a hierarchical PKI, the root's initial public key is 10630 securely distributed to all certificate users in a way that does 10631 not depend on the PKI's certification relationships, i.e., by an 10632 out-of-band procedure. The root's public key may be distributed 10633 simply as a numerical value, but typically is distributed in a 10634 self-signed certificate in which the root is the subject. The 10635 root's certificate is signed by the root itself because there is 10636 no higher authority in a certification hierarchy. The root's 10637 certificate is then the first certificate in every certification 10638 path. 10640 3. (O) /MISSI/ A name previously used for a MISSI policy creation 10641 authority, which is not a root as defined above for general usage, 10642 but is a CA at the second level of the MISSI hierarchy, 10643 immediately subordinate to a MISSI policy approving authority. 10645 4. (O) /UNIX/ A user account (also called "superuser") that has 10646 all privileges (including all security-related privileges) and 10647 thus can manage the system and its other user accounts. 10649 5. (O) /DNS/ The base of the tree structure that defines the name 10650 space for the Internet DNS. (See: domain name.) 10652 $ root certificate 10653 1. (I) A certificate for which the subject is a root. 10655 2. (I) /hierarchical PKI/ The self-signed public-key certificate 10656 at the top of a certification hierarchy. 10658 $ root key 10659 (I) A public key for which the matching private key is held by a 10660 root. 10662 $ root registry 10663 (O) /MISSI/ A name previously used for a MISSI PAA. 10665 $ ROT13 10666 (I) See: Caeser cipher. 10668 $ router 10669 1. (I) /IP/ A networked computer that forwards IP packets that are 10670 not addressed to the computer itself. (Compare: host.) 10671 2. (I) /OSIRM/ A computer that is a gateway between two networks 10672 at OSIRM layer 3 and that relays and directs data packets through 10673 that internetwork. The most common form of router operates on IP 10674 packets. (Compare: bridge, proxy.) 10676 $ RSA 10677 (N) See: Rivest-Shamir-Adleman. 10679 $ rule 10680 See: security rule. 10682 $ rule-based security policy 10683 (I) "A security policy based on global rules imposed for all 10684 users. These rules usually rely on comparison of the sensitivity 10685 of the resource being accessed and the possession of corresponding 10686 attributes of users, a group of users, or entities acting on 10687 behalf of users." [I7498 Part 2] (Compare: identity-based security 10688 policy, RBAC.) 10690 $ rules of behavior 10691 (I) A body of security policy that has been established and 10692 implemented concerning the responsibilities and expected behavior 10693 of entities that have access to a system. (Compare: [R1281].) 10695 Tutorial: For persons employed by a corporation or government, the 10696 rules might cover such matters as working at home, remote access, 10697 use of the Internet, use of copyrighted works, use of system 10698 resources for unofficial purpose, assignment and limitation of 10699 system privileges, and individual accountability. 10701 $ S field 10702 (D) See: Security Level field. 10704 $ S-BGP 10705 (I) See: Secure BGP. 10707 $ S-HTTP 10708 (I) See: Secure Hypertext Transfer Protocol. 10710 $ S/Key 10711 (I) A security mechanism that uses a cryptographic hash function 10712 to generate a sequence of 64-bit, one-time passwords for remote 10713 user login. [R1760] 10715 Tutorial: The client generates a one-time password by applying the 10716 MD4 cryptographic hash function multiple times to the user's 10717 secret key. For each successive authentication of the user, the 10718 number of hash applications is reduced by one. (Thus, an intruder 10719 using wiretapping cannot compute a valid password from knowledge 10720 of one previously used.) The server verifies a password by hashing 10721 the currently presented password (or initialization value) one 10722 time and comparing the hash result with the previously presented 10723 password. 10725 $ S/MIME 10726 (I) See: Secure/MIME. 10728 $ SAD 10729 (I) See: Security Association Database. 10731 $ safety 10732 (I) The property of a system being free from risk of causing harm 10733 (especially physical harm) to its system entities. (Compare: 10734 security.) 10736 $ SAID 10737 (I) See: security association identifier. 10739 $ salt 10740 (I) A data value used to vary the results of a computation in a 10741 security mechanism, so that an exposed computational result from 10742 one instance of applying the mechanism cannot be reused by an 10743 attacker in another instance. (Compare: initialization value.) 10745 Example: A password-based access control mechanism might protect 10746 against capture or accidental disclosure of its password file by 10747 applying a one-way encryption algorithm to passwords before 10748 storing them in the file. To increase the difficulty of off-line, 10749 dictionary attacks that match encrypted values of potential 10750 passwords against a copy of the password file, the mechanism can 10751 concatenate each password with its own random salt value before 10752 applying the one-way function. 10754 $ SAML 10755 (N) See: Security Assertion Markup Language (SAML). 10757 $ sandbox 10758 (I) A restricted, controlled execution environment that prevents 10759 potentially malicious software, such as mobile code, from 10760 accessing any system resources except those for which the software 10761 is authorized. 10763 $ sanitize 10764 (I) Delete sensitive data from a file, a device, or a system; or 10765 modify data so as to be able to downgrade its classification 10766 level. 10768 $ SAP 10769 (O) See: special access program. 10771 $ SASL 10772 (I) See: Simple Authentication and Security Layer. 10774 $ SCA 10775 (I) See: subordinate certification authority. 10777 $ scavenging 10778 (I) See: (secondary definition under) threat consequence. 10780 $ SCI 10781 (O) See: sensitive compartmented information. 10783 $ SCIF 10784 (O) See: sensitive compartmented information facility. 10786 $ SCOMP 10787 (N) Secure COMmunications Processor; an enhanced, MLS version of 10788 the Honeywell Level 6 minicomputer. It was the first system to be 10789 rated in TCSEC Class A1. (See: KSOS.) 10791 $ screen room 10792 (I) /slang/ Synonym for "shielded enclosure". 10794 $ screening router 10795 (I) Synonym for "filtering router". 10797 $ script kiddy 10798 (D) /slang/ A cracker who is able to use existing attack 10799 techniques (i.e., to read scripts) and execute existing attack 10800 software, but is unable to invent new exploits or manufacture the 10801 tools to perform them; pejoratively, an immature or novice 10802 cracker. (See: packet monkey.) 10804 Deprecated Term: It is likely that other cultures have different 10805 metaphors for this concept. Therefore, to ensure international 10806 understanding, ISDs SHOULD NOT use this term. (See: (Deprecated 10807 Usage under) Green Book.) 10809 $ SDE 10810 (N) See: Secure Data Exchange. 10812 $ SDNS 10813 (O) See: Secure Data Network System. 10815 $ seal 10816 1. (I) To use asymmetric cryptography to encrypt plain text with a 10817 public key in such a way that only the holder of the matching 10818 private key can learn what was the plain text. [Chau] 10820 Usage: The definition is not widely known; therefore, ISDs that 10821 use this term SHOULD state a definition for it. 10823 Tutorial: The definition does *not* say "only the holder of the 10824 matching private key can decrypt the ciphertext to learn what was 10825 the plaintext"; sealing is stronger than that. If Alice simply 10826 encrypts a plaintext P with a public key K to produce ciphertext C 10827 = K(P), then if Bob guesses that P = X, Bob could verify the guess 10828 by checking whether K(P) = K(X). To "seal" P and block Bob's 10829 guessing attack, Alice could attach a long string R of random bits 10830 to P before encrypting to produce C = K(P,R); if Bob guesses that 10831 P = X, Bob can only test the guess by also guessing R. 10833 2. (D) To use cryptography to provide data integrity service for a 10834 data object. (See: sign.) 10836 Deprecated Definition: ISDs SHOULD NOT use this term with this 10837 definition. Instead, use a term that is more specific with regard 10838 to the mechanism(s) used to provide the data integrity service; 10839 e.g., use "sign" when the mechanism is digital signature. 10841 $ secret 10842 1a. (I) /adjective/ The condition of information being protected 10843 from being known by any system entities except those that are 10844 intended to know it. 10846 1b. (I) /noun/ An item of information that is protected thusly. 10848 Usage: This term applies to symmetric keys, private keys, and 10849 passwords. 10851 $ secret-key cryptography 10852 (D) Synonym for "symmetric cryptography". 10854 Deprecated Term: ISDs SHOULD NOT use this term; it could be 10855 confused with asymmetric cryptography, in which the private key is 10856 secret. 10858 Derivation: Symmetric cryptography is sometimes called "secret-key 10859 cryptography" because entities that share the key, such as the 10860 originator and the recipient of a message, need to keep the key 10861 secret from other entities. 10863 $ Secure BGP (S-BGP) 10864 (I) A project of BBN Technologies, sponsored by the U.S. DoD's 10865 Defense Advanced Research Projects Agency, to design and 10866 demonstrate an architecture to secure the Border Gateway Protocol 10867 (RFC 1771) and to promote deployment of that architecture in the 10868 Internet. 10870 Tutorial: S-BGP incorporates three security mechanisms: 10871 - A PKI supports authentication of ownership of IP address 10872 blocks, autonomous system (AS) numbers, an AS's identity, and a 10873 BGP router's identity and its authorization to represent an AS. 10874 This PKI parallels and takes advantage of the Internet's 10875 existing IP address and AS number assignment system. 10876 - A new, optional, BGP transitive path attribute carries digital 10877 signatures (in "attestations") covering the routing information 10878 in a BGP UPDATE. These signatures along with certificates from 10879 the S-BGP PKI enable the receiver of a BGP routing UPDATE to 10880 verify the address prefixes and path information that it 10881 contains. 10882 - IPsec provides data and partial sequence integrity, and enables 10883 BGP routers to authenticate each other for exchanges of BGP 10884 control traffic. 10886 $ Secure Data Exchange (SDE) 10887 (N) A LAN security protocol defined by the IEEE 802.10 standard. 10889 $ Secure Data Network System (SDNS) 10890 (O) An NSA program that developed security protocols for 10891 electronic mail (see: MSP), OSIRM layer 3 (see: SP3), OSIRM layer 10892 4 (see: SP4), and key management (see: KMP). 10894 $ Secure Hash Algorithm (SHA) 10895 (N) A cryptographic hash function (specified in SHS) that produces 10896 a 160-bit output (hash result) for input data of any length < 10897 2**64 bits. 10899 $ Secure Hash Standard (SHS) 10900 (N) The U.S. Government standard [FP180] that specifies SHA. 10902 $ Secure Hypertext Transfer Protocol (S-HTTP) 10903 (I) A Internet protocol (RFC 2660) for providing client-server 10904 security services for HTTP communications. (Compare: https.) 10906 Tutorial: S-HTTP was originally specified by CommerceNet, a 10907 coalition of businesses interested in developing the Internet for 10908 commercial uses. Several message formats may be incorporated into 10909 S-HTTP clients and servers, particularly CMS and MOSS. S-HTTP 10910 supports choice of security policies, key management mechanisms, 10911 and cryptographic algorithms through option negotiation between 10912 parties for each transaction. S-HTTP supports modes of operation 10913 for both asymmetric and symmetric cryptography. S-HTTP attempts to 10914 avoid presuming a particular trust model, but it attempts to 10915 facilitate multiply-rooted hierarchical trust and anticipates that 10916 principals may have many public-key certificates. 10918 $ Secure/MIME (S/MIME) 10919 (I) Secure/Multipurpose Internet Mail Extensions, an Internet 10920 protocol (RFC 3851) to provide encryption and digital signatures 10921 for Internet mail messages. 10923 $ secure multicast 10924 (I) Refers generally to providing security services for multicast 10925 groups of various types (e.g., 1-to-N and M-to-N) and to classes 10926 of protocols used to protect multicast packets. 10928 Tutorial: Multicast applications include video broadcast and 10929 multicast file transfer, and many of these applications require 10930 network security services. The Multicast Security Reference 10931 Framework [R3740] covers three functional areas: 10932 - Multicast data handling: Security-related treatment of 10933 multicast data by the sender and the receiver. 10934 - Group key management: Secure distribution and refreshment of 10935 keying material. (See: Group Domain of Interpretation.) 10936 - Multicast security policy: Policy translation and 10937 interpretation across the multiple administrative domains that 10938 typically are spanned by a multicast application. 10940 $ Secure Shell(trademark) (SSH(trademark)) 10941 (N) Trademarks of SSH Communications Security Corp. that refer to 10942 a protocol for secure remote login and other secure network 10943 services. 10945 Tutorial: SSH has three main parts: 10946 - Transport layer protocol: Provides server authentication, 10947 confidentiality, and integrity; and can optionally provide 10948 compression. This layer typically runs over a TCP/IP 10949 connection, but might also run on top of any other reliable 10950 data stream. 10951 - User authentication protocol: Authenticates the client-side 10952 user to the server. It runs over the transport layer protocol. 10953 - Connection protocol: Multiplexes the encrypted tunnel into 10954 several logical channels. It runs over the user authentication 10955 protocol. 10957 $ Secure Sockets Layer (SSL) 10958 (N) An Internet protocol (originally developed by Netscape 10959 Communications, Inc.) that uses connection-oriented end-to-end 10960 encryption to provide data confidentiality service and data 10961 integrity service for traffic between a client (often a web 10962 browser) and a server, and that can optionally provide peer entity 10963 authentication between the client and the server. (See: Transport 10964 Layer Security.) 10966 Tutorial: The name misleadingly suggests that SSL is situated in 10967 the IPS transport layer, but SSL is layered above a reliable 10968 transport protocol (usually TCP) and below an application protocol 10969 (often HTTP). SSL is independent of the application it 10970 encapsulates, and any higher level protocol can layer on top of 10971 SSL transparently. However, many Internet applications might be 10972 better served by IPsec. 10974 SSL has two layers: (a) SSL's lower layer, the SSL Record 10975 Protocol, is layered on top of the transport protocol and 10976 encapsulates higher level protocols. One such encapsulated 10977 protocol is SSL Handshake Protocol. (b) SSL's upper layer provides 10978 asymmetric cryptography for server authentication (verifying the 10979 server's identity to the client) and optional client 10980 authentication (verifying the client's identity to the server), 10981 and also enables them, before the application protocol transmits 10982 or receives data, to negotiate a symmetric encryption algorithm 10983 and secret session key (to use for data confidentiality service) 10984 and a keyed hash (to use for data integrity service). 10986 $ secure state 10987 1a. (I) A system condition in which the system is in conformance 10988 with the applicable security policy. (Compare: clean system, 10989 transaction.) 10991 1b. (I) /formal model/ A system condition in which no subject can 10992 access any object in an unauthorized manner. (See: (secondary 10993 definition under) Bell-LaPadula model.) 10995 $ security 10996 1a. (I) A system condition that results from the establishment and 10997 maintenance of measures to protect the system. 10999 1b. (I) A system condition in which system resources are free from 11000 unauthorized access and from unauthorized or accidental change, 11001 destruction, or loss. (Compare: safety.) 11003 2. (I) Measures taken to protect a system. 11005 Tutorial: Providing a condition of system security may involve the 11006 following six basic functions [Park]: 11007 - "Avoidance": Reducing a risk by either reducing the value of 11008 the potential loss or reducing the probability that the loss 11009 will occur. (See: risk, risk analysis.) 11010 - "Deterrence": Reducing an intelligent threat by discouraging 11011 action, such as by fear or doubt. (See: attack, threat action.) 11012 - "Prevention": Impeding a security violation by using a 11013 countermeasure. 11014 - "Detection": Determining that a security violation is 11015 impending, is in progress, or has recently occurred, and thus 11016 make it possible to reduce the potential loss. (See: intrusion 11017 detection.) 11018 - "Recovery": Restoring a normal state of system operation by 11019 compensating for a security violation, possibly by eliminating 11020 or repairing its effects. (See: contingency plan.) 11021 - "Correction": Changing a security architecture to eliminate or 11022 reduce the risk of reoccurrence of a security violation or 11023 threat consequence. 11025 $ security architecture 11026 (I) A plan and set of principles that describe (a) the security 11027 services that a system is required to provide to meet the needs of 11028 its users, (b) the system components required to implement the 11029 services, and (c) the performance levels required in the 11030 components to deal with the threat environment. (See: defense in 11031 depth, IATF, (Tutorial under) security policy. Compare: system 11032 architecture.) 11033 Tutorial: A security architecture is the result of applying the 11034 system engineering process. A complete system security 11035 architecture includes administrative security, communication 11036 security, computer security, emanations security, personnel 11037 security, and physical security (e.g., see: [R2179]). A complete 11038 security architecture needs to deal with both intentional, 11039 intelligent threats and accidental threats. 11041 $ Security Assertion Markup Language (SAML) 11042 (N) A protocol consisting of XML-based request and response 11043 message formats for exchanging security information, expressed in 11044 the form of assertions about subjects, between online business 11045 partners. [SAML] 11047 $ security association 11048 1. (I) A relationship established between two or more entities to 11049 enable them to protect data they exchange. (See: association, 11050 ISAKMP, SAD. Compare: session.) 11052 Tutorial: The relationship is represented by a set of data that is 11053 shared between the entities and is agreed upon and considered a 11054 contract between them. The data describes how the associated 11055 entities jointly use security services. The relationship is used 11056 to negotiate characteristics of security mechanisms, but the 11057 relationship is usually understood to exclude the mechanisms 11058 themselves. 11060 2. (O) "A set of policy and cryptographic keys that provide 11061 security services to network traffic that matches that policy". 11062 [R3740] (See: cryptographic association, group security 11063 association.) 11065 3. (O) /IPsec/ A simplex (uni-directional) logical connection 11066 created for security purposes and implemented with either AH or 11067 ESP (but not both). The security services offered by a security 11068 association depend on the protocol (AH or ESP), the IPsec mode 11069 (transport or tunnel), the endpoints, and the election of optional 11070 services within the protocol. A security association is identified 11071 by a triple consisting of (a) a destination IP address, (b) a 11072 protocol (AH or ESP) identifier, and (c) a Security Parameter 11073 Index. 11075 4. (O) "The totality of communications and security mechanisms and 11076 functions (e.g., communications protocols, security protocols, 11077 security mechanisms and functions) that securely binds together 11078 two security contexts in different end systems or relay systems 11079 supporting the same information domain." [DGSA] 11081 $ Security Association Database (SAD) 11082 (I) In an IPsec implementation operating in a network node, a 11083 database that contains parameters to describe the status and 11084 operation of each of the active security associations that the 11085 node has established with other nodes. Separate inbound and 11086 outbound SADs are needed because of the directionality of IPsec 11087 security associations. [R2401] (Compare: SPD.) 11089 $ security association identifier (SAID) 11090 (I) A data field in a security protocol (such as NLSP or SDE), 11091 used to identify the security association to which a protocol data 11092 unit is bound. The SAID value is usually used to select a key for 11093 decryption or authentication at the destination. (See: Security 11094 Parameter Index.) 11096 $ security assurance 11097 1. (I) An attribute of an information system that provides grounds 11098 for having confidence that the system operates such that the 11099 system security policy is enforced. (Compare: trust.) 11101 2. (I) A procedure that ensures a system is developed and operated 11102 as intended by the system's security policy. 11104 3. (D) "The degree of confidence one has that the security 11105 controls operate correctly and protect the system as intended." 11106 [SP12] 11108 Deprecated Definition: ISDs SHOULD NOT use definition 3; it is a 11109 definition for "assurance level" rather than for "assurance". 11111 4. (D) /U.S. Government, identity authentication/ The (a) "degree 11112 of confidence in the vetting process used to establish the 11113 identity of the individual to whom the [identity] credential was 11114 issued" and (b) "the degree of confidence that the individual who 11115 uses the credential is the individual to whom the credential was 11116 issued". [M0404] 11118 Deprecated Definition: ISDs SHOULD NOT use definition 4; it mixes 11119 concepts in a potentially misleading way. Part "a" is a definition 11120 for "assurance level" (rather than "security assurance") of an 11121 identity registration process; and part "b" is a definition for 11122 "assurance level" (rather than "security assurance") of such a 11123 process. Also, the processes of registration and authentication 11124 should be defined and designed separately to ensure clarity in 11125 certification. 11127 $ security audit 11128 (I) An independent review and examination of a system's records 11129 and activities to determine the adequacy of system controls, 11130 ensure compliance with established security policy and procedures, 11131 detect breaches in security services, and recommend any changes 11132 that are indicated for countermeasures. [I7498 Part 2, NCS01] 11133 (Compare: accounting, intrusion detection.) 11135 Tutorial: The basic audit objective is to establish accountability 11136 for system entities that initiate or participate in security- 11137 relevant events and actions. Thus, means are needed to generate 11138 and record a security audit trail and to review and analyze the 11139 audit trail to discover and investigate attacks and security 11140 compromises. 11142 $ security audit trail 11143 (I) A chronological record of system activities that is sufficient 11144 to enable the reconstruction and examination of the sequence of 11145 environments and activities surrounding or leading to an 11146 operation, procedure, or event in a security-relevant transaction 11147 from inception to final results. [NCS04] (See: security audit.) 11149 $ security by obscurity 11150 (O) Attempting to maintain or increase security of a system by 11151 keeping secret the design or construction of a security mechanism. 11153 Tutorial: This approach has long been discredited in cryptography, 11154 where the phrase refers to trying to keep an algorithm secret, 11155 rather than just concealing the keys [Schn]. One must assume that 11156 mass-produced or widely fielded cryptographic devices eventually 11157 will be lost or stolen and, therefore, that the algorithms will be 11158 reverse engineered and become known to the adversary. Thus, one 11159 should rely only on algorithms and protocols that are strong 11160 enough to have been published widely, and have been peer reviewed 11161 for long enough that their flaws have been found and removed. For 11162 example, NIST used a long, public process to select AES to replace 11163 DES. 11165 In computer and network security, the principle of "no security by 11166 obscurity" also applies to security mechanisms other than 11167 cryptography. For example, if a protocol for access control, or 11168 for identification and authentication, is really good, than 11169 reading the protocol's source code should not enable you to find a 11170 way to evade the protection and penetrate the system. 11172 $ security class 11173 (D) Synonym for "security level". 11175 Deprecated Term: ISDs SHOULD NOT use this term. Instead, use 11176 "security level", which is more widely established and understood. 11178 $ security clearance 11179 (I) A determination that a person is eligible, under the standards 11180 of a specific security policy, for authorization to access 11181 sensitive information or other system resources. (See: clearance 11182 level.) 11184 $ security compromise 11185 (I) A security violation in which a system resource is exposed, or 11186 is potentially exposed, to unauthorized access. (Compare: data 11187 compromise, exposure, violation.) 11189 $ security doctrine 11190 1. (I) A specified set of procedures or practices that direct or 11191 provide guidance for how to comply with security policy. (Compare: 11192 security mechanism, security policy.) 11194 Tutorial: Security policy and security doctrine are relative 11195 terms: policy deals mainly with strategy, and doctrine deals with 11196 tactics. 11198 Security doctrine is often understood to refer mainly to 11199 administrative security, personnel security, and physical 11200 security. For example, security mechanisms and devices that 11201 implement them are normally designed to operate in a limited range 11202 of environmental and administrative conditions, and these 11203 conditions must be met to complement and ensure the technical 11204 protection afforded by the hardware, firmware, and software in the 11205 devices. Security doctrine specifies how to achieve those 11206 conditions. (See: (first law under) Courtney's laws.) 11208 $ security domain 11209 (I) See: domain. 11211 $ security environment 11212 (I) The set of external entities, procedures, and conditions that 11213 affect secure development, operation, and maintenance of a system. 11214 (See: (first law under) Courtney's laws.) 11216 $ security event 11217 (I) A occurrence in a system that is relevant to the security of 11218 the system. (See: security incident.) 11220 Tutorial: The term covers both events that are security incidents 11221 and those that are not. In a CA workstation, for example, a list 11222 of security events might include the following: 11223 - Logging the operator in or out. 11224 - Performing a cryptographic operation, e.g., signing a digital 11225 certificate or CRL. 11226 - Performing a cryptographic card operation: creation, insertion, 11227 removal, or backup. 11228 - Performing a digital certificate lifecycle operation: rekey, 11229 renewal, revocation, or update. 11230 - Posting information to an X.500 Directory. 11231 - Receiving a key compromise notification. 11232 - Receiving an improper certification request. 11233 - Detecting an alarm condition reported by a cryptographic 11234 module. 11235 - Failing a built-in hardware self-test or a software system 11236 integrity check. 11238 $ security fault analysis 11239 (I) A security analysis, usually performed on hardware at a logic 11240 gate level, gate-by-gate, to determine the security properties of 11241 a device when a hardware fault is encountered. 11243 $ security gateway 11244 1. (I) An internetwork gateway that separates trusted (or 11245 relatively more trusted) hosts on one side from untrusted (or less 11246 trusted) hosts on the other side. (See: firewall and guard.) 11248 2. (O) /IPsec/ "An intermediate system that implements IPsec 11249 protocols." [R2401] 11251 Tutorial: IPsec's AH or ESP can be implemented on a gateway 11252 between a protected network and an unprotected network, in order 11253 to provide security services to the protected network's hosts when 11254 they communicate across the unprotected network to other hosts and 11255 gateways. 11257 $ security incident 11258 1. (I) A security event that involves a security violation. (See: 11259 CERT, GRIP, security event, security intrusion. See: security 11260 violation.) 11262 Tutorial: In other words, a security-relevant system event in 11263 which the system's security policy is disobeyed or otherwise 11264 breached. 11266 2. (O) "Any adverse event [that] compromises some aspect of 11267 computer or network security." [R2350] 11269 Deprecated Definition: ISDs SHOULD NOT use this "O" definition, 11270 because (a) a security incident may occur without actually being 11271 harmful (i.e., adverse) and (b) this Glossary defines "compromise" 11272 more narrowly in relation to unauthorized access. 11274 3. (O) "A violation or imminent threat of violation of computer 11275 security policies, acceptable use policies, or standard computer 11276 security practices." [SP61] 11278 Deprecated Definition: ISDs SHOULD NOT use this "O" definition, 11279 because mixes concepts in way that does not agree with common 11280 usage; a security incident is commonly thought of as involving a 11281 realization of a threat (see: threat action), not just a threat. 11283 $ security intrusion 11284 (I) A security event, or a combination of multiple security 11285 events, that constitutes a security incident in which an intruder 11286 gains, or attempts to gain, access to a system (or system 11287 resource) without having authorization to do so. 11289 $ security kernel 11290 (I) "The hardware, firmware, and software elements of a trusted 11291 computing base that implement the reference monitor concept. It 11292 must mediate all accesses, be protected from modification, and be 11293 verifiable as correct." [NCS04] (See: kernel, TCB.) 11295 Tutorial: A security kernel is an implementation of a reference 11296 monitor for a given hardware base. [Huff] 11298 $ security label 11299 (I) An item of meta-data that designates the value of one or more 11300 security-relevant attributes (e.g., security level) of a system 11301 resource. (Compare: security marking. See: [R1457].) 11303 Deprecated usage: To avoid confusion, ISDs SHOULD NOT use 11304 "security label" for "security marking", or vice versa, even 11305 though that is commonly done (including in some national and 11306 international standards that should know better). 11308 Tutorial: Humans and automated security mechanisms use a security 11309 label of a system resource to determine, according to applicable 11310 security policy, how to control access to the resource (and they 11311 affix appropriate, matching security markings to physical 11312 instances of the resource). Security labels are most often used to 11313 support data confidentiality policy, and sometimes used to support 11314 data integrity policy. 11316 As explained in [R1457], the form that is taken by security labels 11317 of a protocol's packets varies depending on the OSIRM layer in 11318 which the protocol operates. Like meta-data generally, a security 11319 label of a data packet may be either explicit (e.g., IPSO) or 11320 implicit (e.g., Alice treats all messages received from Bob as 11321 being labeled "Not For Public Release"). In a connectionless 11322 protocol, every packet might have an explicit label; but in a 11323 connection-oriented protocol, all packets might have the same 11324 implicit label that is determined at the time the connection is 11325 established. 11327 Both classified and unclassified system resources may require a 11328 security label. (See: FOUO.) 11330 $ security level 11331 (I) The combination of a hierarchical classification level and a 11332 set of non-hierarchical category designations that represents how 11333 sensitive a specified type or item of information is. (See: 11334 (Deprecated Usage note under) classification level, dominate, 11335 lattice model.) 11337 Usage: The term is usually understood to refer to sensitivity to 11338 disclosure, but also is used in many other ways and could easily 11339 be misunderstood; therefore, ISDs that use this term SHOULD state 11340 a definition for it. 11342 $ Security Level field 11343 (I) A 16-bit field (the "S field") that specifies a security level 11344 value in the security option (option type 130) of version 4 IP's 11345 datagram header format. 11347 Deprecated Abbreviation: ISDs SHOULD NOT use the abbreviation "S 11348 field", which is potentially ambiguous. Instead, use "Security 11349 Level field". 11351 $ security management infrastructure (SMI) 11352 (I) System components and activities that support security policy 11353 by monitoring and controlling security services and mechanisms, 11354 distributing security information, and reporting security events. 11356 Tutorial: The associated functions are as follows [I7498-4]: 11357 - Controlling (granting or restricting) access to system 11358 resources: This includes verifying authorizations and 11359 identities, controlling access to sensitive security data, and 11360 modifying access priorities and procedures in the event of 11361 attacks. 11362 - Retrieving (gathering) and archiving (storing) security 11363 information: This includes logging security events and 11364 analyzing the log, monitoring and profiling usage, and 11365 reporting security violations. 11366 - Managing and controlling the encryption process: This includes 11367 performing the functions of key management and reporting on key 11368 management problems. (See: PKI.) 11370 $ security marking 11371 (I) A physical marking that is bound to an instance of a system 11372 resource and that represents a security label of the resource, 11373 i.e., that names or designates the value of one or more security- 11374 relevant attributes of the resource. (Compare: security label.) 11376 Tutorial: A security label may be represented by various 11377 equivalent markings depending on the physical form taken by the 11378 labeled resource. For example, a document could have a marking 11379 composed of a bit pattern [FP188] when the document is stored 11380 electronically as a file in a computer, and also a marking of 11381 printed alphabetic characters when the document is in paper form. 11383 $ security mechanism 11384 (I) A process (or a device incorporating such a process) that can 11385 be used in a system to implement a security service that is 11386 provided by or within the system. (See: (discussion under) 11387 security policy. Compare: security doctrine.) 11389 Usage: Usually understood to refer primarily to components of 11390 communication security, computer security, and emanation security. 11392 Examples: Authentication exchange, checksum, digital signature, 11393 encryption, and traffic padding. 11395 $ security model 11396 (I) A schematic description of a set of entities and relationships 11397 by which a specified set of security services are provided by or 11398 within a system. Example: Bell-LaPadula model. (See: (discussion 11399 under) security policy.) 11401 $ security parameters index (SPI) 11402 (I) /IPsec/ A 32-bit identifier used to distinguish among security 11403 associations that terminate at the same destination (IP address) 11404 and use the same security protocol (AH or ESP). Carried in AH and 11405 ESP to enable the receiving system to determine under which 11406 security association to process a received packet. 11408 (I) /mobile IP/ A 32-bit index identifying a security association 11409 between a pair of nodes, from among the collection of associations 11410 between them that are available for application to mobile IP 11411 protocol messages that they exchange. 11413 $ security perimeter 11414 (I) A physical or logical boundary that is defined for a domain or 11415 enclave and within which a particular security policy or security 11416 architecture applies. (See: insider, outsider.) 11418 $ security policy 11419 1a. (I) A set of security principles or rules that direct how a 11420 system or organization provides security services to protect 11421 sensitive and critical system resources. (See: identity-based 11422 security policy, policy rule, rule-based security policy, rules of 11423 behavior. Compare: security architecture, security doctrine, 11424 security mechanism, security model, [R1281].) 11426 1b. (O) /X.509/ A set of security rules laid down by an authority 11427 to govern the use and provision of security services and 11428 facilities. 11430 2. (O) /Common Criteria/ A set of rules that regulate how assets 11431 are managed, protected, and distributed within a TOE. 11433 Tutorial: Ravi Sandhu notes that security policy is one of four 11434 layers of the security engineering process (as shown in the 11435 following diagram). Each layer provides a different view of 11436 security, ranging from what services are needed to how services 11437 are implemented. From a security architect~Os perspective, a 11438 security policy is the requirements specification for designing an 11439 adequately secure system. 11441 What Security Services Should Be Provided? 11442 ^ 11443 | + - - - - - - - - - - - + 11444 | | Security Policy | 11445 | + - - - - - - - - - - - + + - - - - - - - - - - - - - - + 11446 | | Security Model | | A "top-level specification" | 11447 | + - - - - - - - - - - - + <- | is at a level below "model" | 11448 | | Security Architecture | | but above "architecture". | 11449 | + - - - - - - - - - - - + + - - - - - - - - - - - - - - + 11450 | | Security Mechanism | 11451 | + - - - - - - - - - - - + 11452 v 11453 How Are Security Services Implemented? 11455 Rob Shirey suggests that another way to think about Sandhu's 11456 layers is to say that statements of security policy vary in their 11457 degree of abstraction according to the perspectives of the 11458 participants in system design, development, and operation 11459 activities: 11460 - Mission functions view: Has perspective of user of information 11461 system resources. States time-phased protection needs for 11462 system resources and identifies sensitive and critical 11463 resources -- networks, hosts, applications, and databases. 11464 Independent of rules and practices used to achieve protection. 11465 - Domain practices view: Has perspective of enterprise manager 11466 who sets protection standards for resources. States rules and 11467 practices for protection. Identifies domain members; i.e., 11468 entities (users/providers) and resources (including data 11469 objects). Independent of system topology. Not required to be 11470 hierarchical. 11471 - Enclave services view: Has perspective of system designer who 11472 allocates security functions to major components. Assigns 11473 security services to system topology structures and their 11474 contents. Independent of security mechanisms. Hierarchical 11475 across all domains. 11476 - Agent mechanisms view: Has perspective of system engineer who 11477 specifies security mechanisms to implement security services. 11478 Specifies mechanisms to be used by protocol, database, and 11479 application engines. Independent of type and manufacture of 11480 platforms and other physical devices. 11481 - Platform devices view: Has perspective of as-built description 11482 of the system in operation. Specifies exactly how to build or 11483 assemble the system, and also specifies procedures for 11484 operating the system. 11486 $ Security Policy Database (SPD) 11487 (I) In an IPsec implementation operating in a network node, a 11488 database that contains parameters that specify policies set by a 11489 user or administrator to determine what IPsec services, if any, 11490 are to be provided to IP datagrams sent or received by the node, 11491 and in what fashion they are provided. For each datagram, the SPD 11492 specifies one of three choices: discard the datagram, apply IPsec 11493 services (e.g., AH or ESP), or bypass IPsec. Separate inbound and 11494 outbound SPDs are needed because of the directionality of IPsec 11495 security associations. [R2401] (Compare: SAD.) 11497 $ Security Protocol 3 (SP3) 11498 (O) A protocol [SDNS3] developed by SDNS to provide connectionless 11499 data security at the top of OSIRM layer 3. (Compare: IPsec, NLSP.) 11501 $ Security Protocol 4 (SP4) 11502 (O) A protocol [SDNS4] developed by SDNS to provide either 11503 connectionless or end-to-end connection-oriented data security at 11504 the bottom of OSIRM layer 4. (See: TLSP.) 11506 $ security-relevant event 11507 (D) See: security event. 11509 $ security rule 11510 (I) A building block of a security policy; it defines (a) a set of 11511 system conditions and (b) a set of system actions that are to be 11512 performed if those conditions occur. [R3198] 11514 $ security service 11515 1. (I) A processing or communication service that is provided by a 11516 system to give a specific kind of protection to system resources. 11517 (See: access control service, audit service, availability service, 11518 data confidentiality service, data integrity service, data origin 11519 authentication service, non-repudiation service, peer entity 11520 authentication service, system integrity service.) 11522 Tutorial: Security services implement security policies, and are 11523 implemented by security mechanisms. 11525 2. (O) "A service, provided by a layer of communicating open 11526 systems, which ensures adequate security of the systems or the 11527 data transfers." [I7498 Part 2] 11529 $ security situation 11530 (I) ISAKMP usage: The set of all security-relevant information -- 11531 e.g., network addresses, security classifications, manner of 11532 operation (normal or emergency) -- that is needed to decide the 11533 security services that are required to protect the association 11534 that is being negotiated. 11536 $ security target 11537 (N) /Common Criteria/ A set of security requirements and 11538 specifications to be used as the basis for evaluation of an 11539 identified TOE. 11541 Tutorial: An security target (ST) is a statement of security 11542 claims for a particular information technology security product or 11543 system, and is the basis for agreement among all parties as to 11544 what security the product or system offers. An ST parallels the 11545 structure of an protection profile, but has additional elements 11546 that include product-specific detailed information. An ST contains 11547 a summary specification, which defines the specific measures taken 11548 in the product or system to meet the security requirements. 11550 $ security token 11551 (I) See: token. 11553 $ security violation 11554 (I) An act or event that disobeys or otherwise breaches security 11555 policy. (See: compromise, penetration, security incident.) 11557 $ seed 11558 (I) A value that is an input to a pseudorandom number generator. 11560 $ self-signed certificate 11561 (I) A public-key certificate for which the public key bound by the 11562 certificate and the private key used to sign the certificate are 11563 components of the same key pair, which belongs to the signer. 11564 (Compare: root certificate.) 11566 Tutorial: In a self-signed X.509 public-key certificate, the 11567 issuer's DN is the same as the subject's DN. 11569 $ semantic security 11570 (I) An attribute of a encryption algorithm that is a formalization 11571 of the notion that the algorithm not only hides the plain text but 11572 also reveals no partial information about the plain text; i.e., 11573 whatever is computable about the plain text when given the cipher 11574 text, is also computable without the cipher text. (Compare: 11575 indistinguishability.) 11577 $ semiformal 11578 (I) Expressed in a restricted syntax language with defined 11579 semantics. [CCIB] (Compare: formal, informal.) 11581 $ sensitive compartmented information (SCI) 11582 (O) /U.S. Government/ Classified information concerning or derived 11583 from intelligence sources, methods, or analytical processes, which 11584 is required to be handled within formal control systems 11585 established by the Director of Central Intelligence. [DC6/9] (See: 11586 SCIF) 11588 $ sensitive compartmented information facility (SCIF) 11589 (O) /U.S. Government/ An accredited area, room, group of rooms, 11590 building, or installation where SCI may be stored, used, 11591 discussed, or electronically processed. [DC6/9] 11593 $ sensitive information 11594 (I) Information for which (a) disclosure, (b) alteration, or (c) 11595 destruction or loss could adversely affect the interests or 11596 business of its owner or user. (See: data confidentiality, data 11597 integrity. Compare: classified, critical.) 11599 (O) /U.S. Government/ Information for which (a) loss, (b) misuse, 11600 (c) unauthorized access, or (d) unauthorized modification could 11601 adversely affect the national interest or the conduct of federal 11602 programs, or the privacy to which individuals are entitled under 11603 the Privacy Act of 1974, but that has not been specifically 11604 authorized under criteria established by an Executive Order or an 11605 Act of Congress to be kept classified in the interest of national 11606 defense or foreign policy. 11608 Tutorial: Systems that are not U.S. national security systems, but 11609 contain sensitive U.S. Federal Government information, must be 11610 protected according to the Computer Security Act of 1987 (Public 11611 Law 100-235). 11613 $ sensitivity label 11614 (D) Synonym for "classification label". 11616 Deprecated term: ISDs should not use this term because the 11617 definition of "sensitive" involves not only data confidentiality, 11618 but also data integrity. 11620 $ sensitivity level 11621 (D) Synonym for "classification level". 11623 Deprecated term: ISDs should not use this term because the 11624 definition of "sensitive" involves not only data confidentiality, 11625 but also data integrity. 11627 $ separation of duties 11628 (I) The practice of dividing the steps in a system function among 11629 different individual entities (i.e., different users or different 11630 roles) so as to keep a single entity from subverting the process. 11631 Sometimes called "separation of privilege". (See: administrative 11632 security, dual control.) 11634 $ serial number 11635 See: certificate serial number. 11637 $ server 11638 (I) A system entity that provides a service in response to 11639 requests from other system entities called clients. 11641 $ session 11642 1a. (I) /computer usage/ A continuous period of time, usually 11643 initiated by a login, during which a user accesses a computer 11644 system. 11646 1b. (I) /computer activity/ The set of transactions or other 11647 computer activities that are performed by or for a user during a 11648 period of computer usage. 11650 2. (I) /access control/ A temporary mapping of a principal to one 11651 or more roles. (See: role-based access control.) 11653 Tutorial: A user establishes a session as a principal and 11654 activates some subset of roles to which the principal has been 11655 assigned. The authorizations available to the principal in the 11656 session are the union of permissions from all the roles activated 11657 in the session. Each session is associated with a single principal 11658 and, therefore, with a single user. A principal may have multiple, 11659 concurrent sessions and may activate a different set of roles in 11660 each session. 11662 3. (I) /computer network/ A persistent but (normally) temporary 11663 association between a user agent (typically a client) and a second 11664 process (typically a server). The association may persist across 11665 multiple exchanges of data, including multiple connections. 11666 (Compare: security association.) 11668 $ session key 11669 (I) In the context of symmetric encryption, a key that is 11670 temporary or is used for a relatively short period of time. (See: 11671 ephemeral key, KDC, session. Compare: master key.) 11673 Tutorial: A session key is used for a defined period of 11674 communication between two system entities or components, such as 11675 for the duration of a single connection or transaction set; or the 11676 key is used in an application that protects relatively large 11677 amounts of data and, therefore, needs to be rekeyed frequently. 11679 $ SET 11680 (O) See: SET Secure Electronic Transaction(trademark). 11682 $ SET private extension 11683 (O) One of the private extensions defined by SET for X.509 11684 certificates. Carries information about hashed root key, 11685 certificate type, merchant data, cardholder certificate 11686 requirements, encryption support for tunneling, or message support 11687 for payment instructions. 11689 $ SET qualifier 11690 (O) A certificate policy qualifier that provides information about 11691 the location and content of a SET certificate policy. 11693 Tutorial: In addition to the policies and qualifiers inherited 11694 from its own certificate, each CA in the SET certification 11695 hierarchy may add one qualifying statement to the root policy when 11696 the CA issues a certificate. The additional qualifier is a 11697 certificate policy for that CA. Each policy in a SET certificate 11698 may have these qualifiers: (a) a URL where a copy of the policy 11699 statement may be found; (b) an electronic mail address where a 11700 copy of the policy statement may be found; (c) a hash result of 11701 the policy statement, computed using the indicated algorithm; and 11702 (d) a statement declaring any disclaimers associated with the 11703 issuing of the certificate. 11705 $ SET Secure Electronic Transaction(trademark) or SET(trademark) 11706 (N) A protocol developed jointly by MasterCard International and 11707 Visa International and published as an open standard to provide 11708 confidentiality of transaction information, payment integrity, and 11709 authentication of transaction participants for payment card 11710 transactions over unsecured networks, such as the Internet. [SET1] 11711 (See: acquirer, brand, cardholder, dual signature, electronic 11712 commerce, IOTP, issuer, merchant, payment gateway, third party.) 11714 Tutorial: This term and acronym are trademarks of SETCo. 11715 MasterCard and Visa announced the SET standard on 1 February 1996. 11717 $ SETCo 11718 (O) Abbreviation for "SET Secure Electronic Transaction LLC", 11719 formed on 19 December 1997 by MasterCard and Visa for the purpose 11720 of implementing the SET Secure Electronic Transaction" standard. 11721 A memorandum of understanding adds American Express and JCB Credit 11722 Card Company as co-owners of SETCo. 11724 $ SHA, SHA-1, SHA-2 11725 (N) See: Secure Hash Algorithm. 11727 $ shared identity 11728 (I) See: (secondary definition under) identity. 11730 $ shared secret 11731 (D) A synonym for "cryptographic key" or "password". 11733 Deprecated Usage: The term is used in many ways and could easily 11734 be misunderstood; therefore, ISDs that use this term SHOULD state 11735 a definition for it. 11737 $ shielded enclosure 11738 (O) "Room or container designed to attenuate electromagnetic 11739 radiation." [C4009] (See: emanation.) 11741 $ short title 11742 (O) "Identifying combination of letters and numbers assigned to 11743 certain items of COMSEC material to facilitate handling, 11744 accounting, and controlling." [C4009] (Compare: KMID, long title.) 11746 $ SHS 11747 (N) See: Secure Hash Standard. 11749 $ sign 11750 (I) Create a digital signature for a data object. (See: signer.) 11752 $ signal analysis 11753 (I) Gaining indirect knowledge (inference) of communicated data by 11754 monitoring and analyzing a signal that is emitted by a system and 11755 that contains the data but is not intended to communicate the 11756 data. (See: emanation. Compare: traffic analysis.) 11758 $ signal intelligence 11759 (I) The science and practice of extracting information from 11760 signals. (See: signal security.) 11762 $ signal security 11763 (N) (I) The science and practice of protecting signals. (See: 11764 cryptology, security.) 11766 Tutorial: The term "signal" denotes communication in almost any 11767 form and also impulses emitted for other purposes, such as radar. 11768 Signal security is opposed by signal intelligence, and each 11769 discipline includes opposed sub-disciplines as follows [Kahn]: 11771 Signal Security Signal Intelligence 11772 ------------------------------ --------------------------------- 11773 1. Communication Security 1. Communication Intelligence 11774 1a. Cryptography 1a. Cryptanalysis 11775 1b. Traffic Security 1b. Traffic Analysis 11776 1c. Steganography 1c. Detection and Interception 11777 2. Electronic Security 2. Electronic Intelligence 11778 2a. Emission Security 2a. Electronic Reconnaissance 11779 2b. Counter-Countermeasures 2b. Countermeasures 11780 ------------------------------ --------------------------------- 11782 $ signature 11783 (O) A symbol or process adopted or executed by a system entity 11784 with present intention to declare that a data object is genuine. 11785 (See: digital signature, electronic signature.) 11787 $ signature certificate 11789 (I) A public-key certificate that contains a public key that is 11790 intended to be used for verifying digital signatures, rather than 11791 for encrypting data or performing other cryptographic functions. 11793 Tutorial: A v3 X.509 public-key certificate may have a "keyUsage" 11794 extension that indicates the purpose for which the certified 11795 public key is intended. (See: certificate profile.) 11797 $ signed receipt 11798 (I) An S/MIME service [R2634] that (a) provides, to the originator 11799 of a message, proof of delivery of the message and (b) enables the 11800 originator to demonstrate to a third party that the recipient was 11801 able to verify the signature of the original message. 11803 Tutorial: The receipt is bound to the original message by a 11804 signature; consequently, the service may be requested only for a 11805 message that is signed. The receipt sender may optionally also 11806 encrypt the receipt to provide confidentiality between the receipt 11807 sender and the receipt recipient. 11809 $ signer 11810 (N) A human being or organization entity that uses a private key 11811 to sign (i.e., create a digital signature on) a data object. [ABA] 11813 $ SILS 11814 (N) See: Standards for Interoperable LAN/MAN Security. 11816 $ simple authentication 11817 1. (I) An authentication process that uses a password as the 11818 information needed to verify an identity claimed for an entity. 11819 (Compare: strong authentication.) 11821 2. (O) "Authentication by means of simple password arrangements." 11822 [X509] 11824 $ Simple Authentication and Security Layer (SASL) 11825 (I) An Internet specification [R2222] for adding authentication 11826 service to connection-based protocols. 11828 Tutorial: To use SASL, a protocol includes a command for 11829 authenticating a user to a server and for optionally negotiating 11830 protection of subsequent protocol interactions. The command names 11831 a registered security mechanism. SASL mechanisms include Kerberos, 11832 GSSAPI, S/KEY, and others. Some protocols that use SASL are IMAP4 11833 and POP3. 11835 $ Simple Key Management for Internet Protocols (SKIP) 11836 (I) A key distribution protocol that uses hybrid encryption to 11837 convey session keys that are used to encrypt data in IP packets. 11839 Tutorial: SKIP was designed by Ashar Aziz and Whitfield Diffie at 11840 Sun Microsystems and proposed as the standard key management 11841 protocol for IPsec, but IKE was chosen instead. Although IKE is 11842 mandatory for an IPsec implementation, the use of SKIP is not 11843 excluded. 11845 SKIP uses the Diffie-Hellman algorithm (or could use another key 11846 agreement algorithm) to generate a key-encrypting key for use 11847 between two entities. A session key is used with a symmetric 11848 algorithm to encrypt data in one or more IP packets that are to be 11849 sent from one entity to the other. A symmetric KEK is established 11850 and used to encrypt the session key, and the encrypted session key 11851 is placed in a SKIP header that is added to each IP packet that is 11852 encrypted with that session key. 11854 $ Simple Mail Transfer Protocol (SMTP) 11855 (I) A TCP-based, application-level, Internet Standard protocol 11856 (RFC 821) for moving electronic mail messages from one computer to 11857 another. 11859 $ Simple Network Management Protocol (SNMP) 11860 (I) A TCP-based, application-level, Internet Standard protocol 11861 [R2570, R2574] for conveying management information between 11862 managers and agents. 11864 $ Simple Public Key Infrastructure (SPKI) 11865 (I) A set of experimental concepts (RFCs 2692, 2693) that were 11866 proposed as alternatives to the concepts standardized in PKIX. 11868 $ simple security property 11869 (N) /formal model/ Property of a system whereby a subject has 11870 read access to an object only if the clearance of the subject 11871 dominates the classification of the object. See: Bell-LaPadula 11872 model. 11874 $ single sign-on 11875 (I) A system that enables a user to access multiple computer 11876 platforms (usually a set of hosts on the same network) or multiple 11877 application systems after being authenticated just one time. (See: 11878 Kerberos.) 11880 Tutorial: In a single sign-on system, a user typically logs in 11881 just once, and then is transparently granted access to a set of 11882 system resources with no further login being required (unless, of 11883 course, the user logs out). Such a system has the advantages of 11884 being user friendly and enabling authentication to be managed 11885 consistently across an entire enterprise. Such a system also has 11886 the disadvantage of requiring all hosts and applications to trust 11887 the same authentication information. 11889 $ singular identity 11890 (I) See: (secondary definition under) identity. 11892 $ site 11893 (I) A facility--i.e., a physical space, room, or building together 11894 with its physical, personnel, administrative, and other 11895 safeguards--in which system functions are performed. (See: node.) 11897 $ situation 11898 See: security situation. 11900 $ SKEME 11901 (I) A key distribution protocol from which features were adapted 11902 for IKE. [SKEME] 11904 $ SKIP 11905 (I) See: Simple Key-management for IP. 11907 $ SKIPJACK 11908 (N) A type 2 block cipher [SKIP, R2773] with a block size of 64 11909 bits and a key size of 80 bits. (See: CAPSTONE, CLIPPER, FORTEZZA, 11910 Key Exchange Algorithm.) 11912 Tutorial: SKIPJACK was developed by NSA and formerly classified at 11913 the U.S. DoD "Secret" level. On 23 June 1998, NSA announced that 11914 SKIPJACK had been declassified. 11916 $ slot 11917 (O) /MISSI/ One of the FORTEZZA PC card storage areas that are 11918 each able to hold an X.509 certificate plus other data, such as 11919 the private key that is associated with a public-key certificate. 11921 $ smart card 11922 (I) A credit-card sized device containing one or more integrated 11923 circuit chips, which perform the functions of a computer's central 11924 processor, memory, and input/output interface. (See: PC card.) 11926 Usage: Sometimes this term is used rather strictly to mean a card 11927 that closely conforms to the dimensions and appearance of the kind 11928 of plastic credit card issued by banks and merchants. At other 11929 times, the term is used loosely to include cards that are larger 11930 than credit cards, especially cards that are thicker, such as PC 11931 cards. 11933 Tutorial: A "smart token" is a device that conforms to the 11934 definition of smart card except that rather than having standard 11935 credit card dimensions, the token is packaged in some other form, 11936 such as a dog tag or door key shape. 11938 $ smart token 11939 See: (secondary definition under) smart card. 11941 $ SMI 11942 (I) See: security management infrastructure. 11944 $ SMTP 11945 (I) See: Simple Mail Transfer Protocol. 11947 $ smurf attack 11948 (D) A denial-of-service attack that uses IP broadcast addressing 11949 to send ICMP ping packets with the intent of flooding a system. 11950 (See: ICMP flood.) 11952 Deprecated Term: ISDs SHOULD NOT use this term. It is not listed 11953 in most dictionaries, and it is likely that other cultures have 11954 different metaphors for this concept. (The Smurfs are a fictional 11955 race of many small blue creatures that were created by a 11956 cartoonist. Perhaps the inventor of this attack thought that a 11957 swarm of ping packets resembled a group of smurfs.) (See: 11958 (Deprecated Usage under) Green Book.) 11959 Tutorial: The attacker sends ICMP echo request ("ping") packets 11960 that appear to originate not from the attacker's own IP address, 11961 but from the address of the host or router that is target of the 11962 attack. Each packet is addressed to an IP broadcast address, e.g., 11963 to all IP addresses in a given network. Thus, each echo request 11964 that is sent by the attacker results in many echo responses being 11965 sent to the target address. This attack can disrupt service at a 11966 particular host, at the hosts that depend on a particular router, 11967 or in an entire network. 11969 $ sneaker net 11970 (D) A process that transfers data between systems only manually, 11971 under human control; i.e., a data transfer process that involves 11972 an air gap. 11974 Deprecated Term: ISDs SHOULD NOT use this term. It is not listed 11975 in most dictionaries, and it is likely that other cultures have 11976 different metaphors for this concept. 11978 $ Snefru 11979 (N) A public-domain, cryptographic hash function (also called "The 11980 Xerox Secure Hash Function") designed by Ralph C. Merkle at Xerox 11981 Corporation. Snefru can produce either a 128-bit or 256-bit output 11982 (i.e., hash result). [Schn] (See: Khafre, Khufu.) 11984 $ sniffing 11985 (D) Synonym for "passive wiretapping". (See: password sniffing.) 11987 Deprecated Term: ISDs SHOULD NOT use this term; it unnecessarily 11988 duplicates the meaning of a term that is better established. (See: 11989 (Deprecated Usage under) Green Book. 11991 $ SNMP 11992 (I) See: Simple Network Management Protocol. 11994 $ social engineering 11995 (D) A euphemism for non-technical or low-technology methods used 11996 to attack information systems. 11998 Deprecated Term: ISDs SHOULD NOT use this term; it is too vague. 11999 Instead, use a term that is specific with regard to the means of 12000 attack, e.g., lies, impersonation, tricks, bribes, blackmail, and 12001 threats. 12003 $ SOCKS 12004 (I) An Internet protocol [R1928] that provides a generalized proxy 12005 server that enables client-server applications -- such as TELNET, 12006 FTP, and HTTP; running over either TCP or UDP -- to use the 12007 services of a firewall. 12009 Tutorial: SOCKS is layered under the IPS application layer and 12010 above the transport layer. When a client inside a firewall wishes 12011 to establish a connection to an object that is reachable only 12012 through the firewall, it uses TCP to connect to the SOCKS server, 12013 negotiates with the server for the authentication method to be 12014 used, authenticates with the chosen method, and then sends a relay 12015 request. The SOCKS server evaluates the request, typically based 12016 on source and destination addresses, and either establishes the 12017 appropriate connection or denies it. 12019 $ soft TEMPEST 12020 (O) The use of software techniques to reduce the radio frequency 12021 information leakage from computer displays and keyboards. [Kuhn] 12022 (See: TEMPEST.) 12024 $ software 12025 (I) Computer programs (which are stored in and executed by 12026 computer hardware) and associated data (which also is stored in 12027 the hardware) that may be dynamically written or modified during 12028 execution. (See: firmware, hardware.) 12030 $ SORA 12031 (O) See: SSO-PIN ORA. 12033 $ source authentication 12034 (D) Deprecated Term: ISDs SHOULD NOT use this term; it is 12035 ambiguous. If the intent is to authenticate the original creator 12036 or packager of data received, then say "data origin 12037 authentication". If the intent is to authenticate the identity of 12038 the sender of data, then say "peer entity authentication". (See: 12039 data origin authentication, peer entity authentication). 12041 $ source integrity 12042 (I) The degree of confidence that can be placed in information 12043 based on the trustworthiness of its sources. (See: integrity.) 12045 $ SP3 12046 (O) See: Security Protocol 3. 12048 $ SP4 12049 (O) See: Security Protocol 4. 12051 $ spam, SPAM(trademark) 12052 1a. (I) /verb/ To indiscriminately send unsolicited, unwanted, 12053 irrelevant, or inappropriate messages, especially commercial 12054 advertising in mass quantities. 12056 1b. (I) /noun/ Electronic "junk mail". [R2635] 12058 Deprecated Usage: ISDs SHOULD NOT use this term in upper-case 12059 letters, because SPAM(trademark) is a trademark of Hormel Foods 12060 Corporation. Hormel says, "We do not object to use of this slang 12061 term [spam] to describe [unsolicited advertising email], although 12062 we do object to the use of our product image in association with 12063 that term. Also, if the term is to be used, it should be used in 12064 all lower-case letters to distinguish it from our trademark SPAM, 12065 which should be used with all uppercase letters." (See: metadata.) 12067 Tutorial: In sufficient volume, spam can cause denial of service. 12068 (See: flooding.) According to Hormel, the term was adopted as a 12069 result of a Monty Python skit in which a group of Vikings sang a 12070 chorus of 'SPAM, SPAM, SPAM ...' in an increasing crescendo, 12071 drowning out other conversation. This lyric became a metaphor for 12072 the unsolicited advertising messages that threaten to overwhelm 12073 other discourse on the Internet. 12075 $ SPD 12076 (I) See: Security Policy Database. 12078 $ special access program (SAP) 12079 (O) /U.S. Government/ "[A kind of p]rogram [that is] established 12080 for a specific class of classified information [and] that imposes 12081 safeguarding and access requirements that exceed those normally 12082 required for information at the same classified level." [C4009] 12084 $ SPI 12085 (I) See: Security Parameters Index. 12087 $ SPKI 12088 (I) See: Simple Public Key Infrastructure. 12090 $ split key 12091 (I) A cryptographic key that is divided into two or more separate 12092 data items that individually convey no knowledge of the whole key 12093 that results from combining the items. (See: dual control, split 12094 knowledge.) 12096 $ split knowledge 12097 1. (I) A security technique in which two or more entities 12098 separately hold data items that individually convey no knowledge 12099 of the information that results from combining the items. (See: 12100 dual control, split key.) 12102 2. (O) "A condition under which two or more entities separately 12103 have key components which individually convey no knowledge of the 12104 plaintext key which will be produced when the key components are 12105 combined in the cryptographic module." [FP140] 12107 $ spoofing attack 12108 (I) Synonym for "masquerade attack". 12110 $ spread spectrum 12111 1. (N) A TRANSEC technique that transmits a signal in a bandwidth 12112 much greater than the transmitted information needs. [F1037] 12113 Example: frequency hopping. 12115 Tutorial: Usually uses a sequential noise-like signal structure to 12116 spread the normally narrowband information signal over a 12117 relatively wide band of frequencies. The receiver correlates the 12118 signals to retrieve the original information signal. This 12119 technique decreases potential interference to other receivers, 12120 while achieving data confidentiality and increasing immunity of 12121 spread spectrum receivers to noise and interference. 12123 $ spyware 12124 (I) Software that an intruder has installed surreptitiously on a 12125 networked computer to gather data from that computer and send it 12126 through the network to the intruder or some other interested 12127 party. (See: malicious logic, Trojan horse.) 12129 Deprecated Usage: The term is used in many ways and could easily 12130 be misunderstood; therefore, ISDs that use this term SHOULD state 12131 a definition for it. 12133 Tutorial: Some examples of the types of data that might be 12134 gathered by spyware are application files, passwords, email 12135 addresses, usage histories, and keystrokes. Some examples of 12136 motivations for gathering the data are blackmail, financial fraud, 12137 identity theft, industrial espionage, market research, and 12138 voyeurism. 12140 $ SSH(trademark) 12141 (N) See: Secure Shell(trademark). 12143 $ SSL 12144 (I) See: Secure Sockets Layer. 12146 $ SSO 12147 (I) See: system security officer. 12149 $ SSO PIN 12150 (O) /MISSI/ One of two personal identification numbers that 12151 control access to the functions and stored data of a FORTEZZA PC 12152 card. Knowledge of the SSO PIN enables the card user to perform 12153 the FORTEZZA functions intended for use by an end user and also 12154 the functions intended for use by a MISSI CA. (See: user PIN.) 12156 $ SSO-PIN ORA (SORA) 12157 (O) /MISSI/ A MISSI organizational RA that operates in a mode in 12158 which the ORA performs all card management functions and, 12159 therefore, requires knowledge of the SSO PIN for FORTEZZA PC cards 12160 issued to end users. 12162 $ Standards for Interoperable LAN/MAN Security (SILS) 12163 1. (N) The IEEE 802.10 standards committee. (See: FP191.) 12165 2. (N) A set of IEEE standards, which has eight parts: (a) Model, 12166 including security management, (b) Secure Data Exchange protocol, 12167 (c) Key Management, (d) [has been incorporated in (a)], (e) SDE 12168 Over Ethernet 2.0, (f) SDE Sublayer Management, (g) SDE Security 12169 Labels, and (h) SDE PICS Conformance. Parts b, e, f, g, and h are 12170 incorporated in IEEE Standard 802.10-1998. 12172 $ star property 12173 (N) See: *-property. 12175 $ Star Trek attack 12176 (D) An attack that penetrates your system where no attack has ever 12177 gone before. 12179 Deprecated Usage: This is a joke for Trekkies. (See: (Deprecated 12180 Usage under) Green Book.) 12182 $ static 12183 (I) /adjective/ Refers to a cryptographic key or other parameter 12184 that is relatively long-lived. (Compare: ephemeral.) 12186 $ steganography 12187 (I) Methods of hiding the existence of a message or other data. 12188 This is different than cryptography, which hides the meaning in a 12189 message but does not hide the message itself. Example: "Invisible" 12190 ink. (See: cryptology. Compare: digital watermarking.) 12192 $ storage channel 12193 See: covert storage channel. 12195 $ stream cipher 12196 (I) An encryption algorithm that breaks plain text into a stream 12197 of successive elements (usually, bits) and encrypts the n-th 12198 plaintext element with the n-th element of a parallel key stream, 12199 thus converting the plaintext stream into a ciphertext stream. 12200 [Schn] (See: block cipher.) 12202 $ strength 12203 (I) /COMPUSEC/ A rating of effectiveness of a security mechanism, 12204 stated in terms of the minimum effort believed to be needed to 12205 defeat the mechanism. (See: entropy, strong, work factor.) 12207 $ strength of function 12208 (N) /Common Criteria/ "A qualification of a TOE security function 12209 expressing the minimum efforts assumed necessary to defeat its 12210 expected security behavior by directly attacking its underlying 12211 security mechanisms": (See: strength, strong.) 12212 - Basic: "A level of the TOE strength of function where analysis 12213 shows that the function provides adequate protection against 12214 casual breach of TOE security by attackers possessing a low 12215 attack potential." 12216 - Medium: "... against straightforward or intentional breach ... 12218 by attackers possessing a moderate attack potential. 12219 - High: "... against deliberately planned or organized breach ... 12220 by attackers possessing a high attack potential." 12222 $ strong 12223 1. (I) /COMPUSEC/ Used to describe a security mechanism that would 12224 be difficult to defeat. (See: strength.) 12226 2. (I) /cryptography/ Used to describe a cryptographic algorithm 12227 that would require a large amount of computational power to defeat 12228 it. (See: work factor.) 12230 $ strong authentication 12231 1. (I) An authentication process that uses a cryptographic 12232 security mechanism -- particularly public-key certificates -- to 12233 verify the identity claimed for an entity. (Compare: simple 12234 authentication.) 12236 2. (O) "Authentication by means of cryptographically derived 12237 credentials." [X509] 12239 $ subject 12240 1a. (I) A process in a computer system that represents a principal 12241 and that executes with the privileges that have been granted to 12242 that principal. (Compare: principal, user.) 12244 1b. (I) /formal model/ A system entity that causes information to 12245 flow among objects or changes the system state; technically, a 12246 process-domain pair. A subject may itself be an object relative to 12247 some other subject; thus, the set of subjects in a system is a 12248 subset of the set of objects. (See: Bell-LaPadula model, object.) 12250 2. (I) /digital certificate/ The entity name that is bound to the 12251 data items in a digital certificate, and particularly a name that 12252 is bound to a key in a public-key certificate. (See: X.509.) 12254 $ subject CA 12255 (D) The CA that is the subject of a cross-certificate issued by 12256 another CA. [X509] (See: cross-certification.) 12258 Deprecated Term: ISDs SHOULD NOT use this term because it is not 12259 widely known and could be misunderstood. Instead, say "the CA that 12260 is the subject of the cross-certificate". 12262 $ subnetwork 12263 (N) An OSI term for a system of packet relays and connecting links 12264 that implement OSIRM layers 2 or 3 to provide a communication 12265 service that interconnects attached end systems. Usually, the 12266 relays are all of the same type (e.g., X.25 packet switches, or 12267 interface units in an IEEE 802.3 LAN). (See: gateway, internet, 12268 router.) 12270 $ subordinate CA (SCA) 12271 1. (I) A CA whose public-key certificate is issued by another 12272 (superior) CA. (See: certification hierarchy. Compare: cross- 12273 certification.) 12275 2. (O) /MISSI/ The fourth-highest (i.e., bottom) level of a MISSI 12276 certification hierarchy; a MISSI CA whose public-key certificate 12277 is signed by a MISSI CA rather than by a MISSI PCA. A MISSI SCA is 12278 the administrative authority for a subunit of an organization, 12279 established when it is desirable to organizationally distribute or 12280 decentralize the CA service. The term refers both to that 12281 authoritative office or role, and to the person who fills that 12282 office. A MISSI SCA registers end users and issues their 12283 certificates and may also register ORAs, but may not register 12284 other CAs. An SCA periodically issues a CRL. 12286 $ subordinate DN 12287 (I) An X.500 DN is subordinate to another X.500 DN if it begins 12288 with a set of attributes that is the same as the entire second DN 12289 except for the terminal attribute of the second DN (which is 12290 usually the name of a CA). For example, the DN is subordinate to the DN 12292 . 12294 $ subscriber 12295 (I) /PKI/ A user that is registered in a PKI and, therefore, can 12296 be named in the "subject" field of a certificate issued by a CA in 12297 that PKI. (See: registration, user.) 12299 Usage: This term is needed to distinguish registered users from 12300 two other kinds of PKI users: 12301 - Users that access the PKI but are not identified to it. For 12302 example a relying party may access a PKI repository to obtain 12303 the certificate of some other party. (See: access) 12304 - Users that does not access the PKI. For example, a relying 12305 party (see: certificate user) may use a digital certificate 12306 that was obtained from a database that is not part of the PKI 12307 that issued the certificate. 12309 $ substitution 12310 (I) /cryptography/ A method of encryption in which elements of the 12311 plain text retain their original sequence but are replaced by 12312 other elements. (Compare: transposition.) 12314 $ subsystem 12315 (I) A collection of related system components that together 12316 perform a system function or deliver a system service. 12318 $ superencryption 12319 (I) An encryption operation for which the plaintext input to be 12320 transformed is the ciphertext output of a previous encryption 12321 operation. (Compare: hybrid encryption.) 12323 $ survivability 12324 (I) The ability of a system to remain in operation or existence 12325 despite adverse conditions, including both natural occurrences, 12326 accidental actions, and attacks on the system. (Compare: 12327 availability, reliability.) 12329 $ swIPe 12330 (I) An encryption protocol for IP that provides confidentiality, 12331 integrity, and authentication and can be used for both end-to-end 12332 and intermediate-hop security. [Ioan] (Compare: IPsec.) 12334 Tutorial: The swIPe protocol is an IP predecessor that is 12335 concerned only with encryption mechanisms; policy and key 12336 management are handled outside the protocol. 12338 $ syllabary 12339 (N) /encryption/ A list of individual letters, combinations of 12340 letters, or syllables, with their equivalent code groups, used for 12341 spelling out proper names or other unusual words that are not 12342 present in the basic vocabulary (i.e., are not in the codebook) of 12343 a code used for encryption. 12345 $ symmetric cryptography 12346 (I) A branch of cryptography in which the algorithms use the same 12347 key for both of two counterpart cryptographic operations (e.g., 12348 encryption and decryption). (See: asymmetric cryptography. 12349 Compare: secret-key cryptography.) 12351 Tutorial: Symmetric cryptography has been used for thousands of 12352 years [Kahn]. A modern example is AES. 12354 Symmetric cryptography has a disadvantage compared to asymmetric 12355 cryptography with regard to key distribution. For example, when 12356 Alice wants to ensure confidentiality for data she sends to Bob, 12357 she encrypts the data with a key, and Bob uses the same key to 12358 decrypt. However, keeping the shared key secret entails both cost 12359 and risk when the key is distributed to both Alice and Bob. (See: 12360 key management system.) 12362 $ symmetric key 12363 (I) A cryptographic key that is used in a symmetric cryptographic 12364 algorithm. (See: symmetric cryptography.) 12366 $ SYN flood 12367 (I) A denial-of-service attack that sends a large number of TCP 12368 SYN (synchronize) packets to a host with the intent of disrupting 12369 the operation of that host. (See: flooding.) 12371 Tutorial: This attack seeks to exploit a vulnerability in the TCP 12372 specification or in a TCP implementation. Normally, two hosts use 12373 a three-way exchange of packets to establish a TCP connection: (a) 12374 host 1 requests a connection by sending a SYN packet to host 2; 12375 (b) host 2 replies by sending a SYN-ACK (acknowledgement) packet 12376 to host 1; and (c) host 1 completes the connection by sending an 12377 ACK packet to host 2. To attack host 2, host 1 can send a series 12378 of TCP SYNs, each with a different phony source address. ([R2267] 12379 discusses how to use packet filtering to prevent such attacks from 12380 being launched from behind an Internet service provider's 12381 aggregation point.) Host 2 treats each SYN as a request from a 12382 separate host, replies to each with a SYN-ACK, and waits to 12383 receive the matching ACKs. (The attacker can use random or 12384 unreachable sources addresses in the SYN packets, or can use 12385 source addresses that belong to third parties, that then become 12386 secondary victims.) 12388 For each SYN-ACK that is sent, the TCP process in host 2 needs 12389 some memory space to store state information while waiting for the 12390 matching ACK to be returned. If the matching ACK never arrives at 12391 host 2, a timer associated with the pending SYN-ACK will 12392 eventually expire and release the space. But if host 1 (or a 12393 cooperating group of hosts) can rapidly send many SYNs to host 2, 12394 host 2 will need to store state information for many pending SYN- 12395 ACKs and may run out of space. This can prevent host 2 from 12396 responding to legitimate connection requests from other hosts or 12397 even, if there are flaws in host 2's TCP implementation, crash 12398 when the space is exhausted. 12400 $ synchronization 12401 (I) Any technique by which a receiving (decrypting) cryptographic 12402 process attains an internal state that matches the transmitting 12403 (encrypting) process, i.e., has the appropriate keying material to 12404 process the cipher text and is correctly initialized to do so. 12406 $ system 12407 Usage: In this Glossary, the term is mainly used as an 12408 abbreviation for "information system". (See: subsystem.) 12410 $ system architecture 12411 (N) The structure of system components, their relationships, and 12412 the principles and guidelines governing their design and evolution 12413 over time. [DoDAF1] (Compare: security architecture.) 12415 $ system component 12416 1. (I) A collection of system resources that (a) forms a physical 12417 or logical part of the system, (b) has specified functions and 12418 interfaces, and (c) is treated (e.g., by policies or requirement 12419 statements) as existing independently of other parts of the 12420 system. (See: subsystem.) 12422 2. (O) /ITSEC/ An identifiable and self-contained part of a TOE. 12424 Usage: Component is a relative term because components may be 12425 nested; i.e., one component of system may be a part of another 12426 component of that system. 12428 Tutorial: Components can be characterized as follows: 12429 - A "physical component" has mass and takes up space. 12430 - A "logical component" is an abstraction used to manage and 12431 coordinate aspects of the physical environment, and typically 12432 represents a set of states or capabilities of the system. 12434 $ system entity 12435 (I) An active component of a system -- e.g., an automated process 12436 or set of processes (see: subsystem), or a person or set of 12437 persons (e.g., an organization) -- that incorporates a specific 12438 set of capabilities. (Compare: subject, user.) 12440 $ system high 12441 (I) The highest security level at which a system operates, or is 12442 capable of operating, at a particular time or in a particular 12443 environment. (See: system high security mode.) 12445 $ system high security mode 12446 (I) A mode of operation of an information system, wherein all 12447 users having access to the system possess a security clearance or 12448 authorization, but not necessarily a need-to-know, for all data 12449 handled by the system. (See: (system operation) mode.) 12451 Usage: This mode was defined formally in U.S. DoD policy that 12452 applied to system accreditation [DoD2], but the term is widely 12453 used outside the Defense Department and outside the Government. 12455 $ system integrity 12456 (I) "The quality that a system has when it can perform its 12457 intended function in a unimpaired manner, free from deliberate or 12458 inadvertent unauthorized manipulation." [NCS04] (See: recovery, 12459 system integrity service.) 12461 $ system integrity service 12462 (I) A security service that protects system resources in a 12463 verifiable manner against unauthorized or accidental change, loss, 12464 or destruction. (See: system integrity.) 12466 $ system low 12467 (I) The lowest security level supported by a system at a 12468 particular time or in a particular environment. (See: system 12469 high.) 12471 $ system resource 12472 (I) Data contained in an information system; or a service provided 12473 by a system; or a system capability, such as processing power or 12474 communication bandwidth; or an item of system equipment (i.e., 12475 hardware, firmware, software, or documentation); or a facility 12476 that houses system operations and equipment. (See: system 12477 component.) 12479 $ system security officer (SSO) 12480 (I) A person responsible for enforcement or administration of the 12481 security policy that applies to the system. 12483 $ TACACS 12484 (I) See: Terminal Access Controller (TAC) Access Control System. 12486 $ TACACS+ 12487 (I) A TCP-based protocol that improves on TACACS and XTACACS by 12488 separating the functions of authentication, authorization, and 12489 accounting and by encrypting all traffic between the network 12490 access server and authentication server. TACACS+ is extensible to 12491 allow any authentication mechanism to be used with TACACS+ 12492 clients. (See: TACACS, XTACACS.) 12494 $ tamper 12495 (I) Make an unauthorized modification in a system that alters the 12496 system's functioning in a way that degrades the security services 12497 that the system was intended to provide. (See: QUADRANT. Compare: 12498 (secondary definitions under) "corruption" and "misuse".) 12500 $ tamper-evident 12501 (I) A characteristic of a system component that provides evidence 12502 that an attack has been attempted on that component or system. 12504 Usage: Normally refers to physical evidence. (See: tamper.) 12506 $ tamper-resistant 12507 (I) A characteristic of a system component that provides passive 12508 protection against an attack. (See: tamper.) 12510 Usage: Normally refers to physical means of protection. 12512 $ target of evaluation (TOE) 12513 (N) /Common Criteria/ An information technology product or system 12514 that is the subject of a security evaluation, together with the 12515 product's associated administrator and user documentation. 12517 Tutorial: The security characteristics of the target of evaluation 12518 (TOE) are described in specific terms by a corresponding security 12519 target, or in more general terms by a protection profile. In 12520 Common Criteria philosophy, it is important that a TOE be 12521 evaluated against the specific set of criteria expressed in the 12522 security target (ST). This evaluation consists of rigorous 12523 analysis and testing performed by an accredited, independent 12524 laboratory. The scope of a TOE evaluation is set by the EAL and 12525 other requirements specified in the ST. Part of this process is an 12526 evaluation of the ST itself, to ensure that it is correct, 12527 complete, and internally consistent and can be used as the 12528 baseline for the TOE evaluation. 12530 $ TCB 12531 (N) See: trusted computing base. 12533 $ TCC field 12534 (I) See: Transmission Control Code field. 12536 $ TCP 12537 (I) See: Transmission Control Protocol. 12539 $ TCP/IP 12540 (I) Synonym for "Internet Protocol Suite", in which the 12541 Transmission Control Protocol (TCP) and the Internet Protocol (IP) 12542 are important parts. 12544 $ TCSEC 12545 (N) See: Trusted Computer System Evaluation Criteria. (Compare: 12546 TSEC.) 12548 $ TDEA 12549 (I) See: Triple Data Encryption Algorithm. 12551 $ teardrop attack 12552 (D) An denial-of-service attack that sends improperly formed IP 12553 packet fragments with the intent of causing the destination system 12554 to fail. 12556 Deprecated Term: The term is often used imprecisely and could 12557 easily be misunderstood; therefore, ISDs that use this term SHOULD 12558 state a definition for it. (See: (Deprecated Usage under) Green 12559 Book.) 12561 $ technical non-repudiation 12562 (I) See: (secondary definition under) non-repudiation. 12564 $ technical security 12565 (I) Security mechanisms and procedures that are implemented in and 12566 executed by hardware, software, or firmware (rather than by 12567 people) to provide automated protection for a system. (See: 12568 security architecture. Compare: administrative security.) 12570 $ Telecommunications Security Nomenclature System (TSEC) 12571 (O) An NSA designation system for telecommunication security 12572 equipment. (Compare: TCSEC.) 12574 Tutorial: A TSEC designator has the following parts: 12575 - Prefix "TSEC/" for items and systems, or suffix "/TSEC" for 12576 assemblies. (Often omitted when the context is clear.) 12577 - First letter, for function: "C" COMSEC equipment system, "G" 12578 general purpose, "K" cryptographic, "H" crypto-ancillary, "M" 12579 manufacturing, "N" noncryptographic, "S" special purpose. 12580 - Second letter, for type or purpose: "G" key generation, "I" 12581 data transmission, "L" literal conversion, "N" signal 12582 conversion, "O" multipurpose, "P" materials production, "S" 12583 special purpose, "T" testing or checking, "U" television, "W" 12584 teletypewriter, "X" facsimile, "Y" speech. 12585 - Optional third letter, used only in designations of assemblies, 12586 for type or purpose: "A" advancing, "B" base or cabinet, "C" 12587 combining, "D" drawer or panel, "E" strip or chassis, "F" frame 12588 or rack, "G" key generator, "H" keyboard, "I" translator or 12589 reader, "J" speech processing, "K" keying or permuting, "L" 12590 repeater, "M" memory or storage, "O" observation, "P" power 12591 supply or converter, "R" receiver, "S" synchronizing, "T" 12592 transmitter, "U" printer, "V" removable COMSEC component, "W" 12593 logic programmer/programming, "X" special purpose. 12594 - Model number, usually two or 3 digits, assigned sequentially 12595 within each letter combination (e.g., KG-34, KG-84). 12596 - Optional suffix letter, used to designate a version. First 12597 version has no letter, next version has "A" (e.g., KG-84, KG- 12598 84A), etc. 12600 $ TELNET 12601 (I) A TCP-based, application-level, Internet Standard protocol 12602 (RFC 854) for remote login from one host to another. 12604 $ TEMPEST 12605 (N) Short name for technology and methods for protecting against 12606 data compromise due to electromagnetic emanations from electrical 12607 and electronic equipment. [Russ] (See: inspectable space, soft 12608 TEMPEST, TEMPEST zone. Compare: QUADRANT) 12610 (O) /U.S. Government/ "Short name referring to investigation, 12611 study, and control of compromising emanations from IS equipment." 12612 [N4009] 12614 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 12615 "electromagnetic emanations security"; instead, use EMSEC. Also, 12616 the term is NOT an acronym for Transient Electromagnetic Pulse 12617 Surveillance Technology. 12619 Tutorial: U.S. Government security policy states (a) 12620 specifications and standards for techniques to reduce the 12621 strength of emanations from systems and reduce the ability of 12622 unauthorized parties to receive and make use of emanations, and 12623 (b) rules for applying those techniques. Other nations presumably 12624 do the same. 12626 $ TEMPEST zone 12627 (O) "Designated area [i.e., a physical volume] within a facility 12628 where equipment that has appropriate TEMPEST characteristics ... 12629 may be operated." [C4009] (See: emanation security, TEMPEST. 12630 Compare: inspectable space.) 12632 Tutorial: The strength of an electromagnetic signal decreases in 12633 proportion to the square of the distance between the source and 12634 the receiver. Therefore, EMSEC for electromagnetic signals can be 12635 achieved by a combination of (a) reducing the strength of 12636 emanations to a defined level and (b) establishing around that 12637 equipment an appropriately sized physical buffer zone from which 12638 unauthorized entities are excluded. By making the zone large 12639 enough, it is possible to limit the signal strength available to 12640 entities outside the zone to a level lower than can be received 12641 and read with known, state-of-the-art methods. Typically, the need 12642 for and size of a TEMPEST zone established by a security policy 12643 depends not only on the measured level of signal emitted by 12644 equipment, but also on the perceived threat level in the 12645 equipment's environment. 12647 $ Terminal Access Controller (TAC) Access Control System (TACACS) 12648 (I) A UDP-based authentication and access control protocol [R1492] 12649 in which a network access server receives an identifier and 12650 password from a remote terminal and passes them to a separate 12651 authentication server for verification. (See: TACACS+, XTACACS.) 12653 Tutorial: TACACS can provide service not only for network access 12654 servers but also routers and other networked computing devices via 12655 one or more centralized authentication servers. TACACS was 12656 originally developed for ARPANET and has evolved for use in 12657 commercial equipment. 12659 $ TESS 12660 (I) See: The Exponential Encryption System. 12662 $ The Exponential Encryption System (TESS) 12663 (I) A system of separate but cooperating cryptographic mechanisms 12664 and functions for the secure authenticated exchange of 12665 cryptographic keys, the generation of digital signatures, and the 12666 distribution of public keys. TESS uses asymmetric cryptography, 12667 based on discrete exponentiation, and a structure of self- 12668 certified public keys. [R1824] 12670 $ threat 12671 1a. (I) A potential for violation of security, which exists when 12672 there is an entity, circumstance, capability, action, or event 12673 that could cause harm. (See: dangling threat, INFOCON level, 12674 threat action, threat agent, threat consequence. Compare: attack, 12675 vulnerability.) 12677 1b. (N) Any circumstance or event with the potential to adversely 12678 affect a system through unauthorized access, destruction, 12679 disclosure, or modification of data, or denial of service. [C4009] 12680 (See: sensitive information.) 12682 Usage: (a) Frequently misused with the meaning of either "threat 12683 action" or "vulnerability". (b) In some contexts, "threat" is used 12684 more narrowly to refer only to intelligent threats; for example, 12685 see definition 2 below. (c) In some contexts, "threat" is used 12686 more broadly to cover both definition 1 and other concepts, such 12687 as in definition 3 below. 12689 Tutorial: A threat is a possible danger that might exploit a 12690 vulnerability. 12691 - "Intentional threat": A possibility of an attack by an 12692 intelligent entity (e.g., an individual cracker or a criminal 12693 organization). 12694 - "Accidental threat": A possibility of human error or omission, 12695 unintended equipment malfunction, or natural disaster (e.g., 12696 fire, flood, earthquake, or windstorm). (See list in [FP031].) 12698 The Common Criteria characterizes a threat in terms of (a) a 12699 threat agent, (b) a presumed method of attack, (c) any 12700 vulnerabilities that are the foundation for the attack, and (d) 12701 the system resource that is attacked. 12703 2. (O) The technical and operational capability of a hostile 12704 entity to detect, exploit, or subvert a friendly system and the 12705 demonstrated, presumed, or inferred intent of that entity to 12706 conduct such activity. 12708 Tutorial: To be likely to launch an attack, an adversary must have 12709 (a) a motive to attack, (b) a method or technical capability to 12710 make the attack, and (c) an opportunity to appropriately access 12711 the targeted system. 12713 3. (O) "An indication of an impending undesirable event." [Park] 12715 Tutorial: Definition 3 was intended to include these meanings: 12716 - "Potential threat": A possible security violation; i.e., the 12717 same as definition 1. 12718 - "Active threat": An expression of intent to violate security. 12719 (Context usually distinguishes this meaning from the previous 12720 one.) 12721 - "Accomplished threat" or "actualized threat": That is, an 12722 attack. Deprecated Usage: ISDs SHOULD NOT use the term "threat" 12723 with this meaning; instead, use "threat action". 12725 $ threat action 12726 (I) A realization of a threat, i.e., an occurrence in which system 12727 security is assaulted as the result of either an accidental event 12728 or an intentional act. (See: attack, threat, threat consequence.) 12730 Tutorial: A complete security architecture deals with both 12731 intentional acts (i.e. attacks) and accidental events [FIPS31]. 12732 (See: (various kinds of threat actions defined as subentries 12733 under) threat consequence.) 12735 $ threat agent 12736 (I) A system entity that performs a threat action, or an event 12737 that results in a threat action. 12739 $ threat analysis 12740 (I) An analysis of the probability of occurrences and consequences 12741 of damaging actions to a system. 12743 $ threat consequence 12744 (I) A security violation that results from a threat action. 12746 Tutorial: The four basic types of threat consequence are 12747 "unauthorized disclosure", "deception", "disruption", and 12748 "usurpation" (see definitions of these four terms for discussion 12749 of the types of threat actions that can these consequences). 12751 $ thumbprint 12752 (I) A pattern of curves formed by the ridges on the tip of a 12753 thumb. (See: biometric authentication, fingerprint.) 12755 Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for 12756 "hash result" because that meaning mixes concepts in a potentially 12757 misleading way. 12759 $ ticket 12760 (I) Synonym for "capability". 12762 Tutorial: A ticket is usually granted by a centralized access 12763 control server (ticket-granting agent) to authorize access to a 12764 system resource for a limited time. Tickets can be implemented 12765 with either symmetric cryptography (see: Kerberos) or asymmetric 12766 cryptography (see: attribute certificate). 12768 $ tiger team 12769 (I) A group of evaluators employed by a system's managers to 12770 perform penetration tests on the system. 12772 Deprecated Term: It is likely that other cultures have different 12773 metaphors for this concept. Therefore, to ensure international 12774 understanding, ISDs SHOULD NOT use this term. (See: (Deprecated 12775 Usage under) Green Book.) 12777 $ time stamp 12778 (I) /noun/ With respect to a data object, a label or marking in 12779 which is recorded the time (time of day or other instant of 12780 elapsed time) at which the label or marking was affixed to the 12781 data object. (See: Time-Stamp Protocol.) 12783 (O) /noun/ "With respect to a recorded network event, a data field 12784 in which is recorded the time (time of day or other instant of 12785 elapsed time) at which the event took place." [A1523] 12787 Tutorial: A time stamp can be used as evidence to prove that a 12788 data object existed (or that an event occurred) at or before a 12789 particular time. For example, a time stamp might be used to prove 12790 that a digital signature based on a private key was created while 12791 the corresponding public-key certificate was valid, i.e., before 12792 the certificate either expired or was revoked. Establishing this 12793 proof would enable the certificate to be used after its expiration 12794 or revocation, to verify a signature that was created earlier. 12795 This kind of proof is required as part of implementing PKI 12796 services such as non-repudiation service and long-term security 12797 services such as audit. 12799 $ Time-Stamp Protocol 12800 (I) An Internet protocol (RFC 3161) that specifies how a client 12801 requests and receives a time stamp from a server for a data object 12802 held by the client. 12804 Tutorial: The protocol describes the format of (a) a request sent 12805 to a time stamping authority and (b) the response that is returned 12806 containing a time stamp. The authority creates the stamp by 12807 concatenating (a) a hash value of the input data object with (b) a 12808 UTC time value and other parameters (policy OID, serial number, 12809 indication of time accuracy, nonce, DN of the authority, and 12810 various extensions), and then signing that dataset with the 12811 authority's private key as specified in CMS. Such an authority 12812 typically would operate as a trusted third-party service, but 12813 other operational models might be used. 12815 $ timing channel 12816 See: covert timing channel. 12818 $ TLS 12819 (I) See: Transport Layer Security. 12821 $ TLSP 12822 (N) See: Transport Layer Security Protocol. 12824 $ TOE 12825 (N) See: target of evaluation 12827 $ token 12828 1. (I) /cryptography/ See: cryptographic token. (Compare: dongle.) 12830 2. (I) /access control/ An object that is used to control access 12831 and is passed between cooperating entities in a protocol that 12832 synchronizes use of a shared resource. Usually, the entity that 12833 currently holds the token has exclusive access to the resource. 12835 Usage: This term is heavily overloaded in the computing 12836 literature; therefore, ISDs SHOULD NOT use this term with any 12837 definition other than 1 or 2. 12839 3a. (D) /authentication/ A data object or a physical device used 12840 to verify an identity in an authentication process. 12842 3b. (D) /U.S. Government/ Something that the claimant in an 12843 authentication process (i.e., the entity that claims an identity) 12844 possesses and controls, and uses to prove the claim during the 12845 verification step of the process. [SP63] 12847 Usage: Deprecated usage: ISDs SHOULD NOT use this term with 12848 definitions 3a and 3b; instead, use more specifically descriptive 12849 and informative terms such as "authentication information" or 12850 "cryptographic token", depending on what is meant. 12852 NIST defines four types of claimant tokens for electronic 12853 authentication in an information system [SP63]. ISDs SHOULD NOT 12854 use these four NIST terms; they mix concepts in potentially 12855 confusing ways. These terms can be avoided by using more 12856 specifically descriptive terms as follows: 12857 - NIST "hard token": A hardware device that contains a protected 12858 cryptographic key. (This is a type of "cryptographic token", 12859 and the key is a type of "authentication information".) 12860 - NIST "one-time password device token": A personal hardware 12861 device that generates one-time passwords. (One-time passwords 12862 are typically generated cryptographically. Therefore, this is a 12863 type of "cryptographic token", and the key is a type of 12864 "authentication information".) 12865 - NIST "soft token": A cryptographic key that typically is stored 12866 on disk or some other magnetic media. (The key is a type of 12867 "authentication information"; "authentication key" would be a 12868 better description.) 12869 - NIST "password token": A secret data value that the claimant 12870 memorizes. (This is a "password" that is being used as 12871 "authentication information".) 12873 $ token backup 12874 (I) A token management operation that stores sufficient 12875 information in a database (e.g., in a CAW) to recreate or restore 12876 a security token (e.g., a smart card) if it is lost or damaged. 12878 $ token copy 12879 (I) A token management operation that copies all the personality 12880 information from one security token to another. However, unlike in 12881 a token restore operation, the second token is initialized with 12882 its own, different local security values such as PINs and storage 12883 keys. 12885 $ token management 12886 (I) The process of initializing security tokens (e.g., see: smart 12887 card), loading data into the tokens, and controlling the tokens 12888 during their life cycle. May include performing key management and 12889 certificate management functions; generating and installing PINs; 12890 loading user personality data; performing card backup, card copy, 12891 and card restore operations; and updating firmware. 12893 $ token restore 12894 (I) A token management operation that loads a security token with 12895 data for the purpose of recreating (duplicating) the contents 12896 previously held by that or another token. (See: recovery.) 12898 $ token storage key 12899 (I) A cryptographic key used to protect data that is stored on a 12900 security token. 12902 $ top CA 12903 (I) A synonym for "root" in a certification hierarchy. 12905 $ top-level specification 12906 (I) "A non-procedural description of system behavior at the most 12907 abstract level; typically a functional specification that omits 12908 all implementation details." [NCS04] (See: (discussion under) 12909 security policy.) 12911 Tutorial: A top-level specification may be descriptive or formal: 12912 - "Descriptive top-level specification": One that is written in a 12913 natural language like English or an informal design notation. 12914 - "Formal top-level specification": One that is written in a 12915 formal mathematical language to enable theorems to be proven 12916 that show that the specification correctly implements a set of 12917 formal requirements or a formal security model. (See: 12918 correctness proof.) 12920 $ traceback 12921 (I) Identification of the source of a data packet. (See: network 12922 weaving.) 12924 $ tracker 12925 (N) An attack technique for achieving unauthorized disclosure from 12926 a statistical database. [Denns] (See: (Tutorial under) inference 12927 control.) 12929 $ traffic analysis 12930 1. (I) Gaining knowledge of information by inference from 12931 observable characteristics of data flow(s), even when the 12932 information is encrypted or otherwise not directly available. Such 12933 characteristics include the identities and locations of the 12934 source(s) and destination(s), and the presence, amount, frequency, 12935 and duration of occurrence. (See: inference, traffic-flow 12936 confidentiality, wiretapping. Compare: signal analysis.) 12938 2. (O) "The inference of information from observation of traffic 12939 flows (presence, absence, amount, direction, and frequency)." 12940 [I7498 Part 2] 12942 $ traffic-flow analysis 12943 (I) Synonym for "traffic analysis". 12945 $ traffic-flow confidentiality 12946 1. (I) A data confidentiality service to protect against traffic 12947 analysis. (See: communications cover.) 12949 2. (O) "A confidentiality service to protect against traffic 12950 analysis." [I7498 Part 2] 12952 $ traffic padding 12953 (I) "The generation of spurious instances of communication, 12954 spurious data units, and/or spurious data within data units." 12955 [I7498 Part 2] 12957 $ tranquillity property 12958 (N) /formal model/ Property of a system whereby the security level 12959 of an object cannot change while the object is being processed by 12960 the system. (See: Bell-LaPadula model.) 12962 $ transaction 12963 1. (I) A unit of interaction between an external entity and a 12964 system, or between components within a system, that involves a 12965 series of system actions or events. 12967 2. (O) "A discrete event between user and systems that supports a 12968 business or programmatic purpose." [M0404] 12970 Tutorial: To maintain secure state, transactions need to be 12971 processed coherently and reliably. Usually, they need to be 12972 designed to be atomic, consistent, isolated, and durable [Gray]: 12973 - "Atomic": All actions and events that comprise the transaction 12974 are guaranteed to be completed successfully, or else the result 12975 is as if none at all were executed. 12976 - "Consistent": The transaction satisfies correctness constraints 12977 defined for the data that is being processed. 12978 - "Isolated": If two transactions are performed concurrently, 12979 they do not interfere with each other, and it appears as though 12980 the system performs one at a time. 12981 - "Durable": System state and transaction semantics survive 12982 system failures. 12984 $ TRANSEC 12985 (I) See: transmission security. 12987 $ Transmission Control Code field (TCC field) 12988 (I) A data field that provides a means to segregate traffic and 12989 define controlled communities of interest in the security option 12990 (option type = 130) of IP's datagram header format. The TCC values 12991 are alphanumeric trigraphs assigned by the U.S. Government as 12992 specified in RFC 791. 12994 $ Transmission Control Protocol (TCP) 12995 (I) An Internet Standard, transport-layer protocol (RFC 793) that 12996 reliably delivers a sequence of datagrams from one computer to 12997 another in a computer network. (See: TCP/IP.) 12999 Tutorial: TCP is designed to fit into a layered suite of protocols 13000 that support internetwork applications. TCP assumes it can obtain 13001 a simple but potentially unreliable end-to-end datagram service 13002 (such as IP) from the lower level protocols. 13004 $ transmission security (TRANSEC) 13005 (I) Measures that protect communications from interception and 13006 exploitation by means other than cryptanalysis. Usually understood 13007 to be a part of COMSEC. (Compare: traffic flow confidentiality.) 13009 $ Transport Layer Security (TLS) 13010 (I) TLS Version 1.0 is an Internet protocol [R2246] that is based 13011 on, and very similar to, SSL Version 3.0. (Compare: TLSP.) 13013 Usage: The TLS protocol is misnamed, because it operates well 13014 above the IPS transport layer. 13016 $ Transport Layer Security Protocol (TLSP) 13017 (N) An end-to-end encryption protocol (ISO 10736) that provides 13018 security services at the bottom of OSIRM layer 4, i.e., directly 13019 above layer 3. (Compare: TLS.) 13021 Tutorial: TLSP evolved directly from SP4. 13023 $ transport mode 13024 (I) One of two ways to apply AH or ESP to protect data packets; in 13025 this mode, the IPsec protocol encapsulates (i.e., the protection 13026 applies to) the packets of an IPS transport protocol (e.g., TCP, 13027 UDP), which is normally carried directly above IP in an IPS 13028 protocol stack. (Compare: tunnel mode.) 13030 Tutorial: An IPsec transport-mode security association is always 13031 between two hosts; neither end has the role of a security gateway. 13032 Whenever either end of an IPsec security association is a security 13033 gateway, the association is required to be in tunnel mode. 13035 $ transposition 13036 (I) /cryptography/ A method of encryption in which elements of the 13037 plain text retain their original form but undergo some change in 13038 their relative position. (Compare: substitution.) 13040 $ trap door 13041 (I) Synonym for "back door". 13043 $ Triple Data Encryption Algorithm 13044 (I) An block cipher that transforms each 64-bit plaintext block by 13045 applying the DEA three successive times, using either two or three 13046 different keys for an effective key length of 112 or 168 bits. 13047 [A9052, SP67] 13048 Example: A variation proposed for IPsec's ESP uses a 168-bit key, 13049 consisting of three independent 56-bit values used by the DEA, and 13050 a 64-bit initialization vector. Each datagram contains an IV to 13051 ensure that each received datagram can be decrypted even when 13052 other datagrams are dropped or a sequence of datagrams is 13053 reordered in transit. [R1851] 13055 $ triple-wrapped 13056 (I) /S-MIME/ Data that has been signed with a digital signature, 13057 and then encrypted, and then signed again. [R2634] 13059 $ Trojan horse 13060 (I) A computer program that appears to have a useful function, but 13061 also has a hidden and potentially malicious function that evades 13062 security mechanisms, sometimes by exploiting legitimate 13063 authorizations of a system entity that invokes the program. (See: 13064 malware, spyware. Compare: logic bomb, virus, worm.) 13066 $ trust 13067 1. (I) /information system/ The extent to which someone who relies 13068 on a system can have confidence that the system meets its 13069 specifications, i.e., that the system does what it claims to do 13070 and does not perform unwanted functions. (See: trust level, 13071 trusted system, trustworthy system. Compare: assurance.) 13073 2. (I) /PKI/ A relationship between a certificate user and a CA in 13074 which the user acts according to the assumption that the CA 13075 creates only valid digital certificates. 13077 Tutorial: "Generally, an entity is said to 'trust' a second entity 13078 when the first entity makes the assumption that the second entity 13079 will behave exactly as the first entity expects. This trust may 13080 apply only for some specific function. The key role of trust in 13081 [X.509] is to describe the relationship between an entity and a 13082 [CA]; an entity shall be certain that it can trust the CA to 13083 create only valid and reliable certificates." [X509] 13085 Components can be grouped into three categories of trust [Gass]: 13086 - "Trusted": The component is responsible for enforcing security 13087 policy on other components; the system's security depends on 13088 flawless operation of the component. (See: trusted process.) 13089 - "Benign": The component is not responsible for enforcing 13090 security policy, but it has sensitive authorizations. It must 13091 be trusted not to intentionally violate security policy, but 13092 security violations are assumed to be accidental and not likely 13093 to affect overall system security. 13094 - "Untrusted": The component is of unknown or suspicious 13095 provenance and must be treated as deliberately malicious. (See: 13096 malicious logic.) 13098 $ trust anchor 13099 (D) /PKI/ Synonym for "trusted certificate", "root", "root 13100 certificate", or "root key". (See: trust chain.) 13102 Deprecated Term: ISDs SHOULD NOT use this term; it unnecessarily 13103 duplicates the meaning of other terms and mixes concepts in a 13104 potentially misleading way. (See: (Deprecated Term under) trust 13105 chain.) 13107 $ trust chain 13108 (D) Synonym for "certification path". (See: trust anchor, trusted 13109 certificate.) 13111 Deprecated Term: ISDs SHOULD NOT use this term, because it 13112 unnecessarily duplicates the meaning of the internationally 13113 standardized term. 13115 This term also mixes concepts in a potentially misleading way. 13116 Having "trust" involves factors unrelated to verifying signatures 13117 and performing other tests as specified by a standard for path 13118 validation (e.g., RFC 3280). Thus, even if a user is able to 13119 validate a certification path, the user still might distrust one 13120 of the CAs that issued certificates in that path or distrust some 13121 other aspects of the PKI. 13123 $ trust-file PKI 13124 (I) A non-hierarchical PKI in which each certificate user has a 13125 local file (which is used by application software) of public-key 13126 certificates that the user trusts as starting points (i.e., roots) 13127 for certification paths. (Compare: hierarchical PKI, mesh PKI, 13128 trusted certificate, web of trust.) 13130 Example: Popular browsers are distributed with an initial file of 13131 root certificates, which often are self-signed certificates. Users 13132 can add certificates to the file or delete from it. The file may 13133 be directly managed by the user, or the user's organization may 13134 manage it from a centralized server. 13136 $ trust hierarchy 13137 (D) Synonym for "certification hierarchy". 13139 Deprecated Usage: ISDs SHOULD NOT use this term because it mixes 13140 concepts in a potentially misleading way. (See: trust, trust 13141 chain, web of trust.) 13143 $ trust level 13144 (I) A characterization of a standard of security protection to be 13145 met by an information system. (See: Common Criteria, TCSEC.) 13147 Tutorial: A trust level is based not only on (a) the presence of 13148 security mechanisms, but also on the use of (b) systems 13149 engineering discipline to properly structure the system and (c) 13150 implementation analysis to ensure that the system provides an 13151 appropriate degree of trust. 13153 $ trusted certificate 13154 (I) A certificate upon which a certificate user relies as being 13155 valid without the need for validation testing; especially a 13156 public-key certificate that is used to provide the first public 13157 key in a certification path. (See: certification path, root 13158 certificate, validation.) 13160 Tutorial: A trusted public-key certificate might be (a) the root 13161 certificate in a hierarchical PKI, (b) the certificate of the CA 13162 that issued the user's own certificate in a mesh PKI, or (c) a 13163 certificate accepted by the user in a trust-file PKI. 13165 $ Trusted Computer System Evaluation Criteria (TCSEC) 13166 (N) A standard for evaluating the security provided by operating 13167 systems [CSC001, DoD1]. Known as the "Orange Book" because of the 13168 color of its cover; first document in the Rainbow Series. (See: 13169 Common Criteria, (Deprecated Usage under) Green Book, Orange Book, 13170 trust level, trusted computer system. Compare: TSEC.) 13172 Tutorial: The TCSEC defines classes of hierarchically ordered 13173 assurance levels for rating computer systems. From highest to 13174 lowest, the classes are as follows: 13176 - Division A. Verified protection. 13177 Beyond A1. Beyond current technology. (See: beyond A1.) 13178 Class A1. Verified design. (See: SCOMP.) 13179 - Division B: Mandatory protection. 13180 Class B3. Security domains. 13181 Class B2. Structured protection. (See: Multics.) 13182 Class B1. Labeled security protection. 13183 - Division C: Discretionary protection. 13184 Class C2. Controlled access protection. 13185 Class C1. Discretionary security protection. 13186 - Division D: Minimal protection; i.e., has been evaluated but 13187 does not meet the requirements for a higher evaluation class. 13189 $ trusted computing base (TCB) 13190 (N) "The totality of protection mechanisms within a computer 13191 system, including hardware, firmware, and software, the 13192 combination of which is responsible for enforcing a security 13193 policy." [NCS04] (See: (discussion of "trusted" under) trust.) 13195 $ trusted distribution 13196 (I) /computer security/ "A trusted method for distributing the TCB 13197 hardware, software, and firmware components, both originals and 13198 updates, that provides methods for protecting the TCB from 13199 modification during distribution and for detection of any changes 13200 to the TCB that may occur." [NCS04] (See: code signing, 13201 configuration control.) 13203 $ trusted key 13204 (I) A public key upon which a user relies; especially a public key 13205 that can be used as the first public key in a certification path. 13206 (See: certification path, root key, validation.) 13208 Tutorial: A trusted public key might be (a) the root key in a 13209 hierarchical PKI, (b) the key of the CA that issued the user's own 13210 certificate in a mesh PKI, or (c) any key accepted by the user in 13211 a trust-file PKI. 13213 $ trusted path 13214 1a. (I) /COMPUSEC/ A mechanism by which a computer system user can 13215 communicate directly and reliably with the TCB and that can only 13216 be activated by the user or the TCB and cannot be imitated by 13217 untrusted software within the computer. [NCS04] 13219 1b. (I) /COMSEC/ A mechanism by which a person or process can 13220 communicate directly with a cryptographic module and that can only 13221 be activated by the person, process, or module, and cannot be 13222 imitated by untrusted software within the module. [FP140] 13224 $ trusted process 13225 1. (I) A system component that has privileges that enable it to 13226 affect the state of system security and that can, therefore, 13227 through incorrect or malicious execution, violate the system's 13228 security policy. (See: privileged process, trusted system.) 13230 $ trusted recovery 13231 (I) A process that, after a system has experienced a failure or an 13232 attack, restores the system to normal operation (or to a secure 13233 state) without causing a security compromise. (See: recovery.) 13235 $ trusted subnetwork 13236 (I) A subnetwork containing hosts and routers that trust each 13237 other not to engage in active or passive attacks. (There also is 13238 an assumption that the underlying communication channels -- e.g., 13239 telephone lines, or a LAN -- are protected from attack.) 13241 $ trusted system 13242 1. (I) /information system/ A system that operates as expected, 13243 according to design and policy, doing what is required -- despite 13244 environmental disruption, human user and operator errors, and 13245 attacks by hostile parties -- and not doing other things [NRC98]. 13246 (See: trust level, trusted process. Compare: trustworthy.) 13248 2. (N) /multilevel secure/ "A [trusted computer system is a] 13249 system that employs sufficient hardware and software assurance 13250 measures to allow its use for simultaneous processing of a range 13251 of sensitive or classified information." [NCS04] (See: multilevel 13252 security mode.) 13254 $ Trusted Systems Interoperability Group (TSIG) 13255 (N) A forum of computer vendors, system integrators, and users 13256 devoted to promoting interoperability of trusted computer systems. 13258 $ trustworthy system 13259 1. (I) A system that not only is trusted, but also for which the 13260 trust can be guaranteed in some convincing way, such as through 13261 formal analysis or code review. (See: trust. Compare: trusted.) 13263 2. (O) /Digital Signature Guidelines/ "Computer hardware, 13264 software, and procedures that: (a) are reasonably secure from 13265 intrusion and misuse; (b) provide a reasonably reliable level of 13266 availability, reliability, and correct operation; (c) are 13267 reasonably suited to performing their intended functions; and (d) 13268 adhere to generally accepted security principles." [ABA] 13270 $ TSEC 13271 (O) See: Telecommunications Security Nomenclature System. 13272 (Compare: TCSEC.) 13274 $ TSIG 13275 (N) See: Trusted System Interoperability Group. 13277 $ tunnel 13278 1. (I) A communication channel created in a computer network by 13279 encapsulating (i.e., layering) a communication protocol's data 13280 packets in (i.e., above) a second protocol that normally would be 13281 carried above, or at the same layer as, the first one. (See: L2TP, 13282 VPN.) 13284 Tutorial: Tunneling can involve almost any OSIRM or TCP/IP 13285 protocol layers; for example, a TCP connection between two hosts 13286 could conceivably be tunneled through email messages across the 13287 Internet. However, a tunnel usually is a logical point-to-point 13288 link -- i.e., an OSIRM layer 2 connection -- created by 13289 encapsulating the layer 2 protocol in an IPS transport layer 13290 protocol (such as TCP), in an IPS network or internetwork layer 13291 protocol (such as IP), or in another layer 2 protocol. In many 13292 cases, the encapsulation is accomplished with an extra, 13293 intermediate protocol, i.e., a tunneling protocol (such as L2TP) 13294 that is layered between the tunneled layer 2 protocol and the 13295 encapsulating protocol. 13297 Tunneling can be used to move data between computers that use a 13298 protocol not supported by the network connecting them. Tunneling 13299 also can enable a computer network to use the services of a second 13300 network as though the second network were a set of point-to-point 13301 links between the first network's nodes. (See: virtual private 13302 network.) 13304 2. (O) /SET/ The name of a SET private extension that indicates 13305 whether the CA or the payment gateway supports passing encrypted 13306 messages to the cardholder through the merchant. If so, the 13307 extension lists OIDs of symmetric encryption algorithms that are 13308 supported. 13310 $ tunnel mode 13311 (I) One of two ways to apply the IPsec protocols (AH and ESP) to 13312 protect data packets; in this mode, the IPsec protocol 13313 encapsulates (i.e., the protection applies to) IP packets, rather 13314 than the packets of higher layer protocols. (Compare: transport 13315 mode.) 13317 Tutorial: Each end of a tunnel-mode security association may be 13318 either a host or a security gateway. Whenever either end of an 13319 IPsec security association is a security gateway, the association 13320 is required to be in tunnel mode. 13322 $ two-person control 13323 (I) The close surveillance and control of a system, a process, or 13324 materials (especially with regard to cryptography) at all times by 13325 a minimum of two appropriately authorized persons, each capable of 13326 detecting incorrect and unauthorized procedures with respect to 13327 the tasks to be performed and each familiar with established 13328 security requirements. (See: dual control, no-lone zone.) 13330 $ type 0 product 13331 (O) /cryptography, U.S. Government/ Classified cryptographic 13332 equipment endorsed by NSA specifically for use (when appropriately 13333 keyed) in electronically distributing bulk keying material. 13335 $ type 1 product 13336 (O) /cryptography, U.S. Government/ "Classified or controlled 13337 cryptographic item endorsed by the NSA for securing classified and 13338 sensitive U.S. Government information, when appropriately keyed. 13339 The term refers only to products, and not to information, key, 13340 services, or controls. Type 1 products contain classified NSA 13341 algorithms. They are available to U.S. Government users, their 13342 contractors, and federally sponsored non-U.S. Government 13343 activities subject to export restrictions in accordance with 13344 International Traffic in Arms Regulation." [C4009] (See: ITAR.) 13346 $ type 2 product 13347 (O) /cryptography, U.S. Government/ "Unclassified cryptographic 13348 equipment, assembly, or component, endorsed by the NSA, for use in 13349 national security systems as defined in Title 40 U.S.C. Section 13350 1452." [C4009] (See: national security system. Compare: EUCI.) 13352 $ type 3 algorithm 13353 (O) /cryptography, U.S. Government/ "Cryptographic algorithm 13354 registered by [NIST] and published as a [FIPS] for use in 13355 protecting unclassified sensitive information or commercial 13356 information." [C4009] 13358 $ type 4 algorithm 13359 (O) /cryptography, U.S. Government/ "Unclassified cryptographic 13360 algorithm that has been registered by [NIST] but not published as 13361 a [FIPS]." [C4009] 13363 $ UDP 13364 (I) See: User Datagram Protocol. 13366 $ UDP flood 13367 (I) A denial-of-service attack that connects one system's UDP test 13368 function that generates a series of characters for each packet it 13369 receives, to another system's UPD test function that echoes any 13370 character it receives, resulting in a nonstop flood of data 13371 between the two systems. 13373 $ unauthorized disclosure 13374 (I) A circumstance or event whereby an entity gains access to 13375 information for which the entity is not authorized. 13377 Tutorial: This type of threat consequence can be caused by the 13378 following types of threat actions: exposure, interception, 13379 inference, intrusion. Some methods of protecting against this 13380 consequence include access control, flow control, and inference 13381 control. (See: data confidentiality.) 13383 $ unauthorized user 13384 (I) /access control/ A system entity that accesses a system 13385 resource for which the entity has not received an authorization. 13386 (See: user. Compare: authorized user, insider, outsider.) 13388 Usage: The term is used in many ways and could easily be 13389 misunderstood; therefore, ISDs that use this term SHOULD state a 13390 definition for it. 13392 $ uncertainty 13393 (I) An information-theoretic measure (usually stated as a number 13394 of bits) of the minimum amount of plaintext information that needs 13395 to be recovered from cipher text in order to learn the entire 13396 plain text that was encrypted. [SP63] (See: entropy.) 13398 $ unclassified 13399 (I) Not classified. 13401 $ unencrypted 13402 (I) Not encrypted. 13404 $ unforgeable 13405 (I) /cryptography/ The property of a cryptographic data structure 13406 (i.e., a data structure that is defined using one or more 13407 cryptographic functions; e.g., see digital certificate) that makes 13408 it computationally infeasible to construct (i.e., compute) an 13409 unauthorized but correct value of the structure without having 13410 knowledge of one of more keys. 13412 Tutorial: This definition is narrower than general English usage, 13413 where "unforgeable" means unable to be fraudulently created or 13414 duplicated. In that broader sense, anyone can forge a digital 13415 certificate containing any set of data items whatsoever by 13416 generating the to-be-signed certificate and signing it with any 13417 private key whatsoever. But for PKI purposes, the forged data 13418 structure is invalid if it is not signed with the true private key 13419 of the claimed issuer; thus, the forgery will be detected when a 13420 certificate user uses the true public key of the claimed issuer to 13421 verify the signature. 13423 $ uniform resource identifier (URI) 13424 (I) A type of formatted identifier (RFC 1630) that encapsulates 13425 the name of an Internet object, and labels it with an 13426 identification of the name space, thus producing a member of the 13427 universal set of names in registered name spaces and of addresses 13428 referring to registered protocols or name spaces. 13430 Tutorial: URIs are used in HTML to identify the target of 13431 hyperlinks. In common practice, URIs include URLs and relative 13432 URLs (RFC 1808). 13434 $ uniform resource locator (URL) 13435 (I) A type of formatted identifier (RFC 1738) that describes the 13436 access method and location of an information resource object on 13437 the Internet. 13439 Tutorial: A URL is a URI that provides explicit instructions on 13440 how to access the named object. For example, 13441 "ftp://bbnarchive.bbn.com/foo/bar/picture/cambridge.zip" is a URL. 13442 The part before the colon specifies the access scheme or protocol, 13443 and the part after the colon is interpreted according to that 13444 access method. Usually, two slashes after the colon indicate the 13445 host name of a server (written as a domain name). In an FTP or 13446 HTTP URL, the host name is followed by the path name of a file on 13447 the server. The last (optional) part of a URL may be either a 13448 fragment identifier that indicates a position in the file, or a 13449 query string. 13451 $ uniform resource name (URN) 13452 (I) A URI that has an institutional commitment to persistence and 13453 availability. 13455 $ untrusted process 13456 1. (I) A system component that is not able to affect the state of 13457 system security through incorrect or malicious operation. Example: 13458 A component that has its operations confined by a security kernel. 13459 (See: trusted process.) 13461 2. (I) A system component that (a) has not been evaluated or 13462 examined for adherence to a specified security policy and, 13463 therefore, (b) must be assumed to contain logic that might attempt 13464 to circumvent system security. 13466 $ UORA 13467 (O) See: user-PIN ORA. 13469 $ update 13470 See: certificate update and key update. 13472 $ upgrade 13473 (I) /data security/ Increase the classification level of data 13474 without changing the information content of the data. (Compare: 13475 downgrade. See: regrade.) 13477 $ URI 13478 (I) See: uniform resource identifier. 13480 $ URL 13481 (I) See: uniform resource locator. 13483 $ URN 13484 (I) See: uniform resource name. 13486 $ user 13487 (I) An active system entity that uses a product or service 13488 provided by the system, or that accesses system resources to 13489 produce a product or service of the system. (See: access, [R2504]. 13490 Compare: authorized user, manager, operator, principal, subject, 13491 subscriber, unauthorized user.) 13493 Usage: The term is used in many ways and could easily be 13494 misunderstood; therefore, ISDs that use this term SHOULD state a 13495 definition for it. 13497 - This term usually refers to an entity that has been authorized 13498 to access the system, but the term sometimes is used without 13499 regard for whether access is authorized. 13500 - This term usually refers to a living human being acting either 13501 personally or in an organizational role, but the term may refer 13502 to an automated process in the form of either hardware or 13503 software or both, or to a set of persons, or to a set of 13504 processes 13505 - ISDs SHOULD exclude the case of a mixed set containing both 13506 persons and processes. The exclusion is intended to prevent 13507 situations that might require a security policy to be 13508 interpreted in two different and conflicting ways. 13510 $ user authentication service 13511 (I) A security service that verifies that the identity claimed by 13512 an entity that attempts to access the system. (See: 13513 authentication, user.) 13515 $ User Datagram Protocol (UDP) 13516 (I) An Internet Standard, transport-layer protocol (RFC 768) that 13517 delivers a sequence of datagrams from one computer to another in a 13518 computer network. (See: UPD flood.) 13520 Tutorial: UDP assumes that IP is the underlying protocol. UDP 13521 enables application programs to send transaction-oriented data to 13522 other programs with minimal protocol mechanism. UDP does not 13523 provide reliable delivery, flow control, sequencing, or other end- 13524 to-end service guarantees that TCP does. 13526 $ user identity 13527 (I) See: identity. 13529 $ user identifier 13530 (I) See: identifier. 13532 $ user PIN 13533 (O) /MISSI/ One of two PINs that control access to the functions 13534 and stored data of a FORTEZZA PC card. Knowledge of the user PIN 13535 enables the card user to perform the FORTEZZA functions that are 13536 intended for use by an end user. (Compare: SSO PIN.) 13538 $ user-PIN ORA (UORA) 13539 (O) /MISSI/ A MISSI organizational RA that operates in a mode in 13540 which the ORA performs only the subset of card management 13541 functions that are possible with knowledge of the user PIN for a 13542 FORTEZZA PC card. (See: no-PIN ORA, SSO-PIN ORA.) 13544 $ usurpation 13545 (I) A circumstance or event that results in control of system 13546 services or functions by an unauthorized entity. This type of 13547 threat consequence can be caused by the following types of threat 13548 actions: misappropriation, misuse. (See: access control.) 13550 $ UTCTime 13551 (N) The ASN.1 data type "UTCTime" contains a calendar date 13552 (YYMMDD) and a time to a precision of either one minute (HHMM) or 13553 one second (HHMMSS), where the time is either (a) Coordinated 13554 Universal Time or (b) the local time followed by an offset that 13555 enables Coordinated Universal Time to be calculated. Note: UTCTime 13556 has the Year 2000 problem. (See: Coordinated Universal Time, 13557 GeneralizedTime.) 13559 $ v1 certificate 13560 (I) An abbreviation that ambiguously refers to either an "X.509 13561 public-key certificate in version 1 format" or an "X.509 attribute 13562 certificate in version 1 format". 13564 Deprecated Usage: ISDs MAY use this term as an abbreviation for 13565 "version 1 X.509 public-key certificate", but only after using the 13566 full term at the first instance. Otherwise, the term is ambiguous, 13567 because X.509 specifies both v1 public-key certificates and v1 13568 attribute certificates. (See: X.509 attribute certificate, X.509 13569 public-key certificate.) 13571 $ v1 CRL 13572 (I) An abbreviation for "X.509 CRL in version 1 format". 13574 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 13575 term at its first occurrence and define the abbreviation there. 13577 $ v2 certificate 13578 (I) An abbreviation for "X.509 public-key certificate in version 2 13579 format". 13581 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 13582 term at its first occurrence and define the abbreviation there. 13584 $ v2 CRL 13585 (I) An abbreviation for "X.509 CRL in version 2 format". 13587 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 13588 term at its first occurrence and define the abbreviation there. 13590 $ v3 certificate 13591 (I) An abbreviation for "X.509 public-key certificate in version 3 13592 format". 13594 Usage: ISDs MAY use this abbreviation, but SHOULD use the full 13595 term at its first occurrence and define the abbreviation there. 13597 $ valid certificate 13598 1. (I) A digital certificate that can be validated successfully. 13599 (See: validate, verify.) 13601 2. (I) A digital certificate for which the binding of the data 13602 items can be trusted. 13604 $ valid signature 13605 (D) Synonym for "authentic signature". 13607 Deprecated Term: ISDs SHOULD NOT use this term; instead, say 13608 "authentic signature". This Glossary recommends saying "validate 13609 the certificate" and "verify the signature"; therefore, it would 13610 be inconsistent to say that a signature is "valid". (See: 13611 validate, verify.) 13613 $ validate 13614 1. (I) Establish the soundness or correctness of a construct. 13615 Example: certificate validation. (See: validate vs. verify.) 13617 2. (I) To officially approve something, sometimes in relation to a 13618 standard. Example: NIST validates cryptographic modules for 13619 conformance with FIPS PUB 140 [FP140]. 13621 $ validate vs. verify 13622 Usage: To ensure consistency and align with ordinary English 13623 usage, ISDs SHOULD comply with the following two rules: 13624 - Rule 1: Use "validate" when referring to a process intended to 13625 establish the soundness or correctness of a construct (e.g., 13626 see: certificate validation). (See: validate.) 13627 - Rule 2: Use "verify" when referring to a process intended to 13628 test or prove the truth or accuracy of a fact or value (e.g., 13629 see: authenticate). (See: verify.) 13631 Tutorial: The Internet security community sometimes uses these two 13632 terms inconsistently, especially in a PKI context. Most often, 13633 however, we say "verify the signature" but say "validate the 13634 certificate". That is, we "verify" atomic truths but "validate" 13635 data structures, relationships, and systems that are composed of 13636 or depend on verified items. This usage has a basis in Latin: 13638 The word "valid" derives from a Latin word that means "strong". 13639 Thus, to validate means to check that a construct is sound. For 13640 example, a certificate user validates a public-key certificate to 13641 establish trust in the binding that the certificate asserts 13642 between an identity and a key. This can include checking various 13643 aspects of the certificate's construction, such as verifying the 13644 digital signature on the certificate by performing calculations, 13645 verifying that the current time is within the certificate's 13646 validity period, and validating a certification path involving 13647 additional certificates. 13649 The word "verify" derives from a Latin word that means "true". 13650 Thus, to verify means to check the truth of an assertion by 13651 examining evidence or performing tests. For example, to verify an 13652 identity, an authentication process examines identification 13653 information that is presented or generated. To validate a 13654 certificate, a certificate user verifies the digital signature on 13655 the certificate by performing calculations, verifies that the 13656 current time is within the certificate's validity period, and may 13657 need to validate a certification path involving additional 13658 certificates. 13660 $ validation 13661 (I) See: validate vs. verify. 13663 $ validity period 13664 (I) A data item in a digital certificate that specifies the time 13665 period for which the binding between data items (especially 13666 between the subject name and the public key value in a public-key 13667 certificate) is valid, except if the certificate appears on a CRL 13668 or the key appears on a CKL. 13670 $ value-added network (VAN) 13671 (I) A computer network or subnetwork (usually a commercial 13672 enterprise) that transmits, receives, and stores EDI transactions 13673 on behalf of its users. 13675 Tutorial: A VAN may also provide additional services, ranging from 13676 EDI format translation, to EDI-to-FAX conversion, to integrated 13677 business systems. 13679 $ VAN 13680 (I) See: value-added network. 13682 $ verification 13683 1. (I) /authentication/ Presenting information to establish the 13684 truth of a claimed identity. (See: validate vs. verify.) 13686 2. (N) /computer security/ The process of comparing two levels of 13687 system specification for proper correspondence, such as comparing 13688 a security model with a top-level specification, a top-level 13689 specification with source code, or source code with object code. 13690 [NCS04] 13692 $ verified design 13693 (O) See: TCSEC Class A1. 13695 $ verify 13696 (I) To test or prove the truth or accuracy of a fact or value. For 13697 example, see "authenticate". (See: validate vs. verify.) 13699 $ vet 13700 (I) /verb/ To examine or evaluate thoroughly. (Compare: 13701 authenticate, identity proofing, validate, verify.) 13703 $ violation 13704 See: security violation. 13706 $ virtual private network (VPN) 13707 (I) A restricted-use, logical (i.e., artificial or simulated) 13708 computer network that is constructed from the system resources of 13709 a relatively public, physical (i.e., real) network (e.g., the 13710 Internet), often by using encryption (located at hosts or 13711 gateways), and often by tunneling links of the virtual network 13712 across the real network. 13714 Tutorial: A VPN is generally less expensive to build and operate 13715 than a dedicated real network, because the virtual network shares 13716 the cost of system resources with other users of the underlying 13717 real network. For example, if a corporation has LANs at several 13718 different sites, each connected to the Internet by a firewall, the 13719 corporation could create a VPN by (a) using encrypted tunnels to 13720 connect from firewall to firewall across the Internet and (b) not 13721 allowing any other traffic through the firewalls. 13723 $ virus 13724 (I) A self-replicating (and usually hidden) section of computer 13725 software (usually malicious logic) that propagates by infecting -- 13726 i.e., inserting a copy of itself into and becoming part of -- 13727 another program. A virus cannot run by itself; it requires that 13728 its host program be run to make the virus active. 13730 $ VisaCash 13731 (O) A smartcard-based electronic money system that incorporates 13732 cryptography and can be used to make payments via the Internet. 13733 (See: IOTP.) 13735 $ volatile media 13736 (I) Storage media that require an external power supply to 13737 maintain stored information. (Compare: non-volatile media, 13738 permanent storage.) 13740 $ VPN 13741 (I) See: virtual private network. 13743 $ vulnerability 13744 (I) A flaw or weakness in a system's design, implementation, or 13745 operation and management that could be exploited to violate the 13746 system's security policy. (See: harden.) 13748 Tutorial: A system can have three types of vulnerabilities: (a) 13749 vulnerabilities in design or specification; (b) vulnerabilities in 13750 implementation; and (c) vulnerabilities in operation and 13751 management. Most systems have one or more vulnerabilities, but 13752 this does not mean that the systems are too flawed to use. Not 13753 every threat results in an attack, and not every attack succeeds. 13754 Success depends on the degree of vulnerability, the strength of 13755 attacks, and the effectiveness of any countermeasures in use. If 13756 the attacks needed to exploit a vulnerability are very difficult 13757 to carry out, then the vulnerability may be tolerable. If the 13758 perceived benefit to an attacker is small, then even an easily 13759 exploited vulnerability may be tolerable. However, if the attacks 13760 are well understood and easily made, and if the vulnerable system 13761 is employed by a wide range of users, then it is likely that there 13762 will be enough motivation for someone to launch an attack. 13764 $ W3 13765 (D) Synonym for WWW. 13767 Deprecated Abbreviation: This abbreviation could be confused with 13768 W3C; use "WWW" instead. 13770 $ W3C 13771 See: World Wide Web Consortium. 13773 $ war dialer 13774 (I) A computer program that automatically dials a series of 13775 telephone numbers to find lines connected to computer systems, and 13776 catalogs those numbers so that a cracker can try to break the 13777 systems. 13779 Deprecated Usage: This term could confuse international readers; 13780 therefore, ISDs that use it SHOULD state a definition for it. 13782 $ Wassenaar Arrangement 13783 (N) The Wassenaar Arrangement on Export Controls for Conventional 13784 Arms and Dual-Use Goods and Technologies is a global, multilateral 13785 agreement approved by 33 countries in July 1996 to contribute to 13786 regional and international security and stability, by promoting 13787 information exchange concerning, and greater responsibility in, 13788 transfers of arms and dual-use items, thus preventing 13789 destabilizing accumulations. (See: International Traffic in Arms 13790 Regulations.) 13792 Tutorial: The Arrangement began operations in September 1996 with 13793 headquarters in Vienna. The participating countries were 13794 Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech 13795 Republic, Denmark, Finland, France, Germany, Greece, Hungary, 13796 Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, 13797 Norway, Poland, Portugal, Republic of Korea, Romania, Russian 13798 Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, 13799 Ukraine, United Kingdom, and United States. 13801 Participating countries seek through their national policies to 13802 ensure that transfers do not contribute to the development or 13803 enhancement of military capabilities that undermine the goals of 13804 the arrangement, and are not diverted to support such 13805 capabilities. The countries maintain effective export controls for 13806 items on the agreed lists, which are reviewed periodically to 13807 account for technological developments and experience gained. 13808 Through transparency and exchange of views and information, 13809 suppliers of arms and dual-use items can develop common 13810 understandings of the risks associated with their transfer and 13811 assess the scope for coordinating national control policies to 13812 combat these risks. Members provide semi-annual notification of 13813 arms transfers, covering seven categories derived from the UN 13814 Register of Conventional Arms. Members also report transfers or 13815 denials of transfers of certain controlled dual-use items. 13816 However, the decision to transfer or deny transfer of any item is 13817 the sole responsibility of each participating country. All 13818 measures undertaken with respect to the arrangement are in 13819 accordance with national legislation and policies and are 13820 implemented on the basis of national discretion. 13822 $ watermarking 13823 See: digital watermarking. 13825 $ weak key 13826 (I) In the context of a particular cryptographic algorithm, a key 13827 value that provides poor security. 13829 Example: The DEA has four "weak keys" [Schn] for which encryption 13830 produces the same result as decryption. It also has ten pairs of 13831 "semi-weak keys" [Schn] (also known as "dual keys" [FP074]) for 13832 which encryption with one key in the pair produces the same result 13833 as decryption with the other key. 13835 $ web, Web 13836 1. (C) /not capitalized/ ISD SHOULD NOT capitalize "web" when 13837 using the term (usually as an adjective) to refer generically to 13838 technology -- such as web browsers, web servers, HTTP, and HTML -- 13839 that is used in the Web or similar networks. 13841 2. (I) /capitalized/ ISDs SHOULD capitalize "Web" when using the 13842 term (as either a noun or an adjective) to refer specifically to 13843 the World Wide Web. (Similarly, see: internet.) 13845 Usage: IETF documents SHOULD spell out "World Wide Web" fully at 13846 the first instance of usage and MUST use "Web" and "web" 13847 especially carefully where confusion with the PGP web of trust is 13848 possible. 13850 $ web of trust 13851 (D) /PGP/ A trust-file PKI technique used for building a file of 13852 trusted public keys by making personal judgments about being able 13853 to trust certain people to be holding properly certified keys of 13854 other people. (See: certification hierarchy, mesh PKI.) 13856 Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts 13857 in a potentially misleading way. This PKI technique does not 13858 depend on World Wide Web technology. 13860 $ web server 13861 (I) A software process that runs on a host computer connected to a 13862 network and responds to HTTP requests made by client web browsers. 13864 $ WEP 13865 (N) See: Wired Equivalency Protocol. 13867 $ Wired Equivalent Privacy (WEP) 13868 (N) A cryptographic protocol defined in the IEEE 802.11 standard 13869 encapsulate the packets on wireless LANs. (Frequently referred to 13870 as "Wired Equivalency Protocol".) 13872 Tutorial: The WEP design, which uses RC4 to encrypt the plaintext 13873 and a CRC, has been shown to be flawed in multiple ways; and it 13874 also has often been flawed in implementation and management. 13876 $ wiretapping 13877 (I) An attack that intercepts and accesses information contained 13878 in a data flow in a communication system. (See: active 13879 wiretapping, end-to-end encryption, passive wiretapping.) 13881 Usage: Although the term originally referred to making a 13882 mechanical connection to an electrical conductor that links two 13883 nodes, it is now used to refer to accessing information from any 13884 sort of medium used for a link or even from a node, such as a 13885 gateway or subnetwork switch. 13887 Tutorial: Wiretapping can be characterized according to intent: 13888 - "Active wiretapping" attempts to alter the data or otherwise 13889 affect the flow. 13890 - "Passive wiretapping" only attempts to observe the data flow 13891 and gain knowledge of information contained in it. 13893 $ work factor 13894 1. (I) /COMPUSEC/ The estimated amount of effort or time that can 13895 be expected to be expended by a potential intruder to penetrate a 13896 system, or defeat a particular countermeasure, when using 13897 specified amounts of expertise and resources. (See: strength.) 13899 2. (I) /cryptography/ The estimated amount of computing power and 13900 time needed to break a cryptographic system. 13902 $ World Wide Web ("the Web", WWW) 13903 (N) The global, hypermedia-based collection of information and 13904 services that is available on Internet servers and is accessed by 13905 browsers using Hypertext Transfer Protocol and other information 13906 retrieval mechanisms. (See: web vs. Web, [R2084].) 13908 $ World Wide Web Consortium (W3C) 13909 (N) Created in October 1994 to develop and standardize protocols 13910 to promote the evolution and interoperability of the Web, and now 13911 consisting of over 300 member organizations (commercial firms, 13912 government agencies, schools, and other organizations). 13914 Tutorial: W3C Recommendations are developed through a process 13915 similar to that of the standards published by other organizations, 13916 such as the IETF. The W3 Recommendation Track (i.e., standards 13917 track) has four levels of increasing maturity: Working, Candidate 13918 Recommendation, Proposed Recommendation, and W3C Recommendation 13919 W3C Recommendations are similar to the standards published by 13920 other organizations. (Compare: Internet Standard, ISO.) 13922 $ worm 13923 (I) A computer program that can run independently, can propagate a 13924 complete working version of itself onto other hosts on a network, 13925 and may consume system resources destructively. (See: Morris Worm, 13926 virus.) 13928 $ wrap 13929 (D) To use cryptography to provide data confidentiality service 13930 for keying material. (See: encrypt. Compare: seal.) 13932 Deprecated Term: ISDs SHOULD NOT use this term as defined here; 13933 the definition duplicates the meaning of other, standard terms. 13934 Instead, use "encrypt" or another term that is specific with 13935 regard to the mechanism being used. 13937 $ write 13938 (I) /COMPUSEC/ A fundamental operation in an information system 13939 that results in a flow of information only from a subject to an 13940 object. (See: access mode.) 13942 $ WWW 13943 (I) See: World Wide Web. 13945 $ X.400 13946 (N) An ITU-T Recommendation [X400] that is one part of a joint 13947 ITU-T/ISO multi-part standard (X.400-X.421) that defines the 13948 Message Handling Systems. (The ISO equivalent is IS 10021, parts 13949 1-7.) (See: Message Handling Systems.) 13951 $ X.500 13952 (N) An ITU-T Recommendation [X500] that is one part of a joint 13953 ITU-T/ISO multi-part standard (X.500-X.525) that defines the X.500 13954 Directory, a conceptual collection of systems that provide 13955 distributed directory capabilities for OSI entities, processes, 13956 applications, and services. (The ISO equivalent is IS 9594-1 and 13957 related standards, IS 9594-x.) (See: directory vs. Directory, 13958 X.509.) 13960 Tutorial: The X.500 Directory is structured as a tree (the 13961 Directory Information Tree), and information is stored in 13962 directory entries. Each entry is a collection of information about 13963 one object, and each object has a DN. A directory entry is 13964 composed of attributes, each with a type and one or more values. 13965 For example, if a PKI uses the Directory to distribute 13966 certificates, then the X.509 public-key certificate of an end user 13967 is normally stored as a value of an attribute of type 13968 "userCertificate" in the Directory entry that has the DN that is 13969 the subject of the certificate. 13971 $ X.509 13972 (N) An ITU-T Recommendation [X509] that defines a framework to 13973 provide and support data origin authentication and peer entity 13974 authentication, including formats for X.509 public-key 13975 certificates, X.509 attribute certificates, and X.509 CRLs. (The 13976 ISO equivalent is IS 9498-4.) (See: X.500.) 13978 Tutorial: X.509 describes two "levels" of authentication: "simple 13979 authentication" and "strong authentication". It recommends, "While 13980 simple authentication offers some limited protection against 13981 unauthorized access, only strong authentication should be used as 13982 the basis for providing secure services." 13984 $ X.509 attribute certificate 13985 (N) An attribute certificate in the version 1 (v1) format defined 13986 by X.509. (The v1 designation for an X.509 attribute certificate 13987 is disjoint from the v1 designation for an X.509 public-key 13988 certificate, and from the v1 designation for an X.509 CRL.) 13990 Tutorial: An X.509 attribute certificate has a "subject" field, 13991 but the attribute certificate is a separate data structure from 13992 that subject's public-key certificate. A subject may have multiple 13993 attribute certificates associated with each of its public-key 13994 certificates, and an attribute certificate may be issued by a 13995 different CA than the one that issued the associated public-key 13996 certificate. 13998 An X.509 attribute certificate contains a sequence of data items 13999 and has a digital signature that is computed from that sequence. 14000 In addition to the signature, an attribute certificate contains 14001 items 1 through 9 listed below: 14003 1. version Identifies v1. 14004 2. subject Is one of the following: 14005 2a. baseCertificateID Issuer and serial number of an 14006 X.509 public-key certificate. 14007 2b. subjectName DN of the subject. 14008 3. issuer DN of the issuer (the CA who signed). 14009 4. signature OID of algorithm that signed the cert. 14010 5. serialNumber Certificate serial number; 14011 an integer assigned by the issuer. 14012 6. attCertValidityPeriod Validity period; a pair of UTCTime 14013 values: "not before" and "not after". 14014 7. attributes Sequence of attributes describing the 14015 subject. 14016 8. issuerUniqueId Optional, when a DN is not sufficient. 14017 9. extensions Optional. 14019 $ X.509 authority revocation list 14020 (N) An ARL in one of the formats defined by X.509 -- version 1 14021 (v1) or version 2 (v2). A specialized kind of certificate 14022 revocation list. 14024 $ X.509 certificate 14025 (N) Synonym for "X.509 public-key certificate". 14027 Usage: ISDs MAY use this term as an abbreviation for "X.509 14028 public-key certificate", but only after using the full term at the 14029 first instance. Otherwise, the term is ambiguous, because X.509 14030 specifies both public-key certificates and attribute certificates. 14031 (See: X.509 attribute certificate, X.509 public-key certificate.) 14032 Deprecated Usage: ISDs SHOULD NOT use this term as an abbreviation 14033 for "X.509 attribute certificate", because the term is likely to 14034 be misunderstood to mean "X.509 public-key certificate". 14036 $ X.509 certificate revocation list (CRL) 14037 (N) A CRL in one of the formats defined by X.509 -- version 1 (v1) 14038 or version 2 (v2). (The v1 and v2 designations for an X.509 CRL 14039 are disjoint from the v1 and v2 designations for an X.509 public- 14040 key certificate, and from the v1 designation for an X.509 14041 attribute certificate.) (See: certificate revocation.) 14043 Usage: ISDs SHOULD NOT refer to an X.509 CRL as a digital 14044 certificate; however, note that an X.509 CRL does meet this 14045 Glossary's definition of "digital certificate". Like a digital 14046 certificate, an X.509 CRL makes an assertion and is signed by a 14047 CA. But instead of binding a key or other attributes to a subject, 14048 an X.509 CRL asserts that certain previously-issued X.509 14049 certificates have been revoked. 14051 Tutorial: An X.509 CRL contains a sequence of data items and has a 14052 digital signature computed on that sequence. In addition to the 14053 signature, both v1 and v2 contain items 2 through 6b listed below. 14054 Version 2 contains item 1 and may optionally contain 6c and 7. 14056 1. version Optional. If present, identifies v2. 14057 2. signature OID of the algorithm that signed CRL. 14058 3. issuer DN of the issuer (the CA who signed). 14059 4. thisUpdate A UTCTime value. 14060 5. nextUpdate A UTCTime value. 14061 6. revokedCertificates 3-tuples of 6a, 6b, and (optional) 6c: 14062 6a. userCertificate A certificate's serial number. 14063 6b. revocationDate UTCTime value for the revocation date. 14064 6c. crlEntryExtensions Optional. 14065 7. crlExtensions Optional. 14067 $ X.509 public-key certificate 14068 (N) A public-key certificate in one of the formats defined by 14069 X.509 -- version 1 (v1), version 2 (v2), or version 3 (v3). (The 14070 v1 and v2 designations for an X.509 public-key certificate are 14071 disjoint from the v1 and v2 designations for an X.509 CRL, and 14072 from the v1 designation for an X.509 attribute certificate.) 14074 Tutorial: An X.509 public-key certificate contains a sequence of 14075 data items and has a digital signature computed on that sequence. 14076 In addition to the signature, all three versions contain items 1 14077 through 7 listed below. Only v2 and v3 certificates may also 14078 contain items 8 and 9, and only v3 may contain item 10. 14080 1. version Identifies v1, v2, or v3. 14081 2. serialNumber Certificate serial number; 14082 an integer assigned by the issuer. 14084 3. signature OID of algorithm that was used to 14085 sign the certificate. 14086 4. issuer DN of the issuer (the CA who signed). 14087 5. validity Validity period; a pair of UTCTime 14088 values: "not before" and "not after". 14089 6. subject DN of entity who owns the public key. 14090 7. subjectPublicKeyInfo Public key value and algorithm OID. 14091 8. issuerUniqueIdentifier Defined for v2, v3; optional. 14092 9. subjectUniqueIdentifier Defined for v2, v2; optional. 14093 10. extensions Defined only for v3; optional. 14095 $ X9 14096 See: (Accredited Standards Committee X9 under) ANSI. 14098 $ XML 14099 (N) See: Extensible Markup Language. 14101 $ XML-Signature. 14102 (N) A W3C Recommendation (i.e. approved standard) that specifies 14103 XML syntax and processing rules for creating and representing 14104 digital signatures (based on asymmetric cryptography) that can be 14105 applied to any digital content (i.e., any data object) including 14106 other XML material. 14108 $ XTACACS 14109 (I) Cisco Corporation's implementation of the Terminal Access 14110 Controller (TAC) Access Control System. This implementation 14111 enhances and extends the original TACACS. (See: TACACS, TACACS+.) 14113 $ Yellow Book 14114 (D) Synonym for "Computer Security Requirements: Guidance for 14115 Applying the [U.S.] Department of Defense Trusted Computer System 14116 Evaluation Criteria in Specific Environments" [CSC3] (See: (first 14117 law under) Courtney's laws). 14119 Deprecated Term: ISDs SHOULD NOT use this term as a synonym for 14120 that or any other document. Instead, use the full proper name of 14121 the document or, in subsequent references, a conventional 14122 abbreviation. (See: (Deprecated Usage under) Green Book, Rainbow 14123 Series.) 14125 $ zero-knowledge proof 14126 (I) /cryptography/ A proof-of-possession protocol whereby a system 14127 entity can prove possession of some information to another entity, 14128 without revealing any of that information. (See: proof-of- 14129 possession protocol.) 14131 $ zeroize 14132 1. (I) Synonym for "purge". Usage: Particularly with regard to 14133 erasing keys that are stored in a cryptographic module. 14135 2. (O) Erase electronically stored data by altering the contents 14136 of the data storage so as to prevent the recovery of the data. 14137 [FP140] 14139 $ zombie 14140 (I) An Internet host computer that has been surreptitiously 14141 penetrated by an intruder that installed malicious daemon software 14142 to cause the host to operate as an accomplice in attacking other 14143 hosts, particularly in distributed attacks that attempt denial of 14144 service through flooding. 14146 Deprecated Term: It is likely that other cultures have different 14147 metaphors for this concept. Therefore, to ensure international 14148 understanding, ISDs SHOULD NOT use this term. (See: (Deprecated 14149 Usage under) Green Book.) 14151 $ zone of control 14152 (O) /EMSEC/ Synonym for "inspectable space". [C4009] (See: 14153 TEMPEST.) 14155 5. References 14157 This Glossary focuses on the Internet Standards Process. Therefore, 14158 this set of references emphasizes international, governmental, and 14159 industry standards documents. 14161 [A1523] American National Standards Institute, "American National 14162 Standard Telecomm Glossary", ANSI T1.523-2001. 14164 [A3092] ---, "American National Standard Data Encryption Algorithm", 14165 ANSI X3.92-1981, 30 Dec 1980. 14167 [A9009] ---, "Financial Institution Message Authentication 14168 (Wholesale)", ANSI X9.9-1986, 15 Aug 1986. 14170 [A9017] ---, "Financial Institution Key Management (Wholesale)", 14171 X9.17, 4 Apr 1985. [Defines procedures for the manual and 14172 automated management of keying material and uses DES to 14173 provide key management for a variety of operational 14174 environments.] 14176 [A9042] ---, "Public key Cryptography for the Financial Service 14177 Industry: Agreement of Symmetric Keys Using Diffie-Hellman 14178 and MQV Algorithms", X9.42, 29 Jan 1999. 14180 [A9052] ---, "Triple Data Encryption Algorithm Modes of Operation", 14181 X9.52-1998, ANSI approval 9 Nov 1998. 14183 [A9062] ---, "Public Key Cryptography for the Financial Services 14184 Industry: The Elliptic Curve Digital Signature Algorithm 14185 (ECDSA)", X9.62-1998, ANSI approval 7 Jan 1999. 14187 [A9063] ---, "---: Key Agreement and Key Transport Using Elliptic 14188 Curve Cryptography", X9.63-2001. 14190 [ABA] American Bar Association, "Digital Signature Guidelines: 14191 Legal Infrastructure for Certification Authorities and 14192 Secure Electronic Commerce", Chicago, IL, 1 Aug 1996. 14194 [ACM] Association for Computing Machinery, "Communications of the 14195 ACM", Jul 1998 issue with: M. Yeung, "Digital Watermarking"; 14196 N. Memom and P. Wong, "Protecting Digital Media Content"; 14197 and S. Craver, B.-L. Yeo, and M. Yeung, "Technical Trials 14198 and Legal Tribulations". 14200 [Ande] J. Anderson, "Computer Security Technology Planning Study", 14201 ESD-TR-73-51, Vols. I and II, USAF Electronics Systems Div., 14202 Bedford, MA, Oct 1972. (Available as AD-758206 and -772806, 14203 National Technical Information Service, Springfield, VA.) 14205 [ANSI] American National Standards Institute, "Role Based Access 14206 Control", Secretariat, Information Technology Industry 14207 Council, BSR INCITS 359, DRAFT, 10 Nov 2003. 14209 [Army] U.S. Army Corps of Engineers, "Electromagnetic Pulse (EMP) 14210 and Tempest Protection for Facilities", EP 1110-3-2, 31 Dec 14211 1990. 14213 [B1822] Bolt Baranek and Newman Inc., "Appendix H: Interfacing a 14214 Host to a Private Line Interface" in "Specifications for the 14215 Interconnection of a Host and an IMP", BBN Report No. 1822, 14216 revised, Dec 1983. 14218 [B4799] ---, "A History of the Arpanet: The First Decade", BBN 14219 Report No. 4799, Apr 1981. 14221 [BS7799] British Standards Institution, "Information Security 14222 Management, Part 1: Code of Practice for Information 14223 Security Management", BS 7799-1:1999, effective 15 May 1999. 14225 ---, ---, "Part 2: Specification for Information Security 14226 Management Systems", BS 7799-2:1999, effective 15 May 1999. 14228 [Bell] D. Bell and L. LaPadula, "Secure Computer Systems: 14229 Mathematical Foundations and Model", M74-244, The MITRE 14230 Corporation, Bedford, MA, May 1973. (Available as AD-771543, 14231 National Technical Information Service, Springfield, VA.) 14233 [Biba] K. Biba, "Integrity Considerations for Secure Computer 14234 Systems", ESD-TR-76-372, USAF Electronic Systems Division, 14235 Bedford, MA, Apr 1977. 14237 [BN89] D. Brewer and M. Nash, "The Chinese wall security policy", 14238 in "Proceedings of IEEE Symposium on Security and Privacy", 14239 May 1989, pp. 205-214. 14241 [C4009] Committee National Security System, "National Information 14242 Assurance (IA) Glossary", CNSS Instruction No. 4009, revised 14243 May 2003. 14245 [CCIB] Common Criteria Implementation Board, "Common Criteria for 14246 Information Technology Security Evaluation, Part 1: 14247 Introduction and General Model", ver. 2.0, CCIB-98-026, May 14248 1998. 14250 [Chau] D. Chaum, "Untraceable Electronic Mail, Return Addresses, 14251 and Digital Pseudonyms", in "Communications of the ACM", 14252 vol. 24, no. 2, Feb 1981, pp. 84-88. 14254 [Cheh] M. Cheheyl, M. Gasser, G. Huff, and J. Millen, "Verifying 14255 Security", in "ACM Computing Surveys", vol. 13, no. 3, Sep 14256 1981, pp. 279-339. 14258 [Chris] M. Chrissis et al, 1993. "SW-CMM [Capability Maturity Model 14259 for Software Version", Release 3.0, Software Engineering 14260 Institute, Carnegie Mellon University, Aug 1996. 14262 [CIPSO] Trusted Systems Interoperability Working Group, "Common IP 14263 Security Option", ver. 2.3, 9 Mar 1993. 14265 [Clark] D. Clark and D. Wilson, "A Comparison of Commercial and 14266 Military computer Security Policies", in "Proceedings of the 14267 IEEE Symposium on Security and Privacy", Apr 1987, pp. 184- 14268 194. 14270 [CSC1] U.S. DoD Computer Security Center, "Department of Defense 14271 Trusted Computer System Evaluation Criteria", CSC-STD-001- 14272 83, 15 Aug 1983. (Superseded by [DoD1].) 14274 [CSC2] ---, "Department of Defense Password Management Guideline", 14275 CSC-STD-002-85, 12 Apr 1985. 14277 [CSC3] ---, "Computer Security Requirements: Guidance for Applying 14278 the Department of Defense Trusted Computer System Evaluation 14279 Criteria in Specific Environments", CSC-STD-003-85, 25 Jun 14280 1985. 14282 [CSOR] U.S. Department of Commerce, "General Procedures for 14283 Registering Computer Security Objects", National Institute 14284 of Standards Interagency Report 5308, Dec 1993. 14286 [Daem] J. Daemen and V. Rijmen, "Rijndael, the advanced encryption 14287 standard" in "Dr. Dobb's Journal", vol. 26, no. 3, Mar 2001, 14288 pp.137-139. 14290 [DC6/9] Director of Central Intelligence, "Physical Security 14291 Standards for Sensitive Compartemented [sic] Information 14292 Facilities ", DCI Directive 6/9, 18 Nov 2002. 14294 [Denn] D. Denning, "A Lattice Model of Secure Information Flow", in 14295 "Communications of the ACM", vol. 19, no. 5, May 1976, pp. 14296 236-243. 14298 [Denns] D. Denning and P. Denning, "Data Security" in "ACM Computing 14299 Surveys", vol. 11, no. 3, Sep 1979, pp. 227-249. 14301 [DH76] W. Diffie and M. Hellman, "New Directions in Cryptography" 14302 in "IEEE Transactions on Information Theory", vol. IT-22, 14303 no. 6, Nov 1976, pp. 644-654. 14305 [DoD1] U.S. DoD, "Department of Defense Trusted Computer System 14306 Evaluation Criteria", DoD 5200.28-STD, 26 Dec 1985. 14307 (Supersedes [CSC1].) (Superseded by DoD Directive 8500.1.) 14309 [DoD2] ---, Directive 5200.28, "Security Requirements for Automated 14310 Information Systems (AISs)", 21 Mar 1988. (Superseded by DoD 14311 Directive 8500.1.) 14313 [DoD3] ---, "X.509 Certificate Policy for the United States 14314 Department of Defense", version 7, 18 Dec 2002. 14316 [DoD4] ---, "NSA Key Recovery Assessment Criteria", 8 Jun 1998. 14318 [DoD5] ---, Directive 5200.1, "DoD Information Security Program", 14319 13 Dec 1996. 14321 [DoD6] ---, "DoD Architecture Framework", Version 1, 30 Aug 2003. 14323 [ElGa] T. El Gamal, "A Public-Key Cryptosystem and a Signature 14324 Scheme Based on Discrete Logarithms" in "IEEE Transactions 14325 on Information Theory", vol. IT-31, no. 4, 1985, pp. 469- 14326 472. 14328 [EMV1] Europay International S.A., MasterCard International 14329 Incorporated, and Visa International Service Association, 14330 "EMV '96 Integrated Circuit Card Specification for Payment 14331 Systems", ver. 3.1.1, 31 May 1998. 14333 [EMV2] ---, "EMV '96 Integrated Circuit Card Terminal Specification 14334 for Payment Systems", ver. 3.1.1, 31 May 1998. 14336 [EMV3] ---, EMV '96 Integrated Circuit Card Application 14337 Specification for Payment Systems", ver. 3.1.1, 31 May 1998. 14339 [F1037] U.S. General Services Administration, "Glossary of 14340 Telecommunications Terms", FED STD 1037C, 7 Aug 1996. 14342 [For94] W. Ford, "Computer Communications Security: Principles, 14343 Standard Protocols and Techniques", ISBN 0-13-799453-2, 14344 1994. 14346 [For97] W. Ford and M. Baum, "Secure Electronic Commerce: Building 14347 the Infrastructure for Digital Signatures and Encryption", 14348 ISBN 0-13-476342-4, 1994. 14350 [FP031] U.S. Department of Commerce, "Guidelines for Automatic Data 14351 Processing Physical Security and Risk Management", Federal 14352 Information Processing Standards Publication (FIPS PUB) 31, 14353 Jun 1974. 14355 [FP039] ---, "Glossary for Computer Systems Security", FIPS PUB 39, 14356 15 Feb 1976. 14358 [FP041] ---, "Computer Security Guidelines for Implementing the 14359 Privacy Act of 1974", FIPS PUB 41, 30 May 1975. 14361 [FP046] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25 Oct 14362 1999. 14364 [FP074] ---, "Data Encryption Standard (DES)", FIPS PUB 46-3, 25 Oct 14365 1999. 14367 [FP081] ---, "DES Modes of Operation", FIPS PUB 81, 2 Dec 1980. 14369 [FP087] ---, "Guidelines for ADP Contingency Planning", FIPS PUB 87, 14370 27 Mar 1981. 14372 [FP102] ---, "Guideline for Computer Security Certification and 14373 Accreditation", FIPS PUB 102, 27 Sep 1983. 14375 [FP113] ---, "Computer Data Authentication", FIPS PUB 113, 30 May 14376 1985. 14378 [FP140] ---, "Security Requirements for Cryptographic Modules", FIPS 14379 PUB 140-2, 25 May 2001 (Change Notices 3 Dec 2002). 14381 [FP151] ---, "Portable Operating System Interface (POSIX)--System 14382 Application Program Interface [C Language]", FIPS PUB 151-2, 14383 12 May 1993 14385 [FP180] ---, "Secure Hash Standard", FIPS PUB 180-2, Aug 2000. 14387 [FP185] ---, "Escrowed Encryption Standard", FIPS PUB 185, 9 Feb 14388 1994. 14390 [FP186] ---, "Digital Signature Standard (DSS)", FIPS PUB 186-2, 27 14391 Jun 2000. 14393 [FP188] ---, "Standard Security Label for Information Transfer", 14394 FIPS PUB 188, 6 Sep 1994. 14396 [FP191] ---, "Guideline for the Analysis of Local Area Network 14397 Security", FIPS PUB 191, 9 Nov 1994. 14399 [FP197] ---, "Advanced Encryption Standard", FIPS PUB 197, 26 Nov 14400 2001. 14402 [FPKI] U.S. Department of Commerce, "Public Key Infrastructure 14403 (PKI) Technical Specifications: Part A--Technical Concept of 14404 Operations", National Institute of Standards, 4 Sep 1998. 14406 [Gass] M. Gasser, "Building a Secure Computer System", Van Nostrand 14407 Reinhold Company, New York, 1988, ISBN 0-442-23022-2. 14409 [Gray] J. Gray and A. Reuter, "Transaction Processing: Concepts and 14410 Techniques", Morgan Kaufmann Publishers, Inc., 1993. 14412 [Hafn] K. Hafner and M. Lyon, "Where Wizards Stay Up Late: The 14413 Origins of the Internet", Simon & Schuster, New York, 1996. 14415 [Huff] G. Huff, "Trusted Computer Systems -- Glossary", MTR 8201, 14416 The MITRE Corporation, Mar 1981. 14418 [I3166] International Standards Organization, "Codes for the 14419 Representation of Names of countries and Their Subdivisions 14420 --Part 1: Country Codes", ISO 3166-1:1997. 14422 ---, --- "Part 2: Country Subdivision Codes", ISO/DIS 3166- 14423 2. 14425 ---, --- "Part 3: Codes for Formerly Used Names of 14426 Countries", ISO/DIS 3166-3. 14428 [I7498] ---, "Information Processing Systems--Open Systems 14429 Interconnection Reference Model--[Part 1:] Basic Reference 14430 Model", ISO/IEC 7498-1. (Equivalent to ITU-T Recommendation 14431 X.200.) 14433 ---, --- "Part 2: Security Architecture", ISO/IEC 7499-2. 14435 ---, --- "Part 4: Management Framework", ISO/IEC 7498-4. 14437 [I7812] ---, "Identification cards--Identification of Issuers--Part 14438 1: Numbering System", ISO/IEC 7812-1:1993 14440 ---, --- "Part 2: Application and Registration Procedures", 14441 ISO/IEC 7812-2:1993. 14443 [I9945] "Portable Operating System Interface for Computer 14444 Environments", ISO/IEC 9945-1: 1990. 14446 [IATF] U.S. DoD, "Information Assurance Technical Framework", 14447 Release 3, NSA, Sep 2000. (See: IATF.) 14449 [IDSAN] ---, "Intrusion Detection System Analyzer Protection 14450 Profile", version 1.1, NSA, 10 Dec 2001. 14452 [IDSSC] ---, "Intrusion Detection System Scanner Protection 14453 Profile", version 1.1, NSA, 10 Dec 2001. 14455 [IDSSE] ---, "Intrusion Detection System Sensor Protection Profile", 14456 version 1.1, NSA, 10 Dec 2001. 14458 [IDSSY] ---, "Intrusion Detection System", version 1.4, NSA, 4 Feb 14459 2002. 14461 [Ioan] J. Ioannidis and M. Blaze, "The Architecture and 14462 Implementation of Network Layer Security in UNIX", in "UNIX 14463 Security IV Symposium", Oct 1993, pp. 29-39. 14465 [ITSEC] "Information Technology Security Evaluation Criteria 14466 (ITSEC): Harmonised Criteria of France, Germany, the 14467 Netherlands, and the United Kingdom", ver. 1.2, U.K. 14468 Department of Trade and Industry, Jun 1991. 14470 [JCSP1] U.S. DoD, "Dictionary of Military and Associated Terms", 14471 Joint Chiefs of Staff, JCS Pub. 1, 1 Apr 1984. 14473 [Kahn] D. Kahn, "The Codebreakers: The Story of Secret Writing", 14474 The Macmillan Company, New York, 1967. 14476 [Knut] D. Knuth, Chapter 3 ("Random Numbers") in Volume 2 14477 ("Seminumerical Algorithms") of "The Art of Computer 14478 Programming", Addison-Wesley, Reading, MA, 1969. 14480 [Kuhn] M. Kuhn and R. Anderson, "Soft Tempest: Hidden Data 14481 Transmission Using Electromagnetic Emanations", in David 14482 Aucsmith, ed., "Information Hiding, Second International 14483 Workshop, IH'98", Portland, Oregon, USA, 15-17 Apr 1998, 14484 LNCS 1525, Springer-Verlag, ISBN 3-540-65386-4, pp. 124-142. 14486 [Land] C. Landwehr, "Formal Models for Computer Security", in "ACM 14487 Computing Surveys", vol. 13, no. 3, Sep 1981, pp. 247-278. 14489 [Larm] J. Larmouth, "ASN.1 Complete", Open System Solutions, 1999 14490 (a freeware book). 14492 [M0404] U.S. Office of Management and Budget, "E-Authentication 14493 Guidance for Federal Agencies", Memorandum M-04-04, 16 Dec 14494 2003. 14496 [Mene] A. Menezes et al, "Some Key Agreement Protocols Providing 14497 Implicit Authentication" in "The 2nd Workshop on Selected 14498 Areas in Cryptography", 1995. 14500 [Moor] A. Moore et al, "Attack Modeling for Information Security 14501 and Survivability", Carnegie-Mellon University / Software 14502 Engineering Institute, CMU/SEI-2001-TN-001, Mar 2001. 14504 [Murr] W. Murray, "Courtney's Laws of Security" in "Infosecurity 14505 News", Mar/Apr 1993, p. 65. 14507 [N4001] National Security Telecommunications and Information System 14508 Security Committee, "Controlled Cryptographic Items", 14509 NSTISSI No. 4001, 25 Mar 1985. 14511 [N4006] ---, "Controlled Cryptographic Items", NSTISSI No. 4006, 2 14512 Dec 1991. 14514 [N7003] ---, "Protective Distribution Systems", NSTISSI No. 7003, 13 14515 Dec 1996. 14517 [NCS01] National Computer Security Center, "A Guide to Understanding 14518 Audit in Trusted Systems", NCSC-TG-001, 1 Jun 1988. (See: 14519 Rainbow Series.) 14521 [NCS03] ---, "Information System Security Policy Guideline", I942-TR- 14522 003, ver. 1, Jul 1994. 14524 [NCS04] ---, "Glossary of Computer Security Terms", NCSC-TG-004, 14525 ver. 1, 21 Oct 1988. (See: Rainbow Series.) 14527 [NCS05] ---, "Trusted Network Interpretation of the Trusted Computer 14528 System Evaluation Criteria", NCSC-TG-005, ver. 1, 31 Jul 14529 1987. (See: Rainbow Series.) 14531 [NCS25] ---, "A Guide to Understanding Data Remanence in Automated 14532 Information Systems", NCSC-TG-025, ver. 2, Sep 1991. (See: 14533 Rainbow Series.) 14535 [NCS25] ---, "A Guide to Understanding Data Remanence in Automated 14536 Information Systems", NCSC-TG-025, ver. 2, Sep 1991. (See: 14537 Rainbow Series.) 14539 [NRC91] National Research Council, "Computers At Risk: Safe 14540 Computing in the Information Age", National Academy Press, 14541 1991. 14543 [NRC98] F. Schneider, ed., "Trust in Cyberspace", National Research 14544 Council, National Academy of Sciences, 1998. 14546 [Park] D. Parker, "Computer Security Management", ISBN 0-8359-0905- 14547 0, 1981 14549 [Perr] T. Perrine et al, "An Overview of the Kernelized Secure 14550 Operating System (KSOS)" in "Proceedings of the 7th DoD/NBS 14551 Computer Security Conference", 24-26 Sep 1984. 14553 [PGP] S. Garfinkel, "PGP: Pretty Good Privacy", O'Reilly & 14554 Associates, Inc., Sebastopol, CA, 1995. 14556 [PKCS] B. Kaliski, Jr., "An Overview of the PKCS Standards", RSA 14557 Data Security, Inc., 3 Jun 1991. 14559 [PKC05] RSA Laboratories, "PKCS #5: Password-Based Encryption 14560 Standard ", ver. 1.5, RSA Laboratories Technical Note, 1 Nov 14561 1993. 14563 [PKC07] ---, "PKCS #7: Cryptographic Message Syntax Standard", ver. 14564 1.5, RSA Laboratories Technical Note, 1 Nov 1993. 14566 [PKC10] ---, "PKCS #10: Certification Request Syntax Standard", ver. 14567 1.0, RSA Laboratories Technical Note, 1 Nov 1993. 14569 [PKC11] ---, "PKCS #11: Cryptographic Token Interface Standard", 14570 ver. 1.0, 28 Apr 1995. 14572 [R1108] S. Kent, "U.S. Department of Defense Security Options for 14573 the Internet Protocol", RFC 1108, Nov 1991. 14575 [R1135] J. Reynolds, "The Helminthiasis of the Internet", RFC 1135, 14576 Dec 1989 14578 [R1157] J. Case et al, "A Simple Network Management Protocol (SNMP)" 14579 [version 1], STD 15, RFC 1157, May 1990. 14581 [R1208] O. Jacobsen et al, "A Glossary of Networking Terms", RFC 14582 1208, Mar 1991. 14584 [R1281] R. Pethia et al, "Guidelines for Secure Operation of the 14585 Internet", RFC 1281, Nov 1991. 14587 [R1319] B. Kaliski, "The MD2 Message-Digest Algorithm", RFC 1319, 14588 Apr 1992. 14590 [R1320] R. Rivest, "The MD4 Message-Digest Algorithm", RFC 1320, Apr 14591 1992. 14593 [R1321] ---, "The MD5 Message-Digest Algorithm", RFC 1321, Apr 1992. 14595 [R1334] B. Lloyd et al, "PPP Authentication Protocols", RFC 1334, 14596 Oct 1992. 14598 [R1413] M. St. Johns, "Identification Protocol", RFC 1413, Feb 1993. 14600 [R1421] J. Linn, "Privacy Enhancement for Internet Electronic Mail, 14601 Part I: Message Encryption and Authentication Procedures", 14602 RFC 1421, Feb 1993. 14604 [R1422] S. Kent, "Privacy Enhancement for Internet Electronic Mail, 14605 Part II: Certificate-Based Key Management", RFC 1422, Feb 14606 1993. 14608 [R1455] D. Eastlake, III, "Physical Link Security Type of Service", 14609 RFC 1455, May 1993. 14611 [R1457] R. Housley, "Security Label Framework for the Internet", RFC 14612 1457, May 1993. 14614 [R1492] C. Finseth, "An Access Control Protocol, Sometimes Called 14615 TACACS", RFC 1492, Jul 1993. 14617 [R1507] C. Kaufman, "DASS: Distributed Authentication Security 14618 Service", RFC 1507, Sep 1993. 14620 [R1510] J. Kohl et al, "The Kerberos Network Authentication Service 14621 (V5)", RFC 1510, Sep 1993 14623 [R1731] J. Myers, "IMAP4 Authentication Mechanisms", RFC 1731, Dec 14624 1994. 14626 [R1734] ---, "POP3 AUTHentication Command", RFC 1734, Dec, 1994. 14628 [R1750] D. Eastlake, 3rd, et al, "Randomness Recommendations for 14629 Security", Dec 1994. 14631 [R1824] H. Danisch, "The Exponential Security System TESS: An 14632 Identity-Based Cryptographic Protocol for Authenticated Key- 14633 Exchange (E.I.S.S.-Report 1995/4)", RFC 1824, Aug 1995. 14635 [R1828] P. Metzger et al, "IP Authentication using Keyed MD5", RFC 14636 1828, Aug 1995. 14638 [R1829] P. Karn et al, "The ESP DES-CBC Transform", RFC 1829, Aug 14639 1995. 14641 [R1848] S. Crocker et al, "MIME Object Security Services", RFC 1848, 14642 Oct 1995. 14644 [R1851] P. Karn et al, "The ESP Triple DES Transform", RFC 1851, Sep 14645 1995. 14647 [R1885] A. Conta et al, "Internet Control Message Protocol (ICMPv6) 14648 for the Internet Protocol Version 6 (IPv6) Specification", 14649 RFC 1885, Dec 1995. 14651 [R1928] M. Leech et al, "SOCKS Protocol Version 5", RFC 1928, Mar 14652 1996. 14654 [R1938] N. Haller et al, "A One-Time Password System", RFC 1938, May 14655 1996. 14657 [R1983] G. Malkin, ed., "Internet Users' Glossary", FYI 18, RFC 14658 1983, Aug 1996. 14660 [R1994] W. Simpson, "PPP Challenge Handshake Authentication Protocol 14661 (CHAP)", RFC 1994, Aug 1996. 14663 [R2026] S. Bradner, "The Internet Standards Process--Revision 3", 14664 BCP009, RFC 2026, Mar 1994. 14666 [R2065] D. Eastlake, 3rd, "Domain Name System Security Extensions", 14667 RFC 2065, Jan 1997. 14669 [R2078] J. Linn, "Generic Security Service Application Program 14670 Interface, Version 2", RFC 2078, Jan 1997. 14672 [R2084] G. Bossert et al, "Considerations for Web Transaction 14673 Security", RFC 2084, Jan 1997. 14675 [R2104] H. Krawczyk et al, "HMAC: Keyed-Hashing for Message 14676 Authentication", RFC 2104, Feb 1997. 14678 [R2137] D. Eastlake, 3rd, "Secure Domain Name System Dynamic 14679 Update", RFC 2137, Apr 1997. 14681 [R2138] C. Rigney et al, "Remote Authentication Dial In User Service 14682 (RADIUS)", RFC 2138, Apr 1997. 14684 [R2179] A. Gwinn, "Network Security For Trade Shows", RFC 2179, Jul 14685 1997. 14687 [R2195] J. Klensin et al, "IMAP/POP AUTHorize Extension for Simple 14688 Challenge/Response", RFC 2195, Sep 1997. 14690 [R2196] B. Fraser, "Site Security Handbook", FYI 8, RFC 2196, Sep 14691 1997. 14693 [R2202] P. Cheng et al, "Test Cases for HMAC-MD5 and HMAC- 14694 SHA-1", RFC 2202, Sep. 1997. 14696 [R2222] J. Myers, "Simple Authentication and Security Layer (SASL)", 14697 RFC 2222, Oct 1997. 14699 [R2223] J. Postel, "Instructions to RFC Authors", RFC 2223, Oct 14700 1997. 14702 [R2246] T. Dierks et al, "The TLS Protocol, Version 1.0", RFC 2246, 14703 Jan 1999. 14705 [R2267] P. Ferguson et al, "Network Ingress Filtering: Defeating 14706 Denial of Service Attacks Which Employ IP Source Address 14707 Spoofing", RFC 2267, Jan 1998 14709 [R2315] B. Kaliski, "PKCS #7: Cryptographic Message Syntax, Version 14710 1.5", RFC 2315, Mar 1998. 14712 [R2323] A. Ramos, "IETF Identification and Security Guidelines", RFC 14713 2323, 1 Apr 1998. [Intended for humorous entertainment 14714 ("please laugh loud and hard"); does not contain serious 14715 security information.] 14717 [R2350] N. Brownlee et al, "Expectations for Computer Security 14718 Incident Response", RFC 2350, Jun 1998. 14720 [R2356] G. Montenegro et al, "Sun's SKIP Firewall Traversal for 14721 Mobile IP", RFC 2356, Jun 1998. 14723 [R2401] S. Kent et al, "Security Architecture for the Internet 14724 Protocol", RFC 2401, Nov 1998. 14726 [R2402] S. Kent et al, "IP Authentication Header", RFC 2402, Nov 14727 1998. 14729 [R2403] C. Madson et al, "The Use of HMAC-MD5-96 within ESP and AH", 14730 RFC 2403, Nov 1998. 14732 [R2404] C. Madson et al, "The Use of HMAC-SHA-1-96 within ESP and 14733 AH", RFC 2404, Nov 1998. 14735 [R2405] C. Madson et al, "The ESP DES-CBC Cipher Algorithm With 14736 Explicit IV", RFC 2405, Nov 1998. 14738 [R2406] S. Kent et al, "IP Encapsulating Security Payload (ESP)", 14739 RFC 2406, Nov 1998. 14741 [R2407] D. Piper, "The Internet IP Security Domain of Interpretation 14742 for ISAKMP", RFC 2407, Nov 1998. 14744 [R2408] D. Maughan et al, "Internet Security Association and Key 14745 Management Protocol (ISAKMP)", RFC 2408, Nov 1998. 14747 [R2409] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", 14748 RFC 2409, Nov 1998. 14750 [R2410] R. Glenn et al, "The NULL Encryption Algorithm and Its Use 14751 With IPsec", RFC 2410, Nov 1998. 14753 [R2412] H. Orman, "The OAKLEY Key Determination Protocol", RFC 2412, 14754 Nov 1998. 14756 [R2451] R. Pereira et al, "The ESP CBC-Mode Cipher Algorithms", RFC 14757 2451, Nov 1998. 14759 [R2459] R. Housley et al, " Internet X.509 Public Key Infrastructure 14760 Certificate and CRL Profile", RFC 2459, Jan 1999. 14762 [R2504] E. Guttman et al, "Users' Security Handbook", RFC 2504, Feb 14763 1999. 14765 [R2510] C. Adams et al, "Internet X.509 Public Key Infrastructure 14766 Certificate Management Protocols", RFC 2510, Mar 1999. 14768 [R2527] S. Chokhani et al, "Internet X.509 Public Key 14769 Infrastructure, Certificate Policy and Certification 14770 Practices Framework", RFC 2527, Mar 1999. 14772 [R2536] D. Eastlake, "DSA KEYs and SIGs in the Domain Name System 14773 (DNS)", RFC 2536, Mar 1999. 14775 [R2560] M. Myers et al, "X.509 Internet Public Key Infrastructure 14776 Online Certificate Status Protocol", RFC 2560, Jun 1999. 14778 [R2570] J. Case et al, "Introduction to Version 3 of the Internet- 14779 Standard Network Management Framework", RFC 2570, Apr 1999. 14781 [R2574] U. Blumenthal et al, "User-based Security Model (USM) for 14782 Version 3 of the Simple Network Management Protocol 14783 (SNMPv3)", RFC 2574, Apr 1999. 14785 [R2612] C. Adams et al, "The CAST-256 Encryption Algorithm", RFC 14786 2612, Jun 1999. 14788 [R2628] V. Smyslov, "Simple Cryptographic Program Interface", RFC 14789 2628, Jun 1999. 14791 [R2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 14792 2631, Jun 1999. 14794 [R2634] P. Hoffman, ed., "Enhanced Security Services for S/MIME", 14795 RFC 2634, Jun 1999. 14797 [R2635] S. Hambridge et al, "Don't Spew: A Set of Guidelines for 14798 Mass Unsolicited Mailings and Postings", RFC 2635, Jun 1999. 14800 [R2773] R. Housley et al, "Encryption using KEA and SKIPJACK", RFC 14801 2773, Feb 2000. 14803 [R2898] B. Kaliski, PKCS #5: Password-Based Cryptography 14804 Specification, Version 2.0", RFC 2898, Sep 2000. 14806 [R3198] A. Westerinen et al, "Terminology for Policy-Based 14807 Management", RFC 3198, Nov 2001. 14809 [R3547] M. Baugher et al, "Group Domain of Interpretation", RFC 14810 3547, Jul 2003. 14812 [R3739] S. Santesson et al, "Internet X.509 Public Key 14813 Infrastructure: Qualified Certificates Profile", RFC 3739, 14814 Mar 2004. 14816 [R3740] T. Hardjono et al, "The Multicast Group Security 14817 Architecture", RFC 3740, Mar 2004. 14819 [R3748] B. Aboda, et al, "Extensible Authentication Protocol (EAP)", 14820 RFC 3748, Jun 2004. 14822 [R3753] J. Manner et al, ed's., "Mobility Related Terminology", RFC 14823 3573, Jun 2004. 14825 [R3820] S. Tuecke et al, "Internet X.509 Public Key Infrastructure 14826 (PKI) Proxy Certificate Profile", RFC 3280, Jun 2004. 14828 [Raym] E. Raymond, ed., "The On-Line Hacker Jargon File", ver. 14829 4.0.0, 24 Jul 1996. (Also available as "The New Hacker's 14830 Dictionary", 2nd edition, MIT Press, Sep 1993, ISBN 0-262- 14831 18154-1. See: http://www.tuxedo.org/jargon/ for the latest 14832 version.) 14834 [Roge] H. Rogers, "An Overview of the Caneware Program", in 14835 "Proceedings of the 10th National Computer Security 14836 Conference", NIST and NCSC, Sep 1987. 14838 [Russ] D. Russell et al, Chapter 10 ("TEMPEST") in "Computer 14839 Security Basics", ISBN 0-937175-71-4, 1991. 14841 [SAML] Organization for the Advancement of Structured Information 14842 Standards (OASIS), "Assertions and Protocol for the OASIS 14843 Security Assertion Markup Language (SAML)", version 1.1, 2 14844 Sep 2003. 14846 [Sand] R. Sandhu et al, "Role-Based Access Control Models", in 14847 "IEEE Computer", vol. 29, no.2, Feb 1996, pp. 38-47. 14849 [Schn] B. Schneier, "Applied Cryptography Second Edition", John 14850 Wiley & Sons, Inc., New York, 1996. 14852 [SDNS3] U.S. DoD, NSA, "Secure Data Network Systems, Security 14853 Protocol 3 (SP3)", document SDN.301, Revision 1.5, 15 May 14854 1989. 14856 [SDNS4] ---, ---, "Security Protocol 4 (SP4)", document SDN.401, 14857 Revision 1.2, 12 Jul 1988. 14859 [SDNS7] ---, ---, "Secure data Network System, Message Security 14860 Protocol (MSP)", document SDN.701, Revision 4.0, 7 Jun 1996, 14861 with Corrections to Message Security Protocol, SDN.701, Rev 14862 4.0", 96-06-07, 30 Aug, 1996. 14864 [SET1] MasterCard and Visa, "SET Secure Electronic Transaction 14865 Specification, Book 1: Business Description", ver. 1.0, 31 14866 May 1997. 14868 [SET2] ---, "SET Secure Electronic Transaction Specification, Book 14869 2: Programmer's Guide", ver. 1.0, 31 May 1997. 14871 [SKEME] H. Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 14872 Mechanism for Internet", in "Proceedings of the 1996 14873 Symposium on Network and Distributed Systems Security". 14875 [SKIP] "SKIPJACK and KEA Algorithm Specifications", ver. 2.0, 22 14876 May 1998 (available from NIST Computer Security Resource 14877 Center). 14879 [SP12] NIST, "An Introduction to Computer Security: The NIST 14880 Handbook", Special Publication 800-12. 14882 [SP14] M. Swanson et al (NIST), "Generally Accepted Principles and 14883 Practices for Security Information Technology Systems", --- 14884 800-14, Sep 1996. 14886 [SP15] W. Burr et al (NIST), "Minimum Interoperability 14887 Specification for PKI Components (MISPC), Version 1", --- 14888 800-15, Sep 1997. 14890 [SP22] A. Rukhin et al (NIST), "A Statistical Test Suite for Random 14891 and Pseudorandom Number Generators for Cryptographic 14892 Applications", --- 800-15, 15 May 2001. 14894 [SP27] G. Stoneburner et al (NIST), "Engineering Principles for 14895 Information Technology Security (A Baseline for Achieving 14896 Security)", --- 800-27 Rev A, June 2004. 14898 [SP28] W. Jansen (NIST), "Guidelines on Active Content and Mobile 14899 Code", --- 800-28, Oct 2001. 14901 [SP30] G. Stoneburner et al (NIST), "Risk Management Guide for 14902 Information Technology Systems", --- 800-30, Oct 2001. 14904 [SP31] R. Bace et al (NIST), "Intrusion Detection Systems", --- 14905 800-31. 14907 [SP32] D. Kuhn (NIST), "Introduction to Public Key Technology and 14908 the Federal PKI Infrastructure ", --- 800-32, 26 Feb 2001. 14910 [SP33] G. Stoneburner (NIST), "Underlying Technical Models for 14911 Information Technology Security", --- 800-33, Dec 2001. 14913 [SP37] R. Ross et al (NIST), "Guide for the Security Certification 14914 and Accreditation of Federal Information Systems", --- 800- 14915 37, May 2004 14917 [SP41] J. Wack et al (NIST), "Guidelines on Firewalls and Firewall 14918 Policy", --- 800-41, Jan 2002. 14920 [SP42] J. Wack et al (NIST), "Guideline on Network Security 14921 Testing", --- 800-42, Oct 2003. 14923 [SP56] NIST, "Recommendations on Key Establishment Schemes", Draft 14924 2.0, --- 800-63, Jan 2003. 14926 [SP57] NIST, "Recommendation for Key Management", Part 1 "General 14927 Guideline" and Part 2 "Best Practices for Key Management 14928 Organization", --- 800-57, Jan 2003. 14930 [SP61] T. Grance et al (NIST), "Computer Security Incident Handling 14931 Guide", --- 800-57, Jan 2003. 14933 [SP63] W. Burr et al (NIST), "Electronic Authentication Guideline", 14934 --- 800-63, Jun 2004 14936 [SP67] W. Barker (NIST), "Recommendation for the Triple Data 14937 Encryption Algorithm (TDEA) Block Cipher", --- 800-67, May 14938 2004 14940 [Stei] J. Steiner et al, "Kerberos: An Authentication Service for 14941 Open Network Systems" in "Usenix Conference Proceedings", 14942 Feb 1988. 14944 [Weis] C. Weissman, "Blacker: Security for the DDN: Examples of A1 14945 Security Engineering Trades", in "Symposium on Security and 14946 Privacy", IEEE Computer Society Press, May 1992, pp. 286- 14947 292. 14949 [X400] International Telecommunications Union--Telecommunication 14950 Standardization Sector (formerly "CCITT"), Recommendation 14951 X.400, "Message Handling Services: Message Handling System 14952 and Service Overview". 14954 [X500] ---, Recommendation X.500, "Information Technology--Open 14955 Systems Interconnection--The Directory: Overview of 14956 Concepts, Models, and Services". (Equivalent to ISO 9594-1.) 14958 [X501] ---, Recommendation X.501, "Information Technology--Open 14959 Systems Interconnection--The Directory: Models". 14961 [X509] ---, Recommendation X.509, "Information Technology--Open 14962 Systems Interconnection--The Directory: Authentication 14963 Framework", COM 7-250-E Revision 1, 23 Feb 2001. (Equivalent 14964 to ISO 9594-8.) 14966 [X519] ---, Recommendation X.519, "Information Technology--Open 14967 Systems Interconnection--The Directory: Protocol 14968 Specifications". 14970 [X520] ---, Recommendation X.520, "Information Technology--Open 14971 Systems Interconnection--The Directory: Selected Attribute 14972 Types". 14974 [X680] ---, Recommendation X.680, "Information Technology--Abstract 14975 Syntax Notation One (ASN.1)--Specification of Basic 14976 Notation", 15 Nov 1994. (Equivalent to ISO/IEC 8824-1.) 14978 [X690] ---, Recommendation X.690, "Information Technology--ASN.1 14979 Encoding Rules--Specification of Basic Encoding Rules (BER), 14980 Canonical Encoding Rules (CER) and Distinguished Encoding 14981 Rules (DER)", 15 Nov 1994. (Equivalent to ISO/IEC 8825-1.) 14983 6. Security Considerations 14985 This document mainly defines security terms and recommends how to use 14986 them. It also provides limited tutorial information about security 14987 aspects of Internet protocols, but it not describe in detail the 14988 vulnerabilities of or threats to specific protocols and does not 14989 definitively describe mechanisms that protect specific protocols. 14991 7. Acknowledgments 14993 Funding for the RFC Editor function is currently provided by the 14994 Internet Society. 14996 George Huff had a good idea! [Huff] 14998 8. Author's Address 15000 Please address all comments to: 15002 Robert W. Shirey BBN Technologies 15003 E-mail: rshirey@bbn.com Suite 400, Mail Stop 30/6B1 15004 1300 Seventeenth Street North 15005 Arlington, VA 22209-3801 USA 15007 9. Full Copyright Statement 15009 Copyright (C) The Internet Society (2004). This document is subject 15010 to the rights, licenses and restrictions contained in BCP 78, and 15011 except as set forth therein, the authors retain all their rights. 15013 This document and the information contained herein are provided on an 15014 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE IS SPONSORED 15015 BY, THE INTERNET SOCIETY, AND THE INTERNET ENGINEERING TASK FORCE 15016 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 15017 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 15018 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 15019 OR FITNESS FOR A PARTICULAR PURPOSE. 15021 Expiration Date: 20 February 2004.