Key Management Using ANSI X9.17
`
`U.S. DEPARTMENT OF COMMERCE
`
`, Barbara Hackman Franklin, Secretary
`
`NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY
`
`John W. Lyons, Director
`Foreword
`
`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.
`
`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.
`
`James H. Burrows, Director Computer Systems Laboratory
`Abstract
`
`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.
`
`Key words: ADP security, computer security, cryptography, Federal Information
`Processing Standard (FIPS), key management. Federal Information Processing
`
`0001
`
`GROUPON - EXHIBIT 1011
`
`

`

`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:
`
`· Control of the keying material during its lifetime to prevent unauthorized
`disclosure, modification or substitution;
`· Distribution of the keying material in order to permit interoperability between
`cryptographic equipment or facilities;
`· Ensuring the integrity of keying material during all phases of its life, including
`its generation, distribution, storage, entry, use and destruction; and
`· 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.
`
`0002
`
`

`

`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.
`
`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:
`
`· 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,
`· 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
`· 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.
`
`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
`
`0003
`
`

`

`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.
`
`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
`
`b. cause a major adverse financial impact on the operator which is not offset by
`Governmentwide savings.
`
`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.
`
`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.
`
`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.
`
`A copy of the waiver, any supporting documents, the document approving the
`waiver and any supporting and accompanying documents, with such deletions as
`
`0004
`
`

`

`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.
`
`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.
`
`Federal Information Processing Standard Publication 171
`
`1992 April 27
`
`Specifications for
`KEY MANAGEMENT USING ANSI X9.17
`
`INTRODUCTION
`
`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.
`
`OPTIONS SELECTED FOR FEDERAL GOVERNMENT USE
`
`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.
`
`1 ROLE ASSUMED BY A PARTY TO A KEY EXCHANGE
`
`USE IN ANSI X9.17:
`
`0005
`
`

`

`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`2 RSI FROM PARTY B TO PARTY A
`
`USE IN ANSI X9.17:
`
`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`3 SVR SUBFIELD ORDERING
`
`Use in ANSI X9.17:
`
`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.
`
`0006
`
`

`

`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`When the subfields of the SVR field are used, it is mandatory that the ordering of
`subfields be as follows:
`
`*KK (requests key encrypting key pair)
`
`KD (requests second data key)
`
`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.
`
`4 EDC FIELD IN THE RSI AND ESM
`
`USE IN ANSI X9.17:
`
`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE
`
`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.
`
`5 GENERATE OR OTHERWISE ACQUIRE KEYS AND AN IV
`
`USE IN ANSI X9.17:
`
`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`0007
`
`

`

`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.
`
`6 KEY GENERATION TECHNIQUE
`
`USE IN ANSI X9.17:
`
`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`7 KEY NAMING
`
`USE IN ANSI X9.17:
`
`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.
`
`Keys of different types (i.e., a *KK and a KD) may have the same name.
`
`0008
`
`

`

`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`It is mandatory that: o All keys are named, even if one and only one key of that
`type is shared.
`
`· 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.
`· 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.
`
`8 KEY AND FACILITY IDENTIFIER CHARACTER SETS
`
`USE IN ANSI X9.17:
`
`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
`
`0009
`
`

`

`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`9 KEY ENCRYPTING KEY LENGTH
`
`USE IN ANSI X9.17:
`
`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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:
`
`· allow for longer cryptoperiods,
`· provide more security,
`· substantially reduce the requirements for operators to enter new manual key
`encrypting keys,
`· reduce the number of errors which occur during the manual entry of keys
`because of the less frequent need to enter *KKs, and
`· result in lowered overall communications costs.
`
`10 NOTARIZATION OF KEYS
`
`USE IN ANSI X9.17:
`
`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.
`
`0010
`
`

`

`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`11 SENDING KEY ENCRYPTING KEYS IN A KSM IN THE PTP ENVIRONMENT
`
`USE IN ANSI X9.17:
`
`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`12 SEND EITHER ONE OR TWO DATA KEYS
`
`USE IN ANSI X9.17:
`
`Either one or two data keys (KDs) may be contained in KSM, RFS or RTR
`messages. At least one KD is always present.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`13 SEND ODD PARITY ON KEYS
`
`USE IN ANSI X9.17:
`
`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.
`
`0011
`
`

`

`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`14 SEND INITIALIZATION VECTORS WITH KEYS
`
`USE IN ANSI X9.17:
`
`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`15 ENCRYPTION OF INITIALIZATION VECTORS
`
`USE IN ANSI X9.17:
`
`When an IV is sent in a KSM, the encryption of the IV is optional.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`16 SEND EFFECTIVE DATE OF KEY (EDK) WITH KEYS
`
`USE IN ANSI X9.17:
`
`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).
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`17 USE OF DISCONNECT SERVICE MESSAGES
`
`USE IN ANSI X9.17:
`
`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
`
`0012
`
`

`

`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:
`
`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.
`
`18 USE OF THE IDA FIELD IN A DSM IF ONLY ONE DATA KEY IS SHARED
`
`USE IN ANSI X9.17:
`
`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`19 USE "C" AS A GENERAL ERROR CODE IN ESM AND ERS MESSAGES
`
`USE IN ANSI X9.17:
`
`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).
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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.
`
`20 ACTION WHEN A COUNT ERROR IS REPORTED
`
`USE IN ANSI X9.17:
`
`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
`
`0013
`
`

`

`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.
`
`SELECTION FOR FEDERAL GOVERNMENT USE:
`
`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