snmp: T3606: Install MIBs into well known location

FRR also expects the MIBs in /usr/share/snmp/mibs

1 files changed, 912 insertions, 0 deletions

diff --git a/mibs/SNMP-USER-BASED-SM-MIB.txt b/mibs/SNMP-USER-BASED-SM-MIB.txt
new file mode 100644
index 000000000..3b714030c
--- /dev/null
+++ b/mibs/SNMP-USER-BASED-SM-MIB.txt
@@ -0,0 +1,912 @@
+SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+    MODULE-IDENTITY, OBJECT-TYPE,
+    OBJECT-IDENTITY,
+    snmpModules, Counter32                FROM SNMPv2-SMI
+    TEXTUAL-CONVENTION, TestAndIncr,
+    RowStatus, RowPointer,
+    StorageType, AutonomousType           FROM SNMPv2-TC
+    MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF
+    SnmpAdminString, SnmpEngineID,
+    snmpAuthProtocols, snmpPrivProtocols  FROM SNMP-FRAMEWORK-MIB;
+
+snmpUsmMIB MODULE-IDENTITY
+    LAST-UPDATED "200210160000Z"            -- 16 Oct 2002, 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
+                              Network Associates Laboratories
+                  postal:     15204 Omega Drive, Suite 300
+                              Rockville, MD 20850-4601
+                              USA
+                  email:      mundy@tislabs.com
+
+                  phone:      +1 301-947-7107
+
+                  Co-Chair:   David Harrington
+                              Enterasys Networks
+                  Postal:     35 Industrial Way
+                              P. O. Box 5004
+                              Rochester, New Hampshire 03866-5005
+                              USA
+                  EMail:      dbh@enterasys.com
+                  Phone:      +1 603-337-2614
+
+                  Co-editor   Uri Blumenthal
+                              Lucent Technologies
+                  postal:     67 Whippany Rd.
+                              Whippany, NJ 07981
+                              USA
+                  email:      uri@lucent.com
+                  phone:      +1-973-386-2163
+
+                  Co-editor:  Bert Wijnen
+                              Lucent Technologies
+                  postal:     Schagen 33
+                              3461 GL Linschoten
+                              Netherlands
+                  email:      bwijnen@lucent.com
+                  phone:      +31-348-480-685
+                 "
+    DESCRIPTION  "The management information definitions for the
+                  SNMP User-based Security Model.
+
+                  Copyright (C) The Internet Society (2002). This
+                  version of this MIB module is part of RFC 3414;
+                  see the RFC itself for full legal notices.
+                 "
+--  Revision history
+
+    REVISION     "200210160000Z"          -- 16 Oct 2002, midnight
+    DESCRIPTION  "Changes in this revision:
+                  - Updated references and contact info.
+                  - Clarification to usmUserCloneFrom DESCRIPTION
+                    clause
+                  - Fixed 'command responder' into 'command generator'
+                    in last para of DESCRIPTION clause of
+                    usmUserTable.
+                  This revision published as RFC3414.
+                 "
+    REVISION     "199901200000Z"          -- 20 Jan 1999, midnight
+    DESCRIPTION  "Clarifications, published as RFC2574"
+
+    REVISION     "199711200000Z"          -- 20 Nov 1997, midnight
+    DESCRIPTION  "Initial version, published as RFC2274"
+    ::= { snmpModules 15 }
+
+-- Administrative assignments ****************************************
+
+usmMIBObjects     OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
+usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
+
+-- Identification of Authentication and Privacy Protocols ************
+
+usmNoAuthProtocol OBJECT-IDENTITY
+    STATUS        current
+    DESCRIPTION  "No Authentication Protocol."
+    ::= { snmpAuthProtocols 1 }
+
+usmHMACMD5AuthProtocol OBJECT-IDENTITY
+    STATUS        current
+    DESCRIPTION  "The HMAC-MD5-96 Digest Authentication Protocol."
+    REFERENCE    "- H. Krawczyk, M. Bellare, R. Canetti HMAC:
+                    Keyed-Hashing for Message Authentication,
+                    RFC2104, Feb 1997.
+                  - Rivest, R., Message Digest Algorithm MD5, RFC1321.
+                 "
+    ::= { snmpAuthProtocols 2 }
+
+usmHMACSHAAuthProtocol OBJECT-IDENTITY
+    STATUS        current
+    DESCRIPTION  "The HMAC-SHA-96 Digest Authentication Protocol."
+    REFERENCE    "- H. Krawczyk, M. Bellare, R. Canetti, HMAC:
+                    Keyed-Hashing for Message Authentication,
+                    RFC2104, Feb 1997.
+                  - Secure Hash Algorithm. NIST FIPS 180-1.
+                 "
+    ::= { snmpAuthProtocols 3 }
+
+usmNoPrivProtocol OBJECT-IDENTITY
+    STATUS        current
+    DESCRIPTION  "No Privacy Protocol."
+    ::= { snmpPrivProtocols 1 }
+
+usmDESPrivProtocol OBJECT-IDENTITY
+    STATUS        current
+    DESCRIPTION  "The CBC-DES Symmetric Encryption Protocol."
+    REFERENCE    "- Data Encryption Standard, National Institute of
+                    Standards and Technology.  Federal Information
+                    Processing Standard (FIPS) Publication 46-1.
+
+                    Supersedes FIPS Publication 46,
+                    (January, 1977; reaffirmed January, 1988).
+
+                  - 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 2 }
+
+-- Textual Conventions ***********************************************
+
+KeyChange ::=     TEXTUAL-CONVENTION
+   STATUS         current
+   DESCRIPTION
+         "Every definition of an object with this syntax must identify
+          a protocol P, a secret key K, and a hash algorithm H
+          that produces output of L octets.
+
+          The object's value is a manager-generated, partially-random
+          value which, when modified, causes the value of the secret
+          key K, to be modified via a one-way function.
+
+          The value of an instance of this object is the concatenation
+          of two components: first a 'random' component and then a
+          'delta' component.
+
+          The lengths of the random and delta components
+          are given by the corresponding value of the protocol P;
+          if P requires K to be a fixed length, the length of both the
+          random and delta components is that fixed length; if P
+          allows the length of K to be variable up to a particular
+          maximum length, the length of the random component is that
+          maximum length and the length of the delta component is any
+          length less than or equal to that maximum length.
+          For example, usmHMACMD5AuthProtocol requires K to be a fixed
+          length of 16 octets and L - of 16 octets.
+          usmHMACSHAAuthProtocol requires K to be a fixed length of
+          20 octets and L - of 20 octets. Other protocols may define
+          other sizes, as deemed appropriate.
+
+          When a requester wants to change the old key K to a new
+          key keyNew on a remote entity, the 'random' component is
+          obtained from either a true random generator, or from a
+          pseudorandom generator, and the 'delta' component is
+          computed as follows:
+
+           - a temporary variable is initialized to the existing value
+             of K;
+           - if the length of the keyNew is greater than L octets,
+             then:
+              - the random component is appended to the value of the
+                temporary variable, and the result is input to the
+                the hash algorithm H to produce a digest value, and
+                the temporary variable is set to this digest value;
+              - the value of the temporary variable is XOR-ed with
+                the first (next) L-octets (16 octets in case of MD5)
+                of the keyNew to produce the first (next) L-octets
+                (16 octets in case of MD5) of the 'delta' component.
+              - the above two steps are repeated until the unused
+                portion of the keyNew component is L octets or less,
+           - the random component is appended to the value of the
+             temporary variable, and the result is input to the
+             hash algorithm H to produce a digest value;
+           - this digest value, truncated if necessary to be the same
+             length as the unused portion of the keyNew, is XOR-ed
+             with the unused portion of the keyNew to produce the
+             (final portion of the) 'delta' component.
+
+           For example, using MD5 as the hash algorithm H:
+
+              iterations = (lenOfDelta - 1)/16; /* integer division */
+              temp = keyOld;
+              for (i = 0; i < iterations; i++) {
+                  temp = MD5 (temp || random);
+                  delta[i*16 .. (i*16)+15] =
+                         temp XOR keyNew[i*16 .. (i*16)+15];
+              }
+              temp = MD5 (temp || random);
+              delta[i*16 .. lenOfDelta-1] =
+                     temp XOR keyNew[i*16 .. lenOfDelta-1];
+
+          The 'random' and 'delta' components are then concatenated as
+          described above, and the resulting octet string is sent to
+          the recipient as the new value of an instance of this object.
+
+          At the receiver side, when an instance of this object is set
+          to a new value, then a new value of K is computed as follows:
+
+           - a temporary variable is initialized to the existing value
+             of K;
+           - if the length of the delta component is greater than L
+             octets, then:
+              - the random component is appended to the value of the
+                temporary variable, and the result is input to the
+                hash algorithm H to produce a digest value, and the
+                temporary variable is set to this digest value;
+              - the value of the temporary variable is XOR-ed with
+                the first (next) L-octets (16 octets in case of MD5)
+                of the delta component to produce the first (next)
+                L-octets (16 octets in case of MD5) of the new value
+                of K.
+              - the above two steps are repeated until the unused
+                portion of the delta component is L octets or less,
+           - the random component is appended to the value of the
+             temporary variable, and the result is input to the
+             hash algorithm H to produce a digest value;
+           - this digest value, truncated if necessary to be the same
+             length as the unused portion of the delta component, is
+             XOR-ed with the unused portion of the delta component to
+             produce the (final portion of the) new value of K.
+
+           For example, using MD5 as the hash algorithm H:
+
+              iterations = (lenOfDelta - 1)/16; /* integer division */
+              temp = keyOld;
+              for (i = 0; i < iterations; i++) {
+                  temp = MD5 (temp || random);
+                  keyNew[i*16 .. (i*16)+15] =
+                         temp XOR delta[i*16 .. (i*16)+15];
+              }
+              temp = MD5 (temp || random);
+              keyNew[i*16 .. lenOfDelta-1] =
+                     temp XOR delta[i*16 .. lenOfDelta-1];
+
+          The value of an object with this syntax, whenever it is
+          retrieved by the management protocol, is always the zero
+          length string.
+
+          Note that the keyOld and keyNew are the localized keys.
+
+          Note that it is probably wise that when an SNMP entity sends
+          a SetRequest to change a key, that it keeps a copy of the old
+          key until it has confirmed that the key change actually
+          succeeded.
+         "
+    SYNTAX       OCTET STRING
+
+-- Statistics for the User-based Security Model **********************
+
+usmStats         OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
+
+usmStatsUnsupportedSecLevels OBJECT-TYPE
+    SYNTAX       Counter32
+    MAX-ACCESS   read-only
+    STATUS       current
+    DESCRIPTION "The total number of packets received by the SNMP
+                 engine which were dropped because they requested a
+                 securityLevel that was unknown to the SNMP engine
+                 or otherwise unavailable.
+                "
+    ::= { usmStats 1 }
+
+usmStatsNotInTimeWindows OBJECT-TYPE
+    SYNTAX       Counter32
+    MAX-ACCESS   read-only
+    STATUS       current
+    DESCRIPTION "The total number of packets received by the SNMP
+                 engine which were dropped because they appeared
+                 outside of the authoritative SNMP engine's window.
+                "
+    ::= { usmStats 2 }
+
+usmStatsUnknownUserNames OBJECT-TYPE
+    SYNTAX       Counter32
+    MAX-ACCESS   read-only
+    STATUS       current
+    DESCRIPTION "The total number of packets received by the SNMP
+                 engine which were dropped because they referenced a
+                 user that was not known to the SNMP engine.
+                "
+    ::= { usmStats 3 }
+
+usmStatsUnknownEngineIDs OBJECT-TYPE
+    SYNTAX       Counter32
+    MAX-ACCESS   read-only
+    STATUS       current
+    DESCRIPTION "The total number of packets received by the SNMP
+                 engine which were dropped because they referenced an
+                 snmpEngineID that was not known to the SNMP engine.
+                "
+    ::= { usmStats 4 }
+
+usmStatsWrongDigests OBJECT-TYPE
+    SYNTAX       Counter32
+    MAX-ACCESS   read-only
+    STATUS       current
+    DESCRIPTION "The total number of packets received by the SNMP
+                 engine which were dropped because they didn't
+                 contain the expected digest value.
+                "
+    ::= { usmStats 5 }
+
+usmStatsDecryptionErrors OBJECT-TYPE
+    SYNTAX       Counter32
+    MAX-ACCESS   read-only
+    STATUS       current
+    DESCRIPTION "The total number of packets received by the SNMP
+                 engine which were dropped because they could not be
+                 decrypted.
+                "
+    ::= { usmStats 6 }
+
+-- The usmUser Group ************************************************
+
+usmUser          OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
+
+usmUserSpinLock  OBJECT-TYPE
+    SYNTAX       TestAndIncr
+    MAX-ACCESS   read-write
+    STATUS       current
+    DESCRIPTION "An advisory lock used to allow several cooperating
+                 Command Generator Applications to coordinate their
+                 use of facilities to alter secrets in the
+                 usmUserTable.
+                "
+    ::= { usmUser 1 }
+
+-- The table of valid users for the User-based Security Model ********
+
+usmUserTable     OBJECT-TYPE
+    SYNTAX       SEQUENCE OF UsmUserEntry
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "The table of users configured in the SNMP engine's
+                 Local Configuration Datastore (LCD).
+
+                 To create a new user (i.e., to instantiate a new
+                 conceptual row in this table), it is recommended to
+                 follow this procedure:
+
+                   1)  GET(usmUserSpinLock.0) and save in sValue.
+
+                   2)  SET(usmUserSpinLock.0=sValue,
+                           usmUserCloneFrom=templateUser,
+                           usmUserStatus=createAndWait)
+                       You should use a template user to clone from
+                       which has the proper auth/priv protocol defined.
+
+                 If the new user is to use privacy:
+
+                   3)  generate the keyChange value based on the secret
+                       privKey of the clone-from user and the secret key
+                       to be used for the new user. Let us call this
+                       pkcValue.
+                   4)  GET(usmUserSpinLock.0) and save in sValue.
+                   5)  SET(usmUserSpinLock.0=sValue,
+                           usmUserPrivKeyChange=pkcValue
+                           usmUserPublic=randomValue1)
+                   6)  GET(usmUserPulic) and check it has randomValue1.
+                       If not, repeat steps 4-6.
+
+                 If the new user will never use privacy:
+
+                   7)  SET(usmUserPrivProtocol=usmNoPrivProtocol)
+
+                 If the new user is to use authentication:
+
+                   8)  generate the keyChange value based on the secret
+                       authKey of the clone-from user and the secret key
+                       to be used for the new user. Let us call this
+                       akcValue.
+                   9)  GET(usmUserSpinLock.0) and save in sValue.
+                   10) SET(usmUserSpinLock.0=sValue,
+                           usmUserAuthKeyChange=akcValue
+                           usmUserPublic=randomValue2)
+                   11) GET(usmUserPulic) and check it has randomValue2.
+                       If not, repeat steps 9-11.
+
+                 If the new user will never use authentication:
+
+                   12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
+
+                 Finally, activate the new user:
+
+                   13) SET(usmUserStatus=active)
+
+                 The new user should now be available and ready to be
+                 used for SNMPv3 communication. Note however that access
+                 to MIB data must be provided via configuration of the
+                 SNMP-VIEW-BASED-ACM-MIB.
+
+                 The use of usmUserSpinlock is to avoid conflicts with
+                 another SNMP command generator application which may
+                 also be acting on the usmUserTable.
+                "
+    ::= { usmUser 2 }
+
+usmUserEntry     OBJECT-TYPE
+    SYNTAX       UsmUserEntry
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "A user configured in the SNMP engine's Local
+                 Configuration Datastore (LCD) for the User-based
+                 Security Model.
+                "
+    INDEX       { usmUserEngineID,
+                  usmUserName
+                }
+    ::= { usmUserTable 1 }
+
+UsmUserEntry ::= SEQUENCE
+    {
+        usmUserEngineID         SnmpEngineID,
+        usmUserName             SnmpAdminString,
+        usmUserSecurityName     SnmpAdminString,
+        usmUserCloneFrom        RowPointer,
+        usmUserAuthProtocol     AutonomousType,
+        usmUserAuthKeyChange    KeyChange,
+        usmUserOwnAuthKeyChange KeyChange,
+        usmUserPrivProtocol     AutonomousType,
+        usmUserPrivKeyChange    KeyChange,
+        usmUserOwnPrivKeyChange KeyChange,
+        usmUserPublic           OCTET STRING,
+        usmUserStorageType      StorageType,
+        usmUserStatus           RowStatus
+    }
+
+usmUserEngineID  OBJECT-TYPE
+    SYNTAX       SnmpEngineID
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "An SNMP engine's administratively-unique identifier.
+
+                 In a simple agent, this value is always that agent's
+                 own snmpEngineID value.
+
+                 The value can also take the value of the snmpEngineID
+                 of a remote SNMP engine with which this user can
+                 communicate.
+                "
+    ::= { usmUserEntry 1 }
+
+usmUserName      OBJECT-TYPE
+    SYNTAX       SnmpAdminString (SIZE(1..32))
+    MAX-ACCESS   not-accessible
+    STATUS       current
+    DESCRIPTION "A human readable string representing the name of
+                 the user.
+
+                 This is the (User-based Security) Model dependent
+                 security ID.
+                "
+    ::= { usmUserEntry 2 }
+
+usmUserSecurityName OBJECT-TYPE
+    SYNTAX       SnmpAdminString
+    MAX-ACCESS   read-only
+    STATUS       current
+    DESCRIPTION "A human readable string representing the user in
+                 Security Model independent format.
+
+                 The default transformation of the User-based Security
+                 Model dependent security ID to the securityName and
+                 vice versa is the identity function so that the
+                 securityName is the same as the userName.
+                "
+    ::= { usmUserEntry 3 }
+
+usmUserCloneFrom OBJECT-TYPE
+    SYNTAX       RowPointer
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "A pointer to another conceptual row in this
+                 usmUserTable.  The user in this other conceptual
+                 row is called the clone-from user.
+
+                 When a new user is created (i.e., a new conceptual
+                 row is instantiated in this table), the privacy and
+                 authentication parameters of the new user must be
+                 cloned from its clone-from user. These parameters are:
+                   - authentication protocol (usmUserAuthProtocol)
+                   - privacy protocol (usmUserPrivProtocol)
+                 They will be copied regardless of what the current
+                 value is.
+
+                 Cloning also causes the initial values of the secret
+                 authentication key (authKey) and the secret encryption
+
+                 key (privKey) of the new user to be set to the same
+                 values as the corresponding secrets of the clone-from
+                 user to allow the KeyChange process to occur as
+                 required during user creation.
+
+                 The first time an instance of this object is set by
+                 a management operation (either at or after its
+                 instantiation), the cloning process is invoked.
+                 Subsequent writes are successful but invoke no
+                 action to be taken by the receiver.
+                 The cloning process fails with an 'inconsistentName'
+                 error if the conceptual row representing the
+                 clone-from user does not exist or is not in an active
+                 state when the cloning process is invoked.
+
+                 When this object is read, the ZeroDotZero OID
+                 is returned.
+                "
+    ::= { usmUserEntry 4 }
+
+usmUserAuthProtocol OBJECT-TYPE
+    SYNTAX       AutonomousType
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "An indication of whether messages sent on behalf of
+                 this user to/from the SNMP engine identified by
+                 usmUserEngineID, can be authenticated, and if so,
+                 the type of authentication protocol which is used.
+
+                 An instance of this object is created concurrently
+                 with the creation of any other object instance for
+                 the same user (i.e., as part of the processing of
+                 the set operation which creates the first object
+                 instance in the same conceptual row).
+
+                 If an initial set operation (i.e. at row creation time)
+                 tries to set a value for an unknown or unsupported
+                 protocol, then a 'wrongValue' error must be returned.
+
+                 The value will be overwritten/set when a set operation
+                 is performed on the corresponding instance of
+                 usmUserCloneFrom.
+
+                 Once instantiated, the value of such an instance of
+                 this object can only be changed via a set operation to
+                 the value of the usmNoAuthProtocol.
+
+                 If a set operation tries to change the value of an
+
+                 existing instance of this object to any value other
+                 than usmNoAuthProtocol, then an 'inconsistentValue'
+                 error must be returned.
+
+                 If a set operation tries to set the value to the
+                 usmNoAuthProtocol while the usmUserPrivProtocol value
+                 in the same row is not equal to usmNoPrivProtocol,
+                 then an 'inconsistentValue' error must be returned.
+                 That means that an SNMP command generator application
+                 must first ensure that the usmUserPrivProtocol is set
+                 to the usmNoPrivProtocol value before it can set
+                 the usmUserAuthProtocol value to usmNoAuthProtocol.
+                "
+    DEFVAL      { usmNoAuthProtocol }
+    ::= { usmUserEntry 5 }
+
+usmUserAuthKeyChange OBJECT-TYPE
+    SYNTAX       KeyChange   -- typically (SIZE (0 | 32)) for HMACMD5
+                             -- typically (SIZE (0 | 40)) for HMACSHA
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "An object, which when modified, causes the secret
+                 authentication key used for messages sent on behalf
+                 of this user to/from the SNMP engine identified by
+                 usmUserEngineID, to be modified via a one-way
+                 function.
+
+                 The associated protocol is the usmUserAuthProtocol.
+                 The associated secret key is the user's secret
+                 authentication key (authKey). The associated hash
+                 algorithm is the algorithm used by the user's
+                 usmUserAuthProtocol.
+
+                 When creating a new user, it is an 'inconsistentName'
+                 error for a set operation to refer to this object
+                 unless it is previously or concurrently initialized
+                 through a set operation on the corresponding instance
+                 of usmUserCloneFrom.
+
+                 When the value of the corresponding usmUserAuthProtocol
+                 is usmNoAuthProtocol, then a set is successful, but
+                 effectively is a no-op.
+
+                 When this object is read, the zero-length (empty)
+                 string is returned.
+
+                 The recommended way to do a key change is as follows:
+
+                   1) GET(usmUserSpinLock.0) and save in sValue.
+                   2) generate the keyChange value based on the old
+                      (existing) secret key and the new secret key,
+                      let us call this kcValue.
+
+                 If you do the key change on behalf of another user:
+
+                   3) SET(usmUserSpinLock.0=sValue,
+                          usmUserAuthKeyChange=kcValue
+                          usmUserPublic=randomValue)
+
+                 If you do the key change for yourself:
+
+                   4) SET(usmUserSpinLock.0=sValue,
+                          usmUserOwnAuthKeyChange=kcValue
+                          usmUserPublic=randomValue)
+
+                 If you get a response with error-status of noError,
+                 then the SET succeeded and the new key is active.
+                 If you do not get a response, then you can issue a
+                 GET(usmUserPublic) and check if the value is equal
+                 to the randomValue you did send in the SET. If so, then
+                 the key change succeeded and the new key is active
+                 (probably the response got lost). If not, then the SET
+                 request probably never reached the target and so you
+                 can start over with the procedure above.
+                "
+    DEFVAL      { ''H }    -- the empty string
+    ::= { usmUserEntry 6 }
+
+usmUserOwnAuthKeyChange OBJECT-TYPE
+    SYNTAX       KeyChange   -- typically (SIZE (0 | 32)) for HMACMD5
+                             -- typically (SIZE (0 | 40)) for HMACSHA
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one
+                 notable difference: in order for the set operation
+                 to succeed, the usmUserName of the operation
+                 requester must match the usmUserName that
+                 indexes the row which is targeted by this
+                 operation.
+                 In addition, the USM security model must be
+                 used for this operation.
+
+                 The idea here is that access to this column can be
+                 public, since it will only allow a user to change
+                 his own secret authentication key (authKey).
+                 Note that this can only be done once the row is active.
+
+                 When a set is received and the usmUserName of the
+                 requester is not the same as the umsUserName that
+                 indexes the row which is targeted by this operation,
+                 then a 'noAccess' error must be returned.
+
+                 When a set is received and the security model in use
+                 is not USM, then a 'noAccess' error must be returned.
+                "
+    DEFVAL      { ''H }    -- the empty string
+    ::= { usmUserEntry 7 }
+
+usmUserPrivProtocol OBJECT-TYPE
+    SYNTAX       AutonomousType
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "An indication of whether messages sent on behalf of
+                 this user to/from the SNMP engine identified by
+                 usmUserEngineID, can be protected from disclosure,
+                 and if so, the type of privacy protocol which is used.
+
+                 An instance of this object is created concurrently
+                 with the creation of any other object instance for
+                 the same user (i.e., as part of the processing of
+                 the set operation which creates the first object
+                 instance in the same conceptual row).
+
+                 If an initial set operation (i.e. at row creation time)
+                 tries to set a value for an unknown or unsupported
+                 protocol, then a 'wrongValue' error must be returned.
+
+                 The value will be overwritten/set when a set operation
+                 is performed on the corresponding instance of
+                 usmUserCloneFrom.
+
+                 Once instantiated, the value of such an instance of
+                 this object can only be changed via a set operation to
+                 the value of the usmNoPrivProtocol.
+
+                 If a set operation tries to change the value of an
+                 existing instance of this object to any value other
+                 than usmNoPrivProtocol, then an 'inconsistentValue'
+                 error must be returned.
+
+                 Note that if any privacy protocol is used, then you
+                 must also use an authentication protocol. In other
+                 words, if usmUserPrivProtocol is set to anything else
+                 than usmNoPrivProtocol, then the corresponding instance
+                 of usmUserAuthProtocol cannot have a value of
+
+                 usmNoAuthProtocol. If it does, then an
+                 'inconsistentValue' error must be returned.
+                "
+    DEFVAL      { usmNoPrivProtocol }
+    ::= { usmUserEntry 8 }
+
+usmUserPrivKeyChange OBJECT-TYPE
+    SYNTAX       KeyChange  -- typically (SIZE (0 | 32)) for DES
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "An object, which when modified, causes the secret
+                 encryption key used for messages sent on behalf
+                 of this user to/from the SNMP engine identified by
+                 usmUserEngineID, to be modified via a one-way
+                 function.
+
+                 The associated protocol is the usmUserPrivProtocol.
+                 The associated secret key is the user's secret
+                 privacy key (privKey). The associated hash
+                 algorithm is the algorithm used by the user's
+                 usmUserAuthProtocol.
+
+                 When creating a new user, it is an 'inconsistentName'
+                 error for a set operation to refer to this object
+                 unless it is previously or concurrently initialized
+                 through a set operation on the corresponding instance
+                 of usmUserCloneFrom.
+
+                 When the value of the corresponding usmUserPrivProtocol
+                 is usmNoPrivProtocol, then a set is successful, but
+                 effectively is a no-op.
+
+                 When this object is read, the zero-length (empty)
+                 string is returned.
+                 See the description clause of usmUserAuthKeyChange for
+                 a recommended procedure to do a key change.
+                "
+    DEFVAL      { ''H }    -- the empty string
+    ::= { usmUserEntry 9 }
+
+usmUserOwnPrivKeyChange OBJECT-TYPE
+    SYNTAX       KeyChange  -- typically (SIZE (0 | 32)) for DES
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one
+                 notable difference: in order for the Set operation
+                 to succeed, the usmUserName of the operation
+                 requester must match the usmUserName that indexes
+
+                 the row which is targeted by this operation.
+                 In addition, the USM security model must be
+                 used for this operation.
+
+                 The idea here is that access to this column can be
+                 public, since it will only allow a user to change
+                 his own secret privacy key (privKey).
+                 Note that this can only be done once the row is active.
+
+                 When a set is received and the usmUserName of the
+                 requester is not the same as the umsUserName that
+                 indexes the row which is targeted by this operation,
+                 then a 'noAccess' error must be returned.
+
+                 When a set is received and the security model in use
+                 is not USM, then a 'noAccess' error must be returned.
+                "
+    DEFVAL      { ''H }    -- the empty string
+    ::= { usmUserEntry 10 }
+
+usmUserPublic    OBJECT-TYPE
+    SYNTAX       OCTET STRING (SIZE(0..32))
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "A publicly-readable value which can be written as part
+                 of the procedure for changing a user's secret
+                 authentication and/or privacy key, and later read to
+                 determine whether the change of the secret was
+                 effected.
+                "
+    DEFVAL      { ''H }  -- the empty string
+    ::= { usmUserEntry 11 }
+
+usmUserStorageType OBJECT-TYPE
+    SYNTAX       StorageType
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The storage type for this conceptual row.
+
+                 Conceptual rows having the value 'permanent' must
+                 allow write-access at a minimum to:
+
+                 - usmUserAuthKeyChange, usmUserOwnAuthKeyChange
+                   and usmUserPublic for a user who employs
+                   authentication, and
+                 - usmUserPrivKeyChange, usmUserOwnPrivKeyChange
+                   and usmUserPublic for a user who employs
+                   privacy.
+
+                 Note that any user who employs authentication or
+                 privacy must allow its secret(s) to be updated and
+                 thus cannot be 'readOnly'.
+
+                 If an initial set operation tries to set the value to
+                 'readOnly' for a user who employs authentication or
+                 privacy, then an 'inconsistentValue' error must be
+                 returned.  Note that if the value has been previously
+                 set (implicit or explicit) to any value, then the rules
+                 as defined in the StorageType Textual Convention apply.
+
+                 It is an implementation issue to decide if a SET for
+                 a readOnly or permanent row is accepted at all. In some
+                 contexts this may make sense, in others it may not. If
+                 a SET for a readOnly or permanent row is not accepted
+                 at all, then a 'wrongValue' error must be returned.
+                "
+    DEFVAL      { nonVolatile }
+    ::= { usmUserEntry 12 }
+
+usmUserStatus    OBJECT-TYPE
+    SYNTAX       RowStatus
+    MAX-ACCESS   read-create
+    STATUS       current
+    DESCRIPTION "The status of this conceptual row.
+
+                 Until instances of all corresponding columns are
+                 appropriately configured, the value of the
+                 corresponding instance of the usmUserStatus column
+                 is 'notReady'.
+
+                 In particular, a newly created row for a user who
+                 employs authentication, cannot be made active until the
+                 corresponding usmUserCloneFrom and usmUserAuthKeyChange
+                 have been set.
+
+                 Further, a newly created row for a user who also
+                 employs privacy, cannot be made active until the
+                 usmUserPrivKeyChange has been set.
+
+                 The RowStatus TC [RFC2579] requires that this
+                 DESCRIPTION clause states under which circumstances
+                 other objects in this row can be modified:
+
+                 The value of this object has no effect on whether
+                 other objects in this conceptual row can be modified,
+                 except for usmUserOwnAuthKeyChange and
+                 usmUserOwnPrivKeyChange. For these 2 objects, the
+
+                 value of usmUserStatus MUST be active.
+                "
+    ::= { usmUserEntry 13 }
+
+-- Conformance Information *******************************************
+
+usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
+usmMIBGroups      OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
+
+-- Compliance statements
+
+usmMIBCompliance MODULE-COMPLIANCE
+    STATUS       current
+    DESCRIPTION "The compliance statement for SNMP engines which
+                 implement the SNMP-USER-BASED-SM-MIB.
+                "
+
+    MODULE       -- this module
+        MANDATORY-GROUPS { usmMIBBasicGroup }
+
+        OBJECT           usmUserAuthProtocol
+        MIN-ACCESS       read-only
+        DESCRIPTION     "Write access is not required."
+
+        OBJECT           usmUserPrivProtocol
+        MIN-ACCESS       read-only
+        DESCRIPTION     "Write access is not required."
+    ::= { usmMIBCompliances 1 }
+
+-- Units of compliance
+usmMIBBasicGroup OBJECT-GROUP
+    OBJECTS     {
+                  usmStatsUnsupportedSecLevels,
+                  usmStatsNotInTimeWindows,
+                  usmStatsUnknownUserNames,
+                  usmStatsUnknownEngineIDs,
+                  usmStatsWrongDigests,
+                  usmStatsDecryptionErrors,
+                  usmUserSpinLock,
+                  usmUserSecurityName,
+                  usmUserCloneFrom,
+                  usmUserAuthProtocol,
+                  usmUserAuthKeyChange,
+                  usmUserOwnAuthKeyChange,
+                  usmUserPrivProtocol,
+                  usmUserPrivKeyChange,
+                  usmUserOwnPrivKeyChange,
+                  usmUserPublic,
+                  usmUserStorageType,
+                  usmUserStatus
+                }
+    STATUS       current
+    DESCRIPTION "A collection of objects providing for configuration
+                 of an SNMP engine which implements the SNMP
+                 User-based Security Model.
+                "
+    ::= { usmMIBGroups 1 }
+
+END