| < draft-shirey-secgloss-v2-04.txt | draft-shirey-secgloss-v2-05.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT R. W. Shirey | INTERNET-DRAFT R. W. Shirey | |||
| Obsoletes: RFC 2828, FYI 36 BBN Technologies | Obsoletes: RFC 2828, FYI 36 BBN Technologies Corp. | |||
| Expiration Date: 20 September 2006 20 March 2006 | Expiration Date: 22 February 2007 22 August 2006 | |||
| Internet Security Glossary, Version 2 | Internet Security Glossary, Version 2 | |||
| <draft-shirey-secgloss-v2-04.txt> | <draft-shirey-secgloss-v2-05.txt> | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| This document and the information contained herein are provided on an | ||||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
| ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
| INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
| This document may not be modified, and derivative works of it may | This document may not be modified, and derivative works of it may | |||
| not be created, except to publish it as an RFC and to translate it | not be created, except to publish it as an RFC and to translate it | |||
| into languages other than English. | into languages other than English. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that other | |||
| groups may also distribute working documents as Internet-Drafts. | groups may also distribute working documents as Internet-Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| skipping to change at page 2, line 5 ¶ | skipping to change at page 1, line 50 ¶ | |||
| Abstract | Abstract | |||
| This Glossary provides definitions, abbreviations, and explanations | This Glossary provides definitions, abbreviations, and explanations | |||
| of terminology for information system security. The 297 pages of | of terminology for information system security. The 297 pages of | |||
| entries offer recommendations to improve the clarity of Internet | entries offer recommendations to improve the clarity of Internet | |||
| Standards documents (ISDs) and to make them more easily understood by | Standards documents (ISDs) and to make them more easily understood by | |||
| international readers. The recommendations follow the principles that | international readers. The recommendations follow the principles that | |||
| ISDs should (a) use the same term or definition whenever the same | ISDs should (a) use the same term or definition whenever the same | |||
| concept is mentioned; (b) use terms in their plainest, dictionary | concept is mentioned; (b) use terms in their plainest, dictionary | |||
| sense; (c) use terms that are already well-established in open | sense; (c) use terms that are already well-established in open | |||
| publications; and (d) avoid terms that are proprietary, favor a | publications; and (d) avoid terms that either favor a particular | |||
| particular vendor, or create a bias toward a particular technology or | vendor or favor a particular technology or mechanism over other, | |||
| mechanism versus other, competing techniques that already exist or | competing techniques that already exist or could be developed. | |||
| might be developed. | ||||
| Table of Contents | Table of Contents | |||
| Section Page | Section Page | |||
| ------- ---- | ------- ---- | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Format of Entries . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Format of Entries . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.1 Order of Entries . . . . . . . . . . . . . . . . . . . . . 4 | 2.1 Order of Entries . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.2 Capitalization and Abbreviation . . . . . . . . . . . . . 4 | 2.2 Capitalization and Abbreviation . . . . . . . . . . . . . 4 | |||
| 2.3 Support for Automated Searching . . . . . . . . . . . . . 5 | 2.3 Support for Automated Searching . . . . . . . . . . . . . 5 | |||
| skipping to change at page 2, line 31 ¶ | skipping to change at page 2, line 26 ¶ | |||
| 2.6 Cross-References . . . . . . . . . . . . . . . . . . . . . 5 | 2.6 Cross-References . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.7 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.7 Trademarks . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 2.8 The New Punctuation . . . . . . . . . . . . . . . . . . . 6 | 2.8 The New Punctuation . . . . . . . . . . . . . . . . . . . 6 | |||
| 3. Types of Entries . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Types of Entries . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3.1 Type "I": Recommended Definitions of Internet Origin . . . 7 | 3.1 Type "I": Recommended Definitions of Internet Origin . . . 7 | |||
| 3.2 Type "N": Recommended Definitions of Non-Internet Origin . 7 | 3.2 Type "N": Recommended Definitions of Non-Internet Origin . 7 | |||
| 3.3 Type "O": Other Terms and Definitions to be Noted . . . . 7 | 3.3 Type "O": Other Terms and Definitions to be Noted . . . . 7 | |||
| 3.4 Type "D": Deprecated Terms and Definitions . . . . . . . . 8 | 3.4 Type "D": Deprecated Terms and Definitions . . . . . . . . 8 | |||
| 3.5 Definition Substitutions . . . . . . . . . . . . . . . . . 8 | 3.5 Definition Substitutions . . . . . . . . . . . . . . . . . 8 | |||
| 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 5. Informative References . . . . . . . . . . . . . . . . . . . . 306 | 5. Informative References . . . . . . . . . . . . . . . . . . . . 314 | |||
| 6. Security Considerations and IANA Considerations . . . . . . . 325 | 6. Security Considerations and IANA Considerations . . . . . . . 333 | |||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 325 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 333 | |||
| 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 325 | 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 333 | |||
| 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 325 | 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 333 | |||
| 1. Introduction | 1. Introduction | |||
| This Glossary is *not* an Internet Standard, and its recommendations | ||||
| represent only the opinions of its author. However, this Glossary | ||||
| provides reasons for its recommendations -- especially for the SHOULD | ||||
| NOTs -- so that readers can judge for themselves what to do. | ||||
| This Glossary provides an internally consistent and self-contained | This Glossary provides an internally consistent and self-contained | |||
| set of terms, abbreviations, and definitions -- supported by | set of terms, abbreviations, and definitions -- supported by | |||
| explanations, recommendations, and references -- for terminology that | explanations, recommendations, and references -- for terminology that | |||
| concerns information system security. The intent of this Glossary is | concerns information system security. The intent of this Glossary is | |||
| to improve the comprehensibility of Internet Standards documents | to improve the comprehensibility of Internet Standards documents | |||
| (ISDs) -- i.e., RFCs, Internet-Drafts, and other material produced as | (ISDs) -- i.e., RFCs, Internet-Drafts, and other material produced as | |||
| part of the Internet Standards Process (RFC 2026) -- and other | part of the Internet Standards Process (RFC 2026) -- and other | |||
| Internet-related discourse. A few non-security, networking terms are | Internet-related discourse. A few non-security, networking terms are | |||
| included to make the Glossary self-contained, but more complete | included to make the Glossary self-contained, but more complete | |||
| glossaries of such terms are available elsewhere [A1523, F1037, | glossaries of such terms are available elsewhere [A1523, F1037, | |||
| skipping to change at page 4, line 4 ¶ | skipping to change at page 4, line 9 ¶ | |||
| protocols. Using terms in their plainest, dictionary sense (when | protocols. Using terms in their plainest, dictionary sense (when | |||
| appropriate) helps to ensure international understanding. ISDs | appropriate) helps to ensure international understanding. ISDs | |||
| need to avoid using private, newly invented terms in place of | need to avoid using private, newly invented terms in place of | |||
| generally accepted terms from open publications. ISDs need to | generally accepted terms from open publications. ISDs need to | |||
| avoid substituting new definitions that conflict with established | avoid substituting new definitions that conflict with established | |||
| ones. ISDs need to avoid using "cute" synonyms (e.g., "Green | ones. ISDs need to avoid using "cute" synonyms (e.g., "Green | |||
| Book"), because no matter how popular a nickname may be in one | Book"), because no matter how popular a nickname may be in one | |||
| community, it is likely to cause confusion in another. | community, it is likely to cause confusion in another. | |||
| o Openness, Fairness, and Timeliness | o Openness, Fairness, and Timeliness | |||
| ISDs need to avoid terms that are proprietary or otherwise favor a | ||||
| particular vendor, or that create a bias toward a particular | ISDs need to avoid using proprietary and trademarked terms for | |||
| security technology or mechanism over other, competing techniques | purposes other than referring to those particular systems. ISDs | |||
| that already exist or might be developed in the future. The set of | also need to avoid terms that either favor a particular vendor or | |||
| terminology used across the set of ISDs needs to be flexible and | favor a particular security technology or mechanism over other, | |||
| adaptable as the state of Internet security art evolves. | competing techniques that already exist or might be developed in | |||
| the future. The set of terminology used across the set of ISDs | ||||
| needs to be flexible and adaptable as the state of Internet | ||||
| security art evolves. | ||||
| In support of those goals, this Glossary provides guidance by marking | In support of those goals, this Glossary provides guidance by marking | |||
| terms and definitions as being either endorsed or deprecated for use | terms and definitions as being either endorsed or deprecated for use | |||
| in ISDs. The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | in ISDs. The key words "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", | |||
| and "OPTIONAL" are intended to be interpreted the same way as in an | and "OPTIONAL" are intended to be interpreted the same way as in an | |||
| Internet Standard (i.e., as specified in RFC 2119). Other glossaries | Internet Standard (i.e., as specified in RFC 2119). Other glossaries | |||
| (e.g., [Raym]) list additional terms that deal with Internet security | (e.g., [Raym]) list additional terms that deal with Internet security | |||
| but have not been included in this Glossary because they are not | but have not been included in this Glossary because they are not | |||
| appropriate for ISDs. | appropriate for ISDs. | |||
| This Glossary is not an Internet Standard, and its guidance | ||||
| represents only the recommendations of this author. However, this | ||||
| Glossary provides reasons for its recommendations -- especially for | ||||
| the SHOULD NOTs -- so that readers can judge for themselves whether | ||||
| to follow the guidance. | ||||
| 2. Format of Entries | 2. Format of Entries | |||
| Section 4 presents Glossary entries in the following manner: | Section 4 presents Glossary entries in the following manner: | |||
| 2.1 Order of Entries | 2.1 Order of Entries | |||
| Entries are sorted in lexicographic order, without regard to | Entries are sorted in lexicographic order, without regard to | |||
| capitalization. Numeric digits are treated as preceding alphabetic | capitalization. Numeric digits are treated as preceding alphabetic | |||
| characters, and special characters are treated as preceding | characters, and special characters are treated as preceding | |||
| digits. Blanks are treated as preceding non-blank characters, | digits. Blanks are treated as preceding non-blank characters, | |||
| skipping to change at page 11, line 45 ¶ | skipping to change at page 11, line 45 ¶ | |||
| identity-based security policy, mandatory access control, rule- | identity-based security policy, mandatory access control, rule- | |||
| based security policy.) | based security policy.) | |||
| Tutorial: This service includes protecting against use of a | Tutorial: This service includes protecting against use of a | |||
| resource in an unauthorized manner by an entity (i.e., a | resource in an unauthorized manner by an entity (i.e., a | |||
| principal) that is authorized to use the resource in some other | principal) that is authorized to use the resource in some other | |||
| manner. (See: insider.) The two basic mechanisms for implementing | manner. (See: insider.) The two basic mechanisms for implementing | |||
| this service are ACLs and tickets. | this service are ACLs and tickets. | |||
| $ access level | $ access level | |||
| (D) Synonym for the hierarchical "classification level" in a | 1. (D) Synonym for the hierarchical "classification level" in a | |||
| security level. [C4009] (See: security level.) | security level. [C4009] (See: security level.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | 2. (D) Synonym for "clearance level". | |||
| in a potentially misleading way. Access control may be based on | ||||
| attributes other than classification level. | Deprecated Definitions: ISDs SHOULD NOT use this term with these | |||
| definitions because they duplicate the meaning of more specific | ||||
| terms. Any ISD that uses this term SHOULD provide a specific | ||||
| definition for it because access control may be based on many | ||||
| attributes other than classification level and clearance level. | ||||
| $ access list | $ access list | |||
| (I) /physical security/ Roster of persons who are authorized to | (I) /physical security/ Roster of persons who are authorized to | |||
| enter a controlled area. (Compare: access control list.) | enter a controlled area. (Compare: access control list.) | |||
| $ access mode | $ access mode | |||
| (I) A distinct type of data processing operation (e.g., read, | (I) A distinct type of data processing operation (e.g., read, | |||
| write, append, or execute, or a combination of operations) that a | write, append, or execute, or a combination of operations) that a | |||
| subject can potentially perform on an object in an information | subject can potentially perform on an object in an information | |||
| system. [Huff] | system. [Huff] (See: read, write.) | |||
| $ access policy | $ access policy | |||
| (I) A kind of "security policy". (See: access, access control.) | (I) A kind of "security policy". (See: access, access control.) | |||
| $ access profile | $ access profile | |||
| (O) Synonym for "capability list". | (O) Synonym for "capability list". | |||
| Usage: ISDs that use this term SHOULD state a definition for it | Usage: ISDs that use this term SHOULD state a definition for it | |||
| because the definition is not widely known. | because the definition is not widely known. | |||
| skipping to change at page 15, line 12 ¶ | skipping to change at page 15, line 16 ¶ | |||
| or 256 bits to operate on a 128-bit block, and (b) states policy | or 256 bits to operate on a 128-bit block, and (b) states policy | |||
| for using that algorithm to protect unclassified, sensitive data. | for using that algorithm to protect unclassified, sensitive data. | |||
| Tutorial: Rijndael was designed to handle additional block sizes | Tutorial: Rijndael was designed to handle additional block sizes | |||
| and key lengths that were not adopted in the AES. Rijndael was | and key lengths that were not adopted in the AES. Rijndael was | |||
| selected by NIST through a public competition that was held to | selected by NIST through a public competition that was held to | |||
| find a successor to the DEA; the other finalists were MARS, RC6, | find a successor to the DEA; the other finalists were MARS, RC6, | |||
| Serpent, and Twofish. | Serpent, and Twofish. | |||
| $ adversary | $ adversary | |||
| 1. (I) An entity that attacks a system. (Compare: intruder.) | 1. (I) An entity that attacks a system. (Compare: cracker, | |||
| intruder, hacker.) | ||||
| 2. (I) An entity that is a threat to a system. | 2. (I) An entity that is a threat to a system. | |||
| $ AES | $ AES | |||
| (N) See: Advanced Encryption Standard. | (N) See: Advanced Encryption Standard. | |||
| $ Affirm | $ Affirm | |||
| (O) A formal methodology, language, and integrated set of software | (O) A formal methodology, language, and integrated set of software | |||
| tools developed at the University of Southern California's | tools developed at the University of Southern California's | |||
| Information Sciences Institute for specifying, coding, and | Information Sciences Institute for specifying, coding, and | |||
| skipping to change at page 21, line 4 ¶ | skipping to change at page 21, line 8 ¶ | |||
| encrypts the data with a public key provided by Bob. Only Bob | encrypts the data with a public key provided by Bob. Only Bob | |||
| has the matching private key that is needed to decrypt the | has the matching private key that is needed to decrypt the | |||
| data. (Compare: seal.) | data. (Compare: seal.) | |||
| - In an asymmetric digital signature algorithm (e.g., "DSA"), | - In an asymmetric digital signature algorithm (e.g., "DSA"), | |||
| when Alice wants to ensure data integrity or provide | when Alice wants to ensure data integrity or provide | |||
| authentication for data she sends to Bob, she uses her private | authentication for data she sends to Bob, she uses her private | |||
| key to sign the data (i.e., create a digital signature based on | key to sign the data (i.e., create a digital signature based on | |||
| the data). To verify the signature, Bob uses the matching | the data). To verify the signature, Bob uses the matching | |||
| public key that Alice has provided. | public key that Alice has provided. | |||
| - In an asymmetric key-agreement algorithm (e.g., "Diffie- | - In an asymmetric key-agreement algorithm (e.g., "Diffie- | |||
| Hellman"), Alice and Bob each send their own public key to the | Hellman-Merkle"), Alice and Bob each send their own public key | |||
| other party. Then each uses their own private key and the | to the other party. Then each uses their own private key and | |||
| other's public key to compute the new key value. | the other's public key to compute the new key value. | |||
| $ asymmetric key | $ asymmetric key | |||
| (I) A cryptographic key that is used in an asymmetric | (I) A cryptographic key that is used in an asymmetric | |||
| cryptographic algorithm. (See: asymmetric cryptography, private | cryptographic algorithm. (See: asymmetric cryptography, private | |||
| key, public key.) | key, public key.) | |||
| $ ATIS | $ ATIS | |||
| (N) See: "Alliance for Telecommunications Industry Solutions" | (N) See: "Alliance for Telecommunications Industry Solutions" | |||
| under "ANSI". | under "ANSI". | |||
| skipping to change at page 29, line 41 ¶ | skipping to change at page 29, line 42 ¶ | |||
| $ backup | $ backup | |||
| (I) /noun or adjective/ Refers to alternate means of performing | (I) /noun or adjective/ Refers to alternate means of performing | |||
| system functions despite loss of system resources. (See: | system functions despite loss of system resources. (See: | |||
| contingency plan). | contingency plan). | |||
| Example: A reserve copy of data, preferably one that is stored | Example: A reserve copy of data, preferably one that is stored | |||
| separately from the original, for use if the original becomes lost | separately from the original, for use if the original becomes lost | |||
| or damaged. (Compare: archive.) | or damaged. (Compare: archive.) | |||
| $ bagbiter | $ bagbiter | |||
| (D) /slang/ "An entity, such as a program or a computer, that | (D) /slang/ "An entity, such as a program or a computer, that | |||
| fails to work or that works in a remarkably clumsy manner. A | fails to work or that works in a remarkably clumsy manner. A | |||
| person who has caused some trouble, inadvertently or otherwise, | person who has caused some trouble, inadvertently or otherwise, | |||
| typically by failing to program the computer properly." [NCSSG] | typically by failing to program the computer properly." [NCSSG] | |||
| (See: flaw.) | (See: flaw.) | |||
| Deprecated Term: It is likely that other cultures use different | Deprecated Term: It is likely that other cultures use different | |||
| metaphors for these concepts. Therefore, to avoid international | metaphors for these concepts. Therefore, to avoid international | |||
| misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated | misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated | |||
| Usage under "Green Book.") | Usage under "Green Book.") | |||
| skipping to change at page 33, line 38 ¶ | skipping to change at page 33, line 39 ¶ | |||
| result) much faster than a brute force attack can; and a clever | result) much faster than a brute force attack can; and a clever | |||
| adversary can use such a capability to create considerable | adversary can use such a capability to create considerable | |||
| mischief. However, no birthday attack can enable an adversary to | mischief. However, no birthday attack can enable an adversary to | |||
| decrypt a given cipher text (or find a hash input that results in | decrypt a given cipher text (or find a hash input that results in | |||
| a given hash result) any faster than a brute force attack can. | a given hash result) any faster than a brute force attack can. | |||
| $ bit | $ bit | |||
| (I) A contraction of the term "binary digit"; the smallest unit of | (I) A contraction of the term "binary digit"; the smallest unit of | |||
| information storage, which has two possible states or values. The | information storage, which has two possible states or values. The | |||
| values usually are represented by the symbols "0" (zero) and "1" | values usually are represented by the symbols "0" (zero) and "1" | |||
| (one). (See: block, byte, word.) | (one). (See: block, byte, nibble, word.) | |||
| $ bit string | $ bit string | |||
| (I) A sequence of bits, each of which is either "0" or "1". | (I) A sequence of bits, each of which is either "0" or "1". | |||
| $ BLACK | $ BLACK | |||
| 1. (N) Designation for data that consists only of cipher text, and | 1. (N) Designation for data that consists only of cipher text, and | |||
| for information system equipment items or facilities that handle | for information system equipment items or facilities that handle | |||
| only cipher text. Example: "BLACK key".(See: color change, | only cipher text. Example: "BLACK key".(See: color change, | |||
| RED/BLACK separation. Compare: RED.) | RED/BLACK separation. Compare: RED.) | |||
| 2. (O) /U.S. Government/ "Designation applied to information | 2. (O) /U.S. Government/ "Designation applied to information | |||
| systems, and to associated areas, circuits, components, and | systems, and to associated areas, circuits, components, and | |||
| equipment, in which national security information is encrypted or | equipment, in which national security information is encrypted or | |||
| is not processed." [C4009] | is not processed." [C4009] | |||
| 3. (D) Any data that can be disclosed without harm. | ||||
| Deprecated Definition: ISDs SHOULD NOT use the term with | ||||
| definition 3 because the definition is ambiguous with regard to | ||||
| whether the data is protected or not. | ||||
| $ BLACK/Crypto/RED (BCR) | $ BLACK/Crypto/RED (BCR) | |||
| (N) An experimental, end-to-end, network packet encryption system | (N) An experimental, end-to-end, network packet encryption system | |||
| developed in a working prototype form by BBN and the Collins Radio | developed in a working prototype form by BBN and the Collins Radio | |||
| division of Rockwell Corporation in the 1975-1980 time frame for | division of Rockwell Corporation in the 1975-1980 time frame for | |||
| the U.S. DoD. BCR was the first network security system to support | the U.S. DoD. BCR was the first network security system to support | |||
| TCP/IP traffic, and it incorporated the first DES chips that were | TCP/IP traffic, and it incorporated the first DES chips that were | |||
| validated by the U.S. National Bureau of Standards (now called | validated by the U.S. National Bureau of Standards (now called | |||
| NIST). BCR also was the first to use a KDC and an ACC to manage | NIST). BCR also was the first to use a KDC and an ACC to manage | |||
| connections. | connections. | |||
| skipping to change at page 35, line 32 ¶ | skipping to change at page 35, line 40 ¶ | |||
| $ block cipher | $ block cipher | |||
| (I) An encryption algorithm that breaks plain text into fixed-size | (I) An encryption algorithm that breaks plain text into fixed-size | |||
| segments and uses the same key to transform each plaintext segment | segments and uses the same key to transform each plaintext segment | |||
| into a fixed-size segment of cipher text. Examples: AES, Blowfish, | into a fixed-size segment of cipher text. Examples: AES, Blowfish, | |||
| DEA, IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream | DEA, IDEA, RC2, and SKIPJACK. (See: block, mode. Compare: stream | |||
| cipher.) | cipher.) | |||
| Tutorial: A block cipher can be adapted to have a different | Tutorial: A block cipher can be adapted to have a different | |||
| external interface, such as that of a stream cipher, by using a | external interface, such as that of a stream cipher, by using a | |||
| mode of cryptographic operation to package the basic algorithm. | mode of cryptographic operation to package the basic algorithm. | |||
| (See: CBC, CFB, DEA, ECB, OFB.) | (See: CBC, CCM, CFB, CMAC, CTR, DEA, ECB, OFB.) | |||
| $ Blowfish | $ Blowfish | |||
| (N) A symmetric block cipher with variable-length key (32 to 448 | (N) A symmetric block cipher with variable-length key (32 to 448 | |||
| bits) designed in 1993 by Bruce Schneier as an unpatented, | bits) designed in 1993 by Bruce Schneier as an unpatented, | |||
| license-free, royalty-free replacement for DES or IDEA. [Schn] | license-free, royalty-free replacement for DES or IDEA. [Schn] | |||
| (See: Twofish.) | (See: Twofish.) | |||
| $ brain-damaged | $ brain-damaged | |||
| (D) /slang/ "Obviously wrong: extremely poorly designed. Calling | (D) /slang/ "Obviously wrong: extremely poorly designed. Calling | |||
| something brain-damaged is very extreme. The word implies that the | something brain-damaged is very extreme. The word implies that the | |||
| skipping to change at page 36, line 25 ¶ | skipping to change at page 36, line 33 ¶ | |||
| $ brand CRL identifier (BCI) | $ brand CRL identifier (BCI) | |||
| (O) /SET/ A digitally signed list, issued by a BCA, of the names | (O) /SET/ A digitally signed list, issued by a BCA, of the names | |||
| of CAs for which CRLs need to be processed when verifying | of CAs for which CRLs need to be processed when verifying | |||
| signatures in SET messages. [SET2] | signatures in SET messages. [SET2] | |||
| $ break | $ break | |||
| (I) /cryptography/ To successfully perform cryptanalysis and thus | (I) /cryptography/ To successfully perform cryptanalysis and thus | |||
| succeed in decrypting data or performing some other cryptographic | succeed in decrypting data or performing some other cryptographic | |||
| function, without initially having knowledge of the key that the | function, without initially having knowledge of the key that the | |||
| function requires. (See: penetrate, strength.) | function requires. (See: penetrate, strength, work factor.) | |||
| Usage: This term applies to encrypted data or, more generally, to | Usage: This term applies to encrypted data or, more generally, to | |||
| a cryptographic algorithm or cryptographic system. | a cryptographic algorithm or cryptographic system. Also, while the | |||
| most common use is to refer to completely breaking an algorithm, | ||||
| the term is also used when a method is found that substantially | ||||
| reduces the work factor. | ||||
| $ Brewer-Nash model | $ Brewer-Nash model | |||
| (N) A security model [BN89] to enforce the Chinese wall policy. | (N) A security model [BN89] to enforce the Chinese wall policy. | |||
| (Compare: Bell-LaPadula model, Clark-Wilson model.) | (Compare: Bell-LaPadula model, Clark-Wilson model.) | |||
| Tutorial: All proprietary information in the set of commercial | Tutorial: All proprietary information in the set of commercial | |||
| firms F(1), F(2), ..., F(N) is categorized into mutually exclusive | firms F(1), F(2), ..., F(N) is categorized into mutually exclusive | |||
| conflict-of-interest classes I(1), I(2), ..., I(M) that apply | conflict-of-interest classes I(1), I(2), ..., I(M) that apply | |||
| across all firms. Each firm belongs to exactly one class. The | across all firms. Each firm belongs to exactly one class. The | |||
| Brewer-Nash model has the following mandatory rules: | Brewer-Nash model has the following mandatory rules: | |||
| skipping to change at page 37, line 40 ¶ | skipping to change at page 37, line 48 ¶ | |||
| management systems. [BS7799] (See: ISO 17799.) | management systems. [BS7799] (See: ISO 17799.) | |||
| $ browser | $ browser | |||
| (I) An client computer program that can retrieve and display | (I) An client computer program that can retrieve and display | |||
| information from servers on the World Wide Web. Examples: | information from servers on the World Wide Web. Examples: | |||
| Netscape's Navigator and Microsoft's Internet Explorer. | Netscape's Navigator and Microsoft's Internet Explorer. | |||
| $ brute force | $ brute force | |||
| (I) A cryptanalysis technique or other kind of attack method | (I) A cryptanalysis technique or other kind of attack method | |||
| involving an exhaustive procedure that tries a large number of | involving an exhaustive procedure that tries a large number of | |||
| possible solutions to the problem, one-by-one. (See: impossible, | possible solutions to the problem. (See: impossible, strength, | |||
| strength, work factor.) | work factor.) | |||
| Tutorial: In some cases, brute force involves trying all of the | Tutorial: In some cases, brute force involves trying all of the | |||
| possibilities. For example, for cipher text where the analyst | possibilities. For example, for cipher text where the analyst | |||
| already knows the decryption algorithm, a brute force technique | already knows the decryption algorithm, a brute force technique | |||
| for finding matching plain text is to decrypt the message with | for finding matching plain text is to decrypt the message with | |||
| every possible key. In other cases, brute force involves trying a | every possible key. In other cases, brute force involves trying a | |||
| large number of possibilities but substantially fewer than all of | large number of possibilities but substantially fewer than all of | |||
| them. For example, given a hash function that produces a N-bit | them. For example, given a hash function that produces a N-bit | |||
| hash result, the probability is greater than 1/2 that the analyst | hash result, the probability is greater than 1/2 that the analyst | |||
| will find two inputs that have the same hash result after trying | will find two inputs that have the same hash result after trying | |||
| skipping to change at page 38, line 28 ¶ | skipping to change at page 38, line 36 ¶ | |||
| that each operate under a different security policy. | that each operate under a different security policy. | |||
| Tutorial: To connect a private network to the Internet or some | Tutorial: To connect a private network to the Internet or some | |||
| other relatively public network, one could construct a small, | other relatively public network, one could construct a small, | |||
| separate, isolated LAN and connect it to both the private network | separate, isolated LAN and connect it to both the private network | |||
| and the public network; one or both of the connections would | and the public network; one or both of the connections would | |||
| implement a firewall to limit the traffic that could pass through | implement a firewall to limit the traffic that could pass through | |||
| the buffer zone. | the buffer zone. | |||
| $ bulk encryption | $ bulk encryption | |||
| (N) "Simultaneous encryption of all channels of a multichannel | 1. (I) Encryption of multiple channels by aggregating them into a | |||
| single transfer path and then encrypting that path. (See: | ||||
| channel.) | ||||
| 2. (O) "Simultaneous encryption of all channels of a multichannel | ||||
| telecommunications link." [C4009] (Compare: bulk keying material.) | telecommunications link." [C4009] (Compare: bulk keying material.) | |||
| Usage: The use of "simultaneous" in definition 2 could be | ||||
| interpreted to mean that multiple channels are encrypted | ||||
| separately but at the same time. However, the common meaning of | ||||
| the term is that multiple data flows are combined into a single | ||||
| stream and then that stream is encrypted as a whole. | ||||
| $ bulk key | $ bulk key | |||
| (D) In a few published descriptions of hybrid encryption for SSH, | (D) In a few published descriptions of hybrid encryption for SSH, | |||
| Windows 2000, and other applications, this term refers to a | Windows 2000, and other applications, this term refers to a | |||
| symmetric key that (a) is used to encrypt a relatively large | symmetric key that (a) is used to encrypt a relatively large | |||
| amount of data and (b) is itself encrypted with a public key. | amount of data and (b) is itself encrypted with a public key. | |||
| (Compare: bulk keying material.) | (Compare: bulk keying material.) | |||
| Example: To send a large file to Bob, Alice (a) generates a | Example: To send a large file to Bob, Alice (a) generates a | |||
| symmetric key and uses it to encrypt the file (i.e., encrypt the | symmetric key and uses it to encrypt the file (i.e., encrypt the | |||
| bulk of the information that is to be sent) and then (b) encrypts | bulk of the information that is to be sent) and then (b) encrypts | |||
| that symmetric key (the "bulk key") with Bob's public key. | that symmetric key (the "bulk key") with Bob's public key. | |||
| Deprecated Term: ISDs SHOULD NOT use this term or definition; they | Deprecated Term: ISDs SHOULD NOT use this term or definition; they | |||
| are not well-established and could be confused with the | are not well-established and could be confused with the | |||
| established term "bulk keying material". Instead, use "symmetric | established term "bulk keying material". Instead, use "symmetric | |||
| key" and carefully explain how the key is applied. | key" and carefully explain how the key is applied. | |||
| skipping to change at page 40, line 39 ¶ | skipping to change at page 41, line 6 ¶ | |||
| could be issued a certificate with "keyUsage" set to other values, | could be issued a certificate with "keyUsage" set to other values, | |||
| either with or without "keyCertSign". | either with or without "keyCertSign". | |||
| $ CA domain | $ CA domain | |||
| (N) /PKI/ A security policy domain that "consists of a CA and its | (N) /PKI/ A security policy domain that "consists of a CA and its | |||
| subjects [i.e., the entities named in the certificates issued by | subjects [i.e., the entities named in the certificates issued by | |||
| the CA]. Sometimes referred to as a PKI domain." [PAG] (See: | the CA]. Sometimes referred to as a PKI domain." [PAG] (See: | |||
| domain.) | domain.) | |||
| $ Caesar cipher | $ Caesar cipher | |||
| (I) A cipher that, given an alphabet of N characters, A(1), A(2), | (I) A cipher that is defined for an alphabet of N characters, | |||
| character A(i) by A(i+K, mod N) for some 0<K<N+1. [Schn] | A(1), A(2), ..., A(N), and creates cipher text by replacing each | |||
| plaintext character A(i) by A(i+K, mod N) for some 0<K<N+1. [Schn] | ||||
| Examples: (a) During the Gallic wars, Julius Caesar used a cipher | Examples: (a) During the Gallic wars, Julius Caesar used a cipher | |||
| with K=3. In a Caesar cipher with K=3 for the English alphabet, A | with K=3. In a Caesar cipher with K=3 for the English alphabet, A | |||
| is replaced by D, B by E, C by F, ..., W by Z, X by A, Y by B, Z | is replaced by D, B by E, C by F, ..., W by Z, X by A, Y by B, Z | |||
| by C. (b) UNIX systems sometimes include "ROT13" software that | by C. (b) UNIX systems sometimes include "ROT13" software that | |||
| implements a Caesar cipher with K=13 (i.e., ROTate by 13). | implements a Caesar cipher with K=13 (i.e., ROTate by 13). | |||
| $ call back | $ call back | |||
| (I) An authentication technique for terminals that remotely access | (I) An authentication technique for terminals that remotely access | |||
| a computer via telephone lines; the host system disconnects the | a computer via telephone lines; the host system disconnects the | |||
| skipping to change at page 43, line 38 ¶ | skipping to change at page 44, line 6 ¶ | |||
| $ CAST | $ CAST | |||
| (N) A design procedure for symmetric encryption algorithms, and a | (N) A design procedure for symmetric encryption algorithms, and a | |||
| resulting family of algorithms, invented by Carlisle Adams (C.A.) | resulting family of algorithms, invented by Carlisle Adams (C.A.) | |||
| and Stafford Tavares (S.T.). [R2144, R2612] | and Stafford Tavares (S.T.). [R2144, R2612] | |||
| $ category | $ category | |||
| (I) A grouping of sensitive information items to which a non- | (I) A grouping of sensitive information items to which a non- | |||
| hierarchical restrictive security label is applied to increase | hierarchical restrictive security label is applied to increase | |||
| protection of the data. (See: formal access approval. Compare: | protection of the data. (See: formal access approval. Compare: | |||
| category, classification.) | compartment, classification.) | |||
| $ CAW | $ CAW | |||
| (N) See: certification authority workstation. | (N) See: certification authority workstation. | |||
| $ CBC | $ CBC | |||
| (N) See: cipher block chaining. | (N) See: cipher block chaining. | |||
| $ CCA | $ CCA | |||
| (O) See: cardholder certification authority. | (O) See: cardholder certification authority. | |||
| $ CCEP | $ CCEP | |||
| (O) See: Commercial COMSEC Endorsement Program. | (O) See: Commercial COMSEC Endorsement Program. | |||
| $ CCI | $ CCI | |||
| (O) See: Controlled Cryptographic Item. | (O) See: Controlled Cryptographic Item. | |||
| $ CCITT | $ CCITT | |||
| (N) Acronym for French translation of International Telephone and | (N) Acronym for French translation of International Telephone and | |||
| Telegraph Consultative Committee. Now renamed ITU-T. | Telegraph Consultative Committee. Now renamed ITU-T. | |||
| $ CCM | ||||
| (N) See: Counter with Cipher Block Chaining-Message Authentication | ||||
| Code. | ||||
| $ CERIAS | $ CERIAS | |||
| (O) Purdue University's Center for Education and Research in | (O) Purdue University's Center for Education and Research in | |||
| Information Assurance and Security, which includes faculty from | Information Assurance and Security, which includes faculty from | |||
| multiple schools and departments and takes a multidisciplinary | multiple schools and departments and takes a multidisciplinary | |||
| approach to security problems ranging from technical to ethical, | approach to security problems ranging from technical to ethical, | |||
| legal, educational, communicational, linguistic, and economic. | legal, educational, communicational, linguistic, and economic. | |||
| $ CERT | $ CERT | |||
| (I) See: computer emergency response team. | (I) See: computer emergency response team. | |||
| skipping to change at page 44, line 40 ¶ | skipping to change at page 45, line 10 ¶ | |||
| integrated with an application for the purpose of routing, | integrated with an application for the purpose of routing, | |||
| replying to, and otherwise managing and meditating certificate | replying to, and otherwise managing and meditating certificate | |||
| validation requests between that application and the CAs in the | validation requests between that application and the CAs in the | |||
| ACES PKI. | ACES PKI. | |||
| $ certificate authority | $ certificate authority | |||
| (D) Synonym for "certification authority". | (D) Synonym for "certification authority". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it suggests | Deprecated Term: ISDs SHOULD NOT use this term; it suggests | |||
| careless use of the term "certification authority", which is | careless use of the term "certification authority", which is | |||
| standardized by X.509. A person who uses this term probably has | preferred in PKI standards (e.g., [X509, R3280]). | |||
| never read the basic technical standards for PKI [X509, R3280]. | ||||
| $ certificate chain | $ certificate chain | |||
| (D) Synonym for "certification path". (See: trust chain.) | (D) Synonym for "certification path". (See: trust chain.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it duplicates the | Deprecated Term: ISDs SHOULD NOT use this term; it duplicates the | |||
| meaning of a standardized term. Instead, use "certification path". | meaning of a standardized term. Instead, use "certification path". | |||
| $ certificate chain validation | $ certificate chain validation | |||
| (D) Synonym for "certificate validation" or "path validation". | (D) Synonym for "certificate validation" or "path validation". | |||
| skipping to change at page 45, line 12 ¶ | skipping to change at page 45, line 34 ¶ | |||
| validation", depending on what is meant. (See: validate vs. | validation", depending on what is meant. (See: validate vs. | |||
| verify.) | verify.) | |||
| $ certificate creation | $ certificate creation | |||
| (I) The act or process by which a CA sets the values of a digital | (I) The act or process by which a CA sets the values of a digital | |||
| certificate's data fields and signs it. (See: issue.) | certificate's data fields and signs it. (See: issue.) | |||
| $ certificate expiration | $ certificate expiration | |||
| (I) The event that occurs when a certificate ceases to be valid | (I) The event that occurs when a certificate ceases to be valid | |||
| because its assigned lifetime has been exceeded. (See: certificate | because its assigned lifetime has been exceeded. (See: certificate | |||
| revocation, validity period.) | revocation, expire.) | |||
| Tutorial: The assigned lifetime of an X.509 certificate is stated | ||||
| in the certificate itself. (See: validity period.) | ||||
| $ certificate extension | $ certificate extension | |||
| (I) See: extension. | (I) See: extension. | |||
| $ certificate holder | $ certificate holder | |||
| (D) Synonym for the "subject" of a digital certificate. (Compare: | (D) Synonym for the "subject" of a digital certificate. (Compare: | |||
| certificate owner, certificate user.) | certificate owner, certificate user.) | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for the subject of a digital certificate; the term is potentially | for the subject of a digital certificate; the term is potentially | |||
| skipping to change at page 46, line 9 ¶ | skipping to change at page 46, line 33 ¶ | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for the subject of a digital certificate; the term is potentially | for the subject of a digital certificate; the term is potentially | |||
| ambiguous. For example, the term could refer to a system entity, | ambiguous. For example, the term could refer to a system entity, | |||
| such as a corporation, that has purchased a certificate to operate | such as a corporation, that has purchased a certificate to operate | |||
| equipment, such as a Web server. | equipment, such as a Web server. | |||
| $ certificate path | $ certificate path | |||
| (D) Synonym for "certification path". | (D) Synonym for "certification path". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it suggests | Deprecated Term: ISDs SHOULD NOT use this term; it suggests | |||
| careless use of "certification path", which is a term standardized | careless use of "certification path", which is preferred in PKI | |||
| by X.509. A person who uses this term probably has never read the | standards (e.g., [X509, R3280]). | |||
| basic technical standards for PKI [X509, R3280]. | ||||
| $ certificate policy | $ certificate policy | |||
| (I) "A named set of rules that indicates the applicability of a | (I) "A named set of rules that indicates the applicability of a | |||
| certificate to a particular community and/or class of application | certificate to a particular community and/or class of application | |||
| with common security requirements." [X509] (Compare: CPS, security | with common security requirements." [X509] (Compare: CPS, security | |||
| policy.) | policy.) | |||
| Example: U.S. DoD's certificate policy [DoD7] defined four classes | Example: U.S. DoD's certificate policy [DoD7] defined four classes | |||
| (i.e., assurance levels) for X.509 public-key certificates and | (i.e., assurance levels) for X.509 public-key certificates and | |||
| defines the applicability of those classes. (See: class 2.) | defines the applicability of those classes. (See: class 2.) | |||
| skipping to change at page 47, line 49 ¶ | skipping to change at page 48, line 20 ¶ | |||
| items are changed, and the old certificate is revoked, only as | items are changed, and the old certificate is revoked, only as | |||
| required by the PKI and CPS to support the renewal. If changes go | required by the PKI and CPS to support the renewal. If changes go | |||
| beyond that, the process is a "certificate rekey" or "certificate | beyond that, the process is a "certificate rekey" or "certificate | |||
| update". | update". | |||
| $ certificate request | $ certificate request | |||
| (D) Synonym for "certification request". | (D) Synonym for "certification request". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it suggests | Deprecated Term: ISDs SHOULD NOT use this term; it suggests | |||
| careless use of the term "certification request", which is | careless use of the term "certification request", which is | |||
| standardized by PKCS #10 and used in PKIX. Instead, use | preferred in PKI standards (e.g., see PKCS #10). | |||
| "certification request". | ||||
| $ certificate revocation | $ certificate revocation | |||
| (I) The event that occurs when a CA declares that a previously | (I) The event that occurs when a CA declares that a previously | |||
| valid digital certificate issued by that CA has become invalid; | valid digital certificate issued by that CA has become invalid; | |||
| usually stated with a effective date. | usually stated with a effective date. | |||
| Tutorial: In X.509, a revocation is announced to potential | Tutorial: In X.509, a revocation is announced to potential | |||
| certificate users by issuing a CRL that mentions the certificate. | certificate users by issuing a CRL that mentions the certificate. | |||
| Revocation and listing on a CRL is only necessary prior to the | Revocation and listing on a CRL is only necessary prior to the | |||
| certificate's scheduled expiration. | certificate's scheduled expiration. | |||
| skipping to change at page 48, line 51 ¶ | skipping to change at page 49, line 21 ¶ | |||
| provide additional attribute information for the subject | provide additional attribute information for the subject | |||
| certificate." [DoD7] | certificate." [DoD7] | |||
| Deprecated Term: ISDs SHOULD NOT use this term because it is not | Deprecated Term: ISDs SHOULD NOT use this term because it is not | |||
| widely accepted; instead, use "certificate status responder" or | widely accepted; instead, use "certificate status responder" or | |||
| "OCSP server", or otherwise explain what is meant. | "OCSP server", or otherwise explain what is meant. | |||
| $ certificate status responder | $ certificate status responder | |||
| (N) /FPKI/ A trusted on-line server that acts for a CA to provide | (N) /FPKI/ A trusted on-line server that acts for a CA to provide | |||
| authenticated certificate status information to certificate users | authenticated certificate status information to certificate users | |||
| [FPKI]. Offers an alternative to issuing a CRL, but is not | [FPKI]. Offers an alternative to issuing a CR. (See: certificate | |||
| supported in X.509. (See: certificate revocation tree, OCSP.) | revocation tree, OCSP.) | |||
| $ certificate update | $ certificate update | |||
| (I) The act or process by which non-key data items bound in an | (I) The act or process by which non-key data items bound in an | |||
| existing public-key certificate, especially authorizations granted | existing public-key certificate, especially authorizations granted | |||
| to the subject, are changed by issuing a new certificate. (See: | to the subject, are changed by issuing a new certificate. (See: | |||
| certificate rekey, certificate renewal.) | certificate rekey, certificate renewal.) | |||
| Usage: For an X.509 public-key certificate, the essence of this | Usage: For an X.509 public-key certificate, the essence of this | |||
| process is that fundamental changes are made in the data that is | process is that fundamental changes are made in the data that is | |||
| bound to the public key, such that it is necessary to revoke the | bound to the public key, such that it is necessary to revoke the | |||
| skipping to change at page 53, line 21 ¶ | skipping to change at page 53, line 44 ¶ | |||
| A CPS is usually more detailed and procedurally oriented than a | A CPS is usually more detailed and procedurally oriented than a | |||
| certificate policy. A CPS applies to a particular CA or CA | certificate policy. A CPS applies to a particular CA or CA | |||
| community, while a certificate policy applies across CAs or | community, while a certificate policy applies across CAs or | |||
| communities. A CA with its single CPS may support multiple | communities. A CA with its single CPS may support multiple | |||
| certificate policies, which may be used for different application | certificate policies, which may be used for different application | |||
| purposes or by different user communities. On the other hand, | purposes or by different user communities. On the other hand, | |||
| multiple CAs, each with a different CPS, may support the same | multiple CAs, each with a different CPS, may support the same | |||
| certificate policy. [R3647] | certificate policy. [R3647] | |||
| $ certification request | $ certification request | |||
| (I) A algorithm-independent transaction format, defined by PKCS | (I) A algorithm-independent transaction format (e.g., PKCS #10, | |||
| #10 and used in PKIX, that contains a DN, a public key, and | RFC 4211) that contains a DN, and a public key or, optionally, a | |||
| optionally a set of attributes, collectively signed by the entity | set of attributes, collectively signed by the entity requesting | |||
| requesting certification, and sent to a CA, which transforms the | certification, and sent to a CA, which transforms the request to | |||
| request to an X.509 public-key certificate or another type of | an X.509 public-key certificate or another type of certificate. | |||
| certificate. | ||||
| $ certify | $ certify | |||
| 1. (I) Issue a digital certificate and thus vouch for the truth, | 1. (I) Issue a digital certificate and thus vouch for the truth, | |||
| accuracy, and binding between data items in the certificate (e.g., | accuracy, and binding between data items in the certificate (e.g., | |||
| "X.509 public-key certificate"), such as the identity of the | "X.509 public-key certificate"), such as the identity of the | |||
| certificate's subject and the ownership of a public key. (See: | certificate's subject and the ownership of a public key. (See: | |||
| certification.) | certification.) | |||
| Usage: To "certify a public key" means to issue a public-key | Usage: To "certify a public key" means to issue a public-key | |||
| certificate that vouches for the binding between the certificate's | certificate that vouches for the binding between the certificate's | |||
| subject and the key. | subject and the key. | |||
| 2. (I) The act by which a CA uses measures to verify the truth, | 2. (I) The act by which a CA uses measures to verify the truth, | |||
| accuracy, and binding between data items in a digital certificate. | accuracy, and binding between data items in a digital certificate. | |||
| Tutorial: A description of the measures used for verification | Tutorial: A description of the measures used for verification | |||
| should be included in the CA's CPS. | should be included in the CA's CPS. | |||
| $ CFB | $ CFB | |||
| (N) See: cipher feedback. | (N) See: cipher feedback. | |||
| $ chain | $ chain | |||
| (D) See: trust chain. | (D) See: trust chain. | |||
| $ Challenge Handshake Authentication Protocol (CHAP) | $ Challenge Handshake Authentication Protocol (CHAP) | |||
| (I) A peer entity authentication method for PPP, using a randomly | (I) A peer entity authentication method (employed by PPP and other | |||
| generated challenge and requiring a matching response that depends | protocols, e.g., RFC 3720) that uses a randomly generated | |||
| on a cryptographic hash of some combination of the challenge and a | challenge and requires a matching response that depends on a | |||
| cryptographic hash of some combination of the challenge and a | ||||
| secret key. [R1994] (See: challenge-response, PAP.) | secret key. [R1994] (See: challenge-response, PAP.) | |||
| $ challenge-response | $ challenge-response | |||
| (I) An authentication process that verifies an identity by | (I) An authentication process that verifies an identity by | |||
| requiring correct authentication information to be provided in | requiring correct authentication information to be provided in | |||
| response to a challenge. In a computer system, the authentication | response to a challenge. In a computer system, the authentication | |||
| information is usually a value that is required to be computed in | information is usually a value that is required to be computed in | |||
| response to an unpredictable challenge value, but it might be just | response to an unpredictable challenge value, but it might be just | |||
| password. | password. | |||
| skipping to change at page 55, line 54 ¶ | skipping to change at page 56, line 26 ¶ | |||
| (O) See: Computer Incident Advisory Capability. | (O) See: Computer Incident Advisory Capability. | |||
| $ CIK | $ CIK | |||
| (N) See: cryptographic ignition key. | (N) See: cryptographic ignition key. | |||
| $ cipher | $ cipher | |||
| (I) A cryptographic algorithm for encryption and decryption. | (I) A cryptographic algorithm for encryption and decryption. | |||
| $ cipher block chaining (CBC) | $ cipher block chaining (CBC) | |||
| (N) A block cipher mode that enhances ECB mode by chaining | (N) A block cipher mode that enhances ECB mode by chaining | |||
| together blocks of cipher text it produces. [FP081] (See: [R1829], | together blocks of cipher text it produces. [FP081] (See: block | |||
| [R2405], [R2451].) | cipher, [R1829], [R2405], [R2451], [SP38A].) | |||
| Tutorial: This mode operates by combining (exclusive OR-ing) the | Tutorial: This mode operates by combining (exclusive OR-ing) the | |||
| algorithm's ciphertext output block with the next plaintext block | algorithm's ciphertext output block with the next plaintext block | |||
| to form the next input block for the algorithm. | to form the next input block for the algorithm. | |||
| $ cipher feedback (CFB) | $ cipher feedback (CFB) | |||
| (N) A block cipher mode that enhances ECB mode by chaining | (N) A block cipher mode that enhances ECB mode by chaining | |||
| together the blocks of cipher text it produces and operating on | together the blocks of cipher text it produces and operating on | |||
| plaintext segments of variable length less than or equal to the | plaintext segments of variable length less than or equal to the | |||
| block length. [FP081] | block length. [FP081] (See: block cipher, [SP38A].) | |||
| Tutorial: This mode operates by using the previously generated | Tutorial: This mode operates by using the previously generated | |||
| ciphertext segment as the algorithm's input (i.e., by "feeding | ciphertext segment as the algorithm's input (i.e., by "feeding | |||
| back" the cipher text) to generate an output block, and then | back" the cipher text) to generate an output block, and then | |||
| combining (exclusive OR-ing) that output block with the next | combining (exclusive OR-ing) that output block with the next | |||
| plaintext segment (block length or less) to form the next | plaintext segment (block length or less) to form the next | |||
| ciphertext segment. | ciphertext segment. | |||
| $ cipher text | $ cipher text | |||
| 1. (I) /noun/ Data that has been transformed by encryption so that | 1. (I) /noun/ Data that has been transformed by encryption so that | |||
| its semantic information content (i.e., its meaning) is no longer | its semantic information content (i.e., its meaning) is no longer | |||
| intelligible or directly available. (See: ciphertext. Compare: | intelligible or directly available. (See: ciphertext. Compare: | |||
| clear text, plain text.) | clear text, plain text.) | |||
| 2. (O) "Data produced through the use of encipherment. The | 2. (O) "Data produced through the use of encipherment. The | |||
| semantic content of the resulting data is not available." [I7498- | semantic content of the resulting data is not available." [I7498- | |||
| 2] | 2] | |||
| $ ciphertext | $ ciphertext | |||
| 1. (I) /adjective/ Referring to cipher text. (See: cipher text, | 1. (O) /noun/ Synonym for "cipher text" [I7498-2]. | |||
| Compare: cleartext, plaintext.) | ||||
| 2. (D) /noun/ A synonym for cipher text. | ||||
| Deprecated Usage: ISDs should not use this term as a synonym for | 2. (I) /adjective/ Referring to cipher text. Usage: Commonly used | |||
| cipher text. ISDs SHOULD distinguish between the adjective | instead of "cipher-text". (Compare: cleartext, plaintext.) | |||
| "ciphertext" and the noun phrase "cipher text". | ||||
| $ ciphertext auto-key (CTAK) | $ ciphertext auto-key (CTAK) | |||
| (D) "Cryptographic logic that uses previous cipher text to | (D) "Cryptographic logic that uses previous cipher text to | |||
| generate a key stream." [C4009, A1523] (See: KAK.) | generate a key stream." [C4009, A1523] (See: KAK.) | |||
| Deprecated Term: IDS SHOULD NOT use this term; it is neither well- | Deprecated Term: ISDs SHOULD NOT use this term; it is neither | |||
| known nor precisely defined. Instead, use terms associated with | well-known nor precisely defined. Instead, use terms associated | |||
| modes that are defined in standards, such as CBC, CFB, and OFB. | with modes that are defined in standards, such as CBC, CFB, and | |||
| OFB. | ||||
| $ ciphertext-only attack | $ ciphertext-only attack | |||
| (I) A cryptanalysis technique in which the analyst tries to | (I) A cryptanalysis technique in which the analyst tries to | |||
| determine the key solely from knowledge of intercepted cipher text | determine the key solely from knowledge of intercepted cipher text | |||
| (although the analyst may also know other clues, such as the | (although the analyst may also know other clues, such as the | |||
| cryptographic algorithm, the language in which the plain text was | cryptographic algorithm, the language in which the plain text was | |||
| written, the subject matter of the plain text, and some probable | written, the subject matter of the plain text, and some probable | |||
| plaintext words.) | plaintext words.) | |||
| $ ciphony | $ ciphony | |||
| skipping to change at page 58, line 10 ¶ | skipping to change at page 58, line 31 ¶ | |||
| $ Class A1, B3, B2, B1, C2, or C1 computer system | $ Class A1, B3, B2, B1, C2, or C1 computer system | |||
| (O) /TCSEC/ See: Tutorial under "Trusted Computer System | (O) /TCSEC/ See: Tutorial under "Trusted Computer System | |||
| Evaluation Criteria". | Evaluation Criteria". | |||
| $ classification | $ classification | |||
| 1. (I) A grouping of classified information to which a | 1. (I) A grouping of classified information to which a | |||
| hierarchical, restrictive security label is applied to increase | hierarchical, restrictive security label is applied to increase | |||
| protection of the data from unauthorized disclosure. (See: | protection of the data from unauthorized disclosure. (See: | |||
| aggregation, classified, data confidentiality service. Compare: | aggregation, classified, data confidentiality service. Compare: | |||
| compartment.) | category, compartment.) | |||
| 2. (I) An authorized process by which information is determined to | 2. (I) An authorized process by which information is determined to | |||
| be classified and assigned to a security level. (See: | be classified and assigned to a security level. (See: | |||
| declassification.) | declassification.) | |||
| Usage: Usually understood to involve data confidentiality, but | Usage: Usually understood to involve data confidentiality, but | |||
| ISDs SHOULD make this clear when data also is sensitive in other | ISDs SHOULD make this clear when data also is sensitive in other | |||
| ways and SHOULD use other terms for those other sensitivity | ways and SHOULD use other terms for those other sensitivity | |||
| concepts. (See: sensitive information, data integrity.) | concepts. (See: sensitive information, data integrity.) | |||
| skipping to change at page 59, line 34 ¶ | skipping to change at page 60, line 4 ¶ | |||
| (D) /verb/ Synonym for "erase". [C4009] | (D) /verb/ Synonym for "erase". [C4009] | |||
| Deprecated Definition: ISDs SHOULD NOT use the term with this | Deprecated Definition: ISDs SHOULD NOT use the term with this | |||
| definition; that could be confused with "clear text" in which | definition; that could be confused with "clear text" in which | |||
| information is directly recoverable. | information is directly recoverable. | |||
| $ clear text | $ clear text | |||
| 1. (I) /noun/ Data in which the semantic information content | 1. (I) /noun/ Data in which the semantic information content | |||
| (i.e., the meaning) is intelligible or is directly available, | (i.e., the meaning) is intelligible or is directly available, | |||
| i.e., not encrypted. (See: cleartext, in the clear. Compare: | i.e., not encrypted. (See: cleartext, in the clear. Compare: | |||
| cipher text, plain text.) | cipher text, plain text.) | |||
| 2. (O) "Intelligible data, the semantic content of which is | 2. (O) /noun/ "Intelligible data, the semantic content of which is | |||
| available." [I7498-2] | available." [I7498-2] | |||
| 3. (D) Synonym for "plain text". | 3. (D) /noun/ Synonym for "plain text". | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "plain text", because the plain text that is input to an | for "plain text", because the plain text that is input to an | |||
| encryption process may itself be cipher text that was output from | encryption operation may itself be cipher text that was output | |||
| an encryption. (See: superencryption.) | from a previous encryption operation. (See: superencryption.) | |||
| $ clearance | $ clearance | |||
| See: security clearance. | See: security clearance. | |||
| $ clearance level | $ clearance level | |||
| (I) The security level of information to which a security | (I) The security level of information to which a security | |||
| clearance authorizes a person to have access. | clearance authorizes a person to have access. | |||
| $ cleartext | $ cleartext | |||
| 1. (I) /adjective/ Referring to clear text. (See: clear text. | 1. (O) /noun/ Synonym for "clear text" [I7498-2]. | |||
| Compare: ciphertext, plaintext.) | ||||
| 2. (D) /noun/ A synonym for clear text. | ||||
| Deprecated Usage: ISDs should not use this term as a synonym for | 2. (I) /adjective/ Referring to clear text. Usage: Commonly used | |||
| clear text. ISDs SHOULD distinguish between the adjective | instead of "clear-text". (Compare: ciphertext, plaintext.) | |||
| "cleartext" and the noun phrase "clear text". | ||||
| 3. (D) /adjective/ Synonym for "plaintext". | ||||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | ||||
| for "plaintext", because the plaintext data that is input to an | ||||
| encryption operation may itself be ciphertext data that was output | ||||
| from a previous encryption operation. (See: superencryption.) | ||||
| $ CLEF | $ CLEF | |||
| (N) See: commercially licensed evaluation facility. | (N) See: commercially licensed evaluation facility. | |||
| $ client | $ client | |||
| (I) A system entity that requests and uses a service provided by | (I) A system entity that requests and uses a service provided by | |||
| another system entity, called a "server". (See: server.) | another system entity, called a "server". (See: server.) | |||
| Tutorial: Usually, it is understood that the client and server are | Tutorial: Usually, it is understood that the client and server are | |||
| automated components of the system, and the client makes the | automated components of the system, and the client makes the | |||
| skipping to change at page 61, line 9 ¶ | skipping to change at page 61, line 34 ¶ | |||
| provide an acceptable presumption that they have not introduced | provide an acceptable presumption that they have not introduced | |||
| malicious logic. (b) Configuration control provides sufficient | malicious logic. (b) Configuration control provides sufficient | |||
| assurance that system applications and the equipment they run on | assurance that system applications and the equipment they run on | |||
| are protected against the introduction of malicious logic prior to | are protected against the introduction of malicious logic prior to | |||
| and during the operation of applications. [NCS04] (See: "first | and during the operation of applications. [NCS04] (See: "first | |||
| law" under "Courtney's laws". Compare: open security environment.) | law" under "Courtney's laws". Compare: open security environment.) | |||
| $ CMA | $ CMA | |||
| (D) See: certificate management authority. | (D) See: certificate management authority. | |||
| $ CMAC | ||||
| (N) A message authentication code, specified by NIST [SP38B], that | ||||
| is based on a symmetric block cipher. (See: block cipher.) | ||||
| Derivation: Cipher-based MAC. (Compare: HMAC.) | ||||
| Tutorial: Because CMAC is based on approved, symmetric-key block | ||||
| ciphers, such as AES, CMAC can be considered a mode of operation | ||||
| for those block ciphers. (See: mode of operation.) | ||||
| $ CMCS | $ CMCS | |||
| (O) See: COMSEC Material Control System. | (O) See: COMSEC Material Control System. | |||
| $ CMM | $ CMM | |||
| (N) See: Capability Maturity Model. | (N) See: Capability Maturity Model. | |||
| $ CMS | $ CMS | |||
| (I) See: Cryptographic Message Syntax. | (I) See: Cryptographic Message Syntax. | |||
| $ code | $ code | |||
| skipping to change at page 62, line 15 ¶ | skipping to change at page 62, line 50 ¶ | |||
| 2. (I) An encryption algorithm that uses a word substitution | 2. (I) An encryption algorithm that uses a word substitution | |||
| technique. [C4009] (See: code, ECB.) | technique. [C4009] (See: code, ECB.) | |||
| $ code signing | $ code signing | |||
| (I) A security mechanism that uses a digital signature to provide | (I) A security mechanism that uses a digital signature to provide | |||
| data integrity and data origin authentication for software that is | data integrity and data origin authentication for software that is | |||
| being distributed for use. (See: mobile code, trusted | being distributed for use. (See: mobile code, trusted | |||
| distribution.) | distribution.) | |||
| Tutorial: In some cases, the signature on a software module may | ||||
| imply some assertion that the signer makes about the software. For | ||||
| example, a signature may imply that the software has been | ||||
| designed, developed, or tested according some criterion. | ||||
| $ code word | $ code word | |||
| (O) /U.S. Government/ "A single word assigned a classified meaning | (O) /U.S. Government/ "A single word assigned a classified meaning | |||
| by appropriate authority to ensure proper security concerning | by appropriate authority to ensure proper security concerning | |||
| intentions and to safeguard information pertaining to actual, | intentions and to safeguard information pertaining to actual, | |||
| real-world military plans or operations classified as CONFIDENTIAL | real-world military plans or operations classified as CONFIDENTIAL | |||
| or higher." | or higher." | |||
| $ collateral information | $ collateral information | |||
| (O) /U.S. Government/ "Information identified as National Security | (O) /U.S. Government/ "Information identified as National Security | |||
| Information under the provisions of [Executive Order] 12958 but | Information under the provisions of [Executive Order] 12958 but | |||
| skipping to change at page 65, line 7 ¶ | skipping to change at page 65, line 48 ¶ | |||
| information in support of shared missions, business processes, and | information in support of shared missions, business processes, and | |||
| objectives." | objectives." | |||
| $ community risk | $ community risk | |||
| (N) Probability that a particular vulnerability will be exploited | (N) Probability that a particular vulnerability will be exploited | |||
| within an interacting population and adversely affect some members | within an interacting population and adversely affect some members | |||
| of that population. [C4009] (See: Morris worm.) | of that population. [C4009] (See: Morris worm.) | |||
| $ community string | $ community string | |||
| (I) A community name in the form of an octet string that serves as | (I) A community name in the form of an octet string that serves as | |||
| a cleartext password in SNMP version 1. (RFC 1157) | a cleartext password in SNMP version 1 (RFC 1157) and version 2 | |||
| (RFC 1901). (See: password, Simple Network Management Protocol.) | ||||
| Tutorial: The SNMPv1 and SNMPv2 protocols have been declared | ||||
| "historic" and have been replaced by the more secure SNMPv3 | ||||
| standard (RFCs 3410-3418), which does not use cleartext passwords. | ||||
| $ compartment | $ compartment | |||
| 1. (I) A grouping of sensitive information items that require | 1. (I) A grouping of sensitive information items that require | |||
| special access controls beyond those normally provided for the | special access controls beyond those normally provided for the | |||
| basic classification level of the information. (See: compartmented | basic classification level of the information. (See: compartmented | |||
| security mode. Compare: category, classification.) | security mode. Compare: category, classification.) | |||
| Usage: The term is usually understood to include the special | Usage: The term is usually understood to include the special | |||
| handling procedures to be used for the information. | handling procedures to be used for the information. | |||
| skipping to change at page 67, line 11 ¶ | skipping to change at page 68, line 4 ¶ | |||
| $ computer system | $ computer system | |||
| (I) Synonym for "information system", or a component thereof. | (I) Synonym for "information system", or a component thereof. | |||
| (Compare: computer platform.) | (Compare: computer platform.) | |||
| $ computer emergency response team (CERT) | $ computer emergency response team (CERT) | |||
| (I) An organization that studies computer and network INFOSEC in | (I) An organization that studies computer and network INFOSEC in | |||
| order to provide incident response services to victims of attacks, | order to provide incident response services to victims of attacks, | |||
| publish alerts concerning vulnerabilities and threats, and offer | publish alerts concerning vulnerabilities and threats, and offer | |||
| other information to help improve computer and network security. | other information to help improve computer and network security. | |||
| (See: CSIRT, security incident.) | (See: CSIRT, security incident.) | |||
| Examples: CERT Coordination Center at Carnegie Mellon University | ||||
| Examples: CERT Coordination Center at Carnegie-Mellon University | ||||
| (sometimes called "the" CERT); CIAC. | (sometimes called "the" CERT); CIAC. | |||
| $ Computer Incident Advisory Capability (CIAC) | $ Computer Incident Advisory Capability (CIAC) | |||
| (O) The centralized CSIRT of the U.S. Department of Energy; a | (O) The centralized CSIRT of the U.S. Department of Energy; a | |||
| member of FIRST. | member of FIRST. | |||
| $ computer network | $ computer network | |||
| (I) A collection of host computers together with the subnetwork or | (I) A collection of host computers together with the subnetwork or | |||
| internetwork through which they can exchange data. | internetwork through which they can exchange data. | |||
| skipping to change at page 70, line 36 ¶ | skipping to change at page 71, line 29 ¶ | |||
| Tutorial: Configuration control helps protect against unauthorized | Tutorial: Configuration control helps protect against unauthorized | |||
| or malicious alteration of a system and thus provides assurance of | or malicious alteration of a system and thus provides assurance of | |||
| system integrity. (See: malicious logic.) | system integrity. (See: malicious logic.) | |||
| $ confinement property | $ confinement property | |||
| (N) /formal model/ Property of a system whereby a subject has | (N) /formal model/ Property of a system whereby a subject has | |||
| write access to an object only if the classification of the object | write access to an object only if the classification of the object | |||
| dominates the clearance of the subject. (See: *-property, Bell- | dominates the clearance of the subject. (See: *-property, Bell- | |||
| LaPadula model.) | LaPadula model.) | |||
| $ connectionless integrity service | ||||
| (I) Synonym for "datagram integrity service". | ||||
| $ constraint | $ constraint | |||
| (I) /access control/ A limitation on the function of an identity, | (I) /access control/ A limitation on the function of an identity, | |||
| role, or privilege. (See: rule-based access control.) | role, or privilege. (See: rule-based access control.) | |||
| Tutorial: In effect, a constraint is a form of security policy and | Tutorial: In effect, a constraint is a form of security policy and | |||
| may be either static or dynamic: | may be either static or dynamic: | |||
| - "Static constraint": A constraint that must be satisfied at the | - "Static constraint": A constraint that must be satisfied at the | |||
| time the policy is defined, and then continues to be satisfied | time the policy is defined, and then continues to be satisfied | |||
| until the constraint is removed. | until the constraint is removed. | |||
| - "Dynamic constraint": A constraint that may be defined to apply | - "Dynamic constraint": A constraint that may be defined to apply | |||
| skipping to change at page 73, line 11 ¶ | skipping to change at page 73, line 51 ¶ | |||
| definition 3; that would duplicate the meaning of better- | definition 3; that would duplicate the meaning of better- | |||
| established terms and mix concepts in a potentially misleading | established terms and mix concepts in a potentially misleading | |||
| way. | way. | |||
| $ Coordinated Universal Time (UTC) | $ Coordinated Universal Time (UTC) | |||
| (N) UTC is derived from International Atomic Time (TAI) by adding | (N) UTC is derived from International Atomic Time (TAI) by adding | |||
| a number of leap seconds. The International Bureau of Weights and | a number of leap seconds. The International Bureau of Weights and | |||
| Measures computes TAI once each month by averaging data from many | Measures computes TAI once each month by averaging data from many | |||
| laboratories. (See: GeneralizedTime, UTCTime.) | laboratories. (See: GeneralizedTime, UTCTime.) | |||
| $ copy | $ correction | |||
| See: card copy. | (I) /security/ A system change made to eliminate or reduce the | |||
| risk of reoccurrence of a security violation or threat | ||||
| $ correction | consequence. (See: secondary definition under "security".) | |||
| (I) See: secondary definition under "security". | ||||
| $ correctness | $ correctness | |||
| (I) "The property of a system that is guaranteed as the result of | (I) "The property of a system that is guaranteed as the result of | |||
| formal verification activities." [Huff] (See: correctness proof, | formal verification activities." [Huff] (See: correctness proof, | |||
| verification.) | verification.) | |||
| $ correctness integrity | $ correctness integrity | |||
| (I) The property that the information represented by data is | (I) The property that the information represented by data is | |||
| accurate and consistent. (Compare: data integrity, source | accurate and consistent. (Compare: data integrity, source | |||
| integrity.) | integrity.) | |||
| Tutorial: IDS SHOULD NOT use this term without providing a | Tutorial: ISDs SHOULD NOT use this term without providing a | |||
| definition; the term is neither well-known nor precisely defined. | definition; the term is neither well-known nor precisely defined. | |||
| Data integrity refers to the constancy of data values, and source | Data integrity refers to the constancy of data values, and source | |||
| integrity refers to confidence in data values. However, | integrity refers to confidence in data values. However, | |||
| correctness integrity refers to confidence in the underlying | correctness integrity refers to confidence in the underlying | |||
| information that data values represent, and this property is | information that data values represent, and this property is | |||
| closely related to issues of accountability and error handling. | closely related to issues of accountability and error handling. | |||
| $ correctness proof | $ correctness proof | |||
| (I) A mathematical proof of consistency between a specification | (I) A mathematical proof of consistency between a specification | |||
| for system security and the implementation of that specification. | for system security and the implementation of that specification. | |||
| (See: correctness, formal specification.) | (See: correctness, formal specification.) | |||
| $ corruption | $ corruption | |||
| (I) A type of threat action that undesirably alters system | (I) A type of threat action that undesirably alters system | |||
| operation by adversely modifying system functions or data. (See: | operation by adversely modifying system functions or data. (See: | |||
| disruption.) | disruption.) | |||
| Usage: This type of threat action includes the following subtypes: | Usage: This type of threat action includes the following subtypes: | |||
| - "Tampering": In context of corruption, deliberately altering a | - "Tampering": /corruption/ Deliberately altering a system's | |||
| system's logic, data, or control information to interrupt or | logic, data, or control information to interrupt or prevent | |||
| prevent correct operation of system functions. (See: misuse, | correct operation of system functions. (See: misuse, main entry | |||
| main entry for "tampering".) | for "tampering".) | |||
| - "Malicious logic": In context of corruption, any hardware, | - "Malicious logic": /corruption/ Any hardware, firmware, or | |||
| firmware, or software (e.g., a computer virus) intentionally | software (e.g., a computer virus) intentionally introduced into | |||
| introduced into a system to modify system functions or data. | a system to modify system functions or data. (See: | |||
| (See: incapacitation, main entry for "malicious logic", | incapacitation, main entry for "malicious logic", masquerade, | |||
| masquerade, misuse.) | misuse.) | |||
| - "Human error": In context of corruption, human action or | - "Human error": /corruption/ Human action or inaction that | |||
| inaction that unintentionally results in the alteration of | unintentionally results in the alteration of system functions | |||
| system functions or data. | or data. | |||
| - "Hardware or software error": In context of corruption, error | - "Hardware or software error": /corruption/ Error that results | |||
| that results in the alteration of system functions or data. | in the alteration of system functions or data. | |||
| - "Natural disaster": In context of corruption, any "act of God" | - "Natural disaster": /corruption/ Any "act of God" (e.g., power | |||
| (e.g., power surge caused by lightning) that alters system | surge caused by lightning) that alters system functions or | |||
| functions or data. [FP031 section 2] | data. [FP031 section 2] | |||
| $ counter | ||||
| 1. (N) /noun/ See: counter mode. | ||||
| 2. (I) /verb/ See: countermeasure. | ||||
| $ counter-countermeasure | $ counter-countermeasure | |||
| (I) An action, device, procedure, or technique used by an attacker | (I) An action, device, procedure, or technique used by an attacker | |||
| to offset a defensive countermeasure. | to offset a defensive countermeasure. | |||
| Tutorial: For every countermeasure devised to protect computers | Tutorial: For every countermeasure devised to protect computers | |||
| and networks, some cracker probably will be able to devise a | and networks, some cracker probably will be able to devise a | |||
| counter-countermeasure. Thus, systems must use "defense in depth". | counter-countermeasure. Thus, systems must use "defense in depth". | |||
| $ counter mode (CTR) | ||||
| (N) A block cipher mode that enhances ECB mode by ensuring that | ||||
| each encrypted block is different from every other block encrypted | ||||
| under the same key. [SP38A] (See: block cipher.) | ||||
| Tutorial: This mode operates by first encrypting a generated | ||||
| sequence of blocks, called "counters", which are separate from the | ||||
| input sequence of plaintext blocks which the mode is intended to | ||||
| protect. The resulting sequence of encrypted counters is | ||||
| exclusive-ORed with the sequence of plaintext blocks to produce | ||||
| the final ciphertext output blocks. The sequence of counters must | ||||
| have the property that each counter is different from every other | ||||
| counter for all of the plain text that is encrypted under the same | ||||
| key. | ||||
| $ Counter with Cipher Block Chaining-Message Authentication Code | ||||
| (CCM) | ||||
| (N) A block cipher mode, specified by NIST [SP38C], that provides | ||||
| both data confidentiality and data origin authentication, by | ||||
| combining the techniques of CTR and a CBC-based message | ||||
| authentication code. (See: block cipher.) | ||||
| $ countermeasure | $ countermeasure | |||
| (I) An action, device, procedure, or technique that reduces a | (I) An action, device, procedure, or technique that meets or | |||
| threat, a vulnerability, or an attack by eliminating or preventing | opposes (i.e., counters) a threat, a vulnerability, or an attack | |||
| it, by minimizing the harm it can cause, or by discovering and | by eliminating or preventing it, by minimizing the harm it can | |||
| reporting it so that corrective action can be taken. | cause, or by discovering and reporting it so that corrective | |||
| action can be taken. | ||||
| Tutorial: In an Internet protocol, a countermeasure may take the | Tutorial: In an Internet protocol, a countermeasure may take the | |||
| form of a protocol feature, an component function, or a usage | form of a protocol feature, an component function, or a usage | |||
| constraint. | constraint. | |||
| $ country code | $ country code | |||
| (I) An identifier that is defined for a nation by ISO. [I3166] | (I) An identifier that is defined for a nation by ISO. [I3166] | |||
| Tutorial: For each nation, ISO Standard 3166 defines a unique two- | Tutorial: For each nation, ISO Standard 3166 defines a unique two- | |||
| character alphabetic code, a unique three-character alphabetic | character alphabetic code, a unique three-character alphabetic | |||
| skipping to change at page 77, line 44 ¶ | skipping to change at page 79, line 8 ¶ | |||
| invalid; but if the extension is non-critical, the program is | invalid; but if the extension is non-critical, the program is | |||
| permitted to ignore the extension. | permitted to ignore the extension. | |||
| In a CRL, if a program does not recognize a critical extension | In a CRL, if a program does not recognize a critical extension | |||
| that is associated with a specific certificate, the program is | that is associated with a specific certificate, the program is | |||
| required to assume that the listed certificate has been revoked | required to assume that the listed certificate has been revoked | |||
| and is no longer valid, and then take whatever action is required | and is no longer valid, and then take whatever action is required | |||
| by local policy. | by local policy. | |||
| When a program does not recognize a critical extension that is | When a program does not recognize a critical extension that is | |||
| associated with the CRL as whole, the program is required to | associated with the CRL as a whole, the program is required to | |||
| assume that all listed certificates have been revoked and are no | assume that all listed certificates have been revoked and are no | |||
| longer valid. However, since failing to process the extension may | longer valid. However, since failing to process the extension may | |||
| mean that the list has not been completed, the program cannot | mean that the list has not been completed, the program cannot | |||
| assume that other certificates are valid, and the program needs to | assume that other certificates are valid, and the program needs to | |||
| take whatever action is therefore required by local policy. | take whatever action is therefore required by local policy. | |||
| $ critical information infrastructure | $ critical information infrastructure | |||
| (I) Those systems that are so vital to a nation that their | (I) Those systems that are so vital to a nation that their | |||
| incapacity or destruction would have a debilitating affect on | incapacity or destruction would have a debilitating effect on | |||
| national security, the economy, or public health and safety. | national security, the economy, or public health and safety. | |||
| $ CRL | $ CRL | |||
| (I) See: certificate revocation list. | (I) See: certificate revocation list. | |||
| $ CRL distribution point | $ CRL distribution point | |||
| (I) See: distribution point. | (I) See: distribution point. | |||
| $ CRL extension | $ CRL extension | |||
| (I) See: extension. | (I) See: extension. | |||
| skipping to change at page 79, line 15 ¶ | skipping to change at page 80, line 31 ¶ | |||
| 2. (O) /U.S. Government/ A process or subsystem that provides a | 2. (O) /U.S. Government/ A process or subsystem that provides a | |||
| capability (which could be either manual or automated) to access | capability (which could be either manual or automated) to access | |||
| two or more differing security domains in a system, or to transfer | two or more differing security domains in a system, or to transfer | |||
| information between such domains. (See: domain, guard.) | information between such domains. (See: domain, guard.) | |||
| $ cryptanalysis | $ cryptanalysis | |||
| 1. (I) The mathematical science that deals with analysis of a | 1. (I) The mathematical science that deals with analysis of a | |||
| cryptographic system in order to gain knowledge needed to break or | cryptographic system in order to gain knowledge needed to break or | |||
| circumvent the protection that the system is designed to provide. | circumvent the protection that the system is designed to provide. | |||
| (See: cryptology.) | (See: cryptology, secondary defintion under "intrusion".) | |||
| 2. (O) "The analysis of a cryptographic system and/or its inputs | 2. (O) "The analysis of a cryptographic system and/or its inputs | |||
| and outputs to derive confidential variables and/or sensitive data | and outputs to derive confidential variables and/or sensitive data | |||
| including cleartext." [I7498-2] | including cleartext." [I7498-2] | |||
| Tutorial: Definition 2 states the traditional goal of | Tutorial: Definition 2 states the traditional goal of | |||
| cryptanalysis, i.e. convert cipher text to plain text (which | cryptanalysis, i.e. convert cipher text to plain text (which | |||
| usually is clear text) without knowing the key; but that | usually is clear text) without knowing the key; but that | |||
| definition applies only to encryption systems. Today, the term is | definition applies only to encryption systems. Today, the term is | |||
| used with reference to all kinds of cryptographic algorithms and | used with reference to all kinds of cryptographic algorithms and | |||
| skipping to change at page 79, line 37 ¶ | skipping to change at page 80, line 53 ¶ | |||
| however, a cryptanalyst tries to uncover or reproduce someone | however, a cryptanalyst tries to uncover or reproduce someone | |||
| else's sensitive data, such as clear text, a key, or an algorithm. | else's sensitive data, such as clear text, a key, or an algorithm. | |||
| The basic cryptanalytic attacks on encryption systems are | The basic cryptanalytic attacks on encryption systems are | |||
| ciphertext-only, known-plaintext, chosen-plaintext, and chosen- | ciphertext-only, known-plaintext, chosen-plaintext, and chosen- | |||
| ciphertext; and these generalize to the other kinds of | ciphertext; and these generalize to the other kinds of | |||
| cryptography. | cryptography. | |||
| $ crypto, CRYPTO | $ crypto, CRYPTO | |||
| 1. (N) A prefix ("crypto-") that means "cryptographic". | 1. (N) A prefix ("crypto-") that means "cryptographic". | |||
| Usage: ISDs MAY use this prefix when it part of a term listed in | Usage: ISDs MAY use this prefix when it is part of a term listed | |||
| this Glossary. Otherwise, ISDs SHOULD NOT use this prefix; | in this Glossary. Otherwise, ISDs SHOULD NOT use this prefix; | |||
| instead, use the unabbreviated adjective, "cryptographic". | instead, use the unabbreviated adjective, "cryptographic". | |||
| 2. (D) In lower case, "crypto" is an abbreviation for the | 2. (D) In lower case, "crypto" is an abbreviation for the | |||
| adjective "cryptographic", or for the nouns "cryptography" or | adjective "cryptographic", or for the nouns "cryptography" or | |||
| "cryptographic component". | "cryptographic component". | |||
| Deprecated Abbreviation: ISDs SHOULD NOT use this abbreviation | Deprecated Abbreviation: ISDs SHOULD NOT use this abbreviation | |||
| because it could easily be misunderstood in some technical sense. | because it could easily be misunderstood in some technical sense. | |||
| 3. (O) /U.S. Government/ In upper case, "CRYPTO" is a marking or | 3. (O) /U.S. Government/ In upper case, "CRYPTO" is a marking or | |||
| skipping to change at page 83, line 17 ¶ | skipping to change at page 84, line 33 ¶ | |||
| $ CSIRT | $ CSIRT | |||
| (I) See: computer security incident response team. | (I) See: computer security incident response team. | |||
| $ CSOR | $ CSOR | |||
| (N) See: Computer Security Objects Register. | (N) See: Computer Security Objects Register. | |||
| $ CTAK | $ CTAK | |||
| (D) See: ciphertext auto-key. | (D) See: ciphertext auto-key. | |||
| $ CTR | ||||
| (N) See: counter mode. | ||||
| $ cut-and-paste attack | $ cut-and-paste attack | |||
| (I) An active attack on the data integrity of cipher text, | (I) An active attack on the data integrity of cipher text, | |||
| effected by replacing sections of cipher text with other cipher | effected by replacing sections of cipher text with other cipher | |||
| text, such that the result appears to decrypt correctly but | text, such that the result appears to decrypt correctly but | |||
| actually decrypts to plain text that is forged to the satisfaction | actually decrypts to plain text that is forged to the satisfaction | |||
| of the attacker. | of the attacker. | |||
| $ cyclic redundancy check (CRC) | $ cyclic redundancy check (CRC) | |||
| (I) A type of checksum algorithm that is not a cryptographic hash | (I) A type of checksum algorithm that is not a cryptographic hash | |||
| but is used to implement data integrity service where accidental | but is used to implement data integrity service where accidental | |||
| skipping to change at page 90, line 6 ¶ | skipping to change at page 91, line 26 ¶ | |||
| Usage: Usually abbreviated as "dedicated mode". This mode was | Usage: Usually abbreviated as "dedicated mode". This mode was | |||
| defined in U.S. Government policy on system accreditation, but the | defined in U.S. Government policy on system accreditation, but the | |||
| term is also used outside the Government. In this mode, the system | term is also used outside the Government. In this mode, the system | |||
| may handle either (a) a single classification level or category of | may handle either (a) a single classification level or category of | |||
| information or (b) a range of levels and categories. | information or (b) a range of levels and categories. | |||
| $ default account | $ default account | |||
| (I) A system login account (usually accessed with a user | (I) A system login account (usually accessed with a user | |||
| identifier and password) that has been predefined in a | identifier and password) that has been predefined in a | |||
| manufactured system to permit initial access when the system is | manufactured system to permit initial access when the system is | |||
| first put into service. (See: harden.] | first put into service. (See: harden.) | |||
| Tutorial: A default account becomes a serious vulnerability if not | Tutorial: A default account becomes a serious vulnerability if not | |||
| properly administered. Sometimes, the default identifier and | properly administered. Sometimes, the default identifier and | |||
| password are well-known because they are the same in each copy of | password are well-known because they are the same in each copy of | |||
| the system. In any case, when a system is put into service, any | the system. In any case, when a system is put into service, any | |||
| default password should immediately be changed or the default | default password should immediately be changed or the default | |||
| account should be disabled. | account should be disabled. | |||
| $ defense in depth | $ defense in depth | |||
| (N) "The siting of mutually supporting defense positions designed | (N) "The siting of mutually supporting defense positions designed | |||
| skipping to change at page 91, line 33 ¶ | skipping to change at page 92, line 51 ¶ | |||
| (I) See: data encryption key. | (I) See: data encryption key. | |||
| $ delay | $ delay | |||
| (I) /packet/ See: secondary definition under "stream integrity | (I) /packet/ See: secondary definition under "stream integrity | |||
| service". | service". | |||
| $ deletion | $ deletion | |||
| (I) /packet/ See: secondary definition under "stream integrity | (I) /packet/ See: secondary definition under "stream integrity | |||
| service". | service". | |||
| $ deliberate exposure | ||||
| (I) /threat action/ See: secondary definition under "exposure". | ||||
| $ delta CRL | $ delta CRL | |||
| (I) A partial CRL that only contains entries for X.509 | (I) A partial CRL that only contains entries for certificates that | |||
| certificates that have been revoked since the issuance of a prior, | have been revoked since the issuance of a prior, base CRL [X509]. | |||
| base CRL. This method can be used to partition CRLs that become | This method can be used to partition CRLs that become too large | |||
| too large and unwieldy. (Compare: CRL distribution point.) | and unwieldy. (Compare: CRL distribution point.) | |||
| $ demilitarized zone (DMZ) | $ demilitarized zone (DMZ) | |||
| (D) Synonym for "buffer zone". | (D) Synonym for "buffer zone". | |||
| Deprecated Term: ISDs SHOULD NOT use this term because it mixes | Deprecated Term: ISDs SHOULD NOT use this term because it mixes | |||
| concepts in a potentially misleading way. (See: Deprecated Usage | concepts in a potentially misleading way. (See: Deprecated Usage | |||
| under "Green Book".) | under "Green Book".) | |||
| $ denial of service | $ denial of service | |||
| (I) The prevention of authorized access to a system resource or | (I) The prevention of authorized access to a system resource or | |||
| skipping to change at page 92, line 34 ¶ | skipping to change at page 94, line 6 ¶ | |||
| (I) An attack that uses a brute-force technique of successively | (I) An attack that uses a brute-force technique of successively | |||
| trying all the words in some large, exhaustive list. | trying all the words in some large, exhaustive list. | |||
| Examples: Attack an authentication service by trying all possible | Examples: Attack an authentication service by trying all possible | |||
| passwords. Attack an encryption service by encrypting some known | passwords. Attack an encryption service by encrypting some known | |||
| plaintext phrase with all possible keys so that the key for any | plaintext phrase with all possible keys so that the key for any | |||
| given encrypted message containing that phrase may be obtained by | given encrypted message containing that phrase may be obtained by | |||
| lookup. | lookup. | |||
| $ Diffie-Hellman | $ Diffie-Hellman | |||
| $ Diffie-Hellman-Merkle | ||||
| (N) A key-agreement algorithm published in 1976 by Whitfield | (N) A key-agreement algorithm published in 1976 by Whitfield | |||
| Diffie and Martin Hellman [DH76, R2631]. | Diffie and Martin Hellman [DH76, R2631]. | |||
| Tutorial: Diffie-Hellman does key establishment, not encryption. | Usage: The algoritm is most often called "Diffie-Hellman". | |||
| However, the key that it produces may be used for encryption, for | However, in the November 1978 issue of "IEEE Communications | |||
| further key management operations, or for any other cryptography. | Magazine", Hellman wrote that the algorithm "is a public key | |||
| distribution system, a concept developed by [Ralph C.] Merkle, and | ||||
| hence should be called 'Diffie-Hellman-Merkle' . . . to recognize | ||||
| Merkle's equal contribution to the invention of public key | ||||
| cryptography." | ||||
| Tutorial: Diffie-Hellman-Merkle does key establishment, not | ||||
| encryption. However, the key that it produces may be used for | ||||
| encryption, for further key management operations, or for any | ||||
| other cryptography. | ||||
| The algorithm is described in [R2631] and [Schn]. In brief, Alice | The algorithm is described in [R2631] and [Schn]. In brief, Alice | |||
| and Bob together pick large integers that satisfy certain | and Bob together pick large integers that satisfy certain | |||
| mathematical conditions, and then use the integers to each | mathematical conditions, and then use the integers to each | |||
| separately compute a public-private key pair. They send each other | separately compute a public-private key pair. They send each other | |||
| their public key. Each person uses their own private key and the | their public key. Each person uses their own private key and the | |||
| other person's public key to compute a key, k, that, because of | other person's public key to compute a key, k, that, because of | |||
| the mathematics of the algorithm, is the same for each of them. | the mathematics of the algorithm, is the same for each of them. | |||
| Passive wiretapping cannot learn the shared k, because k is not | Passive wiretapping cannot learn the shared k, because k is not | |||
| transmitted, and neither are the private keys needed to compute k. | transmitted, and neither are the private keys needed to compute k. | |||
| The difficulty of breaking Diffie-Hellman is considered to be | The difficulty of breaking Diffie-Hellman-Merkle is considered to | |||
| equal to the difficulty of computing discrete logarithms modulo a | be equal to the difficulty of computing discrete logarithms modulo | |||
| large prime. However, without additional mechanisms to | a large prime. However, without additional mechanisms to | |||
| authenticate each party to the other, a protocol based on the | authenticate each party to the other, a protocol based on the | |||
| algorithm may be vulnerable to a man-in-the-middle attack. | algorithm may be vulnerable to a man-in-the-middle attack. | |||
| $ digest | $ digest | |||
| See: message digest. | See: message digest. | |||
| $ digital certificate | $ digital certificate | |||
| (I) A certificate document in the form of a digital data object (a | (I) A certificate document in the form of a digital data object (a | |||
| data object used by a computer) to which is appended a computed | data object used by a computer) to which is appended a computed | |||
| digital signature value that depends on the data object. (See: | digital signature value that depends on the data object. (See: | |||
| skipping to change at page 94, line 30 ¶ | skipping to change at page 96, line 10 ¶ | |||
| $ digital notary | $ digital notary | |||
| (I) An electronic functionary analogous to a notary public. | (I) An electronic functionary analogous to a notary public. | |||
| Provides a trusted time stamp for a digital document, so that | Provides a trusted time stamp for a digital document, so that | |||
| someone can later prove that the document existed at that point in | someone can later prove that the document existed at that point in | |||
| time; verifies the signature(s) on a signed document before | time; verifies the signature(s) on a signed document before | |||
| applying the stamp. (See: notarization.) | applying the stamp. (See: notarization.) | |||
| $ digital signature | $ digital signature | |||
| 1. (I) A value computed with a cryptographic algorithm and | 1. (I) A value computed with a cryptographic algorithm and | |||
| appended to a data object in such a way that any recipient of the | associated with a data object in such a way that any recipient of | |||
| data can use the signature to verify the data's origin and | the data can use the signature to verify the data's origin and | |||
| integrity. (See: data origin authentication service, data | integrity. (See: data origin authentication service, data | |||
| integrity service, signer. Compare: digitized signature, | integrity service, signer. Compare: digitized signature, | |||
| electronic signature.) | electronic signature.) | |||
| 2. (I) "Data appended to, or a cryptographic transformation of, a | 2. (O) "Data appended to, or a cryptographic transformation of, a | |||
| data unit that allows a recipient of the data unit to prove the | data unit that allows a recipient of the data unit to prove the | |||
| source and integrity of the data unit and protect against forgery, | source and integrity of the data unit and protect against forgery, | |||
| e.g. by the recipient." [I7498-2] | e.g. by the recipient." [I7498-2] | |||
| Tutorial: A digital signature should have these properties: | Tutorial: A digital signature should have these properties: | |||
| - Uniquely identify a system entity as being the signer. | ||||
| - Be under the signer's sole control, so that it cannot be | ||||
| created by any other entity. | ||||
| - Be capable of being verified. (See: validate vs. verify.) | - Be capable of being verified. (See: validate vs. verify.) | |||
| - Be bound to the signed data object in such a way that if the | - Be bound to the signed data object in such a way that if the | |||
| data is changed, then when an attempt is made to verify the | data is changed, then when an attempt is made to verify the | |||
| signature, it will be seen as not authentic. | signature, it will be seen as not authentic. (In some schemes, | |||
| the signature is appended to the signed object as stated by | ||||
| definition 2, but in other schemes it is not.) | ||||
| - Uniquely identify a system entity as being the signer. | ||||
| - Be under the signer's sole control, so that it cannot be | ||||
| created by any other entity. | ||||
| To achieve these properties, the data object is first input to a | To achieve these properties, the data object is first input to a | |||
| hash function, and then the hash result is cryptographically | hash function, and then the hash result is cryptographically | |||
| transformed using a private key of the signer. The final resulting | transformed using a private key of the signer. The final resulting | |||
| value is called the digital signature of the data object. The | value is called the digital signature of the data object. The | |||
| signature value is a protected checksum, because the properties of | signature value is a protected checksum, because the properties of | |||
| a cryptographic hash ensure that if the data object is changed, | a cryptographic hash ensure that if the data object is changed, | |||
| the digital signature will no longer match it. The digital | the digital signature will no longer match it. The digital | |||
| signature is unforgeable because one cannot be certain of | signature is unforgeable because one cannot be certain of | |||
| correctly creating or changing the signature without knowing the | correctly creating or changing the signature without knowing the | |||
| skipping to change at page 98, line 30 ¶ | skipping to change at page 100, line 12 ¶ | |||
| Tutorial: A v3 X.509 public-key certificate may have a | Tutorial: A v3 X.509 public-key certificate may have a | |||
| "cRLDistributionPoints" extension that names places to get CRLs on | "cRLDistributionPoints" extension that names places to get CRLs on | |||
| which the certificate might be listed. (See: certificate profile.) | which the certificate might be listed. (See: certificate profile.) | |||
| A CRL obtained from a distribution point may (a) cover either all | A CRL obtained from a distribution point may (a) cover either all | |||
| reasons for which a certificate might be revoked or only some of | reasons for which a certificate might be revoked or only some of | |||
| the reasons, (b) be issued by either the authority that signed the | the reasons, (b) be issued by either the authority that signed the | |||
| certificate or some other authority, and (c) contain revocation | certificate or some other authority, and (c) contain revocation | |||
| entries for only a subset of the full set of certificates issued | entries for only a subset of the full set of certificates issued | |||
| by one CA or (d) contain revocation entries for multiple CAs. | by one CA or (d) contain revocation entries for multiple CAs. | |||
| $ DKIM | ||||
| (I) See: Domain Keys Identified Mail. | ||||
| $ DMZ | $ DMZ | |||
| (D) See: demilitarized zone. | (D) See: demilitarized zone. | |||
| $ DN | $ DN | |||
| (N) See: distinguished name. | (N) See: distinguished name. | |||
| $ DNS | $ DNS | |||
| (I) See: Domain Name System. | (I) See: Domain Name System. | |||
| $ doctrine | $ doctrine | |||
| skipping to change at page 99, line 46 ¶ | skipping to change at page 101, line 33 ¶ | |||
| whose certificates are signed by the CA. | whose certificates are signed by the CA. | |||
| 5. (I) /Internet/ That part of the tree-structured name space of | 5. (I) /Internet/ That part of the tree-structured name space of | |||
| the DNS that is at or below the name that specifies the domain. A | the DNS that is at or below the name that specifies the domain. A | |||
| domain is a subdomain of another domain if it is contained within | domain is a subdomain of another domain if it is contained within | |||
| that domain. For example, D.C.B.A is a subdomain of C.B.A | that domain. For example, D.C.B.A is a subdomain of C.B.A | |||
| 6. (O) /OSI/ An administrative partition of a complex distributed | 6. (O) /OSI/ An administrative partition of a complex distributed | |||
| OSI system. | OSI system. | |||
| $ Domain Keys Identified Mail (DKIM) | ||||
| (I) A protocol, which is being specified by the IETF working group | ||||
| of the same name, to provide data integrity and domain-level (see: | ||||
| DNS, domain name) data origin authentication for Internet mail | ||||
| messages. (Compare: PEM.) | ||||
| Tutorial: DKIM employs asymmetric cryptography to create a digital | ||||
| signature for an Internet email message's body and selected | ||||
| headers (see RFC 1822), and the signature is then carried in a | ||||
| header of the message. A recipient of the message can verify the | ||||
| signature and, thereby, authenticate the identity of the | ||||
| originating domain and the integrity of the signed content, by | ||||
| using a public key belonging to the domain. The key can be | ||||
| obtained from the DNS. | ||||
| $ domain name | $ domain name | |||
| (I) The style of identifier that is defined for subtrees in the | (I) The style of identifier that is defined for subtrees in the | |||
| Internet DNS -- i.e., a sequence of case-insensitive ASCII labels | Internet DNS -- i.e., a sequence of case-insensitive ASCII labels | |||
| separated by dots (e.g., "bbn.com") -- and also is used in other | separated by dots (e.g., "bbn.com") -- and also is used in other | |||
| types of Internet identifiers, such as host names (e.g., | types of Internet identifiers, such as host names (e.g., | |||
| "rosslyn.bbn.com"), mailbox names (e.g., "rshirey@bbn.com.") and | "rosslyn.bbn.com"), mailbox names (e.g., "rshirey@bbn.com.") and | |||
| URLs (e.g., "http://www.rosslyn.bbn.com./foo"). (See: DN, domain.) | URLs (e.g., "http://www.rosslyn.bbn.com./foo"). (See: domain. | |||
| Compare: DN.) | ||||
| Tutorial: The name space of the DNS is a tree structure in which | Tutorial: The name space of the DNS is a tree structure in which | |||
| each node and leaf holds records describing a resource. Each node | each node and leaf holds records describing a resource. Each node | |||
| has a label. The domain name of a node is the list of labels on | has a label. The domain name of a node is the list of labels on | |||
| the path from the node to the root of the tree. The labels in a | the path from the node to the root of the tree. The labels in a | |||
| domain name are printed or read left to right, from the most | domain name are printed or read left to right, from the most | |||
| specific (lowest, farthest from the root) to the least specific | specific (lowest, farthest from the root) to the least specific | |||
| (highest, closest to the root), but the root's label is the null | (highest, closest to the root), but the root's label is the null | |||
| string. (See: country code.) | string. (See: country code.) | |||
| $ Domain Name System (DNS) | $ Domain Name System (DNS) | |||
| (I) The main Internet operations database, which is distributed | (I) The main Internet operations database, which is distributed | |||
| over a collection of servers and used by client software for | over a collection of servers and used by client software for | |||
| purposes such as (a) translating a domain name-style host name | purposes such as (a) translating a domain name-style host name | |||
| into an IP address (e.g., "rosslyn.bbn.com" translates to | into an IP address (e.g., "rosslyn.bbn.com" translates to | |||
| "192.1.7.10") and (b) locating a host that accepts mail for a | "192.1.7.10") and (b) locating a host that accepts mail for a | |||
| given mailbox address. (RFC 1034) | given mailbox address. (RFC 1034) (See: domain name.) | |||
| Tutorial: The DNS has three major components: | Tutorial: The DNS has three major components: | |||
| - Domain name space and resource records: Specifications for the | - Domain name space and resource records: Specifications for the | |||
| tree-structured domain name space, and data associated with the | tree-structured domain name space, and data associated with the | |||
| names. | names. | |||
| - Name servers: Programs that hold information about a subset of | - Name servers: Programs that hold information about a subset of | |||
| the tree's structure and data holdings, and also hold pointers | the tree's structure and data holdings, and also hold pointers | |||
| to other name servers that can provide information from any | to other name servers that can provide information from any | |||
| part of the tree. | part of the tree. | |||
| - Resolvers: Programs that extract information from name servers | - Resolvers: Programs that extract information from name servers | |||
| skipping to change at page 101, line 19 ¶ | skipping to change at page 103, line 22 ¶ | |||
| the matching dongle is attached. When the software runs, it | the matching dongle is attached. When the software runs, it | |||
| periodically queries the dongle and quits if the dongle does not | periodically queries the dongle and quits if the dongle does not | |||
| reply with the proper authentication information. Dongles were | reply with the proper authentication information. Dongles were | |||
| originally constructed as an EPROM (erasable programmable read- | originally constructed as an EPROM (erasable programmable read- | |||
| only memory) to be connected to a serial input-output port of a | only memory) to be connected to a serial input-output port of a | |||
| personal computer. | personal computer. | |||
| $ downgrade | $ downgrade | |||
| (I) /data security/ Reduce the security level of data (especially | (I) /data security/ Reduce the security level of data (especially | |||
| the classification level) without changing the information content | the classification level) without changing the information content | |||
| of the data. (See: regrade, upgrade. Compare: declassify.) | of the data. (Compare: downgrade.) | |||
| $ downgrade attack | ||||
| (I) A type of man-in-the-middle attack in which the attacker can | ||||
| cause two parties, that are negotiating a security association, to | ||||
| agree on a lower level of protection than the highest level that | ||||
| could have been supported by both of them. (Compare: downgrade.) | ||||
| $ draft RFC | $ draft RFC | |||
| (D) A preliminary, temporary version of a document that is | (D) A preliminary, temporary version of a document that is | |||
| intended to become an RFC. | intended to become an RFC. | |||
| Deprecated Term: ISDs SHOULD NOT use this term. The RFC series is | Deprecated Term: ISDs SHOULD NOT use this term. The RFC series is | |||
| archival in nature and consists only of documents in permanent | archival in nature and consists only of documents in permanent | |||
| form. A document that is intended to become an RFC usually needs | form. A document that is intended to become an RFC usually needs | |||
| to be published first as an "Internet-Draft" (RFC 2026). (See: | to be published first as an "Internet-Draft" (RFC 2026). (See: | |||
| "Draft Standard" under "Internet Standard".) | "Draft Standard" under "Internet Standard".) | |||
| skipping to change at page 102, line 28 ¶ | skipping to change at page 104, line 36 ¶ | |||
| public key may be used. (See: certificate profile.) | public key may be used. (See: certificate profile.) | |||
| $ duty | $ duty | |||
| (I) An attribute of a role that obligates an entity playing the | (I) An attribute of a role that obligates an entity playing the | |||
| role to perform one or more tasks, which usually are essential for | role to perform one or more tasks, which usually are essential for | |||
| the functioning of the system. [Sand] (Compare authorization, | the functioning of the system. [Sand] (Compare authorization, | |||
| privilege. See: role, billet.) | privilege. See: role, billet.) | |||
| $ e-cash | $ e-cash | |||
| (O) Electronic cash; money that is in the form of data and can be | (O) Electronic cash; money that is in the form of data and can be | |||
| used as a payment mechanism on the Internet. | used as a payment mechanism on the Internet. (See: IOTP.) | |||
| Usage: ISDs that use this term SHOULD state a definition for it | Usage: ISDs that use this term SHOULD state a definition for it | |||
| because many different types of electronic cash have been devised | because many different types of electronic cash have been devised | |||
| with a variety of security mechanisms. | with a variety of security mechanisms. | |||
| $ EAP | $ EAP | |||
| (I) See: Extensible Authentication Protocol. | (I) See: Extensible Authentication Protocol. | |||
| $ EAL | $ EAL | |||
| (O) See: evaluation assurance level. | (O) See: evaluation assurance level. | |||
| skipping to change at page 104, line 9 ¶ | skipping to change at page 106, line 16 ¶ | |||
| $ El Gamal algorithm | $ El Gamal algorithm | |||
| (N) An algorithm for asymmetric cryptography, invented in 1985 by | (N) An algorithm for asymmetric cryptography, invented in 1985 by | |||
| Taher El Gamal, that is based on the difficulty of calculating | Taher El Gamal, that is based on the difficulty of calculating | |||
| discrete logarithms and can be used for both encryption and | discrete logarithms and can be used for both encryption and | |||
| digital signatures. | digital signatures. | |||
| $ electronic codebook (ECB) | $ electronic codebook (ECB) | |||
| (N) An block cipher mode in which a plaintext block is used | (N) An block cipher mode in which a plaintext block is used | |||
| directly as input to the encryption algorithm and the resultant | directly as input to the encryption algorithm and the resultant | |||
| output block is used directly as cipher text [FP081]. (See: block | output block is used directly as cipher text [FP081]. (See: block | |||
| cipher.) | cipher, [SP38A].) | |||
| $ electronic commerce | $ electronic commerce | |||
| 1. (I) Business conducted through paperless exchanges of | 1. (I) Business conducted through paperless exchanges of | |||
| information, using electronic data interchange, electronic funds | information, using electronic data interchange, electronic funds | |||
| transfer (EFT), electronic mail, computer bulletin boards, | transfer (EFT), electronic mail, computer bulletin boards, | |||
| facsimile, and other paperless technologies. | facsimile, and other paperless technologies. | |||
| 2. (O) /SET/ "The exchange of goods and services for payment | 2. (O) /SET/ "The exchange of goods and services for payment | |||
| between the cardholder and merchant when some or all of the | between the cardholder and merchant when some or all of the | |||
| transaction is performed via electronic communication." [SET2] | transaction is performed via electronic communication." [SET2] | |||
| skipping to change at page 105, line 10 ¶ | skipping to change at page 107, line 17 ¶ | |||
| current consensus on its definition; and some uses and definitions | current consensus on its definition; and some uses and definitions | |||
| may be proprietary. Meanings range from virtual wallets | may be proprietary. Meanings range from virtual wallets | |||
| implemented by data structures to physical wallets implemented by | implemented by data structures to physical wallets implemented by | |||
| cryptographic tokens. (See: Deprecated Usage under "Green Book".) | cryptographic tokens. (See: Deprecated Usage under "Green Book".) | |||
| $ elliptic curve cryptography (ECC) | $ elliptic curve cryptography (ECC) | |||
| (I) A type of asymmetric cryptography based on mathematics of | (I) A type of asymmetric cryptography based on mathematics of | |||
| groups that are defined by the points on a curve, where the curve | groups that are defined by the points on a curve, where the curve | |||
| is defined by a quadratic equation in a finite field. [Schn] | is defined by a quadratic equation in a finite field. [Schn] | |||
| Tutorial: The most efficient implementation of ECC is claimed to | Tutorial: ECC is based on mathematics different than that | |||
| be stronger per bit of key (against cryptanalysis that uses a | originally used to define the Diffie-Hellman-Merkle algorithm and | |||
| brute force attack) than any other known form of asymmetric | the DSA, but ECC can be used to define an algorithm for key | |||
| cryptography. ECC is based on mathematics different than the kinds | agreement that is an analog of Diffie-Hellman-Merkle [A9063] and | |||
| originally used to define the Diffie-Hellman algorithm and the | an algorithm for digital signature that is an analog of DSA | |||
| Digital Signature Algorithm, but ECC can be used to define an | [A9062]. The mathematical problem upon which ECC is based is | |||
| algorithm for key agreement that is an analog of Diffie-Hellman | believed to be more difficult than the problem upon which Diffie- | |||
| [A9063] and an algorithm for digital signature that is an analog | Hellman-Merkle is based and, therefore, that keys for ECC can be | |||
| of DSA [A9062]. (See: ECDSA.) | shorter for a comparable level of security. (See: ECDSA.) | |||
| $ Elliptic Curve Digital Signature Algorithm (ECDSA) | $ Elliptic Curve Digital Signature Algorithm (ECDSA) | |||
| (N) A standard [A9062] that is the analog, in elliptic curve | (N) A standard [A9062] that is the analog, in elliptic curve | |||
| cryptography, of the Digital Signature Algorithm. | cryptography, of the Digital Signature Algorithm. | |||
| $ emanation | $ emanation | |||
| (I) An signal (e.g., electromagnetic or acoustic) that is emitted | (I) An signal (e.g., electromagnetic or acoustic) that is emitted | |||
| by a system (e.g., through radiation or conductance) as a | by a system (e.g., through radiation or conductance) as a | |||
| consequence (i.e., byproduct) of the system's operation, and that | consequence (i.e., byproduct) of the system's operation, and that | |||
| may contain information. (See: emanations security.) | may contain information. (See: emanations security.) | |||
| $ emanations analysis | ||||
| (I) /threat action/ See: secondary definition under | ||||
| "interception". | ||||
| $ emanations security (EMSEC) | $ emanations security (EMSEC) | |||
| (I) Physical security measures to protect against data compromise | (I) Physical security measures to protect against data compromise | |||
| that could occur because of emanations that might be received and | that could occur because of emanations that might be received and | |||
| read by an unauthorized party. (See: emanation, TEMPEST.) | read by an unauthorized party. (See: emanation, TEMPEST.) | |||
| Usage: Refers both to preventing or limiting emanations from a | Usage: Refers both to preventing or limiting emanations from a | |||
| system and to preventing or limiting the ability of unauthorized | system and to preventing or limiting the ability of unauthorized | |||
| parties to receive the emissions. | parties to receive the emissions. | |||
| $ embedded cryptography | $ embedded cryptography | |||
| skipping to change at page 107, line 23 ¶ | skipping to change at page 109, line 34 ¶ | |||
| for "encrypt"; encoding is not always meant to conceal meaning. | for "encrypt"; encoding is not always meant to conceal meaning. | |||
| $ encrypt | $ encrypt | |||
| (I) Cryptographically transform data to produce cipher text. (See: | (I) Cryptographically transform data to produce cipher text. (See: | |||
| encryption. Compare: seal.) | encryption. Compare: seal.) | |||
| $ encryption | $ encryption | |||
| 1. (I) Cryptographic transformation of data (called "plain text") | 1. (I) Cryptographic transformation of data (called "plain text") | |||
| into a different form (called "cipher text") that conceals the | into a different form (called "cipher text") that conceals the | |||
| data's original meaning and prevents the original form from being | data's original meaning and prevents the original form from being | |||
| used. If the transformation is reversible, the corresponding | used. The corresponding reverse process is "decryption", a | |||
| reversal process is called "decryption", which is a transformation | transformation that restores encrypted data to its original form. | |||
| that restores encrypted data to its original state. (See: | (See: cryptography.) | |||
| cryptography.) | ||||
| 2. (O) "The cryptographic transformation of data to produce | 2. (O) "The cryptographic transformation of data to produce | |||
| ciphertext." [I7498-2] | ciphertext." [I7498-2] | |||
| Usage: For this concept, ISDs SHOULD use the verb "to encrypt" | Usage: For this concept, ISDs SHOULD use the verb "to encrypt" | |||
| (and related variations: encryption, decrypt, and decryption). | (and related variations: encryption, decrypt, and decryption). | |||
| However, because of cultural biases involving human burial, some | However, because of cultural biases involving human burial, some | |||
| international documents (particularly ISO and CCITT standards) | international documents (particularly ISO and CCITT standards) | |||
| avoid "to encrypt" and instead use the verb "to encipher" (and | avoid "to encrypt" and instead use the verb "to encipher" (and | |||
| related variations: encipherment, decipher, decipherment). | related variations: encipherment, decipher, decipherment). | |||
| skipping to change at page 107, line 51 ¶ | skipping to change at page 110, line 9 ¶ | |||
| superencryption.) | superencryption.) | |||
| Encryption and decryption involve a mathematical algorithm for | Encryption and decryption involve a mathematical algorithm for | |||
| transforming data. In addition to the data to be transformed, the | transforming data. In addition to the data to be transformed, the | |||
| algorithm has one or more inputs that are control parameters: (a) | algorithm has one or more inputs that are control parameters: (a) | |||
| a key that varies the transformation and, in some cases, (b) an IV | a key that varies the transformation and, in some cases, (b) an IV | |||
| that establishes the starting state of the algorithm. | that establishes the starting state of the algorithm. | |||
| $ encryption certificate | $ encryption certificate | |||
| (I) A public-key certificate that contains a public key that is | (I) A public-key certificate that contains a public key that is | |||
| intended to be used for decrypting data, rather than for verifying | intended to be used for encrypting data, rather than for verifying | |||
| digital signatures or performing other cryptographic functions. | digital signatures or performing other cryptographic functions. | |||
| Tutorial: A v3 X.509 public-key certificate may have a "keyUsage" | Tutorial: A v3 X.509 public-key certificate may have a "keyUsage" | |||
| extension that indicates the purpose for which the certified | extension that indicates the purpose for which the certified | |||
| public key is intended. (See: certificate profile.) | public key is intended. (See: certificate profile.) | |||
| $ end cryptographic unit (ECU) | $ end cryptographic unit (ECU) | |||
| 1. (N) Final destination device into which a key is loaded for | 1. (N) Final destination device into which a key is loaded for | |||
| operational use. | operational use. | |||
| skipping to change at page 109, line 14 ¶ | skipping to change at page 111, line 25 ¶ | |||
| an end system is called a "host". | an end system is called a "host". | |||
| $ end-to-end encryption | $ end-to-end encryption | |||
| (I) Continuous protection of data that flows between two points in | (I) Continuous protection of data that flows between two points in | |||
| a network, effected by encrypting data when it leaves its source, | a network, effected by encrypting data when it leaves its source, | |||
| keeping it encrypted while it passes through any intermediate | keeping it encrypted while it passes through any intermediate | |||
| computers (such as routers), and decrypting it only when it | computers (such as routers), and decrypting it only when it | |||
| arrives at the intended final destination. (See: wiretapping. | arrives at the intended final destination. (See: wiretapping. | |||
| Compare: link encryption.) | Compare: link encryption.) | |||
| Examples: BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS, SILS. | Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS, | |||
| SILS, SSH, SSL, TLS. | ||||
| Tutorial: When two points are separated by multiple communication | Tutorial: When two points are separated by multiple communication | |||
| links that are connected by one or more intermediate relays, end- | links that are connected by one or more intermediate relays, end- | |||
| to-end encryption enables the source and destination systems to | to-end encryption enables the source and destination systems to | |||
| protect their communications without depending on the intermediate | protect their communications without depending on the intermediate | |||
| systems to provide the protection. | systems to provide the protection. | |||
| $ end user | $ end user | |||
| 1. (I) /information system/ A system entity, usually a human | 1. (I) /information system/ A system entity, usually a human | |||
| individual, that makes use of system resources, primarily for | individual, that makes use of system resources, primarily for | |||
| skipping to change at page 110, line 16 ¶ | skipping to change at page 112, line 26 ¶ | |||
| number of bits) of the amount of information in a message; i.e., | number of bits) of the amount of information in a message; i.e., | |||
| the minimum number of bits needed to encode all possible meanings | the minimum number of bits needed to encode all possible meanings | |||
| of that message. [Schn] (See: uncertainty.) | of that message. [Schn] (See: uncertainty.) | |||
| $ ephemeral | $ ephemeral | |||
| (I) /adjective/ Refers to a cryptographic key or other | (I) /adjective/ Refers to a cryptographic key or other | |||
| cryptographic parameter or data object that is short-lived, | cryptographic parameter or data object that is short-lived, | |||
| temporary, or used one time. (See: session key. Compare: static.) | temporary, or used one time. (See: session key. Compare: static.) | |||
| $ erase | $ erase | |||
| (I) Delete magnetically stored data in such a way that the data is | 1. (I) Delete stored data. (See: sanitize, zeroize.) | |||
| irretrievable by ordinary means, but might be recovered using | ||||
| laboratory methods. [C4009] (Compare: purge.) | 2. (O) /U.S. Government/ Delete magnetically stored data in such a | |||
| way that the data cannot be recovered by ordinary means, but might | ||||
| be recoverable by laboratory methods. [C4009] (Compare: /U.S. | ||||
| Government/ purge.) | ||||
| $ error detection code | $ error detection code | |||
| (I) A checksum designed to detect, but not correct, accidental | (I) A checksum designed to detect, but not correct, accidental | |||
| (i.e., unintentional) changes in data. | (i.e., unintentional) changes in data. | |||
| $ Escrowed Encryption Standard (EES) | $ Escrowed Encryption Standard (EES) | |||
| (N) A U.S. Government standard [FP185] that specifies how to use a | (N) A U.S. Government standard [FP185] that specifies how to use a | |||
| symmetric encryption algorithm (SKIPJACK) and create a Law | symmetric encryption algorithm (SKIPJACK) and create a Law | |||
| Enforcement Access Field (LEAF) for implementing part of a key | Enforcement Access Field (LEAF) for implementing part of a key | |||
| escrow system that enables decryption of telecommunications when | escrow system that enables decryption of telecommunications when | |||
| skipping to change at page 111, line 19 ¶ | skipping to change at page 113, line 35 ¶ | |||
| 2. (N) /capitalized, U.S. Government/ The Evaluated Products List | 2. (N) /capitalized, U.S. Government/ The Evaluated Products List | |||
| (http://www.radium.ncsc.mil/tpep/epl/) contains items that have | (http://www.radium.ncsc.mil/tpep/epl/) contains items that have | |||
| been evaluated against the TCSEC by the NCSC, or against the | been evaluated against the TCSEC by the NCSC, or against the | |||
| Common Criteria by the NIAP or one of its partner agencies in | Common Criteria by the NIAP or one of its partner agencies in | |||
| another county. This List forms Chapter 4 of NSA's "Information | another county. This List forms Chapter 4 of NSA's "Information | |||
| Systems Security Products and Services Catalogue". [C4009] | Systems Security Products and Services Catalogue". [C4009] | |||
| $ evaluated system | $ evaluated system | |||
| (I) A system that has been evaluated against security criteria | (I) A system that has been evaluated against security criteria | |||
| such as the TCSEC or the Common Criteria. | (for example, against the TCSEC or against a profile based on the | |||
| Common Criteria). | ||||
| $ evaluation | $ evaluation | |||
| (I) Assessment of an information system against defined security | (I) Assessment of an information system against defined security | |||
| criteria, such as the TCSEC or the Common Criteria. (Compare: | criteria (for example, against the TCSEC or against a profile | |||
| certification.) | based on the Common Criteria). (Compare: certification.) | |||
| $ evaluation assurance level (EAL) | $ evaluation assurance level (EAL) | |||
| (N) A predefined package of assurance components that represents a | (N) A predefined package of assurance components that represents a | |||
| point on the Common Criteria's scale for rating confidence in the | point on the Common Criteria's scale for rating confidence in the | |||
| security of information technology products and systems. | security of information technology products and systems. | |||
| Tutorial: The Common Criteria defines a scale of seven, | Tutorial: The Common Criteria defines a scale of seven, | |||
| hierarchically ordered EALs for rating a TOE. From highest to | hierarchically ordered EALs for rating a TOE. From highest to | |||
| lowest, they are as follows: | lowest, they are as follows: | |||
| - EAL7. Formally verified design and tested. | - EAL7. Formally verified design and tested. | |||
| skipping to change at page 111, line 40 ¶ | skipping to change at page 114, line 4 ¶ | |||
| Tutorial: The Common Criteria defines a scale of seven, | Tutorial: The Common Criteria defines a scale of seven, | |||
| hierarchically ordered EALs for rating a TOE. From highest to | hierarchically ordered EALs for rating a TOE. From highest to | |||
| lowest, they are as follows: | lowest, they are as follows: | |||
| - EAL7. Formally verified design and tested. | - EAL7. Formally verified design and tested. | |||
| - EAL6. Semiformally verified design and tested. | - EAL6. Semiformally verified design and tested. | |||
| - EAL5. Semiformally designed and tested. | - EAL5. Semiformally designed and tested. | |||
| - EAL4. Methodically designed, tested, and reviewed. | - EAL4. Methodically designed, tested, and reviewed. | |||
| - EAL3. Methodically tested and checked. | - EAL3. Methodically tested and checked. | |||
| - EAL2. Structurally tested. | - EAL2. Structurally tested. | |||
| - EAL1. Functionally tested. | - EAL1. Functionally tested. | |||
| An EAL is a consistent, baseline set of requirements. The increase | An EAL is a consistent, baseline set of requirements. The increase | |||
| in assurance from EAL to EAL is accomplished by substituting | in assurance from EAL to EAL is accomplished by substituting | |||
| higher assurance components (i.e. criteria of increasing rigor, | higher assurance components (i.e. criteria of increasing rigor, | |||
| scope, or depth) from seven assurance classes: (a) configuration | scope, or depth) from seven assurance classes: (a) configuration | |||
| management, (b) delivery and operation, (c) development, (d) | management, (b) delivery and operation, (c) development, (d) | |||
| guidance documents, (e) life cycle support, (f) tests, and (g) | guidance documents, (e) life cycle support, (f) tests, and (g) | |||
| vulnerability assessment. | vulnerability assessment. | |||
| The EALs were developed with the goal of preserving concepts of | The EALs were developed with the goal of preserving concepts of | |||
| assurance that were adopted from earlier criteria, so that results | assurance that were adopted from earlier criteria, so that results | |||
| of previous evaluations would remain relevant. For example, EALs | of previous evaluations would remain relevant. For example, EALs | |||
| levels 2-7 are generally equivalent to the assurance portions of | levels 2-7 are generally equivalent to the assurance portions of | |||
| the TCSEC C2-A1 scale. However, this equivalency should be used | the TCSEC C2-A1 scale. However, this equivalency should be used | |||
| with caution. The levels do not derive assurance in the same | with caution. The levels do not derive assurance in the same | |||
| manner, and exact mappings do not exist. | manner, and exact mappings do not exist. | |||
| $ expire | $ expire | |||
| (I) See: certificate expiration. | (I) /credential/ Cease to be valid (i.e., change from being valid | |||
| to being invalid) because its assigned lifetime has been exceeded. | ||||
| (See: certificate expiration.) | ||||
| $ exposure | $ exposure | |||
| (I) A type of threat action whereby sensitive data is directly | (I) A type of threat action whereby sensitive data is directly | |||
| released to an unauthorized entity. (See: unauthorized | released to an unauthorized entity. (See: unauthorized | |||
| disclosure.) | disclosure.) | |||
| Usage: This type of threat action includes the following subtypes: | Usage: This type of threat action includes the following subtypes: | |||
| - "Deliberate Exposure": Intentional release of sensitive data to | - "Deliberate Exposure": Intentional release of sensitive data to | |||
| an unauthorized entity. | an unauthorized entity. | |||
| - "Scavenging": Searching through data residue in a system to | - "Scavenging": Searching through data residue in a system to | |||
| gain unauthorized knowledge of sensitive data. | gain unauthorized knowledge of sensitive data. | |||
| - "Human error": In context of exposure, human action or inaction | - "Human error": /exposure/ Human action or inaction that | |||
| that unintentionally results in an entity gaining unauthorized | unintentionally results in an entity gaining unauthorized | |||
| knowledge of sensitive data. (Compare: corruption, | knowledge of sensitive data. (Compare: corruption, | |||
| incapacitation.) | incapacitation.) | |||
| - "Hardware or software error": In context of exposure, system | - "Hardware or software error": /exposure/ System failure that | |||
| failure that unintentionally results in an entity gaining | unintentionally results in an entity gaining unauthorized | |||
| unauthorized knowledge of sensitive data. (Compare: corruption, | knowledge of sensitive data. (Compare: corruption, | |||
| incapacitation.) | incapacitation.) | |||
| $ Extended Security Option | $ Extended Security Option | |||
| (I) See: secondary definition under "IPSO". | (I) See: secondary definition under "IPSO". | |||
| $ Extensible Authentication Protocol (EAP) | $ Extensible Authentication Protocol (EAP) | |||
| (I) A extension framework for PPP that supports multiple, optional | (I) A extension framework for PPP that supports multiple, optional | |||
| authentication mechanisms, including cleartext passwords, | authentication mechanisms, including cleartext passwords, | |||
| challenge-response, and arbitrary dialog sequences. [R3748] | challenge-response, and arbitrary dialog sequences. [R3748] | |||
| (Compare: GSS-API, SASL.) | ||||
| Tutorial: This protocol is intended for use primarily by a host or | Tutorial: EAP typically runs directly over IPS data link protocols | |||
| router that connects to a network server via switched circuits or | or OSIRM Layer 2 protocols, i.e., without requiring IP. | |||
| dial-up lines. EAP typically runs directly over IPS data link | Originally, EAP was developed for use in PPP, by a host or router | |||
| protocols or OSIRM Layer 2 protocols, such as PPP or IEEE 802, | that connects to a network server via switched circuits or dial-up | |||
| without requiring IP. | lines. Today, EAP's domain of applicability includes other areas | |||
| of network access control; it is used in wired and wireless LANs | ||||
| with IEEE 802.1X, and in IPsec with IKEv2. EAP is conceptually | ||||
| related to other authentication mechanism frameworks, such as SASL | ||||
| and GSS-API. | ||||
| $ Extensible Markup Language (XML) | $ Extensible Markup Language (XML) | |||
| (N) A version of Standard Generalized Markup Language (ISO 8879), | (N) A version of Standard Generalized Markup Language (ISO 8879), | |||
| which separately represents both a document's content and its | which separately represents both a document's content and its | |||
| structure. XML was designed by W3C for use on the World Wide Web. | structure. XML was designed by W3C for use on the World Wide Web. | |||
| $ extension | $ extension | |||
| (I) A data item defined for optional inclusion in a v3 X.509 | (I) /protocol/ A data item or a mechanism that is defined in a | |||
| public-key certificate or a v2 X.509 CRL. | protocol to extend the protocol's basic or original functionality. | |||
| Tutorial: The formats defined in X.509 can be extended to provide | Tutorial: Many protocols have extension mechanisms, and the use of | |||
| these extension is usually optional. IP and X.509 are two examples | ||||
| of protocols that have optional extensions. In IP version 4, | ||||
| extensions are called "options", and some of the options have | ||||
| security purposes (see: IPSO). | ||||
| In X.509, certificate and CRL formats can be extended to provide | ||||
| methods for associating additional attributes with subjects and | methods for associating additional attributes with subjects and | |||
| public keys and for managing a certification hierarchy: | public keys and for managing a certification hierarchy: | |||
| - A "certificate extension": X.509 defines standard extensions | - A "certificate extension": X.509 defines standard extensions | |||
| that may be included in v3 certificates to provide additional | that may be included in v3 certificates to provide additional | |||
| key and security policy information, subject and issuer | key and security policy information, subject and issuer | |||
| attributes, and certification path constraints. | attributes, and certification path constraints. | |||
| - A "CRL extension": X.509 defines extensions that may be | - A "CRL extension": X.509 defines extensions that may be | |||
| included in v2 CRLs to provide additional issuer key and name | included in v2 CRLs to provide additional issuer key and name | |||
| information, revocation reasons and constraints, and | information, revocation reasons and constraints, and | |||
| information about distribution points and delta CRLs. | information about distribution points and delta CRLs. | |||
| skipping to change at page 113, line 33 ¶ | skipping to change at page 116, line 10 ¶ | |||
| Tutorial: An extranet can be implemented securely, either on the | Tutorial: An extranet can be implemented securely, either on the | |||
| Internet or using Internet technology, by constructing the | Internet or using Internet technology, by constructing the | |||
| extranet as a VPN. | extranet as a VPN. | |||
| $ extraction resistance | $ extraction resistance | |||
| (O) Ability of cryptographic equipment to resist efforts to | (O) Ability of cryptographic equipment to resist efforts to | |||
| extract keying material directly from the equipment (as opposed to | extract keying material directly from the equipment (as opposed to | |||
| gaining knowledge of keying material by cryptanalysis). [C4009] | gaining knowledge of keying material by cryptanalysis). [C4009] | |||
| $ extrusion detection | ||||
| (I) Monitoring for unauthorized transfers of sensitive information | ||||
| and other communications that originate inside a system's security | ||||
| perimeter and are directed toward the outside; i.e., roughly the | ||||
| opposite of "intrusion detection". | ||||
| $ fail-safe | $ fail-safe | |||
| (I) A mode of termination of system functions (when a failure | 1. (I) Synonym for "fail-secure". | |||
| occurs or is detected in the system) that automatically leaves | ||||
| system processes and components in a secure state. (See: failure | 2. (I) A mode of termination of system functions that prevents | |||
| control.) | damage to specified system resources and system entities (i.e., | |||
| specified data, property, and life) when a failure occurs or is | ||||
| detected in the system (but the failure still might cause a | ||||
| security compromise). (See: failure control.) | ||||
| Tutorial: Definitions 1 and 2 are opposite design alternatives. | ||||
| Therefore, ISDs SHOULD NOT use this term without providing a | ||||
| definition for it. If definition 1 is intended, ISDs can avoid | ||||
| ambiguity by using "fail-secure" instead. | ||||
| $ fail-secure | ||||
| (I) A mode of termination of system functions that prevents loss | ||||
| of secure state when a failure occurs or is detected in the system | ||||
| (but the failure still might cause damage to some system resource | ||||
| or system entity). (See: failure control. Compare: fail-safe.) | ||||
| $ fail-soft | $ fail-soft | |||
| (I) Selective termination of affected, non-essential system | (I) Selective termination of affected, non-essential system | |||
| functions when a failure occurs or is detected in the system. | functions when a failure occurs or is detected in the system. | |||
| (See: failure control.) | (See: failure control.) | |||
| $ failure control | $ failure control | |||
| (I) A methodology used to provide fail-safe or fail-soft | (I) A methodology used to provide fail-safe, fail-secure or fail- | |||
| termination and recovery of system functions. [FP039] | soft termination and recovery of system functions. [FP039] | |||
| $ fairness | $ fairness | |||
| (I) A property of an access protocol for a system resource whereby | (I) A property of an access protocol for a system resource whereby | |||
| the resource is made equitably or impartially available to all | the resource is made equitably or impartially available to all | |||
| eligible users. (RFC 3753) | eligible users. (RFC 3753) | |||
| Tutorial: Fairness can be used to defend against some types of | Tutorial: Fairness can be used to defend against some types of | |||
| denial-of-service attacks on a system connected to a network. | denial-of-service attacks on a system connected to a network. | |||
| However, this technique assumes that the system can properly | However, this technique assumes that the system can properly | |||
| receive and process inputs from the network. Therefore, the | receive and process inputs from the network. Therefore, the | |||
| skipping to change at page 114, line 48 ¶ | skipping to change at page 117, line 45 ¶ | |||
| tree is an attack tree. | tree is an attack tree. | |||
| $ FEAL | $ FEAL | |||
| (O) A family of symmetric block ciphers that was developed in | (O) A family of symmetric block ciphers that was developed in | |||
| Japan; uses a 64-bit block, keys of either 64 or 128 bits, and a | Japan; uses a 64-bit block, keys of either 64 or 128 bits, and a | |||
| variable number of rounds; and has been successfully attacked by | variable number of rounds; and has been successfully attacked by | |||
| cryptanalysts. [Schn] | cryptanalysts. [Schn] | |||
| $ Federal Information Processing Standards (FIPS) | $ Federal Information Processing Standards (FIPS) | |||
| (N) The Federal Information Processing Standards Publication (FIPS | (N) The Federal Information Processing Standards Publication (FIPS | |||
| PUB) series issued by NIST as technical guidelines for U.S. | PUB) series issued by NIST under the provisions of section 111(d) | |||
| Government procurements of information processing system equipment | of the Federal Property and Administrative Services Act of 1949 as | |||
| and services. [FP031, FP039, FP041, FP046, FP074, FP081, FP087, | amended by the Computer Security Act of 1987 (Public Law 100-235) | |||
| FP102, FP113, FP140, FP151, FP180, FP185, FP186, FP188, FP191, | as technical guidelines for U.S. Government procurements of | |||
| FP197] | information processing system equipment and services. (See: | |||
| "[FPxxx]" items in Section 5, Informative References.) | ||||
| Tutorial: Issued under the provisions of section 111(d) of the | ||||
| Federal Property and Administrative Services Act of 1949 as | ||||
| amended by the Computer Security Act of 1987 (Public Law 100-235). | ||||
| $ Federal Public-key Infrastructure (FPKI) | $ Federal Public-key Infrastructure (FPKI) | |||
| (O) A PKI being planned to establish facilities, specifications, | (O) A PKI being planned to establish facilities, specifications, | |||
| and policies needed by the U.S. Government to use public-key | and policies needed by the U.S. Government to use public-key | |||
| certificates in systems involving unclassified but sensitive | certificates in systems involving unclassified but sensitive | |||
| applications and interactions between Federal agencies as well as | applications and interactions between Federal agencies as well as | |||
| with entities of other branches of the Federal Government, state, | with entities of other branches of the Federal Government, state, | |||
| and local governments, business, and the public. [FPKI] | and local governments, business, and the public. [FPKI] | |||
| $ Federal Standard 1027 | $ Federal Standard 1027 | |||
| skipping to change at page 118, line 4 ¶ | skipping to change at page 120, line 50 ¶ | |||
| definition 2; not every flaw is a vulnerability. | definition 2; not every flaw is a vulnerability. | |||
| $ flaw hypothesis methodology | $ flaw hypothesis methodology | |||
| (I) An evaluation or attack technique in which specifications and | (I) An evaluation or attack technique in which specifications and | |||
| documentation for a system are analyzed to hypothesize flaws in | documentation for a system are analyzed to hypothesize flaws in | |||
| the system. The list of hypothetical flaws is prioritized on the | the system. The list of hypothetical flaws is prioritized on the | |||
| basis of the estimated probability that a flaw exists and, | basis of the estimated probability that a flaw exists and, | |||
| assuming it does, on the ease of exploiting it and the extent of | assuming it does, on the ease of exploiting it and the extent of | |||
| control or compromise it would provide. The prioritized list is | control or compromise it would provide. The prioritized list is | |||
| used to direct a penetration test or attack against the system. | used to direct a penetration test or attack against the system. | |||
| [NCS04] (See: fault tree, flaw.) | [NCS04] (See: fault tree, flaw.) | |||
| $ flooding | $ flooding | |||
| 1. (I) An attack that attempts to cause a failure in a system by | 1. (I) An attack that attempts to cause a failure in a system by | |||
| providing more input than the system can process properly. (See: | providing more input than the system can process properly. (See: | |||
| denial of service, fairness. Compare: jamming.) | denial of service, fairness. Compare: jamming.) | |||
| Tutorial: Flooding uses "overload" as a type of "obstruction" | Tutorial: Flooding uses "overload" as a type of "obstruction" | |||
| intended to cause "disruption". | intended to cause "disruption". | |||
| 2. (I) The process of delivering data or control messages to every | 2. (I) The process of delivering data or control messages to every | |||
| node of a network. (RFC 3753) | node of a network. (RFC 3753) | |||
| $ flow analysis | $ flow analysis | |||
| (I) An analysis performed on a nonprocedural, formal, system | (I) An analysis performed on a nonprocedural, formal, system | |||
| specification that locates potential flows of information between | specification that locates potential flows of information between | |||
| system variables. By assigning security levels to the variables, | system variables. By assigning security levels to the variables, | |||
| the analysis can find some types of covert channels. [Huff] | the analysis can find some types of covert channels. [Huff] | |||
| $ flow control | $ flow control | |||
| 1. (I) A procedure or technique to ensure that information | 1. (I) /data security/ A procedure or technique to ensure that | |||
| transfers within a system are not made from one security level to | information transfers within a system are not made from one | |||
| another security level, and especially not from a higher level to | security level to another security level, and especially not from | |||
| a lower level. [Denns] (See: covert channel, confinement property, | a higher level to a lower level. [Denns] (See: covert channel, | |||
| information flow policy, simple security property.) | confinement property, information flow policy, simple security | |||
| property.) | ||||
| 2. (O) "A concept requiring that information transfers within a | 2. (O) /data security/ "A concept requiring that information | |||
| system be controlled so that information in certain types of | transfers within a system be controlled so that information in | |||
| objects cannot, via any channel within the system, flow to certain | certain types of objects cannot, via any channel within the | |||
| other types of objects." [NCSSG] | system, flow to certain other types of objects." [NCSSG] | |||
| $ For Official Use Only (FOUO) | $ For Official Use Only (FOUO) | |||
| (O) /U.S. DoD/ A U.S. Government designation for information that | (O) /U.S. DoD/ A U.S. Government designation for information that | |||
| has not been given a security classification pursuant to the | has not been given a security classification pursuant to the | |||
| criteria of an Executive Order dealing with national security, but | criteria of an Executive Order dealing with national security, but | |||
| which may be withheld from the public because disclosure would | which may be withheld from the public because disclosure would | |||
| cause a foreseeable harm to an interest protected by one of the | cause a foreseeable harm to an interest protected by one of the | |||
| exemptions stated in the Freedom of Information Act (Section 552 | exemptions stated in the Freedom of Information Act (Section 552 | |||
| of title 5, United States Code). (See: security label, security | of title 5, United States Code). (See: security label, security | |||
| marking. Compare: classified.) | marking. Compare: classified.) | |||
| skipping to change at page 119, line 18 ¶ | skipping to change at page 122, line 11 ¶ | |||
| $ formal model | $ formal model | |||
| (I) A security model that is formal. Example: Bell-LaPadula model. | (I) A security model that is formal. Example: Bell-LaPadula model. | |||
| [Land] (See: formal, security model.) | [Land] (See: formal, security model.) | |||
| $ formal proof | $ formal proof | |||
| (I) "A complete and convincing mathematical argument, presenting | (I) "A complete and convincing mathematical argument, presenting | |||
| the full logical justification for each step in the proof, for the | the full logical justification for each step in the proof, for the | |||
| truth of a theorem or set of theorems." [NCSSG] | truth of a theorem or set of theorems." [NCSSG] | |||
| $ formal specification | $ formal specification | |||
| (I) A specification of hardware or software functionality in a | (I) A precise description of the (intended) behavior of a system, | |||
| computer-readable language; usually a precise mathematical | usually written in a mathematical language, sometimes for the | |||
| description of the behavior of the system with the aim of | purpose of supporting formal verification through a correctness | |||
| providing a correctness proof. [Huff] (See: Affirm, Gypsy, HDM, | proof. [Huff] (See: Affirm, Gypsy, HDM, Ina Jo.) (See: formal.) | |||
| Ina Jo.) | ||||
| Tutorial: A formal specification can be written at any level of | ||||
| detail but is usually a top-level specification. | ||||
| $ formal top-level specification | ||||
| (I) "A top-level specification that is written in a formal | ||||
| mathematical language to allow theorems showing the correspondence | ||||
| of the system specification to its formal requirements to be | ||||
| hypothesized and formally proven." [NCS04] (See: formal | ||||
| specification.) | ||||
| $ formulary | $ formulary | |||
| (I) A technique for enabling a decision to grant or deny access to | (I) A technique for enabling a decision to grant or deny access to | |||
| be made dynamically at the time the access is attempted, rather | be made dynamically at the time the access is attempted, rather | |||
| than earlier when an access control list or ticket is created. | than earlier when an access control list or ticket is created. | |||
| $ FORTEZZA(trademark) | $ FORTEZZA(trademark) | |||
| (O) A registered trademark of NSA, used for a family of | (O) A registered trademark of NSA, used for a family of | |||
| interoperable security products that implement a NIST/NSA-approved | interoperable security products that implement a NIST/NSA-approved | |||
| suite of cryptographic algorithms for digital signature, hash, | suite of cryptographic algorithms for digital signature, hash, | |||
| skipping to change at page 119, line 53 ¶ | skipping to change at page 122, line 55 ¶ | |||
| than 100 members spanning the globe. Its mission includes: | than 100 members spanning the globe. Its mission includes: | |||
| - Provide members with technical information, tools, methods, | - Provide members with technical information, tools, methods, | |||
| assistance, and guidance. | assistance, and guidance. | |||
| - Coordinate proactive liaison activities and analytical support. | - Coordinate proactive liaison activities and analytical support. | |||
| - Encourage development of quality products and services. | - Encourage development of quality products and services. | |||
| - Improve national and international information security for | - Improve national and international information security for | |||
| government, private industry, academia, and the individual. | government, private industry, academia, and the individual. | |||
| - Enhance the image and status of the CSIRT community. | - Enhance the image and status of the CSIRT community. | |||
| $ forward secrecy | $ forward secrecy | |||
| See: public-key forward secrecy. | (I) See: perfect forward secrecy. | |||
| $ FOUO | $ FOUO | |||
| (O) See: For Official Use Only. | (O) See: For Official Use Only. | |||
| $ FPKI | $ FPKI | |||
| (O) See: Federal Public-Key Infrastructure. | (O) See: Federal Public-Key Infrastructure. | |||
| $ fraggle attack | $ fraggle attack | |||
| (D) /slang/ A synonym for "smurf attack". | (D) /slang/ A synonym for "smurf attack". | |||
| skipping to change at page 120, line 28 ¶ | skipping to change at page 123, line 31 ¶ | |||
| $ frequency hopping | $ frequency hopping | |||
| (N) "Repeated switching of frequencies during radio transmission | (N) "Repeated switching of frequencies during radio transmission | |||
| according to a specified algorithm." [C4009] (See: spread | according to a specified algorithm." [C4009] (See: spread | |||
| spectrum.) | spectrum.) | |||
| Tutorial: Frequency hopping is a TRANSEC technique to minimize the | Tutorial: Frequency hopping is a TRANSEC technique to minimize the | |||
| potential for unauthorized interception or jamming. | potential for unauthorized interception or jamming. | |||
| $ fresh | $ fresh | |||
| (I) Original; not yet processed. | (I) Recently generated; not replayed from some earlier interaction | |||
| of the protocol. | ||||
| Usage: Describes data contained in a PDU that is received for the | Usage: Describes data contained in a PDU that is received and | |||
| first time. (See: liveness, nonce, replay attack.) | processed for the first time. (See: liveness, nonce, replay | |||
| attack.) | ||||
| $ FTP | $ FTP | |||
| (I) See: File Transfer Protocol. | (I) See: File Transfer Protocol. | |||
| $ gateway | $ gateway | |||
| (I) An intermediate system (interface, relay) that attaches to two | (I) An intermediate system (interface, relay) that attaches to two | |||
| (or more) computer networks that have similar functions but | (or more) computer networks that have similar functions but | |||
| dissimilar implementations and that enables either one-way or two- | dissimilar implementations and that enables either one-way or two- | |||
| way communication between the networks. (See: bridge, firewall, | way communication between the networks. (See: bridge, firewall, | |||
| guard, internetwork, proxy server, router, and subnetwork.) | guard, internetwork, proxy server, router, and subnetwork.) | |||
| skipping to change at page 121, line 18 ¶ | skipping to change at page 124, line 22 ¶ | |||
| $ GeldKarte | $ GeldKarte | |||
| (O) A smartcard-based, electronic money system that is maintained | (O) A smartcard-based, electronic money system that is maintained | |||
| by the German banking industry, incorporates cryptography, and can | by the German banking industry, incorporates cryptography, and can | |||
| be used to make payments via the Internet. (See: IOTP.) | be used to make payments via the Internet. (See: IOTP.) | |||
| $ GeneralizedTime | $ GeneralizedTime | |||
| (N) The ASN.1 data type "GeneralizedTime" (ISO 8601) contains a | (N) The ASN.1 data type "GeneralizedTime" (ISO 8601) contains a | |||
| calendar date (YYYYMMDD) and a time of day, which is either (a) | calendar date (YYYYMMDD) and a time of day, which is either (a) | |||
| the local time, (b) the Coordinated Universal Time, or (c) both | the local time, (b) the Coordinated Universal Time, or (c) both | |||
| the local time and an offset that enables Coordinated Universal | the local time and an offset that enables Coordinated Universal | |||
| Time to be calculated. (See: Coordinated Universal Time, UTCTime.) | Time to be calculated. (See: Coordinated Universal Time. Compare: | |||
| UTCTime.) | ||||
| $ Generic Security Service Application Program Interface (GSS-API) | $ Generic Security Service Application Program Interface (GSS-API) | |||
| (I) An Internet Standard protocol [R2078] that specifies calling | (I) An Internet Standard protocol [R2078] that specifies calling | |||
| conventions by which an application (typically another | conventions by which an application (typically another | |||
| communication protocol) can obtain authentication, integrity, and | communication protocol) can obtain authentication, integrity, and | |||
| confidentiality security services independently of the underlying | confidentiality security services independently of the underlying | |||
| security mechanisms and technologies, thus enabling the | security mechanisms and technologies, thus enabling the | |||
| application source code to be ported to different environments. | application source code to be ported to different environments. | |||
| (Compare: EAP, SASL.) | ||||
| Tutorial: "A GSS-API caller accepts tokens provided to it by its | Tutorial: "A GSS-API caller accepts tokens provided to it by its | |||
| local GSS-API implementation and transfers the tokens to a peer on | local GSS-API implementation and transfers the tokens to a peer on | |||
| a remote system; that peer passes the received tokens to its local | a remote system; that peer passes the received tokens to its local | |||
| GSS-API implementation for processing. The security services | GSS-API implementation for processing. The security services | |||
| available through GSS-API in this fashion are implementable (and | available through GSS-API in this fashion are implementable (and | |||
| have been implemented) over a range of underlying mechanisms based | have been implemented) over a range of underlying mechanisms based | |||
| on [symmetric] and [asymmetric cryptography]." [R2078] | on [symmetric] and [asymmetric cryptography]." [R2078] | |||
| $ geopolitical certificate authority (GCA) | $ geopolitical certificate authority (GCA) | |||
| skipping to change at page 121, line 48 ¶ | skipping to change at page 124, line 54 ¶ | |||
| is certified by a BCA and that may certify cardholder CAs, | is certified by a BCA and that may certify cardholder CAs, | |||
| merchant CAs, and payment gateway CAs. Using GCAs enables a brand | merchant CAs, and payment gateway CAs. Using GCAs enables a brand | |||
| to distribute responsibility for managing certificates to | to distribute responsibility for managing certificates to | |||
| geographic or political regions, so that brand policies can vary | geographic or political regions, so that brand policies can vary | |||
| between regions as needed. | between regions as needed. | |||
| $ GIG | $ GIG | |||
| (O) See: Global Information Grid. | (O) See: Global Information Grid. | |||
| $ Global Information Grid (GIG) | $ Global Information Grid (GIG) | |||
| (O) /U.S. DoD/ "A globally interconnected, end-to-end set of | (O) /U.S. DoD/ The GIG is "a globally interconnected, end-to-end | |||
| information capabilities, associated processes and personnel for | set of information capabilities, associated processes and | |||
| collecting, processing, storing, disseminating, and managing | personnel for collecting, processing, storing, disseminating, and | |||
| information on demand to warfighters, policy makers, and support | managing information on demand to warfighters, policy makers, and | |||
| personnel." [IATF] Usage: Formerly called the DII. | support personnel." [IATF] Usage: Formerly referred to as the DII. | |||
| $ good engineering practice(s) | $ good engineering practice(s) | |||
| (N) A term used to specify or characterize design, implementation, | (N) A term used to specify or characterize design, implementation, | |||
| installation, or operating practices for an information system, | installation, or operating practices for an information system, | |||
| when a more explicit specification is not possible. Generally | when a more explicit specification is not possible. Generally | |||
| understood to refer to the state of the engineering art for | understood to refer to the state of the engineering art for | |||
| commercial systems that have problems and solutions equivalent to | commercial systems that have problems and solutions equivalent to | |||
| the system in question. | the system in question. | |||
| $ granularity | $ granularity | |||
| 1. (N) "Relative fineness to which an access control mechanism can | 1. (N) "Relative fineness to which an access control mechanism can | |||
| be adjusted." [C4009] | be adjusted." [C4009] | |||
| 2. (O) "The size of the smallest protectable unit of information" | 2. (O) "The size of the smallest protectable unit of information" | |||
| in a trusted computer system. [Huff] | in a trusted system. [Huff] | |||
| $ Green Book | $ Green Book | |||
| (D) /slang/ Synonym for "Defense Password Management Guideline" | (D) /slang/ Synonym for "Defense Password Management Guideline" | |||
| [CSC2]. | [CSC2]. | |||
| Deprecated Term: Except as an explanatory appositive, ISDs SHOULD | Deprecated Term: Except as an explanatory appositive, ISDs SHOULD | |||
| NOT use this term, regardless of the associated definition. | NOT use this term, regardless of the associated definition. | |||
| Instead, use the full proper name of the document or, in | Instead, use the full proper name of the document or, in | |||
| subsequent references, a conventional abbreviation. (See: Rainbow | subsequent references, a conventional abbreviation. (See: Rainbow | |||
| Series.) | Series.) | |||
| skipping to change at page 122, line 44 ¶ | skipping to change at page 125, line 51 ¶ | |||
| standards. | standards. | |||
| - "PostScript Language Program Design", Adobe Systems, Addison- | - "PostScript Language Program Design", Adobe Systems, Addison- | |||
| Wesley, 1988. | Wesley, 1988. | |||
| - IEEE 1003.1 POSIX Operating Systems Interface. | - IEEE 1003.1 POSIX Operating Systems Interface. | |||
| - "Smalltalk-80: Bits of History, Words of Advice", Glenn | - "Smalltalk-80: Bits of History, Words of Advice", Glenn | |||
| Krasner, Addison-Wesley, 1983. | Krasner, Addison-Wesley, 1983. | |||
| - "X/Open Compatibility Guide". | - "X/Open Compatibility Guide". | |||
| - A particular CD-ROM format developed by Phillips. | - A particular CD-ROM format developed by Phillips. | |||
| $ Group Domain of Interpretation (GDOI) | $ Group Domain of Interpretation (GDOI) | |||
| (I) An ISAMKP/IKE domain of interpretation for group key | (I) An ISAKMP/IKE domain of interpretation for group key | |||
| management; i.e., a phase 2 protocol in ISAKMP. [R3547] (See: | management; i.e., a phase 2 protocol in ISAKMP. [R3547] (See: | |||
| secure multicast.) | secure multicast.) | |||
| Tutorial: In this group key management model that extends the | Tutorial: In this group key management model that extends the | |||
| ISAKMP standard, the protocol is run between a group member and a | ISAKMP standard, the protocol is run between a group member and a | |||
| "group controller/key server", which establishes security | "group controller/key server", which establishes security | |||
| associations [R2401] among authorized group members. The GDOI | associations [R2401] among authorized group members. The GDOI | |||
| protocol is itself protected by an ISAKMP phase 1 association. | protocol is itself protected by an ISAKMP phase 1 association. | |||
| For example, multicast applications may use ESP to protect their | For example, multicast applications may use ESP to protect their | |||
| skipping to change at page 124, line 4 ¶ | skipping to change at page 127, line 11 ¶ | |||
| developed at the University of Texas for specifying, coding, and | developed at the University of Texas for specifying, coding, and | |||
| verifying software to produce correct and reliable programs. | verifying software to produce correct and reliable programs. | |||
| [Cheh] | [Cheh] | |||
| $ H field | $ H field | |||
| (D) See: "Deprecated Usage" under "Handling Restrictions field". | (D) See: "Deprecated Usage" under "Handling Restrictions field". | |||
| $ hack | $ hack | |||
| 1a. (I) /verb/ To work on something, especially to program a | 1a. (I) /verb/ To work on something, especially to program a | |||
| computer. (See: hacker.) | computer. (See: hacker.) | |||
| 1b. (I) /verb/ To do some kind of mischief, especially to play a | 1b. (I) /verb/ To do some kind of mischief, especially to play a | |||
| prank on, or penetrate, a system. (See: hacker, cracker.) | prank on, or penetrate, a system. (See: hacker, cracker.) | |||
| 2. (I) /noun/ An item of completed work or an instance of dealing | 2. (I) /noun/ An item of completed work, or a solution for a | |||
| with a problem, especially when that involves computer programming | problem, that is non-generalizable, i.e., is very specific to the | |||
| or other use of a computer. | application area or problem being solved. | |||
| Tutorial: Often, the application area or problem involves computer | ||||
| programming or other use of a computer. Characterizing something | ||||
| as a hack can be a compliment, such as when the solution is | ||||
| minimal and elegant; or it can be derogatory, such as when the | ||||
| solution fixes the problem but leaves the system in an | ||||
| unmaintainable state. | ||||
| See [Raym] for several other meanings of this term and also | ||||
| definitions of several derivative terms. | ||||
| $ hacker | $ hacker | |||
| 1. (I) Someone with a strong interest in computers, who enjoys | 1. (I) Someone with a strong interest in computers, who enjoys | |||
| learning about them, programming them, and experimenting and | learning about them, programming them, and experimenting and | |||
| otherwise working with them. (See: hack. Compare: cracker.) | otherwise working with them. (See: hack. Compare: adversary, | |||
| cracker, intruder.) | ||||
| Usage: This first definition is the original meaning of the term | Usage: This first definition is the original meaning of the term | |||
| (circa 1960); it then had a neutral or positive connotation of | (circa 1960); it then had a neutral or positive connotation of | |||
| "someone who figures things out and makes something cool happen". | "someone who figures things out and makes something cool happen". | |||
| 2. (O) "An individual who spends an inordinate amount of time | 2. (O) "An individual who spends an inordinate amount of time | |||
| working on computer systems for other than professional purposes." | working on computer systems for other than professional purposes." | |||
| [NCSSG] | [NCSSG] | |||
| 3. (D) Synonym for "cracker". | 3. (D) Synonym for "cracker". | |||
| skipping to change at page 125, line 23 ¶ | skipping to change at page 128, line 42 ¶ | |||
| $ harden | $ harden | |||
| (I) To protect a system by configuring it to operate in a way that | (I) To protect a system by configuring it to operate in a way that | |||
| eliminates or mitigates known vulnerabilities. Example: [RSCG]. | eliminates or mitigates known vulnerabilities. Example: [RSCG]. | |||
| (See: default account.) | (See: default account.) | |||
| $ hardware | $ hardware | |||
| (I) The material physical components of an information system. | (I) The material physical components of an information system. | |||
| (See: firmware, software.) | (See: firmware, software.) | |||
| $ hardware error | ||||
| (I) /threat action/ See: secondary definitions under "corruption", | ||||
| "exposure", and "incapacitation". | ||||
| $ hardware token | $ hardware token | |||
| See: token. | See: token. | |||
| $ hash code | $ hash code | |||
| (D) Synonym for "hash result" or "hash function". | (D) Synonym for "hash result" or "hash function". | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | |||
| in a potentially misleading way. A hash result is not a "code", | in a potentially misleading way. A hash result is not a "code", | |||
| and a hash function does not "encode" in any sense defined by this | and a hash function does not "encode" in any sense defined by this | |||
| glossary. (See: hash value, message digest.) | glossary. (See: hash value, message digest.) | |||
| skipping to change at page 127, line 36 ¶ | skipping to change at page 131, line 7 ¶ | |||
| Usage: ISDs that use this term SHOULD state a definition for it | Usage: ISDs that use this term SHOULD state a definition for it | |||
| because the term mixes concepts and could easily be misunderstood. | because the term mixes concepts and could easily be misunderstood. | |||
| $ hijack attack | $ hijack attack | |||
| (I) A form of active wiretapping in which the attacker seizes | (I) A form of active wiretapping in which the attacker seizes | |||
| control of a previously established communication association. | control of a previously established communication association. | |||
| (See: man-in-the-middle attack, pagejacking, piggyback attack.) | (See: man-in-the-middle attack, pagejacking, piggyback attack.) | |||
| $ HIPAA | $ HIPAA | |||
| (N) Health Information Portability and Accountability Act of 1996, | (N) Health Information Portability and Accountability Act of 1996, | |||
| a U.S. law (Public Law 104-191) that protects the privacy of | a U.S. law (Public Law 104-191) that is intended to protect the | |||
| patients' medical records and other health information in all | privacy of patients' medical records and other health information | |||
| forms, and mandates security for that information, including for | in all forms, and mandates security for that information, | |||
| its electronic storage and transmission. | including for its electronic storage and transmission. | |||
| $ HMAC | $ HMAC | |||
| (I) A keyed hash [R2104] that can be based on any iterated | (I) A keyed hash [R2104] that can be based on any iterated | |||
| cryptographic hash (e.g., MD5 or SHA-1), so that the cryptographic | cryptographic hash (e.g., MD5 or SHA-1), so that the cryptographic | |||
| strength of HMAC depends on the properties of the selected | strength of HMAC depends on the properties of the selected | |||
| cryptographic hash. (See: [R2202, R2403, R2404].) | cryptographic hash. (See: [R2202, R2403, R2404].) | |||
| Derivation: Hash-based MAC. (Compare: CMAC.) | ||||
| Tutorial: Assume that H is a generic cryptographic hash in which a | Tutorial: Assume that H is a generic cryptographic hash in which a | |||
| function is iterated on data blocks of length B bytes. L is the | function is iterated on data blocks of length B bytes. L is the | |||
| length of the of hash result of H. K is a secret key of length L | length of the of hash result of H. K is a secret key of length L | |||
| <= K <= B. The values IPAD and OPAD are fixed strings used as | <= K <= B. The values IPAD and OPAD are fixed strings used as | |||
| inner and outer padding and defined as follows: IPAD = the byte | inner and outer padding and defined as follows: IPAD = the byte | |||
| 0x36 repeated B times, and OPAD = the byte 0x5C repeated B times. | 0x36 repeated B times, and OPAD = the byte 0x5C repeated B times. | |||
| HMAC is computed by H(K XOR OPAD, H(K XOR IPAD, inputdata)). | HMAC is computed by H(K XOR OPAD, H(K XOR IPAD, inputdata)). | |||
| HMAC has the following goals: | HMAC has the following goals: | |||
| - To use available cryptographic hash functions without | - To use available cryptographic hash functions without | |||
| modification, particularly functions that perform well in | modification, particularly functions that perform well in | |||
| software and for which software is freely and widely available. | software and for which software is freely and widely available. | |||
| - To preserve the original performance of the selected hash | - To preserve the original performance of the selected hash | |||
| without significant degradation. | without significant degradation. | |||
| - To use and handle keys in a simple way. | - To use and handle keys in a simple way. | |||
| - To have a well-understood cryptographic analysis of the | - To have a well-understood cryptographic analysis of the | |||
| strength of the mechanism based on reasonable assumptions about | strength of the mechanism based on reasonable assumptions about | |||
| the underlying hash function. | the underlying hash function. | |||
| - To enable easy replacement of the hash function in case a | - To enable easy replacement of the hash function in case a | |||
| faster or stronger hash is found or required. | faster or stronger hash is found or required. | |||
| $ honey pot | $ honey pot | |||
| (D) A system (e.g., a web server) or system resource (e.g., a file | (N) A system (e.g., a web server) or system resource (e.g., a file | |||
| on a server) that is designed to be attractive to potential | on a server) that is designed to be attractive to potential | |||
| crackers and intruders, like honey is attractive to bears. (See: | crackers and intruders, like honey is attractive to bears. (See: | |||
| entrapment.) | entrapment.) | |||
| Deprecated Term: It is likely that other cultures use different | Usage: It is likely that other cultures use different metaphors | |||
| metaphors for this concept. Therefore, to avoid international | for this concept. Therefore, to avoid international | |||
| misunderstanding, ISDs SHOULD NOT use this term (unless they also | misunderstanding, an ISD SHOULD NOT use this term without | |||
| provide a definition like this one). (See: Deprecated Usage under | providing a definition for it. (See: Deprecated Usage under "Green | |||
| "Green Book.") | Book.") | |||
| $ host | $ host | |||
| 1. (I) /general/ A computer that is attached to a communication | 1. (I) /general/ A computer that is attached to a communication | |||
| subnetwork or internetwork and can use services provided by the | subnetwork or internetwork and can use services provided by the | |||
| network to exchange data with other attached systems. (See: end | network to exchange data with other attached systems. (See: end | |||
| system. Compare: server.) | system. Compare: server.) | |||
| 2. (I) /IPS/ A networked computer that does not forward IP packets | 2. (I) /IPS/ A networked computer that does not forward IP packets | |||
| that are not addressed to the computer itself. (Compare: router.) | that are not addressed to the computer itself. (Compare: router.) | |||
| skipping to change at page 129, line 5 ¶ | skipping to change at page 132, line 28 ¶ | |||
| $ HTTP | $ HTTP | |||
| (I) See: Hypertext Transfer Protocol. | (I) See: Hypertext Transfer Protocol. | |||
| $ https | $ https | |||
| (I) When used in the first part of a URL (the part that precedes | (I) When used in the first part of a URL (the part that precedes | |||
| the colon and specifies an access scheme or protocol), this term | the colon and specifies an access scheme or protocol), this term | |||
| specifies the use of HTTP enhanced by a security mechanism, which | specifies the use of HTTP enhanced by a security mechanism, which | |||
| is usually SSL. (Compare: S-HTTP.) | is usually SSL. (Compare: S-HTTP.) | |||
| $ human error | ||||
| (I) /threat action/ See: secondary definitions under "corruption", | ||||
| "exposure", and "incapacitation". | ||||
| $ hybrid encryption | $ hybrid encryption | |||
| (I) An application of cryptography that combines two or more | (I) An application of cryptography that combines two or more | |||
| encryption algorithms, particularly a combination of symmetric and | encryption algorithms, particularly a combination of symmetric and | |||
| asymmetric encryption. Examples: digital envelope, MSP, PEM, PGP. | asymmetric encryption. Examples: digital envelope, MSP, PEM, PGP. | |||
| (Compare: superencryption.) | (Compare: superencryption.) | |||
| Tutorial: Asymmetric algorithms require more computation than | Tutorial: Asymmetric algorithms require more computation than | |||
| equivalently strong symmetric ones. Thus, asymmetric encryption is | equivalently strong symmetric ones. Thus, asymmetric encryption is | |||
| not normally used for data confidentiality except to distribute a | not normally used for data confidentiality except to distribute a | |||
| symmetric key in a hybrid encryption scheme, where the symmetric | symmetric key in a hybrid encryption scheme, where the symmetric | |||
| skipping to change at page 133, line 44 ¶ | skipping to change at page 137, line 29 ¶ | |||
| $ IMAP4 AUTHENTICATE | $ IMAP4 AUTHENTICATE | |||
| (I) A IMAP4 command (better described as a transaction type, or | (I) A IMAP4 command (better described as a transaction type, or | |||
| subprotocol) by which an IMAP4 client optionally proposes a | subprotocol) by which an IMAP4 client optionally proposes a | |||
| mechanism to an IMAP4 server to authenticate the client to the | mechanism to an IMAP4 server to authenticate the client to the | |||
| server and provide other security services. (See: POP3.) | server and provide other security services. (See: POP3.) | |||
| Tutorial: If the server accepts the proposal, the command is | Tutorial: If the server accepts the proposal, the command is | |||
| followed by performing a challenge-response authentication | followed by performing a challenge-response authentication | |||
| protocol and, optionally, negotiating a protection mechanism for | protocol and, optionally, negotiating a protection mechanism for | |||
| subsequent POP3 interactions. The security mechanisms that are | subsequent POP3 interactions. The security mechanisms that are | |||
| used by IMAP4 AUTHENTICATE -- including Kerberos, GSSAPI, and | used by IMAP4 AUTHENTICATE -- including Kerberos, GSS-API, and | |||
| S/Key -- are described in [R1731]. | S/Key -- are described in [R1731]. | |||
| $ impossible | $ impossible | |||
| (O) Cannot be done in any reasonable amount of time. (See: break, | (O) Cannot be done in any reasonable amount of time. (See: break, | |||
| brute force, strength, work factor.) | brute force, strength, work factor.) | |||
| $ in the clear | $ in the clear | |||
| (I) Not encrypted. (See: clear text.) | (I) Not encrypted. (See: clear text.) | |||
| $ Ina Jo | $ Ina Jo | |||
| skipping to change at page 134, line 20 ¶ | skipping to change at page 138, line 5 ¶ | |||
| operation by disabling a system component. (See: disruption.) | operation by disabling a system component. (See: disruption.) | |||
| Usage: This type of threat action includes the following subtypes: | Usage: This type of threat action includes the following subtypes: | |||
| - "Malicious logic": In context of incapacitation, any hardware, | - "Malicious logic": In context of incapacitation, any hardware, | |||
| firmware, or software (e.g., logic bomb) intentionally | firmware, or software (e.g., logic bomb) intentionally | |||
| introduced into a system to destroy system functions or | introduced into a system to destroy system functions or | |||
| resources. (See: corruption, main entry for "malicious logic", | resources. (See: corruption, main entry for "malicious logic", | |||
| masquerade, misuse.) | masquerade, misuse.) | |||
| - "Physical destruction": Deliberate destruction of a system | - "Physical destruction": Deliberate destruction of a system | |||
| component to interrupt or prevent system operation. | component to interrupt or prevent system operation. | |||
| - "Human error": In context of incapacitation, action or inaction | - "Human error": /incapacitation/ Action or inaction that | |||
| that unintentionally disables a system component. (See: | unintentionally disables a system component. (See: corruption, | |||
| corruption, exposure.) | ||||
| - "Hardware or software error": In context of incapacitation, | ||||
| error that unintentionally causes failure of a system component | ||||
| and leads to disruption of system operation. (See: corruption, | ||||
| exposure.) | exposure.) | |||
| - "Natural disaster": In context of incapacitation, any "act of | - "Hardware or software error": /incapacitation/ Error that | |||
| God" (e.g., fire, flood, earthquake, lightning, or wind) that | unintentionally causes failure of a system component and leads | |||
| disables a system component. [FP031 section 2] | to disruption of system operation. (See: corruption, exposure.) | |||
| - "Natural disaster": /incapacitation/ Any "act of God" (e.g., | ||||
| fire, flood, earthquake, lightning, or wind) that disables a | ||||
| system component. [FP031 section 2] | ||||
| $ incident | $ incident | |||
| See: security incident. | See: security incident. | |||
| $ INCITS | $ INCITS | |||
| (N) See: "International Committee for Information Technology | (N) See: "International Committee for Information Technology | |||
| Standardization" under "ANSI". | Standardization" under "ANSI". | |||
| $ indicator | $ indicator | |||
| (N) An action -- either specific, generalized, or theoretical -- | (N) An action -- either specific, generalized, or theoretical -- | |||
| skipping to change at page 138, line 5 ¶ | skipping to change at page 141, line 43 ¶ | |||
| mix concepts in potentially confusing ways. | mix concepts in potentially confusing ways. | |||
| Tutorial: An IV can be used to synchronize one cryptographic | Tutorial: An IV can be used to synchronize one cryptographic | |||
| process with another; e.g., CBC, CFB, and OFB use IVs. An IV also | process with another; e.g., CBC, CFB, and OFB use IVs. An IV also | |||
| can be used to introduce cryptographic variance (see: salt) in | can be used to introduce cryptographic variance (see: salt) in | |||
| addition to that provided by a key. | addition to that provided by a key. | |||
| $ initialization vector | $ initialization vector | |||
| (D) /cryptographic function/ Synonym for "initialization value". | (D) /cryptographic function/ Synonym for "initialization value". | |||
| Deprecated Term: For consistency, ISDs SHOULD NOT use this term in | Deprecated Term: To avoid international misunderstanding, ISDs | |||
| the context of cryptographic functions. | SHOULD NOT use this term in the context of cryptographic functions | |||
| because the term's dictionary definition includes the concept of | ||||
| direction, which is not intended in cryptographic use. | ||||
| $ insertion | $ insertion | |||
| (I) /packet/ See: secondary definition under "stream integrity | 1. (I) /packet/ See: secondary definition under "stream integrity | |||
| service". | service". | |||
| 2. (I) /threat action/ See: secondary definition under | ||||
| "falsification". | ||||
| $ inside attack | $ inside attack | |||
| (I) See: secondary definition under "attack". Compare: insider. | (I) See: secondary definition under "attack". Compare: insider. | |||
| $ insider | $ insider | |||
| 1. (I) A user (usually a person) that accesses a system from a | 1. (I) A user (usually a person) that accesses a system from a | |||
| position that is inside the system's security perimeter. (Compare: | position that is inside the system's security perimeter. (Compare: | |||
| authorized user, outsider, unauthorized user.) | authorized user, outsider, unauthorized user.) | |||
| Tutorial: An insider has been assigned a role that has more | Tutorial: An insider has been assigned a role that has more | |||
| privileges to access system resources than do some other types of | privileges to access system resources than do some other types of | |||
| skipping to change at page 142, line 27 ¶ | skipping to change at page 146, line 18 ¶ | |||
| $ Internet Engineering Task Force (IETF) | $ Internet Engineering Task Force (IETF) | |||
| (I) A self-organized group of people who make contributions to the | (I) A self-organized group of people who make contributions to the | |||
| development of Internet technology. The principal body engaged in | development of Internet technology. The principal body engaged in | |||
| developing Internet Standards, although not itself a part of the | developing Internet Standards, although not itself a part of the | |||
| ISOC. Composed of Working Groups, which are arranged into Areas | ISOC. Composed of Working Groups, which are arranged into Areas | |||
| (such as the Security Area), each coordinated by one or more Area | (such as the Security Area), each coordinated by one or more Area | |||
| Directors. Nominations to the IAB and the IESG are made by a | Directors. Nominations to the IAB and the IESG are made by a | |||
| committee selected at random from regular IETF meeting attendees | committee selected at random from regular IETF meeting attendees | |||
| who have volunteered. (RFC 2026) [RFC 2323] | who have volunteered. (RFC 2026) [RFC 2323] | |||
| $ Internet Key Exchange (IKE) | ||||
| (I) An Internet, IPsec, key-establishment protocol [R4306] for | ||||
| putting in place authenticated keying material (a) for use with | ||||
| ISAKMP and (b) for other security associations, such as in AH and | ||||
| ESP. | ||||
| Tutorial: IKE is based on three earlier protocol designs: ISAKMP, | ||||
| OAKLEY, and SKEME. | ||||
| $ Internet Layer | $ Internet Layer | |||
| (I) See: Internet Protocol Suite. | (I) See: Internet Protocol Suite. | |||
| $ Internet Message Access Protocol, version 4 (IMAP4) | $ Internet Message Access Protocol, version 4 (IMAP4) | |||
| (I) An Internet protocol (RFC 2060) by which a client workstation | (I) An Internet protocol (RFC 2060) by which a client workstation | |||
| can dynamically access a mailbox on a server host to manipulate | can dynamically access a mailbox on a server host to manipulate | |||
| and retrieve mail messages that the server has received and is | and retrieve mail messages that the server has received and is | |||
| holding for the client. (See: POP3.) | holding for the client. (See: POP3.) | |||
| Tutorial: IMAP4 has mechanisms for optionally authenticating a | Tutorial: IMAP4 has mechanisms for optionally authenticating a | |||
| client to a server and providing other security services. (See: | client to a server and providing other security services. (See: | |||
| IMAP4 AUTHENTICATE.) | IMAP4 AUTHENTICATE.) | |||
| $ Internet Open Trading Protocol (IOTP) | $ Internet Open Trading Protocol (IOTP) | |||
| (I) An Internet protocol (RFC 2801) proposed as a general | (I) An Internet protocol (RFC 2801) proposed as a general | |||
| framework for Internet commerce, able to encapsulate transactions | framework for Internet commerce, able to encapsulate transactions | |||
| of various proprietary payment systems (e.g., GeldKarte, Mondex, | of various proprietary payment systems (e.g., GeldKarte, Mondex, | |||
| SET, VisaCash). Provides optional security services by | SET, Visa Cash). Provides optional security services by | |||
| incorporating various Internet security mechanisms (e.g., MD5) and | incorporating various Internet security mechanisms (e.g., MD5) and | |||
| protocols (e.g., TLS). | protocols (e.g., TLS). | |||
| $ Internet Policy Registration Authority (IPRA) | $ Internet Policy Registration Authority (IPRA) | |||
| (I) An X.509-compliant CA that is the top CA of the Internet | (I) An X.509-compliant CA that is the top CA of the Internet | |||
| certification hierarchy operated under the auspices of the ISOC | certification hierarchy operated under the auspices of the ISOC | |||
| [R1422]. (See: /PEM/ under "certification hierarchy".) | [R1422]. (See: /PEM/ under "certification hierarchy".) | |||
| $ Internet Private Line Interface (IPLI) | $ Internet Private Line Interface (IPLI) | |||
| (O) A successor to the PLI, updated to use TCP/IP and newer | (O) A successor to the PLI, updated to use TCP/IP and newer | |||
| skipping to change at page 147, line 51 ¶ | skipping to change at page 151, line 51 ¶ | |||
| $ intranet | $ intranet | |||
| (I) A computer network, especially one based on Internet | (I) A computer network, especially one based on Internet | |||
| technology, that an organization uses for its own internal (and | technology, that an organization uses for its own internal (and | |||
| usually private) purposes and that is closed to outsiders. (See: | usually private) purposes and that is closed to outsiders. (See: | |||
| extranet, virtual private network.) | extranet, virtual private network.) | |||
| $ intruder | $ intruder | |||
| (I) An entity that gains or attempts to gain access to a system or | (I) An entity that gains or attempts to gain access to a system or | |||
| system resource without having authorization to do so. (See: | system resource without having authorization to do so. (See: | |||
| intrusion. Compare: adversary, cracker.) | intrusion. Compare: adversary, cracker, hacker.) | |||
| $ intrusion | $ intrusion | |||
| 1. (I) A security event, or a combination of multiple security | 1. (I) A security event, or a combination of multiple security | |||
| events, that constitutes a security incident in which an intruder | events, that constitutes a security incident in which an intruder | |||
| gains, or attempts to gain, access to a system or system resource | gains, or attempts to gain, access to a system or system resource | |||
| without having authorization to do so. (See: IDS.) | without having authorization to do so. (See: IDS.) | |||
| 2. (I) A type of threat action whereby an unauthorized entity | 2. (I) A type of threat action whereby an unauthorized entity | |||
| gains access to sensitive data by circumventing a system's | gains access to sensitive data by circumventing a system's | |||
| security protections. (See: unauthorized disclosure.) | security protections. (See: unauthorized disclosure.) | |||
| skipping to change at page 148, line 25 ¶ | skipping to change at page 152, line 25 ¶ | |||
| - "Reverse engineering": Acquiring sensitive data by | - "Reverse engineering": Acquiring sensitive data by | |||
| disassembling and analyzing the design of a system component. | disassembling and analyzing the design of a system component. | |||
| - "Cryptanalysis": Transforming encrypted data into plain text | - "Cryptanalysis": Transforming encrypted data into plain text | |||
| without having prior knowledge of encryption parameters or | without having prior knowledge of encryption parameters or | |||
| processes. (See: main entry for "cryptanalysis".) | processes. (See: main entry for "cryptanalysis".) | |||
| $ intrusion detection | $ intrusion detection | |||
| (I) Sensing and analyzing system events for the purpose of | (I) Sensing and analyzing system events for the purpose of | |||
| noticing (i.e., becoming aware of) attempts to access system | noticing (i.e., becoming aware of) attempts to access system | |||
| resources in an unauthorized manner. (See: anomaly detection, IDS, | resources in an unauthorized manner. (See: anomaly detection, IDS, | |||
| misuse detection.) [IDSAN, IDSSC, IDSSE, IDSSY] | misuse detection. Compare: extrusion detection.) [IDSAN, IDSSC, | |||
| IDSSE, IDSSY] | ||||
| Usage: This includes the following subtypes: | Usage: This includes the following subtypes: | |||
| - "Active detection": Real-time or near-real-time analysis of | - "Active detection": Real-time or near-real-time analysis of | |||
| system event data to detect current intrusions, which result in | system event data to detect current intrusions, which result in | |||
| an immediate protective response. | an immediate protective response. | |||
| - "Passive detection": Off-line analysis of audit data to detect | - "Passive detection": Off-line analysis of audit data to detect | |||
| past intrusions, which are reported to the system security | past intrusions, which are reported to the system security | |||
| officer for corrective action. (Compare: security audit.) | officer for corrective action. (Compare: security audit.) | |||
| $ intrusion detection system (IDS) | $ intrusion detection system (IDS) | |||
| skipping to change at page 150, line 22 ¶ | skipping to change at page 154, line 23 ¶ | |||
| $ IPRA | $ IPRA | |||
| (I) See: Internet Policy Registration Authority. | (I) See: Internet Policy Registration Authority. | |||
| $ IPS | $ IPS | |||
| (I) See: Internet Protocol Suite. | (I) See: Internet Protocol Suite. | |||
| $ IPsec | $ IPsec | |||
| (I) See: IP Security Protocol. | (I) See: IP Security Protocol. | |||
| $ IPsec Key Exchange (IKE) | ||||
| (I) An Internet, IPsec, key-establishment protocol [R2409] for | ||||
| putting in place authenticated keying material (a) for use with | ||||
| ISAKMP and (b) for other security associations, such as in AH and | ||||
| ESP. | ||||
| Tutorial: IKE is based on three earlier protocol designs: ISAKMP, | ||||
| OAKLEY, and SKEME. | ||||
| $ IPSO | $ IPSO | |||
| (I) See: Internet Protocol Security Option. | (I) See: Internet Protocol Security Option. | |||
| $ ISAKMP | $ ISAKMP | |||
| (I) See: Internet Security Association and Key Management | (I) See: Internet Security Association and Key Management | |||
| Protocol. | Protocol. | |||
| $ ISD | $ ISD | |||
| (I) See: Internet Standards document. | (I) See: Internet Standards document. | |||
| skipping to change at page 152, line 53 ¶ | skipping to change at page 156, line 44 ¶ | |||
| $ KDC | $ KDC | |||
| (I) See: Key Distribution Center. | (I) See: Key Distribution Center. | |||
| $ KEA | $ KEA | |||
| (N) See: Key Exchange Algorithm. | (N) See: Key Exchange Algorithm. | |||
| $ KEK | $ KEK | |||
| (I) See: key-encrypting key. (Compare: KAK.) | (I) See: key-encrypting key. (Compare: KAK.) | |||
| $ Kerberos | $ Kerberos | |||
| (N) A system developed at the Massachusetts Institute of | (I) A system developed at the Massachusetts Institute of | |||
| Technology that depends on passwords and symmetric cryptography | Technology that depends on passwords and symmetric cryptography | |||
| (DES) to implement ticket-based, peer entity authentication | (DES) to implement ticket-based, peer entity authentication | |||
| service and access control service distributed in a client-server | service and access control service distributed in a client-server | |||
| network environment. [R1510, Stei] | network environment. [R4120, Stei] (See: realm.) | |||
| Tutorial: Kerberos was developed by Project Athena and is named | Tutorial: Kerberos was originally developed by Project Athena and | |||
| for the mythical three-headed dog that guards Hades. The system | is named for the mythical three-headed dog that guards Hades. The | |||
| architecture includes servers that function as an ACC and a KDC. | system architecture includes authentication servers and ticket- | |||
| granting servers that function as an ACC and a KDC. | ||||
| RFC 4556 describes extensions to the Kerberos specification that | ||||
| modify the initial authentication exchange between a client and | ||||
| the KDC. The extensions employ public-key cryptography to enable | ||||
| the client and KDC to mutually authenticate and establish shared, | ||||
| symmetric keys that are used to complete the exchange. (See: | ||||
| PKINT.) | ||||
| $ kernel | $ kernel | |||
| (I) A small, trusted part of a system that provides services on | (I) A small, trusted part of a system that provides services on | |||
| which the other parts of the system depend. (See: security | which the other parts of the system depend. (See: security | |||
| kernel.) | kernel.) | |||
| $ Kernelized Secure Operating System (KSOS) | $ Kernelized Secure Operating System (KSOS) | |||
| (O) An MLS computer operating system, designed to be a provably | (O) An MLS computer operating system, designed to be a provably | |||
| secure replacement for UNIX Version 6, and consisting of a | secure replacement for UNIX Version 6, and consisting of a | |||
| security kernel, non-kernel security-related utility programs, and | security kernel, non-kernel security-related utility programs, and | |||
| skipping to change at page 153, line 54 ¶ | skipping to change at page 157, line 54 ¶ | |||
| to guess. (See: brute force attack, cryptanalysis, strength.) | to guess. (See: brute force attack, cryptanalysis, strength.) | |||
| $ key agreement (algorithm or protocol) | $ key agreement (algorithm or protocol) | |||
| 1. (I) A key establishment method (especially one involving | 1. (I) A key establishment method (especially one involving | |||
| asymmetric cryptography) by which two or more entities, without | asymmetric cryptography) by which two or more entities, without | |||
| prior arrangement except a public exchange of data (such as public | prior arrangement except a public exchange of data (such as public | |||
| keys), each can generate the same key value. That is, the method | keys), each can generate the same key value. That is, the method | |||
| does not send a secret from one entity to the other; instead, both | does not send a secret from one entity to the other; instead, both | |||
| entities, without prior arrangement except a public exchange of | entities, without prior arrangement except a public exchange of | |||
| data, can compute the same secret value, but that value cannot be | data, can compute the same secret value, but that value cannot be | |||
| computed by other, unauthorized entities. (See: Diffie-Hellman, | computed by other, unauthorized entities. (See: Diffie-Hellman- | |||
| key establishment, KEA, MQV. Compare: key transport.) | Merkle, key establishment, KEA, MQV. Compare: key transport.) | |||
| 2. (O) "A method for negotiating a key value on line without | 2. (O) "A method for negotiating a key value on line without | |||
| transferring the key, even in an encrypted form, e.g., the Diffie- | transferring the key, even in an encrypted form, e.g., the Diffie- | |||
| Hellman technique." [X509] | Hellman technique." [X509] (See: Diffie-Hellman-Merkle.) | |||
| 3. (O) "The procedure whereby two different parties generate | 3. (O) "The procedure whereby two different parties generate | |||
| shared symmetric keys such that any of the shared symmetric keys | shared symmetric keys such that any of the shared symmetric keys | |||
| is a function of the information contributed by all legitimate | is a function of the information contributed by all legitimate | |||
| participants, so that no party [alone] can predetermine the value | participants, so that no party [alone] can predetermine the value | |||
| of the key." [A9042] | of the key." [A9042] | |||
| Example: A message originator and the intended recipient can each | Example: A message originator and the intended recipient can each | |||
| use their own private key and the other's public key with the | use their own private key and the other's public key with the | |||
| Diffie-Hellman algorithm to first compute a shared secret value | Diffie-Hellman-Merkle algorithm to first compute a shared secret | |||
| and, from that value, derive a session key to encrypt the message. | value and, from that value, derive a session key to encrypt the | |||
| message. | ||||
| $ key authentication | $ key authentication | |||
| (N) "The assurance of the legitimate participants in a key | (N) "The assurance of the legitimate participants in a key | |||
| agreement [i.e., in a key-agreement protocol] that no non- | agreement [i.e., in a key-agreement protocol] that no non- | |||
| legitimate party possesses the shared symmetric key." [A9042] | legitimate party possesses the shared symmetric key." [A9042] | |||
| $ key-auto-key (KAK) | $ key-auto-key (KAK) | |||
| (D) "Cryptographic logic [i.e., a mode of operation] using | (D) "Cryptographic logic [i.e., a mode of operation] using | |||
| previous key to produce key." [C4009, A1523] (See: CTAK, | previous key to produce key." [C4009, A1523] (See: CTAK, | |||
| /cryptographic operation/ under "mode".) | /cryptographic operation/ under "mode".) | |||
| Deprecated Term: IDS SHOULD NOT use this term; it is neither well- | Deprecated Term: ISDs SHOULD NOT use this term; it is neither | |||
| known nor precisely defined. Instead, use terms associated with | well-known nor precisely defined. Instead, use terms associated | |||
| modes that are defined in standards, such as CBC, CFB, and OFB. | with modes that are defined in standards, such as CBC, CFB, and | |||
| OFB. | ||||
| $ key center | $ key center | |||
| (I) A centralized, key-distribution process (used in symmetric | (I) A centralized, key-distribution process (used in symmetric | |||
| cryptography), usually a separate computer system, that uses | cryptography), usually a separate computer system, that uses | |||
| master keys (i.e., KEKs) to encrypt and distribute session keys | master keys (i.e., KEKs) to encrypt and distribute session keys | |||
| needed by a community of users. | needed by a community of users. | |||
| Tutorial: An ANSI standard [A9017] defines two types of key | Tutorial: An ANSI standard [A9017] defines two types of key | |||
| center: "key distribution center" and "key translation center". | center: "key distribution center" and "key translation center". | |||
| skipping to change at page 155, line 34 ¶ | skipping to change at page 159, line 37 ¶ | |||
| (N) A key recovery technique for storing knowledge of a | (N) A key recovery technique for storing knowledge of a | |||
| cryptographic key by encrypting it with another key and ensuring | cryptographic key by encrypting it with another key and ensuring | |||
| that that only certain third parties called "recovery agents" can | that that only certain third parties called "recovery agents" can | |||
| perform the decryption operation to retrieve the stored key. Key | perform the decryption operation to retrieve the stored key. Key | |||
| encapsulation typically permits direct retrieval of a secret key | encapsulation typically permits direct retrieval of a secret key | |||
| used to provide data confidentiality. (Compare: key escrow.) | used to provide data confidentiality. (Compare: key escrow.) | |||
| $ key-encrypting key (KEK) | $ key-encrypting key (KEK) | |||
| (I) A cryptographic key that (a) is used to encrypt other keys | (I) A cryptographic key that (a) is used to encrypt other keys | |||
| (either DEKs or other TEKs) for transmission or storage but (b) | (either DEKs or other TEKs) for transmission or storage but (b) | |||
| usually is not used to encrypt application data. Usage: Sometimes | (usually) is not used to encrypt application data. Usage: | |||
| called "key-encryption key". | Sometimes called "key-encryption key". | |||
| $ key escrow | $ key escrow | |||
| (N) A key recovery technique for storing knowledge of a | (N) A key recovery technique for storing knowledge of a | |||
| cryptographic key or parts thereof in the custody of one or more | cryptographic key or parts thereof in the custody of one or more | |||
| third parties called "escrow agents", so that the key can be | third parties called "escrow agents", so that the key can be | |||
| recovered and used in specified circumstances. (Compare: key | recovered and used in specified circumstances. (Compare: key | |||
| encapsulation.) | encapsulation.) | |||
| Tutorial: Key escrow is typically implemented with split knowledge | Tutorial: Key escrow is typically implemented with split knowledge | |||
| techniques. For example, the Escrowed Encryption Standard [FP185] | techniques. For example, the Escrowed Encryption Standard [FP185] | |||
| skipping to change at page 156, line 15 ¶ | skipping to change at page 160, line 18 ¶ | |||
| communication association. | communication association. | |||
| 2. (I) A procedure that results in keying material being shared | 2. (I) A procedure that results in keying material being shared | |||
| among two or more system entities. [A9042, SP56] | among two or more system entities. [A9042, SP56] | |||
| Tutorial: The two basic techniques for key establishment are "key | Tutorial: The two basic techniques for key establishment are "key | |||
| agreement" and "key transport". | agreement" and "key transport". | |||
| $ Key Exchange Algorithm (KEA) | $ Key Exchange Algorithm (KEA) | |||
| (N) A key-agreement method [SKIP, R2773] that is based on the | (N) A key-agreement method [SKIP, R2773] that is based on the | |||
| Diffie-Hellman algorithm and uses 1024-bit asymmetric keys. (See: | Diffie-Hellman-Merkle algorithm and uses 1024-bit asymmetric keys. | |||
| CAPSTONE, CLIPPER, FORTEZZA, SKIPJACK.) | (See: CAPSTONE, CLIPPER, FORTEZZA, SKIPJACK.) | |||
| Tutorial: KEA was developed by NSA and formerly classified at the | Tutorial: KEA was developed by NSA and formerly classified at the | |||
| U.S. DoD "Secret" level. On 23 June 1998, the NSA announced that | U.S. DoD "Secret" level. On 23 June 1998, the NSA announced that | |||
| KEA had been declassified. | KEA had been declassified. | |||
| $ key generation | $ key generation | |||
| (I) A process that creates the sequence of symbols that comprise a | (I) A process that creates the sequence of symbols that comprise a | |||
| cryptographic key. (See: key management.) | cryptographic key. (See: key management.) | |||
| $ key generator | $ key generator | |||
| skipping to change at page 157, line 55 ¶ | skipping to change at page 161, line 55 ¶ | |||
| (D) Synonym for "keying material". | (D) Synonym for "keying material". | |||
| Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for | Deprecated Usage: ISDs SHOULD NOT use this term as a synonym for | |||
| "keying material". | "keying material". | |||
| $ key pair | $ key pair | |||
| (I) A set of mathematically related keys -- a public key and a | (I) A set of mathematically related keys -- a public key and a | |||
| private key -- that are used for asymmetric cryptography and are | private key -- that are used for asymmetric cryptography and are | |||
| generated in a way that makes it computationally infeasible to | generated in a way that makes it computationally infeasible to | |||
| derive the private key from knowledge of the public key. (See: | derive the private key from knowledge of the public key. (See: | |||
| Diffie-Hellman, RSA.) | Diffie-Hellman-Merkle, RSA.) | |||
| Tutorial: A key pair's owner discloses the public key to other | Tutorial: A key pair's owner discloses the public key to other | |||
| system entities so they can use the key to (a) encrypt data, (b) | system entities so they can use the key to (a) encrypt data, (b) | |||
| verify a digital signature, or (c) generate a key with a key- | verify a digital signature, or (c) generate a key with a key- | |||
| agreement algorithm. The matching private key is kept secret by | agreement algorithm. The matching private key is kept secret by | |||
| the owner, who uses it to (a') decrypt data, (b') generate a | the owner, who uses it to (a') decrypt data, (b') generate a | |||
| digital signature, or (c') generate a key with a key-agreement | digital signature, or (c') generate a key with a key-agreement | |||
| algorithm. | algorithm. | |||
| $ key recovery | $ key recovery | |||
| 1. (I) /cryptanalysis/ A process for learning the value of a | 1. (I) /cryptanalysis/ A process for learning the value of a | |||
| skipping to change at page 166, line 42 ¶ | skipping to change at page 170, line 42 ¶ | |||
| $ MAN | $ MAN | |||
| (I) metropolitan area network. | (I) metropolitan area network. | |||
| $ man-in-the-middle attack | $ man-in-the-middle attack | |||
| (I) A form of active wiretapping attack in which the attacker | (I) A form of active wiretapping attack in which the attacker | |||
| intercepts and selectively modifies communicated data in order to | intercepts and selectively modifies communicated data in order to | |||
| masquerade as one or more of the entities involved in a | masquerade as one or more of the entities involved in a | |||
| communication association. (See: hijack attack, piggyback attack.) | communication association. (See: hijack attack, piggyback attack.) | |||
| Tutorial: For example, suppose Alice and Bob try to establish a | Tutorial: For example, suppose Alice and Bob try to establish a | |||
| session key by using the Diffie-Hellman algorithm without data | session key by using the Diffie-Hellman-Merkle algorithm without | |||
| origin authentication service. A "man in the middle" could (a) | data origin authentication service. A "man in the middle" could | |||
| block direct communication between Alice and Bob and then (b) | (a) block direct communication between Alice and Bob and then (b) | |||
| masquerade as Alice sending data to Bob, (c) masquerade as Bob | masquerade as Alice sending data to Bob, (c) masquerade as Bob | |||
| sending data to Alice, (d) establish separate session keys with | sending data to Alice, (d) establish separate session keys with | |||
| each of them, and (e) function as a clandestine proxy server | each of them, and (e) function as a clandestine proxy server | |||
| between them in order to capture or modify sensitive information | between them in order to capture or modify sensitive information | |||
| that Alice and Bob think they are sending only to each other. | that Alice and Bob think they are sending only to each other. | |||
| $ manager | $ manager | |||
| (I) A person who controls the service configuration of a system or | (I) A person who controls the service configuration of a system or | |||
| the functional privileges of operators and other users. | the functional privileges of operators and other users. | |||
| skipping to change at page 169, line 16 ¶ | skipping to change at page 173, line 16 ¶ | |||
| $ mesh PKI | $ mesh PKI | |||
| (I) A non-hierarchical PKI architecture in which there are several | (I) A non-hierarchical PKI architecture in which there are several | |||
| trusted CAs rather than a single root. Each certificate user bases | trusted CAs rather than a single root. Each certificate user bases | |||
| path validations on the public key of one of the trusted CAs, | path validations on the public key of one of the trusted CAs, | |||
| usually the one that issued that user's own public-key | usually the one that issued that user's own public-key | |||
| certificate. Rather than having superior-to-subordinate | certificate. Rather than having superior-to-subordinate | |||
| relationships between CAs, the relationships are peer-to-peer, and | relationships between CAs, the relationships are peer-to-peer, and | |||
| CAs issue cross-certificates to each other. (Compare: hierarchical | CAs issue cross-certificates to each other. (Compare: hierarchical | |||
| PKI, trust-file PKI.) | PKI, trust-file PKI.) | |||
| $ Message Authentication Code, message authentication code | $ Message Authentication Code (MAC), message authentication code | |||
| 1. (N) /capitalized/ A specific ANSI standard for a checksum that | 1. (N) /capitalized/ A specific ANSI standard for a checksum that | |||
| is computed with a keyed hash that is based on DES. [A9009] Usage: | is computed with a keyed hash that is based on DES. [A9009] Usage: | |||
| a.k.a. Data Authentication Code, which is a U.S. Government | a.k.a. Data Authentication Code, which is a U.S. Government | |||
| standard. [FP113] (See: MAC.) | standard. [FP113] (See: MAC.) | |||
| 2. (D) /not capitalized/ Synonym for "error detection code". | 2. (D) /not capitalized/ Synonym for "error detection code". | |||
| Deprecated Term: ISDs SHOULD NOT use the uncapitalized form | Deprecated Term: ISDs SHOULD NOT use the uncapitalized form | |||
| "message authentication code". Instead, use "checksum", "error | "message authentication code". Instead, use "checksum", "error | |||
| detection code", "hash", "keyed hash", "Message Authentication | detection code", "hash", "keyed hash", "Message Authentication | |||
| skipping to change at page 173, line 5 ¶ | skipping to change at page 177, line 5 ¶ | |||
| $ misuse | $ misuse | |||
| 1. (I) The intentional use (by authorized users) of system | 1. (I) The intentional use (by authorized users) of system | |||
| resources for other than authorized purposes. Example: An | resources for other than authorized purposes. Example: An | |||
| authorized system administrator creates an unauthorized account | authorized system administrator creates an unauthorized account | |||
| for a friend. | for a friend. | |||
| 2. (I) A type of threat action that causes a system component to | 2. (I) A type of threat action that causes a system component to | |||
| perform a function or service that is detrimental to system | perform a function or service that is detrimental to system | |||
| security. (See: usurpation.) | security. (See: usurpation.) | |||
| Usage: This type of threat action includes the following subtypes: | Usage: This type of threat action includes the following subtypes: | |||
| - "Tampering": In context of misuse, deliberately altering a | - "Tampering": /misuse/ Deliberately altering a system's logic, | |||
| system's logic, data, or control information to cause the | data, or control information to cause the system to perform | |||
| system to perform unauthorized functions or services. (See: | unauthorized functions or services. (See: corruption, main | |||
| corruption, main entry for "tampering".) | entry for "tampering".) | |||
| - "Malicious logic": In context of misuse, any hardware, | - "Malicious logic": /misuse/ Any hardware, firmware, or software | |||
| firmware, or software intentionally introduced into a system to | intentionally introduced into a system to perform or control | |||
| perform or control execution of an unauthorized function or | execution of an unauthorized function or service. (See: | |||
| service. (See: corruption, incapacitation, main entry for | corruption, incapacitation, main entry for "malicious logic", | |||
| "malicious logic", masquerade.) | masquerade.) | |||
| - "Violation of authorizations": Action by an entity that exceeds | - "Violation of authorizations": Action by an entity that exceeds | |||
| the entity's system privileges by executing an unauthorized | the entity's system privileges by executing an unauthorized | |||
| function. (See: authorization.) | function. (See: authorization.) | |||
| $ misuse detection | $ misuse detection | |||
| (I) An intrusion detection method that is based on rules that | (I) An intrusion detection method that is based on rules that | |||
| specify system events, sequences of events, or observable | specify system events, sequences of events, or observable | |||
| properties of a system that are believed to be symptomatic of | properties of a system that are believed to be symptomatic of | |||
| security incidents. (See: IDS. Compare: anomaly detection.) | security incidents. (See: IDS. Compare: anomaly detection.) | |||
| skipping to change at page 174, line 10 ¶ | skipping to change at page 178, line 10 ¶ | |||
| Tutorial: Mobile code might be malicious. Using techniques such as | Tutorial: Mobile code might be malicious. Using techniques such as | |||
| "code signing" and a "sandbox" can reduce the risks of receiving | "code signing" and a "sandbox" can reduce the risks of receiving | |||
| and executing mobile code. | and executing mobile code. | |||
| $ mode | $ mode | |||
| $ mode of operation | $ mode of operation | |||
| 1. (I) /cryptographic operation/ A technique for enhancing the | 1. (I) /cryptographic operation/ A technique for enhancing the | |||
| effect of a cryptographic algorithm or adapting the algorithm for | effect of a cryptographic algorithm or adapting the algorithm for | |||
| an application, such as applying a block cipher to a sequence of | an application, such as applying a block cipher to a sequence of | |||
| data blocks or a data stream. (See: ECB, CBC, CFB, OFB.) | data blocks or a data stream. (See: CBC, CCM, CMAC, CFB, CTR, ECB, | |||
| OFB.) | ||||
| 2. (I) /system operation/ A type of security policy that states | 2. (I) /system operation/ A type of security policy that states | |||
| the range of classification levels of information that a system is | the range of classification levels of information that a system is | |||
| permitted to handle and the range of clearances and authorizations | permitted to handle and the range of clearances and authorizations | |||
| of users who are permitted to access the system. (See: | of users who are permitted to access the system. (See: | |||
| compartmented security mode, controlled security mode, dedicated | compartmented security mode, controlled security mode, dedicated | |||
| security mode, multilevel security mode, partitioned security | security mode, multilevel security mode, partitioned security | |||
| mode, system-high security mode. Compare: protection level.) | mode, system-high security mode. Compare: protection level.) | |||
| 3. (I) /IKE/ IKE refers to its various types of ISAKMP-scripted | 3. (I) /IKE/ IKE refers to its various types of ISAKMP-scripted | |||
| exchanges of messages as "modes". Among these are the following: | exchanges of messages as "modes". Among these are the following: | |||
| - "Main mode": One of IKE's two phase 1 modes. (See: ISAKMP.) | - "Main mode": One of IKE's two phase 1 modes. (See: ISAKMP.) | |||
| - "Quick mode": IKE's only phase 2 mode. (See: ISAKMP.) | - "Quick mode": IKE's only phase 2 mode. (See: ISAKMP.) | |||
| $ modulus | $ modulus | |||
| (I) The defining constant in modular arithmetic, and usually a | (I) The defining constant in modular arithmetic, and usually a | |||
| part of the public key in asymmetric cryptography that is based on | part of the public key in asymmetric cryptography that is based on | |||
| modular arithmetic. (See: Diffie-Hellman, RSA.) | modular arithmetic. (See: Diffie-Hellman-Merkle, RSA.) | |||
| $ Mondex | $ Mondex | |||
| (O) A smartcard-based electronic money system that incorporates | (O) A smartcard-based electronic money system that incorporates | |||
| cryptography and can be used to make payments via the Internet. | cryptography and can be used to make payments via the Internet. | |||
| (See: IOTP.) | (See: IOTP.) | |||
| $ Morris Worm | $ Morris Worm | |||
| (I) A worm program that flooded the ARPANET in November, 1988, | (I) A worm program that flooded the ARPANET in November, 1988, | |||
| causing problems for thousands of hosts. [R1135] (See: community | causing problems for thousands of hosts. [R1135] (See: community | |||
| risk, worm) | risk, worm) | |||
| $ MOSS | $ MOSS | |||
| (I) See: MIME Object Security Services. | (I) See: MIME Object Security Services. | |||
| $ MQV | $ MQV | |||
| (N) A key-agreement protocol [Mene] that was proposed by A.J. | (N) A key-agreement protocol [Mene] that was proposed by A.J. | |||
| Menezes, M. Qu, and S.A. Vanstone in 1995 and is based on the | Menezes, M. Qu, and S.A. Vanstone in 1995 and is based on the | |||
| Diffie-Hellman algorithm. | Diffie-Hellman-Merkle algorithm. | |||
| $ MSP | $ MSP | |||
| (N) See: Message Security Protocol. | (N) See: Message Security Protocol. | |||
| $ multicast security | $ multicast security | |||
| See: secure multicast | See: secure multicast | |||
| $ Multics | $ Multics | |||
| (N) MULTiplexed Information and Computing Service, an MLS computer | (N) MULTiplexed Information and Computing Service, an MLS computer | |||
| timesharing system designed and implemented during 1965-69 by a | timesharing system designed and implemented during 1965-69 by a | |||
| skipping to change at page 176, line 21 ¶ | skipping to change at page 180, line 23 ¶ | |||
| (I) Synonym for "identifier". | (I) Synonym for "identifier". | |||
| $ naming authority | $ naming authority | |||
| (O) /U.S. DoD/ An organizational entity responsible for assigning | (O) /U.S. DoD/ An organizational entity responsible for assigning | |||
| DNs and for assuring that each DN is meaningful and unique within | DNs and for assuring that each DN is meaningful and unique within | |||
| its domain. [DoD9] | its domain. [DoD9] | |||
| $ National Computer Security Center (NCSC) | $ National Computer Security Center (NCSC) | |||
| (O) A U.S. DoD organization, housed in NSA, that has | (O) A U.S. DoD organization, housed in NSA, that has | |||
| responsibility for encouraging widespread availability of trusted | responsibility for encouraging widespread availability of trusted | |||
| computer systems throughout the Federal Government. It has | systems throughout the Federal Government. It has established | |||
| established criteria for, and performed evaluations of, computer | criteria for, and performed evaluations of, computer and network | |||
| and network systems that have a TCB. (See: Evaluated Products | systems that have a TCB. (See: Evaluated Products List, Rainbow | |||
| List, Rainbow Series, TCSEC.) | Series, TCSEC.) | |||
| $ National Information Assurance Partnership (NIAP) | $ National Information Assurance Partnership (NIAP) | |||
| (N) An joint initiative of NIST and NSA to enhance the quality of | (N) An joint initiative of NIST and NSA to enhance the quality of | |||
| commercial products for information security and increase consumer | commercial products for information security and increase consumer | |||
| confidence in those products through objective evaluation and | confidence in those products through objective evaluation and | |||
| testing methods. | testing methods. | |||
| Tutorial: NIAP is registered, through the U.S. DoD, as a National | Tutorial: NIAP is registered, through the U.S. DoD, as a National | |||
| Performance Review Reinvention Laboratory. NIAP functions include | Performance Review Reinvention Laboratory. NIAP functions include | |||
| the following: | the following: | |||
| skipping to change at page 177, line 5 ¶ | skipping to change at page 181, line 6 ¶ | |||
| - Working to establish a formal, international mutual recognition | - Working to establish a formal, international mutual recognition | |||
| scheme for a Common Criteria-based evaluation. | scheme for a Common Criteria-based evaluation. | |||
| $ National Institute of Standards and Technology (NIST) | $ National Institute of Standards and Technology (NIST) | |||
| (N) A U.S. Department of Commerce organization that promotes U.S. | (N) A U.S. Department of Commerce organization that promotes U.S. | |||
| economic growth by working with industry to develop and apply | economic growth by working with industry to develop and apply | |||
| technology, measurements, and standards. Has primary Government | technology, measurements, and standards. Has primary Government | |||
| responsibility for INFOSEC standards for sensitive unclassified | responsibility for INFOSEC standards for sensitive unclassified | |||
| information. (See: ANSI, DES, DSA, DSS, FIPS, NIAP, NSA.) | information. (See: ANSI, DES, DSA, DSS, FIPS, NIAP, NSA.) | |||
| $ National Reliability and Interoperability Council (NRIC) | ||||
| (N) An advisory committee chartered by the U.S. Federal | ||||
| Communications Commission (FCC), with participation by network | ||||
| service providers and vendors, to provide recommendations to the | ||||
| FCC for assuring reliability, interoperability, robustness, and | ||||
| security of wireless, wireline, satellite, cable, and public data | ||||
| communication networks. | ||||
| $ national security | $ national security | |||
| (O) /U.S. Government/ The national defense or foreign relations of | (O) /U.S. Government/ The national defense or foreign relations of | |||
| the United States of America. | the United States of America. | |||
| $ National Security Agency (NSA) | $ National Security Agency (NSA) | |||
| (N) A U.S. DoD organization that has primary Government | (N) A U.S. DoD organization that has primary Government | |||
| responsibility for INFOSEC standards for classified information | responsibility for INFOSEC standards for classified information | |||
| and for sensitive unclassified information handled by national | and for sensitive unclassified information handled by national | |||
| security systems. (See: FORTEZZA, KEA, MISSI, national security | security systems. (See: FORTEZZA, KEA, MISSI, national security | |||
| system, NIAP, NIST, SKIPJACK.) | system, NIAP, NIST, SKIPJACK.) | |||
| skipping to change at page 177, line 35 ¶ | skipping to change at page 181, line 44 ¶ | |||
| related to national security; (c) involves command and control of | related to national security; (c) involves command and control of | |||
| military forces; (d) involves equipment that is an integral part | military forces; (d) involves equipment that is an integral part | |||
| of a weapon or weapon system; or (e) is critical to the direct | of a weapon or weapon system; or (e) is critical to the direct | |||
| fulfillment of military or intelligence missions and does not | fulfillment of military or intelligence missions and does not | |||
| include a system that is to be used for routine administrative and | include a system that is to be used for routine administrative and | |||
| business applications (including payroll, finance, logistics, and | business applications (including payroll, finance, logistics, and | |||
| personnel management applications). [Title 40 U.S.C. Section 1552, | personnel management applications). [Title 40 U.S.C. Section 1552, | |||
| Information Technology Management Reform Act of 1996.] (See: type | Information Technology Management Reform Act of 1996.] (See: type | |||
| 2 product.) | 2 product.) | |||
| $ natural disaster | ||||
| (I) /threat action/ See: secondary definition under "corruption" | ||||
| and "incapacitation". | ||||
| $ NCSC | $ NCSC | |||
| (O) See: National Computer Security Center. | (O) See: National Computer Security Center. | |||
| $ need to know, need-to-know | $ need to know, need-to-know | |||
| (I) The necessity for access to, knowledge of, or possession of | (I) The necessity for access to, knowledge of, or possession of | |||
| specific information required to carry out official duties. | specific information required to carry out official duties. | |||
| Usage: The compound "need-to-know" is used as both an adjective | Usage: The compound "need-to-know" is used as both an adjective | |||
| and a noun. | and a noun. | |||
| skipping to change at page 178, line 13 ¶ | skipping to change at page 182, line 27 ¶ | |||
| (I) See: Internet Protocol Suite. | (I) See: Internet Protocol Suite. | |||
| $ Network Interface Layer | $ Network Interface Layer | |||
| (I) See: Internet Protocol Suite. | (I) See: Internet Protocol Suite. | |||
| $ Network Layer Security Protocol (NLSP). | $ Network Layer Security Protocol (NLSP). | |||
| (N) An OSI protocol (IS0 11577) for end-to-end encryption services | (N) An OSI protocol (IS0 11577) for end-to-end encryption services | |||
| at the top of OSIRM Layer 3. NLSP is derived from SP3 but is more | at the top of OSIRM Layer 3. NLSP is derived from SP3 but is more | |||
| complex. (Compare: IPsec.) | complex. (Compare: IPsec.) | |||
| $ National Reliability and Interoperability Council (NRIC) | ||||
| (N) An advisory committee chartered by the U.S. Federal | ||||
| Communications Commission (FCC), with participation by network | ||||
| service providers and vendors, to provide recommendations to the | ||||
| FCC for assuring reliability, interoperability, robustness, and | ||||
| security of wireless, wireline, satellite, cable, and public data | ||||
| communication networks. | ||||
| $ Network Substrate Layer | $ Network Substrate Layer | |||
| (I) Synonym for "Network Hardware Layer". | (I) Synonym for "Network Hardware Layer". | |||
| $ network weaving | $ network weaving | |||
| (I) A penetration technique in which an intruder avoids detection | (I) A penetration technique in which an intruder avoids detection | |||
| and traceback by using multiple linked communication networks to | and traceback by using multiple linked communication networks to | |||
| access and attack a system. [C4009] | access and attack a system. [C4009] | |||
| $ NIAP | $ NIAP | |||
| (N) See: National Information Assurance Partnership. | (N) See: National Information Assurance Partnership. | |||
| skipping to change at page 181, line 49 ¶ | skipping to change at page 185, line 55 ¶ | |||
| $ NULL encryption algorithm | $ NULL encryption algorithm | |||
| (I) An algorithm [R2410] that is specified as doing nothing to | (I) An algorithm [R2410] that is specified as doing nothing to | |||
| transform plaintext data; i.e., a no-op. It originated because ESP | transform plaintext data; i.e., a no-op. It originated because ESP | |||
| always specifies the use of an encryption algorithm for | always specifies the use of an encryption algorithm for | |||
| confidentiality. The NULL encryption algorithm is a convenient way | confidentiality. The NULL encryption algorithm is a convenient way | |||
| to represent the option of not applying encryption in ESP (or in | to represent the option of not applying encryption in ESP (or in | |||
| any other context where a no-op is needed). (Compare: null.) | any other context where a no-op is needed). (Compare: null.) | |||
| $ OAKLEY | $ OAKLEY | |||
| (I) A key establishment protocol (proposed for IPsec but | (I) A key establishment protocol (proposed for IPsec but | |||
| superseded by IKE) based on the Diffie-Hellman algorithm and | superseded by IKE) based on the Diffie-Hellman-Merkle algorithm | |||
| designed to be a compatible component of ISAKMP. [R2412] | and designed to be a compatible component of ISAKMP. [R2412] | |||
| Tutorial: OAKLEY establishes a shared key with an assigned | Tutorial: OAKLEY establishes a shared key with an assigned | |||
| identifier and associated authenticated identities for parties; | identifier and associated authenticated identities for parties; | |||
| i.e., OAKLEY provides authentication service to ensure the | i.e., OAKLEY provides authentication service to ensure the | |||
| entities of each other's identity, even if the Diffie-Hellman | entities of each other's identity, even if the Diffie-Hellman- | |||
| exchange is threatened by active wiretapping. Also, it provides | Merkle exchange is threatened by active wiretapping. Also, it | |||
| public-key forward secrecy for the shared key and supports key | provides public-key forward secrecy for the shared key and | |||
| updates, incorporation of keys distributed by out-of-band | supports key updates, incorporation of keys distributed by out-of- | |||
| mechanisms, and user-defined abstract group structures for use | band mechanisms, and user-defined abstract group structures for | |||
| with Diffie-Hellman. | use with Diffie-Hellman-Merkle. | |||
| $ object | $ object | |||
| (I) /formal model/ Trusted computer system modeling usage: A | (I) /formal model/ Trusted-system modeling usage: A system | |||
| system component that contains or receives information. (See: | component that contains or receives information. (See: Bell- | |||
| Bell-LaPadula model, trusted computer system.) | LaPadula model, trusted system.) | |||
| $ object identifier (OID) | $ object identifier (OID) | |||
| 1. (N) An official, globally unique name for a thing, written as a | 1. (N) An official, globally unique name for a thing, written as a | |||
| sequence of integers (which are formed and assigned as defined in | sequence of integers (which are formed and assigned as defined in | |||
| the ASN.1 standard) and used to reference the thing in abstract | the ASN.1 standard) and used to reference the thing in abstract | |||
| specifications and during negotiation of security services in a | specifications and during negotiation of security services in a | |||
| protocol. | protocol. | |||
| 2. (O) "A value (distinguishable from all other such values) which | 2. (O) "A value (distinguishable from all other such values) which | |||
| is associated with an object." [X680] | is associated with an object." [X680] | |||
| skipping to change at page 183, line 54 ¶ | skipping to change at page 188, line 8 ¶ | |||
| Deprecated Usage: ISDs SHOULD NOT use this term; it is a joke for | Deprecated Usage: ISDs SHOULD NOT use this term; it is a joke for | |||
| English speakers. (See: Deprecated Usage under "Green Book".) | English speakers. (See: Deprecated Usage under "Green Book".) | |||
| $ OID | $ OID | |||
| (N) See: object identifier. | (N) See: object identifier. | |||
| $ On-line Certificate Status Protocol (OCSP) | $ On-line Certificate Status Protocol (OCSP) | |||
| (I) An Internet protocol [R2560] used by a client to obtain from a | (I) An Internet protocol [R2560] used by a client to obtain from a | |||
| server the validity status and other information about a digital | server the validity status and other information about a digital | |||
| certificate. | certificate. (Mentioned in [X509] but not specified there.) | |||
| Tutorial: In some applications, such as those involving high-value | Tutorial: In some applications, such as those involving high-value | |||
| commercial transactions, it may be necessary either (a) to obtain | commercial transactions, it may be necessary either (a) to obtain | |||
| certificate revocation status that is more timely than is possible | certificate revocation status that is more timely than is possible | |||
| with CRLs or (b) to obtain other kinds of status information. OCSP | with CRLs or (b) to obtain other kinds of status information. OCSP | |||
| may be used to determine the current revocation status of a | may be used to determine the current revocation status of a | |||
| digital certificate, in lieu of or as a supplement to checking | digital certificate, in lieu of or as a supplement to checking | |||
| against a periodic CRL. An OCSP client issues a status request to | against a periodic CRL. An OCSP client issues a status request to | |||
| an OCSP server and suspends acceptance of the certificate in | an OCSP server and suspends acceptance of the certificate in | |||
| question until the server provides a response. | question until the server provides a response. | |||
| skipping to change at page 184, line 38 ¶ | skipping to change at page 188, line 45 ¶ | |||
| it impractical except in special situations. | it impractical except in special situations. | |||
| $ one-time password, One-Time Password (OTP) | $ one-time password, One-Time Password (OTP) | |||
| 1. (I) /not capitalized/ A "one-time password" is a simple | 1. (I) /not capitalized/ A "one-time password" is a simple | |||
| authentication technique in which each password is used only once | authentication technique in which each password is used only once | |||
| as authentication information that verifies an identity. This | as authentication information that verifies an identity. This | |||
| technique counters the threat of a replay attack that uses | technique counters the threat of a replay attack that uses | |||
| passwords captured by wiretapping. | passwords captured by wiretapping. | |||
| 2. (I) /capitalized/ "One-Time Password" is an Internet protocol | 2. (I) /capitalized/ "One-Time Password" is an Internet protocol | |||
| [R1938] that is based on S/KEY and uses a cryptographic hash | [R2289] that is based on S/KEY and uses a cryptographic hash | |||
| function to generate one-time passwords for use as authentication | function to generate one-time passwords for use as authentication | |||
| information in system login and in other processes that need | information in system login and in other processes that need | |||
| protection against replay attacks. | protection against replay attacks. | |||
| $ one-way encryption | $ one-way encryption | |||
| (I) Irreversible transformation of plain text to cipher text, such | (I) Irreversible transformation of plain text to cipher text, such | |||
| that the plain text cannot be recovered from the cipher text by | that the plain text cannot be recovered from the cipher text by | |||
| other than exhaustive procedures even if the cryptographic key is | other than exhaustive procedures even if the cryptographic key is | |||
| known. (See: brute force, encryption.) | known. (See: brute force, encryption.) | |||
| skipping to change at page 187, line 4 ¶ | skipping to change at page 191, line 10 ¶ | |||
| $ operational integrity | $ operational integrity | |||
| (I) Synonym for "system integrity"; this synonym emphasizes the | (I) Synonym for "system integrity"; this synonym emphasizes the | |||
| actual performance of system functions rather than just the | actual performance of system functions rather than just the | |||
| ability to perform them. | ability to perform them. | |||
| $ operational security | $ operational security | |||
| 1. (I) System capabilities, or performance of system functions, | 1. (I) System capabilities, or performance of system functions, | |||
| that are needed either (a) to securely manage a system or (b) to | that are needed either (a) to securely manage a system or (b) to | |||
| manage security features of a system. (Compare: operations | manage security features of a system. (Compare: operations | |||
| security (OPSEC).) | security (OPSEC).) | |||
| Usage: ISDs that use this term SHOULD state a definition because | Usage: ISDs that use this term SHOULD state a definition because | |||
| (a) the definition provide here is general and vague and (b) the | (a) the definition provided here is general and vague and (b) the | |||
| term could easily be confused with "operations security", which is | term could easily be confused with "operations security", which is | |||
| a different concept. | a different concept. | |||
| Tutorial: For example, in the context of an Internet service | Tutorial: For example, in the context of an Internet service | |||
| provider, the term could refer to capabilities to manage network | provider, the term could refer to capabilities to manage network | |||
| devices in the event of attacks, simplify troubleshooting, keep | devices in the event of attacks, simplify troubleshooting, keep | |||
| track of events that affect system integrity, help analyze sources | track of events that affect system integrity, help analyze sources | |||
| of attacks, and provide administrators with control over network | of attacks, and provide administrators with control over network | |||
| addresses and protocols to help mitigate the most common attacks | addresses and protocols to help mitigate the most common attacks | |||
| and exploits. [R3871] | and exploits. [R3871] | |||
| skipping to change at page 190, line 25 ¶ | skipping to change at page 194, line 51 ¶ | |||
| Tutorial: Out-of-band mechanisms are often used to distribute | Tutorial: Out-of-band mechanisms are often used to distribute | |||
| shared secrets (e.g., a symmetric key) or other sensitive | shared secrets (e.g., a symmetric key) or other sensitive | |||
| information items (e.g., a root key) that are needed to initialize | information items (e.g., a root key) that are needed to initialize | |||
| or otherwise enable the operation of cryptography or other | or otherwise enable the operation of cryptography or other | |||
| security mechanisms. Example: Using postal mail to distribute | security mechanisms. Example: Using postal mail to distribute | |||
| printed or magnetic media containing symmetric cryptographic keys | printed or magnetic media containing symmetric cryptographic keys | |||
| for use in Internet encryption devices. (See: key distribution.) | for use in Internet encryption devices. (See: key distribution.) | |||
| $ output feedback (OFB) | $ output feedback (OFB) | |||
| (N) A block cipher mode [FP081] that modifies ECB mode to operate | (N) A block cipher mode that modifies ECB mode to operate on | |||
| on plaintext segments of variable length less than or equal to the | plaintext segments of variable length less than or equal to the | |||
| block length. | block length. [FP081] (See: block cipher, [SP38A].) | |||
| Tutorial: This mode operates by directly using the algorithm's | Tutorial: This mode operates by directly using the algorithm's | |||
| previously generated output block as the algorithm's next input | previously generated output block as the algorithm's next input | |||
| block (i.e., by "feeding back" the output block) and combining | block (i.e., by "feeding back" the output block) and combining | |||
| (exclusive OR-ing) the output block with the next plaintext | (exclusive OR-ing) the output block with the next plaintext | |||
| segment (of block length or less) to form the next ciphertext | segment (of block length or less) to form the next ciphertext | |||
| segment. | segment. | |||
| $ outside attack | $ outside attack | |||
| (I) See: secondary definition under "attack". Compare: outsider.) | (I) See: secondary definition under "attack". Compare: outsider.) | |||
| skipping to change at page 191, line 13 ¶ | skipping to change at page 195, line 37 ¶ | |||
| (I) /threat action/ See: secondary definition under "obstruction". | (I) /threat action/ See: secondary definition under "obstruction". | |||
| $ P1363 | $ P1363 | |||
| (N) See: IEEE P1363. | (N) See: IEEE P1363. | |||
| $ PAA | $ PAA | |||
| (O) See: policy approving authority. | (O) See: policy approving authority. | |||
| $ package | $ package | |||
| (N) /Common Criteria/ A reusable set of either functional or | (N) /Common Criteria/ A reusable set of either functional or | |||
| assurance components (e.g. an EAL), combined in a single unit to | assurance components, combined in a single unit to satisfy a set | |||
| satisfy a set of identified security objectives. Example: The | of identified security objectives. (Compare: protection profile.) | |||
| seven EALs defined in Part 3 of the Common Criteria are predefined | ||||
| assurance packages. (Compare: protection profile.) | Example: The seven EALs defined in Part 3 of the Common Criteria | |||
| are predefined assurance packages. | ||||
| Tutorial: A package is a combination of security requirement | Tutorial: A package is a combination of security requirement | |||
| components and is intended to be reusable in the construction of | components and is intended to be reusable in the construction of | |||
| either more complex packages or protection profiles and security | either more complex packages or protection profiles and security | |||
| targets. A package expresses a set of either functional or | targets. A package expresses a set of either functional or | |||
| assurance requirements that meet some particular need, expressed | assurance requirements that meet some particular need, expressed | |||
| as a set of security objectives. | as a set of security objectives. | |||
| $ packet | $ packet | |||
| (I) A block of data that is carried from a source to a destination | (I) A block of data that is carried from a source to a destination | |||
| skipping to change at page 195, line 30 ¶ | skipping to change at page 200, line 5 ¶ | |||
| $ PEM | $ PEM | |||
| (I) See: Privacy Enhanced Mail. | (I) See: Privacy Enhanced Mail. | |||
| $ penetrate | $ penetrate | |||
| 1a. (I) Circumvent a system's security protections. (See: attack, | 1a. (I) Circumvent a system's security protections. (See: attack, | |||
| break, violation.) | break, violation.) | |||
| 1b. (I) Successfully and repeatedly gain unauthorized access to a | 1b. (I) Successfully and repeatedly gain unauthorized access to a | |||
| protected system resource. [Huff] | protected system resource. [Huff] | |||
| $ penetration | ||||
| (I) /threat action/ See: secondary definition under "intrusion". | ||||
| $ penetration test | $ penetration test | |||
| (I) A system test, often part of system certification, in which | (I) A system test, often part of system certification, in which | |||
| evaluators attempt to circumvent the security features of a | evaluators attempt to circumvent the security features of a | |||
| system. [NCS04, SP42] (See: tiger team.) | system. [NCS04, SP42] (See: tiger team.) | |||
| Tutorial: Penetration testing evaluates the relative vulnerability | Tutorial: Penetration testing evaluates the relative vulnerability | |||
| of a system to attacks and identifies methods of gaining access to | of a system to attacks and identifies methods of gaining access to | |||
| a system by using tools and techniques that are available to | a system by using tools and techniques that are available to | |||
| adversaries. Testing may be performed under various constraints | adversaries. Testing may be performed under various constraints | |||
| and conditions, including a specified level of knowledge of the | and conditions, including a specified level of knowledge of the | |||
| system design and implementation. For a TCSEC evaluation, testers | system design and implementation. For a TCSEC evaluation, testers | |||
| are assumed to have all system design and implementation | are assumed to have all system design and implementation | |||
| documentation, including source code, manuals, and circuit | documentation, including source code, manuals, and circuit | |||
| diagrams, and to work under no greater constraints than those | diagrams, and to work under no greater constraints than those | |||
| applied to ordinary users. | applied to ordinary users. | |||
| $ perfect forward secrecy | $ perfect forward secrecy | |||
| (I) See: Usage under "public-key forward secrecy". | (I) For a key agreement protocol, the property that compromise of | |||
| long-term keying material does not compromise session keys that | ||||
| were previously derived from the long-term material. (Compare: | ||||
| public-key forward secrecy.) | ||||
| Usage: Some existing RFCs use this term but either do not define | ||||
| it or do not define it precisely. While preparing this Glossary, | ||||
| we found this to be a muddled area. Experts did not agree. For all | ||||
| practical purposes, the literature defines "perfect forward | ||||
| secrecy" by stating the Diffie-Hellman-Merkle algorithm. The term | ||||
| "public-key forward secrecy" (suggested by Hilarie Orman) and the | ||||
| definition stated for it in this Glossary were crafted to be | ||||
| compatible with current Internet documents, yet be narrow and | ||||
| leave room for improved terminology. | ||||
| Challenge to the Internet security community: We need a taxonomy | ||||
| of terms and definitions to cover the basic properties discussed | ||||
| here for the full range of cryptographic algorithms and protocols | ||||
| used in Internet Standards: | ||||
| Involvement of session keys vs. long-term keys: Experts disagree | ||||
| about the basic ideas involved: | ||||
| - One concept of "forward secrecy" is that, given observations of | ||||
| the operation of a key establishment protocol up to time t, and | ||||
| given some of the session keys derived from those protocol | ||||
| runs, you cannot derive unknown past session keys or future | ||||
| session keys. | ||||
| - A related property is that, given observations of the protocol | ||||
| and knowledge of the derived session keys, you cannot derive | ||||
| one or more of the long-term private keys. | ||||
| - The "I" definition presented above involves a third concept of | ||||
| "forward secrecy" that refers to the effect of the compromise | ||||
| of long-term keys. | ||||
| - All three concepts involve the idea that a compromise of "this" | ||||
| encryption key is not supposed to compromise the "next" one. | ||||
| There also is the idea that compromise of a single key will | ||||
| compromise only the data protected by the single key. In | ||||
| Internet literature, the focus has been on protection against | ||||
| decryption of back traffic in the event of a compromise of | ||||
| secret key material held by one or both parties to a | ||||
| communication. | ||||
| Forward vs. backward: Experts are unhappy with the word "forward", | ||||
| because compromise of "this" encryption key also is not supposed | ||||
| to compromise the "previous" one, which is "backward" rather than | ||||
| forward. In S/KEY, if the key used at time t is compromised, then | ||||
| all keys used prior to that are compromised. If the "long-term" | ||||
| key (i.e., the base of the hashing scheme) is compromised, then | ||||
| all keys past and future are compromised; thus, you could say that | ||||
| S/KEY has neither forward nor backward secrecy. | ||||
| Asymmetric cryptography vs. symmetric: Experts disagree about | ||||
| forward secrecy in the context of symmetric cryptographic systems. | ||||
| In the absence of asymmetric cryptography, compromise of any long- | ||||
| term key seems to compromise any session key derived from the | ||||
| long-term key. For example, Kerberos isn't forward secret, because | ||||
| compromising a client's password (thus compromising the key shared | ||||
| by the client and the authentication server) compromises future | ||||
| session keys shared by the client and the ticket-granting server. | ||||
| Ordinary forward secrecy vs. "perfect" forward secret: Experts | ||||
| disagree about the difference between these two. Some say there is | ||||
| no difference, and some say that the initial naming was | ||||
| unfortunate and suggest dropping the word "perfect". Some suggest | ||||
| using "forward secrecy" for the case where one long-term private | ||||
| key is compromised, and adding "perfect" for when both private | ||||
| keys (or, when the protocol is multi-party, all private keys) are | ||||
| compromised. | ||||
| Acknowledgements: Bill Burr, Burt Kaliski, Steve Kent, Paul Van | ||||
| Oorschot, Jonathan Trostle, Michael Wiener, and, especially, | ||||
| Hilarie Orman contributed ideas to this discussion. | ||||
| $ perimeter | $ perimeter | |||
| See: security perimeter. | See: security perimeter. | |||
| $ periods processing | $ periods processing | |||
| (I) A mode of system operation in which information of different | (I) A mode of system operation in which information of different | |||
| sensitivities is processed at distinctly different times by the | sensitivities is processed at distinctly different times by the | |||
| same system, with the system being properly purged or sanitized | same system, with the system being properly purged or sanitized | |||
| between periods. (See: color change.) | between periods. (See: color change.) | |||
| Tutorial: The security mode of operation and maximum | Tutorial: The security mode of operation and maximum | |||
| classification of data handled by the system is established for an | classification of data handled by the system is established for an | |||
| interval of time and then is changed for the following interval of | interval of time and then is changed for the following interval of | |||
| time. A period extends from the secure initialization of the | time. A period extends from the secure initialization of the | |||
| system to the completion of any purging of sensitive data handled | system to the completion of any purging of sensitive data handled | |||
| by the system during the period. | by the system during the period. | |||
| $ permanent storage | $ permanent storage | |||
| (I) Non-volatile media that, once written into, can never be | (I) Non-volatile media that, once written into, can never be | |||
| completely erased. | completely erased. | |||
| skipping to change at page 197, line 4 ¶ | skipping to change at page 202, line 53 ¶ | |||
| certificates would establish procedures (d) to enable "the holder | certificates would establish procedures (d) to enable "the holder | |||
| of a PERSONA certificate to request that his certificate be | of a PERSONA certificate to request that his certificate be | |||
| revoked" and (e) to ensure that it did not issue the same subject | revoked" and (e) to ensure that it did not issue the same subject | |||
| DN to multiple users. The latter condition implies that a persona | DN to multiple users. The latter condition implies that a persona | |||
| certificate is not an organizational certificate unless the | certificate is not an organizational certificate unless the | |||
| organization has just one member or representative. | organization has just one member or representative. | |||
| $ personal identification number (PIN) | $ personal identification number (PIN) | |||
| 1a. (I) A character string used as a password to gain access to a | 1a. (I) A character string used as a password to gain access to a | |||
| system resource. (See: authentication information.) | system resource. (See: authentication information.) | |||
| Example: A cryptographic token typically requires its user to | ||||
| enter a PIN in order to access information stored in the token and | ||||
| invoke the token's cryptographic functions. | ||||
| 1b. (O) An alphanumeric code or password used to authenticate an | 1b. (O) An alphanumeric code or password used to authenticate an | |||
| identity. | identity. | |||
| Tutorial: Despite the words "identification" and "number", a PIN | Tutorial: Despite the words "identification" and "number", a PIN | |||
| seldom serves as a user identifier, and a PIN's characters are not | seldom serves as a user identifier, and a PIN's characters are not | |||
| necessarily all numeric. Retail banking applications use 4-digit | necessarily all numeric. Retail banking applications use 4-digit | |||
| numeric user PINs, but the FORTEZZA PC card uses 12-character | numeric user PINs, but the FORTEZZA PC card uses 12-character | |||
| alphanumeric SSO PINs. | alphanumeric SSO PINs. (See: SSO PIN, user PIN.) | |||
| Thus, a better name for this concept would have been "personnel | A better name for this concept would have been "personnel | |||
| authentication system string" (PASS), in which case an | authentication system string" (PASS), in which case an | |||
| alphanumeric character string for this purpose would have been | alphanumeric character string for this purpose would have been | |||
| called, obviously, a "PASSword". | called, obviously, a "PASSword". | |||
| $ personal information | $ personal information | |||
| (I) Information about a particular person, especially information | (I) Information about a particular person, especially information | |||
| of an intimate or critical nature, that could cause harm or pain | of an intimate or critical nature, that could cause harm or pain | |||
| to that person if disclosed to unauthorized parties. Examples: | to that person if disclosed to unauthorized parties. Examples: | |||
| medical record, arrest record, credit report, academic transcript, | medical record, arrest record, credit report, academic transcript, | |||
| training report, job application, credit card number, Social | training report, job application, credit card number, Social | |||
| skipping to change at page 198, line 22 ¶ | skipping to change at page 204, line 23 ¶ | |||
| $ phishing | $ phishing | |||
| (D) /slang/ A technique for attempting to acquire sensitive data, | (D) /slang/ A technique for attempting to acquire sensitive data, | |||
| such as bank account numbers, through a fraudulent solicitation in | such as bank account numbers, through a fraudulent solicitation in | |||
| email or on a Web site, in which the perpetrator masquerades as a | email or on a Web site, in which the perpetrator masquerades as a | |||
| legitimate business or reputable person. (See: social | legitimate business or reputable person. (See: social | |||
| engineering.) | engineering.) | |||
| Derivation: Possibly from "phony fishing"; the solicitation | Derivation: Possibly from "phony fishing"; the solicitation | |||
| usually involves some kind of lure or bait to hook unwary | usually involves some kind of lure or bait to hook unwary | |||
| recipients. | recipients. (Compare: phreaking.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term; it is not listed | Deprecated Term: ISDs SHOULD NOT use this term; it is not listed | |||
| in most dictionaries and could confuse international readers. | in most dictionaries and could confuse international readers. | |||
| (See: Deprecated Usage under "Green Book.") | (See: Deprecated Usage under "Green Book.") | |||
| $ Photuris | $ Photuris | |||
| (I) A UDP-based, key establishment protocol for session keys, | (I) A UDP-based, key establishment protocol for session keys, | |||
| designed for use with the IPsec protocols AH and ESP. Superseded | designed for use with the IPsec protocols AH and ESP. Superseded | |||
| by IKE. | by IKE. | |||
| $ phreaking | $ phreaking | |||
| (D) A contraction of "telephone breaking". An attack on or | (D) A contraction of "telephone breaking". An attack on or | |||
| penetration of a telephone system or, by extension, any other | penetration of a telephone system or, by extension, any other | |||
| communication or information system. [Raym] | communication or information system. [Raym] | |||
| Deprecated Term: ISDs SHOULD NOT use this contraction; it is not | Deprecated Term: ISDs SHOULD NOT use this contraction; it is not | |||
| listed in most dictionaries and could confuse international | listed in most dictionaries and could confuse international | |||
| readers. (See: Deprecated Usage under "Green Book.") | readers. (See: Deprecated Usage under "Green Book.") | |||
| $ physical destruction | ||||
| (I) /threat action/ See: secondary definition under | ||||
| "incapacitation". | ||||
| $ physical security | $ physical security | |||
| (I) Tangible means of preventing unauthorized physical access to a | (I) Tangible means of preventing unauthorized physical access to a | |||
| system. Examples: Fences, walls, and other barriers; locks, safes, | system. Examples: Fences, walls, and other barriers; locks, safes, | |||
| and vaults; dogs and armed guards; sensors and alarm bells. | and vaults; dogs and armed guards; sensors and alarm bells. | |||
| [FP031, R1455] | [FP031, R1455] | |||
| $ piggyback attack | $ piggyback attack | |||
| (I) A form of active wiretapping in which the attacker gains | (I) A form of active wiretapping in which the attacker gains | |||
| access to a system via intervals of inactivity in another user's | access to a system via intervals of inactivity in another user's | |||
| legitimate communication connection. Sometimes called a "between- | legitimate communication connection. Sometimes called a "between- | |||
| skipping to change at page 199, line 33 ¶ | skipping to change at page 205, line 39 ¶ | |||
| $ ping sweep | $ ping sweep | |||
| (I) An attack that sends ICMP echo requests ("pings") to a range | (I) An attack that sends ICMP echo requests ("pings") to a range | |||
| of IP addresses, with the goal of finding hosts that can be probed | of IP addresses, with the goal of finding hosts that can be probed | |||
| for vulnerabilities. (See: ping of death. Compare: port scan.) | for vulnerabilities. (See: ping of death. Compare: port scan.) | |||
| $ PKCS | $ PKCS | |||
| (N) See: Public-Key Cryptography Standards. | (N) See: Public-Key Cryptography Standards. | |||
| $ PKCS #5 | $ PKCS #5 | |||
| (N) A standard [PKC05, R2898] from the PKCS series; defines a | (N) A standard [PKC05] (see: RFC 2898) from the PKCS series; | |||
| method for encrypting an octet string with a secret key derived | defines a method for encrypting an octet string with a secret key | |||
| from a password. | derived from a password. | |||
| Tutorial: Although the method can be used for arbitrary octet | Tutorial: Although the method can be used for arbitrary octet | |||
| strings, its intended primary application in public-key | strings, its intended primary application in public-key | |||
| cryptography is for encrypting private keys when transferring them | cryptography is for encrypting private keys when transferring them | |||
| from one computer system to another, as described in PKCS #8. | from one computer system to another, as described in PKCS #8. | |||
| $ PKCS #7 | $ PKCS #7 | |||
| (N) A standard [PKC07, R2315] from the PKCS series; defines a | (N) A standard [PKC07] (see: RFC 2315) from the PKCS series; | |||
| syntax for data that may have cryptography applied to it, such as | defines a syntax for data that may have cryptography applied to | |||
| for digital signatures and digital envelopes. (See: CMS.) | it, such as for digital signatures and digital envelopes. (See: | |||
| CMS.) | ||||
| $ PKCS #10 | $ PKCS #10 | |||
| (N) A standard [PKC10] from the PKCS series; defines a syntax for | (N) A standard [PKC10] (see: RFC 2986) from the PKCS series; | |||
| requests for public-key certificates. (See: certification | defines a syntax for certification requests. (See: certification | |||
| request.) | request.) | |||
| Tutorial: A PKCS #10 request contains a DN and a public key, and | Tutorial: A PKCS #10 request contains a DN and a public key, and | |||
| may contain other attributes, and is signed by the entity making | may contain other attributes, and is signed by the entity making | |||
| the request. The request is sent to a CA, who converts it to an | the request. The request is sent to a CA, who converts it to an | |||
| X.509 public-key certificate (or some other form), and returns it, | X.509 public-key certificate (or some other form), and returns it, | |||
| possibly in PKCS #7 format. | possibly in PKCS #7 format. | |||
| $ PKCS #11 | $ PKCS #11 | |||
| (N) A standard [PKC11] from the PKCS series; defines CAPI called | (N) A standard [PKC11] from the PKCS series; defines CAPI called | |||
| "Cryptoki" for devices that hold cryptographic information and | "Cryptoki" for devices that hold cryptographic information and | |||
| perform cryptographic functions. | perform cryptographic functions. | |||
| $ PKI | $ PKI | |||
| (I) See: public-key infrastructure. | (I) See: public-key infrastructure. | |||
| $ PKINT | ||||
| (I) Abbreviation for "Public Key Cryptography for Initial | ||||
| Authentication in Kerberos" (RFC 4556). (See: Tutorial under | ||||
| "Kerberos".) | ||||
| $ PKIX | $ PKIX | |||
| 1a. (I) A contraction of "Public-Key Infrastructure (X.509)", the | 1a. (I) A contraction of "Public-Key Infrastructure (X.509)", the | |||
| name of the IETF working group that is specifying an architecture | name of the IETF working group that is specifying an architecture | |||
| [R3280] and set of protocols [R2510] to provide X.509-based PKI | [R3280] and set of protocols [R4210] to provide X.509-based PKI | |||
| services for the Internet. | services for the Internet. | |||
| 1b. (I) A collective name for that Internet PKI architecture and | 1b. (I) A collective name for that Internet PKI architecture and | |||
| associated set of protocols. | associated set of protocols. | |||
| Tutorial: The goal of PKIX is to facilitate the use of X.509 | Tutorial: The goal of PKIX is to facilitate the use of X.509 | |||
| public-key certificates in multiple Internet applications and to | public-key certificates in multiple Internet applications and to | |||
| promote interoperability between different implementations that | promote interoperability between different implementations that | |||
| use those certificates. The resulting PKI is intended to provide a | use those certificates. The resulting PKI is intended to provide a | |||
| framework that supports a range of trust and hierarchy | framework that supports a range of trust and hierarchy | |||
| skipping to change at page 200, line 39 ¶ | skipping to change at page 206, line 51 ¶ | |||
| profiles of the v3 X.509 public-key certificate standards and the | profiles of the v3 X.509 public-key certificate standards and the | |||
| v2 X.509 CRL standards for the Internet, (b) operational protocols | v2 X.509 CRL standards for the Internet, (b) operational protocols | |||
| used by relying parties to obtain information such as certificates | used by relying parties to obtain information such as certificates | |||
| or certificate status, (c) management protocols used by system | or certificate status, (c) management protocols used by system | |||
| entities to exchange information needed for proper management of | entities to exchange information needed for proper management of | |||
| the PKI, and (d) information about certificate policies and CPSs, | the PKI, and (d) information about certificate policies and CPSs, | |||
| covering the areas of PKI security not directly addressed in the | covering the areas of PKI security not directly addressed in the | |||
| rest of PKIX. | rest of PKIX. | |||
| $ plain text | $ plain text | |||
| (I) /noun/ Data that is input to and transformed by an encryption | 1. (I) /noun/ Data that is input to an encryption process. (See: | |||
| process, or that is output from a decryption process. (See: | ||||
| plaintext. Compare: cipher text, clear text.) | plaintext. Compare: cipher text, clear text.) | |||
| Tutorial: Usually, the plain text that is the input to an | 2. (D) /noun/ Synonym for "clear text". | |||
| encryption operation is clear text, but the input could be cipher | ||||
| text that was output from another encryption operation. (See: | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| superencryption.) | for "clear text". Sometimes plain text that is input to an | |||
| encryption operation is clear text, but other times plain text is | ||||
| cipher text that was output from a previous encryption operation. | ||||
| (See: superencryption.) | ||||
| $ plaintext | $ plaintext | |||
| 1. (I) /adjective/ Referring to plain text. (See: plain text. | 1. (O) /noun/ Synonym for "plain text". | |||
| Compare: ciphertext, cleartext.) | ||||
| 2. (D) /noun/ A synonym for plain text. | 2. (I) /adjective/ Referring to plain text. Usage: Commonly used | |||
| instead of "plain-text". (Compare: ciphertext, cleartext.) | ||||
| Deprecated Usage: ISDs should not use this term as a synonym for | 3. (D) /noun/ Synonym for "cleartext". | |||
| "plain text". ISDs SHOULD distinguish between the adjective | ||||
| "plaintext" and the noun phrase "plain text". | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "cleartext". Cleartext data is, by definition, not encrypted; | ||||
| but plaintext data that is input to an encryption operation may be | ||||
| cleartext data or may be ciphertext data that was output from a | ||||
| previous encryption operation. (See: superencryption.) | ||||
| $ PLI | $ PLI | |||
| (I) See: Private Line Interface. | (I) See: Private Line Interface. | |||
| $ PMA | $ PMA | |||
| (N) See: policy management authority. | (N) See: policy management authority. | |||
| $ Point-to-Point Protocol (PPP) | $ Point-to-Point Protocol (PPP) | |||
| (I) An Internet Standard protocol (RFC 1661) for encapsulation and | (I) An Internet Standard protocol (RFC 1661) for encapsulation and | |||
| full-duplex transportation of protocol data packets in OSIRM Layer | full-duplex transportation of protocol data packets in OSIRM Layer | |||
| skipping to change at page 202, line 38 ¶ | skipping to change at page 209, line 4 ¶ | |||
| control measurements are being gathered. Audit trails are | control measurements are being gathered. Audit trails are | |||
| examples of control measurements that are recorded as part of | examples of control measurements that are recorded as part of | |||
| system operations. | system operations. | |||
| - "Procedures" define how a system is operated, and relate | - "Procedures" define how a system is operated, and relate | |||
| closely to issues of what technology is used, who the operators | closely to issues of what technology is used, who the operators | |||
| are, and how the system is deployed physically. Procedures | are, and how the system is deployed physically. Procedures | |||
| define both normal and abnormal operating circumstances. | define both normal and abnormal operating circumstances. | |||
| - For every control defined by a practice statement, there should | - For every control defined by a practice statement, there should | |||
| be corresponding procedures to implement the control and | be corresponding procedures to implement the control and | |||
| provide ongoing measurement of the control parameters. | provide ongoing measurement of the control parameters. | |||
| Conversely, procedures require management practices to insure | Conversely, procedures require management practices to insure | |||
| consistent and correct operational behavior. | consistent and correct operational behavior. | |||
| $ policy approval authority | $ policy approval authority | |||
| (D) /PKI/ Synonym for "policy management authority". [PAG] | (D) /PKI/ Synonym for "policy management authority". [PAG] | |||
| Deprecated Term: IDSs SHOULD NOT use this term as synonym for | Deprecated Term: ISDs SHOULD NOT use this term as synonym for | |||
| "policy management authority". The term suggests a limited, | "policy management authority". The term suggests a limited, | |||
| passive role that is not typical of PMAs. | passive role that is not typical of PMAs. | |||
| $ policy approving authority (PAA) | $ policy approving authority (PAA) | |||
| (O) /MISSI/ The top-level signing authority of a MISSI | (O) /MISSI/ The top-level signing authority of a MISSI | |||
| certification hierarchy. The term refers both to that | certification hierarchy. The term refers both to that | |||
| authoritative office or role and to the person who plays that | authoritative office or role and to the person who plays that | |||
| role. (See: policy management authority, root registry.) | role. (See: policy management authority, root registry.) | |||
| Tutorial: A MISSI PAA (a) registers MISSI PCAs and signs their | Tutorial: A MISSI PAA (a) registers MISSI PCAs and signs their | |||
| X.509 public-key certificates, (b) issues CRLs but does not issue | X.509 public-key certificates, (b) issues CRLs but does not issue | |||
| a CKL, and (c) may issue cross-certificates to other PAAs. | a CKL, and (c) may issue cross-certificates to other PAAs. | |||
| $ policy authority | $ policy authority | |||
| (D) /PKI/ Synonym for "policy management authority". [PAG] | (D) /PKI/ Synonym for "policy management authority". [PAG] | |||
| Deprecated Term: IDSs SHOULD NOT use this term as synonym for | Deprecated Term: ISDs SHOULD NOT use this term as synonym for | |||
| "policy management authority". The term is unnecessarily vague and | "policy management authority". The term is unnecessarily vague and | |||
| thus may be confused with other PKI entities, such as CAs and RAs, | thus may be confused with other PKI entities, such as CAs and RAs, | |||
| that enforce of apply various aspects of PKI policy. | that enforce of apply various aspects of PKI policy. | |||
| $ policy certification authority (Internet PCA) | $ policy certification authority (Internet PCA) | |||
| (I) An X.509-compliant CA at the second level of the Internet | (I) An X.509-compliant CA at the second level of the Internet | |||
| certification hierarchy, under the IPRA. Each PCA operates in | certification hierarchy, under the IPRA. Each PCA operates in | |||
| accordance with its published security policy (see: certificate | accordance with its published security policy (see: certificate | |||
| policy, CPS) and within constraints established by the IPRA for | policy, CPS) and within constraints established by the IPRA for | |||
| all PCAs. [R1422]. (See: policy creation authority.) | all PCAs. [R1422]. (See: policy creation authority.) | |||
| skipping to change at page 204, line 43 ¶ | skipping to change at page 211, line 8 ¶ | |||
| server and provide other security services. (See: POP3 APOP, IMAP4 | server and provide other security services. (See: POP3 APOP, IMAP4 | |||
| AUTHENTICATE.) | AUTHENTICATE.) | |||
| Tutorial: If the server accepts the proposal, the command is | Tutorial: If the server accepts the proposal, the command is | |||
| followed by performing a challenge-response authentication | followed by performing a challenge-response authentication | |||
| protocol and, optionally, negotiating a protection mechanism for | protocol and, optionally, negotiating a protection mechanism for | |||
| subsequent POP3 interactions. The security mechanisms used by POP3 | subsequent POP3 interactions. The security mechanisms used by POP3 | |||
| AUTH are those used by IMAP4. | AUTH are those used by IMAP4. | |||
| $ port scan | $ port scan | |||
| (I) An attack that sends client requests to a range of server port | (I) A technique that sends client requests to a range of service | |||
| addresses on a host, with the goal of finding an active port and | port addresses on a host. (See: probe. Compare: ping sweep.) | |||
| exploiting a known vulnerability of that service. (Compare: ping | ||||
| sweep.) | Tutorial: A port scan can be used for pre-attack surveillance, | |||
| with the goal of finding an active port and subsequently | ||||
| exploiting a known vulnerability of that port's service. A port | ||||
| scan can also be used as a flooding attack. | ||||
| $ positive authorization | $ positive authorization | |||
| (I) The principle that a security architecture should be designed | (I) The principle that a security architecture should be designed | |||
| so that access to system resources is permitted only when | so that access to system resources is permitted only when | |||
| explicitly granted; i.e., in the absence of an explicit | explicitly granted; i.e., in the absence of an explicit | |||
| authorization that grants access, the default action shall be to | authorization that grants access, the default action shall be to | |||
| refuse access. (See: authorization, access.) | refuse access. (See: authorization, access.) | |||
| $ POSIX | $ POSIX | |||
| (N) Portable Operating System Interface for Computer Environments, | (N) Portable Operating System Interface for Computer Environments, | |||
| skipping to change at page 205, line 40 ¶ | skipping to change at page 212, line 11 ¶ | |||
| $ PPTP | $ PPTP | |||
| (I) See: Point-to-Point Tunneling Protocol. | (I) See: Point-to-Point Tunneling Protocol. | |||
| $ preauthorization | $ preauthorization | |||
| (N) /PKI/ A CAW feature that enables certification requests to be | (N) /PKI/ A CAW feature that enables certification requests to be | |||
| automatically validated against data provided in advance to the CA | automatically validated against data provided in advance to the CA | |||
| by an authorizing entity. | by an authorizing entity. | |||
| $ precedence | $ precedence | |||
| (N) A designation assigned to a communication (i.e., packet, | 1. (I) /information system/ A ranking assigned to events or data | |||
| message, data stream, connection, etc.) by the originator to state | objects that determines the relative order in which they are | |||
| the importance or urgency of that communication versus other | processed. | |||
| communications, and thus indicate to the transmission system the | ||||
| relative order of handling, and indicate to the receiver the order | 2. (N) /communication system/ A designation assigned to a | |||
| in which the communication is to be noted. [F1037] (See: | communication (i.e., packet, message, data stream, connection, | |||
| availability, critical, preemption.) | etc.) by the originator to state the importance or urgency of that | |||
| communication versus other communications, and thus indicate to | ||||
| the transmission system the relative order of handling, and | ||||
| indicate to the receiver the order in which the communication is | ||||
| to be noted. [F1037] (See: availability, critical, preemption.) | ||||
| Example: The "Precedence" subfield of the "Type of Service" field | Example: The "Precedence" subfield of the "Type of Service" field | |||
| of the IPv4 header supports the following designations (in | of the IPv4 header supports the following designations (in | |||
| descending order of importance): 111 Network Control, 110 | descending order of importance): 111 Network Control, 110 | |||
| Internetwork Control, 101 CRITIC/ECP (Critical Intelligence | Internetwork Control, 101 CRITIC/ECP (Critical Intelligence | |||
| Communication/Emergency Command Precedence), 100 Flash Override, | Communication/Emergency Command Precedence), 100 Flash Override, | |||
| 011 Flash, 010 Immediate, 001 Priority, and 000 Routine. These | 011 Flash, 010 Immediate, 001 Priority, and 000 Routine. These | |||
| designations were adopted from U.S. DoD systems that existed | designations were adopted from U.S. DoD systems that existed | |||
| before ARPANET. | before ARPANET. | |||
| $ preemption | $ preemption | |||
| (N) The seizure, usually automatic, of system resources that are | (N) The seizure, usually automatic, of system resources that are | |||
| being used to serve a lower precedence communication, in order to | being used to serve a lower precedence communication, in order to | |||
| serve immediately a higher precedence communication. [F1037] | serve immediately a higher precedence communication. [F1037] | |||
| $ Pretty Good Privacy(trademark) (PGP(trademark)) | $ Pretty Good Privacy(trademark) (PGP(trademark)) | |||
| (O) Trademarks of Network Associates, Inc., referring to a | (O) Trademarks of Network Associates, Inc., referring to a | |||
| computer program (and related protocols) that uses cryptography to | computer program (and related protocols) that uses cryptography to | |||
| provide data security for electronic mail and other applications | provide data security for electronic mail and other applications | |||
| on the Internet. (Compare: MOSS, MSP, PEM, S/MIME.) | on the Internet. (Compare: DKIM, MOSS, MSP, PEM, S/MIME.) | |||
| Tutorial: PGP encrypts messages with IDEA in CFB mode, distributes | Tutorial: PGP encrypts messages with a symmetric algorithm | |||
| the IDEA keys by encrypting them with RSA, and creates digital | (originally, IDEA in CFB mode), distributes the symmetric keys by | |||
| signatures on messages with MD5 and RSA. To establish ownership of | encrypting them with an asymmetric algorithm (originally, RSA), | |||
| public keys, PGP depends on the web of trust. | and creates digital signatures on messages with a cryptographic | |||
| hash and an asymmetric encryption algorithm (originally, MD5 and | ||||
| RSA). To establish ownership of public keys, PGP depends on the | ||||
| "web of trust". | ||||
| $ prevention | $ prevention | |||
| (I) See: secondary definition under "security". | (I) See: secondary definition under "security". | |||
| $ primary account number (PAN) | $ primary account number (PAN) | |||
| (O) /SET/ "The assigned number that identifies the card issuer and | (O) /SET/ "The assigned number that identifies the card issuer and | |||
| cardholder. This account number is composed of an issuer | cardholder. This account number is composed of an issuer | |||
| identification number, an individual account number | identification number, an individual account number | |||
| identification, and an accompanying check digit as defined by ISO | identification, and an accompanying check digit as defined by ISO | |||
| 7812-1985." [SET2, IS7812] (See: bank identification number.) | 7812-1985." [SET2, IS7812] (See: bank identification number.) | |||
| skipping to change at page 206, line 49 ¶ | skipping to change at page 213, line 26 ¶ | |||
| (I) A specific identity claimed by a user when accessing a system. | (I) A specific identity claimed by a user when accessing a system. | |||
| Usage: Usually understood to be an identity that is registered in | Usage: Usually understood to be an identity that is registered in | |||
| and authenticated by the system; equivalent to the notion of login | and authenticated by the system; equivalent to the notion of login | |||
| account identifier. Each principal is normally assigned to a | account identifier. Each principal is normally assigned to a | |||
| single user, but a single user may be assigned (or attempt to use) | single user, but a single user may be assigned (or attempt to use) | |||
| more than one principal. Each principal can spawn one or more | more than one principal. Each principal can spawn one or more | |||
| subjects, but each subject is associated with only one principal. | subjects, but each subject is associated with only one principal. | |||
| (Compare: role, subject, user.) | (Compare: role, subject, user.) | |||
| (N) /Kerberos/ A uniquely named client or server instance that | (I) /Kerberos/ A uniquely identified (i.e., uniquely named) client | |||
| participates in a network communication. | or server instance that participates in a network communication. | |||
| $ priority | ||||
| (I) /information system/ Precedence for processing an event or | ||||
| data object, determined by security importance or other factors. | ||||
| (See: precedence.) | ||||
| $ privacy | $ privacy | |||
| 1. (I) The right of an entity (normally a person), acting in its | 1. (I) The right of an entity (normally a person), acting in its | |||
| own behalf, to determine the degree to which it will interact with | own behalf, to determine the degree to which it will interact with | |||
| its environment, including the degree to which the entity is | its environment, including the degree to which the entity is | |||
| willing to share its personal information with others. (See: | willing to share its personal information with others. (See: | |||
| HIPAA, personal information, Privacy Act of 1974. Compare: | HIPAA, personal information, Privacy Act of 1974. Compare: | |||
| anonymity, data confidentiality.) | anonymity, data confidentiality.) | |||
| 2. (O) "The right of individuals to control or influence what | 2. (O) "The right of individuals to control or influence what | |||
| skipping to change at page 207, line 24 ¶ | skipping to change at page 214, line 6 ¶ | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | Deprecated Definition: ISDs SHOULD NOT use this term as a synonym | |||
| for "data confidentiality" or "data confidentiality service", | for "data confidentiality" or "data confidentiality service", | |||
| which are different concepts. Privacy is a reason for security | which are different concepts. Privacy is a reason for security | |||
| rather than a kind of security. For example, a system that stores | rather than a kind of security. For example, a system that stores | |||
| personal data needs to protect the data to prevent harm, | personal data needs to protect the data to prevent harm, | |||
| embarrassment, inconvenience, or unfairness to any person about | embarrassment, inconvenience, or unfairness to any person about | |||
| whom data is maintained, and to protect the person's privacy. For | whom data is maintained, and to protect the person's privacy. For | |||
| that reason, the system may need to provide data confidentiality | that reason, the system may need to provide data confidentiality | |||
| service. | service. | |||
| Tutorial: The term "privacy" is used for various separate but | ||||
| related concepts, including bodily privacy, territorial privacy, | ||||
| personal information privacy, and communication privacy. ISDs are | ||||
| expected to address only communication privacy, which in this | ||||
| Glossary is defined primarily by "data confidentiality" and | ||||
| secondarily by "data integrity". | ||||
| ISDs are not expected to address information privacy, but this | ||||
| Glossary provides definition 1 for that concept because personal | ||||
| information privacy is often confused with communication privacy. | ||||
| ISDS are not expected to address bodily privacy or territorial | ||||
| privacy, and this Glossary does not define those concepts because | ||||
| they are not easily confused with communication privacy. | ||||
| $ Privacy Act of 1974 | $ Privacy Act of 1974 | |||
| (O) A U.S. Federal law (Section 552a of Title 5, United States | (O) A U.S. Federal law (Section 552a of Title 5, United States | |||
| Code) that seeks to balance the U.S. Government's need to maintain | Code) that seeks to balance the U.S. Government's need to maintain | |||
| data about individuals with the rights of individuals to be | data about individuals with the rights of individuals to be | |||
| protected against unwarranted invasions of their privacy stemming | protected against unwarranted invasions of their privacy stemming | |||
| from federal agencies' collection, maintenance, use, and | from federal agencies' collection, maintenance, use, and | |||
| disclosure of personal data. (See: privacy.) | disclosure of personal data. (See: privacy.) | |||
| Tutorial: In 1974, the U.S. Congress was concerned with the | Tutorial: In 1974, the U.S. Congress was concerned with the | |||
| potential for abuses that could arise from the Government's | potential for abuses that could arise from the Government's | |||
| skipping to change at page 207, line 50 ¶ | skipping to change at page 214, line 46 ¶ | |||
| - To grant individuals the right to seek amendment of agency | - To grant individuals the right to seek amendment of agency | |||
| records maintained on themselves upon a showing that the | records maintained on themselves upon a showing that the | |||
| records are not accurate, relevant, timely, or complete. | records are not accurate, relevant, timely, or complete. | |||
| - To establish a code of "fair information practices" that | - To establish a code of "fair information practices" that | |||
| requires agencies to comply with statutory norms for | requires agencies to comply with statutory norms for | |||
| collection, maintenance, and dissemination of records. | collection, maintenance, and dissemination of records. | |||
| $ Privacy Enhanced Mail (PEM) | $ Privacy Enhanced Mail (PEM) | |||
| (I) An Internet protocol to provide data confidentiality, data | (I) An Internet protocol to provide data confidentiality, data | |||
| integrity, and data origin authentication for electronic mail. | integrity, and data origin authentication for electronic mail. | |||
| [R1421, R1422]. (Compare: MOSS, MSP, PGP, S/MIME.) | [R1421, R1422]. (Compare: DKIM, MOSS, MSP, PGP, S/MIME.) | |||
| Tutorial: PEM encrypts messages with DES in CBC mode, provides | Tutorial: PEM encrypts messages with a symmetric algorithm | |||
| distribution for DES keys by encrypting them with RSA, and signs | (originally, DES in CBC mode), provides distribution for the | |||
| messages with RSA over either MD2 or MD5. To establish ownership | symmetric keys by encrypting them with an asymmetric algorithm | |||
| of public keys, PEM uses a certification hierarchy, with X.509 | (originally, RSA), and signs messages with an asymmetric | |||
| public-key certificates and X.509 CRLs that are signed with RSA | encryption algorithm over a cryptographic hash (originally, RSA | |||
| and MD2. | over either MD2 or MD5). To establish ownership of public keys, | |||
| PEM uses a certification hierarchy, with X.509 public-key | ||||
| certificates and X.509 CRLs that are signed with an asymmetric | ||||
| encryption algorithm over a cryptographic hash (originally, RSA | ||||
| over MD2). | ||||
| PEM is designed to be compatible with a wide range of key | PEM is designed to be compatible with a wide range of key | |||
| management methods, but is limited to specifying security services | management methods, but is limited to specifying security services | |||
| only for text messages and, like MOSS, has not been widely | only for text messages and, like MOSS, has not been widely | |||
| implemented in the Internet. | implemented in the Internet. | |||
| $ private component | $ private component | |||
| (I) Synonym for "private key". | (I) Synonym for "private key". | |||
| Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; | Deprecated Usage: In most cases, ISDs SHOULD NOT use this term; | |||
| skipping to change at page 208, line 34 ¶ | skipping to change at page 215, line 34 ¶ | |||
| 1. (I) The secret component of a pair of cryptographic keys used | 1. (I) The secret component of a pair of cryptographic keys used | |||
| for asymmetric cryptography. (See: key pair, public key, secret | for asymmetric cryptography. (See: key pair, public key, secret | |||
| key.) | key.) | |||
| 2. (O) In a public key cryptosystem, "that key of a user's key | 2. (O) In a public key cryptosystem, "that key of a user's key | |||
| pair which is known only by that user." [X509] | pair which is known only by that user." [X509] | |||
| $ Private Line Interface (PLI) | $ Private Line Interface (PLI) | |||
| (I) The first end-to-end packet encryption system for a computer | (I) The first end-to-end packet encryption system for a computer | |||
| network, developed by BBN starting in 1975 for the U.S. DoD, | network, developed by BBN starting in 1975 for the U.S. DoD, | |||
| incorporating Government-furnished, military-grade COMSEC | incorporating U.S. Government-furnished, military-grade COMSEC | |||
| equipment (TSEC/KG-34). [B1822] (Compare: IPLI.) | equipment (TSEC/KG-34). [B1822] (Compare: IPLI.) | |||
| $ privilege | $ privilege | |||
| 1a. (I) /access control/ A synonym for "authorization". (See | 1a. (I) /access control/ A synonym for "authorization". (See | |||
| authorization. Compare: permission.) | authorization. Compare: permission.) | |||
| 1b. (I) /computer platform/ An authorization to perform a | 1b. (I) /computer platform/ An authorization to perform a | |||
| security-relevant function in the context of a computer's | security-relevant function in the context of a computer's | |||
| operating system. | operating system. | |||
| skipping to change at page 209, line 28 ¶ | skipping to change at page 216, line 28 ¶ | |||
| and authentication information, or are authorized to assign or | and authentication information, or are authorized to assign or | |||
| change other users' access to system resources. | change other users' access to system resources. | |||
| - Users that are authorized to change control parameters (e.g., | - Users that are authorized to change control parameters (e.g., | |||
| network addresses, routing tables, processing priorities) on | network addresses, routing tables, processing priorities) on | |||
| routers, multiplexers, and other important equipment. | routers, multiplexers, and other important equipment. | |||
| - Users that are authorized to monitor or perform troubleshooting | - Users that are authorized to monitor or perform troubleshooting | |||
| for a system's security functions, typically using special | for a system's security functions, typically using special | |||
| tools and features that are not available to ordinary users. | tools and features that are not available to ordinary users. | |||
| $ probe | $ probe | |||
| (I) /verb/ To access an information system in an attempt to gather | (I) /verb/ A technique that attempts to access a system to learn | |||
| information about the system for the purpose of circumventing the | something about the system. (See: port scan.) | |||
| system's security measures. | ||||
| Tutorial: The purpose of a probe may be offensive, e.g., an | ||||
| attempt to gather information for the purpose of circumventing the | ||||
| system's protections; or the purpose may be defensive, e.g., to | ||||
| verify that the system is working properly. | ||||
| $ procedural security | $ procedural security | |||
| (D) Synonym for "administrative security". | (D) Synonym for "administrative security". | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | |||
| "administrative security". The term may be misleading because any | "administrative security". The term may be misleading because any | |||
| type of security may involve procedures, and procedures may be | type of security may involve procedures, and procedures may be | |||
| either external to the system or internal. Instead, use | either external to the system or internal. Instead, use | |||
| "administrative security", "communication security", "computer | "administrative security", "communication security", "computer | |||
| security", "emanations security", "personnel security", "physical | security", "emanations security", "personnel security", "physical | |||
| skipping to change at page 210, line 29 ¶ | skipping to change at page 217, line 34 ¶ | |||
| (I) See: secondary definition under "Internet Protocol Security | (I) See: secondary definition under "Internet Protocol Security | |||
| Option". | Option". | |||
| $ protection level | $ protection level | |||
| (N) /U.S. Government/ An indication of the trust that is needed in | (N) /U.S. Government/ An indication of the trust that is needed in | |||
| a system's technical ability to enforce security policy for | a system's technical ability to enforce security policy for | |||
| confidentiality. (Compare: /system operation/ under "mode of | confidentiality. (Compare: /system operation/ under "mode of | |||
| operation".) | operation".) | |||
| Tutorial: An organization's security policy could define | Tutorial: An organization's security policy could define | |||
| protection levels that are based on (a) the sensitivity of | protection levels that are based on comparing (a) the sensitivity | |||
| information handled by a system compared to (b) the authorizations | of information handled by a system to (b) the authorizations of | |||
| of users that receive information from the system without manual | users that receive information from the system without manual | |||
| intervention and reliable human review. For each level, the policy | intervention and reliable human review. For each level, the policy | |||
| could specify security features and assurances that must be | could specify security features and assurances that must be | |||
| included in any system that was intended to operate at that level. | included in any system that was intended to operate at that level. | |||
| Example: Given some set of data objects that are classified at one | Example: Given some set of data objects that are classified at one | |||
| or more hierarchical levels and in one or more non-hierarchical | or more hierarchical levels and in one or more non-hierarchical | |||
| categories, the following table defines five protection levels for | categories, the following table defines five protection levels for | |||
| systems that would handle that data. Beginning with PL1 and | systems that would handle that data. Beginning with PL1 and | |||
| evolving to PL5, each successive level would require stronger | evolving to PL5, each successive level would require stronger | |||
| features and assurances to handle the dataset. (See: clearance, | features and assurances to handle the dataset. (See: clearance, | |||
| skipping to change at page 211, line 40 ¶ | skipping to change at page 218, line 40 ¶ | |||
| - PL1 is equivalent to dedicated security mode. | - PL1 is equivalent to dedicated security mode. | |||
| $ protection profile | $ protection profile | |||
| (N) /Common Criteria/ An implementation-independent set of | (N) /Common Criteria/ An implementation-independent set of | |||
| security requirements for a category of targets of evaluation that | security requirements for a category of targets of evaluation that | |||
| meet specific consumer needs. [CCIB] Example: [IDSAN]. (See: | meet specific consumer needs. [CCIB] Example: [IDSAN]. (See: | |||
| target of evaluation. Compare: certificate profile, package.) | target of evaluation. Compare: certificate profile, package.) | |||
| Tutorial: A protection profile (PP) is the kind of document used | Tutorial: A protection profile (PP) is the kind of document used | |||
| by consumers to specify functional requirements they want in a | by consumers to specify functional requirements they want in a | |||
| product, and a target of evaluation (TOE) is the kind of document | product, and a security target (ST) is the kind of document used | |||
| used by vendors to make functional claims about a product. | by vendors to make functional claims about a product. | |||
| A PP is intended to be a reusable statement of product security | A PP is intended to be a reusable statement of product security | |||
| needs, which are known to be useful and effective, for a set of | needs, which are known to be useful and effective, for a set of | |||
| information technology security products that could be built. A PP | information technology security products that could be built. A PP | |||
| contains a set of security requirements, preferably taken from the | contains a set of security requirements, preferably taken from the | |||
| catalogs in Parts 2 and 3 of the Common Criteria, and should | catalogs in Parts 2 and 3 of the Common Criteria, and should | |||
| include an EAL. A PP could be developed by user communities, | include an EAL. A PP could be developed by user communities, | |||
| product developers, or any other parties interested in defining a | product developers, or any other parties interested in defining a | |||
| common set of requirements. | common set of requirements. | |||
| skipping to change at page 212, line 48 ¶ | skipping to change at page 219, line 48 ¶ | |||
| control their joint operation of the layer. | control their joint operation of the layer. | |||
| $ protocol suite | $ protocol suite | |||
| (I) A complementary collection of communication protocols used in | (I) A complementary collection of communication protocols used in | |||
| a computer network. (See: IPS, OSI.) | a computer network. (See: IPS, OSI.) | |||
| $ proxy | $ proxy | |||
| 1. (I) A computer process that acts on behalf of a user or client. | 1. (I) A computer process that acts on behalf of a user or client. | |||
| 2. (I) A computer process -- often used as, or as part of, a | 2. (I) A computer process -- often used as, or as part of, a | |||
| firewall -- that relays a protocol between client and server | firewall -- that relays application transactions or a protocol | |||
| computer systems, by appearing to the client to be the server and | between client and server computer systems, by appearing to the | |||
| appearing to the server to be the client. (See: SOCKS.) | client to be the server and appearing to the server to be the | |||
| client. (See: SOCKS.) | ||||
| Tutorial: In a firewall, a proxy server usually runs on a bastion | Tutorial: In a firewall, a proxy server usually runs on a bastion | |||
| host, which may support proxies for several protocols (e.g., FTP, | host, which may support proxies for several applications and | |||
| HTTP, and TELNET). Instead of a client in the protected enclave | protocols (e.g., FTP, HTTP, and TELNET). Instead of a client in | |||
| connecting directly to an external server, the internal client | the protected enclave connecting directly to an external server, | |||
| connects to the proxy server which in turn connects to the | the internal client connects to the proxy server which in turn | |||
| external server. The proxy server waits for a request from inside | connects to the external server. The proxy server waits for a | |||
| the firewall, forwards the request to the server outside the | request from inside the firewall, forwards the request to the | |||
| firewall, gets the response, then sends the response back to the | server outside the firewall, gets the response, then sends the | |||
| client. The proxy may be transparent to the clients, or they may | response back to the client. The proxy may be transparent to the | |||
| need to connect first to the proxy server, and then use that | clients, or they may need to connect first to the proxy server, | |||
| association to also initiate a connection to the real server. | and then use that association to also initiate a connection to the | |||
| real server. | ||||
| Proxies are generally preferred over SOCKS for their ability to | Proxies are generally preferred over SOCKS for their ability to | |||
| perform caching, high-level logging, and access control. A proxy | perform caching, high-level logging, and access control. A proxy | |||
| can provide security service beyond that which is normally part of | can provide security service beyond that which is normally part of | |||
| the relayed protocol, such as access control based on peer entity | the relayed protocol, such as access control based on peer entity | |||
| authentication of clients, or peer entity authentication of | authentication of clients, or peer entity authentication of | |||
| servers when clients do not have that ability. A proxy at OSIRM | servers when clients do not have that ability. A proxy at OSIRM | |||
| Layer 7 can also provide finer-grained security service than can a | Layer 7 can also provide finer-grained security service than can a | |||
| filtering router at Layer 3. For example, an FTP proxy could | filtering router at Layer 3. For example, an FTP proxy could | |||
| permit transfers out of, but not into, a protected network. | permit transfers out of, but not into, a protected network. | |||
| skipping to change at page 214, line 50 ¶ | skipping to change at page 221, line 53 ¶ | |||
| and academia, originally including Apple, Digital, Lotus, | and academia, originally including Apple, Digital, Lotus, | |||
| Microsoft, Northern Telecom, Sun, and MIT. Today, the | Microsoft, Northern Telecom, Sun, and MIT. Today, the | |||
| specifications are widely used, but they are not sanctioned by an | specifications are widely used, but they are not sanctioned by an | |||
| official standards organization, such as ANSI, ITU-T, or IETF. RSA | official standards organization, such as ANSI, ITU-T, or IETF. RSA | |||
| Laboratories retains sole decision-making authority over the PKCS. | Laboratories retains sole decision-making authority over the PKCS. | |||
| $ public-key forward secrecy (PFS) | $ public-key forward secrecy (PFS) | |||
| (I) For a key-agreement protocol based on asymmetric cryptography, | (I) For a key-agreement protocol based on asymmetric cryptography, | |||
| the property that ensures that a session key derived from a set of | the property that ensures that a session key derived from a set of | |||
| long-term public and private keys will not be compromised if one | long-term public and private keys will not be compromised if one | |||
| of the private keys is compromised in the future. | of the private keys is compromised in the future. (See: Usage note | |||
| and other discussion under "perfect forward secrecy".) | ||||
| Usage: Some existing RFCs use the term "perfect forward secrecy" | ||||
| but either do not define it or do not define it precisely. While | ||||
| preparing this Glossary, we tried to find a good definition for | ||||
| that term, but found this to be a muddled area. Experts did not | ||||
| agree. For all practical purposes, the literature defines "perfect | ||||
| forward secrecy" by stating the Diffie-Hellman algorithm. The term | ||||
| "public-key forward secrecy" (suggested by Hilarie Orman) and the | ||||
| "I" definition stated for it here were crafted to be compatible | ||||
| with current Internet documents, yet be narrow and leave room for | ||||
| improved terminology. | ||||
| Challenge to the Internet security community: We need a taxonomy | ||||
| of terms and definitions to cover the basic properties discussed | ||||
| here for the full range of cryptographic algorithms and protocols | ||||
| used in Internet Standards: | ||||
| Involvement of session keys vs. long-term keys: Experts disagree | ||||
| about the basic ideas involved: | ||||
| - One concept of "forward secrecy" is that, given observations of | ||||
| the operation of a key establishment protocol up to time t, and | ||||
| given some of the session keys derived from those protocol | ||||
| runs, you cannot derive unknown past session keys or future | ||||
| session keys. | ||||
| - A related property is that, given observations of the protocol | ||||
| and knowledge of the derived session keys, you cannot derive | ||||
| one or more of the long-term private keys. | ||||
| - The "I" definition presented above involves a third concept of | ||||
| "forward secrecy" that refers to the effect of the compromise | ||||
| of long-term keys. | ||||
| - All three concepts involve the idea that a compromise of "this" | ||||
| encryption key is not supposed to compromise the "next" one. | ||||
| There also is the idea that compromise of a single key will | ||||
| compromise only the data protected by the single key. In | ||||
| Internet literature, the focus has been on protection against | ||||
| decryption of back traffic in the event of a compromise of | ||||
| secret key material held by one or both parties to a | ||||
| communication. | ||||
| Forward vs. backward: Experts are unhappy with the word "forward", | ||||
| because compromise of "this" encryption key also is not supposed | ||||
| to compromise the "previous" one, which is "backward" rather than | ||||
| forward. In S/KEY, if the key used at time t is compromised, then | ||||
| all keys used prior to that are compromised. If the "long-term" | ||||
| key (i.e., the base of the hashing scheme) is compromised, then | ||||
| all keys past and future are compromised; thus, you could say that | ||||
| S/KEY has neither forward nor backward secrecy. | ||||
| Asymmetric cryptography vs. symmetric: Experts disagree about | ||||
| forward secrecy in the context of symmetric cryptographic systems. | ||||
| In the absence of asymmetric cryptography, compromise of any long- | ||||
| term key seems to compromise any session key derived from the | ||||
| long-term key. For example, Kerberos isn't forward secret, because | ||||
| compromising a client's password (thus compromising the key shared | ||||
| by the client and the authentication server) compromises future | ||||
| session keys shared by the client and the ticket-granting server. | ||||
| Ordinary forward secrecy vs. "perfect" forward secret: Experts | ||||
| disagree about the difference between these two. Some say there is | ||||
| no difference, and some say that the initial naming was | ||||
| unfortunate and suggest dropping the word "perfect". Some suggest | ||||
| using "forward secrecy" for the case where one long-term private | ||||
| key is compromised, and adding "perfect" for when both private | ||||
| keys (or, when the protocol is multi-party, all private keys) are | ||||
| compromised. | ||||
| Acknowledgements: Bill Burr, Burt Kaliski, Steve Kent, Paul Van | $ public-key Kerberos | |||
| Oorschot, Michael Wiener, and, especially, Hilarie Orman | (I) See: Tutorial under "Kerberos", PKINIT. | |||
| contributed ideas to this discussion. | ||||
| $ public-key infrastructure (PKI) | $ public-key infrastructure (PKI) | |||
| 1. (I) A system of CAs (and, optionally, RAs and other supporting | 1. (I) A system of CAs (and, optionally, RAs and other supporting | |||
| servers and agents) that perform some set of certificate | servers and agents) that perform some set of certificate | |||
| management, archive management, key management, and token | management, archive management, key management, and token | |||
| management functions for a community of users in an application of | management functions for a community of users in an application of | |||
| asymmetric cryptography. (See: hierarchical PKI, mesh PKI, | asymmetric cryptography. (See: hierarchical PKI, mesh PKI, | |||
| security management infrastructure, trust-file PKI.) | security management infrastructure, trust-file PKI.) | |||
| 2. (I) /PKIX/ The set of hardware, software, people, policies, and | 2. (I) /PKIX/ The set of hardware, software, people, policies, and | |||
| skipping to change at page 216, line 43 ¶ | skipping to change at page 222, line 33 ¶ | |||
| certificates at a much later time. Key pairs for data | certificates at a much later time. Key pairs for data | |||
| confidentiality may be generated (and perhaps escrowed) by CAs or | confidentiality may be generated (and perhaps escrowed) by CAs or | |||
| RAs, but requiring a PKI client to generate its own digital | RAs, but requiring a PKI client to generate its own digital | |||
| signature key pair helps maintain system integrity of the | signature key pair helps maintain system integrity of the | |||
| cryptographic system, because then only the client ever possesses | cryptographic system, because then only the client ever possesses | |||
| the private key it uses. Also, an authority may be established to | the private key it uses. Also, an authority may be established to | |||
| approve or coordinate CPSs, which are security policies under | approve or coordinate CPSs, which are security policies under | |||
| which components of a PKI operate. | which components of a PKI operate. | |||
| A number of other servers and agents may support the core PKI, and | A number of other servers and agents may support the core PKI, and | |||
| PKI clients may obtain services from them. The full range of such | PKI clients may obtain services from them, such as certificate | |||
| services is not yet fully understood and is evolving, but | validation services. The full range of such services is not yet | |||
| supporting roles may include archive agent, certified delivery | fully understood and is evolving, but supporting roles may include | |||
| agent, confirmation agent, digital notary, directory, key escrow | archive agent, certified delivery agent, confirmation agent, | |||
| agent, key generation agent, naming agent who ensures that issuers | digital notary, directory, key escrow agent, key generation agent, | |||
| and subjects have unique identifiers within the PKI, repository, | naming agent who ensures that issuers and subjects have unique | |||
| ticket-granting agent, and time-stamp agent. | identifiers within the PKI, repository, ticket-granting agent, | |||
| time-stamp agent, and validation agent. | ||||
| $ purge | $ purge | |||
| (I) Use degaussing or other means to render (magnetically) stored | 1. (I) Synonym for "erase". | |||
| data unusable and unrecoverable by any means, including laboratory | ||||
| methods. [C4009] (See: zeroize. Compare: erase, sanitize.) | 2. (O) /U.S. Government/ Use degaussing or other methods to render | |||
| magnetically stored data unusable and irrecoverable by any means, | ||||
| including laboratory methods. [C4009] (Compare: /U.S. Government/ | ||||
| erase.) | ||||
| $ QUADRANT | $ QUADRANT | |||
| (O) /U.S. Government/ Short name for technology and methods that | (O) /U.S. Government/ Short name for technology and methods that | |||
| protect cryptographic equipment by making the equipment tamper- | protect cryptographic equipment by making the equipment tamper- | |||
| resistant. [C4009] (Compare: protective packaging, TEMPEST.) | resistant. [C4009] (Compare: protective packaging, TEMPEST.) | |||
| Tutorial: Equipment cannot be made completely tamper-proof, but it | Tutorial: Equipment cannot be made completely tamper-proof, but it | |||
| can be made tamper-resistant or tamper-evident. | can be made tamper-resistant or tamper-evident. | |||
| $ qualified certificate | $ qualified certificate | |||
| skipping to change at page 218, line 34 ¶ | skipping to change at page 224, line 27 ¶ | |||
| $ RBAC | $ RBAC | |||
| (N) See: role-based access control, rule-based access control. | (N) See: role-based access control, rule-based access control. | |||
| Deprecated Usage: ISDs that use this term SHOULD state a | Deprecated Usage: ISDs that use this term SHOULD state a | |||
| definition for it because the abbreviation is ambiguous. | definition for it because the abbreviation is ambiguous. | |||
| $ RC2, RC4, RC6 | $ RC2, RC4, RC6 | |||
| (N) See: Rivest Cipher #2, #4, #6. | (N) See: Rivest Cipher #2, #4, #6. | |||
| $ read | $ read | |||
| (I) A fundamental operation in an information system that results | (I) /security model/ A system operation that causes a flow of | |||
| only in the flow of information from an object to a subject. (See: | information from an object to a subject. (See: access mode. | |||
| access mode.) | Compare: write.) | |||
| $ realm | $ realm | |||
| (O) /Kerberos/ The domain of authority of a Kerberos server | (I) /Kerberos/ A domain consisting of a set Kerberized clients, | |||
| (consisting of an authentication server and a ticket-granting | Kerberized application servers, and one or more Kerberos | |||
| server), including the Kerberized clients and the Kerberized | authentication servers and ticket-granting servers that support | |||
| application servers. (See: domain.) | the clients and applications, all operating under the same | |||
| security policy. (See: domain.) | ||||
| $ recovery | $ recovery | |||
| 1. (I) /cryptography/ The process of learning or obtaining | 1. (I) /cryptography/ The process of learning or obtaining | |||
| cryptographic data or plain text through cryptanalysis. (See: key | cryptographic data or plain text through cryptanalysis. (See: key | |||
| recovery, data recovery.) | recovery, data recovery.) | |||
| 2a. (I) /system integrity/ The process of restoring a secure state | 2a. (I) /system integrity/ The process of restoring a secure state | |||
| in a system after there has been an accidental failure or a | in a system after there has been an accidental failure or a | |||
| successful attack. (See: secondary definition under "security", | successful attack. (See: secondary definition under "security", | |||
| system integrity.) | system integrity.) | |||
| skipping to change at page 221, line 17 ¶ | skipping to change at page 227, line 11 ¶ | |||
| not sign either digital certificates or CRLs but has | not sign either digital certificates or CRLs but has | |||
| responsibility for recording or verifying some or all of the | responsibility for recording or verifying some or all of the | |||
| information (particularly the identities of subjects) needed by a | information (particularly the identities of subjects) needed by a | |||
| CA to issue certificates and CRLs and to perform other certificate | CA to issue certificates and CRLs and to perform other certificate | |||
| management functions. (See: ORA, registration.) | management functions. (See: ORA, registration.) | |||
| 2. (I) /PKIX/ An optional PKI component, separate from the CA(s). | 2. (I) /PKIX/ An optional PKI component, separate from the CA(s). | |||
| The functions that the RA performs will vary from case to case but | The functions that the RA performs will vary from case to case but | |||
| may include identity authentication and name assignment, key | may include identity authentication and name assignment, key | |||
| generation and archiving of key pairs, token distribution, and | generation and archiving of key pairs, token distribution, and | |||
| revocation reporting. [R2510] | revocation reporting. [R4210] | |||
| Tutorial: Sometimes, a CA may perform all certificate management | Tutorial: Sometimes, a CA may perform all certificate management | |||
| functions for all end users for which the CA signs certificates. | functions for all end users for which the CA signs certificates. | |||
| Other times, such as in a large or geographically dispersed | Other times, such as in a large or geographically dispersed | |||
| community, it may be necessary or desirable to offload secondary | community, it may be necessary or desirable to offload secondary | |||
| CA functions and delegate them to an assistant, while the CA | CA functions and delegate them to an assistant, while the CA | |||
| retains the primary functions (signing certificates and CRLs). The | retains the primary functions (signing certificates and CRLs). The | |||
| tasks that are delegated to an RA by a CA may include personal | tasks that are delegated to an RA by a CA may include personal | |||
| authentication, name assignment, token distribution, revocation | authentication, name assignment, token distribution, revocation | |||
| reporting, key generation, and archiving. | reporting, key generation, and archiving. | |||
| skipping to change at page 222, line 40 ¶ | skipping to change at page 228, line 35 ¶ | |||
| (I) Residual information that can be recovered from a storage | (I) Residual information that can be recovered from a storage | |||
| medium after clearing. (See: clear, magnetic remanence, purge.) | medium after clearing. (See: clear, magnetic remanence, purge.) | |||
| $ Remote Authentication Dial-In User Service (RADIUS) | $ Remote Authentication Dial-In User Service (RADIUS) | |||
| (I) An Internet protocol [R2865] for carrying dial-in users' | (I) An Internet protocol [R2865] for carrying dial-in users' | |||
| authentication information and configuration information between a | authentication information and configuration information between a | |||
| shared, centralized authentication server (the RADIUS server) and | shared, centralized authentication server (the RADIUS server) and | |||
| a network access server (the RADIUS client) that needs to | a network access server (the RADIUS client) that needs to | |||
| authenticate the users of its network access ports. (See: TACACS.) | authenticate the users of its network access ports. (See: TACACS.) | |||
| Tutorial: A user of the RADIUS client presents authentication | User presents authentication and possibly other information to the | |||
| information to the client, and the client passes that information | Radius client (e.g., health information regarding the user | |||
| to the RADIUS server. The server authenticates the client using a | device). | |||
| shared secret value, then checks the user's authentication | ||||
| information, and finally returns to the client all authorization | Tutorial: A user presents authentication information and possibly | |||
| and configuration information needed by the client to deliver | other information to the RADIUS client, and the client passes that | |||
| service to the user. | information to the RADIUS server. The server authenticates the | |||
| client using a shared secret value and checks the presented | ||||
| information, and then returns to the client all authorization and | ||||
| configuration information needed by the client to serve the user. | ||||
| $ renew | $ renew | |||
| See: certificate renewal. | See: certificate renewal. | |||
| $ replay attack | $ replay attack | |||
| (I) An attack in which a valid data transmission is maliciously or | (I) An attack in which a valid data transmission is maliciously or | |||
| fraudulently repeated, either by the originator or by a third | fraudulently repeated, either by the originator or by a third | |||
| party who intercepts the data and retransmits it, possibly as part | party who intercepts the data and retransmits it, possibly as part | |||
| of a masquerade attack. (See: active wiretapping, fresh, liveness, | of a masquerade attack. (See: active wiretapping, fresh, liveness, | |||
| nonce. Compare: indirect attack, reflection attack.) | nonce. Compare: indirect attack, reflection attack.) | |||
| skipping to change at page 224, line 15 ¶ | skipping to change at page 230, line 13 ¶ | |||
| published as RFCs. | published as RFCs. | |||
| $ residual risk | $ residual risk | |||
| (I) The portion of an original risk or set of risks that remains | (I) The portion of an original risk or set of risks that remains | |||
| after countermeasures have been applied. (Compare: acceptable | after countermeasures have been applied. (Compare: acceptable | |||
| risk, risk analysis.) | risk, risk analysis.) | |||
| $ restore | $ restore | |||
| See: card restore. | See: card restore. | |||
| $ reverse engineering | ||||
| (I) /threat action/ See: secondary definition under "intrusion". | ||||
| $ revocation | $ revocation | |||
| See: certificate revocation. | See: certificate revocation. | |||
| $ revocation date | $ revocation date | |||
| (N) /X.509/ In a CRL entry, a date-time field that states when the | (N) /X.509/ In a CRL entry, a date-time field that states when the | |||
| certificate revocation occurred, i.e., when the CA declared the | certificate revocation occurred, i.e., when the CA declared the | |||
| digital certificate to be invalid. (See: invalidity date.) | digital certificate to be invalid. (See: invalidity date.) | |||
| Tutorial: The revocation date may not resolve some disputes | Tutorial: The revocation date may not resolve some disputes | |||
| because, in the worst case, all signatures made during the | because, in the worst case, all signatures made during the | |||
| skipping to change at page 231, line 47 ¶ | skipping to change at page 237, line 50 ¶ | |||
| $ SAML | $ SAML | |||
| (N) See: Security Assertion Markup Language (SAML). | (N) See: Security Assertion Markup Language (SAML). | |||
| $ sandbox | $ sandbox | |||
| (I) A restricted, controlled execution environment that prevents | (I) A restricted, controlled execution environment that prevents | |||
| potentially malicious software, such as mobile code, from | potentially malicious software, such as mobile code, from | |||
| accessing any system resources except those for which the software | accessing any system resources except those for which the software | |||
| is authorized. | is authorized. | |||
| $ sanitize | $ sanitize | |||
| 1. (I) Delete sensitive data from a file, device, or system. | 1. (I) Delete sensitive data from a file, device, or system. (See: | |||
| erase, zeroize.) | ||||
| 2. (I) Modify data so as to be able either (a) to completely | 2. (I) Modify data so as to be able either (a) to completely | |||
| declassify it or (b) to downgrade it to a lower security level. | declassify it or (b) to downgrade it to a lower security level. | |||
| $ SAP | $ SAP | |||
| (O) See: special access program. | (O) See: special access program. | |||
| $ SASL | $ SASL | |||
| (I) See: Simple Authentication and Security Layer. | (I) See: Simple Authentication and Security Layer. | |||
| $ SCA | $ SCA | |||
| (I) See: subordinate certification authority. | (I) See: subordinate certification authority. | |||
| $ scavenging | $ scavenging | |||
| (I) See: secondary definition under "threat consequence". | (I) /threat action/ See: secondary definition under "exposure". | |||
| $ SCI | $ SCI | |||
| (O) See: sensitive compartmented information. | (O) See: sensitive compartmented information. | |||
| $ SCIF | $ SCIF | |||
| (O) See: sensitive compartmented information facility. | (O) See: sensitive compartmented information facility. | |||
| $ SCOMP | $ SCOMP | |||
| (N) Secure COMmunications Processor; an enhanced, MLS version of | (N) Secure COMmunications Processor; an enhanced, MLS version of | |||
| the Honeywell Level 6 minicomputer. It was the first system to be | the Honeywell Level 6 minicomputer. It was the first system to be | |||
| skipping to change at page 233, line 11 ¶ | skipping to change at page 239, line 14 ¶ | |||
| $ SDU | $ SDU | |||
| (N) See: "service data unit" under "protocol data unit". | (N) See: "service data unit" under "protocol data unit". | |||
| $ seal | $ seal | |||
| 1. (I) To use asymmetric cryptography to encrypt plain text with a | 1. (I) To use asymmetric cryptography to encrypt plain text with a | |||
| public key in such a way that only the holder of the matching | public key in such a way that only the holder of the matching | |||
| private key can learn what was the plain text. [Chau] (Compare: | private key can learn what was the plain text. [Chau] (Compare: | |||
| shroud, wrap.) | shroud, wrap.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term with definition 1; | Deprecated Usage: ISDs SHOULD NOT use this term with definition 1 | |||
| the definition duplicates the meaning of other, standard terms. | unless the ISD includes the definition, because the definition is | |||
| Instead, use "encrypt" or another term that is specific with | not wide known and the concept can be expressed by using other, | |||
| regard to the mechanism being used. | standard terms. Instead, use "salt and encrypt" or other | |||
| terminology that is specific with regard to the mechanism being | ||||
| used. | ||||
| Tutorial: The definition does *not* say "only the holder of the | Tutorial: The definition does *not* say "only the holder of the | |||
| matching private key can decrypt the ciphertext to learn what was | matching private key can decrypt the ciphertext to learn what was | |||
| the plaintext"; sealing is stronger than that. If Alice simply | the plaintext"; sealing is stronger than that. If Alice simply | |||
| encrypts a plaintext P with a public key K to produce ciphertext C | encrypts a plaintext P with a public key K to produce ciphertext C | |||
| = K(P), then if Bob guesses that P = X, Bob could verify the guess | = K(P), then if Bob guesses that P = X, Bob could verify the guess | |||
| by checking whether K(P) = K(X). To "seal" P and block Bob's | by checking whether K(P) = K(X). To "seal" P and block Bob's | |||
| guessing attack, Alice could attach a long string R of random bits | guessing attack, Alice could attach a long string R of random bits | |||
| to P before encrypting to produce C = K(P,R); if Bob guesses that | to P before encrypting to produce C = K(P,R); if Bob guesses that | |||
| P = X, Bob can only test the guess by also guessing R. | P = X, Bob can only test the guess by also guessing R. (See: | |||
| salt.) | ||||
| 2. (D) To use cryptography to provide data integrity service for a | 2. (D) To use cryptography to provide data integrity service for a | |||
| data object. (See: sign.) | data object. (See: sign.) | |||
| Deprecated Definition: ISDs SHOULD NOT use this term with | Deprecated Definition: ISDs SHOULD NOT use this term with | |||
| definition 2. Instead, use a term that is more specific with | definition 2. Instead, use a term that is more specific with | |||
| regard to the mechanism used to provide the data integrity | regard to the mechanism used to provide the data integrity | |||
| service; e.g., use "sign" when the mechanism is digital signature. | service; e.g., use "sign" when the mechanism is digital signature. | |||
| $ secret | $ secret | |||
| skipping to change at page 235, line 41 ¶ | skipping to change at page 241, line 47 ¶ | |||
| Framework [R3740] covers three functional areas: | Framework [R3740] covers three functional areas: | |||
| - Multicast data handling: Security-related treatment of | - Multicast data handling: Security-related treatment of | |||
| multicast data by the sender and the receiver. | multicast data by the sender and the receiver. | |||
| - Group key management: Secure distribution and refreshment of | - Group key management: Secure distribution and refreshment of | |||
| keying material. (See: Group Domain of Interpretation.) | keying material. (See: Group Domain of Interpretation.) | |||
| - Multicast security policy: Policy translation and | - Multicast security policy: Policy translation and | |||
| interpretation across the multiple administrative domains that | interpretation across the multiple administrative domains that | |||
| typically are spanned by a multicast application. | typically are spanned by a multicast application. | |||
| $ Secure Shell(trademark) (SSH(trademark)) | $ Secure Shell(trademark) (SSH(trademark)) | |||
| (N) Trademarks of SSH Communications Security Corp. that refer to | (N) Refers to a protocol for secure remote login and other secure | |||
| a protocol for secure remote login and other secure network | network services. | |||
| services. | ||||
| Usage: On the Web site of SSH Communication Security Corporation, | ||||
| at http://www.ssh.com/legal_notice.html, it says, "SSH [and] the | ||||
| SSH logo . . . are either trademarks or registered trademarks of | ||||
| SSH." This Glossary seeks to make readers aware of this trademark | ||||
| claim but takes no position on its validity. | ||||
| Tutorial: SSH has three main parts: | Tutorial: SSH has three main parts: | |||
| - Transport layer protocol: Provides server authentication, | - Transport layer protocol: Provides server authentication, | |||
| confidentiality, and integrity; and can optionally provide | confidentiality, and integrity; and can optionally provide | |||
| compression. This layer typically runs over a TCP connection, | compression. This layer typically runs over a TCP connection, | |||
| but might also run on top of any other reliable data stream. | but might also run on top of any other reliable data stream. | |||
| - User authentication protocol: Authenticates the client-side | - User authentication protocol: Authenticates the client-side | |||
| user to the server. It runs over the transport layer protocol. | user to the server. It runs over the transport layer protocol. | |||
| - Connection protocol: Multiplexes the encrypted tunnel into | - Connection protocol: Multiplexes the encrypted tunnel into | |||
| several logical channels. It runs over the user authentication | several logical channels. It runs over the user authentication | |||
| skipping to change at page 236, line 53 ¶ | skipping to change at page 243, line 11 ¶ | |||
| $ security | $ security | |||
| 1a. (I) A system condition that results from the establishment and | 1a. (I) A system condition that results from the establishment and | |||
| maintenance of measures to protect the system. | maintenance of measures to protect the system. | |||
| 1b. (I) A system condition in which system resources are free from | 1b. (I) A system condition in which system resources are free from | |||
| unauthorized access and from unauthorized or accidental change, | unauthorized access and from unauthorized or accidental change, | |||
| destruction, or loss. (Compare: safety.) | destruction, or loss. (Compare: safety.) | |||
| 2. (I) Measures taken to protect a system. | 2. (I) Measures taken to protect a system. | |||
| Tutorial: Parker suggests that providing a condition of system | Tutorial: Parker [Park] suggests that providing a condition of | |||
| security may involve the following six basic functions [Park]; | system security may involve the following six basic functions, | |||
| however, these functions overlap to some extent: | which overlap to some extent: | |||
| - "Deterrence": Reducing an intelligent threat by discouraging | - "Deterrence": Reducing an intelligent threat by discouraging | |||
| action, such as by fear or doubt. (See: attack, threat action.) | action, such as by fear or doubt. (See: attack, threat action.) | |||
| - "Avoidance": Reducing a risk by either reducing the value of | - "Avoidance": Reducing a risk by either reducing the value of | |||
| the potential loss or reducing the probability that the loss | the potential loss or reducing the probability that the loss | |||
| will occur. (See: risk analysis. Compare: "risk avoidance" | will occur. (See: risk analysis. Compare: "risk avoidance" | |||
| under "risk".) | under "risk".) | |||
| - "Prevention": Impeding a security violation by using a | - "Prevention": Impeding or thwarting a potential security | |||
| countermeasure. | violation by deploying a countermeasure. | |||
| - "Detection": Determining that a security violation is | - "Detection": Determining that a security violation is | |||
| impending, is in progress, or has recently occurred, and thus | impending, is in progress, or has recently occurred, and thus | |||
| make it possible to reduce the potential loss. (See: intrusion | make it possible to reduce the potential loss. (See: intrusion | |||
| detection.) | detection.) | |||
| - "Recovery": Restoring a normal state of system operation by | - "Recovery": Restoring a normal state of system operation by | |||
| compensating for a security violation, possibly by eliminating | compensating for a security violation, possibly by eliminating | |||
| or repairing its effects. (See: contingency plan, main entry | or repairing its effects. (See: contingency plan, main entry | |||
| for "recovery".) | for "recovery".) | |||
| - "Correction": Changing a security architecture to eliminate or | - "Correction": Changing a security architecture to eliminate or | |||
| reduce the risk of reoccurrence of a security violation or | reduce the risk of reoccurrence of a security violation or | |||
| skipping to change at page 248, line 4 ¶ | skipping to change at page 254, line 24 ¶ | |||
| (I) An act or event that disobeys or otherwise breaches security | (I) An act or event that disobeys or otherwise breaches security | |||
| policy. (See: compromise, penetration, security incident.) | policy. (See: compromise, penetration, security incident.) | |||
| $ seed | $ seed | |||
| (I) A value that is an input to a pseudorandom number generator. | (I) A value that is an input to a pseudorandom number generator. | |||
| $ selective-field confidentiality | $ selective-field confidentiality | |||
| (I) A data confidentiality service that preserves confidentiality | (I) A data confidentiality service that preserves confidentiality | |||
| for one or more parts (i.e., fields) of each packet. (See: | for one or more parts (i.e., fields) of each packet. (See: | |||
| selective-field integrity.) | selective-field integrity.) | |||
| Tutorial: Data confidentiality service usually is applied to | Tutorial: Data confidentiality service usually is applied to | |||
| entire SDUs, but some situations might require protection of only | entire SDUs, but some situations might require protection of only | |||
| part of each packet. For example, when Alice uses a debit card at | part of each packet. For example, when Alice uses a debit card at | |||
| an automated teller machine (ATM), perhaps only her personal | an automated teller machine (ATM), perhaps only her PIN is | |||
| identification number (PIN) is enciphered for confidentiality when | enciphered for confidentiality when her transaction request is | |||
| her transaction request is transmitted from the ATM to her bank's | transmitted from the ATM to her bank's computer. | |||
| computer. | ||||
| In any given operational situation, there could be many different | In any given operational situation, there could be many different | |||
| reasons for using selective field confidentiality. In the ATM | reasons for using selective field confidentiality. In the ATM | |||
| example, there are at least four possibilities: The service may | example, there are at least four possibilities: The service may | |||
| provide a fail-safe mode of operation, ensuring that the bank can | provide a fail-safe mode of operation, ensuring that the bank can | |||
| still process transactions (although with some risk) even when the | still process transactions (although with some risk) even when the | |||
| encryption system fails. It may make messages easier to work with | encryption system fails. It may make messages easier to work with | |||
| when doing system fault isolation. It may avoid problems with laws | when doing system fault isolation. It may avoid problems with laws | |||
| that prevent shipping enciphered data across international | that prevent shipping enciphered data across international | |||
| borders. It may improve efficiency by reducing processing load at | borders. It may improve efficiency by reducing processing load at | |||
| skipping to change at page 252, line 48 ¶ | skipping to change at page 259, line 13 ¶ | |||
| accounting, and controlling." [C4009] (Compare: KMID, long title.) | accounting, and controlling." [C4009] (Compare: KMID, long title.) | |||
| $ shroud | $ shroud | |||
| (D) /verb/ To encrypt a private key, possibly in concert with a | (D) /verb/ To encrypt a private key, possibly in concert with a | |||
| policy that prevents the key from ever being available in | policy that prevents the key from ever being available in | |||
| cleartext form beyond a certain, well-defined security perimeter. | cleartext form beyond a certain, well-defined security perimeter. | |||
| [PKCS12] (See: encrypt. Compare: seal, wrap.) | [PKCS12] (See: encrypt. Compare: seal, wrap.) | |||
| Deprecated Term: ISDs SHOULD NOT use this term as defined here; | Deprecated Term: ISDs SHOULD NOT use this term as defined here; | |||
| the definition duplicates the meaning of other, standard terms. | the definition duplicates the meaning of other, standard terms. | |||
| Instead, use "encrypt" or another term that is specific with | Instead, use "encrypt" or other terminology that is specific with | |||
| regard to the mechanism being used. | regard to the mechanism being used. | |||
| $ SHS | $ SHS | |||
| (N) See: Secure Hash Standard. | (N) See: Secure Hash Standard. | |||
| $ sign | $ sign | |||
| (I) Create a digital signature for a data object. (See: signer.) | (I) Create a digital signature for a data object. (See: signer.) | |||
| $ signal analysis | $ signal analysis | |||
| (I) Gaining indirect knowledge (inference) of communicated data by | (I) Gaining indirect knowledge (inference) of communicated data by | |||
| skipping to change at page 254, line 26 ¶ | skipping to change at page 260, line 43 ¶ | |||
| $ simple authentication | $ simple authentication | |||
| 1. (I) An authentication process that uses a password as the | 1. (I) An authentication process that uses a password as the | |||
| information needed to verify an identity claimed for an entity. | information needed to verify an identity claimed for an entity. | |||
| (Compare: strong authentication.) | (Compare: strong authentication.) | |||
| 2. (O) "Authentication by means of simple password arrangements." | 2. (O) "Authentication by means of simple password arrangements." | |||
| [X509] | [X509] | |||
| $ Simple Authentication and Security Layer (SASL) | $ Simple Authentication and Security Layer (SASL) | |||
| (I) An Internet specification [R2222] for adding authentication | (I) An Internet specification [R2222] for adding authentication | |||
| service to connection-based protocols. | service to connection-based protocols. (Compare: EAP, GSS-API.) | |||
| Tutorial: To use SASL, a protocol includes a command for | Tutorial: To use SASL, a protocol includes a command for | |||
| authenticating a user to a server and for optionally negotiating | authenticating a user to a server and for optionally negotiating | |||
| protection of subsequent protocol interactions. The command names | protection of subsequent protocol interactions. The command names | |||
| a registered security mechanism. SASL mechanisms include Kerberos, | a registered security mechanism. SASL mechanisms include Kerberos, | |||
| GSSAPI, S/KEY, and others. Some protocols that use SASL are IMAP4 | GSS-API, S/KEY, and others. Some protocols that use SASL are IMAP4 | |||
| and POP3. | and POP3. | |||
| $ Simple Key Management for Internet Protocols (SKIP) | $ Simple Key Management for Internet Protocols (SKIP) | |||
| (I) A key-distribution protocol that uses hybrid encryption to | (I) A key-distribution protocol that uses hybrid encryption to | |||
| convey session keys that are used to encrypt data in IP packets. | convey session keys that are used to encrypt data in IP packets. | |||
| Tutorial: SKIP was designed by Ashar Aziz and Whitfield Diffie at | Tutorial: SKIP was designed by Ashar Aziz and Whitfield Diffie at | |||
| Sun Microsystems and proposed as the standard key management | Sun Microsystems and proposed as the standard key management | |||
| protocol for IPsec, but IKE was chosen instead. Although IKE is | protocol for IPsec, but IKE was chosen instead. Although IKE is | |||
| mandatory for an IPsec implementation, the use of SKIP is not | mandatory for an IPsec implementation, the use of SKIP is not | |||
| excluded. | excluded. | |||
| SKIP uses the Diffie-Hellman algorithm (or could use another key- | SKIP uses the Diffie-Hellman-Merkle algorithm (or could use | |||
| agreement algorithm) to generate a key-encrypting key for use | another key-agreement algorithm) to generate a key-encrypting key | |||
| between two entities. A session key is used with a symmetric | for use between two entities. A session key is used with a | |||
| algorithm to encrypt data in one or more IP packets that are to be | symmetric algorithm to encrypt data in one or more IP packets that | |||
| sent from one entity to the other. A symmetric KEK is established | are to be sent from one entity to the other. A symmetric KEK is | |||
| and used to encrypt the session key, and the encrypted session key | established and used to encrypt the session key, and the encrypted | |||
| is placed in a SKIP header that is added to each IP packet that is | session key is placed in a SKIP header that is added to each IP | |||
| encrypted with that session key. | packet that is encrypted with that session key. | |||
| $ Simple Mail Transfer Protocol (SMTP) | $ Simple Mail Transfer Protocol (SMTP) | |||
| (I) A TCP-based, Application-Layer, Internet Standard protocol | (I) A TCP-based, Application-Layer, Internet Standard protocol | |||
| (RFC 821) for moving electronic mail messages from one computer to | (RFC 821) for moving electronic mail messages from one computer to | |||
| another. | another. | |||
| $ Simple Network Management Protocol (SNMP) | $ Simple Network Management Protocol (SNMP) | |||
| (I) A TCP-based, Application-Layer, Internet Standard protocol | (I) A TCP-based, Application-Layer, Internet Standard protocol | |||
| [R3410, R3414] for conveying management information between system | (RFCs 3410-3418) for conveying management information between | |||
| components that act as managers and agents. | system components that act as managers and agents. | |||
| $ Simple Public Key Infrastructure (SPKI) | $ Simple Public Key Infrastructure (SPKI) | |||
| (I) A set of experimental concepts (RFCs 2692, 2693) that were | (I) A set of experimental concepts (RFCs 2692, 2693) that were | |||
| proposed as alternatives to the concepts standardized in PKIX. | proposed as alternatives to the concepts standardized in PKIX. | |||
| $ simple security property | $ simple security property | |||
| (N) /formal model/ Property of a system whereby a subject has | (N) /formal model/ Property of a system whereby a subject has | |||
| read access to an object only if the clearance of the subject | read access to an object only if the clearance of the subject | |||
| dominates the classification of the object. See: Bell-LaPadula | dominates the classification of the object. See: Bell-LaPadula | |||
| model. | model. | |||
| skipping to change at page 258, line 45 ¶ | skipping to change at page 265, line 11 ¶ | |||
| the definition duplicates the meaning of other, standard terms. | the definition duplicates the meaning of other, standard terms. | |||
| Instead, use "attribute certificate" or another term that is | Instead, use "attribute certificate" or another term that is | |||
| specific with regard to the mechanism being used. | specific with regard to the mechanism being used. | |||
| $ software | $ software | |||
| (I) Computer programs (which are stored in and executed by | (I) Computer programs (which are stored in and executed by | |||
| computer hardware) and associated data (which also is stored in | computer hardware) and associated data (which also is stored in | |||
| the hardware) that may be dynamically written or modified during | the hardware) that may be dynamically written or modified during | |||
| execution. (Compare: firmware.) | execution. (Compare: firmware.) | |||
| $ software error | ||||
| (I) /threat action/ See: secondary definitions under "corruption", | ||||
| "exposure", and "incapacitation". | ||||
| $ SORA | $ SORA | |||
| (O) See: SSO-PIN ORA. | (O) See: SSO-PIN ORA. | |||
| $ source authentication | $ source authentication | |||
| (D) Synonym for "data origin authentication" or "peer entity | (D) Synonym for "data origin authentication" or "peer entity | |||
| authentication". (See: data origin authentication, peer entity | authentication". (See: data origin authentication, peer entity | |||
| authentication). | authentication). | |||
| Deprecated Term: ISDs SHOULD NOT use this term because it is | Deprecated Term: ISDs SHOULD NOT use this term because it is | |||
| ambiguous and, in either meaning, duplicates the meaning of | ambiguous and, in either meaning, duplicates the meaning of | |||
| skipping to change at page 260, line 36 ¶ | skipping to change at page 267, line 4 ¶ | |||
| (I) A cryptographic key that is generated and distributed as two | (I) A cryptographic key that is generated and distributed as two | |||
| or more separate data items that individually convey no knowledge | or more separate data items that individually convey no knowledge | |||
| of the whole key that results from combining the items. (See: dual | of the whole key that results from combining the items. (See: dual | |||
| control, split knowledge.) | control, split knowledge.) | |||
| $ split knowledge | $ split knowledge | |||
| 1. (I) A security technique in which two or more entities | 1. (I) A security technique in which two or more entities | |||
| separately hold data items that individually do not convey | separately hold data items that individually do not convey | |||
| knowledge of the information that results from combining the | knowledge of the information that results from combining the | |||
| items. (See: dual control, split key.) | items. (See: dual control, split key.) | |||
| 2. (O) "A condition under which two or more entities separately | 2. (O) "A condition under which two or more entities separately | |||
| have key components which individually convey no knowledge of the | have key components which individually convey no knowledge of the | |||
| plaintext key which will be produced when the key components are | plaintext key which will be produced when the key components are | |||
| combined in the cryptographic module." [FP140] | combined in the cryptographic module." [FP140] | |||
| $ spoof | ||||
| (I) /threat action/ See: secondary definition under "masquerade". | ||||
| $ spoofing attack | $ spoofing attack | |||
| (I) Synonym for "masquerade attack". | (I) Synonym for "masquerade attack". | |||
| $ spread spectrum | $ spread spectrum | |||
| (N) A TRANSEC technique that transmits a signal in a bandwidth | (N) A TRANSEC technique that transmits a signal in a bandwidth | |||
| much greater than the transmitted information needs. [F1037] | much greater than the transmitted information needs. [F1037] | |||
| Example: frequency hopping. | Example: frequency hopping. | |||
| Tutorial: Usually uses a sequential, noise-like signal structure | Tutorial: Usually uses a sequential, noise-like signal structure | |||
| to spread the normally narrowband information signal over a | to spread the normally narrowband information signal over a | |||
| skipping to change at page 261, line 32 ¶ | skipping to change at page 268, line 6 ¶ | |||
| $ SSH(trademark) | $ SSH(trademark) | |||
| (N) See: Secure Shell(trademark). | (N) See: Secure Shell(trademark). | |||
| $ SSL | $ SSL | |||
| (I) See: Secure Sockets Layer. | (I) See: Secure Sockets Layer. | |||
| $ SSO | $ SSO | |||
| (I) See: system security officer. | (I) See: system security officer. | |||
| $ SSO PIN | $ SSO PIN | |||
| (O) /MISSI/ One of two personal identification numbers that | (O) /MISSI/ One of two PINs that control access to the functions | |||
| control access to the functions and stored data of a FORTEZZA PC | and stored data of a FORTEZZA PC card. Knowledge of the SSO PIN | |||
| card. Knowledge of the SSO PIN enables the card user to perform | enables a card user to perform the FORTEZZA functions intended for | |||
| the FORTEZZA functions intended for use by an end user and also | use by an end user and also the functions intended for use by a | |||
| the functions intended for use by a MISSI CA. (See: user PIN.) | MISSI CA. (See: user PIN.) | |||
| $ SSO-PIN ORA (SORA) | $ SSO-PIN ORA (SORA) | |||
| (O) /MISSI/ A MISSI organizational RA that operates in a mode in | (O) /MISSI/ A MISSI organizational RA that operates in a mode in | |||
| which the ORA performs all card management functions and, | which the ORA performs all card management functions and, | |||
| therefore, requires knowledge of the SSO PIN for FORTEZZA PC cards | therefore, requires knowledge of the SSO PIN for FORTEZZA PC cards | |||
| issued to end users. | issued to end users. | |||
| $ Standards for Interoperable LAN/MAN Security (SILS) | $ Standards for Interoperable LAN/MAN Security (SILS) | |||
| 1. (N) The IEEE 802.10 standards committee. (See: FP191.) | 1. (N) The IEEE 802.10 standards committee. (See: FP191.) | |||
| skipping to change at page 263, line 4 ¶ | skipping to change at page 269, line 30 ¶ | |||
| Tutorial: Some internet applications need only datagram integrity, | Tutorial: Some internet applications need only datagram integrity, | |||
| but others require that an entire stream of packets be protected | but others require that an entire stream of packets be protected | |||
| against insertion, reordering, deletion, and delay: | against insertion, reordering, deletion, and delay: | |||
| - "Insertion": The destination receives an additional packet that | - "Insertion": The destination receives an additional packet that | |||
| was not sent by the source. | was not sent by the source. | |||
| - "Reordering": The destination receives packets in a different | - "Reordering": The destination receives packets in a different | |||
| order than that in which they were sent by the source. | order than that in which they were sent by the source. | |||
| - "Deletion": A packet sent by the source is not ever delivered | - "Deletion": A packet sent by the source is not ever delivered | |||
| to the intended destination. | to the intended destination. | |||
| - "Delay": A packet is detained for some period of time at a | - "Delay": A packet is detained for some period of time at a | |||
| relay, thus hampering and postponing the packet's normal timely | relay, thus hampering and postponing the packet's normal timely | |||
| delivery from source to destination. | delivery from source to destination. | |||
| $ strength | $ strength | |||
| 1. (I) /cryptography/ A cryptographic mechanism's level of | 1. (I) /cryptography/ A cryptographic mechanism's level of | |||
| resistance to attacks [R3776]. (See: strong.) | resistance to attacks [R3776]. (See: entropy, strong, work | |||
| factor.) | ||||
| 2. (N) /Common Criteria/ "Strength of function" is a | 2. (N) /Common Criteria/ "Strength of function" is a | |||
| "qualification of a TOE security function expressing the minimum | "qualification of a TOE security function expressing the minimum | |||
| efforts assumed necessary to defeat its expected security behavior | efforts assumed necessary to defeat its expected security behavior | |||
| by directly attacking its underlying security mechanisms": (See: | by directly attacking its underlying security mechanisms": (See: | |||
| strong.) | strong.) | |||
| - Basic: "A level of the TOE strength of function where analysis | - Basic: "A level of the TOE strength of function where analysis | |||
| shows that the function provides adequate protection against | shows that the function provides adequate protection against | |||
| casual breach of TOE security by attackers possessing a low | casual breach of TOE security by attackers possessing a low | |||
| attack potential." | attack potential." | |||
| skipping to change at page 265, line 4 ¶ | skipping to change at page 271, line 30 ¶ | |||
| $ subscriber | $ subscriber | |||
| (I) /PKI/ A user that is registered in a PKI and, therefore, can | (I) /PKI/ A user that is registered in a PKI and, therefore, can | |||
| be named in the "subject" field of a certificate issued by a CA in | be named in the "subject" field of a certificate issued by a CA in | |||
| that PKI. (See: registration, user.) | that PKI. (See: registration, user.) | |||
| Usage: This term is needed to distinguish registered users from | Usage: This term is needed to distinguish registered users from | |||
| two other kinds of PKI users: | two other kinds of PKI users: | |||
| - Users that access the PKI but are not identified to it: For | - Users that access the PKI but are not identified to it: For | |||
| example a relying party may access a PKI repository to obtain | example a relying party may access a PKI repository to obtain | |||
| the certificate of some other party. (See: access.) | the certificate of some other party. (See: access.) | |||
| - Users that do not access the PKI: For example, a relying party | - Users that do not access the PKI: For example, a relying party | |||
| (see: certificate user) may use a digital certificate that was | (see: certificate user) may use a digital certificate that was | |||
| obtained from a database that is not part of the PKI that | obtained from a database that is not part of the PKI that | |||
| issued the certificate. | issued the certificate. | |||
| $ substitution | $ substitution | |||
| (I) /cryptography/ A method of encryption in which elements of the | 1. (I) /cryptography/ A method of encryption in which elements of | |||
| plain text retain their original sequence but are replaced by | the plain text retain their sequential position but are replaced | |||
| other elements. (Compare: transposition.) | by elements of cipher text. (Compare: transposition.) | |||
| 2. (I) /threat action/ See: secondary definition under | ||||
| "falsification". | ||||
| $ subsystem | $ subsystem | |||
| (I) A collection of related system components that together | (I) A collection of related system components that together | |||
| perform a system function or deliver a system service. | perform a system function or deliver a system service. | |||
| $ superuser | $ superuser | |||
| (I) /UNIX/ Synonym for "root". | (I) /UNIX/ Synonym for "root". | |||
| $ superencryption | $ superencryption | |||
| (I) An encryption operation for which the plaintext input to be | (I) An encryption operation for which the plaintext input to be | |||
| skipping to change at page 269, line 37 ¶ | skipping to change at page 276, line 14 ¶ | |||
| the system but cannot provide input or otherwise interact with | the system but cannot provide input or otherwise interact with | |||
| the system. | the system. | |||
| - "Active user": A system entity that is (a) inside the system's | - "Active user": A system entity that is (a) inside the system's | |||
| security perimeter *or* (b) can provide input or otherwise | security perimeter *or* (b) can provide input or otherwise | |||
| interact with the system. | interact with the system. | |||
| $ TACACS | $ TACACS | |||
| (I) See: Terminal Access Controller (TAC) Access Control System. | (I) See: Terminal Access Controller (TAC) Access Control System. | |||
| $ TACACS+ | $ TACACS+ | |||
| (I) A TCP-based protocol that improves on TACACS and XTACACS by | (I) A TCP-based protocol that improves on TACACS by separating the | |||
| separating the functions of authentication, authorization, and | functions of authentication, authorization, and accounting and by | |||
| accounting and by encrypting all traffic between the network | encrypting all traffic between the network access server and | |||
| access server and authentication server. TACACS+ is extensible to | authentication server. TACACS+ is extensible to allow any | |||
| allow any authentication mechanism to be used with TACACS+ | authentication mechanism to be used with TACACS+ clients. | |||
| clients. (See: TACACS, XTACACS.) | ||||
| $ tamper | $ tamper | |||
| (I) Make an unauthorized modification in a system that alters the | (I) Make an unauthorized modification in a system that alters the | |||
| system's functioning in a way that degrades the security services | system's functioning in a way that degrades the security services | |||
| that the system was intended to provide. (See: QUADRANT. Compare: | that the system was intended to provide. (See: QUADRANT. Compare: | |||
| secondary definitions under "corruption" and "misuse".) | secondary definitions under "corruption" and "misuse".) | |||
| $ tamper-evident | $ tamper-evident | |||
| (I) A characteristic of a system component that provides evidence | (I) A characteristic of a system component that provides evidence | |||
| that an attack has been attempted on that component or system. | that an attack has been attempted on that component or system. | |||
| Usage: Usually involves physical evidence. (See: tamper.) | Usage: Usually involves physical evidence. (See: tamper.) | |||
| $ tamper-resistant | $ tamper-resistant | |||
| (I) A characteristic of a system component that provides passive | (I) A characteristic of a system component that provides passive | |||
| protection against an attack. (See: tamper.) | protection against an attack. (See: tamper.) | |||
| Usage: Usually involves physical means of protection. | Usage: Usually involves physical means of protection. | |||
| $ tampering | ||||
| (I) /threat action/ See: secondary definitions under "corruption" | ||||
| and "misuse". | ||||
| $ target of evaluation (TOE) | $ target of evaluation (TOE) | |||
| (N) /Common Criteria/ An information technology product or system | (N) /Common Criteria/ An information technology product or system | |||
| that is the subject of a security evaluation, together with the | that is the subject of a security evaluation, together with the | |||
| product's associated administrator and user documentation. | product's associated administrator and user documentation. | |||
| (Compare: protection profile.) | (Compare: protection profile.) | |||
| Tutorial: The security characteristics of the target of evaluation | Tutorial: The security characteristics of the target of evaluation | |||
| (TOE) are described in specific terms by a corresponding security | (TOE) are described in specific terms by a corresponding security | |||
| target, or in more general terms by a protection profile. In | target, or in more general terms by a protection profile. In | |||
| Common Criteria philosophy, it is important that a TOE be | Common Criteria philosophy, it is important that a TOE be | |||
| skipping to change at page 270, line 35 ¶ | skipping to change at page 277, line 14 ¶ | |||
| in the target. Part of this process is an evaluation of the target | in the target. Part of this process is an evaluation of the target | |||
| itself, to ensure that it is correct, complete, and internally | itself, to ensure that it is correct, complete, and internally | |||
| consistent and can be used as the baseline for the TOE evaluation. | consistent and can be used as the baseline for the TOE evaluation. | |||
| $ TCB | $ TCB | |||
| (N) See: trusted computing base. | (N) See: trusted computing base. | |||
| $ TCC field | $ TCC field | |||
| (I) See: Transmission Control Code field. | (I) See: Transmission Control Code field. | |||
| $ TCG | ||||
| (N) See: Trusted Computing Group. | ||||
| $ TCP | $ TCP | |||
| (I) See: Transmission Control Protocol. | (I) See: Transmission Control Protocol. | |||
| $ TCP/IP | $ TCP/IP | |||
| (I) Synonym for "Internet Protocol Suite". | (I) Synonym for "Internet Protocol Suite". | |||
| $ TCSEC | $ TCSEC | |||
| (N) See: Trusted Computer System Evaluation Criteria. (Compare: | (N) See: Trusted Computer System Evaluation Criteria. (Compare: | |||
| TSEC.) | TSEC.) | |||
| skipping to change at page 272, line 41 ¶ | skipping to change at page 279, line 26 ¶ | |||
| and read with known, state-of-the-art methods. Typically, the need | and read with known, state-of-the-art methods. Typically, the need | |||
| for and size of a TEMPEST zone established by a security policy | for and size of a TEMPEST zone established by a security policy | |||
| depends not only on the measured level of signal emitted by | depends not only on the measured level of signal emitted by | |||
| equipment, but also on the perceived threat level in the | equipment, but also on the perceived threat level in the | |||
| equipment's environment. | equipment's environment. | |||
| $ Terminal Access Controller (TAC) Access Control System (TACACS) | $ Terminal Access Controller (TAC) Access Control System (TACACS) | |||
| (I) A UDP-based authentication and access control protocol [R1492] | (I) A UDP-based authentication and access control protocol [R1492] | |||
| in which a network access server receives an identifier and | in which a network access server receives an identifier and | |||
| password from a remote terminal and passes them to a separate | password from a remote terminal and passes them to a separate | |||
| authentication server for verification. (See: TACACS+, XTACACS.) | authentication server for verification. (See: TACACS+.) | |||
| Tutorial: TACACS can provide service not only for network access | Tutorial: TACACS can provide service not only for network access | |||
| servers but also routers and other networked computing devices via | servers but also routers and other networked computing devices via | |||
| one or more centralized authentication servers. TACACS was | one or more centralized authentication servers. TACACS was | |||
| originally developed for ARPANET and has evolved for use in | originally developed for ARPANET and has evolved for use in | |||
| commercial equipment. | commercial equipment. | |||
| $ TESS | $ TESS | |||
| (I) See: The Exponential Encryption System. | (I) See: The Exponential Encryption System. | |||
| $ The Exponential Encryption System (TESS) | $ The Exponential Encryption System (TESS) | |||
| (I) A system of separate but cooperating cryptographic mechanisms | (I) A system of separate but cooperating cryptographic mechanisms | |||
| and functions for the secure authenticated exchange of | and functions for the secure authenticated exchange of | |||
| cryptographic keys, the generation of digital signatures, and the | cryptographic keys, the generation of digital signatures, and the | |||
| distribution of public keys. TESS uses asymmetric cryptography, | distribution of public keys. TESS uses asymmetric cryptography, | |||
| based on discrete exponentiation, and a structure of self- | based on discrete exponentiation, and a structure of self- | |||
| certified public keys. [R1824] | certified public keys. [R1824] | |||
| $ theft | ||||
| (I) /threat action/ See: secondary definitions under | ||||
| "interception" and "misappropriation". | ||||
| $ threat | $ threat | |||
| 1a. (I) A potential for violation of security, which exists when | 1a. (I) A potential for violation of security, which exists when | |||
| there is an entity, circumstance, capability, action, or event | there is an entity, circumstance, capability, action, or event | |||
| that could cause harm. (See: dangling threat, INFOCON level, | that could cause harm. (See: dangling threat, INFOCON level, | |||
| threat action, threat agent, threat consequence. Compare: attack, | threat action, threat agent, threat consequence. Compare: attack, | |||
| vulnerability.) | vulnerability.) | |||
| 1b. (N) Any circumstance or event with the potential to adversely | 1b. (N) Any circumstance or event with the potential to adversely | |||
| affect a system through unauthorized access, destruction, | affect a system through unauthorized access, destruction, | |||
| disclosure, or modification of data, or denial of service. [C4009] | disclosure, or modification of data, or denial of service. [C4009] | |||
| skipping to change at page 274, line 52 ¶ | skipping to change at page 281, line 41 ¶ | |||
| terms for lists of the types of threat actions that can result in | terms for lists of the types of threat actions that can result in | |||
| these consequences.) | these consequences.) | |||
| $ thumbprint | $ thumbprint | |||
| 1. (I) A pattern of curves formed by the ridges on the tip of a | 1. (I) A pattern of curves formed by the ridges on the tip of a | |||
| thumb. (See: biometric authentication, fingerprint.) | thumb. (See: biometric authentication, fingerprint.) | |||
| 2. (D) Synonym for some type of "hash result". (See: biometric | 2. (D) Synonym for some type of "hash result". (See: biometric | |||
| authentication. Compare: fingerprint.) | authentication. Compare: fingerprint.) | |||
| Deprecated Usage: ISDs SHOULD NOT use this term with definition 3 | Deprecated Usage: ISDs SHOULD NOT use this term with definition 2 | |||
| because that meaning mixes concepts in a potentially misleading | because that meaning mixes concepts in a potentially misleading | |||
| way. | way. | |||
| $ ticket | $ ticket | |||
| (I) Synonym for "capability token". | (I) Synonym for "capability token". | |||
| Tutorial: A ticket is usually granted by a centralized access | Tutorial: A ticket is usually granted by a centralized access | |||
| control server (ticket-granting agent) to authorize access to a | control server (ticket-granting agent) to authorize access to a | |||
| system resource for a limited time. Tickets can be implemented | system resource for a limited time. Tickets can be implemented | |||
| with either symmetric cryptography (see: Kerberos) or asymmetric | with either symmetric cryptography (see: Kerberos) or asymmetric | |||
| skipping to change at page 278, line 8 ¶ | skipping to change at page 284, line 46 ¶ | |||
| (I) A cryptographic key used to protect data that is stored on a | (I) A cryptographic key used to protect data that is stored on a | |||
| security token. | security token. | |||
| $ top CA | $ top CA | |||
| (I) Synonym for "root" in a certification hierarchy. (See: apex | (I) Synonym for "root" in a certification hierarchy. (See: apex | |||
| trust anchor.) | trust anchor.) | |||
| $ top-level specification | $ top-level specification | |||
| (I) "A non-procedural description of system behavior at the most | (I) "A non-procedural description of system behavior at the most | |||
| abstract level; typically a functional specification that omits | abstract level; typically a functional specification that omits | |||
| all implementation details." [NCS04] (See: Tutorial under | all implementation details." [NCS04] (See: formal top-level | |||
| "security policy".) | specification, Tutorial under "security policy".) | |||
| Tutorial: A top-level specification is at a level of abstraction | Tutorial: A top-level specification is at a level of abstraction | |||
| below "security model" and above "security architecture" (see: | below "security model" and above "security architecture" (see: | |||
| Tutorial under "security policy"). | Tutorial under "security policy"). | |||
| A top-level specification may be descriptive or formal: | A top-level specification may be descriptive or formal: | |||
| - "Descriptive top-level specification": One that is written in a | - "Descriptive top-level specification": One that is written in a | |||
| natural language like English or an informal design notation. | natural language like English or an informal design notation. | |||
| - "Formal top-level specification": One that is written in a | - "Formal top-level specification": One that is written in a | |||
| formal mathematical language to enable theorems to be proven | formal mathematical language to enable theorems to be proven | |||
| that show that the specification correctly implements a set of | that show that the specification correctly implements a set of | |||
| formal requirements or a formal security model. (See: | formal requirements or a formal security model. (See: | |||
| correctness proof.) | correctness proof.) | |||
| $ TPM | ||||
| (N) See: Trusted Platform Module. | ||||
| $ traceback | $ traceback | |||
| (I) Identification of the source of a data packet. (See: | (I) Identification of the source of a data packet. (See: | |||
| masquerade, network weaving.) | masquerade, network weaving.) | |||
| $ tracker | $ tracker | |||
| (N) An attack technique for achieving unauthorized disclosure from | (N) An attack technique for achieving unauthorized disclosure from | |||
| a statistical database. [Denns] (See: Tutorial under "inference | a statistical database. [Denns] (See: Tutorial under "inference | |||
| control".) | control".) | |||
| $ traffic analysis | $ traffic analysis | |||
| skipping to change at page 281, line 15 ¶ | skipping to change at page 288, line 6 ¶ | |||
| $ transmission security (TRANSEC) | $ transmission security (TRANSEC) | |||
| (I) COMSEC measures that protect communications from interception | (I) COMSEC measures that protect communications from interception | |||
| and exploitation by means other than cryptanalysis. Example: | and exploitation by means other than cryptanalysis. Example: | |||
| frequency hopping. (Compare: anti-jam, traffic flow | frequency hopping. (Compare: anti-jam, traffic flow | |||
| confidentiality.) | confidentiality.) | |||
| $ Transport Layer | $ Transport Layer | |||
| See: Internet Protocol Suite, OSIRM. | See: Internet Protocol Suite, OSIRM. | |||
| $ Transport Layer Security (TLS) | $ Transport Layer Security (TLS) | |||
| (I) TLS Version 1.0 is an Internet protocol [R2246] that is based | (I) TLS is an Internet protocol [R4346] that is based on, and very | |||
| on, and very similar to, SSL Version 3.0. (Compare: TLSP.) | similar to, SSL Version 3.0. (Compare: TLSP.) | |||
| Deprecated Usage: The TLS protocol is misnamed. The name | Tutorial: The TLS protocol is misnamed. The name misleadingly | |||
| misleadingly suggests that TLS is situated in the IPS Transport | suggests that TLS is situated in the IPS Transport Layer, but TLS | |||
| Layer, but TLS is always layered above a reliable Transport-Layer | is always layered above a reliable Transport-Layer protocol | |||
| protocol (usually TCP) and either layered immediately below or | (usually TCP) and either layered immediately below or integrated | |||
| integrated with an Application-Layer protocol (often HTTP). | with an Application-Layer protocol (often HTTP). | |||
| $ Transport Layer Security Protocol (TLSP) | $ Transport Layer Security Protocol (TLSP) | |||
| (N) An end-to-end encryption protocol (ISO 10736) that provides | (N) An end-to-end encryption protocol (ISO 10736) that provides | |||
| security services at the bottom of OSIRM Layer 4, i.e., directly | security services at the bottom of OSIRM Layer 4, i.e., directly | |||
| above Layer 3. (Compare: TLS.) | above Layer 3. (Compare: TLS.) | |||
| Tutorial: TLSP evolved directly from SP4. | Tutorial: TLSP evolved directly from SP4. | |||
| $ transport mode | $ transport mode | |||
| (I) One of two ways to apply AH or ESP to protect data packets; in | (I) One of two ways to apply AH or ESP to protect data packets; in | |||
| skipping to change at page 281, line 46 ¶ | skipping to change at page 288, line 37 ¶ | |||
| protocol stack. (Compare: tunnel mode.) | protocol stack. (Compare: tunnel mode.) | |||
| Tutorial: An IPsec transport-mode security association is always | Tutorial: An IPsec transport-mode security association is always | |||
| between two hosts; neither end has the role of a security gateway. | between two hosts; neither end has the role of a security gateway. | |||
| Whenever either end of an IPsec security association is a security | Whenever either end of an IPsec security association is a security | |||
| gateway, the association is required to be in tunnel mode. | gateway, the association is required to be in tunnel mode. | |||
| $ transposition | $ transposition | |||
| (I) /cryptography/ A method of encryption in which elements of the | (I) /cryptography/ A method of encryption in which elements of the | |||
| plain text retain their original form but undergo some change in | plain text retain their original form but undergo some change in | |||
| their relative position. (Compare: substitution.) | their sequential position. (Compare: substitution.) | |||
| $ trap door | $ trap door | |||
| (I) Synonym for "back door". | (I) Synonym for "back door". | |||
| $ trespass | ||||
| (I) /threat action/ See: secondary definition under "intrusion". | ||||
| $ Triple Data Encryption Algorithm | $ Triple Data Encryption Algorithm | |||
| (I) An block cipher that transforms each 64-bit plaintext block by | (I) An block cipher that transforms each 64-bit plaintext block by | |||
| applying the DEA three successive times, using either two or three | applying the DEA three successive times, using either two or three | |||
| different keys for an effective key length of 112 or 168 bits. | different keys for an effective key length of 112 or 168 bits. | |||
| [A9052, SP67] | [A9052, SP67] | |||
| Example: A variation proposed for IPsec's ESP uses a 168-bit key, | Example: A variation proposed for IPsec's ESP uses a 168-bit key, | |||
| consisting of three independent 56-bit values used by the DEA, and | consisting of three independent 56-bit values used by the DEA, and | |||
| a 64-bit initialization vector. Each datagram contains an IV to | a 64-bit initialization vector. Each datagram contains an IV to | |||
| ensure that each received datagram can be decrypted even when | ensure that each received datagram can be decrypted even when | |||
| other datagrams are dropped or a sequence of datagrams is | other datagrams are dropped or a sequence of datagrams is | |||
| reordered in transit. [R1851] | reordered in transit. [R1851] | |||
| $ triple-wrapped | $ triple-wrapped | |||
| (I) /S-MIME/ Data that has been signed with a digital signature, | (I) /S-MIME/ Data that has been signed with a digital signature, | |||
| then encrypted, and then signed again. [R2634] | then encrypted, and then signed again. [R2634] | |||
| skipping to change at page 285, line 16 ¶ | skipping to change at page 292, line 10 ¶ | |||
| Also, the term mixes concepts in a potentially misleading way. | Also, the term mixes concepts in a potentially misleading way. | |||
| Having "trust" involves factors unrelated to simply verifying | Having "trust" involves factors unrelated to simply verifying | |||
| signatures and performing other tests as specified by a standard | signatures and performing other tests as specified by a standard | |||
| algorithm for path validation (e.g., RFC 3280). Thus, even if a | algorithm for path validation (e.g., RFC 3280). Thus, even if a | |||
| user is able to validate a certification path algorithmically, the | user is able to validate a certification path algorithmically, the | |||
| user still might distrust one of the CAs that issued certificates | user still might distrust one of the CAs that issued certificates | |||
| in that path or distrust some other aspects of the PKI. | in that path or distrust some other aspects of the PKI. | |||
| $ trust-file PKI | $ trust-file PKI | |||
| (I) A non-hierarchical PKI in which each certificate user has a | (I) A non-hierarchical PKI in which each certificate user has its | |||
| local file (which is used by application software) of public-key | own local file (which is used by application software) of trust | |||
| certificates that the user trusts as starting points (i.e., trust | anchors, i.e., either public keys or public-key certificates that | |||
| anchors) for certification paths. (Compare: hierarchical PKI, mesh | the user trusts as starting points for certification paths. (See: | |||
| PKI, trusted certificate, web of trust.) | trust anchor, web of trust. Compare: hierarchical PKI, mesh PKI.) | |||
| Example: Popular browsers are distributed with an initial file of | Example: Popular browsers are distributed with an initial file of | |||
| trust anchor certificates, which often are self-signed | trust anchor certificates, which often are self-signed | |||
| certificates. Users can add certificates to the file or delete | certificates. Users can add certificates to the file or delete | |||
| from it. The file may be directly managed by the user, or the | from it. The file may be directly managed by the user, or the | |||
| user's organization may manage it from a centralized server. | user's organization may manage it from a centralized server. | |||
| $ trust hierarchy | $ trust hierarchy | |||
| (D) Synonym for "certification hierarchy". | (D) Synonym for "certification hierarchy". | |||
| Deprecated Usage: ISDs SHOULD NOT use this term because it mixes | Deprecated Usage: ISDs SHOULD NOT use this term because it mixes | |||
| concepts in a potentially misleading way. (See: trust, trust | concepts in a potentially misleading way, and because a trust | |||
| hierarchy could be implemented in other ways. (See: trust, trust | ||||
| chain, web of trust.) | chain, web of trust.) | |||
| $ trust level | $ trust level | |||
| (N) A characterization of a standard of security protection to be | (N) A characterization of a standard of security protection to be | |||
| met by an information system. (See: Common Criteria, TCSEC.) | met by an information system. (See: Common Criteria, TCSEC.) | |||
| Tutorial: A trust level is based not only on (a) the presence of | Tutorial: A trust level is based not only on (a) the presence of | |||
| security mechanisms, but also on the use of (b) systems | security mechanisms, but also on the use of (b) systems | |||
| engineering discipline to properly structure the system and (c) | engineering discipline to properly structure the system and (c) | |||
| implementation analysis to ensure that the system provides an | implementation analysis to ensure that the system provides an | |||
| skipping to change at page 286, line 31 ¶ | skipping to change at page 293, line 26 ¶ | |||
| public-key certificate might be (a) the root certificate in a | public-key certificate might be (a) the root certificate in a | |||
| hierarchical PKI, (b) the certificate of the CA that issued the | hierarchical PKI, (b) the certificate of the CA that issued the | |||
| user's own certificate in a mesh PKI, or (c) a certificate | user's own certificate in a mesh PKI, or (c) a certificate | |||
| provided with an application that uses a trust-file PKI. | provided with an application that uses a trust-file PKI. | |||
| $ Trusted Computer System Evaluation Criteria (TCSEC) | $ Trusted Computer System Evaluation Criteria (TCSEC) | |||
| (N) A standard for evaluating the security provided by operating | (N) A standard for evaluating the security provided by operating | |||
| systems [CSC001, DoD1]. Known as the "Orange Book" because of the | systems [CSC001, DoD1]. Known as the "Orange Book" because of the | |||
| color of its cover; first document in the Rainbow Series. (See: | color of its cover; first document in the Rainbow Series. (See: | |||
| Common Criteria, Deprecated Usage under "Green Book", Orange Book, | Common Criteria, Deprecated Usage under "Green Book", Orange Book, | |||
| trust level, trusted computer system. Compare: TSEC.) | trust level, trusted system. Compare: TSEC.) | |||
| Tutorial: The TCSEC defines classes of hierarchically ordered | Tutorial: The TCSEC defines classes of hierarchically ordered | |||
| assurance levels for rating computer systems. From highest to | assurance levels for rating computer systems. From highest to | |||
| lowest, the classes are as follows: | lowest, the classes are as follows: | |||
| - Division A: Verified protection. | - Division A: Verified protection. | |||
| Beyond A1 Beyond current technology. (See: beyond A1.) | Beyond A1 Beyond current technology. (See: beyond A1.) | |||
| Class A1 Verified design. (See: SCOMP.) | Class A1 Verified design. (See: SCOMP.) | |||
| - Division B: Mandatory protection. | - Division B: Mandatory protection. | |||
| Class B3 Security domains. | Class B3 Security domains. | |||
| Class B2 Structured protection. (See: Multics.) | Class B2 Structured protection. (See: Multics.) | |||
| skipping to change at page 286, line 53 ¶ | skipping to change at page 293, line 48 ¶ | |||
| - Division C: Discretionary protection. | - Division C: Discretionary protection. | |||
| Class C2 Controlled access protection. | Class C2 Controlled access protection. | |||
| Class C1 Discretionary security protection. | Class C1 Discretionary security protection. | |||
| - Division D: Minimal protection, i.e., has been evaluated but | - Division D: Minimal protection, i.e., has been evaluated but | |||
| does not meet the requirements for a higher evaluation class. | does not meet the requirements for a higher evaluation class. | |||
| $ trusted computing base (TCB) | $ trusted computing base (TCB) | |||
| (N) "The totality of protection mechanisms within a computer | (N) "The totality of protection mechanisms within a computer | |||
| system, including hardware, firmware, and software, the | system, including hardware, firmware, and software, the | |||
| combination of which is responsible for enforcing a security | combination of which is responsible for enforcing a security | |||
| policy." [NCS04] (See: "trusted" under "trust".) | policy." [NCS04] (See: "trusted" under "trust". Compare: TPM.) | |||
| $ Trusted Computing Group (TCG) | ||||
| (N) A not-for-profit, industry standards organization formed to | ||||
| develop, define, and promote open standards for hardware-enabled | ||||
| trusted computing and security technologies, including hardware | ||||
| building blocks and software interfaces, across multiple | ||||
| platforms, peripherals, and devices. (See: TPM, trusted system. | ||||
| Compare: TSIG.) | ||||
| $ trusted distribution | $ trusted distribution | |||
| (I) /COMPUSEC/ "A trusted method for distributing the TCB | (I) /COMPUSEC/ "A trusted method for distributing the TCB | |||
| hardware, software, and firmware components, both originals and | hardware, software, and firmware components, both originals and | |||
| updates, that provides methods for protecting the TCB from | updates, that provides methods for protecting the TCB from | |||
| modification during distribution and for detection of any changes | modification during distribution and for detection of any changes | |||
| to the TCB that may occur." [NCS04] (See: code signing, | to the TCB that may occur." [NCS04] (See: code signing, | |||
| configuration control.) | configuration control.) | |||
| $ trusted key | $ trusted key | |||
| skipping to change at page 287, line 34 ¶ | skipping to change at page 294, line 36 ¶ | |||
| 1a. (I) /COMPUSEC/ A mechanism by which a computer system user can | 1a. (I) /COMPUSEC/ A mechanism by which a computer system user can | |||
| communicate directly and reliably with the TCB and that can only | communicate directly and reliably with the TCB and that can only | |||
| be activated by the user or the TCB and cannot be imitated by | be activated by the user or the TCB and cannot be imitated by | |||
| untrusted software within the computer. [NCS04] | untrusted software within the computer. [NCS04] | |||
| 1b. (I) /COMSEC/ A mechanism by which a person or process can | 1b. (I) /COMSEC/ A mechanism by which a person or process can | |||
| communicate directly with a cryptographic module and that can only | communicate directly with a cryptographic module and that can only | |||
| be activated by the person, process, or module, and cannot be | be activated by the person, process, or module, and cannot be | |||
| imitated by untrusted software within the module. [FP140] | imitated by untrusted software within the module. [FP140] | |||
| $ Trusted Platform Module (TPM) | ||||
| (N) The name of a specification, published by the TCG, for a | ||||
| microcontroller that can store secured information; and also the | ||||
| general name of implementations of that specification. (Compare: | ||||
| TCB.) | ||||
| $ trusted process | $ trusted process | |||
| (I) A system component that has privileges that enable it to | (I) A system component that has privileges that enable it to | |||
| affect the state of system security and that can, therefore, | affect the state of system security and that can, therefore, | |||
| through incorrect or malicious execution, violate the system's | through incorrect or malicious execution, violate the system's | |||
| security policy. (See: privileged process, trusted system.) | security policy. (See: privileged process, trusted system.) | |||
| $ trusted public key | $ trusted public key | |||
| (I) A public key upon which a user relies; especially a public key | (I) A public key upon which a user relies; especially a public key | |||
| that is used as a trust anchor key. (See: certification path, root | that is used as a trust anchor key. (See: certification path, root | |||
| key, trust anchor key, validation.) | key, trust anchor key, validation.) | |||
| skipping to change at page 288, line 15 ¶ | skipping to change at page 295, line 23 ¶ | |||
| an assumption that the underlying communication channels, such as | an assumption that the underlying communication channels, such as | |||
| telephone lines or a LAN, are protected from attack.) | telephone lines or a LAN, are protected from attack.) | |||
| $ trusted system | $ trusted system | |||
| 1. (I) /information system/ A system that operates as expected, | 1. (I) /information system/ A system that operates as expected, | |||
| according to design and policy, doing what is required -- despite | according to design and policy, doing what is required -- despite | |||
| environmental disruption, human user and operator errors, and | environmental disruption, human user and operator errors, and | |||
| attacks by hostile parties -- and not doing other things [NRC98]. | attacks by hostile parties -- and not doing other things [NRC98]. | |||
| (See: trust level, trusted process. Compare: trustworthy.) | (See: trust level, trusted process. Compare: trustworthy.) | |||
| 2. (N) /multilevel secure/ "A [trusted computer system is a] | 2. (N) /multilevel secure/ "A [trusted system is a] system that | |||
| system that employs sufficient hardware and software assurance | employs sufficient hardware and software assurance measures to | |||
| measures to allow its use for simultaneous processing of a range | allow its use for simultaneous processing of a range of sensitive | |||
| of sensitive or classified information." [NCS04] (See: multilevel | or classified information." [NCS04] (See: multilevel security | |||
| security mode.) | mode.) | |||
| $ Trusted Systems Interoperability Group (TSIG) | $ Trusted Systems Interoperability Group (TSIG) | |||
| (N) A forum of computer vendors, system integrators, and users | (N) A forum of computer vendors, system integrators, and users | |||
| devoted to promoting interoperability of trusted computer systems. | devoted to promoting interoperability of trusted computer systems. | |||
| (See: trusted system. Compare: TCG.) | ||||
| $ trustworthy system | $ trustworthy system | |||
| 1. (I) A system that not only is trusted, but also warrants that | 1. (I) A system that not only is trusted, but also warrants that | |||
| trust because the system's behavior can be validated in some | trust because the system's behavior can be validated in some | |||
| convincing way, such as through formal analysis or code review. | convincing way, such as through formal analysis or code review. | |||
| (See: trust. Compare: trusted.) | (See: trust. Compare: trusted.) | |||
| 2. (O) /Digital Signature Guidelines/ "Computer hardware, | 2. (O) /Digital Signature Guidelines/ "Computer hardware, | |||
| software, and procedures that: (a) are reasonably secure from | software, and procedures that: (a) are reasonably secure from | |||
| intrusion and misuse; (b) provide a reasonably reliable level of | intrusion and misuse; (b) provide a reasonably reliable level of | |||
| skipping to change at page 291, line 50 ¶ | skipping to change at page 299, line 8 ¶ | |||
| duplicated. In that broader sense, anyone can forge a digital | duplicated. In that broader sense, anyone can forge a digital | |||
| certificate containing any set of data items whatsoever by | certificate containing any set of data items whatsoever by | |||
| generating the to-be-signed certificate and signing it with any | generating the to-be-signed certificate and signing it with any | |||
| private key whatsoever. But for PKI purposes, the forged data | private key whatsoever. But for PKI purposes, the forged data | |||
| structure is invalid if it is not signed with the true private key | structure is invalid if it is not signed with the true private key | |||
| of the claimed issuer; thus, the forgery will be detected when a | of the claimed issuer; thus, the forgery will be detected when a | |||
| certificate user uses the true public key of the claimed issuer to | certificate user uses the true public key of the claimed issuer to | |||
| verify the signature. | verify the signature. | |||
| $ uniform resource identifier (URI) | $ uniform resource identifier (URI) | |||
| (I) A type of formatted identifier (RFC 1630) that encapsulates | (I) A type of formatted identifier (RFC 3986) that encapsulates | |||
| the name of an Internet object, and labels it with an | the name of an Internet object, and labels it with an | |||
| identification of the name space, thus producing a member of the | identification of the name space, thus producing a member of the | |||
| universal set of names in registered name spaces and of addresses | universal set of names in registered name spaces and of addresses | |||
| referring to registered protocols or name spaces. | referring to registered protocols or name spaces. | |||
| Tutorial: URIs are used in HTML to identify the target of | Example: HTML uses URIs to identify the target of hyperlinks. | |||
| hyperlinks. In common practice, URIs include URLs and relative | ||||
| URLs (RFC 1808). | Usage: "A URI can be classified as a locator (see: URL), a name | |||
| (see: URN), or both. . . . Instances of URIs from any given scheme | ||||
| may have the characteristics of names or locators or both, often | ||||
| depending on the persistence and care in the assignment of | ||||
| identifiers by the naming authority, rather than on any quality of | ||||
| the scheme." ISDs SHOULD "use the general term 'URI' rather than | ||||
| the more restrictive terms 'URL' and 'URN'." (RFC 3986) | ||||
| $ uniform resource locator (URL) | $ uniform resource locator (URL) | |||
| (I) A type of formatted identifier (RFC 1738) that describes the | (I) A URI that describes the access method and location of an | |||
| access method and location of an information resource object on | information resource object on the Internet. (See: Usage under | |||
| the Internet. | "URI". Compare: URN.) | |||
| Tutorial: A URL is a URI that provides explicit instructions on | Tutorial: The term URL "refers to the subset of URIs that, in | |||
| how to access the named object. For example, | addition to identifying a resource, provide a means of locating | |||
| the resource by describing its primary access mechanism (e.g., its | ||||
| network 'location')." (RFC 3986) | ||||
| A URL provides explicit instructions on how to access the named | ||||
| object. For example, | ||||
| "ftp://bbnarchive.bbn.com/foo/bar/picture/cambridge.zip" is a URL. | "ftp://bbnarchive.bbn.com/foo/bar/picture/cambridge.zip" is a URL. | |||
| The part before the colon specifies the access scheme or protocol, | The part before the colon specifies the access scheme or protocol, | |||
| and the part after the colon is interpreted according to that | and the part after the colon is interpreted according to that | |||
| access method. Usually, two slashes after the colon indicate the | access method. Usually, two slashes after the colon indicate the | |||
| host name of a server (written as a domain name). In an FTP or | host name of a server (written as a domain name). In an FTP or | |||
| HTTP URL, the host name is followed by the path name of a file on | HTTP URL, the host name is followed by the path name of a file on | |||
| the server. The last (optional) part of a URL may be either a | the server. The last (optional) part of a URL may be either a | |||
| fragment identifier that indicates a position in the file, or a | fragment identifier that indicates a position in the file, or a | |||
| query string. | query string. | |||
| $ uniform resource name (URN) | $ uniform resource name (URN) | |||
| (I) A URI that has an institutional commitment to persistence and | (I) A URI with the properties of a name. (See: Usage under "URI". | |||
| availability. | Compare: URL.) | |||
| Tutorial: The term URN "has been used historically to refer to | ||||
| both URIs under the "urn" scheme (RFC 2141), which are required | ||||
| to remain globally unique and persistent even when the resource | ||||
| ceases to exist or becomes unavailable, and to any other URI with | ||||
| the properties of a name." (RFC 3986) | ||||
| $ untrusted | $ untrusted | |||
| (I) See: secondary definition under "trust". | (I) See: secondary definition under "trust". | |||
| $ untrusted process | $ untrusted process | |||
| 1. (I) A system component that is not able to affect the state of | 1. (I) A system component that is not able to affect the state of | |||
| system security through incorrect or malicious operation. Example: | system security through incorrect or malicious operation. Example: | |||
| A component that has its operations confined by a security kernel. | A component that has its operations confined by a security kernel. | |||
| (See: trusted process.) | (See: trusted process.) | |||
| skipping to change at page 293, line 43 ¶ | skipping to change at page 301, line 18 ¶ | |||
| $ user identity | $ user identity | |||
| (I) See: identity. | (I) See: identity. | |||
| $ user identifier | $ user identifier | |||
| (I) See: identifier. | (I) See: identifier. | |||
| $ user PIN | $ user PIN | |||
| (O) /MISSI/ One of two PINs that control access to the functions | (O) /MISSI/ One of two PINs that control access to the functions | |||
| and stored data of a FORTEZZA PC card. Knowledge of the user PIN | and stored data of a FORTEZZA PC card. Knowledge of the user PIN | |||
| enables the card user to perform the FORTEZZA functions that are | enables a card user to perform the FORTEZZA functions that are | |||
| intended for use by an end user. (Compare: SSO PIN.) | intended for use by an end user. (See: PIN. Compare: SSO PIN.) | |||
| $ user-PIN ORA (UORA) | $ user-PIN ORA (UORA) | |||
| (O) /MISSI/ A MISSI organizational RA that operates in a mode in | (O) /MISSI/ A MISSI organizational RA that operates in a mode in | |||
| which the ORA performs only the subset of card management | which the ORA performs only the subset of card management | |||
| functions that are possible with knowledge of the user PIN for a | functions that are possible with knowledge of the user PIN for a | |||
| FORTEZZA PC card. (See: no-PIN ORA, SSO-PIN ORA.) | FORTEZZA PC card. (See: no-PIN ORA, SSO-PIN ORA.) | |||
| $ usurpation | $ usurpation | |||
| (I) A circumstance or event that results in control of system | (I) A circumstance or event that results in control of system | |||
| services or functions by an unauthorized entity. This type of | services or functions by an unauthorized entity. This type of | |||
| threat consequence can be caused by the following types of threat | threat consequence can be caused by the following types of threat | |||
| actions: misappropriation, misuse. (See: access control.) | actions: misappropriation, misuse. (See: access control.) | |||
| $ UTCTime | $ UTCTime | |||
| (N) The ASN.1 data type "UTCTime" contains a calendar date | (N) The ASN.1 data type "UTCTime" contains a calendar date | |||
| (YYMMDD) and a time to a precision of either one minute (HHMM) or | (YYMMDD) and a time to a precision of either one minute (HHMM) or | |||
| one second (HHMMSS), where the time is either (a) Coordinated | one second (HHMMSS), where the time is either (a) Coordinated | |||
| Universal Time or (b) the local time followed by an offset that | Universal Time or (b) the local time followed by an offset that | |||
| enables Coordinated Universal Time to be calculated. Note: UTCTime | enables Coordinated Universal Time to be calculated. (See: | |||
| has the Year 2000 problem. (See: Coordinated Universal Time, | Coordinated Universal Time. Compare: GeneralizedTime.) | |||
| GeneralizedTime.) | ||||
| Usage: If you care about centuries or millennia, you probably need | ||||
| to use the GenralizedTime data type instead of UTCTime. | ||||
| $ v1 certificate | $ v1 certificate | |||
| (N) An abbreviation that ambiguously refers to either an "X.509 | (N) An abbreviation that ambiguously refers to either an "X.509 | |||
| public-key certificate in version 1 format" or an "X.509 attribute | public-key certificate in version 1 format" or an "X.509 attribute | |||
| certificate in version 1 format". | certificate in version 1 format". | |||
| Deprecated Usage: ISDs MAY use this term as an abbreviation of | Deprecated Usage: ISDs MAY use this term as an abbreviation of | |||
| "version 1 X.509 public-key certificate", but only after using the | "version 1 X.509 public-key certificate", but only after using the | |||
| full term at the first instance. Otherwise, the term is ambiguous, | full term at the first instance. Otherwise, the term is ambiguous, | |||
| because X.509 specifies both v1 public-key certificates and v1 | because X.509 specifies both v1 public-key certificates and v1 | |||
| skipping to change at page 297, line 21 ¶ | skipping to change at page 304, line 48 ¶ | |||
| a relatively public, physical (i.e., real) network (e.g., the | a relatively public, physical (i.e., real) network (e.g., the | |||
| Internet), often by using encryption (located at hosts or | Internet), often by using encryption (located at hosts or | |||
| gateways), and often by tunneling links of the virtual network | gateways), and often by tunneling links of the virtual network | |||
| across the real network. | across the real network. | |||
| Tutorial: A VPN is generally less expensive to build and operate | Tutorial: A VPN is generally less expensive to build and operate | |||
| than a dedicated real network, because the virtual network shares | than a dedicated real network, because the virtual network shares | |||
| the cost of system resources with other users of the underlying | the cost of system resources with other users of the underlying | |||
| real network. For example, if a corporation has LANs at several | real network. For example, if a corporation has LANs at several | |||
| different sites, each connected to the Internet by a firewall, the | different sites, each connected to the Internet by a firewall, the | |||
| corporation could create a VPN by (a) using encrypted tunnels to | corporation could create a VPN by using encrypted tunnels to | |||
| connect from firewall to firewall across the Internet and (b) not | connect from firewall to firewall across the Internet. | |||
| allowing any other traffic through the firewalls. | ||||
| $ virus | $ virus | |||
| (I) A self-replicating (and usually hidden) section of computer | (I) A self-replicating (and usually hidden) section of computer | |||
| software (usually malicious logic) that propagates by infecting -- | software (usually malicious logic) that propagates by infecting -- | |||
| i.e., inserting a copy of itself into and becoming part of -- | i.e., inserting a copy of itself into and becoming part of -- | |||
| another program. A virus cannot run by itself; it requires that | another program. A virus cannot run by itself; it requires that | |||
| its host program be run to make the virus active. | its host program be run to make the virus active. | |||
| $ VisaCash | $ Visa Cash | |||
| (O) A smartcard-based electronic money system that incorporates | (O) A smartcard-based electronic money system that incorporates | |||
| cryptography and can be used to make payments via the Internet. | cryptography and can be used to make payments via the Internet. | |||
| (See: IOTP.) | (See: IOTP.) | |||
| $ volatile media | $ volatile media | |||
| (I) Storage media that require an external power supply to | (I) Storage media that require an external power supply to | |||
| maintain stored information. (Compare: non-volatile media, | maintain stored information. (Compare: non-volatile media, | |||
| permanent storage.) | permanent storage.) | |||
| $ VPN | $ VPN | |||
| skipping to change at page 299, line 49 ¶ | skipping to change at page 307, line 24 ¶ | |||
| 2. (I) /capitalized/ ISDs SHOULD capitalize "Web" when using the | 2. (I) /capitalized/ ISDs SHOULD capitalize "Web" when using the | |||
| term (as either a noun or an adjective) to refer specifically to | term (as either a noun or an adjective) to refer specifically to | |||
| the World Wide Web. (Similarly, see: internet.) | the World Wide Web. (Similarly, see: internet.) | |||
| Usage: ISDs SHOULD NOT use "web" or "Web" in a way that might | Usage: ISDs SHOULD NOT use "web" or "Web" in a way that might | |||
| confuse these definitions with the PGP "web of trust". When using | confuse these definitions with the PGP "web of trust". When using | |||
| Web as an abbreviation for "World Wide Web", ISDs SHOULD fully | Web as an abbreviation for "World Wide Web", ISDs SHOULD fully | |||
| spell out the term at the first instance of usage. | spell out the term at the first instance of usage. | |||
| $ web of trust | $ web of trust | |||
| (D) /PGP/ A trust-file PKI technique used for building a file of | (D) /PGP/ A PKI architecture in which each certificate user | |||
| trusted public keys by making personal judgments about being able | defines their own trust anchor(s) by depending on personal | |||
| to trust certain people to be holding properly certified keys of | relationships. (See: trust anchor. Compare: hierarchical PKI, mesh | |||
| other people. (See: certification hierarchy, mesh PKI, trust | PKI.) | |||
| anchor, web, Web.) | ||||
| Deprecated Term: ISDs SHOULD NOT use this term; it mixes concepts | Deprecated Usage: ISDs SHOULD NOT use this term except with | |||
| in a potentially misleading way. This PKI technique does not | reference to PGP. This term mixes concepts in potentially | |||
| depend on World Wide Web technology. | misleading ways; e.g., this architecture does not depend on World | |||
| Wide Web technology. Instead of this term, ISDs MAY use "trust- | ||||
| file PKI". (See: web, Web). | ||||
| Tutorial: This type of architecture does not usually include | ||||
| public repositories of certificates. Instead, each certificate | ||||
| user builds their own, private repository of trusted public keys | ||||
| by making personal judgments about being able to trust certain | ||||
| people to be holding properly certified keys of other people. It | ||||
| is this set of person-to-person relationships from which the | ||||
| architecture gets its name. | ||||
| $ web server | $ web server | |||
| (I) A software process that runs on a host computer connected to a | (I) A software process that runs on a host computer connected to a | |||
| network and responds to HTTP requests made by client web browsers. | network and responds to HTTP requests made by client web browsers. | |||
| $ WEP | $ WEP | |||
| (N) See: Wired Equivalency Protocol. | (N) See: Wired Equivalency Protocol. | |||
| $ Wired Equivalent Privacy (WEP) | $ Wired Equivalent Privacy (WEP) | |||
| (N) A cryptographic protocol that is defined in the IEEE 802.11 | (N) A cryptographic protocol that is defined in the IEEE 802.11 | |||
| skipping to change at page 300, line 27 ¶ | skipping to change at page 308, line 11 ¶ | |||
| a.k.a. "Wired Equivalency Protocol". | a.k.a. "Wired Equivalency Protocol". | |||
| Tutorial: The WEP design, which uses RC4 to encrypt both the plain | Tutorial: The WEP design, which uses RC4 to encrypt both the plain | |||
| text and a CRC, has been shown to be flawed in multiple ways; and | text and a CRC, has been shown to be flawed in multiple ways; and | |||
| it also has often suffered from flawed implementation and | it also has often suffered from flawed implementation and | |||
| management. | management. | |||
| $ wiretapping | $ wiretapping | |||
| (I) An attack that intercepts and accesses information contained | (I) An attack that intercepts and accesses information contained | |||
| in a data flow in a communication system. (See: active | in a data flow in a communication system. (See: active | |||
| wiretapping, end-to-end encryption, passive wiretapping.) | wiretapping, end-to-end encryption, passive wiretapping, secondary | |||
| definition under "interception".) | ||||
| Usage: Although the term originally referred to making a | Usage: Although the term originally referred to making a | |||
| mechanical connection to an electrical conductor that links two | mechanical connection to an electrical conductor that links two | |||
| nodes, it is now used to refer to accessing information from any | nodes, it is now used to refer to accessing information from any | |||
| sort of medium used for a link or even from a node, such as a | sort of medium used for a link or even from a node, such as a | |||
| gateway or subnetwork switch. | gateway or subnetwork switch. | |||
| Tutorial: Wiretapping can be characterized according to intent: | Tutorial: Wiretapping can be characterized according to intent: | |||
| - "Active wiretapping" attempts to alter the data or otherwise | - "Active wiretapping" attempts to alter the data or otherwise | |||
| affect the flow. | affect the flow. | |||
| skipping to change at page 301, line 27 ¶ | skipping to change at page 309, line 12 ¶ | |||
| W3C Recommendations are similar to the standards published by | W3C Recommendations are similar to the standards published by | |||
| others organizations. (Compare: Internet Standard, ISO.) | others organizations. (Compare: Internet Standard, ISO.) | |||
| $ worm | $ worm | |||
| (I) A computer program that can run independently, can propagate a | (I) A computer program that can run independently, can propagate a | |||
| complete working version of itself onto other hosts on a network, | complete working version of itself onto other hosts on a network, | |||
| and may consume system resources destructively. (See: mobile code, | and may consume system resources destructively. (See: mobile code, | |||
| Morris Worm, virus.) | Morris Worm, virus.) | |||
| $ wrap | $ wrap | |||
| (D) /verb/ To use cryptography to provide data confidentiality | 1. (N) To use cryptography to provide data confidentiality service | |||
| service for keying material. (See: encrypt. Compare: seal, | for keying material. (See: encrypt, wrapping algorithm, wrapping | |||
| shroud.) | key. Compare: seal, shroud.) | |||
| Deprecated Definition: ISDs SHOULD NOT use this term as defined | 2. (D) To use cryptography to provide data confidentiality service | |||
| here; the definition duplicates the meaning of other, standard | for data in general. | |||
| terms. Instead, use "encrypt" or another term that is specific | ||||
| with regard to the mechanism being used. | Deprecated Usage: ISDs SHOULD NOT use this term with definition 2 | |||
| because that duplicates the meaning of the more widely understood | ||||
| "encrypt". | ||||
| $ wrapping algorithm | ||||
| (N) An encryption algorithm that is specifically intended for use | ||||
| in encrypting keys. (See: KEK, wrap.) | ||||
| $ wrapping key | ||||
| (N) Synonym for "KEK". (See: encrypt. Compare: seal, shroud.) | ||||
| $ write | $ write | |||
| (I) /COMPUSEC/ A fundamental operation in an information system | (I) /security model/ A system operation that causes a flow of | |||
| that results in a flow of information only from a subject to an | information from a subject to an object. (See: access mode. | |||
| object. (See: access mode.) | Compare: read.) | |||
| $ WWW | $ WWW | |||
| (I) See: World Wide Web. | (I) See: World Wide Web. | |||
| $ X.400 | $ X.400 | |||
| (N) An ITU-T Recommendation [X400] that is one part of a joint | (N) An ITU-T Recommendation [X400] that is one part of a joint | |||
| ITU-T/ISO multi-part standard (X.400-X.421) that defines the | ITU-T/ISO multi-part standard (X.400-X.421) that defines the | |||
| Message Handling Systems. (The ISO equivalent is IS 10021, parts | Message Handling Systems. (The ISO equivalent is IS 10021, parts | |||
| 1-7.) (See: Message Handling Systems.) | 1-7.) (See: Message Handling Systems.) | |||
| skipping to change at page 304, line 36 ¶ | skipping to change at page 312, line 29 ¶ | |||
| 4. issuer DN of the issuer (the CA who signed). | 4. issuer DN of the issuer (the CA who signed). | |||
| 5. validity Validity period; a pair of UTCTime | 5. validity Validity period; a pair of UTCTime | |||
| values: "not before" and "not after". | values: "not before" and "not after". | |||
| 6. subject DN of entity who owns the public key. | 6. subject DN of entity who owns the public key. | |||
| 7. subjectPublicKeyInfo Public key value and algorithm OID. | 7. subjectPublicKeyInfo Public key value and algorithm OID. | |||
| 8. issuerUniqueIdentifier Defined for v2, v3; optional. | 8. issuerUniqueIdentifier Defined for v2, v3; optional. | |||
| 9. subjectUniqueIdentifier Defined for v2, v2; optional. | 9. subjectUniqueIdentifier Defined for v2, v2; optional. | |||
| 10. extensions Defined only for v3; optional. | 10. extensions Defined only for v3; optional. | |||
| $ X9 | $ X9 | |||
| See: "Accredited Standards Committee X9" under "ANSI". | (N) See: "Accredited Standards Committee X9" under "ANSI". | |||
| $ XML | $ XML | |||
| (N) See: Extensible Markup Language. | (N) See: Extensible Markup Language. | |||
| $ XML-Signature. | $ XML-Signature. | |||
| (N) A W3C Recommendation (i.e. approved standard) that specifies | (N) A W3C Recommendation (i.e. approved standard) that specifies | |||
| XML syntax and processing rules for creating and representing | XML syntax and processing rules for creating and representing | |||
| digital signatures (based on asymmetric cryptography) that can be | digital signatures (based on asymmetric cryptography) that can be | |||
| applied to any digital content (i.e., any data object) including | applied to any digital content (i.e., any data object) including | |||
| other XML material. | other XML material. | |||
| $ XTACACS | ||||
| (I) Cisco Corporation's implementation of the Terminal Access | ||||
| Controller (TAC) Access Control System. This implementation | ||||
| enhances and extends the original TACACS. (See: TACACS, TACACS+.) | ||||
| $ Yellow Book | $ Yellow Book | |||
| (D) /slang/ Synonym for "Computer Security Requirements: Guidance | (D) /slang/ Synonym for "Computer Security Requirements: Guidance | |||
| for Applying the [U.S.] Department of Defense Trusted Computer | for Applying the [U.S.] Department of Defense Trusted Computer | |||
| System Evaluation Criteria in Specific Environments" [CSC3] (See: | System Evaluation Criteria in Specific Environments" [CSC3] (See: | |||
| "first law" under "Courtney's laws".) | "first law" under "Courtney's laws".) | |||
| Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | Deprecated Term: ISDs SHOULD NOT use this term as a synonym for | |||
| that or any other document. Instead, use the full proper name of | that or any other document. Instead, use the full proper name of | |||
| the document or, in subsequent references, a conventional | the document or, in subsequent references, a conventional | |||
| abbreviation. (See: Deprecated Usage under "Green Book", Rainbow | abbreviation. (See: Deprecated Usage under "Green Book", Rainbow | |||
| Series.) | Series.) | |||
| $ zero-knowledge proof | $ zero-knowledge proof | |||
| (I) /cryptography/ A proof-of-possession protocol whereby a system | (I) /cryptography/ A proof-of-possession protocol whereby a system | |||
| entity can prove possession of some information to another entity, | entity can prove possession of some information to another entity, | |||
| without revealing any of that information. (See: proof-of- | without revealing any of that information. (See: proof-of- | |||
| possession protocol.) | possession protocol.) | |||
| $ zeroize | $ zeroize | |||
| 1. (I) Synonym for "purge". Usage: Particularly with regard to | 1. (I) Synonym for "erase". (See: sanitize.) Usage: Particularly | |||
| erasing keys that are stored in a cryptographic module. | with regard to erasing keys that are stored in a cryptographic | |||
| module. | ||||
| 2. (O) Erase electronically stored data by altering the contents | 2. (O) Erase electronically stored data by altering the contents | |||
| of the data storage so as to prevent the recovery of the data. | of the data storage so as to prevent the recovery of the data. | |||
| [FP140] | [FP140] | |||
| 3. (O) Remove or eliminate all keying material, or a specific key, | ||||
| from a cryptographic equipment or fill device. [C4009] | ||||
| $ zombie | $ zombie | |||
| (I) /slang/ An Internet host computer that has been | (I) /slang/ An Internet host computer that has been | |||
| surreptitiously penetrated by an intruder that installed malicious | surreptitiously penetrated by an intruder that installed malicious | |||
| daemon software to cause the host to operate as an accomplice in | daemon software to cause the host to operate as an accomplice in | |||
| attacking other hosts, particularly in distributed attacks that | attacking other hosts, particularly in distributed attacks that | |||
| attempt denial of service through flooding. | attempt denial of service through flooding. | |||
| Deprecated Usage: It is likely that other cultures use different | Deprecated Usage: Other cultures likely use different metaphorical | |||
| metaphors for this concept. Therefore, to avoid international | terms (such as "robot") for this concept, and some use this term | |||
| misunderstanding, ISDs SHOULD NOT use this term. (See: Deprecated | for different concepts. Therefore, to avoid international | |||
| Usage under "Green Book".) | misunderstanding, ISDs SHOULD NOT use this term. Instead, use | |||
| "compromised, coopted computer" or other explicitly descriptive | ||||
| terminology. (See: Deprecated Usage under "Green Book".) | ||||
| $ zone of control | $ zone of control | |||
| (O) /EMSEC/ Synonym for "inspectable space". [C4009] (See: | (O) /EMSEC/ Synonym for "inspectable space". [C4009] (See: | |||
| TEMPEST.) | TEMPEST.) | |||
| 5. Informative References | 5. Informative References | |||
| This Glossary focuses on the Internet Standards Process. Therefore, | This Glossary focuses on the Internet Standards Process. Therefore, | |||
| this set of informative references emphasizes international, | this set of informative references emphasizes international, | |||
| governmental, and industry standards documents. Some RFCs that are | governmental, and industry standards documents. Some RFCs that are | |||
| skipping to change at page 306, line 35 ¶ | skipping to change at page 314, line 35 ¶ | |||
| (Wholesale)", ANSI X9.9-1986, 15 August 1986. | (Wholesale)", ANSI X9.9-1986, 15 August 1986. | |||
| [A9017] ---, "Financial Institution Key Management (Wholesale)", | [A9017] ---, "Financial Institution Key Management (Wholesale)", | |||
| X9.17, 4 April 1985. (Defines procedures for manual and | X9.17, 4 April 1985. (Defines procedures for manual and | |||
| automated management of keying material and uses DES to | automated management of keying material and uses DES to | |||
| provide key management for a variety of operational | provide key management for a variety of operational | |||
| environments.) | environments.) | |||
| [A9042] ---, "Public key Cryptography for the Financial Service | [A9042] ---, "Public key Cryptography for the Financial Service | |||
| Industry: Agreement of Symmetric Keys Using Diffie-Hellman | Industry: Agreement of Symmetric Keys Using Diffie-Hellman | |||
| and MQV Algorithms", X9.42, 29 January 1999. | and MQV Algorithms", X9.42, 29 January 1999. (See: Diffie- | |||
| Hellman-Merkle.) | ||||
| [A9052] ---, "Triple Data Encryption Algorithm Modes of Operation", | [A9052] ---, "Triple Data Encryption Algorithm Modes of Operation", | |||
| X9.52-1998, ANSI approval 9 November 1998. | X9.52-1998, ANSI approval 9 November 1998. | |||
| [A9062] ---, "Public Key Cryptography for the Financial Services | [A9062] ---, "Public Key Cryptography for the Financial Services | |||
| Industry: The Elliptic Curve Digital Signature Algorithm | Industry: The Elliptic Curve Digital Signature Algorithm | |||
| (ECDSA)", X9.62-1998, ANSI approval 7 January 1999. | (ECDSA)", X9.62-1998, ANSI approval 7 January 1999. | |||
| [A9063] ---, "---: Key Agreement and Key Transport Using Elliptic | [A9063] ---, "---: Key Agreement and Key Transport Using Elliptic | |||
| Curve Cryptography", X9.63-2001. | Curve Cryptography", X9.63-2001. | |||
| skipping to change at page 309, line 4 ¶ | skipping to change at page 317, line 5 ¶ | |||
| [Denn] Denning, D., "A Lattice Model of Secure Information Flow", | [Denn] Denning, D., "A Lattice Model of Secure Information Flow", | |||
| in "Communications of the ACM", vol. 19, no. 5, May 1976, | in "Communications of the ACM", vol. 19, no. 5, May 1976, | |||
| pp. 236-243. | pp. 236-243. | |||
| [Denns] Denning, D. and P. Denning, "Data Security", in "ACM | [Denns] Denning, D. and P. Denning, "Data Security", in "ACM | |||
| Computing Surveys", vol. 11, no. 3, September 1979, pp. 227- | Computing Surveys", vol. 11, no. 3, September 1979, pp. 227- | |||
| 249. | 249. | |||
| [DH76] Diffie, W. and M. Hellman, "New Directions in Cryptography", | [DH76] Diffie, W. and M. Hellman, "New Directions in Cryptography", | |||
| in "IEEE Transactions on Information Theory", vol. IT-22, | in "IEEE Transactions on Information Theory", vol. IT-22, | |||
| no. 6, November 1976, pp. 644-654. | no. 6, November 1976, pp. 644-654. (See: Diffie-Hellman- | |||
| Merkle.) | ||||
| [DoD1] U.S. DoD, "Department of Defense Trusted Computer System | [DoD1] U.S. DoD, "Department of Defense Trusted Computer System | |||
| Evaluation Criteria", DoD 5200.28-STD, 26 December 1985. | Evaluation Criteria", DoD 5200.28-STD, 26 December 1985. | |||
| (Supersedes [CSC1].) (Superseded by DoD Directive 8500.1.) | (Supersedes [CSC1].) (Superseded by DoD Directive 8500.1.) | |||
| [DoD4] ---, "NSA Key Recovery Assessment Criteria", 8 June 1998. | [DoD4] ---, "NSA Key Recovery Assessment Criteria", 8 June 1998. | |||
| [DoD5] ---, Directive 5200.1, "DoD Information Security Program", | [DoD5] ---, Directive 5200.1, "DoD Information Security Program", | |||
| 13 December 1996. | 13 December 1996. | |||
| [DoD6] ---, "DoD Architecture Framework", Version 1, 30 August | [DoD6] ---, "DoD Architecture Framework", Version 1, 30 August | |||
| 2003. | 2003. | |||
| [DoD7] ---, "X.509 Certificate Policy for the United States | [DoD7] ---, "X.509 Certificate Policy for the United States | |||
| Department of Defense", version 7, 18 December 2002. | Department of Defense", version 7, 18 December 2002. | |||
| (Superseded by [DoD9].) | (Superseded by [DoD9].) | |||
| [DoD9] ---, "X.509 Certificate Policy for the United States | [DoD9] ---, "X.509 Certificate Policy for the United States | |||
| Department of Defense", version 9, 9 February 2005. | Department of Defense", version 9, 9 February 2005. | |||
| [DoDGSA] ---, "Department of Defense Technical Architecture Framework | ||||
| for Information Management, Volume 6: Department of Defense | ||||
| (DoD) Goal Security Architecture", Defense Information | ||||
| Systems Agency, Center for Standards, version 3.0, 15 April | ||||
| 1996. | ||||
| [DSG] American Bar Association, "Digital Signature Guidelines: | [DSG] American Bar Association, "Digital Signature Guidelines: | |||
| Legal Infrastructure for Certification Authorities and | Legal Infrastructure for Certification Authorities and | |||
| Secure Electronic Commerce", Chicago, IL, 1 August 1996. | Secure Electronic Commerce", Chicago, IL, 1 August 1996. | |||
| (See: [PAG].) | (See: [PAG].) | |||
| [ElGa] El Gamal, T., "A Public-Key Cryptosystem and a Signature | [ElGa] El Gamal, T., "A Public-Key Cryptosystem and a Signature | |||
| Scheme Based on Discrete Logarithms", in "IEEE Transactions | Scheme Based on Discrete Logarithms", in "IEEE Transactions | |||
| on Information Theory", vol. IT-31, no. 4, 1985, pp. 469- | on Information Theory", vol. IT-31, no. 4, 1985, pp. 469- | |||
| 472. | 472. | |||
| skipping to change at page 313, line 37 ¶ | skipping to change at page 321, line 45 ¶ | |||
| [M0404] U.S. Office of Management and Budget, "E-Authentication | [M0404] U.S. Office of Management and Budget, "E-Authentication | |||
| Guidance for Federal Agencies", Memorandum M-04-04, 16 | Guidance for Federal Agencies", Memorandum M-04-04, 16 | |||
| December 2003. | December 2003. | |||
| [Mene] Menezes, A. et al, "Some Key Agreement Protocols Providing | [Mene] Menezes, A. et al, "Some Key Agreement Protocols Providing | |||
| Implicit Authentication", in "The 2nd Workshop on Selected | Implicit Authentication", in "The 2nd Workshop on Selected | |||
| Areas in Cryptography", 1995. | Areas in Cryptography", 1995. | |||
| [Moor] Moore, A. et al, "Attack Modeling for Information Security | [Moor] Moore, A. et al, "Attack Modeling for Information Security | |||
| and Survivability", Carnegie-Mellon University / Software | and Survivability", Carnegie Mellon University / Software | |||
| Engineering Institute, CMU/SEI-2001-TN-001, March 2001. | Engineering Institute, CMU/SEI-2001-TN-001, March 2001. | |||
| [Murr] Murray, W., "Courtney's Laws of Security", in "Infosecurity | [Murr] Murray, W., "Courtney's Laws of Security", in "Infosecurity | |||
| News", March/April 1993, p. 65. | News", March/April 1993, p. 65. | |||
| [N4001] National Security Telecommunications and Information System | [N4001] National Security Telecommunications and Information System | |||
| Security Committee, "Controlled Cryptographic Items", | Security Committee, "Controlled Cryptographic Items", | |||
| NSTISSI No. 4001, 25 March 1985. | NSTISSI No. 4001, 25 March 1985. | |||
| [N4006] ---, "Controlled Cryptographic Items", NSTISSI No. 4006, 2 | [N4006] ---, "Controlled Cryptographic Items", NSTISSI No. 4006, 2 | |||
| skipping to change at page 314, line 50 ¶ | skipping to change at page 323, line 6 ¶ | |||
| Operating System (KSOS)", in "Proceedings of the 7th DoD/NBS | Operating System (KSOS)", in "Proceedings of the 7th DoD/NBS | |||
| Computer Security Conference", 24-26 September 1984. | Computer Security Conference", 24-26 September 1984. | |||
| [PGP] Garfinkel, S.. "PGP: Pretty Good Privacy", O'Reilly & | [PGP] Garfinkel, S.. "PGP: Pretty Good Privacy", O'Reilly & | |||
| Associates, Inc., Sebastopol, CA, 1995. | Associates, Inc., Sebastopol, CA, 1995. | |||
| [PKCS] Kaliski Jr., B., "An Overview of the PKCS Standards", RSA | [PKCS] Kaliski Jr., B., "An Overview of the PKCS Standards", RSA | |||
| Data Security, Inc., 3 June 1991. | Data Security, Inc., 3 June 1991. | |||
| [PKC05] RSA Laboratories, "PKCS #5: Password-Based Encryption | [PKC05] RSA Laboratories, "PKCS #5: Password-Based Encryption | |||
| Standard ", version 1.5, 1 November 1993. (See: [R2898].) | Standard ", version 1.5, 1 November 1993. (See: RFC 2898.) | |||
| [PKC07] ---, "PKCS #7: Cryptographic Message Syntax Standard", | [PKC07] ---, "PKCS #7: Cryptographic Message Syntax Standard", | |||
| version 1.5, 1 November 1993. | version 1.5, 1 November 1993. (See: RFC 2315.) | |||
| [PKC10] ---, "PKCS #10: Certification Request Syntax Standard", | [PKC10] ---, "PKCS #10: Certification Request Syntax Standard", | |||
| version 1.0, 1 November 1993. | version 1.0, 1 November 1993. | |||
| [PKC11] ---, "PKCS #11: Cryptographic Token Interface Standard", | [PKC11] ---, "PKCS #11: Cryptographic Token Interface Standard", | |||
| version 1.0, 28 April 1995. | version 1.0, 28 April 1995. | |||
| [PKC12] ---, "PKCS #12: Personal Information Exchange Syntax", | [PKC12] ---, "PKCS #12: Personal Information Exchange Syntax", | |||
| version 1.0, 24 June 1995. | version 1.0, 24 June 1995. | |||
| skipping to change at page 316, line 6 ¶ | skipping to change at page 324, line 14 ¶ | |||
| [R1457] Housley, R., "Security Label Framework for the Internet", | [R1457] Housley, R., "Security Label Framework for the Internet", | |||
| RFC 1457, May 1993. | RFC 1457, May 1993. | |||
| [R1492] Finseth, C., "An Access Control Protocol, Sometimes Called | [R1492] Finseth, C., "An Access Control Protocol, Sometimes Called | |||
| TACACS", RFC 1492, July 1993. | TACACS", RFC 1492, July 1993. | |||
| [R1507] Kaufman, C., "DASS: Distributed Authentication Security | [R1507] Kaufman, C., "DASS: Distributed Authentication Security | |||
| Service", RFC 1507, September 1993. | Service", RFC 1507, September 1993. | |||
| [R1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication | ||||
| Service (V5)", RFC 1510, September 1993. (Superseded by RFC | ||||
| 4120.) | ||||
| [R1731] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, | [R1731] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, | |||
| December 1994. | December 1994. | |||
| [R1734] ---, "POP3 AUTHentication Command", RFC 1734, Dec, 1994. | [R1734] ---, "POP3 AUTHentication Command", RFC 1734, Dec, 1994. | |||
| [R1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness | [R1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness | |||
| Recommendations for Security", RFC 1750, December 1994. | Recommendations for Security", RFC 1750, December 1994. | |||
| (Superseded by RFC 4086.) | (Superseded by RFC 4086.) | |||
| [R1760] Haller, N., "The S/KEY One-Time Password System", RFC 1760, | [R1760] Haller, N., "The S/KEY One-Time Password System", RFC 1760, | |||
| skipping to change at page 316, line 41 ¶ | skipping to change at page 324, line 45 ¶ | |||
| [R1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME | [R1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME | |||
| Object Security Services", RFC 1848, October 1995. | Object Security Services", RFC 1848, October 1995. | |||
| [R1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES | [R1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES | |||
| Transform", RFC 1851, September 1995. | Transform", RFC 1851, September 1995. | |||
| [R1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. | [R1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. | |||
| Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. | Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. | |||
| [R1938] Haller, N. and C. Metz, "A One-Time Password System", RFC | ||||
| 1938, May 1996. (Superseded by RFC 2289.) | ||||
| [R1958] Carpenter, B., "Architectural Principles of the Internet", | [R1958] Carpenter, B., "Architectural Principles of the Internet", | |||
| RFC 1958, June 1996. | RFC 1958, June 1996. | |||
| [R1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, | [R1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, | |||
| August 1996. | August 1996. | |||
| [R1994] Simpson, W., "PPP Challenge Handshake Authentication | [R1994] Simpson, W., "PPP Challenge Handshake Authentication | |||
| Protocol (CHAP)", RFC 1994, August 1996. | Protocol (CHAP)", RFC 1994, August 1996. | |||
| [R2078] Linn, J., "Generic Security Service Application Program | [R2078] Linn, J., "Generic Security Service Application Program | |||
| skipping to change at page 317, line 31 ¶ | skipping to change at page 325, line 32 ¶ | |||
| [R2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, | [R2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, | |||
| September 1997. | September 1997. | |||
| [R2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- | [R2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- | |||
| SHA-1", RFC 2202, Sep. 1997. | SHA-1", RFC 2202, Sep. 1997. | |||
| [R2222] Myers, J., "Simple Authentication and Security Layer | [R2222] Myers, J., "Simple Authentication and Security Layer | |||
| (SASL)", RFC 2222, October 1997. | (SASL)", RFC 2222, October 1997. | |||
| [R2246] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", | [R2289] Haller, N., Metz, C., Nesser, P., and M. Straw, "A One-Time | |||
| RFC 2246, January 1999. | Password System", STD 61, RFC 2289, February 1998. | |||
| [R2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax, Version | ||||
| 1.5", RFC 2315, March 1998. | ||||
| [R2323] Ramos, A., "IETF Identification and Security Guidelines", | [R2323] Ramos, A., "IETF Identification and Security Guidelines", | |||
| RFC 2323, 1 April 1998. (Intended for humorous entertainment | RFC 2323, 1 April 1998. (Intended for humorous entertainment | |||
| -- "please laugh loud and hard" -- and does not contain | -- "please laugh loud and hard" -- and does not contain | |||
| serious security information.) | serious security information.) | |||
| [R2350] Brownlee, N. and E. Guttman, "Expectations for Computer | [R2350] Brownlee, N. and E. Guttman, "Expectations for Computer | |||
| Security Incident Response", BCP 21, RFC 2350, June 1998. | Security Incident Response", BCP 21, RFC 2350, June 1998. | |||
| [R2356] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal | [R2356] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal | |||
| skipping to change at page 318, line 21 ¶ | skipping to change at page 326, line 18 ¶ | |||
| [R2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload | [R2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload | |||
| (ESP)", RFC 2406, November 1998. | (ESP)", RFC 2406, November 1998. | |||
| [R2407] Piper, D. "The Internet IP Security Domain of Interpretation | [R2407] Piper, D. "The Internet IP Security Domain of Interpretation | |||
| for ISAKMP", RFC 2407, November 1998. | for ISAKMP", RFC 2407, November 1998. | |||
| [R2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, | [R2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, | |||
| "Internet Security Association and Key Management Protocol | "Internet Security Association and Key Management Protocol | |||
| (ISAKMP)", RFC 2408, November 1998. | (ISAKMP)", RFC 2408, November 1998. | |||
| [R2409] Harkins, D. and D. Carrel, "The Internet Key Exchange | ||||
| (IKE)", RFC 2409, November 1998. | ||||
| [R2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and | [R2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and | |||
| Its Use With IPsec", RFC 2410, November 1998. | Its Use With IPsec", RFC 2410, November 1998. | |||
| [R2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC | [R2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC | |||
| 2412, November 1998. | 2412, November 1998. | |||
| [R2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher | [R2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher | |||
| Algorithms", RFC 2451, November 1998. | Algorithms", RFC 2451, November 1998. | |||
| [R2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security | [R2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security | |||
| Handbook", RFC 2504, February 1999. | Handbook", RFC 2504, February 1999. | |||
| [R2510] Adams, C. and S. Farrell, "Internet X.509 Public Key | ||||
| Infrastructure Certificate Management Protocols", RFC 2510, | ||||
| March 1999. | ||||
| [R2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. | [R2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. | |||
| Adams, "X.509 Internet Public Key Infrastructure Online | Adams, "X.509 Internet Public Key Infrastructure Online | |||
| Certificate Status Protocol - OCSP", RFC 2560, June 1999. | Certificate Status Protocol - OCSP", RFC 2560, June 1999. | |||
| [R2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption | [R2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption | |||
| Algorithm", RFC 2612, June 1999. | Algorithm", RFC 2612, June 1999. | |||
| [R2628] Smyslov, V., "Simple Cryptographic Program Interface (Crypto | [R2628] Smyslov, V., "Simple Cryptographic Program Interface (Crypto | |||
| API)", RFC 2628, June 1999. | API)", RFC 2628, June 1999. | |||
| [R2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC | [R2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC | |||
| 2631, June 1999. | 2631, June 1999. (See: Diffie-Hellman-Merkle.) | |||
| [R2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC | [R2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC | |||
| 2634, June 1999. | 2634, June 1999. | |||
| [R2635] Hambridge, S. and A. Lunde, "DON'T SPEW: A Set of Guidelines | [R2635] Hambridge, S. and A. Lunde, "DON'T SPEW: A Set of Guidelines | |||
| for Mass Unsolicited Mailings and Postings", RFC 2635, June | for Mass Unsolicited Mailings and Postings", RFC 2635, June | |||
| 1999. | 1999. | |||
| [R2660] Rescorla, E. and A. Schiffman, "The Secure HyperText | [R2660] Rescorla, E. and A. Schiffman, "The Secure HyperText | |||
| Transfer Protocol", RFC 2660, August 1999. | Transfer Protocol", RFC 2660, August 1999. | |||
| skipping to change at page 319, line 24 ¶ | skipping to change at page 327, line 16 ¶ | |||
| 1.0", RFC 2801, April 2000. | 1.0", RFC 2801, April 2000. | |||
| [R2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: | [R2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: | |||
| Defeating Denial of Service Attacks which employ IP Source | Defeating Denial of Service Attacks which employ IP Source | |||
| Address Spoofing", BCP 38, RFC 2827, May 2000. | Address Spoofing", BCP 38, RFC 2827, May 2000. | |||
| [R2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote | [R2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote | |||
| Authentication Dial In User Service (RADIUS)", RFC 2865, | Authentication Dial In User Service (RADIUS)", RFC 2865, | |||
| June 2000. | June 2000. | |||
| [R2898] Kaliski, B., "PKCS #5: Password-Based Cryptography | ||||
| Specification, Version 2.0", RFC 2898, September 2000. (See: | ||||
| [PKC05].) | ||||
| [R3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, | [R3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, | |||
| "Policy Core Information Model -- Version 1 Specification", | "Policy Core Information Model -- Version 1 Specification", | |||
| RFC 3060, February 2001. | RFC 3060, February 2001. | |||
| [R3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, | [R3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, | |||
| M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, | M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, | |||
| J., and S. Waldbusser, "Terminology for Policy-Based | J., and S. Waldbusser, "Terminology for Policy-Based | |||
| Management", RFC 3198, November 2001. | Management", RFC 3198, November 2001. | |||
| [R3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet | [R3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet | |||
| X.509 Public Key Infrastructure Certificate and Certificate | X.509 Public Key Infrastructure Certificate and Certificate | |||
| Revocation List (CRL) Profile", RFC 3280, April 2002. | Revocation List (CRL) Profile", RFC 3280, April 2002. | |||
| [R3410] Case, J., Mundy, R., Partain, D., and B. Stewart, | ||||
| "Introduction and Applicability Statements for Internet- | ||||
| Standard Management Framework", RFC 3410, December 2002. | ||||
| [R3414] Blumenthal, U. and B. Wijnen, "User-based Security Model | ||||
| (USM) for version 3 of the Simple Network Management | ||||
| Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. | ||||
| [R3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "Group | [R3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "Group | |||
| Domain of Interpretation", RFC 3547, July 2003. | Domain of Interpretation", RFC 3547, July 2003. | |||
| [R3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text | [R3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text | |||
| on Security Considerations", RFC 3552, July 2003. | on Security Considerations", RFC 3552, July 2003. | |||
| [R3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, | [R3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, | |||
| "Internet X.509 Public Key Infrastructure Certificate Policy | "Internet X.509 Public Key Infrastructure Certificate Policy | |||
| and Certification Practices Framework", RFC 3647, November | and Certification Practices Framework", RFC 3647, November | |||
| 2003. | 2003. | |||
| skipping to change at page 320, line 47 ¶ | skipping to change at page 328, line 26 ¶ | |||
| 4033, March 2005. | 4033, March 2005. | |||
| [R4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [R4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
| Rose, "Resource Records for the DNS Security Extensions", | Rose, "Resource Records for the DNS Security Extensions", | |||
| RFC 4034, March 2005. | RFC 4034, March 2005. | |||
| [R4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [R4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
| Rose, "Protocol Modifications for the DNS Security | Rose, "Protocol Modifications for the DNS Security | |||
| Extensions", RFC 4035, March 2005. | Extensions", RFC 4035, March 2005. | |||
| [R4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The | ||||
| Kerberos Network Authentication Service (V5)", RFC 4120, | ||||
| July 2005. | ||||
| [R4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. | [R4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. | |||
| Nicholas, "Internet X.509 Public Key Infrastructure: | Nicholas, "Internet X.509 Public Key Infrastructure: | |||
| Certification Path Building", RFC 4158, September 2005. | Certification Path Building", RFC 4158, September 2005. | |||
| [R4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet | ||||
| X.509 Public Key Infrastructure Certificate Management | ||||
| Protocol (CMP)", RFC 4210, September 2005. | ||||
| [R4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC | ||||
| 4306, December 2005. | ||||
| [R4346] Dierks, T. and E. Rescorla, "The Transport Layer Security | ||||
| (TLS) Protocol Version 1.1", RFC 4346, April 2006. | ||||
| [Raym] Raymond, E., ed., "The On-Line Hacker Jargon File", version | [Raym] Raymond, E., ed., "The On-Line Hacker Jargon File", version | |||
| 4.0.0, 24 July 1996. (See: http://www.catb.org/~esr/jargon | 4.0.0, 24 July 1996. (See: http://www.catb.org/~esr/jargon | |||
| for the latest version. Also, "The New Hacker's Dictionary", | for the latest version. Also, "The New Hacker's Dictionary", | |||
| 3rd edition, MIT Press, September 1996, ISBN 0-262-68092-0.) | 3rd edition, MIT Press, September 1996, ISBN 0-262-68092-0.) | |||
| [Roge] Rogers, H., "An Overview of the CANEWARE Program", in | [Roge] Rogers, H., "An Overview of the CANEWARE Program", in | |||
| "Proceedings of the 10th National Computer Security | "Proceedings of the 10th National Computer Security | |||
| Conference", NIST and NCSC, September 1987. | Conference", NIST and NCSC, September 1987. | |||
| [RSCG] NSA, "Router Security Configuration Guide: Principles and | [RSCG] NSA, "Router Security Configuration Guide: Principles and | |||
| skipping to change at page 322, line 42 ¶ | skipping to change at page 330, line 35 ¶ | |||
| [SP32] Kuhn, D. (NIST), "Introduction to Public Key Technology and | [SP32] Kuhn, D. (NIST), "Introduction to Public Key Technology and | |||
| the Federal PKI Infrastructure ", --- 800-32, 26 February | the Federal PKI Infrastructure ", --- 800-32, 26 February | |||
| 2001. | 2001. | |||
| [SP33] Stoneburner, G. (NIST), "Underlying Technical Models for | [SP33] Stoneburner, G. (NIST), "Underlying Technical Models for | |||
| Information Technology Security", --- 800-33, December 2001. | Information Technology Security", --- 800-33, December 2001. | |||
| [SP37] Ross, R. et al (NIST), "Guide for the Security Certification | [SP37] Ross, R. et al (NIST), "Guide for the Security Certification | |||
| and Accreditation of Federal Information Systems", --- 800- | and Accreditation of Federal Information Systems", --- 800- | |||
| 37, May 2004 | 37, May 2004. | |||
| [SP41] Wack. J. et al (NIST), "Guidelines on Firewalls and Firewall | [SP38A] Dworkin, M. (NIST), "Recommendation for Block Cipher Modes | |||
| of Operation: Methods and Techniques", --- 800-38A, 2001 | ||||
| Edition, December 2001. | ||||
| [SP38B] ---, "Recommendation for Block Cipher Modes of Operation: | ||||
| The CMAC Mode for Authentication", --- 800-38B, May 2005. | ||||
| [SP38C] ---, "Recommendation for Block Cipher Modes of Operation: | ||||
| The CCM Mode for Authentication and Confidentiality", --- | ||||
| 800-38C, May 2004. | ||||
| [SP41] Wack, J. et al (NIST), "Guidelines on Firewalls and Firewall | ||||
| Policy", --- 800-41, January 2002. | Policy", --- 800-41, January 2002. | |||
| [SP42] ---, "Guideline on Network Security Testing", --- 800-42, | [SP42] ---, "Guideline on Network Security Testing", --- 800-42, | |||
| October 2003. | October 2003. | |||
| [SP56] NIST, "Recommendations on Key Establishment Schemes", Draft | [SP56] NIST, "Recommendations on Key Establishment Schemes", Draft | |||
| 2.0, --- 800-63, January 2003. | 2.0, --- 800-63, January 2003. | |||
| [SP57] ---, "Recommendation for Key Management", Part 1 "General | [SP57] ---, "Recommendation for Key Management", Part 1 "General | |||
| Guideline" and Part 2 "Best Practices for Key Management | Guideline" and Part 2 "Best Practices for Key Management | |||
| skipping to change at page 325, line 45 ¶ | skipping to change at page 333, line 45 ¶ | |||
| except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
| This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE IS SPONSORED | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE IS SPONSORED | |||
| BY, THE INTERNET SOCIETY, AND THE INTERNET ENGINEERING TASK FORCE | BY, THE INTERNET SOCIETY, AND THE INTERNET ENGINEERING TASK FORCE | |||
| DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT | DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT | |||
| LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL | LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL | |||
| NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY | NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY | |||
| OR FITNESS FOR A PARTICULAR PURPOSE. | OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| Expiration Date: 20 September 2006. | Expiration Date: 22 February 2007. | |||
| End of changes. 288 change blocks. | ||||
| 678 lines changed or deleted | 1055 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||