|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/ap.belleisle/INFOSEC/stds/ |
Upload File : |
<!doctype html public "-//IETF//DTD HTML//EN"> <HTML> <HEAD> <META NAME="GENERATOR" CONTENT="Internet Assistant for Word 1.0Z"> <TITLE>Key Management Using ANSI X9.17 </TITLE> </HEAD> <BODY> <H1>Key Management Using ANSI X9.17 </H1> <P> U.S. DEPARTMENT OF COMMERCE <P> , Barbara Hackman Franklin, Secretary <P> NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY <P> John W. Lyons, Director <H2>Foreword</H2> <P> The Federal Information Processing Standards Publication Series of the National Institute of Standards and Technology (NIST) is the official series of publications relating to standards and guidelines adopted and promulgated 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. These mandates have given the Secretary of Commerce and NIST the responsibilities for improving the utilization and management of computer and related telecommunications systems in the Federal Government. The NIST, through its Computer Systems Laboratory, provides leadership, technical guidance, and coordination of Government efforts in the development of standards and guidelines in these areas. <P> Comments concerning Federal Information Processing Standards Publications are welcomed and should be addressed to the Director, Computer Systems Laboratory, National Institute of Standards and Technology, Gaithersburg, MD 20899. <P> James H. Burrows, Director Computer Systems Laboratory <H2>Abstract</H2> <P> This standard specifies a particular selection of options for the automated distribution of keying material by the Federal Government when using the protocols of ANSI X9.17. ANSI X9.17 defines procedures for the manual and automated management of keying materials and contains a number of options. Systems which are built to conform to all options of ANSI X9.17 are likely to be complex and expensive. The selected options specified in this standard will allow the development of cost effective systems which will, in addition, increase the likelihood of interoperability. <P> Key words: ADP security, computer security, cryptography, Federal Information Processing Standard (FIPS), key management. Federal Information Processing Standards Publication 171, 1992 April 27, Announcing the Standard for KEY MANAGEMENT USING ANSI X9.17, Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to 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. 1. Name of Standard. Key Management Using ANSI X9.17 (FIPS PUB 171). 2. Category of Standard. Computer Security Standard; Cryptography. 3. Explanation. ANSI X9.17-1985, Financial Institution Key Management (Wholesale), is a voluntary industry standard that defines procedures for the manual and automated management of the data (e.g., keys and initialization vectors) necessary to establish and maintain cryptographic keying relationships. This data is known as keying material. ANSI X9.17 specifies the minimum requirements for: <UL> <LI>· Control of the keying material during its lifetime to prevent unauthorized disclosure, modification or substitution; <LI>· Distribution of the keying material in order to permit interoperability between cryptographic equipment or facilities; <LI>· Ensuring the integrity of keying material during all phases of its life, including its generation, distribution, storage, entry, use and destruction; and <LI>· Recovery in the event of a failure of the key management process or when the integrity of the keying material is questioned. ANSI X9.17 utilizes the Data Encryption Standard (DES) to provide key management solutions for a variety of operational environments. As such, ANSI X9.17 contains a number of options. Systems which are built to conform to all options of ANSI X9.17 are likely to be complex and expensive. This document adopts ANSI X9.17-1985 and specifies a particular selection of options for the automated distribution of keying material by the Federal Government using the protocols of ANSI X9.17. Interoperability between systems built to conform to this selection of options will be more likely, and the cost of building and testing such systems will be reduced. However, less restrictive implementations may be used as long as the necessary restrictions can be effected when used for Federal Government applications. 4. Approving Authority. Secretary of Commerce. 5. Maintenance Agency. U.S. Department of Commerce, National Institute of Standards and Technology (NIST), Computer Systems Laboratory. 6. Cross Index. a. FIPS PUB 1-2, Code for Information Interchange, Its Representations, Subsets, and Extensions. b. FIPS PUB 46-1, Data Encryption Standard. c. FIPS PUB 81, DES Modes of Operation. d. FIPS PUB 113, Computer Data Authentication. e. FIPS PUB 161, Electronic Data Interchange (EDI). f. ANSI X9.17-1985, Financial Institution Key Management (Wholesale). g. ANSI X9.9, Financial Institution Message Authentication (Wholesale). h. Federal Information Resources Management Regulations subpart 201-20.303, Standards, and subpart 201-39.1002, Federal Standards. </UL> <P> <P> Other FIPS and Federal Standards may be applicable to the implementation and use of this standard. A list of currently approved FIPS may be obtained from the National Institute of Standards and Technology, Computer Systems Laboratory, Gaithersburg, MD 20899. <P> 7. Objectives. The objective of this standard is to provide an interoperable key management system when the protocols of ANSI X9.17 are used, and the same option set is selected. The options selected in this standard were chosen with regard to the degree of cryptographic protection that can be provided for the data with which the keys will be used, as well as a decision to reduce the complexity and cost of ANSI X9.17 implementations by limiting the number of options which are implemented and tested. 8. Applicability. This standard shall be used by Federal departments and agencies when designing, acquiring, implementing and managing keying material using the manual and automated procedures of ANSI X9.17. In the future, other key management methods may be approved by NIST for Federal Government use (e.g., public key based key management methods). In addition, this standard may be adopted and used by non-Federal Government organizations. Such use is encouraged when it is either cost effective or provides interoperability for commercial and private organizations. 9. Applications. This standard, along with ANSI X9.17, provides a key management system for: <UL> <LI>· a Point-to-Point environment in which each party to a key exchange shares a key encrypting key which is used to distribute other keys between the parties, <LI>· a Key Distribution Center environment in which each party shares a key encrypting key with a center who generates keys for distribution and use between pairs of parties, and <LI>· a Key Translation Center environment in which each party shares a key encrypting key with a center who translates keys generated by one party which will be distributed to another party, the ultimate recipient. </UL> <P> <P> 10. Implementations. This standard covers key management implementations which may be in software, hardware, firmware or a combination thereof. Key management implementations that are validated by NIST will be considered as complying with this standard. Information about the key management validation program can be obtained from the National Institute of Standards and Technology, Computer Systems Laboratory, Gaithersburg, MD 20899. 11. Specifications. The specifications for Federal Information Processing Standard (FIPS) 171, Key Management Using ANSI X9.17, (affixed) are contained in ANSI X9.17-1985, Financial Institution Key Management (Wholesale), as modified by the technical specification section of this document. 12. Implementation Schedule. This standard becomes effective October 30, 1992. 13. Export Control. Certain cryptographic devices and technical data regarding them are deemed to be defense articles (i.e., inherently military in character) and are subject to Federal Government export controls as specified in Title 22, Code of Federal Regulations, Parts 120-128. Some exports of cryptographic modules conforming to this standard and technical data regarding them must comply with these Federal regulations and be licensed by the Office of Defense Trade Controls of the U.S. Department of State. Other exports of cryptographic modules conforming to this standard and technical data regarding them fall under the licensing authority of the Bureau of Export Administration of the U.S. Department of Commerce. The Department of Commerce is responsible for licensing cryptographic devices used for authentication, access control, proprietary software, automatic teller machines (ATMs), and certain devices used in other equipment and software. For advice concerning which agency has licensing authority for a particular cryptographic device, please contact the respective agencies. 14. Patents. Cryptographic devices used to implement this standard and ANSI X9.17 may be covered by U.S. and foreign patents. <MENU> <LI>15. Waiver Procedure. Under certain exceptional circumstances, the heads of Federal departments and agencies may approve waivers to Federal Information Processing Standards (FIPS). The head of such agency may redelegate such authority only to a senior official designated pursuant to Section 3506(b) of Title 44, U.S. Code. Waivers shall be granted only when: a. compliance with a standard would adversely affect the accomplishment of the mission of an operator of a Federal computer system, or </MENU> <P> <P> b. cause a major adverse financial impact on the operator which is not offset by Governmentwide savings. <P> Agency heads may act upon a written waiver request containing the information detailed above. Agency heads may also act without a written waiver request when they determine that conditions for meeting the standard cannot be met. Agency heads may approve waivers only by a written decision which explains the basis on which the agency head made the required finding(s). A copy of each such decision, with procurement sensitive or classified portions clearly identified, shall be sent to: National Institute of Standards and Technology; ATTN: FIPS Waiver Decisions, Technology Building, Room B-154; Gaithersburg, MD 20899. <P> In addition, notice of each waiver granted and each delegation of authority to approve waivers shall be sent promptly to the Committee of Government Operations of the House of Representatives and the Committee on Governmental Affairs of the Senate and shall be published promptly in the Federal Register. <P> When the determination on a waiver applies to the procurement of equipment and/or services, a notice of the waiver determination must be published in the Commerce Business Daily as a part of the notice of solicitation for offers of an acquisition or, if the waiver determination is made after that notice is published, by amendment to such notice. <P> A copy of the waiver, any supporting documents, the document approving the waiver and any supporting and accompanying documents, with such deletions as the agency is authorized and decides to make under 5 U.S.C. Section 552(b), shall be part of the procurement documentation and retained by the agency. <MENU> <LI>16. Where to Obtain Copies. Copies of this publication are for sale by the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. (Sale of the included specifications document is by arrangement with the American Bankers Association.) When ordering, refer to Federal Information Processing Standards Publication 171 (FIPSPUB171), and title. Payment may be made by check, money order, credit card or NTIS deposit account. </MENU> <P> <P> Federal Information Processing Standard Publication 171 <P> 1992 April 27 <P> Specifications for <H2>KEY MANAGEMENT USING ANSI X9.17 </H2> <H3>INTRODUCTION</H3> <P> ANSI X9.17-1985, Financial Institution Key Management (Wholesale), is a voluntary standard that utilizes the Data Encryption Standard (DES) to provide key management solutions for a variety of operational environments. As such, ANSI X9.17 contains a number of options. Systems which are built to conform to all options of ANSI X9.17 are likely to be complex and expensive. This document adopts ANSI X9.17 and specifies a particular selection of options for the automated distribution of keying material by the Federal Government using the protocols of ANSI X9.17. Interoperability between systems built to conform to this selection of options will be more likely, and the cost of building and testing such systems will be reduced. It is assumed that the reader of this standard is familiar with ANSI X9.17. <H4>OPTIONS SELECTED FOR FEDERAL GOVERNMENT USE</H4> <P> This standard discusses 27 of the options which are provided in ANSI X9.17. In this section, each option is numbered and listed, its use in ANSI X9.17 is described, the selection for Federal Government use is specified along with any other additional requirements, and a brief justification for the selection is provided. Underlined bold face type and the use of the word "shall" are used to indicate mandatory requirements. The use of the word "should" is used to indicate recommendations. <H5>1 ROLE ASSUMED BY A PARTY TO A KEY EXCHANGE</H5> <H6>USE IN ANSI X9.17:</H6> <P> Party A is responsible for sending keys to the other party. Party B is the receiver of those keys. A party to a key exchange may assume the role of either Party A or Party B. Implementations may be designed to (1) always assume the role of Party A, (2) always assume the role of Party B, or (3) assume either role. Implementations which assume the role of Party A in the PTP or CKT environments must be able to generate or otherwise acquire keys (and optionally an IV) and send the keys (and IV) in a KSM. Implementations which assume the role of Party A in the CKD environment requests keys (and an IV) from a CKD (see Option 23). Implementations which assume the role of Party A in the CKT or CKD environments must be able to communicate directly with a CKD or CKT. Implementations which assume the role of Party B in any of the environments must be able to receive keys (and an IV) in a KSM. <H6> SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The role(s) which may be assumed by an equipment is optional. The information management needs of an organization or agency will in large measure determine the roles to be assumed by the equipment. Implementations which offer both roles offers greater flexibility, but is more costly. Implementations which offer a single role is restricted to that role, and can only communicate with parties which can assume the opposite role. <H5>2 RSI FROM PARTY B TO PARTY A</H5> <H6>USE IN ANSI X9.17:</H6> <P> In the event that a party does not have the capability to generate or otherwise acquire keys (and an IV) or it is deemed advisable not to do so, an RSI permits that party (assuming the role of Party B) to request that another party (assuming the role of Party A) generate or otherwise acquire the keys (and IV) and send them in a KSM. Note that a Party A may also send keys (and an IV) to a Party B without receiving an RSI from Party B. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The implementation and use of RSIs from Party B to Party A is optional. There may be applications where Party B will be required to let Party A know that keys (and an IV) are needed. There may be other applications where Party B may not need to request keys, and RSI's will not be used. <H5>3 SVR SUBFIELD ORDERING</H5> <H6>Use in ANSI X9.17:</H6> <P> When an RSI is sent, it contains an SVR field. One KD is implicitly requested. A second KD, an IV, and/or a (*)KK may be requested by including subfields in the SVR field (except in the CKD environment. The ordering of these subfields is unspecified, although an ordering is shown in the examples of key field formats. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> When the subfields of the SVR field are used, it is mandatory that the ordering of subfields be as follows: <P> *KK (requests key encrypting key pair) <P> KD (requests second data key) <P> IV (requests Initialization Vector) For example, SVR/*KK.KD.IV requests a *KK, two KDs and an IV. The selection of a fixed ordering simplifies implementation and improves interoperability. <H5>4 EDC FIELD IN THE RSI AND ESM</H5> <H6>USE IN ANSI X9.17:</H6> <P> The error detection code (EDC) is a Message Authentication Code (MAC) computed on a message using a fixed, publicly known key. An EDC field is an optional field in RSI and ESM messages. The EDC field may be appended to these messages to aid in the detection of errors missed by network error handling protocols. Upon receiving an RSI or ESM with an EDC field, a recipient who does not implement the EDC option may choose to either respond with an ESM containing an "O" (option not implemented) in the ERF field, or may simply ignore the EDC field. <P> SELECTION FOR FEDERAL GOVERNMENT USE <P> The implementation and use of EDC fields in RSIs and ESMs is mandatory. EDCs provide a simple automated means of detecting errors missed by network error-handling protocols. An EDC is easy to compute using an existing feature of the cryptographic system (i.e., the MAC computation). Since the use of EDCs is mandatory, the recipient of an RSI or ESM with an EDC field must process the field. The sending of an ESM in response to an ESM with an EDC error is forbidden. <H5>5 GENERATE OR OTHERWISE ACQUIRE KEYS AND AN IV </H5> <H6>USE IN ANSI X9.17:</H6> <P> During a key exchange, new keys and IVs may be either generated or otherwise acquired by Party A in the PTP and CKT environments. In the CKD environment, Party A may request keys and IVs from the CKD, who either generates or otherwise acquires them. Alternatively, the CKD may send unsolicited keys and IVs to Party A which have been generated or otherwise acquired. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The choice of whether to generate or otherwise acquire keys and IVs is optional. The generation of keys is the most sensitive of all COMSEC functions. Any inadequacies in the implementation of the key generation function or in the physical security safeguards of that function will seriously undermine the security of the cryptographic mechanisms. It is imperative that the physical security measures implemented to protect the key management facility be designed to restrict access to both the key generation system and the keys generated therein. These measures are necessary to prevent unauthorized disclosure, insertion and deletion of the system or keys produced by the system. The provisions of ANSI X9.17-1985 paragraphs 3.2, 3.4.2 and 5.2 should be fully considered in the design and operation of the key management facility. There may be some applications where the generation of keys may be desirable, and other applications where the distribution of keys from another source (e.g., a central authority) may be desirable, depending on the desired management structure. <H5>6 KEY GENERATION TECHNIQUE</H5> <H6>USE IN ANSI X9.17:</H6> <P> Cryptographic keys may or may not be generated by each party. ANSI X9.17 does not specify the method to be used for key generation, but does supply a key generation technique in Appendix C which may be used. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> Only NIST approved key generation algorithms (e.g., the technique defined in Appendix C of ANSI X9.17) shall be used. The generation of keys is the most sensitive of all cryptographic functions. Any inadequacies in the implementation of the key generation function or in the physical security safeguards of that function will seriously undermine the integrity of other cryptographic mechanisms. <H5>7 KEY NAMING </H5> <H6>USE IN ANSI X9.17:</H6> <P> When one or more keys are shared between two parties, the standard provides a means for naming the keys. The IDK1 subfield of a key field may be used to name that key. The IDK2 subfield of a key field may be used to name the key encrypting key used to encrypt the key transmitted in that field. The IDD and IDA fields of a DSM, and the IDD field of an RSM to a DSM identify keys to be discontinued. If one and only one key of a particular type ((*)KK or KD) is shared between two parties, then that key does not have to be named. If the key is not named, then the IDK1 and IDK2 subfields are NULL, and the IDA field is omitted. <P> Keys of different types (i.e., a *KK and a KD) may have the same name. <P> Two data keys with the same name may be sent in the same message. The first data key is to be used for authentication, and the second is to be used for encryption. <H6> SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> It is mandatory that: o All keys are named, even if one and only one key of that type is shared. <UL> <LI>· All keys of a particular type (i.e., *KK or KD) which are shared at any given time between two parties must be uniquely named. o Key names (i.e., in IDK1, IDK2, IDD, and IDA fields) must be used in CSMs whenever keys are sent or referenced, even if one and only one key of that type is shared. o If an unnamed key is received in a CSM and it is permissible to respond to the CSM with an ESM, then an ESM must be returned with a "C" (cannot process) in the ERF field (see Option 18). The use of key names, even when one and only one key of a particular type is shared, simplifies implementations and operations. The use of key names is a means of eliminating ambiguities during use and storage of a key, and aids in the message reconstruction at a later time. It is also mandatory that: o Two KD's within a single KSM must not have the same name. <LI>· A manually transmitted key must be identified by placing the name for that key on the material itself and on the package (e.g., envelope) used to provide confidentiality protection for the keys. The outer security wrapping should not contain this identification. It is highly recommended that all keys, regardless of type, which are shared between a communicating pair be uniquely named. This implies that a key cannot be replaced by a key of the same name (and type), but must always be deleted by a DSM. However, it allows all keys, even discontinued and archived keys, to be easily identified by their name alone. It is also recommended that a structured and consistent naming convention be used within a network, department, or agency. Such a convention may be of great long term benefit in key management, audit, and in the conduct of investigations. </UL> <P> <H5>8 KEY AND FACILITY IDENTIFIER CHARACTER SETS </H5> <H6>USE IN ANSI X9.17:</H6> <P> Each facility identifier (e.g., the contents of the ORG, RCV, IDU, and IDC fields) consists of 4 to 16 characters (inclusive). Key identifiers (e.g., contained in the IDK1 and IDK2 subfields and the IDD and IDA fields) consist of up to 16 characters. The character set for these identifiers has not been precisely defined, however. Several characters have been defined in the standard as delimiters or otherwise reserved for special use. These are: period (.), blank (), solidus (/), open and close parentheses ("(" and ")"), carriage return (CR) and line feed (LF). Additionally, the asterisk (*) is used to designate key encrypting key pairs in the ANSI X9.17 standard, and it is used to indicate a failed MAC in the ANSI X9.9 standard. While the ANSI X9.17 standard restricts the use of the period and blank within fields and subfields, and hence, in key and facility identifiers, there is doubt as to whether the remaining characters should be allowed in these identifiers. <H6> SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> Three characters in addition to the period and blank are forbidden in facility and key identifier fields and subfields because they may cause confusion. These characters are the asterisk, carriage return, and line feed. The other characters used for special purposes (i.e., the solidus and the open and close parentheses) may be used since they do not cause any confusion. The implementation and use of a standardized and unambiguous character set will allow greater interoperability. <H5>9 KEY ENCRYPTING KEY LENGTH </H5> <H6>USE IN ANSI X9.17:</H6> <P> The standard permits manual key encrypting keys shared between two parties to be either single key encrypting keys (KKs) or key encrypting key pairs (*KKs). Manual keys shared between a party and a center must be *KKs. In the PTP and CKT environments, the standard permits two parties to exchange either KKs or *KKs. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The use of *KKs is mandatory for manual key encrypting keys shared between two parties in the PTP environment, and for new key encrypting keys exchanged between two parties in the PTP and CKT environments. The use of KKs is forbidden. The use of *KKs may: <UL> <LI>· allow for longer cryptoperiods, <LI>· provide more security, <LI>· substantially reduce the requirements for operators to enter new manual key encrypting keys, <LI>· reduce the number of errors which occur during the manual entry of keys because of the less frequent need to enter *KKs, and <LI>· result in lowered overall communications costs. </UL> <P> <H5>10 NOTARIZATION OF KEYS </H5> <H6>USE IN ANSI X9.17:</H6> <P> In the CKT and CKD environments, the notarization of keys is required in RTRs generated by the centers. Notarization is also used in the subsequent KSMs. However, in the PTP environment, the notarization of keys is optional in KSMs generated by Party A. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The implementation and use of notarization in the PTP environment is mandatory. Notarization improves security and can provide a digital signature capability when properly implemented in physically secure modules. <H5>11 SENDING KEY ENCRYPTING KEYS IN A KSM IN THE PTP ENVIRONMENT </H5> <H6>USE IN ANSI X9.17:</H6> <P> In the PTP environment, Key Service Messages (KSMs) may carry an automatically distributed key encrypting key ((*)KK) in addition to one or two KDs and possibly an IV. The (*)KKs may be used to encrypt KDs in subsequent messages which do not contain (*)KKs. Alternatively, systems may be designed which never carry (*)KKs in KSMs, but only carry one or two KDs and,optionally, an IV. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The sending of a *KK in KSMs in the PTP environment is optional. The sending of a *KK in a KSM and its subsequent use in sending KDs in other messages may reduce the use and exposure of the manually distributed *KKs. The operational needs of an organization will in large measure determine whether or not the option is used. Implementations which use the option will provide greater flexibility. <H5>12 SEND EITHER ONE OR TWO DATA KEYS </H5> <H6>USE IN ANSI X9.17:</H6> <P> Either one or two data keys (KDs) may be contained in KSM, RFS or RTR messages. At least one KD is always present. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The sending of two KDs in a KSM (all environments) or an RTR (CKD environment) is optional. Without the option of sending two data keys (which is a major feature of the standard), equipment will lack the ability to distribute data keys for both authentication and encryption within a single key exchange. The sending of two KDs in an RFS or RTR (CKT environment) is disallowed in accordance with Option 26. <H5>13 SEND ODD PARITY ON KEYS </H5> <H6>USE IN ANSI X9.17:</H6> <P> The standard requires that all manually transmitted and entered plaintext keys have odd parity. The plaintext form of automatically transmitted keys may optionally have odd parity. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The use of odd parity on the plaintext form of all keys, whether manually entered or automatically transmitted, is mandatory in order to provide interoperability. <H5>14 SEND INITIALIZATION VECTORS WITH KEYS </H5> <H6>USE IN ANSI X9.17:</H6> <P> When Party A sends keys in a KSM, an Initialization Vector (IV) may also be sent. In a CKD environment, an IV may be sent in an RTR message. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The sending of an IV is optional. If an IV is needed for encryption and is not reliably transmitted by other means, the presence of an IV is necessary. The inclusion of an IV in a CSM provides a reliable means of exchanging IVs. <H5>15 ENCRYPTION OF INITIALIZATION VECTORS</H5> <H6>USE IN ANSI X9.17:</H6> <P> When an IV is sent in a KSM, the encryption of the IV is optional. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> It is mandatory that IVs be encrypted. FIPS 140 requires encrypted IVs for the CBC mode. The encryption of all IVs simplifies implementation and processing, and improves security when IVs are transmitted over unprotected channels. <H5>16 SEND EFFECTIVE DATE OF KEY (EDK) WITH KEYS </H5> <H6>USE IN ANSI X9.17:</H6> <P> When Party A sends keys in a KSM or the CKD sends keys to Party A in an RTR, the Effective Date of Key (EDK) field may be used to indicate the date and time of key activation (i.e., the start of the cryptoperiod). <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The use of the EDK field is optional. The use of the EDK field will permit the exchange of keys prior to their activation. This option may be desired for some applications. <H5>17 USE OF DISCONNECT SERVICE MESSAGES</H5> <H6>USE IN ANSI X9.17:</H6> <P> DSMs may be used to disconnect (i.e., delete) one or more keys, and may be used to terminate a keying relationship. The DSMs may be used to protect a party in the event of the compromise of a key or keying material, to terminate a business relationship or simply to reduce the number of keys that must be stored. When a DSM is sent to request the deletion of keys, the RSM returned to the party which sent the DSM provides an authenticated response which acknowledges the receipt of the instruction to delete the key(s); if errors are detected in the reception of the DSM, an ESM is returned. If the DSM is implemented, the RSM and ESM are required by the standard. SELECTION FOR FEDERAL GOVERNMENT USE: <P> The implementation of the ability to both send and receive DSMs is mandatory. It is desirable to have a convenient and reliable automated means to discontinue keys that are no longer needed or may be suspected of compromise. The use of the DSM capability is optional for the sender, i.e., other means may be used to discontinue keys. <H5>18 USE OF THE IDA FIELD IN A DSM IF ONLY ONE DATA KEY IS SHARED </H5> <H6>USE IN ANSI X9.17:</H6> <P> If one and only one KD is shared between two parties, then the identity (name) of the key for authenticating a Disconnect Service Message (DSM) may or may not be specified in an IDA field of the DSM. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The use of the IDA field in a DSM is mandatory, even if one and only one KD is shared between the two parties. This provides a consistent and interoperable method for generating DSMs. <H5>19 USE "C" AS A GENERAL ERROR CODE IN ESM AND ERS MESSAGES </H5> <H6>USE IN ANSI X9.17:</H6> <P> A "C" in the ERF field of ESM and ERS messages is a general error code which may be used when a more specific error code is not appropriate. The "C" indicates an inability to process the previous message. Another ERF code which may be used is the "F" (format error). <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The use of "C" as a general error code in the ERF field of an ESM and ERS is mandatory when other error codes are not readily applicable. <H5>20 ACTION WHEN A COUNT ERROR IS REPORTED </H5> <H6>USE IN ANSI X9.17:</H6> <P> When a CSM (i.e., KSM, RFS, RTR) is received with a count (i.e., CTA, CTB, CTP) less than the recipient's expected (stored) count, the message is rejected and an ESM is returned to the originator of the CSM. In the event of a count error in a KSM in a center environment, Party B returns an ESM to Party A, and Party A sends an ERS to the center. The ESM or ERS includes an indication of a count error, the count received in the related CSM, and the recipient's expected (stored) count. Upon receipt of the ESM or ERS indicating a count error, the counters may be resynchronized by either: (1) automatically adjusting the origination count up to the expected count received in the ESM or ERS, or (2) replacing (possibly manually) the (*)KK associated with the count in error, thereby also re-initializing the counters. <H6> SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> It is mandatory that automatic adjustment of the counters be attempted at least once upon receipt of an ESM or ERS reporting a count error in a previously received CSM. In the event that this first attempt to automatically adjust the counters does not correct the error, then subsequent attempts to correct the error may either be (1) to adjust the counters automatically, or (2) to replace the associated *KK. If the associated *KK is replaced, and an organization has a security officer or an individual designated as crypto custodian, that individual should be notified immediately. All attempts to resynchronize counters manually should be logged. The organization responsible for the auditing should be notified of such attempts. Automatic resynchronization of counters may eliminate the need for human intervention (e.g., manual distribution and entry of new *KKs) and the errors induced by this process. <H5>21 USE "CRLF" AS A CSM FIELD DELIMITER </H5> <H6>USE IN ANSI X9.17:</H6> <P> Normally, the field delimiter in CSMs is a blank (). In order to improve the readability of CSMs displayed on a screen or hard copy listing, the field delimiter may be a blank followed by a carriage return and line feed (CRLF). <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The use of a "CRLF" as the field delimiter in CSMs is forbidden. The use of the "CRLF" may adversely affect interoperability. As the standard was originally written, it referenced ANSI X9.9-1982 and defined the MAC such that the "CRLF" would be edited out before CSM authentication. However, when ANSI X9.9-1986 was revised, it required that all characters in the CSM be utilized in the authentication process. Therefore, the use of "CRLF" is not compatible with the use of only a "". <H5>22 LOGGING OF A CSM</H5> <H6>USE IN ANSI X9.17:</H6> <P> This option is referenced in the standard in the table for processing counters. The table indicates that logging is mandatory when counts disagree, whereas logging is optional when the counts agree. There is no indication of what information is to be logged. <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The logging of all CSMs is mandatory. Logging is a prudent accounting and control practice. <H5>23 USE OF CENTERS (CKD AND CKT) </H5> <H6>USE IN ANSI X9.17:</H6> <P> A CKD is used to generate or otherwise acquire keys and IVs when a party cannot or may not be allowed to perform this process. A CKT is used to translate keys for a party with whom the requesting party does not share an appropriate (*)KK (i.e., a manually distributed (*)KK if (*)KKs are to be sent, otherwise a manually or automatically distributed (*)KK). <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The use of centers is optional. In large networks, the use of centers reduces procedural problems and the operational costs of manual entry. Centers are used to reduce the operational and security problems inherent in the manual distribution of large numbers of keys. Their use does not reduce the number of keys that must be sent (by whatever means), but provides an electronic mechanism that substitutes for costly and inefficient manual key distribution (e.g., by a courier service). <H5>24 RSI FROM PARTY A TO A CKD </H5> <H6>USE IN ANSI X9.17:</H6> <P> In the Key Distribution Center (CKD) environment, an RSI allows Party A to request that the CKD generate or otherwise acquire data keys and IVs and send them to Party A in a Response-To-Request (RTR) message. Note that the CKD may send the data keys and IVs to Party A without receiving an RSI from Party A (i.e., send an unsolicited RTR) (see Option 24). <H6>SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The use of RSIs from Party A to the CKD is optional. If Party A must use a CKD to get keys and IVs when Party A determines that they are needed, then the RSI provides an automated method of doing so. <H5>25 UNSOLICITED RESPONSE TO REQUEST (RTR) MESSAGES </H5> <H6>USE IN ANSI X9.17:</H6> <P> In the Key Distribution Center (CKD) environment, a request for keys may be initiated by Party A. Alternatively, in an unsolicited action, the CKD can send keys to Party A for Party A to use in establishing a keying relationship with Party B. The CKD sends one or two KD(s) for Party A, and sends the same keys as KDU(s) for Party A to forward to Party B. An optional IV may be included. The use of the unsolicited RTR provides a centralization of control over key generation and acquisition as well as the timing of key exchanges. <H6> SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The use of unsolicited RTRs is optional. The use of the unsolicited RTR will reduce communications costs by eliminating the use of the RSI from Party A to the CKD and will allow the CKD to control the timing of key exchanges. <H5>26 SEND (*)KK OR KD TO A CKT FOR TRANSLATION </H5> <H6>USE IN ANSI X9.17:</H6> <P> In the CKT environment, Party A may generate or otherwise acquire and send one or two KDs in a RFS to a CKT for translation, notarization, and return as one or two KDUs for forwarding to Party B. Alternatively, Party A may generate or otherwise acquire and send a (*)KK in an RFS to a CKT for translation, notarization, and return as a (*)KKU for forwarding to Party B. In the latter case, a KD is also sent in the RFS message which is used only for message authentication of the RFS and the responding RTR message. <H6> SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> In the CKT environment, it is mandatory that Party A only send *KKs in an RFS message to a CKT for translation and notarization. The translation of one or two KDs may not be requested. This restriction significantly reduces the load on the CKT since the parties to the exchange may then enter a PTP mode to send KDs. <H5>27 USE OF A COUNT WINDOW </H5> <H6>USE IN ANSI X9.17:</H6> <P> In the CKD and CKT environments, it is possible for a recipient to receive CSMs whose counts are out of sequence, yet the MACs in these CSMs indicate that the messages are authentic. A recipient of these CSMs may establish a window which represents a range of reception counter values such that the corresponding CSMs, should they arrive out of sequence, shall be accepted without declaring an error. Appendix F of ANSI X9.17 describes a method of defining and managing such a window. <H6> SELECTION FOR FEDERAL GOVERNMENT USE:</H6> <P> The use of the window technique described in Appendix F of ANSI X9.17 is mandatory in the CKD and CKT environments. It is desirable to have a uniform window technique for Federal Government use. The use of the window technique in Appendix F of ANSI X9.17 in the CKD and CKT environments will permit interoperabilty. Note that when the window size is equal to one, the window technique functions as if no window technique was present. However, the implemented window technique shall allow for a window size greater than one to be used. <P> TABLE I SUMMARY OF OPTIONS AND SELECTIONS: ALL ENVIRONMENTS <P> Option Section(s) Description Federal Impact(s) Number of ANSI of Option Government X9.17 Use <MENU> <LI>1 8.6.2 Role Optional Implementing both <LI> 8.6.3 assumed by roles provides <LI> 8.6.4 a party to flexibility a key exchange <LI>2 8.2 RSIs from Optional Implementation <LI> 8.6.2 Party B to provides Party A flexibility <LI>3 Table II SVR Defined Simplifies subfield order is implementation; ordering mandatory improves interoperability </MENU> <P> <P> 4 7.2.8 EDC in Mandatory Automated means RSIs and of detecting errors ESMs <P> 5 8.6.2 Generate Optional Implementation <P> 5. or other- provides autonomy; wise acquire no generation or keys and IVs acquisition capability <P> 6 5. Key As defined Provides required <P> 5.3 generation in Appendix randomness technique C <P> 7 Table II Key naming Mandatory Eliminates (see Option ambiguities; allows 6) a better journaling capability <P> 8 8.3 Key and Mandated Eliminates <P> 8.4 facility per Option ambiguities; <P> 8.5 identifier 7 improves Table II character interoperability sets <MENU> <LI>13 Table II Send odd Mandatory Improves parity on interoperability keys </MENU> <P> <P> TABLE I (Cont'd). SUMMARY OF OPTIONS AND SELECTIONS: ALL ENVIRONMENTS <P> Option Section(s) Description Federal Impact(s) Number of ANSI of Option Government X9.17 Use <MENU> <LI>14 8.6.2 Send IVs Optional Provides a reliable <LI> 8.6.3 with keys means of <LI> 8.6.4 transmitting an IV <LI>15 7.2.6 Encrypt Mandatory Simplifies IVs implementation since encryption requires encrypted IVs <LI>16 Table II Send EDKs Optional Permits the with keys exchange of keys prior to activation <LI>17 8.2 Use of Mandatory Automated, <LI> 8.6.4 DSMs convenient and reliable means of discontinuing keys <LI>18 Table II Use of the Mandatory Provides IDA field interoperability in a DSM if only one data key is shared <LI>19 Table II Use "C" as Mandatory Eliminates a general confusion error code in an ESM and ERS <LI>20 7.3.3 Action Mandatory Eliminates the need when a for one for human count attempt to intervention error is adjust reported before sending new keys </MENU> <P> <P> TABLE I (Cont'd). SUMMARY OF OPTIONS AND SELECTIONS: ALL ENVIRONMENTS <MENU> <LI>Option Section(s) Description Federal Impact(s) Number of ANSI of Option Government X9.17 Use <LI>21 8.3 Use Forbidden Provides <LI> 8.4 " CRLF" interoperability <LI> 8.5 as a field delimiter <LI>22 Table I Logging of Mandatory Prudent accounting CSMs and control practice <LI>23 8.1 Use of Optional Reduces cost; centers improves security (CKD and CKT) </MENU> <P> <P> TABLE II SUMMARY OF OPTIONS AND SELECTIONS: POINT_TO_POINT ENVIRONMENT <MENU> <LI>Option Section(s) Description Federal Impact(s) Number of ANSI of Option Government X9.17 Use </MENU> <MENU> <LI>9 8.6.2 Key Use of *KK Reduces cost; <LI> 8.6.4 encrypting is mandatory improves security key length <LI>10 Table II Notariza- Mandatory Provides a digital tion of signature keys capability; improves security <LI>11 8.6.2 Sending Optional Operational Table III key flexibility encrypting keys in KSMs <LI>12 4.3 Send Optional Implementation <LI> 8.6.2 either one allows encryption <LI> 8.6.3 or two and authentication <LI> 8.6.4 data keys keys to be sent in the same message </MENU> <P> <P> TABLE III SUMMARY OF OPTIONS AND SELECTIONS: KEY DISTRIBUTION CENTER ENVIRONMENT <MENU> <LI>Option Section(s) Description Federal Impact(s) Number of ANSI of Option Government X9.17 Use <LI>12 4.3 Send Optional Implementation <LI> 8.6.2 either one allows encryption <LI> 8.6.3 or two and authentication <LI> 8.6.4 data keys keys to be sent in the same message <MENU> <LI>24 8.2 RSIs from Optional Automated method of <LI> 8.6.3 Party A to acquiring keys a CKD <LI>25 8.6.3 Unsolicited Optional Reduces RTR messages communication costs; allows centralized control <LI>27 7.3.3 Use of a Window Reduces costs; count technique provides window of Appendix interoperability F of ANSI X9.17 is mandatory </MENU> </MENU> <P> <P> TABLE IV SUMMARY OF OPTIONS AND SELECTIONS: KEY TRANSLATION CENTER ENVIRONMENT <P> Option Section(s) Description Federal Impact(s) Number of ANSI of Option Government X9.17 Use <P> 9 8.6.2 Key Use of *KK Reduces costs; <P> 8.6.4 encrypting is mandatory improves security key length <P> 26 8.6.4 Send KDs Mandatory Reduces costs and or (*)KKs that *KKs load on the CKT to a CKT be sent for translation <H3>27 7.3.3 Use of a Window Reduces costs; count technique provides window of Appendix interoperability F of ANSI X9.17 is mandatory </H3> <H3> APPENDIX A ANSI X9.17 INTERPRETATIONS</H3> <P> Ambiguities and inconsistencies have been noted in ANSI X9.17 during the implementation of the standard. The following items contain interpretations of the standard which have been made. The requirements for Federal Government use appear in underlined bold face type. <H4>A.1 SENDING AN ESM IN RESPONSE TO AN RSM SENT IN RESPONSE TO A DSM. </H4> <P> Problem: The standard explicitly states that "when an RSM [sent in response to a DSM] is received in error, no ESM shall be sent, and manual recovery procedures are required". In addition, the figures which depict message flow with errors do not show an ESM in response to an RSM to a DSM However, the description in the processing of an RSM contradicts this and implies that an ESM to an RSM to a DSM is required. In particular, it states that "If an IDD field is present, this RSM is in response to a DSM ... If the IDD does not match one of the IDD fields sent in the DSM to which this RSM responds, this shall cause processing of the RSM to cease and the generation and transmission to the originating party of an ESM with an "I" in the ERF field. I.e., ERF/I." Interpretation The first statement is considered to be the appropriate action, i.e., an ESM shall not be sent in response to an RSM which responds to a DSM. An error found in the RSM to a DSM should cause processing of the RSM to cease, and manual recovery procedures should be used to resolve the discrepancy. <H4>A.2 THE USE OF NAMED AND UNNAMED KEYS </H4> <P> Problem: The standard specifies that a key may be unnamed if it is the only key of that type shared between two parties or between a party and a center . The standard does not forbid naming a key even if it is the only key of that type shared. The combination of these two facts implies that if one and only one key of a particular type is shared, then that key may or may not be named; and that if more than one key of a particular type is shared, then all such keys must be named. <P> In addition, there are numerous statements in the standard which specify that the key name need not be used in key identifier subfields if it is the only key of that type shared. The following difficulties arise: o What is the appropriate action when several keys of a particular type are shared (and hence named), and a KSM is received containing a single unnamed key of the same type? o How should a party respond when a single key of a particular type is shared, the key is unnamed, and a KSM is received containing a named key of the same type? o If a key of a particular type has a name, but it is the only one shared, should the name be used in the key identity subfields of a KSM or in the IDD or IDA fields of DSMs, and RSMs which respond to DSMs? o When the standard discusses actions which may be taken if the key is the only key of that type shared, does this mean that the key is the only key of that type that may ever be shared (e.g., there is storage for only one key of that type), or does it mean that there is only one key of that type that is currently shared (i.e., more keys may have been shared previously or may be shared in the future)? Interpretation: The parties to a key exchange must have a prior bi-lateral agreement to name keys or not to name them. Once such an agreement is made, a change from naming to not naming (or the converse) cannot be made without changing the underlying agreement concerning the keying relationship. If key(s) are received in violation of this agreement, an ESM should be returned with a "C" (cannot process) in the ERF field. In particular, if two parties share one or more named keys and an unnamed key is received, the recipient shall return an ESM with a "C" in the ERF field. If two parties share one unnamed key and a named key is received, the recipient should return an ESM with a "C" in the ERF field. In addition, when keys are named, the names should always be used. Refer to Option 6. <H3>A.3 DISCONTINUING VERSUS REPLACING KEYS. </H3> <P> Problem: The standard states that "when a (*)KK is discontinued, all keys sent encrypted under that (*)KK shall also be discontinued without being named in the DSM". This may be implemented by maintaining a linkage between the higher level (*)KK and the (*)KKs and KDs encrypted by it. However, when a manually or automatically distributed (*)KK is replaced by a new (*)KK of the same name, it is not clear whether or not all other (*)KK's and KD's distributed (encrypted) by the original (*)KK should be discontinued. <P> Interpretation: When a (*)KK is replaced (as opposed to discontinued) then only that (*)KK shall be affected, and other keys which may have been encrypted by that (*)KK should not be affected. A "linkage" shall be made between the new (*)KK and the keys encrypted by the replaced (*)KK, so that if a compromise of the replaced (*)KK is later discovered, all keys encrypted by the replaced (*)KK can easily be identified and discontinued. <H3>A.4 ARCHIVING OF KEYS</H3> <P> Problem: Section 3.6.3 discusses the archiving of keys, but does not state that archiving MUST be done or suggest when it should be done. However, it is a good business practice to archive a discontinued key if the key may be needed later. Should replaced keys also be archived? <P> Interpretation: Replacing a key by a new key with the same name effectively discontinues the original key, and the key should, therefore, be archived. The archiving of keys in any system is regarded as good accounting practice. The transactions may have to be reconstructed at a later date to verify that the correct action was taken. <H3>A.5 DELAYS BETWEEN THE SENDING OF AN RSM TO A KSM AND THE RECEIPT OF A RESPONSE </H3> <P> Problem: If an RSM is sent in response to a KSM, either an ESM response is expected or no response is expected. The standard does not address the time interval to wait until it is known that the RSM was received successfully. Interpretation: This is outside the scope of ANSI X9.17. However, this problem does not occur if, upon correct receipt of the RSM, the sender of the KSM immediately sends valid data protected using the data keys sent in the KSM. Receipt of that data and its subsequent successful authentication or decryption provides a positive acknowledgement that the RSM was received correctly. <H3>A.6 CONFUSION ABOUT THE UNIQUE IDENTIFICATION OF DATA KEYS </H3> <P> Problem: The standard never explicitly states how keys are to be uniquely identified. At first, it appears that keys can be uniquely identified by their sharing party, key identifier, and key type ((*)KK or KD). However, the standard explicitly states that "Two data keys with the same name may be sent in the same message". Unless otherwise determined by prior agreement, if two KDs are sent in the same message, the first KD shall be used by the ultimate recipient for authentication; the second shall be used for encryption". Therefore, KDs may be identified not only by the sharing party, key identifier, and type (KD), but also by a subtype (authentication or encryption). Interpretation (*)KKs may be uniquely identified by their sharing party, key identifier and their type (i.e., key encrypting key). KDs may be identified by their sharing party, key identity, their type (data key) and their subtype (data key for authentication or data key for encryption). <H3>A.7 KD REPLACEMENT CONFUSION</H3> <P> Problem: When two data keys are sent in the same message, the first is designated as an authentication key; the second as an encryption key. If a KSM is received with two KDs having distinct identifiers, the first KD (say, KDX) is an authentication key, and the second KD (say, KDY) is an encryption key. If another KSM is received using the same two distinct KD identifiers, but the key with identifier KDY is first and the key with identifier KDX is second, it is unclear whether the new KDY (an authentication key) replaces the old KDY (an encryption key), or if this situation is illegal. The same goes for the replacement of the old KDX (an authentication key) by the new KDX (an encryption key). <P> Interpretation: The new KDY (an authentication key) replaces the old KDY (an encryption key), and the new KDX (an encryption key) replaces the old KDX (an authentication key). Section 6.4 states that "all stored keys of the same type (key encrypting keys or data keys) with the same name shall be replaced". <H3>A.8 IMPLICIT DESIGNATION OF THE USE OF A DATA KEY FOR AUTHENTICATION OR ENCRYPTION. </H3> <P> Problem: The standard states that "A data key can be used for either encryption or authentication but not both, except for a Cryptographic Service Message". This is interpreted to mean that this stipulation applies to the entire cryptoperiod of the key, not just for a single message. I.e., once a key is used for authentication of one message, it can never be used as an encryption key, and conversely, once a key is used as an encryption key, it can never be used as an authentication key. <P> The standard does not designate the purpose of a single KD field in a message. However, if an IV accompanies that KD, the KD could be considered to be an encryption key. If the single KD is not accompanied by an IV, the designation as an authentication or encryption key is not known. <P> Interpretation: When one KD is sent in a message, the first use of that KD after it is sent in a CSM shall determine its use for the remainder of the key's cryptoperiod unless a bilateral agreement states otherwise. <H3>A.9 TERMINATION OF A KEYING RELATIONSHIP UPON THE RECEIPT OF A DSM CONTAINING A NULL IDD FIELD</H3> <P> Problem: The standard indicates that an empty IDD field in a DSM means that the entire keying relationship should be terminated. However, the standard never explicitly states what the entire relationship is. <P> Interpretation: The keying relationship consists of all manually and automatically distributed keys and IVs shared with the other party. The keying relationship is terminated (i.e., all keys and IVs are deleted) if the DSM contains either a single NULL IDD field, or several IDD fields, one or more of which are NULL. Resumption of the keying relationship will then require a redistribution of manual keys, or, in the case of a center environment, utilization of the center to re-establish a keying relationship. <P> Note that in generating the RSM to the DSM, the IDD fields must be copied from the DSM to the RSM. This is interpretated to mean that the fields are copied in the order in which they were received in the DSM. <H3>A.10 RECEIPT OF AN RSI WHICH REQUESTS A *KK TO BE SENT WHEN ONLY A MANUALLY DISTRIBUTED KK IS SHARED </H3> <P> Problem: If an RSI is received with a *KK in the SVR field, but only a single manually distributed KK is shared, there is no error identified to return in an ESM. In fact, in Section 10.7 on processing an RSI message, the SVR field is not even checked. <P> Interpretation: The SVR field of an RSI must be checked for appropriate requests, including the presence of a *KK request when only a KK is shared, as well as a request for both a KK and a *KK. An error code of "C" shall be returned in the ERF field of an ESM when an error of this type is detected. <H3>A.11 PROCESSING A MISROUTED CSM</H3> <P> Problem: The standard indicates that if the party identified in the RCV field of a received CSM is not the party processing the CSM, then the message has been misrouted and shall not be processed further. The standard does not discuss the handling of this misrouted CSM. <P> Interpretation: If the originator of the CSM is known, the party processing the CSM may notify the originator by manual means, since no error code is specifically indicated for this type of error, or an ESM may be returned with the general purpose error code "C", or the receiver could ignore the received message and send no response. If the originator of the CSM is not known (e.g., in the context of the cryptographic system data base, the communications network, or another relationship), the CSM should be disregarded. <H3>A.12 USING AN IV ONLY WITH THE KD WITH WHICH IT WAS SENT</H3> <P> Problem: When an IV is sent in a CSM, it is encrypted by the last (or only) KD in the message. No restriction is made concerning its use in the encryption of data messages. Specifically, the standard does not indicate whether or not the IV may be used with KDs other than the one which encrypted it in the CSM. <P> Interpretation: The IV is intended to be used with the KD which encrypted it in the CSM. However, this is outside the scope of ANSI X9.17. <H3>A.13 PRESENCE OF THE IDK2 SUBFIELD IN THE KD FIELD OF A KSM </H3> <P> Problem: When a (*)KK field is present in a KSM, the KD(s) present in that KSM is encrypted by that (*)KK. The IDK2 subfield is not really necessary in the KD field because the key encrypting key is known. However, there is also a statement that "If an IDK2 subfield is not present, the (*)KK used to decrypt the (*)KK [replace with KD] is the only one shared by the message originator and recipient". This is confusing when a manually distributed (*)KK is shared, since if there is a (*)KK in the message, there are at least two (*)KKs to choose from, the (*)KK in the message and the manually distributed one. <P> Interpretation: If a (*)KK is present in the KSM, use that (*)KK to decrypt the KD in the field. If no (*)KK is present in the KSM, but the IDK2 subfield is present in the KD field(s), use the (*)KK named in the IDK2 subfield to decrypt the KD(s). If no (*)KK is present in the message and no (*)KK is named in the IDK2 subfield of the KD field(s), use the only (*)KK shared by the parties identified in the ORG and RCV fields. If more than one (*)KK is shared, send an ESM with a "C" (Cannot process) code in the ERF field. <H3>A.14 PROTECTION OF THE HEADER, MAC FIELD TAG AND THE CLOSING PARENTHESIS IN A CSM</H3> <P> Problem: In the CSMs which are authenticated using a MAC (e.g., KSM, DSM, RSM), the MAC is computed on the message from the "M" in the message class field tag ("MCL") through the space prior to the "M" in the MAC field tag ("MAC"). Since the CSM header ("CSM("), the MAC field tag ("MAC") and the closing parenthesis are outside the authenticated text, these characters could be modified without altering the MAC. <P> Interpretation: This is true. Errors in these areas need to be checked by the program itself or by the communications routines. If the errors are not detected by the communications routines, the message could be disregarded. <H3>A.15 VALUE OF THE CTP FIELD IN AN ESM WHEN THE IDENTITY OF THE (*)KK USED TO PROTECT A KSM IS NOT KNOWN </H3> <P> Problem: In the Point-to-Point environment, an ESM which responds to a KSM requires a CTP field containing the expected count. However, there is at least one situation where it is necessary to send an ESM in response to a KSM when the expected count is not known. This situation occurs when the ESM is being sent because the manual (*)KK identified by the IDK2 subfield of the (*)KK field (or the KD field if the (*)KK field is not present) is not known and hence its associated receive count (the expected count) is not known. <P> Solution: Since the count is not known, the count field returned in the ESM shall be a null field (i.e., CTP/ with nothing after the solidus (slash)). <H3>A.16 IDA FIELD IN A DSM </H3> <P> Problem: The standard does not permit a data encryption key to be used for data authentication and vice versa. However,a data encryption key is sometimes used in the authentication process for CSMs (i.e., ERSs, RFSs, RTRs, KSMs and RSMs). This occurs in two cases: (1) when two KDs are sent in the same message and (2), when only one KD is sent which may be an encryption key. In the first case, the KDs are combined to produce the authentication key, and in the second case, the KD in the message is used. The KD identified in the IDA field of a DSM is used to authenticate the DSM and the RSM which responds to the DSM. The standard does not specify whether the KD identified in the IDA field should be an authentication key or an encryption key. <P> Interpretation: Since encryption keys are used for the authentication of other CSMs, the KD identified in the IDA field may be either an authentication KD or an encryption KD. In fact, if a communicating pair share only an encryption key, there is no authentication key with which to authenticate a DSM. However, when possible, an authentication key rather than an encryption key shall be identified in the IDA field and used to authenticate the DSM. <H3>A.17 MESSAGE AND EVENT LOGGING </H3> <P> Problem: The standard states that logging is mandatory when the received count in CSMs is not equal to the expected count. Logging is optional when the received and expected counts are equal. The implication is that the log contains something about the event, but the standard does not specify what should be included in the log. <P> Solution: The most appropriate information to log would be the CSM itself, the expected count and the time of receipt as a minimum. It would indeed be desirable to log all CSMs, and the Federal Government is in fact required to do so (see Option 22). <H3>A.18 PROCESSING AN EDK FIELD</H3> <P> Problem: The inclusion of an EDK field in a KSM or RTR is optional. However, if an EDK field is present in a CSM, it is not clear whether the receiver who does not generate an EDK field is required to process the message and field anyway (i.e., may ignore the field), or may return an "Option Not Implemented" error code ("O") in an ESM, if appropriate. <P> Interpretation: Since there is no identified method for checking the contents of the EDK field, a party who doesn't send the EDK field may not know how to check a received EDK for acceptability. Ignoring the field would not be in accordance with the originator's request. Therefore it would be preferable that the receiving party return an ESM with a "Cannot Process" or an "Option not implemented" error code in this case. <H3>A.19 TWO AND THREE LAYER ARCHITECTURES</H3> <P> Problem: The standard permits two or three layers of keys in its architecture. However, there are several conflicting statements regarding the use of these two architectures. <UL> <LI>· "The architecture shall consist of either two or three layers of keys." This seems to say that the two architectures shouldn't co-exist in the same implementation. <LI>· "All implementations shall have the capability of functioning in a two layer architecture." This seems to say that an implementation with a three layer architecture should also be able to switch to a two layer "mode". <LI>· "In a three layer architecture,...When no key encrypting key is transmitted, one or two data keys shall be sent and shall be encrypted under an automatically distributed key encrypting key which has been previously exchanged between the communicating pair." This seems to say that you can't use a manually distributed key encrypting key to encrypt a data key when a three layer architecture is implemented, i.e., you can't switch to a two layer architecture. </UL> <P> <P> Interpretation: An implementation may use the manually distributed (*)KKs to encrypt keys to be exchanged irregardless of whether a two or three layer architecture has been implemented. However, if a (*)KK is exchanged, only a manually distributed (*)KK may be used to encrypt that key. <H2>APPENDIX B - ABBREVIATIONS USED IN THIS DOCUMENT</H2> <P> Abbreviation Meaning <P> ANSI American National Standards Institute <P> ATM Automatic Teller Machine <P> CBC Cipher Block Chaining <P> CRLF Space, Carriage Return, Line Feed <P> CKD Key Distribution Center <P> CKT Key Translation Center <P> COMSEC Communications Security <P> CR Carriage Return <P> CRLF Carriage Return and Line Feed <P> CSL Computer Systems Laboratory <P> CSM Cryptographic Service Message <P> CTA Count "A" <P> CTB Count "B" <P> CTP Count "P" <P> DES Data Encryption Standard <P> DSM Disconnect Service Message <P> EDC Error Detection Code <P> EDK Effective Date of Key <P> ERF Error Field <P> ERS Error Recovery Service Message <P> ESM Error Service Message <P> FIPS PUBS Federal Information Processing Standards Publications <P> IDA Identity of Key for Authentication <P> IDC Identity of Key Distribution Center or Key Translation Center <P> IDD Identity of key to be discontinued <P> IDU Identity of Ultimate Recipient <P> IDK1 Key Identifier (subfield) <P> IDK2 Key Encrypting Key Identifier (subfield) <P> IV Initialization Vector <P> KD Data Key <P> KDU Notarized Data Key for the Ultimate Recipient <P> KK Key Encrypting Key <P> *KK Key Encrypting Key Pair <P> (*)KK Key Encrypting Key or Key Encrypting Key Pair <P> *KKU Notarized Key Encrypting Key Pair for the Ultimate Recipient <P> (*)KKU Notarized Key Encrypting Key or Key Encrypting - Key Pair for the Ultimate Recipient <P> KSM Key Service Message <P> LF Line Feed <P> MAC Message Authentication Code <P> NIST National Institute of Standards and Technology <P> ORG Originator identity <P> PTP Point-to-Point (environment) <P> RCV Receiver (Recipient) identity <P> RFS Request for Service Message <P> RSI Request Service Initiation Message <P> RSM Response Service Message <P> RTR Response to Request Message <P> SVR Service Request Message </BODY> </HTML>