SNMPv3 Working Group David Reeder INTERNET-DRAFT NAI Labs Olafur Gudmundsson NAI Labs 6 October 1999 Extension to the User-Based Security Model (USM) to Support Triple-DES EDE in "Outside" CBC Mode Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes an extension to the the User-based Security Model (USM) [RFC2574]. It defines the Elements of Procedure for providing SNMP message level security for a privacy protocol using Triple-DES EDE in "Outside" Cipher-Block Chaining (CBC) mode. This document also extends the existing SNMPv3 MIBs in order to remotely monitor and manage the configuration parameters for this privacy protocol of the USM. Reeder & Gudmundsson Expires April 2000 [Page 1] INTERNET-DRAFT 3DES-EDE for USM October 1999 Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1. Introduction 2 2. Use of Password-to-Key Algorithm with 3DES-EDE 5 2.1 Chaining of the Password-to-Key Algorithm 5 2.2 Password (P) versus Ku versus the localized key Kul 6 3. Use of SNMP-USER-BASED-SM-3DES-MIB MIB Module 7 4. Definitions 8 5. 3DES-EDE Symmetric Encryption Protocol 11 5.1. Mechanisms 11 5.1.1. Symmetric Encryption Protocol 11 5.1.1.1. 3DES-EDE Key and Initialization Vector 12 5.1.1.1.1. 3DES-EDE Key 12 5.1.1.1.2. 3DES-EDE Initialization Vector 13 5.1.1.2. Data Encryption 14 5.1.1.3. Data Decryption 15 5.2. Elements of the 3DES-EDE Privacy Protocol 16 5.2.1. Users 16 5.2.2. msgAuthoritativeEngineID 16 5.2.3. SNMP Messages Using this Privacy Protocol 17 5.2.4. Services provided by the 3DES-EDE Privacy Module 17 5.2.4.1. Services for Encrypting Outgoing Data 17 5.2.4.2. Services for Decrypting Incoming Data 18 5.3. Elements of Procedure 19 5.3.1. Processing an Outgoing Message 19 5.3.2. Processing an Incoming Message 19 6. Security Considerations 20 7. Acknowledgements 20 8. Intellectual Property 20 9. References 21 10. Editors' Addresses 23 11. Full Copyright Statement 24 A. SNMP engine Installation Parameters Using 3DES-EDE 24 B. Password-to-Key Chaining Sample Results 25 B.1. Password-to-Key Chaining Sample Results using MD5 25 B.2. Password-to-Key Chaining Sample Results using SHA 26 C. Sample keyChange Results 26 C.1. Sample keyChange Results using MD5 26 C.2. Sample keyChange Results using SHA 27 D.1. Strength of 3DES-EDE and Known Attacks 28 Reeder & Gudmundsson Expires April 2000 [Page 2] INTERNET-DRAFT 3DES-EDE for USM October 1999 D.2. Further References 29 1. Introduction The Architecture for describing Internet Management Frameworks [RFC2571] describes that an SNMP engine is composed of: 1) a Dispatcher 2) a Message Processing Subsystem, 3) a Security Subsystem, and 4) an Access Control Subsystem. Applications make use of the services of these subsystems. It is important to understand the SNMP architecture and the terminology of the architecture to understand where the extensions to the Security Model described in this document fit into the architecture and interact with other subsystems within the architecture. The reader is expected to have read and understood the description of the SNMP architecture and the User-Based Security Model (USM), as defined in [RFC2571] and [RFC2574], respectively. This memo describes an extension to the User-based Security Model which defines the 3DES-EDE privacy protocol using Triple-DES EDE in "Outside" CBC mode. "EDE" is one method of triple encryption which simply varies the "direction" that the single DES algorithm is used in each iteration -- first encrypting, then decrypting, and finally encrypting again. Since the second decryption uses a different key than the first encryption, the decryption iteration serves to further encrypt the data. This extension adds to, but does not otherwise change, the details describing the use of privacy protocols in the USM. Further, it makes no changes to the remainder of the USM, and adopts all its assumptions, supporting concepts and apparatus. It is expected that this document alone will provide all necessary details necessary for the immediate integration and use of 3DES-EDE into the existing USM subsystem. In particular, the following aspects of the USM are adopted in their entirety, without modification, by the 3DES-EDE extension: Reeder & Gudmundsson Expires April 2000 [Page 3] INTERNET-DRAFT 3DES-EDE for USM October 1999 - Abstract Service Interface describing the User-based Security Model primitives for privacy, - Format of SNMP messages using the User-based Security Model, - Password-to-key key localization algorithm, - Services for generating an outgoing SNMP Message, and for processing an incoming SNMP message, - Existing USM security considerations including: * Recommended practices * Defining users * Conformance * Use of reports * Access to the SNMP-USER-BASED-SM-MIB. Note that some details surrounding the use of the password-to-key algorithm for key localization are necessarily changed when using this extension in order to provide for the larger number of bits required by the 3DES-EDE cryptographic key. The key localization algorithm as specified in the USM as the password-to-key algorithm has not changed, however. (See [LOCALIZED-KEY] for the original definition.) In addition, while users may specify passphrases of any length, the maximum length of keying material used by the SNMP engine is limited to the length of the largest hash generated by the currently specified authentication protocols. Some effort should be taken to provide for key lengths greater than this protocols provide. Work in this regard, however, is outside the scope of this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Reeder & Gudmundsson Expires April 2000 [Page 4] INTERNET-DRAFT 3DES-EDE for USM October 1999 2. Use of Password-to-Key Algorithm with 3DES-EDE A set of sample code fragments given in the USM document demonstrate the password-to-key algorithm which can be used to map a password to a privacy key using MD5 or SHA. 2.1 Chaining of the Password-to-Key Algorithm Some cryptographic algorithms may require keys that have a length greater than the that of the hash output used by the password-to-key algorithm. This will be the case, for example, with any user that defines usm3DESEDEPrivProtocol as its privacy protocol (described below in Section 6). To acquire the necessary number of key bits, the password-to-key algorithm may be chained using its own output as further input in order to generate an appropriate number of key bits. Chaining is described as follows. First, run the password-to-key algorithm with inputs of the passphrase and engineID as described in the USM document. This will output as many key bits as the hash algorithm used to implement the password-to-key algorithm. Secondly, run the password-to-key algorithm again with the previous output (instead of the passphrase) and the same engineID as inputs. Repeat this process as many times as necessary in order to generate the minimum number of key bits for the chosen privacy protocol. The outputs of each execution are concatenated into a single string of key bits. When this process results in more key bits than are necessary, only the most significant bits of the string should be used. For example, if password-to-key implemented with SHA creates a 40-octet string string for use as key bits, only the first 32 octets will be used for usm3DESEDEPrivProtocol. Chaining may be demonstrated using simplified pseudo-code as follows, let: Output_bits <-- P2K( Input_bits, EngineID ) where the string of key bits (Output_bits) is returned from the password-to-key (P2K) algorithm which takes a string of bits (Input_bits) and the engineID (EngineID) as inputs. One iteration of chaining, creating a localized key of twice the normal length is achieved as follows: Reeder & Gudmundsson Expires April 2000 [Page 5] INTERNET-DRAFT 3DES-EDE for USM October 1999 K1 <-- P2K( , ) K2 <-- P2K( K1, ) localized_key = K1 | K2 The next further iteration will pass K2 (instead of K1) and return K3. The iteration after that passes K3 and returns K4, etc. The results of all iterations (K1, K2, ..., Kn) are concatenated to form the localized key. Note that the engineID is the same for all iterations. An example of the results of a correct implementation is provided in Appendix B. 2.2 Password (P) versus Ku versus the localized key Kul It is important to note that using the chaining method confuses the simple relationship between the passphrase, Ku and the localized key, Kul described in the USM document. It is believed that this should pose no significant difficulty to for existing USM implementations, however. The password-to-key algorithm performs two actions. First, it derives Ku from P by expanding P to 1024 kilobytes and hashing the result. Second, it derives Kul from Ku by hashing a concatenation of Ku and engineID. This latter step constitutes the localization method. Normally, Ku is temporarily generated within the password-to-key algorithm only for use in generating Kul, and it is expected that Ku will be discarded after this use. When the password-to-key algorithm is chained as described in Section 2.1, the final string of key bits output is no longer directly derived from P through Ku. Further there is no longer a one-to-one mapping between P and Ku, and from Ku to Kul. Nonetheless, the cryptographic mixing and uniqifying function provided by chaining the password-to-key algorithm serves the same purpose as a single use of the password-to-key algorithm. Alternatives to the chaining method might require the password-to-key algorithm to take an input indicating the number of key bits desired, allowing the algorithm to perform the entire chaining operation (or some other pseudo-random number generation technique). The benefits of chaining the password-to-key algorithm, effectively using it "as is," include the following: Reeder & Gudmundsson Expires April 2000 [Page 6] INTERNET-DRAFT 3DES-EDE for USM October 1999 - Should be simpler for existing implementations to adapt to the longer 3DES-EDE key length with a minimum of changes. - No need to document and define a choice between the existing password-to-key algorithm and some new algorithm. The drawbacks of the described chaining method include: - The notion of Ku and its relationship to P and Kul is confused. - Network management stations that insist on storing Ku will have to store the passphrase (P) instead. Note that storing P poses the same security risks as storing Ku. - A new algorithm could be optimized to save at least one hashing operation per chaining cycle. 3. Use of SNMP-USER-BASED-SM-3DES-MIB MIB Module The current purpose of the SNMP-USER-BASED-SM-3DES-MIB MIB module is simply to define the OBJECT-IDENTITY usm3DESEDEPrivProtocol. This adds to but does not change the { snmpModules snmpFrameworkMIB } MIB module [RFC2571] by naming a new privacy protocol. This naming takes place within the context of the USM { snmpModules snmpUsmMIB } MIB module where other privacy protocols have previously been defined. When the 3DES-EDE privacy protocol is used, a size of SIZE(0 | 64) is recommended for use with the following OBJECT-TYPEs: { usmUserEntry usmUserPrivKeyChange } { usmUserEntry usmUserOwnPrivKeyChange }. Reeder & Gudmundsson Expires April 2000 [Page 7] INTERNET-DRAFT 3DES-EDE for USM October 1999 4. Definitions Reeder & Gudmundsson Expires April 2000 [Page 8] INTERNET-DRAFT 3DES-EDE for USM October 1999 SNMP-USER-BASED-SM-3DES-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, snmpModules FROM SNMPv2-SMI AutonomousType FROM SNMPv2-TC snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; snmpUsmMIB MODULE-IDENTITY LAST-UPDATED "9910060000Z" -- 06 October 1999, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In msg body: subscribe snmpv3 Chair: Russ Mundy NAI Labs postal: 3060 Washington Rd Glenwood MD 21738 USA email: mundy@tislabs.com phone: +1-443-259-2307 Co-editor: David Reeder NAI Labs postal: 3060 Washington Road (Route 97) Glenwood, MD 21738 USA email: dreeder@tislabs.com phone: +1-443-259-2348 Co-editor: Olafur Gudmundsson NAI Labs postal: 3060 Washington Road (Route 97) Glenwood, MD 21738 USA email: ogud@tislabs.com phone: +1-443-259-2389 " DESCRIPTION "Extension to the SNMP User-based Security Model to support Triple-DES EDE in 'Outside' CBC (cipher-block chaining) Mode. " -- Revision history Reeder & Gudmundsson Expires April 2000 [Page 9] INTERNET-DRAFT 3DES-EDE for USM October 1999 REVISION "9910060000Z" -- 06 October 1999, midnight DESCRIPTION "Initial version, published as an Internet Draft." ::= { snmpModules 15 } -- Identification of Privacy Protocols ******************************* -- Note: { snmpPrivProtocols 1 } through { snmpPrivProtocols 2 } -- are defined in USM. usm3DESEDEPrivProtocol OBJECT-IDENTITY STATUS current DESCRIPTION "The 3DES-EDE Symmetric Encryption Protocol." REFERENCE "- Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 46-3, (1999, pending approval). Will supersede FIPS Publication 46-2. - Data Encryption Algorithm, American National Standards Institute. ANSI X3.92-1981, (December, 1980). - DES Modes of Operation, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 81, (December, 1980). - Data Encryption Algorithm - Modes of Operation, American National Standards Institute. ANSI X3.106-1983, (May 1983). " ::= { snmpPrivProtocols 3 } END Reeder & Gudmundsson Expires April 2000 [Page 10] INTERNET-DRAFT 3DES-EDE for USM October 1999 5. 3DES-EDE Symmetric Encryption Protocol This section describes the 3DES-EDE Symmetric Encryption Protocol. This protocol is an optional privacy protocol defined for use with the User-based Security Model. This protocol is identified by usm3DESEDEPrivProtocol. Over time, other privacy protocols may be defined either as a replacement of this protocol or in addition to this protocol. 5.1. Mechanisms - In support of data confidentiality, an encryption algorithm is required. An appropriate portion of the message is encrypted prior to being transmitted. The User-based Security Model specifies that the scopedPDU is the portion of the message that needs to be encrypted. - A secret value in combination with a timeliness value is used to create the en/decryption key and the initialization vector. The secret value is shared by all SNMP engines authorized to originate messages on behalf of the appropriate user. 5.1.1. Symmetric Encryption Protocol The Symmetric Encryption Protocol defined here provides support for data confidentiality. The designated portion of an SNMP message is encrypted and included as part of the message sent to the recipient. Two organizations have published specifications defining 3DES-EDE: the National Institute of Standards and Technology (NIST) [3DES-NIST] and the American National Standards Institute [3DES-ANSI]. There is a companion Modes of Operation specification for each definition ([DESO-NIST] and [DESO-ANSI], respectively). Additional information about 3DES-EDE may be found in [SCHNEIER95] (see Chapter 12 and Section 15.2). The NIST has published three additional documents that implementors may find useful. Although these documents were written with (single) DES in mind, they may be adapted to the use of 3DES-EDE. - There is a document with guidelines for implementing and using the DES, including functional specifications for the DES and its modes of operation [DESG-NIST]. Reeder & Gudmundsson Expires April 2000 [Page 11] INTERNET-DRAFT 3DES-EDE for USM October 1999 - There is a specification of a validation test suite for the DES [DEST-NIST]. The suite is designed to test all aspects of the DES and is useful for pinpointing specific problems. - There is a specification of a maintenance test for the DES [DESM-NIST]. The test utilizes a minimal amount of data and processing to test all components of the DES. It provides a simple yes-or-no indication of correct operation and is useful to run as part of an initialization step, e.g., when a computer re-boots. 5.1.1.1. 3DES-EDE Key and Initialization Vector 5.1.1.1.1. 3DES-EDE Key The first 24 octets of the 32-octet secret (private privacy key) are used as a 3DES-EDE key. Since 3DES-EDE uses only 168 bits, the Least Significant Bit in each octet is disregarded. The 3DES-EDE subkeys are obtained in the following manner. The 24-octet sequence is divided into three smaller 8-octet sequences where bytes 1 through 8 define K1, bytes 9 through 16 define K2, and bytes 17 through 24 define K3. For each 8-octet sequence, bytes are assigned to its respective subkey from left to right, beginning with the most significant byte and extending to the least significant byte. The three subkeys MUST be verified to be different. This may be done by checking that K1 is not equal to K2, and that K2 is not equal to K3. This will guarantee that at least two of the three subkeys are different. To verify that all three subkeys are different, it SHOULD be verified in addition that K1 is not equal to K3. The first set of checks verifies that the whole key contains at least 112 bits, the second check verifies that the whole key contains 168 bits. For a stronger key it is advised that both checks are performed. There are no published attacks against 3DES-EDE that take advantage of using "weak keys" for any of K1, K2 or K3. The list of weak keys includes the semi-weak and possibly-weak keys. It is generally accepted that 3DES-EDE is resistant to attacks using these keys, unlike single DES. Nonetheless, since the list of weak keys is small, it is advised that each of the subkeys SHOULD be checked for membership in this list. The complete list of known weak keys is given in [SCHNEIER95]. Reeder & Gudmundsson Expires April 2000 [Page 12] INTERNET-DRAFT 3DES-EDE for USM October 1999 The checks for difference and weakness noted above should be performed when the key is assigned. If any of the mandated tests fail, then the whole key MUST be discarded and an appropriate exception noted. 5.1.1.1.2. 3DES-EDE Initialization Vector The Initialization Vector for encryption is obtained using the following procedure. The last 8 octets of the 32-octet secret (private privacy key) are used as pre-IV. In order to ensure that the IV for two different packets encrypted by the same key, are not the same (i.e., the IV does not repeat over the lifetime of the private key) we need to "salt" the pre-IV with something unique per packet. An 8-octet string is used as the "salt". The concatenation of the generating SNMP engine's 32-bit snmpEngineBoots and a local 32-bit integer, that the encryption engine maintains, is input to the "salt". The 32-bit integer is initialized to an arbitrary value at boot time. This 32-bit arbitrary integer SHOULD be randomly determined when the engine boots. This is in keeping with the recommendations given in [RFC1750] and [PLAIN-ANALYSIS] with regard to the generation of random numbers and the use of predictable plaintext to speed a cryptographic search for a secret key. If the arbitrary integer cannot be chosen randomly, it is suggested instead that it SHOULD be derived from a hardware clock, or from system.sysUpTime.0 if a hardware clock is not available. These options are preferable to a simple counter as periodic use of it will not describe a direct sequence of natural numbers. The 32-bit snmpEngineBoots is converted to the first 4 octets (Most Significant Byte first) of our "salt". The 32-bit integer is then converted to the last 4 octets (Most Significant Byte first) of our "salt". To achieve effective bit spreading, the complete 8-octet "salt" value SHOULD be hashed using the usmUserAuthProtocol. This may be performed using the authentication algorithm directly, or by passing the "salt" as input the the password-to-key algorithm. The result of the hash is truncated to 8 octets. Reeder & Gudmundsson Expires April 2000 [Page 13] INTERNET-DRAFT 3DES-EDE for USM October 1999 The resulting "salt" is then XOR-ed with the pre-IV to obtain the IV. The 8-octet "salt" is then put into the privParameters field encoded as an OCTET STRING. Finally, the "salt" value is updated in preparation for future use, possibly using one of the methods just described. How exactly the value of the "salt" varies (and thus the value of the IV), is an implementation issue, as long as the measures are taken to avoid producing a duplicate IV over the lifetime of the private key. The "salt" must be placed in the privParameters field to enable the receiving entity to compute the correct IV and to decrypt the message. 5.1.1.2. Data Encryption The data to be encrypted is treated as sequence of octets. Its length should be an integral multiple of 8 - and if it is not, the data is padded at the end as necessary. The actual pad value is irrelevant. The data is encrypted using Triple DES Encryption - Decryption - Encryption (EDE) in Outside Cipher Block Chaining (CBC) mode. The plaintext is divided into 64-bit blocks. A single block of plaintext is encrypted by performing a sequence of encryption with the first key (K1), followed by decryption of the previous result with the second key (K2), finally followed by encryption of the previous result with the final key (K3). The plaintext for each block is XOR-ed with the ciphertext of the previous EDE encryption, the result is EDE encrypted and the output of the encryption is the ciphertext for the block. This procedure is repeated until there are no more plaintext blocks. For the very first block, the Initialization Vector (IV) is used instead of the ciphertext of the previous block. This is expressed more succinctly by the following formula: Ci = E_K3( D_K2( E_K1( Pi XOR C(i-1) ) ) ) Where plaintext block number i is XOR-ed with ciphertext block number (i-1), then encrypted with K1, decrypted with K2, and encrypted again with K3 to give ciphertext block number i. For the first EDE Reeder & Gudmundsson Expires April 2000 [Page 14] INTERNET-DRAFT 3DES-EDE for USM October 1999 encryption, C(i-1) is replaced by the IV. A more thorough explanation may be found in [SCHNEIER95]. 5.1.1.3. Data Decryption Before decryption, the encrypted data length is verified. If the length of the OCTET STRING to be decrypted is not an integral multiple of 8 octets, the decryption process is halted and an appropriate exception noted. When decrypting, the padding is ignored. The first ciphertext block is decrypted, the decryption output is XOR-ed with the Initialization Vector, and the result is the first plaintext block. A single ciphertext block is decrypted by performing a sequence of decryption with the third key (K3), followed by encryption of the previous result with the second key (K2), finally followed by decryption of the previous result with the first key (K1). This cycle of decryption - encryption - decryption (DED) is the reverse of the EDE sequence used for encryption. For each subsequent block, the ciphertext block is DED decrypted, then the decryption output is XOR-ed with the previous ciphertext block and the result is the plaintext block. This is expressed more succinctly by the following formula: Pi = C(i-1) XOR D_K1( E_K2( D_K3( Ci ) ) ) Where ciphertext block number i is decrypted with K3, then encrypted with K2, then decrypted with K1 and finally XOR-ed with ciphertext block (i-1) to give plaintext block number i. For the first ciphertext block of the series, C(i-1) is replaced by the IV. A more thorough explanation may be found in [SCHNEIER95]. Reeder & Gudmundsson Expires April 2000 [Page 15] INTERNET-DRAFT 3DES-EDE for USM October 1999 5.2. Elements of the 3DES-EDE Privacy Protocol This section contains definitions required to realize the privacy module defined by this memo. 5.2.1. Users Data en/decryption using this Symmetric Encryption Protocol makes use of a defined set of userNames. For any user on whose behalf a message must be en/decrypted at a particular SNMP engine, that SNMP engine must have knowledge of that user. An SNMP engine that wishes to communicate with another SNMP engine must also have knowledge of a user known to that SNMP engine, including knowledge of the applicable attributes of that user. A user and its attributes are defined as follows: An octet string representing the name of the user. A user's secret key to be used as input for the 3DES-EDE key and IV. The length of this key MUST be 32 octets. 5.2.2. msgAuthoritativeEngineID The msgAuthoritativeEngineID value contained in an authenticated message specifies the authoritative SNMP engine for that particular message (see the definition of SnmpEngineID in the SNMP Architecture document [RFC2571]). The user's (private) privacy key is normally different at each authoritative SNMP engine and so the snmpEngineID is used to select the proper key for the en/decryption process. Reeder & Gudmundsson Expires April 2000 [Page 16] INTERNET-DRAFT 3DES-EDE for USM October 1999 5.2.3. SNMP Messages Using this Privacy Protocol Messages using this privacy protocol carry a msgPrivacyParameters field as part of the msgSecurityParameters. For this protocol, the msgPrivacyParameters field is the serialized OCTET STRING representing the "salt" that was used to create the IV. 5.2.4. Services provided by the 3DES-EDE Privacy Module This section describes the inputs and outputs that the 3DES-EDE Privacy module expects and produces when the User-based Security module invokes the 3DES-EDE Privacy module for services. 5.2.4.1. Services for Encrypting Outgoing Data This 3DES-EDE privacy protocol assumes that the selection of the privKey is done by the caller and that the caller passes the secret key to be used. Upon completion the privacy module returns statusInformation and, if the encryption process was successful, the encryptedPDU and the msgPrivacyParameters encoded as an OCTET STRING. The abstract service primitive is: statusInformation = -- success of failure encryptData( IN encryptKey -- secret key for encryption IN dataToEncrypt -- data to encrypt (scopedPDU) OUT encryptedData -- encrypted data (encryptedPDU) OUT privParameters -- filled in by service provider ) The abstract data elements are: statusInformation An indication of the success or failure of the encryption process. In case of failure, it is an indication of the error. encryptKey The secret key to be used by the encryption algorithm. The length of this key MUST be 32 octets. dataToEncrypt The data that must be encrypted. encryptedData The encrypted data upon successful completion. privParameters Reeder & Gudmundsson Expires April 2000 [Page 17] INTERNET-DRAFT 3DES-EDE for USM October 1999 The privParameters encoded as an OCTET STRING. 5.2.4.2. Services for Decrypting Incoming Data This 3DES-EDE privacy protocol assumes that the selection of the privKey is done by the caller and that the caller passes the secret key to be used. Upon completion the privacy module returns statusInformation and, if the decryption process was successful, the scopedPDU in plain text. The abstract service primitive is: statusInformation = decryptData( IN decryptKey -- secret key for decryption IN privParameters -- as received on the wire IN encryptedData -- encrypted data (encryptedPDU) OUT decryptedData -- decrypted data (scopedPDU) ) The abstract data elements are: statusInformation An indication whether the data was successfully decrypted and if not an indication of the error. decryptKey The secret key to be used by the decryption algorithm. The length of this key MUST be 32 octets. encryptedData The data to be decrypted. decryptedData The decrypted data. privParameters The "salt" to be used to calculate the IV. Reeder & Gudmundsson Expires April 2000 [Page 18] INTERNET-DRAFT 3DES-EDE for USM October 1999 5.3. Elements of Procedure This section describes the procedures for the 3DES-EDE privacy protocol. 5.3.1. Processing an Outgoing Message This section describes the procedure followed by an SNMP engine whenever it must encrypt part of an outgoing message using the usm3DESEDEPrivProtocol. 1) The secret cryptKey is used to construct the 3DES-EDE encryption key, the "salt" and the 3DES-EDE pre-IV (from which the IV is computed as described in section 5.1.1.1.2). 2) The privParameters field is set to the serialization according to the rules in [RFC1906] of an OCTET STRING representing the the "salt" string. 3) The scopedPDU is encrypted (as described in section 5.1.1.2) and the encrypted data is serialized according to the rules in [RFC1906] as an OCTET STRING. 4) The serialized OCTET STRING representing the encrypted scopedPDU together with the privParameters and statusInformation indicating success is returned to the calling module. 5.3.2. Processing an Incoming Message This section describes the procedure followed by an SNMP engine whenever it must decrypt part of an incoming message using the usm3DESEDEPrivProtocol. 1) If the privParameters field is not an 8-octet OCTET STRING, then an error indication (decryptionError) is returned to the calling module. 2) The "salt" is extracted from the privParameters field. 3) The secret cryptKey and the "salt" are then used to construct the 3DES-EDE decryption key and pre-IV (from which the IV is computed as described in section 5.1.1.1.2). 4) The encryptedPDU is then decrypted (as described in section 5.1.1.3). Reeder & Gudmundsson Expires April 2000 [Page 19] INTERNET-DRAFT 3DES-EDE for USM October 1999 5) If the encryptedPDU cannot be decrypted, then an error indication (decryptionError) is returned to the calling module. 6) The decrypted scopedPDU and statusInformation indicating success are returned to the calling module. 6. Security Considerations This document fully adopts and expects enforcement of the details presented in the Security Considerations section of the document describing the User-based Security Model [RFC2574]. Insofar as the privacy protocol presented in this document is considered to be an improvement over existing SNMP privacy protocols, this document presents an alternative offering greater security for the SNMP architecture. 7. Acknowledgements The general structure of this document and some of the text in it was taken directly from the document describing the User-based Security Model. Many details and references specific to the strength and analysis of the Triple-DES cryptographic algorithm were initially adapted from the description of that algorithm given in documents generated by the IPSec Working Group concerning the Encapsulation Security Protocol [ESP-DESCBC][ESP-3DES]. 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Reeder & Gudmundsson Expires April 2000 [Page 20] INTERNET-DRAFT 3DES-EDE for USM October 1999 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 9. References [3DES-ANSI] Data Encryption Algorithm, American National Standards Institute. ANSI X9.52. [3DES-NIST] Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 46-3, (1999, pending approval). Will supersede FIPS Publication 46-2. http://csrc.nist.gov/fips/dfips46-3.pdf http://csrc.nist.gov/cryptval/des/fr990115.htm [DESG-NIST] Guidelines for Implementing and Using the NBS Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 74, (April, 1981). http://www.itl.nist.gov/fipspubs/fip74.htm [DESO-ANSI] Data Encryption Algorithm - Modes of Operation, American National Standards Institute. ANSI X3.106- 1983, (May 1983). [DESO-NIST] DES Modes of Operation, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 81, (December, 1980). http://www.itl.nist.gov/fipspubs/fip81.htm [DESM-NIST] Maintenance Testing for the Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-61, (August, 1980). [DEST-NIST] Validating the Correctness of Hardware Implementations of the NBS Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-20. Reeder & Gudmundsson Expires April 2000 [Page 21] INTERNET-DRAFT 3DES-EDE for USM October 1999 [ESP-DESCBC] Madson, C. and N. Dorswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998. [ESP-3DES] Doraswamy, N., Metzger, P., and Simpson, W.A., "The ESP Triple DES Transform", , July 1997. http://www.ietf.org/internet-drafts/draft-ietf- ipsec-ciph-des3-00.txt [IETF-CRYPTO] Schiller, J., "Cryptographic Algorithms for the IETF," , August 1999. http://web.mit.edu/network/sa/draft-ietf- saag-aes-ciph-00.txt [LOCALIZED-KEY] U. Blumenthal, N. C. Hien, B. Wijnen "Key Derivation for Network Management Applications" IEEE Network Magazine, April/May issue, 1997. [MIN-KEYLENGTH] Blaze, M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., and M. Wiener, "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", currently available at http://www.crypto.com/papers/keylength.ps http://www.crypto.com/papers/keylength.txt [PLAIN-ANALYSIS] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997. http://www.research.att.com/~smb/papers/probtxt.ps http://www.research.att.com/~smb/papers/probtxt.pdf [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. http://www.ietf.org/rfc/rfc1750.txt [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. Reeder & Gudmundsson Expires April 2000 [Page 22] INTERNET-DRAFT 3DES-EDE for USM October 1999 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [SCHNEIER95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 10. Editors' Addresses David Reeder NAI Labs 3060 Washington Road (Route 97) Glenwood, MD 21738 USA Phone: +1-443-259-2348 Email: dreeder@tislabs.com Olafur Gudmundsson NAI Labs 3060 Washington Road (Route 97) Glenwood, MD 21738 USA Phone: +1-443-259-2389 Email: ogud@tislabs.com Reeder & Gudmundsson Expires April 2000 [Page 23] INTERNET-DRAFT 3DES-EDE for USM October 1999 11. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Appendix A. SNMP engine Installation Parameters Using 3DES-EDE In order to use the 3DES-EDE privacy protocol in place of the CBC- DES, the SNMP engine may use the following usmUserEntry in the initial configuration of the usmUserTable: Reeder & Gudmundsson Expires April 2000 [Page 24] INTERNET-DRAFT 3DES-EDE for USM October 1999 privacy support --------------- usmUserEngineID localEngineID usmUserName "initial" usmUserSecurityName "initial" usmUserCloneFrom ZeroDotZero usmUserAuthProtocol usmHMACMD5AuthProtocol usmUserAuthKeyChange "" usmUserOwnAuthKeyChange "" usmUserPrivProtocol usm3DESEDEPrivProtocol usmUserPrivKeyChange "" usmUserOwnPrivKeyChange "" usmUserPublic "" usmUserStorageType anyValidStorageType usmUserStatus active Templates instantiated as initial usmUserEntries for use as clone- from users have a similar format. The usmUserPrivProtocol of usm3DESEDEPrivProtocol replaces usmDESPrivProtocol. B. Password-to-Key Chaining Sample Results B.1. Password-to-Key Chaining Sample Results using MD5 [Please Note: This note will be removed when the following values have been double-checked by a third party.] The following shows a sample output of the password-to-key algorithm for a 32-octet key using MD5. The password used in this example is "maplesyrup". The first 16 octets (bytes 1 through 16) are generated by password-to-key algorithm with the pasphrase as input. The second 16 octets (bytes 17 through 32) are generated from the password-to- key algorithm with the first 16 octets as input. Each invocation of the password-to-key algorithm in the generation of a string of key bits uses the same engineID. In this example the engineID is: '00 00 00 00 00 00 00 00 00 00 00 02'H The final output of the password-to-key algorithm, used twice as described above, produces a 32-octet localized key of: Reeder & Gudmundsson Expires April 2000 [Page 25] INTERNET-DRAFT 3DES-EDE for USM October 1999 '52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b 79 ef f4 4a 90 65 0e e0 a3 a4 0a bf ac 5a cc 12'H B.2. Password-to-Key Chaining Sample Results using SHA [Please Note: This note will be removed when the following values have been double-checked by a third party.] The following shows a sample output of the password-to-key algorithm for a 40-octet key using SHA. The password used in this example is "maplesyrup". The first 20 octets (bytes 1 through 20) are generated by password-to-key algorithm with the pasphrase as input. The second 20 octets (bytes 21 through 40) are generated from the password-to- key algorithm with the first 20 octets as input. Each invocation of the password-to-key algorithm in the generation of a string of key bits uses the same engineID. In this example the engineID is: '00 00 00 00 00 00 00 00 00 00 00 02'H The final output of the password-to-key algorithm, used twice as described above, produces a 40-octet localized key of: '66 95 fe bc 92 88 e3 62 82 23 5f c7 15 1f 12 84 97 b3 8f 3f 9b 8b 6d 78 93 6b a6 e7 d1 9d fd 9c d2 d5 06 55 47 74 3f b5'H C. Sample keyChange Results for 32-octet keys C.1. Sample keyChange Results for 32-octet Keys Using MD5 [Please Note: This section is incomplete.] Let us assume that a user has a current password of "maplesyrup" as in section B.1. and let us also assume the snmpEngineID of 12 octets: '00 00 00 00 00 00 00 00 00 00 00 02'H If we now want to change the password to "newsyrup", then we first calculate the localized key for the new password. It is as follows: 87 02 1d 7b d9 d1 01 ba 05 ea 6e 3b f9 d9 bd 4a 70 29 8b 75 7c 91 99 b6 a8 fb f3 93 7b e0 54 XX'H Reeder & Gudmundsson Expires April 2000 [Page 26] INTERNET-DRAFT 3DES-EDE for USM October 1999 Then, using the following value as a placeholder for the random value: '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H we compute a keyChange value of: '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX'H C.2. Sample keyChange Results for 32-octet Keys Using SHA [Please Note: This section is incomplete.] Let us assume that a user has a current password of "maplesyrup" as in section B.2. and let us also assume the snmpEngineID of 12 octets: '00 00 00 00 00 00 00 00 00 00 00 02'H If we now want to change the password to "newsyrup", then we first calculate the localized key for the new password. It is as follows: 78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63 91 f1 cd 25 97 74 35 55 f9 fc f9 4a c3 e7 e9 22'H Note that this value has been truncated from to 32 octets. Then, using the following value as a placeholder for the random value: '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H we compute a keyChange value of: '00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX'H Reeder & Gudmundsson Expires April 2000 [Page 27] INTERNET-DRAFT 3DES-EDE for USM October 1999 D.1. Strength of 3DES-EDE and Known Attacks Although 3DES-EDE has an effective key length of 168 bits (56 * 3), it may be attacked with brute force as though its key were only 112 bits via the meet-in-the-middle attack [MULTI-CRYPT]. Even so, this number of key bits is greater than the minimum currently recommended by expert cryptanalysts, although it is still somewhat short of the most conservative estimates [MIN-KEYLENGTH]. It has been demonstrated that a DES key may be recovered by differential cryptanalysis [DIFF-ANALYSIS] and linear cryptanalysis [LIN-ANALYSIS] after collecting a minimum of 2^47 and 2^43 plaintext/ciphertext pairs, respectively. 3DES-EDE is susceptible to the same attacks given the same number of plaintext/ciphertext pairs [DESMODES]. Thus the primary value of 3DES-EDE over DES is not so much that it is more resistant to published theoretical attacks, but that it is apparently more resistant to brute force attacks. [DIFF-ANALYSIS] also demonstrates a rare attack which requires only 2^33 plaintext/ciphertext pairs. For this reason, it is recommended that keys are changed after no more than 2^32 block encryptions. Finally, as has been demonstrated in the context of IP Security, it is often a simpler and highly successful technique to guess at the contents of an encrypted block, and use these guesses in combination with differential or linear cryptananalysis to increase the probability of recovering the secret key [PLAIN-ANALYSIS]. SNMP has possible vulnerabilities in this regard as the following PDU fields are likely to be easily predictable by a passive observer: - PDU Type - Request ID - Error Status, Error Index - Non-Repeaters, Max-Repetition Implementations may be classified by the species of their ASN.1 encoding engines, just as network hosts and routers may be classified by the species of their TCP/IP stack. This in combination with knowledge of common PDU exchanges makes the prediction of PDU fields a realistic endeavor. Suggestions in [PLAIN-ANALYSIS] for closing these sorts of security holes include: Reeder & Gudmundsson Expires April 2000 [Page 28] INTERNET-DRAFT 3DES-EDE for USM October 1999 * Starting counters at random values, * Replacing predictable values with random values when they are already known by the receiver, * Keyed compression. Concerns of this nature, however, are beyond the scope of this document. D.2. Further References [DESMODES] Biham, E., "On Modes of Operation," Fast Software Encryption, Cambridge Security Workship Proceedings, Springer-Verlag, 1994, pp. 116-120. [DIFF-ANALYSIS] Biham, E., and Shamir, A., "Differential Cryptanalysis of the Data Encryption Standard", Berlin: Springer-Verlag, 1993. [LIN-ANALYSIS] Matsui, M., "Linear Cryptanalysis method for DES Cipher," Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag, 1994. [MULTI-CRYPT] Merkle, R.C., and Hellman, M., "On the Security of Multiple Encryption", Communications of the ACM, v. 24 n. 7, 1981, pp. 465-467. Reeder & Gudmundsson Expires April 2000 [Page 29]