[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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
                <draft-reeder-snmpv3-usm-3desede-00.txt>

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( <passphrase>, <engine_id> )
           K2 <-- P2K( K1,           <engine_id> )

           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 <K1, K2, K3> 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:

   <userName>
     An octet string representing the name of the user.

   <privKey>
     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", <draft-ietf-ipsec-ciph-
                     des3-00.txt>, July 1997.
                     http://www.ietf.org/internet-drafts/draft-ietf-
                     ipsec-ciph-des3-00.txt

   [IETF-CRYPTO]     Schiller, J., "Cryptographic Algorithms for the
                     IETF," <draft-ietf-saag-aes-ciph-00.txt>, 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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/