Internet Standards

home *** CD-ROM | disk | FTP | other *** search

/ Internet Standards / CD1.mdf / nist / oiw / agreemnt / 12s_9403.txt < prev next >

Wrap

Text File | 1994-05-22 | 121KB | 4,093 lines

Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 12 - OS Security Output from the March 1994 Open Systems Environment Implementors' Workshop (OIW) Acting SIG Chair: Richard Harris, The Boeing Company SIG Editor: Dr. Mohammad Mirhakkak, MITRE PART 12 - SECURITY March 1994 (Stable) Foreword This part of the Stable Implementation Agreements was prepared by the Security Special Interest Group (SECSIG) of the Open Systems Environment Implementors' Workshop (OIW) hosted by the National Institute of Standards and Technology (NIST). See Part 1 - Workshop Policies and Procedures of the "Draft Working Implementation Agreements Document." Text in this part has been approved by the Plenary of the above- mentioned Workshop. This part replaces the previously existing chapter on this subject. There is significant technical change from this text as previously given. Future changes and additions to this version of these Implementor Agreements will be published as change pages. Deleted and replaced text will be shown as strikeout. New and replacement text will be shown as shaded. ii PART 12 - SECURITY March 1994 (Stable) Table of Contents Part 12 - Security . . . . . . . . . . . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Normative References . . . . . . . . . . . . . . . . . . 1 3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 4 Symbols and Abbreviations . . . . . . . . . . . . . . . . 2 5 Architectures . . . . . . . . . . . . . . . . . . . . . . 2 5.1 Introduction . . . . . . . . . . . . . . . . . . . . 3 5.2 Application Environments . . . . . . . . . . . . . . 3 5.2.1 Base Environment . . . . . . . . . . . . . 4 5.2.2 Single Application Association Environment 5 5.2.2.1 Architectural Diagram . . . . . . . . . . . 6 5.2.2.2 Functional Groups . . . . . . . . . . . . . 6 5.2.3 Application Relay Environment . . . . . . . 6 5.2.3.1 Architectural Diagram . . . . . . . . . . . 7 5.2.3.2 Functional Groups . . . . . . . . . . . . . 8 5.2.4 Distributed Applications Environment . . . 8 5.2.4.1 Architectural diagram . . . . . . . . . . . 8 5.2.4.2 Functional Groups . . . . . . . . . . . . . 9 5.3 Security Classes . . . . . . . . . . . . . . . . . . 10 5.3.1 Security Class S0 . . . . . . . . . . . . . 11 5.3.2 Security Class S1 . . . . . . . . . . . . . 11 5.3.3 Security Class S2 . . . . . . . . . . . . . 12 5.4 Guidelines for OIW Application Profile Development . 12 6 Key Management . . . . . . . . . . . . . . . . . . . . . 12 7 Security Algorithms . . . . . . . . . . . . . . . . . . . 12 7.1 Message Digests . . . . . . . . . . . . . . . . . . 13 7.1.1 Square-Mod-N . . . . . . . . . . . . . . . 13 7.1.2 MD2 . . . . . . . . . . . . . . . . . . . . 14 7.1.3 MD4 . . . . . . . . . . . . . . . . . . . . 14 7.1.4 MD5 . . . . . . . . . . . . . . . . . . . . 15 7.1.5 SHA . . . . . . . . . . . . . . . . . . . . 15 7.1.6 MDC-2 . . . . . . . . . . . . . . . . . . . 15 7.2 Reversible Public Key Algorithms . . . . . . . . . . 16 7.2.1 RSA (X.509) . . . . . . . . . . . . . . . . 16 7.2.2 RSA Encryption . . . . . . . . . . . . . . 17 7.2.3 RSA Signature . . . . . . . . . . . . . . . 17 7.3 Irreversible Public Key Algorithms . . . . . . . . . 17 iii PART 12 - SECURITY March 1994 (Stable) 7.3.1 El Gamal . . . . . . . . . . . . . . . . . 18 7.3.2 DSA . . . . . . . . . . . . . . . . . . . . 18 7.3.3 DSA with Common Parameters . . . . . . . . 19 7.4 Key Exchange . . . . . . . . . . . . . . . . . . . 19 7.4.1 Diffie-Hellman . . . . . . . . . . . . . . 19 7.4.2 Diffie-Hellman with Common Parameters . . . 20 7.4.3 RSA Key Transport . . . . . . . . . . . . . 20 7.5 Signature Algorithms . . . . . . . . . . . . . . . . 21 7.5.1 Message Digests with RSA . . . . . . . . . 21 7.5.1.1 Square-Mod-N with RSA . . . . . . . . . . . 21 7.5.1.2 MD2 with RSA . . . . . . . . . . . . . . . 21 7.5.1.3 MD4 with RSA . . . . . . . . . . . . . . . 21 7.5.1.4 MD5 with RSA . . . . . . . . . . . . . . . 22 7.5.2 Message Digests with RSA Encryption . . . . 22 7.5.2.1 MD2 with RSA Encryption . . . . . . . . . . 22 7.5.2.2 MD4 with RSA Encryption . . . . . . . . . . 22 7.5.2.3 MD5 with RSA Encryption . . . . . . . . . . 22 7.5.3 DSA With SHA . . . . . . . . . . . . . . . 23 7.5.4 DSA With SHA with Common Parameters . . . . 23 7.5.5 RSA Signature With MDC-2 . . . . . . . . . 23 7.5.6 RSA Signature With SHA . . . . . . . . . . 23 7.6 Symmetric Encryption Algorithms . . . . . . . . . . 24 7.6.1 Data Encryption Standard . . . . . . . . . 24 7.6.1.1 DES-ECB . . . . . . . . . . . . . . . . . . 24 7.6.1.2 DES-CBC . . . . . . . . . . . . . . . . . . 25 7.6.1.3 DES-OFB . . . . . . . . . . . . . . . . . . 26 7.6.1.4 DES-CFB . . . . . . . . . . . . . . . . . . 26 7.6.1.5 DES-MAC . . . . . . . . . . . . . . . . . . 26 7.6.1.6 DES-EDE . . . . . . . . . . . . . . . . . . 27 7.6.2 RC2-CBC . . . . . . . . . . . . . . . . . . 27 7.6.3 RC-4 . . . . . . . . . . . . . . . . . . . 28 7.7 ASN.1 . . . . . . . . . . . . . . . . . . . . . . . 28 7.7.1 Distinguished Encoding Rules . . . . . . . 28 8 Lower Layers Security . . . . . . . . . . . . . . . . . . 30 9 Upper Layers Security . . . . . . . . . . . . . . . . . . 30 9.1 Security Mechanisms . . . . . . . . . . . . . . . . 30 9.1.1 Peer Entity Authentication . . . . . . . . 30 9.1.1.1 Simple-Strong Authentication . . . . . . . 31 9 . 1 . 1 . 1 . 1 Operation . . . . . . . . . . . . . . . . . 31 9 . 1 . 1 . 1 . 2 Data Structure . . . . . . . . . . . . . . 31 9 . 1 . 1 . 1 . 3 Options . . . . . . . . . . . . . . . . . . 32 9.1.1.2 External Authentication Mechanisms . . . . 33 9 . 1 . 1 . 2 . 1 Kerberos Version 5 . . . . . . . . . . . . 33 9.1.2 Integrity/Data Origin Authentication iv PART 12 - SECURITY March 1994 (Stable) Transformation . . . . . . . . . . . . . . 33 10 Message Handling System (MHS) Security . . . . . . . . . 35 11 Directory Services Security . . . . . . . . . . . . . . . 36 12 Network Management Security . . . . . . . . . . . . . . . 36 12.1 Threats . . . . . . . . . . . . . . . . . . . . . . 36 12.2 Security Services . . . . . . . . . . . . . . . . . 37 12.2.1 Basic Security Services . . . . . . . . . . 37 12.2.2 Enhanced Security Services . . . . . . . . 37 12.3 Security Mechanisms . . . . . . . . . . . . . . . . 38 12.3.1 Peer Entity Authentication . . . . . . . . 38 12.3.2 Connectionless IntegrityProposed text for this clause appears in WIA Part 12, clause 12.3.2. Annex A (normative) ISPICS Requirements List . . . . . . . . . . . . . . . . . . 39 Annex B (normative) Errata . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Annex C (normative) TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Annex D (informative) Security Algorithms and Attributes . . . . . . . . . . . . . 42 Annex E (normative) References for Security Algorithms . . . . . . . . . . . . . 46 Annex F (informative) Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 50 Annex G (informative) ElGamal . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 G.1 Background . . . . . . . . . . . . . . . . . . . . . 43 G.2 Digital Signature . . . . . . . . . . . . . . . . . 44 G.3 Verification . . . . . . . . . . . . . . . . . . . . 45 G.4 Known Constraints on Parameters . . . . . . . . . . 45 v PART 12 - SECURITY March 1994 (Stable) List of Figures Figure 1 - Basic Elements of a Generic OSI Application Environment . . . . . . . . . . . . . . . . . . . . . . 4 Figure 2 - Architectural Diagram for Single Application Association Environment . . . . . . . . . . . . . . . . 6 Figure 3 - Architectural diagram for Application Relay Environment . . . . . . . . . . . . . . . . . . . . . . 7 Figure 4 - Architectural diagram for Distributed Applications Environment . . . . . . . . . . . . . . . . 9 vi PART 12 - SECURITY March 1994 (Stable) List of Tables Table 1 - Security Classes . . . . . . . . . . . . . . . . . 10 Table B.1 - SIA Part 12 changes . . . . . . . . . . . . . . . 40 vii Part 12 - Security Editor's Note - Previous material in this part has been deleted and is no longer applicable. 0 Introduction The relationship between protocols and security is accomplished by developing a security profile that binds these two together. Security profiles define protocol specific implementations of security architectures. A security profile includes the following items: a) A grouping of the security services to be offered; b) The placement of those security services; c) The selection of mechanisms to support the placed security services. This part completes this sequence of steps for several generalized security architectures. A generalized security architecture is chosen and tailored to derive a protocol-specific security profile. This part is comprised of protocol-specific security profiles and other supporting functions. 1 Scope 2 Normative References [ISO7498-2] ISO/IEC 7498-2 Information Processing Systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture, February 1989. [ISO8649] ISO/IEC 8649: 1988/Amd 1:1990 Service Definition for the Association Control Service Element, Amendment 1: Peer-Entity Authentication During Association Establishment. [ISO8650] ISO/IEC 9594-3 Information Technology - Open Systems Interconnection - The Directory - Part 3: Abstract Service Definition. [ISO8650/1] ISO/IEC 8650: 1988/Amd 1:1990 Protocol Specification for the Association Control Service Element, Amendment 1: Peer-Entity Authentication During Association Establishment. [ISO9594-7] ISO/IEC 9594-7 Information Processing Systems - 1 PART 12 - SECURITY March 1994 (Stable) Open Systems Interconnection - The Directory - Part 7: Selected Object Classes, 1990. [ISO9594-8] ISO/IEC 9594-8 Information Processing Systems - Open Systems Interconnection - The Directory - Part 8: Authentication Framework, 1990. [ISO10021-4] ISO/IEC 10021-4 Information Processing Systems - Text Communication - MOTIS - Message Transfer System : Abstract Service Definition and Procedures. [X.509-88] CCITT X.509:1988 The Directory - Authentication Framework. [X.511-88] CCITT X.511:1988 The Directory - Abstract Service Definition. [X.411-84] CCITT X.411:1984 Message Transfer System - Message Transfer Layer. [X.521-88] CCITT X.521:1988 The Directory - Selected Object Classes. 3 Definitions 4 Symbols and Abbreviations 5 Architectures The purpose of this clause is to provide guidance on how to build a security architecture based on an OSI application environment and its threats and vulnerabilities. A Security Architecture specifies the relationship between the set of security services and mechanisms with which protection from threats and vulnerabilities is achieved. It is designed to respond to assessed vulnerabilities, threats, and risks as identified by a security policy. The establishment of security policies is beyond the scope of the OIW. 2 PART 12 - SECURITY March 1994 (Stable) 5.1 Introduction Open Systems Security provides for secure distributed information processing in OSI application environments which are heterogeneous in terms of technology and administration. For example, some environments may require protection from a minimal set of security threats while others require more complete protection. The sequence of steps by which a security architecture is created for a specific application environment is as follows: a) Development of threat analysis; b) Determination of security services; c) Placement of security services; d) Selection of mechanisms; e) Selection of algorithms. These implementation agreements assume that steps a and b have been completed for the specific application. An introduction to the threat analysis process and the determination of security services is included in Annex H. Generic OSI application environments are defined in Clause 5.2. Generic security services as defined by ISO 7498-2 are grouped into classes in Clause 5.3. A generalized security architecture for each environment is developed by mapping the security classes onto the functional groups of each environment and providing guidance as to at which layer to support the service in Clause 5.4. Guidance on how to select mechanisms suitable for each security service is presented in Clause 5.5. It is beyond the scope of these implementation agreements to specify the use of one algorithm over another. Clause 7 presents a set of algorithms suitable for various mechanisms. 5.2 Application Environments It is useful for the sake of simplification to look at the OSI application environments and to separate them into generic OSI application environments so that security profiles can be developed for each. The environments are: Single Application Association, Application Relay, and Distributed Applications. All applications will operate in one or more of these environments. For example, a Message Handling application that 3 PART 12 - SECURITY March 1994 (Stable) uses a Message Transfer Agent (MTA) to relay mail from one User Agent (UA) to another UA would map to the Application Relay Environment. Likewise a Message Handling application which only includes a UA accessing a Message Store (MS) would map to the Single Application Association Environment. For each environment, an architectural diagram is provided that portrays the interconnection of the elements. In addition, a set of functional groups are defined each of which is comprised of an interconnected set of elements. 5.2.1 Base Environment Figure 1 depicts the basic elements of a generic OSI application environment from which all OSI application environments can be derived. In all application environment figures, dashed lines indicate an optional communication path and the double-lined boxes indicate an optional basic element. Ellipses indicate that the previous basic element may be repeated zero or more times. +---------------------------------------------------------------+ | | | +---------------------------------+ | | | | | | +-----+ | +-----+ +------+ | +------+ | | | SU +------+---+ SA + ... | SA +--------+----+ SU | | | +-----+ | +-----+ +------+ | +------+ | | | | | | +-------------SS------------------+ | | | | SU = Service User | | SA = Service Agent | | SS = Service System | | | +---------------------------------------------------------------+ Figure 1 - Basic Elements of a Generic OSI Application Environment The basic elements are as follows: Service User (SU): an entity that functions as a service initiator or responder ; Service Agent (SA): an intermediate entity that actively participates in providing the services between an initiator and a responder; Service System (SS): zero or more cooperating service 4 PART 12 - SECURITY March 1994 (Stable) agents. Basic elements that communicate, either through a direct association or indirectly through intermediaries, are classified as a functional group. Functional groups defined in Figure 1 are: a. f0: SU -> SU (Service User to Service User directly); b. f1: SU => SU (Service User to Service User indirectly); c. f2: SU -> SA (Service User to Service Agent directly); d. f3: SU => SA (Service User to Service Agent indirectly); e. f4: SA -> SA (Service Agent to Service Agent directly); f. f5: SA => SA (Service Agent to Service Agent indirectly); g. f6: SA -> SU (Service Agent to Service User directly); h. f7: SA => SU (Service Agent to Service User indirectly). Editor's Note - the "->" notation indicates association security relationship and "=>" indicates relay security relationship. These definitions and this functional group syntax will be used to define generic OSI application environments. In some applications, these functional groups may have to be combined for the purpose of performing a security analysis. 5.2.2 Single Application Association Environment The Single Application Association Environment covers applications which are designed to operate over Single Application Associations (as defined in ISO 9545) between one pair of application-entity-invocations (AEIs). This environment specifically includes the case of recovery, i.e., different associations may exist at different times between one pair of AEIs. Examples of applications to which this environment applies are as follows: 5 PART 12 - SECURITY March 1994 (Stable) a) FTAM; b) Network Management; c) Virtual Terminal. Applications such as MHS, Directory Services, and TP are only partially covered by this environment because some of their service elements may use store and forward or chaining types of relay functions. The environments that apply to these applications are the Application Relay and Distributed Applications Environments respectively. 5.2.2.1 Architectural Diagram Figure 2 portrays the architectural diagram for the Single Application Association Environment. +-------------------------------------------------------+ | | | +-----+ +-----+ | | | SU +----------------------+ SU | | | +-----+ +-----+ | | SU = Service User | | | +-------------------------------------------------------+ Figure 2 - Architectural Diagram for Single Application Association Environment 5.2.2.2 Functional Groups The following functional group is defined for the Single Application Association Environment: a) f0:SU -> SU. 5.2.3 Application Relay Environment The Application Relay Environment covers applications which are designed to operate with the active participation of at least one service agent in support of transferring a service user request from an initiator to a responder. When more than one service agent is present, they function sequentially. An example of an application to which this environment applies is 6 PART 12 - SECURITY March 1994 (Stable) Message Handling Systems. 5.2.3.1 Architectural Diagram Figure 3 portrays the architectural diagram for the Application Relay Environment. In all application environment figures, dashed lines indicate an optional communication path and the double-lined boxes indicate an optional basic element. Ellipses indicate that the previous basic element may be repeated zero or more times. +---------------------------------------------------------------- ---------+ | +---------------------------------+ | | | | | | +-----+ | +-----+ +-----+ | +-----+ | | | SU +------+---+ SA | ... | SA +------+-----+ SU | | | +-----+ | +-----+ +-----+ | +-----+ | | | | | | +----------- SS -----------------+ | | | | SU = Service User | | SA = Service Agent | | SS = Service System | | | | | +---------------------------------------------------------------- ---------+ Figure 3 - Architectural diagram for Application Relay Environment 7 PART 12 - SECURITY March 1994 (Stable) 5.2.3.2 Functional Groups The following functional groups are defined and added for the Application Relay Environment: a. f2: SU -> SA; b. f3: SU => SA; c. f4: SA -> SA; d. f6: SA -> SU. 5.2.4 Distributed Applications Environment The Distributed Application Environment covers applications which are designed to operate with the active participation of zero or more service agents which may process a service user request. Processing may include modifying, interpreting, or transferring the service user request or its data. When more than one service agent is present, they may function in parallel, sequentially, or both. 5.2.4.1 Architectural diagram Figure 4 portrays the architectural diagram for the Distributed Applications Environment. In all application environment figures, dashed lines indicate an optional communication path and the double-lined boxes indicate an optional basic element. Ellipses indicate that the previous basic element may be repeated zero or more times. 8 PART 12 - SECURITY March 1994 (Stable) +---------------------------------------------------------------- ---------+ | +---------------------------------+ | | | | | | +-----+ | +-----+ | +-----+ | | | SU +------+---+ SA | ... --------|-----| SU | | | +-----+ | +-----+ | +-----+ | | | | | | +----------- SS -----------------+ | | | | SU = Service User | | SA = Service Agent | | SS = Service System | | | | | +---------------------------------------------------------------- ---------+ Figure 4 - Architectural diagram for Distributed Applications Environment 5.2.4.2 Functional Groups The following functional groups are defined and added for the Distributed Applications Environment: a) f0: SU -> {SU; ... }; b) f1: SU => {SU; ... }; c) f2: SU -> {SA; ... }; d) f3: SU => {SA; ... }; 9 PART 12 - SECURITY March 1994 (Stable) e) f4: SA -> {SA; ... }; f) f5: SA => {SA; ... }; g) f6: SA -> {SU; ... }; h) f7: SA => {SU; ... }. 5.3 Security Classes Security classes are defined to provide a framework on which to build security profiles. Each class specifies the required security services. The services specified in each class are the generic security services as defined by ISO 7498-2. For each application's profile, specific security services are chosen for each class. For example, data integrity is a generic security service for which there exists five distinct data integrity services. One or more specific security services must be specified to meet the requirements of a security class in an application specific security profile. The classes are organized into two similar hierarchies as shown in Table 1. Each level of each hierarchy is a superset of the security services required of the immediately preceding level. For each level in the hierarchies, the same set of security services are required, except that one hierarchy includes confidentiality services. Table 1 - Security Classes +------------------------+-------------------+ | SECURITY SERVICES | SECURITY CLASSES | | +---------+---------+ | | |ADD CONF | +------------------------+---------+---------+ | AUTH. & ACCESS CONTROL| S0 | | | | | S0A | +------------------------+---------+---------+ | ADD DATA INTEGRITY | S1 | | | | | S1A | +------------------------+---------+---------+ | ADD NON-REPUDIATION | S2 | | | | | S2A | | | | | +------------------------+---------+---------+ There are two interesting properties of these relationships 10 PART 12 - SECURITY March 1994 (Stable) between the classes. First, each level of the confidentiality hierarchy is a superset of the other hierarchy at the same level and a superset of the confidentiality hierarchy at the immediately preceding level. For example, class S2A is a superset of classes S2 and S1A. Second, for two entities each supporting a distinct security class in a different hierarchy, the best level of service that can be achieved between them is the class in the non- confidentiality hierarchy at the same level as the lowest class of the two entities. For example, if one entity supports class S2 and the other supports class S1A, the best class of service achievable is S1. Editor's Note - This is not a mechanism for negotiated services. That is a future work item. 5.3.1 Security Class S0 The Security Class S0 includes implementation of the following security services: a) S0 = Authentication and Access Control. The Security Class S0A adds the confidentiality service to the Class S0 as follows: b) S0A = S0 + Confidentiality. 5.3.2 Security Class S1 The Security Class S1 adds the Data Integrity Service to class S0 as follows: a) S1 = S0 + Data Integrity. The Security Class S1A adds the Confidentiality Service to Class S1 as follows: b) S1A = S1 + Confidentiality 11 PART 12 - SECURITY March 1994 (Stable) 5.3.3 Security Class S2 The Security Class S2 adds the Non-repudiation Service to Class S1 as follows: a) S2 = S1 + Non-repudiation The Security Class S2A adds the Confidentiality Service to Class S2 as follows: b) S2A = S2 + Confidentiality 5.4 Guidelines for OIW Application Profile Development 6 Key Management [ISO7498-2] defines Key Management (KM) as the "generation, storage, distribution, deletion, archiving, and application of keys in accordance with a security policy." The Security SIG recognizes that security policies are outside the scope of IAs, and it is inappropriate to make general recommendations in the absence of a KM framework. 7 Security Algorithms Editor's Note - Implementors are cautioned that security of an algorithm may change at any time. Therefore, the WIA must be consulted in order to determine if there is more current information. The algorithms included here are listed in no particular order (beyond categorization by type of algorithm). It is beyond the scope of these agreements to recommend the use of one algorithm over another. However, if a vulnerability is known to exist a reference will be provided along with a recommendation not to use the algorithm. This clause references a definitive specification for each algorithm, which includes an object identifier. In general, control of the definitive specification is expected to be outside the scope of the OIW. The benefit of not controlling the specification is that the organization that developed the algorithm is best situated to maintain and have knowledge of the security of the algorithm. Algorithms for which there is no controlling organization are defined in an Annex in this Part. For each algorithm, its typical usage is stated, its definitive 12 PART 12 - SECURITY March 1994 (Stable) reference is given, and its object identifier is included for reference purposes.Optionally, additional information may be included, for example a reference to known vulnerabilities. Implementors should be aware that export of products using cryptography may be subject to export restrictions. In general, use of cryptography not involving confidentiality is subject to Commerce Department regulations, while use of cryptography for confidentiality is controlled by (more stringent) State Department regulations. It is the implementor's responsibility to determine any export restrictions which apply to a given product, as the export controls may change from time to time. Editor's Note - Some of the references are RFCs, Internet Drafts, and PKCS documents. We need to include information on how to access these documents. 7.1 Message Digests These message digest algorithms (or hash algorithms) compute a fixed size representation of an input stream. They have different performance characteristics and employ different computational techniques, making each suitable for different applications. 7.1.1 Square-Mod-N Square-Mod-N is a hash algorithm that is used to compute a fixed size representation of an input stream. It is defined in [X.509] and its object identifier is defined there as: sqmod-n ALGORITHM PARAMETER BlockSize ::= {hashAlgorithm 1} BlockSize ::= INTEGER Recent research regarding the square-mod-n one-way hash function described in Annex D of [X.509] has revealed that the function is not secure. Its use, therefore, is discouraged. Editor's Note - We need the reference that identifies its vulnerabilities so we can recommend it not be used. 13 PART 12 - SECURITY March 1994 (Stable) 7.1.2 MD2 MD2 is a message digest algorithm that employs accepted, traditional computational techniques. Its speed is the slowest of the message digests listed here. It is defined in Internet Draft [a] and its object identifier is defined there as: md2 ALGORITHM PARAMETER NULL ::= {iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 2} Editor's Note - There is a Directory SIG OID for this algorithm. The reference includes a source code implementation of the algorithm written in the C programming language. MD2 is copyrighted and its use may require specific permission or a license. Details are stated in the Internet Draft. 7.1.3 MD4 MD4 is a message digest algorithm that employs non-traditional computational techniques to enhance its speed in software and hardware with native 32-bit arithmetic. Its speed is the fastest of the message digests listed here. It is defined in Internet Draft [b] and its object identifier is there as: md4 ALGORITHM PARAMETER NULL ::= {iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 4} This reference includes a source code implementation of the algorithm written in the C programming language. It is suggested that MD4 be used only with applications for which performance is critical. Editor's Note - We need to include text from the MD4/5 Internet Drafts which describes the differences between the two algorithms and the preference for MD5. 14 PART 12 - SECURITY March 1994 (Stable) 7.1.4 MD5 MD5 is a message digest algorithm which is based on the techniques of MD4, but with additional enhancements to counter proposed attacks. A detailed description of the changes can be found in [c].. MD5 is defined in Internet Draft [c] and its object identifier is defined there as: md5 ALGORITHM PARAMETER NULL ::= {iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5} This reference includes a source code implementation of the algorithm written in the C programming language. 7.1.5 SHA This algorithm is the NIST Secure Hash Algorithm [ab]. It is based on concepts similar to those used in MD4 and MD5, and outputs a 160-bit digest. sha ALGORITHM PARAMETER NULL ::= {algorithm 18} Editor's Note - This and other algorithms may be registered by ISO instead, in which case this text will be adjusted prior to moving to Stable Agreements, or if necessary as Alignment Errata. 7.1.6 MDC-2 This is a DES-based hash function [ac] in which the output of each block encryption is fed back as keying material for the next block. It outputs a 128 bit digest. mdc-2 ALGORITHM PARAMETER NULL ::= { algorithm 19 } 15 PART 12 - SECURITY March 1994 (Stable) 7.2 Reversible Public Key Algorithms These algorithms are asymmetric; separate keys are used for encryption and decryption. They also have the property that applying the encipherment function followed by the decipherment function has the same effect as applying the decipherment function followed by the encipherment function. This is useful if a single algorithm is needed to provide both confidentiality (e.g., transport of symmetric keys) and authentication/integrity (e.g., digital signatures). RSA is a public key (asymmetric) cryptographic algorithm, typically used in conjunction with message digest (or hash) algorithms to create digital signatures and for confidential distribution of symmetric keys. It may also be used to exchange confidential messages. The RSA algorithm is defined in [d] and is also described in Annex C of [X.509]. The RSA technology is patented in the United States [e][f]. According to [X.509], the ASN.1 BIT STRING containing the public key will contain the BER encoding of the modulus and exponent: SEQUENCE { n INTEGER, -- modulus e INTEGER } -- public exponent 7.2.1 RSA (X.509) RSA is defined in [X.509] and its object identifier is defined there as: rsa ALGORITHM PARAMETER KeySize ::= {encryptionAlgorithm 1} KeySize ::= INTEGER The key size specifies the length in bits of the RSA public key modulus. The definition of this algorithm does not include specification of padding rules. If one assumes that the data is treated as an integer and padded with zero bits on the left, the algorithm is subject to various attacks, such as those described in [ah], which render it unsuitable for some applications, e.g., multi- recipient mail, notarization. In such cases RSAEncryption is 16 PART 12 - SECURITY March 1994 (Stable) preferred. 7.2.2 RSA Encryption RSA Encryption is defined in PKCS #1 [g] and its object identifier is defined there as: rsaEncryption ALGORITHM PARAMETER NULL ::= {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1} This algorithm defines various types of block padding depending on whether the block is being encrypted using a public or private key. The padding protects against various attacks documented in the literature. 7.2.3 RSA Signature This algorithm [ad] is compatible with IS 9796 [ae], with the Sign and Verify functions required to be those in Annex A of ISO 9796. rsaSignature ALGORITHM PARAMETER NULL ::= {algorithm 11} This algorithm provides additional redundancy in the construction of the signature block, and ensures that it is not a natural power. (If the signature block is a natural power, one can forge a signature by simply taking the e-th root where e is the public exponent. E.g., if e is 3, one could potentially forge a signature, if the block is a natural cube, by taking the (integer) cube root. However, the chance that an integer near a given x is a cube is quite small if x is large; the probability x-2/3, so if x is about 2505 (as is the case for 512-bit RSA), then the probability is about 2-337.) 7.3 Irreversible Public Key Algorithms These algorithms are not reversible, as defined in section 7.2. Typically, different algorithms are used for encryption and signature. This section defines several signature-only algorithms. Note that these algorithms expand the plaintext, producing output which is significantly larger than the input block or digest. These algorithms are of use in authentication- only systems, and are generally not subject to export 17 PART 12 - SECURITY March 1994 (Stable) restrictions. 7.3.1 El Gamal ElGamal is a public key (asymmetric) digital signature algorithm. It is defined in [k]. Its object identifier is: ElGamal ALGORITHM PARAMETER NULL ::= {encryptionAlgorithm 1} Editor's Note - This OID was assigned by the Directory SIG. In [X.509], the ASN.1 data element subjectPublicKey defined as BIT STRING should be interpreted in the case of ElGamal as being of type: SEQUENCE { prime INTEGER, -- p base INTEGER, -- alpha key INTEGER -- public key, Y } Also, in [X.509], the value associated with the ENCRYPTED MACRO should be interpreted in the case of ElGamal as being of type: SEQUENCE { s INTEGER, r INTEGER } The ElGamal technology is patented in the United States [f]. Editor's Note - Should we describe and define OIDs for the message digest with ElGamal signature algorithms? There is a Directory SIG OID for md2WithElGamal. 7.3.2 DSA The NIST Digital Signature Algorithm [aa] is a variant of ElGamal which produces a shorter signature size. Its object identifier is: dsa ALGORITHM PARAMETER DSAParameters ::= {algorithm 12} The ASN.1 data element subjectPublicKey defined as BIT STRING 18 PART 12 - SECURITY March 1994 (Stable) should be interpreted in the case of DSA as being of type: DSAPublicKey ::= INTEGER DSAParameters ::= SEQUENCE { prime1 INTEGER, -- p prime2 INTEGER, -- q base INTEGER } -- g The DSAPublicKey is simply an INTEGER, which is encapsulated in the subjectPublicKey BIT STRING in the obvious way: The MSB of the INTEGER becomes the MSB of the BIT STRING, and the LSB of the INTEGER becomes the LSB of the BIT STRING. In [X.509], the value associated with the ENCRYPTED MACRO (i.e. the signature value) should be interpreted in the case of DSA as being of type: SEQUENCE { r INTEGER, s INTEGER } 7.3.3 DSA with Common Parameters This version of DSA uses common parameters which are distributed externally. The DSAPublicKey is till an INTEGER as described in the DSA case. The algorithm's object identifier is: dsaCommon ALGORITHM PARAMETER NULL ::= { algorithm 20 } 7.4 Key Exchange 7.4.1 Diffie-Hellman Diffie-Hellman Key Exchange is a public key (asymmetric) algorithm whereby two parties, without any prior arrangements, can agree upon some shared (secret) information. The parties exchange public information which, in conjunction with private information retained by each user, may be used to compute a common value. This value is typically used as a symmetric key, for example, to encrypt further communications between the parties. The Diffie-Hellman Key Exchange is defined in [h] and is also 19 PART 12 - SECURITY March 1994 (Stable) described in [j]. The Diffie-Hellman Key Exchange is patented in the United States [i][f]. The object identifier is defined in PKCS #3 [j] as: dhKeyAgreement ALGORITHM PARAMETER DHParameter ::= {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-3(3) 1} DHParameter ::= SEQUENCE { prime INTEGER, -- p base INTEGER -- g privateValueLength INTEGER OPTIONAL } 7.4.2 Diffie-Hellman with Common Parameters This version of Diffie-Hellman assumes the use of a common modulus and generator, which are distributed by external means rather than being conveyed in the parameter component of the AlgorithmIdentifier. The patent restrictions in the previous section still apply. The object identifier is defined as: dhWithCommonModulus ALGORITHM PARAMETER NULL ::= {algorithm 16} DHParameter ::= SEQUENCE { prime INTEGER, -- p base INTEGER -- g } 7.4.3 RSA Key Transport RSA key transport is used only for encipherment, typically for transporting symmetric keys. It uses the type 2 padding mechanism of [g]; other padding mechanisms (e.g., those used for signature) are not valid. The algorithm's object identifier is: rsaKeyTransport ALGORITHM PARAMETER NULL ::= { algorithm 22 } 20 PART 12 - SECURITY March 1994 (Stable) 7.5 Signature Algorithms This section specifies a number of signature algorithms, i.e., hash algorithms combined with appropriate asymmetric encryption algorithms. 7.5.1 Message Digests with RSA The algorithms listed below are signature algorithms that combine a message digest algorithm with the RSA cryptographic algorithm to produce a digital signature. Editor's Note - The OIDs below have been assigned by the Directory SIG and the Security SIG. Should we explain why they do not appear in a single tree? 7.5.1.1 Square-Mod-N with RSA Square-Mod-N is a signature algorithm that combines the Square-Mod-N hash algorithm with the RSA cryptographic algorithm to produce a digital signature. This algorithm is defined in [X.509] and its object identifier is defined there as: sqmod-Nwithrsa ALGORITHM PARAMETER KeyAndBlockSize ::= {signatureAlgorithm 1} KeyAndBlockSize ::= INTEGER Recent research regarding the square-mod-n one-way hash function described in Annex D of [X.509] has revealed that the function is not secure. Its use, therefore, is discouraged. 7.5.1.2 MD2 with RSA Its object identifier is: md2WithRsa ALGORITHM PARAMETER NULL ::= {signatureAlgorithm 1} This OID was assigned by the Directory SIG. 7.5.1.3 MD4 with RSA Its object identifier is: 21 PART 12 - SECURITY March 1994 (Stable) md4WithRSA ALGORITHM PARAMETER NULL ::= {algorithm 2} 7.5.1.4 MD5 with RSA Its object identifier is: md5WithRSA ALGORITHM PARAMETER NULL ::= {algorithm 3} 7.5.2 Message Digests with RSA Encryption The algorithms listed below are signature algorithms that combine a message digest algorithm with the RSA Encryption cryptographic algorithm to produce a digital signature. 7.5.2.1 MD2 with RSA Encryption MD2 with RSA encryption is defined in PKCS #1 [g] and its object identifier is defined there as: md2WithRSAEncryption ALGORITHM PARAMETER NULL ::= {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2} 7.5.2.2 MD4 with RSA Encryption Its object identifier is: md4WithRSAEncryption ALGORITHM PARAMETER NULL ::= {algorithm 4} 7.5.2.3 MD5 with RSA Encryption MD5 with RSA Encryption is defined in PKCS #1 [g] and its object identifier is defined there as: 22 PART 12 - SECURITY March 1994 (Stable) md5WithRSAEncryption ALGORITHM PARAMETER NULL ::= {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4} 7.5.3 DSA With SHA This signature algorithm produces a 320-bit signature. SHA is the only hash algorithm which may be used with DSA. Its object identifier is dsaWithSHA ALGORITHM PARAMETER DSAParameters ::= {algorithm 13) 7.5.4 DSA With SHA with Common Parameters This version DSA with SHA signature algorithm uses common parameters which are distributed externally. Its object identifier is dsaCommonWithSHA ALGORITHM PARAMETER NULL ::= { algorithm 21) 7.5.5 RSA Signature With MDC-2 This algorithm uses the RSA Signature algorithm to sign the digest produced by the MDC-2 DES-based hash algorithm. Its object identifier is mdc2WithRSASignature PARAMETER NULL ::= { algorithm 14 } 7.5.6 RSA Signature With SHA This algorithm uses the RSA Signature algorithm to sign a 160-bit SHA digest. Its object identifier is shaWithRSASignature PARAMETER NULL ::= {algorithm 15} 23 PART 12 - SECURITY March 1994 (Stable) 7.6 Symmetric Encryption Algorithms 7.6.1 Data Encryption Standard The Data Encryption Standard (DES) is a secret key (symmetric) cryptographic algorithm. It is defined in FIPS 46-1 [l]. It is also defined as DEA-1 in ANSI X3.92-1981 [m].Implementors will also find several other references useful. FIPS PUB 74 [p] provides guidance on the implementation and use of DES and includes a complete specification of the algorithm. SPEC PUB 500-20 [p] describes the design and operation of the NIST (formerly NBS) testbed that is used for the validation of DES implementations. It specifies a set of 291 test cases that have been designed to exercise every basic element of the algorithm, and as a further check on the correctness of an implementation, it specifies an extensive Monte Carlo analysis. SPEC PUB 500-61 describes the design of four maintenance tests for DES implementations. The tests consist of an iterative test procedure that uses a small program and minimum data. The tests are designed to be independent of implementation and to be fast enough to test devices during actual operation. The tests are defined as four specific stopping points in a general testing process and satisfy four testing requirements of increasing degree of completeness on the thoroughness of testing desired. There are four modes of operation of the DES, as specified by FIPS 81 [n] and ANSI X3.106-1983 [o]. The modes specify how the data will be encrypted and decrypted. In all cases the key is 64 bits. Use of DES for encryption (i.e., all modes discussed below except DES-MAC) are subject to export controls. 7.6.1.1 DES-ECB This is the Electronic Codebook mode of operation. Its object identifier is: desECB ALGORITHM PARAMETER NULL ::= {algorithm 6} This mode should be used to encrypt small blocks (e.g., other DES keys). Its use is deprecated for block encryption since it allows cryptanalysis of repeated block values (i.e., the same plaintext in the same place relative to the block), as well as reassembling messages from known blocks. 24 PART 12 - SECURITY March 1994 (Stable) 7.6.1.2 DES-CBC This is the Cipher Block Chaining mode of operation. Its object identifier is: desCBC ALGORITHM PARAMETER CBCParameter ::= {algorithm 7} The PARAMETER is needed to specify the Initialization Vector, which need not be kept secret. This mode should be used to encrypt multiple blocks, where the full message is available. The random IV prevents codebook analysis of the start of the chain. The IV may be public. This mode will propagate a single bit error in one plaintext block into all succeeding blocks, and will propagate a single bit error in the ciphertext into a garbled plaintext block on decryption as well as a single bit error in the next plaintext block. The following padding mechanism from [w] should be used if the data to be encrypted is octet aligned, unless the security policy dictates otherwise: The input to the DES CBC encryption process must be padded to a multiple of 8 octet, in the following manner. Let n be the length in octets of the input. Pad the input by appending 8-(n mod 8) octet to the end of the message, each having the value 8-(n mod 8), the number of octets being added. In hexadecimal, the possible paddings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606, 07070707070707, and 0808080808080808. All input is padded with 1 to 8 octets to produce a multiple of 8 octets in length. The padding can be removed unambiguously after decryption. Editor's Note - If adding the padding rules would cause existing implementations to break, this should be registered as a separate algorithm identifier. Note, however, that [FIPS 81] specifies its own padding rules for padding binary data, in the absence of application-defined rules such as those above; those rules require an indication (which could be conveyed as an algorithm PARAMETER) of whether the data has been padded or not. 25 PART 12 - SECURITY March 1994 (Stable) 7.6.1.3 DES-OFB This is the Output Feedback mode of operation. Its object identifier and parameters are: desOFB ALGORITHM PARAMETER FBParameter ::= {algorithm 8} The parameters are needed to specify an IV and the number of feedback bits. This mode may be used to encrypt multiple blocks where the error extension properties of DES-CBC are undesirable. A single bit error in the ciphertext will cause only a single bit error in the output plaintext. 7.6.1.4 DES-CFB This is the Cipher Feedback mode of operation. Its object identifier and parameters are desCFB ALGORITHM PARAMETER FBParameter ::= {algorithm 9} The parameters are needed to specify an IV and the number of feedback bits. This mode may be used when the plaintext is made available in pieces, e.g., a character (8-bit CFB) or a bit (1-bit CFB) at a time. This mode will propagate a single bit error in one plaintext block into all succeeding blocks, and will propagate a single bit error in the ciphertext into a single-bit error in the corresponding plaintext character as well as garbling of the next 8 bytes or so of output (the exact amount depends on the feedback size). 7.6.1.5 DES-MAC DES-MAC is a Message Authentication Code algorithm (cryptographic checksum) based on the DES that uses a single 64-bit DES key. It is specified in FIPS 113 [s] and is equivalent to the binary mode defined in ANSI X9.9-1986 [t]. Its object identifier and parameter are: 26 PART 12 - SECURITY March 1994 (Stable) desMAC ALGORITHM PARAMETER MACParameter ::= {algorithm 10} The parameter is needed to specify the MAC length in bits. DES-MAC is equivalent to DES-CBC using an all zero Initialization Vector (IV), with all but the last cipher output block discarded. Separate keys (where one may simply be a variant of the other) should be used if both DES-CBC encrypting and MACing the same data. Editor's Note - We need to include the reference which specifies the vulnerability when the same key is used to DES-CBC encrypt and MAC the same data, and recommends the use of separate keys. 7.6.1.6 DES-EDE The DES algorithm in Encrypt-Decrypt-Encrypt (EDE) mode, as defined by [af] for encryption and decryption with pairs of 64-bit keys, might be used for key or MAC encryption when symmetric key management is employed. (The mechanism is subject to the same constraints as DES ECB, but is cryptographically stronger.) Given the pair of keys, the data is enciphered with the first key, deciphered with the second key, and enciphered again with the first key to perform encryption; the process is reversed for decryption. Note that if both keys are the same, the result is equivalent to a single encryption under the single key. The key may be represented as a single 128-bit string with the first 64 bits being the first key and the last 64 bits being the second key. desEDE ALGORITHM PARAMETER NULL ::= {algorithm 17} 7.6.2 RC2-CBC RC2-CBC is a symmetric block encryption algorithm. It is proprietary to RSA Data Security, Inc., and a license from them is required to use the algorithm. The algorithm uses an 8-byte key and operates on an 8-byte block, with cipher block chaining as in DES. The recommended padding is as described above for DES-CBC: the final block is padded to an 8-byte boundary by appending 8 - (n mod 8) bytes, each having the value 8 - (n mod 8), where n is the total number of bytes being encrypted. The speed is comparable to DES. 27 PART 12 - SECURITY March 1994 (Stable) rc2CBC ALGORITHM PARAMETER RC2-CBCParameter ::={iso(1) member-body(2) US(840) rsadsi(113549) encryptionAlgorithm(3) 2} RC2-CBCParameter ::= CHOICE {IV, SEQUENCE {version RC2Version, IV}} -- with IV only, version defaults to 65 IV ::= OCTET STRING -- 8 octets RC2Version ::= INTEGER -- 0 to 255, defined by RSADSI The version number relates to the security level. Different versions of RC2 provide different security levels, some of which are exportable. 7.6.3 RC-4 RC-4 is a symmetric block encryption algorithm. It is proprietary to RSA Data Security, Inc., and a license from them is required to use the algorithm. The RC4 key size is variable, 1 to 256 bytes; the block size is one byte. RC4 is a stream cipher, and it exclusive-ors a pseudorandom sequence generated from the key to encrypt or decrypt; a given key should therefore be used only once. RC4 is very fast. rc4 ALGORITHM PARAMETER NULL ::={iso(1) member-body(2) US(840) rsadsi(113549) encryptionAlgorithm(3) 4} 7.7 ASN.1 7.7.1 Distinguished Encoding Rules In order to allow verification of digital signatures produced by the SIGNED and SIGNATURE MACROs of [ISO9594-8], it is necessary to define a set of distinguished encoding rules to produce an unambiguous encoding of a given abstract syntax value. [ISO9594-8] defines a number of such encoding rules (8.7), but is, unfortunately, underspecified in the following areas: a) Ordering of SET OF components; b) Handling of unused trailing zero bits; 28 PART 12 - SECURITY March 1994 (Stable) c) Invocation and designation of new character sets in some of the character string types. The following rules remove these ambiguities: a) The [ISO9594-8] distinguished encoding rules are always used; b) For SET OF types, components are sorted into ascending order of the distinguished encodings of the components; c) For BIT STRINGS with unused trailing bits, if the type definition that specifies the bits have significance, then they are included in the encoding; otherwise they are not; d) For those character strings which allow it, escape sequences are generated to invoke and designate new register entries only when the register entry for the character currently being encoded is different from that currently designated for G0, C0, or C1. All designations shall be into G0 or C0. (It is assumed that all characters have entries in the ISO Registry of Coded Character Sets.) NOTE - Rules b,c, and d are taken from [ISO/CD8825-3] (Nov. 1990), the ASN.1 Distinguished Encoding Rules. Other features of [ISO/CD8825-3], which conflict with [ISO9594-8] (e.g., length encoding for constructors), are NOT used by this IA. It is recommended that whenever the SIGNED or SIGNATURE macro is to be applied to an object, the object should be transferred in its distinguished encoded form. In this way, when the resources required to encode or decode an object exceed the resources required to apply the SIGNED or SIGNATURE macro, a receiving entity may apply the macro immediately, thus realizing enhanced performance. However, if the macro application is unsuccessful, the object must be distinguished encoded and the macro re-applied to determine its actual success or failure. 29 PART 12 - SECURITY March 1994 (Stable) 8 Lower Layers Security 9 Upper Layers Security This clause addresses the provision of security services in the Upper Layers. The Upper Layers Security Model specifies the interactions among the Upper Layers in providing and using security services [ISO/CD10745]. 9.1 Security Mechanisms 9.1.1 Peer Entity Authentication ACSE authentication extensions [ISO8649][ISO8650/1] support two- way authentication through the definition of a new functional unit. When this functional unit is employed, additional parameters are provided by the A-ASSOCIATE service to indicate this requirement and convey authentication information between entities. The ASN.1 definition for this information is given below: from [ISO8650/1]: Mechanism-name ::= OBJECT IDENTIFIER --This field shall be present if authentication-value is of type ANY. Authentication-value := CHOICE { charstring [0] IMPLICIT GraphicString, bitstring [1] IMPLICIT BIT STRING, external [2] IMPLICIT EXTERNAL, other [3] ANY -- Defined by Mechanism-name } --The abstract syntax of authentication-value is determined by the authentication-mechanism --used during association establishment. The authentication-mechanism is either explicitly --denoted by the OBJECT IDENTIFIER value for Mechanism-name, or it is know implicitly by --prior agreement between the communicating partners. If "other" is chosen, then --"Mechanism-name" must be present in accordance with ISO 8824. 30 PART 12 - SECURITY March 1994 (Stable) These agreements define the following mechanisms for use with this ACSE functional unit: simple-strong authentication mechanism. 9.1.1.1 Simple-Strong Authentication 9.1.1.1.1 Operation The operation of the simple-strong authentication mechanisms are based upon [ISO9594-3] and [ISO9594-8] standards. The sending system is the entity requesting authentication of its identity, and the receiving system is the entity performing the authentication. The sending system supplies data for the ACSE authentication field of the A-ASSOCIATE primitive. The receiving ACSE obtains the ACSE authentication data from the A-ASSOCIATE PDU, and it performs the authentication check. If the check is successful, the association formation succeeds or fails depending upon other circumstances and parameters. The use of the ACSE authentication fields support both the simple and strong credentials variants of the [ISO9594-8] authentication exchanges. Certificates for use with strong authentication must be compatible with [ISO9594-8]. Certificates procured for use with Internet Privacy Enhanced Mail [u][v][w][x] are completely compatible with [ISO9594-8] and may (subject to licensing restrictions) be used by the strong authentication mechanism. However, Privacy Enhanced Mail uses only a subset of the suggested [ISO9594-7] name forms, and might not support certain name forms of interest to specific OIW applications. Examples include Application Entity names and certain name forms defined by the North American Directory Forum in NADF-123 [y]. 9.1.1.1.2 Data Structure Mechanism Name The following is the ASN.1 description of the authentication data structure for simple or strong authentication: 31 PART 12 - SECURITY March 1994 (Stable) simple-strong-auth-mechanism OBJECT IDENTIFIER ::= {iso (1) identified-organization (3) oiw (14) secsig (3) authentication-mechanisms (3) simple-strong-identity-authentication (1) } Authentication Value The authentication value is conveyed in the other option of the authentication-value field of ACSE authentication. Authentication-Value ::= SEQUENCE OF DirectoryAbstractService.Credentials This data type is defined in ASN.1 module DirectoryAbstractService of [ISO9594-3] as modified through resolution of Directory Defect Report Numbers 9594/052 and 063. The semantics of all fields are as specified in clause 8.1.2.1 of [ISO9594-3]. The Authentication-Value is defined as a SEQUENCE because it is permitted to pass credentials for multiple entities in the authentication value. It is the responsibility of the application to determine the specific meaning and use of multiple credentials in such a case. It is anticipated that specific applications (e.g., Network Management) would provide specifications for handling multiple credentials within their own clauses of this Part. This authentication mechanism may employ any registered authentication algorithm; however, it is recommended that the algorithms identified in clause 7 be used. 9.1.1.1.3 Options For the Simple Credentials option of Credentials, the following agreements apply. Conforming implementations are not required to 32 PART 12 - SECURITY March 1994 (Stable) employ the OPTIONAL validity sequence of the SimpleCredential data element. Receiving implementations that do not employ the validity sequence must reject an authentication value which does contain this sequence. Conforming implementations shall employ the optional password field of the SimpleCredential data element. Note that the password may be hashed using one way functions and the other validity fields. Password is either cleartext, Protected1 or Protected2 according to [ISO9594-8]. 9.1.1.2 External Authentication Mechanisms Externally defined authentication exchanges may employ the external [2] option of the authentication-value field of ACSE authentication. In this case it is recommended that the mechanism-name be omitted, with the particular mechanism in use being implied by the abstract syntax identified in the external construct. 9.1.1.2.1 Kerberos Version 5 One instance of an external authentication mechanism is the Kerberos mechanism defined in [z]. The Kerberos specification assigned the following object identifier to an abstract syntax suitable for use in this way: [TBD] 9.1.2 Integrity/Data Origin Authentication Transformation This transformation is a specialization of gulsSignedTransformation, which is defined in clause D.4 of DIS 11586-1. This transformation uses the following parameters, and provides additional details on the operation of the encoding and decoding processes. 1) The initEncRules field has the value { joint-iso-ccitt asn1(1) ber-derived(2) der(1) }, i.e., DER. 2) The signOrSealAlgorithm element shall be keyed-hash- seal: keyed-hash-seal ALGORITHM PARAMETER NULL ::= { algorithm 23 } 33 PART 12 - SECURITY March 1994 (Stable) The keyed-hash-seal algorithm is specified in the encoding process description below. 3) The hash algorithm, if the hashAlgorithm element is not present, shall default to md5. Editor's Note - Points 2 and 3 are redundant with text in the NM Agreements. This should be resolved before progressing to the Stable Agreements. 4) The keyInformation field is not present. Encoding process: When a value of an abstract syntax is to be sealed for transmission, the following procedures apply: 1) Encode the output data type of the transformation using the ASN.1 Distinguished Encoding Rules, with the shared secret key used as the value of the appendix component. (Since automatic tagging is used, this is equivalent to encoding the unprotectedItem using DER, and enclosing it in the intermediateValue and output data type using BER.) NOTE - This encoding is only for purposes of the security transformation, and does not mean DER must be used to encode the PDU for transmission, i.e., as the transfer syntax. 2) Hash the complete DER encoding of the value derived in step 1. NOTE - The current definition of the gulsSignedTransformation is unduly restrictive in that cryptographic operations are only applied to the intermediateValue element of the output data type, rather than the entire type. This is being submitted as a ballot comment on DIS 11586-1. 3) Insert the hash value into the appendix component of the output data type, which is the xformedDataType element of the transmitted PDV. Encoding process local inputs: Identifier of hash algorithm and any required algorithm parameters, and shared secret key. (Most currently registered hash algorithms have a NULL parameter.) Decoding process: When a received PDV to be verified, the following procedures apply: 1) Extract and save the received hash value contained in 34 PART 12 - SECURITY March 1994 (Stable) the appendix component of the received xformedDataType component of the received PDV. 2) Replace the value in the appendix component of the xformedDataType component with the shared secret key. NOTE - The extraction and replacement of the seal field may be performed directly on the ASN.1 encoded PDU if the length of the secret key and the hash digest are equal. Otherwise, the PDU must be decoded and reencoded. 3) Hash the DER encoding of the xformedDataType element. (Reencoding may be avoided if the unprotectedItem encoding is distinguished, and the generic protecting transfer syntax defined in DIS 11586-4 is used.) 4) Compare the hash extracted in step 1 with the hash derived in step 3. If they are equal, then the seal is valid; otherwise an error is signalled. Decoding process local inputs: Identifier of hash algorithm and any required algorithm parameters, and shared secret key. Decoding process outputs: Recovered unprotected item. and an indication of whether the seal is valid. Errors: An error condition occurs if seal verification fails. Security services: Data origin authentication, data integrity. 10 Message Handling System (MHS) Security All current MHS security relevant text appears in Part 8, clause 10. 35 PART 12 - SECURITY March 1994 (Stable) 11 Directory Services Security 12 Network Management Security This clause outlines an approach to providing security services for OSI Network Management. The goals of this approach are to provide security in a manner that is simple and straight-forward to implement, and to avoid any unnecessary computational and managerial overhead. The approach also takes into consideration the need for different levels of security services within different network management domains, and the near term requirement for interoperability of network management entities over heterogeneous network types. 12.1 Threats For the purpose of discussion, threats are divided into two categories: primary and secondary threats. Primary threats are those considered to be applicable to the full range of network management implementations, while secondary threats are considered to be applicable to the more limited range of highly secure implementations. The primary threats to be protected against are the following: a) The masquerading of a manager or agent entity; b) The fabrication or modification of Common Management Information Protocol (CMIP) data units. By countering primary threats, disruption of network management services by the casual user can be avoided. The secondary threats to be protected against are the following: a) All primary threats; b) The disclosure of CMIP data units; c) The replay, reflection, reordering, insertion, or deletion of CMIP data units. 36 PART 12 - SECURITY March 1994 (Stable) 12.2 Security Services 12.2.1 Basic Security Services The security services required to counter primary threats are: a) Peer entity authentication; b) Data origin authentication; c) Connectionless integrity. Peer entity authentication is to occur during the establishment of an application association. If the association is successfully established, the underlying security mechanism provides information that is subsequently used in data origin authentication. There the information may be included in or, in some other way, transform the data units of subsequent exchanges so that they can be identified as originating from an authenticated entity. Both authentication security services are to be provided at the application level of the protocol. Connectionless integrity insures that data units originating from an authenticated source are not modifiable without detection. When combined with a strong data origin authentication mechanism, the ability to fabricate new data units is also countered. Connectionless integrity may be provided at either the application level of the protocol or within one of the lower levels of the protocol (i.e., transport or network). 12.2.2 Enhanced Security Services The security services required to counter secondary threats are: a) All basic security services with the possible exception of connectionless integrity; b) Connectionless confidentiality; c) Connection integrity with or without recovery. Both connectionless confidentiality and connection integrity may be provided at either the application level of protocol or within one of the lower levels of protocol. The latter provision is assumed here. Enhanced security services are not discussed further in this note, but to be issued as a requirement for the lower layer protocol and service standards, and according to functional standards to be developed. 37 PART 12 - SECURITY March 1994 (Stable) 12.3 Security Mechanisms 12.3.1 Peer Entity Authentication Peer Entity Authentication will use the ACSE authentication mechanism and associated data types as defined in clause 9 of this Part of the IAs. The specific authentication mechanism to be supported is the Simple-Strong Authentication defined in 9.1.1.1. Support of ACSE authentication is optional. 12.3.2 Connectionless IntegrityProposed text for this clause appears in WIA Part 12, clause 12.3.2. 38 PART 12 - SECURITY March 1994 (Stable) Annex A (normative) ISPICS Requirements List 39 PART 12 - SECURITY March 1994 (Stable) Annex B (normative) Errata Table B.1 - SIA Part 12 changes NO. OF TYPE REFERENCED CLAUS NOTES ERRATA DOCUMENT E 40 PART 12 - SECURITY March 1994 (Stable) Annex C (normative) TBD 41 PART 12 - SECURITY March 1994 (Stable) Annex D (informative) Security Algorithms and Attributes OIWSECSIGAlgorithmObjectIdentifiers {i(1) identified-organization(3) oiw(14) secsig(3) oIWSECSIGAlgorithmObjectIdentifiers(1)} DEFINITIONS = BEGIN EXPORTS -- to be determined IMPORTS -- none -- category of information object -- defining our own here; perhaps the definition should be imported from -- {joint-iso-ccitt ds(5) modules(1) usefulDefinitions(0)} algorithm OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2)} -- macros -- taken from {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7)} ALGORITHM MACRO::= BEGIN TYPE NOTATION::= "PARAMETER" type VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) END -- of ALGORITHM -- algorithms md4WithRSA ALGORITHM PARAMETER NULL ::= {algorithm 2} md5WithRSA ALGORITHM PARAMETER NULL ::= {algorithm 3} md4WithRSAEncryption ALGORITHM 42 PART 12 - SECURITY March 1994 (Stable) PARAMETER NULL ::= {algorithm 4} desECB ALGORITHM PARAMETER NULL ::= {algorithm 6} desCBC ALGORITHM PARAMETER CBCParameter ::= {algorithm 7} CBCParameter ::= IV desOFB ALGORITHM PARAMETER FBParameter ::= {algorithm 8} desCFB ALGORITHM PARAMETER FBParameter ::= {algorithm 9} FBParameter ::= SEQUENCE { iv IV, numberOfBits NumberOfBits } NumberOfBits ::= INTEGER -- Number of feedback bits (1 to 64 bits) Editor's Note - Check FIPS PUB 81 for allowed ranges of feedback bits and specify ranges here as a comment. IV ::= OCTET STRING -- 8 octets desMAC ALGORITHM PARAMETER MACParameter ::= {algorithm 10} MACParameter ::= INTEGER -- Length of MAC (16, 24, 32, 40, 40 or 64 bits) Editor's Note - Check FIPS PUB 113 for allowed 43 PART 12 - SECURITY March 1994 (Stable) rsaSignature ALGORITHM PARAMETER NULL ::= { algorithm 11 } dsa ALGORITHM PARAMETER DSAParameters ::= { algorithm 12 } dsaWithSHA ALGORITHM PARAMETER DSAParameters ::= { algorithm 13} mdc2WithRSASignature PARAMETER NULL ::= { algorithm 14 } shaWithRSASignature PARAMETER NULL ::= { algorithm 15 } dhWithCommonModulus ALGORITHM PARAMETER NULL ::= { algorithm 16 } desEDE ALGORITHM PARAMETER NULL ::= { algorithm 17 } sha ALGORITHM PARAMETER NULL ::= { algorithm 18 } mdc-2 ALGORITHM PARAMETER NULL ::= { algorithm 19 } dsaCommon ALGORITHM PARAMETER NULL ::= { algorithm 20 } dsaCommonWithSHA ALGORITHM PARAMETER NULL ::= { algorithm 21) rsaKeyTransport ALGORITHM PARAMETER NULL ::= { algorithm 22 } 44 PART 12 - SECURITY March 1994 (Stable) keyed-hash-seal ALGORITHM PARAMETER NULL ::= { algorithm 23 } END -- of Algorithm Object Identifier Definitions 45 PART 12 - SECURITY March 1994 (Stable) Annex E (normative) References for Security Algorithms [a] Kaliski, B., The MD2 Message-Digest Algorithm, Internet Draft draft-rsadsi-kaliski-md2-00.txt, July 1, 1991. [b] Rivest, R. and S. Dusse, The MD4 Message-Digest Algorithm, Internet Draft draft-rsadsi-rivest-md4-00.txt, July 1, 1991. [c] Rivest, R. and S. Dusse, The MD5 Message-Digest Algorithm, Internet Draft draft-rsadsi-rivest-md5-01.txt, July 10, 1991. [d] Rivest, R. L., A. Shamir and L. Adleman, A method for obtaining digital signatures and public-key cryptosystems, Communications of the ACM, Volume 21, Number 2, February 1978, pp. 120-126. [e] Rivest, Ronald L., Adi Shamir and Leonard M. Adleman, Cryptographic Communications System and Method, United States Patent No. 4,405,829, September 20, 1983. [f] Fougner, R.B., Public Key Standards and Licenses, Internet Request for Comments (RFC) 1170, January 1991. [g] RSA Data Security, Inc., PKCS #1: RSA Encryption Standard, Version 1.4, June 3, 1991. [h] Diffie, W., and M.E. Hellman, New directions in cryptography, IEEE Transactions on Information Theory, IT-22, pp. 644-654, 1976. [i] Hellman, Martin E., Bailey W. Diffie and Ralph C. Merkle, Cryptographic Apparatus and Method, United States Patent No. 4,200,770, April 29, 1980. [j] RSA Data Security, Inc., PKCS #3: Diffie-Hellman Key-Agreement Standard, Version 1.3, June 3, 1991. [k] ElGamal, T., A public key cryptosystem and a signature scheme based on discrete logarithms, IEEE Transactions on Information Theory, IT-31, Number 4, July 1985, pp. 469-472. [l] Federal Information Processing Standards Publication (FIPS PUB) 46-1, Data Encryption Standard, U.S. Department of Commerce/National Bureau of Standards, 46 PART 12 - SECURITY March 1994 (Stable) Supersedes FIPS PUB 46, January 15, 1977, Reaffirmed January 22, 1988. [m] ANSI X3.92-1981, Data Encryption Algorithm, American National Standards Institute, Approved December 30, 1980. [n] Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, U.S. Department of Commerce/National Bureau of Standards, December 2, 1980. [o] ANSI X3.106-1983, Data Encryption Algorithm - Modes of Operation, American National Standards Institute, Approved May 16, 1983. [p] Federal Information Processing Standards Publication (FIPS PUB) 74, Guidelines for Implementing and Using the NBS Data Encryption Standard, U.S. Department of Commerce/National Bureau of Standards, April 1, 1981. [q] Gait, Jason, Validating the Correctness of Hardware Implementations of the NBS Data Encryption Standard, Special Publication 500-20, U.S. Department of Commerce/National Bureau of Standards, Issued November 1977, Revised September 1980. [r] Gait, Jason, Maintenance Testing for the Data Encryption Standard, Special Publication 500-61, U.S. Department of Commerce/National Bureau of Standards, August 1980. [s] Federal Information Processing Standards Publication (FIPS PUB) 113, Computer Data Authentication, U.S. Department of Commerce/National Bureau of Standards, May 30, 1985. [t] American National Standard X9.9-1986, Financial Institution Message Authentication (Wholesale), American Bankers Association, April 7, 1986. [u] Linn, John, Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encipherment and Authentication Procedures, Internet Draft draft-ietf-pem-msgproc-01.txt, September 1991. [v] Kent, Steve, Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management, Internet Draft draft-ietf-pem-keymgmt-00.txt, June 1991. [w] Balenson, David. M, Privacy Enhancement for Internet 47 PART 12 - SECURITY March 1994 (Stable) Electronic Mail: Part III -- Algorithms, Modes, and I d e n t i f i e r s , I n t e r n e t D r a f t draft-ietf-pem-algorithms-00.txt, August 1991. [x] Kaliski, Burton. S, Privacy Enhancement for Internet Electronic Mail: Part IV -- Notary, Co-Issuer, CRL-Storing and CRL-Retrieving Services, Internet Draft draft-ietf-pem-notary-00.txt, July 1991. [y] North American Directory Forum, A Naming Scheme for c=US, Request for Comments 1255, September 1991. [z] Kohl, John and B. Clifford Neuman, The Kerberos Network Authentication Service, Internet Draft cat-kerberos-00.txt, June 1991. [aa] Proposed FIPS xx, Digital Signature Standard, U.S. Dept. of Commerce/National Institute of Standards and Technology, 1992. Also published as ANS X9.30-199x, Public Key Cryptography Using Irreversible Algorithms for the Financial Services Industry, Part 1: The Digital Signature Algorithm (DSA). [ab] Proposed FIPS xx, Secure Hash Standard, U.S. Dept. of Commerce/National Institute of Standards and Technology, 1992. Also published as ANS X9.30-199x, Public Key Cryptography Using Irreversible Algorithms for the Financial Services Industry, Part 1: The Secure Hash Algorithm (SHA). [ac] ANS X9.31-199x, Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry, Part 2: Hash Algorithms. [ad] ANS X9.31-199x, Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry, Part 1: The RSA Signature Algorithm . [ae] ISO/IEC IS 9796, Digital Signature Scheme Giving Message Recovery, 1991. [af] ANS X9.17-1985, Financial Institution Key Management (Wholesale), American Bankers Association, April 4, 1985, Section 7.2. [ag] D. Coppersmith, Analysis of ISO/CCITT Document X.509 Annex D, IBM Research Division, Yorktown Heights, June 1989. [ah] J. Moore, "Protocol Failures in Cryptosystems," 48 PART 12 - SECURITY March 1994 (Stable) Proceedings of the IEEE, vol. 76, no. 5, pp. 594-601, May 1988. [ai] Miller,S.P., B.C. Neuman, J.I. Schiller, and J.H. Saltzer, "Project Athena Technical Plan Section E.2.1: Kerberos Authentication and Authorization System," Project Athena, MIT, December 1987. 49 PART 12 - SECURITY March 1994 (Stable) Annex F (informative) Bibliography [1] ISO/IEC JTC1 SC21 N3614 Information Retrieval, Transfer, and Management for OSI [2] ISO/IEC DP 9796 Data Cryptographic Techniques [3] Secure Data Network System (SDNS): Key Management Profile - Communications Protocol Requirements (SDN-601/NIST IR 90-4262) [4] SDNS: Message Security Protocol (SDN-701/NIST IR 90-4250) [5] SDNS: Directory (SDN-702/NIST IR 90-4250) [6] ISO/IEC JTC1 SC21/WG1 N5002 Security ASE [7] Access Control Information Specification (ACIS) [8] SDNS: Key Management Protocol - Definition of Services Provided (SDN-902/NIST IR 90-4262) [9] SDNS: Key Management Protocol - Specification of the Protocol (SDN-903/NIST IR 90-4262) [10] ISO/IEC JTC1 SC21/WG1 N4110 Authentication ASE Exchange [11] SDNS: Security Protocol 3 (SDN-301/NIST IR 90-4250) [12] SDNS: Security Protocol 4 (SDN-401/NIST IR 90-4250) [13] SDNS: Key Management Protocol - SDNS Traffic Key (SDN-906/NIST IR 90-4262) [14] ISO/IEC JTC1 SC21/WG1 N5001 Upper Layers Security Model [15] ISO/IEC JTC1 SC21/WG1 F29 N5045 Access Control Framework [16] ISO/IEC JTC1 SC21/WG1 F30 Authentication Framework [17] ISO/IEC JTC1 SC21/WG1 F31 N5047 Integrity Framework [18] ISO/IEC JTC1 SC21/WG1 F32 N5046 Non-Repudiation [19] ISO/IEC JTC1 SC21/WG4 N3775 Security Audit Trail [20] ISO/IEC JTC1 SC21/WG1 N4110 Authentication ASE Exchange 50 PART 12 - SECURITY March 1994 (Stable) [21] ISO/IEC JTC1 SC21/WG7 N4022 Key Management Framework [22] ISO/IEC JTC1 SC21/WG1 N5048 Confidentiality Framework [23] ISO/IEC JTC1 SC21/WG1 N5049 Guide to OSI Security Standards [24] ISO/IEC JTC1 SC21/WG1 N5044 Security Framework Overview [25] RFC-1113, Privacy Enhancement for Internet Electronic Mail: Part I - Message Encipherment and Authentication Procedures. [26] RFC-1114, Privacy Enhancement for Internet Electronic Mail: Part II - Certificate-Based Key Management. [27] RFC-1115, Privacy Enhancement for Internet Electronic Mail: Part III - Algorithms, Modes, and Identifiers (August 1989). [28] Network Layer ISO/IEC JTC1 SC6 [29] Transport Layer ISO/IEC JTC1 SC6 6285 [30] Lower Layer ISO/IEC JTC1 SC6 6227 [31] ANSI X9.9 DES Encryption Algorithum 51 PART 12 - SECURITY March 1994 (Stable) Annex G (informative) ElGamal The information in this subclause includes a tutorial description of the ElGamal scheme for digital signature using the notation defined in the Directory Documents, [ISO9594-8]. It is intended that much of the tutorial information provided in this subclause will be moved to the security agreements sometime in the future. G.1 Background The ElGamal digital signature scheme is based on earlier work done by Diffie and Hellman [b] in which it was suggested that a likely candidate for a one-way function is the discrete exponential function (1) where x is an integer between 1 and p-1 inclusive, where p is a very large prime number, and where is an integer such that 1 p and { mod p, 2 mod p, ..., p-1 mod p} is equal to the set {1, 2, ..., p-1}. In algebraic terminology, such an is called a primitive element. References on the topic of primitive roots and elements are [aa] and [ab]. Now, in the real number system, if y = x, then by definition of the logarithm we can solve for x using x = log (y). The same idea extends to solving eq (1) for x so that inverting f(x) requires calculating discrete logarithms. The reason Diffie and Hellman suspected eq (1) is one-way is that for suitable p, it is computationally difficult to invert f(x). According to the current state of the art, computing discrete logs for suitable p has been found to require a number of operations roughly equivalent to (2) where b is the number of bits in p, and c is estimated at c = .69 according to [ac]. This can be compared to only about 2 log2 p multiplications for discrete exponentiation. If in fact the best known algorithm for computing discrete logs is near optimal then Expression (2)is a good measure of the problem's complexity (for a properly chosen p) and the discrete exponential function has all the qualities of a one-way function as described by Diffie and Hellman. 43 PART 12 - SECURITY March 1994 (Stable) G.2 Digital Signature Private Key: Xs denotes the private key for user X. Xs is a randomly chosen integer which user X keeps secret. Public Key: Xp denotes the public key for user X and is calculated using the corresponding private key such that (3) where a) p is a prime satisfying the requirements listed in 12.2.2.4. b) is a primitive element mod p. c) Note that p and could be used globally, but because they should be easily changeable (see 12.2.2.4 for information about why these two parameters should be easily changeable) it would probably be preferable for each user to choose his/her own p and . If users choose their own, then p and must be made available to the recipient for use in the signature verification process. Signing Procedure: Suppose user A wants to sign a message intended for recipient B. The basic idea is to compute a two part signature (r, s) for the message m such that (4) where h is a one-way hash function. Compute the signature (r, s) as follows. a) Choose a random number k, uniformly between 0 and p-1 such that k and p-1 have no common divisor except 1 (i.e., gcd(k,p-1)=1). b) Compute r such that (5) c) Use r to solve for the corresponding s as follows. 1) rewrite eq (4) using eq (5) and the definition of the public key to get (6) 44 PART 12 - SECURITY March 1994 (Stable) Combining exponents, get (7) eq (7) implies that (8) Note that eq (8) has a single solution for s because k was chosen such that gcd(k,p-1)=1. See [ad] for supporting theorem. 2) now solve for s and get (9) where I is computed such that k * I 1 (mod p-1). The ElGamal signature is comparable in size to the corresponding RSA signature. G.3 Verification The recipient receives Ap, m, r, s, , and p and computes both sides of eq (4) and then compares the results. G.4 Known Constraints on Parameters The following list of constraints is the result of a search of current literature and may not be complete: a) p must be prime; b) p must be large. Note that Expression (2) can be used to speculate on the level of security afforded by crypto systems based on the discrete log problem. Breaking the ElGamal scheme has not been proven to be equivalent to finding discrete logs, but if we assume equivalence then we can estimate how large p should be for a desired level of security. For instance,suppose we wanted to use Expression (2) to 45 PART 12 - SECURITY March 1994 (Stable) decide how large p should be so that we can be reasonably sure the system cannot be broken (using the best known algorithm) in a practical amount of time. To be on the conservative side, we decide we want to protect against a special purpose machine that can perform 1015 operations per second. Specifically, we want to know how large p should be so that such a machine would take at least one year to break the system. In one year, the hypothetical machine can perform 3 x 1022 operations. To find the size of the desired p, solve the following equation for b. (10) We get . This is the number of bits in the desired p. So, the magnitude of the desired p is about 2606 which is roughly 266 x 10180. Hence, to be reasonably sure of attaining the desired level of security, we find a prime number greater than 266 x 10180 which satisfies all the other criteria listed in this subclause. Our confidence, however, is strictly based on the assumption that breaking ElGamal is as difficult as finding discrete logs and the assumption that the best known algorithm for finding discrete logs is near optimal. c) p should occasionally be changed. This requirement is discussed in [ae] and is related to the discovery of new algorithms for computing discrete logarithms in GF(p). d) p-1 must have at least one large prime factor. This requirement is discussed in [ae] and is imposed by the Silverman-Pohlig-Hellman algorithm p which computes discrete logarithms in GF(p) using on the order operations and a comparable amount of storage, where r is the largest prime factor in p-1. e) p should not be the square of any prime. A subexponential-time algorithm for computing discrete logarithms in GF(p2) has been found. See [af]for details. 46