-- extracted from draft-reeder-snmpv3-usm-3desede-00.txt -- at Mon Nov 15 17:11:25 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 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 -- -- 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: -- 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: -- '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 -- 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 -- 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: -- * 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.