SNMP-USER-BASED-SM-MIB.txt
上传用户:wxp200602
上传日期:2007-10-30
资源大小:4028k
文件大小:38k
源码类别:

SNMP编程

开发平台:

Unix_Linux

  1. SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
  2. IMPORTS
  3.     MODULE-IDENTITY, OBJECT-TYPE,
  4.     OBJECT-IDENTITY,
  5.     snmpModules, Counter32                FROM SNMPv2-SMI
  6.     TEXTUAL-CONVENTION, TestAndIncr,
  7.     RowStatus, RowPointer,
  8.     StorageType, AutonomousType           FROM SNMPv2-TC
  9.     MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF
  10.     SnmpAdminString, SnmpEngineID,
  11.     snmpAuthProtocols, snmpPrivProtocols  FROM SNMP-FRAMEWORK-MIB;
  12. snmpUsmMIB MODULE-IDENTITY
  13.     LAST-UPDATED "200210160000Z"            -- 16 Oct 2002, midnight
  14.     ORGANIZATION "SNMPv3 Working Group"
  15.     CONTACT-INFO "WG-email:   snmpv3@lists.tislabs.com
  16.                   Subscribe:  majordomo@lists.tislabs.com
  17.                               In msg body:  subscribe snmpv3
  18.                   Chair:      Russ Mundy
  19.                               Network Associates Laboratories
  20.                   postal:     15204 Omega Drive, Suite 300
  21.                               Rockville, MD 20850-4601
  22.                               USA
  23.                   email:      mundy@tislabs.com
  24.                   phone:      +1 301-947-7107
  25.                   Co-Chair:   David Harrington
  26.                               Enterasys Networks
  27.                   Postal:     35 Industrial Way
  28.                               P. O. Box 5004
  29.                               Rochester, New Hampshire 03866-5005
  30.                               USA
  31.                   EMail:      dbh@enterasys.com
  32.                   Phone:      +1 603-337-2614
  33.                   Co-editor   Uri Blumenthal
  34.                               Lucent Technologies
  35.                   postal:     67 Whippany Rd.
  36.                               Whippany, NJ 07981
  37.                               USA
  38.                   email:      uri@lucent.com
  39.                   phone:      +1-973-386-2163
  40.                   Co-editor:  Bert Wijnen
  41.                               Lucent Technologies
  42.                   postal:     Schagen 33
  43.                               3461 GL Linschoten
  44.                               Netherlands
  45.                   email:      bwijnen@lucent.com
  46.                   phone:      +31-348-480-685
  47.                  "
  48.     DESCRIPTION  "The management information definitions for the
  49.                   SNMP User-based Security Model.
  50.                   Copyright (C) The Internet Society (2002). This
  51.                   version of this MIB module is part of RFC 3414;
  52.                   see the RFC itself for full legal notices.
  53.                  "
  54. --  Revision history
  55.     REVISION     "200210160000Z"          -- 16 Oct 2002, midnight
  56.     DESCRIPTION  "Changes in this revision:
  57.                   - Updated references and contact info.
  58.                   - Clarification to usmUserCloneFrom DESCRIPTION
  59.                     clause
  60.                   - Fixed 'command responder' into 'command generator'
  61.                     in last para of DESCRIPTION clause of
  62.                     usmUserTable.
  63.                   This revision published as RFC3414.
  64.                  "
  65.     REVISION     "199901200000Z"          -- 20 Jan 1999, midnight
  66.     DESCRIPTION  "Clarifications, published as RFC2574"
  67.     REVISION     "199711200000Z"          -- 20 Nov 1997, midnight
  68.     DESCRIPTION  "Initial version, published as RFC2274"
  69.     ::= { snmpModules 15 }
  70. -- Administrative assignments ****************************************
  71. usmMIBObjects     OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
  72. usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
  73. -- Identification of Authentication and Privacy Protocols ************
  74. usmNoAuthProtocol OBJECT-IDENTITY
  75.     STATUS        current
  76.     DESCRIPTION  "No Authentication Protocol."
  77.     ::= { snmpAuthProtocols 1 }
  78. usmHMACMD5AuthProtocol OBJECT-IDENTITY
  79.     STATUS        current
  80.     DESCRIPTION  "The HMAC-MD5-96 Digest Authentication Protocol."
  81.     REFERENCE    "- H. Krawczyk, M. Bellare, R. Canetti HMAC:
  82.                     Keyed-Hashing for Message Authentication,
  83.                     RFC2104, Feb 1997.
  84.                   - Rivest, R., Message Digest Algorithm MD5, RFC1321.
  85.                  "
  86.     ::= { snmpAuthProtocols 2 }
  87. usmHMACSHAAuthProtocol OBJECT-IDENTITY
  88.     STATUS        current
  89.     DESCRIPTION  "The HMAC-SHA-96 Digest Authentication Protocol."
  90.     REFERENCE    "- H. Krawczyk, M. Bellare, R. Canetti, HMAC:
  91.                     Keyed-Hashing for Message Authentication,
  92.                     RFC2104, Feb 1997.
  93.                   - Secure Hash Algorithm. NIST FIPS 180-1.
  94.                  "
  95.     ::= { snmpAuthProtocols 3 }
  96. usmNoPrivProtocol OBJECT-IDENTITY
  97.     STATUS        current
  98.     DESCRIPTION  "No Privacy Protocol."
  99.     ::= { snmpPrivProtocols 1 }
  100. usmDESPrivProtocol OBJECT-IDENTITY
  101.     STATUS        current
  102.     DESCRIPTION  "The CBC-DES Symmetric Encryption Protocol."
  103.     REFERENCE    "- Data Encryption Standard, National Institute of
  104.                     Standards and Technology.  Federal Information
  105.                     Processing Standard (FIPS) Publication 46-1.
  106.                     Supersedes FIPS Publication 46,
  107.                     (January, 1977; reaffirmed January, 1988).
  108.                   - Data Encryption Algorithm, American National
  109.                     Standards Institute.  ANSI X3.92-1981,
  110.                     (December, 1980).
  111.                   - DES Modes of Operation, National Institute of
  112.                     Standards and Technology.  Federal Information
  113.                     Processing Standard (FIPS) Publication 81,
  114.                     (December, 1980).
  115.                   - Data Encryption Algorithm - Modes of Operation,
  116.                     American National Standards Institute.
  117.                     ANSI X3.106-1983, (May 1983).
  118.                  "
  119.     ::= { snmpPrivProtocols 2 }
  120. -- Textual Conventions ***********************************************
  121. KeyChange ::=     TEXTUAL-CONVENTION
  122.    STATUS         current
  123.    DESCRIPTION
  124.          "Every definition of an object with this syntax must identify
  125.           a protocol P, a secret key K, and a hash algorithm H
  126.           that produces output of L octets.
  127.           The object's value is a manager-generated, partially-random
  128.           value which, when modified, causes the value of the secret
  129.           key K, to be modified via a one-way function.
  130.           The value of an instance of this object is the concatenation
  131.           of two components: first a 'random' component and then a
  132.           'delta' component.
  133.           The lengths of the random and delta components
  134.           are given by the corresponding value of the protocol P;
  135.           if P requires K to be a fixed length, the length of both the
  136.           random and delta components is that fixed length; if P
  137.           allows the length of K to be variable up to a particular
  138.           maximum length, the length of the random component is that
  139.           maximum length and the length of the delta component is any
  140.           length less than or equal to that maximum length.
  141.           For example, usmHMACMD5AuthProtocol requires K to be a fixed
  142.           length of 16 octets and L - of 16 octets.
  143.           usmHMACSHAAuthProtocol requires K to be a fixed length of
  144.           20 octets and L - of 20 octets. Other protocols may define
  145.           other sizes, as deemed appropriate.
  146.           When a requester wants to change the old key K to a new
  147.           key keyNew on a remote entity, the 'random' component is
  148.           obtained from either a true random generator, or from a
  149.           pseudorandom generator, and the 'delta' component is
  150.           computed as follows:
  151.            - a temporary variable is initialized to the existing value
  152.              of K;
  153.            - if the length of the keyNew is greater than L octets,
  154.              then:
  155.               - the random component is appended to the value of the
  156.                 temporary variable, and the result is input to the
  157.                 the hash algorithm H to produce a digest value, and
  158.                 the temporary variable is set to this digest value;
  159.               - the value of the temporary variable is XOR-ed with
  160.                 the first (next) L-octets (16 octets in case of MD5)
  161.                 of the keyNew to produce the first (next) L-octets
  162.                 (16 octets in case of MD5) of the 'delta' component.
  163.               - the above two steps are repeated until the unused
  164.                 portion of the keyNew component is L octets or less,
  165.            - the random component is appended to the value of the
  166.              temporary variable, and the result is input to the
  167.              hash algorithm H to produce a digest value;
  168.            - this digest value, truncated if necessary to be the same
  169.              length as the unused portion of the keyNew, is XOR-ed
  170.              with the unused portion of the keyNew to produce the
  171.              (final portion of the) 'delta' component.
  172.            For example, using MD5 as the hash algorithm H:
  173.               iterations = (lenOfDelta - 1)/16; /* integer division */
  174.               temp = keyOld;
  175.               for (i = 0; i < iterations; i++) {
  176.                   temp = MD5 (temp || random);
  177.                   delta[i*16 .. (i*16)+15] =
  178.                          temp XOR keyNew[i*16 .. (i*16)+15];
  179.               }
  180.               temp = MD5 (temp || random);
  181.               delta[i*16 .. lenOfDelta-1] =
  182.                      temp XOR keyNew[i*16 .. lenOfDelta-1];
  183.           The 'random' and 'delta' components are then concatenated as
  184.           described above, and the resulting octet string is sent to
  185.           the recipient as the new value of an instance of this object.
  186.           At the receiver side, when an instance of this object is set
  187.           to a new value, then a new value of K is computed as follows:
  188.            - a temporary variable is initialized to the existing value
  189.              of K;
  190.            - if the length of the delta component is greater than L
  191.              octets, then:
  192.               - the random component is appended to the value of the
  193.                 temporary variable, and the result is input to the
  194.                 hash algorithm H to produce a digest value, and the
  195.                 temporary variable is set to this digest value;
  196.               - the value of the temporary variable is XOR-ed with
  197.                 the first (next) L-octets (16 octets in case of MD5)
  198.                 of the delta component to produce the first (next)
  199.                 L-octets (16 octets in case of MD5) of the new value
  200.                 of K.
  201.               - the above two steps are repeated until the unused
  202.                 portion of the delta component is L octets or less,
  203.            - the random component is appended to the value of the
  204.              temporary variable, and the result is input to the
  205.              hash algorithm H to produce a digest value;
  206.            - this digest value, truncated if necessary to be the same
  207.              length as the unused portion of the delta component, is
  208.              XOR-ed with the unused portion of the delta component to
  209.              produce the (final portion of the) new value of K.
  210.            For example, using MD5 as the hash algorithm H:
  211.               iterations = (lenOfDelta - 1)/16; /* integer division */
  212.               temp = keyOld;
  213.               for (i = 0; i < iterations; i++) {
  214.                   temp = MD5 (temp || random);
  215.                   keyNew[i*16 .. (i*16)+15] =
  216.                          temp XOR delta[i*16 .. (i*16)+15];
  217.               }
  218.               temp = MD5 (temp || random);
  219.               keyNew[i*16 .. lenOfDelta-1] =
  220.                      temp XOR delta[i*16 .. lenOfDelta-1];
  221.           The value of an object with this syntax, whenever it is
  222.           retrieved by the management protocol, is always the zero
  223.           length string.
  224.           Note that the keyOld and keyNew are the localized keys.
  225.           Note that it is probably wise that when an SNMP entity sends
  226.           a SetRequest to change a key, that it keeps a copy of the old
  227.           key until it has confirmed that the key change actually
  228.           succeeded.
  229.          "
  230.     SYNTAX       OCTET STRING
  231. -- Statistics for the User-based Security Model **********************
  232. usmStats         OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
  233. usmStatsUnsupportedSecLevels OBJECT-TYPE
  234.     SYNTAX       Counter32
  235.     MAX-ACCESS   read-only
  236.     STATUS       current
  237.     DESCRIPTION "The total number of packets received by the SNMP
  238.                  engine which were dropped because they requested a
  239.                  securityLevel that was unknown to the SNMP engine
  240.                  or otherwise unavailable.
  241.                 "
  242.     ::= { usmStats 1 }
  243. usmStatsNotInTimeWindows OBJECT-TYPE
  244.     SYNTAX       Counter32
  245.     MAX-ACCESS   read-only
  246.     STATUS       current
  247.     DESCRIPTION "The total number of packets received by the SNMP
  248.                  engine which were dropped because they appeared
  249.                  outside of the authoritative SNMP engine's window.
  250.                 "
  251.     ::= { usmStats 2 }
  252. usmStatsUnknownUserNames OBJECT-TYPE
  253.     SYNTAX       Counter32
  254.     MAX-ACCESS   read-only
  255.     STATUS       current
  256.     DESCRIPTION "The total number of packets received by the SNMP
  257.                  engine which were dropped because they referenced a
  258.                  user that was not known to the SNMP engine.
  259.                 "
  260.     ::= { usmStats 3 }
  261. usmStatsUnknownEngineIDs OBJECT-TYPE
  262.     SYNTAX       Counter32
  263.     MAX-ACCESS   read-only
  264.     STATUS       current
  265.     DESCRIPTION "The total number of packets received by the SNMP
  266.                  engine which were dropped because they referenced an
  267.                  snmpEngineID that was not known to the SNMP engine.
  268.                 "
  269.     ::= { usmStats 4 }
  270. usmStatsWrongDigests OBJECT-TYPE
  271.     SYNTAX       Counter32
  272.     MAX-ACCESS   read-only
  273.     STATUS       current
  274.     DESCRIPTION "The total number of packets received by the SNMP
  275.                  engine which were dropped because they didn't
  276.                  contain the expected digest value.
  277.                 "
  278.     ::= { usmStats 5 }
  279. usmStatsDecryptionErrors OBJECT-TYPE
  280.     SYNTAX       Counter32
  281.     MAX-ACCESS   read-only
  282.     STATUS       current
  283.     DESCRIPTION "The total number of packets received by the SNMP
  284.                  engine which were dropped because they could not be
  285.                  decrypted.
  286.                 "
  287.     ::= { usmStats 6 }
  288. -- The usmUser Group ************************************************
  289. usmUser          OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
  290. usmUserSpinLock  OBJECT-TYPE
  291.     SYNTAX       TestAndIncr
  292.     MAX-ACCESS   read-write
  293.     STATUS       current
  294.     DESCRIPTION "An advisory lock used to allow several cooperating
  295.                  Command Generator Applications to coordinate their
  296.                  use of facilities to alter secrets in the
  297.                  usmUserTable.
  298.                 "
  299.     ::= { usmUser 1 }
  300. -- The table of valid users for the User-based Security Model ********
  301. usmUserTable     OBJECT-TYPE
  302.     SYNTAX       SEQUENCE OF UsmUserEntry
  303.     MAX-ACCESS   not-accessible
  304.     STATUS       current
  305.     DESCRIPTION "The table of users configured in the SNMP engine's
  306.                  Local Configuration Datastore (LCD).
  307.                  To create a new user (i.e., to instantiate a new
  308.                  conceptual row in this table), it is recommended to
  309.                  follow this procedure:
  310.                    1)  GET(usmUserSpinLock.0) and save in sValue.
  311.                    2)  SET(usmUserSpinLock.0=sValue,
  312.                            usmUserCloneFrom=templateUser,
  313.                            usmUserStatus=createAndWait)
  314.                        You should use a template user to clone from
  315.                        which has the proper auth/priv protocol defined.
  316.                  If the new user is to use privacy:
  317.                    3)  generate the keyChange value based on the secret
  318.                        privKey of the clone-from user and the secret key
  319.                        to be used for the new user. Let us call this
  320.                        pkcValue.
  321.                    4)  GET(usmUserSpinLock.0) and save in sValue.
  322.                    5)  SET(usmUserSpinLock.0=sValue,
  323.                            usmUserPrivKeyChange=pkcValue
  324.                            usmUserPublic=randomValue1)
  325.                    6)  GET(usmUserPulic) and check it has randomValue1.
  326.                        If not, repeat steps 4-6.
  327.                  If the new user will never use privacy:
  328.                    7)  SET(usmUserPrivProtocol=usmNoPrivProtocol)
  329.                  If the new user is to use authentication:
  330.                    8)  generate the keyChange value based on the secret
  331.                        authKey of the clone-from user and the secret key
  332.                        to be used for the new user. Let us call this
  333.                        akcValue.
  334.                    9)  GET(usmUserSpinLock.0) and save in sValue.
  335.                    10) SET(usmUserSpinLock.0=sValue,
  336.                            usmUserAuthKeyChange=akcValue
  337.                            usmUserPublic=randomValue2)
  338.                    11) GET(usmUserPulic) and check it has randomValue2.
  339.                        If not, repeat steps 9-11.
  340.                  If the new user will never use authentication:
  341.                    12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
  342.                  Finally, activate the new user:
  343.                    13) SET(usmUserStatus=active)
  344.                  The new user should now be available and ready to be
  345.                  used for SNMPv3 communication. Note however that access
  346.                  to MIB data must be provided via configuration of the
  347.                  SNMP-VIEW-BASED-ACM-MIB.
  348.                  The use of usmUserSpinlock is to avoid conflicts with
  349.                  another SNMP command generator application which may
  350.                  also be acting on the usmUserTable.
  351.                 "
  352.     ::= { usmUser 2 }
  353. usmUserEntry     OBJECT-TYPE
  354.     SYNTAX       UsmUserEntry
  355.     MAX-ACCESS   not-accessible
  356.     STATUS       current
  357.     DESCRIPTION "A user configured in the SNMP engine's Local
  358.                  Configuration Datastore (LCD) for the User-based
  359.                  Security Model.
  360.                 "
  361.     INDEX       { usmUserEngineID,
  362.                   usmUserName
  363.                 }
  364.     ::= { usmUserTable 1 }
  365. UsmUserEntry ::= SEQUENCE
  366.     {
  367.         usmUserEngineID         SnmpEngineID,
  368.         usmUserName             SnmpAdminString,
  369.         usmUserSecurityName     SnmpAdminString,
  370.         usmUserCloneFrom        RowPointer,
  371.         usmUserAuthProtocol     AutonomousType,
  372.         usmUserAuthKeyChange    KeyChange,
  373.         usmUserOwnAuthKeyChange KeyChange,
  374.         usmUserPrivProtocol     AutonomousType,
  375.         usmUserPrivKeyChange    KeyChange,
  376.         usmUserOwnPrivKeyChange KeyChange,
  377.         usmUserPublic           OCTET STRING,
  378.         usmUserStorageType      StorageType,
  379.         usmUserStatus           RowStatus
  380.     }
  381. usmUserEngineID  OBJECT-TYPE
  382.     SYNTAX       SnmpEngineID
  383.     MAX-ACCESS   not-accessible
  384.     STATUS       current
  385.     DESCRIPTION "An SNMP engine's administratively-unique identifier.
  386.                  In a simple agent, this value is always that agent's
  387.                  own snmpEngineID value.
  388.                  The value can also take the value of the snmpEngineID
  389.                  of a remote SNMP engine with which this user can
  390.                  communicate.
  391.                 "
  392.     ::= { usmUserEntry 1 }
  393. usmUserName      OBJECT-TYPE
  394.     SYNTAX       SnmpAdminString (SIZE(1..32))
  395.     MAX-ACCESS   not-accessible
  396.     STATUS       current
  397.     DESCRIPTION "A human readable string representing the name of
  398.                  the user.
  399.                  This is the (User-based Security) Model dependent
  400.                  security ID.
  401.                 "
  402.     ::= { usmUserEntry 2 }
  403. usmUserSecurityName OBJECT-TYPE
  404.     SYNTAX       SnmpAdminString
  405.     MAX-ACCESS   read-only
  406.     STATUS       current
  407.     DESCRIPTION "A human readable string representing the user in
  408.                  Security Model independent format.
  409.                  The default transformation of the User-based Security
  410.                  Model dependent security ID to the securityName and
  411.                  vice versa is the identity function so that the
  412.                  securityName is the same as the userName.
  413.                 "
  414.     ::= { usmUserEntry 3 }
  415. usmUserCloneFrom OBJECT-TYPE
  416.     SYNTAX       RowPointer
  417.     MAX-ACCESS   read-create
  418.     STATUS       current
  419.     DESCRIPTION "A pointer to another conceptual row in this
  420.                  usmUserTable.  The user in this other conceptual
  421.                  row is called the clone-from user.
  422.                  When a new user is created (i.e., a new conceptual
  423.                  row is instantiated in this table), the privacy and
  424.                  authentication parameters of the new user must be
  425.                  cloned from its clone-from user. These parameters are:
  426.                    - authentication protocol (usmUserAuthProtocol)
  427.                    - privacy protocol (usmUserPrivProtocol)
  428.                  They will be copied regardless of what the current
  429.                  value is.
  430.                  Cloning also causes the initial values of the secret
  431.                  authentication key (authKey) and the secret encryption
  432.                  key (privKey) of the new user to be set to the same
  433.                  values as the corresponding secrets of the clone-from
  434.                  user to allow the KeyChange process to occur as
  435.                  required during user creation.
  436.                  The first time an instance of this object is set by
  437.                  a management operation (either at or after its
  438.                  instantiation), the cloning process is invoked.
  439.                  Subsequent writes are successful but invoke no
  440.                  action to be taken by the receiver.
  441.                  The cloning process fails with an 'inconsistentName'
  442.                  error if the conceptual row representing the
  443.                  clone-from user does not exist or is not in an active
  444.                  state when the cloning process is invoked.
  445.                  When this object is read, the ZeroDotZero OID
  446.                  is returned.
  447.                 "
  448.     ::= { usmUserEntry 4 }
  449. usmUserAuthProtocol OBJECT-TYPE
  450.     SYNTAX       AutonomousType
  451.     MAX-ACCESS   read-create
  452.     STATUS       current
  453.     DESCRIPTION "An indication of whether messages sent on behalf of
  454.                  this user to/from the SNMP engine identified by
  455.                  usmUserEngineID, can be authenticated, and if so,
  456.                  the type of authentication protocol which is used.
  457.                  An instance of this object is created concurrently
  458.                  with the creation of any other object instance for
  459.                  the same user (i.e., as part of the processing of
  460.                  the set operation which creates the first object
  461.                  instance in the same conceptual row).
  462.                  If an initial set operation (i.e. at row creation time)
  463.                  tries to set a value for an unknown or unsupported
  464.                  protocol, then a 'wrongValue' error must be returned.
  465.                  The value will be overwritten/set when a set operation
  466.                  is performed on the corresponding instance of
  467.                  usmUserCloneFrom.
  468.                  Once instantiated, the value of such an instance of
  469.                  this object can only be changed via a set operation to
  470.                  the value of the usmNoAuthProtocol.
  471.                  If a set operation tries to change the value of an
  472.                  existing instance of this object to any value other
  473.                  than usmNoAuthProtocol, then an 'inconsistentValue'
  474.                  error must be returned.
  475.                  If a set operation tries to set the value to the
  476.                  usmNoAuthProtocol while the usmUserPrivProtocol value
  477.                  in the same row is not equal to usmNoPrivProtocol,
  478.                  then an 'inconsistentValue' error must be returned.
  479.                  That means that an SNMP command generator application
  480.                  must first ensure that the usmUserPrivProtocol is set
  481.                  to the usmNoPrivProtocol value before it can set
  482.                  the usmUserAuthProtocol value to usmNoAuthProtocol.
  483.                 "
  484.     DEFVAL      { usmNoAuthProtocol }
  485.     ::= { usmUserEntry 5 }
  486. usmUserAuthKeyChange OBJECT-TYPE
  487.     SYNTAX       KeyChange   -- typically (SIZE (0 | 32)) for HMACMD5
  488.                              -- typically (SIZE (0 | 40)) for HMACSHA
  489.     MAX-ACCESS   read-create
  490.     STATUS       current
  491.     DESCRIPTION "An object, which when modified, causes the secret
  492.                  authentication key used for messages sent on behalf
  493.                  of this user to/from the SNMP engine identified by
  494.                  usmUserEngineID, to be modified via a one-way
  495.                  function.
  496.                  The associated protocol is the usmUserAuthProtocol.
  497.                  The associated secret key is the user's secret
  498.                  authentication key (authKey). The associated hash
  499.                  algorithm is the algorithm used by the user's
  500.                  usmUserAuthProtocol.
  501.                  When creating a new user, it is an 'inconsistentName'
  502.                  error for a set operation to refer to this object
  503.                  unless it is previously or concurrently initialized
  504.                  through a set operation on the corresponding instance
  505.                  of usmUserCloneFrom.
  506.                  When the value of the corresponding usmUserAuthProtocol
  507.                  is usmNoAuthProtocol, then a set is successful, but
  508.                  effectively is a no-op.
  509.                  When this object is read, the zero-length (empty)
  510.                  string is returned.
  511.                  The recommended way to do a key change is as follows:
  512.                    1) GET(usmUserSpinLock.0) and save in sValue.
  513.                    2) generate the keyChange value based on the old
  514.                       (existing) secret key and the new secret key,
  515.                       let us call this kcValue.
  516.                  If you do the key change on behalf of another user:
  517.                    3) SET(usmUserSpinLock.0=sValue,
  518.                           usmUserAuthKeyChange=kcValue
  519.                           usmUserPublic=randomValue)
  520.                  If you do the key change for yourself:
  521.                    4) SET(usmUserSpinLock.0=sValue,
  522.                           usmUserOwnAuthKeyChange=kcValue
  523.                           usmUserPublic=randomValue)
  524.                  If you get a response with error-status of noError,
  525.                  then the SET succeeded and the new key is active.
  526.                  If you do not get a response, then you can issue a
  527.                  GET(usmUserPublic) and check if the value is equal
  528.                  to the randomValue you did send in the SET. If so, then
  529.                  the key change succeeded and the new key is active
  530.                  (probably the response got lost). If not, then the SET
  531.                  request probably never reached the target and so you
  532.                  can start over with the procedure above.
  533.                 "
  534.     DEFVAL      { ''H }    -- the empty string
  535.     ::= { usmUserEntry 6 }
  536. usmUserOwnAuthKeyChange OBJECT-TYPE
  537.     SYNTAX       KeyChange   -- typically (SIZE (0 | 32)) for HMACMD5
  538.                              -- typically (SIZE (0 | 40)) for HMACSHA
  539.     MAX-ACCESS   read-create
  540.     STATUS       current
  541.     DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one
  542.                  notable difference: in order for the set operation
  543.                  to succeed, the usmUserName of the operation
  544.                  requester must match the usmUserName that
  545.                  indexes the row which is targeted by this
  546.                  operation.
  547.                  In addition, the USM security model must be
  548.                  used for this operation.
  549.                  The idea here is that access to this column can be
  550.                  public, since it will only allow a user to change
  551.                  his own secret authentication key (authKey).
  552.                  Note that this can only be done once the row is active.
  553.                  When a set is received and the usmUserName of the
  554.                  requester is not the same as the umsUserName that
  555.                  indexes the row which is targeted by this operation,
  556.                  then a 'noAccess' error must be returned.
  557.                  When a set is received and the security model in use
  558.                  is not USM, then a 'noAccess' error must be returned.
  559.                 "
  560.     DEFVAL      { ''H }    -- the empty string
  561.     ::= { usmUserEntry 7 }
  562. usmUserPrivProtocol OBJECT-TYPE
  563.     SYNTAX       AutonomousType
  564.     MAX-ACCESS   read-create
  565.     STATUS       current
  566.     DESCRIPTION "An indication of whether messages sent on behalf of
  567.                  this user to/from the SNMP engine identified by
  568.                  usmUserEngineID, can be protected from disclosure,
  569.                  and if so, the type of privacy protocol which is used.
  570.                  An instance of this object is created concurrently
  571.                  with the creation of any other object instance for
  572.                  the same user (i.e., as part of the processing of
  573.                  the set operation which creates the first object
  574.                  instance in the same conceptual row).
  575.                  If an initial set operation (i.e. at row creation time)
  576.                  tries to set a value for an unknown or unsupported
  577.                  protocol, then a 'wrongValue' error must be returned.
  578.                  The value will be overwritten/set when a set operation
  579.                  is performed on the corresponding instance of
  580.                  usmUserCloneFrom.
  581.                  Once instantiated, the value of such an instance of
  582.                  this object can only be changed via a set operation to
  583.                  the value of the usmNoPrivProtocol.
  584.                  If a set operation tries to change the value of an
  585.                  existing instance of this object to any value other
  586.                  than usmNoPrivProtocol, then an 'inconsistentValue'
  587.                  error must be returned.
  588.                  Note that if any privacy protocol is used, then you
  589.                  must also use an authentication protocol. In other
  590.                  words, if usmUserPrivProtocol is set to anything else
  591.                  than usmNoPrivProtocol, then the corresponding instance
  592.                  of usmUserAuthProtocol cannot have a value of
  593.                  usmNoAuthProtocol. If it does, then an
  594.                  'inconsistentValue' error must be returned.
  595.                 "
  596.     DEFVAL      { usmNoPrivProtocol }
  597.     ::= { usmUserEntry 8 }
  598. usmUserPrivKeyChange OBJECT-TYPE
  599.     SYNTAX       KeyChange  -- typically (SIZE (0 | 32)) for DES
  600.     MAX-ACCESS   read-create
  601.     STATUS       current
  602.     DESCRIPTION "An object, which when modified, causes the secret
  603.                  encryption key used for messages sent on behalf
  604.                  of this user to/from the SNMP engine identified by
  605.                  usmUserEngineID, to be modified via a one-way
  606.                  function.
  607.                  The associated protocol is the usmUserPrivProtocol.
  608.                  The associated secret key is the user's secret
  609.                  privacy key (privKey). The associated hash
  610.                  algorithm is the algorithm used by the user's
  611.                  usmUserAuthProtocol.
  612.                  When creating a new user, it is an 'inconsistentName'
  613.                  error for a set operation to refer to this object
  614.                  unless it is previously or concurrently initialized
  615.                  through a set operation on the corresponding instance
  616.                  of usmUserCloneFrom.
  617.                  When the value of the corresponding usmUserPrivProtocol
  618.                  is usmNoPrivProtocol, then a set is successful, but
  619.                  effectively is a no-op.
  620.                  When this object is read, the zero-length (empty)
  621.                  string is returned.
  622.                  See the description clause of usmUserAuthKeyChange for
  623.                  a recommended procedure to do a key change.
  624.                 "
  625.     DEFVAL      { ''H }    -- the empty string
  626.     ::= { usmUserEntry 9 }
  627. usmUserOwnPrivKeyChange OBJECT-TYPE
  628.     SYNTAX       KeyChange  -- typically (SIZE (0 | 32)) for DES
  629.     MAX-ACCESS   read-create
  630.     STATUS       current
  631.     DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one
  632.                  notable difference: in order for the Set operation
  633.                  to succeed, the usmUserName of the operation
  634.                  requester must match the usmUserName that indexes
  635.                  the row which is targeted by this operation.
  636.                  In addition, the USM security model must be
  637.                  used for this operation.
  638.                  The idea here is that access to this column can be
  639.                  public, since it will only allow a user to change
  640.                  his own secret privacy key (privKey).
  641.                  Note that this can only be done once the row is active.
  642.                  When a set is received and the usmUserName of the
  643.                  requester is not the same as the umsUserName that
  644.                  indexes the row which is targeted by this operation,
  645.                  then a 'noAccess' error must be returned.
  646.                  When a set is received and the security model in use
  647.                  is not USM, then a 'noAccess' error must be returned.
  648.                 "
  649.     DEFVAL      { ''H }    -- the empty string
  650.     ::= { usmUserEntry 10 }
  651. usmUserPublic    OBJECT-TYPE
  652.     SYNTAX       OCTET STRING (SIZE(0..32))
  653.     MAX-ACCESS   read-create
  654.     STATUS       current
  655.     DESCRIPTION "A publicly-readable value which can be written as part
  656.                  of the procedure for changing a user's secret
  657.                  authentication and/or privacy key, and later read to
  658.                  determine whether the change of the secret was
  659.                  effected.
  660.                 "
  661.     DEFVAL      { ''H }  -- the empty string
  662.     ::= { usmUserEntry 11 }
  663. usmUserStorageType OBJECT-TYPE
  664.     SYNTAX       StorageType
  665.     MAX-ACCESS   read-create
  666.     STATUS       current
  667.     DESCRIPTION "The storage type for this conceptual row.
  668.                  Conceptual rows having the value 'permanent' must
  669.                  allow write-access at a minimum to:
  670.                  - usmUserAuthKeyChange, usmUserOwnAuthKeyChange
  671.                    and usmUserPublic for a user who employs
  672.                    authentication, and
  673.                  - usmUserPrivKeyChange, usmUserOwnPrivKeyChange
  674.                    and usmUserPublic for a user who employs
  675.                    privacy.
  676.                  Note that any user who employs authentication or
  677.                  privacy must allow its secret(s) to be updated and
  678.                  thus cannot be 'readOnly'.
  679.                  If an initial set operation tries to set the value to
  680.                  'readOnly' for a user who employs authentication or
  681.                  privacy, then an 'inconsistentValue' error must be
  682.                  returned.  Note that if the value has been previously
  683.                  set (implicit or explicit) to any value, then the rules
  684.                  as defined in the StorageType Textual Convention apply.
  685.                  It is an implementation issue to decide if a SET for
  686.                  a readOnly or permanent row is accepted at all. In some
  687.                  contexts this may make sense, in others it may not. If
  688.                  a SET for a readOnly or permanent row is not accepted
  689.                  at all, then a 'wrongValue' error must be returned.
  690.                 "
  691.     DEFVAL      { nonVolatile }
  692.     ::= { usmUserEntry 12 }
  693. usmUserStatus    OBJECT-TYPE
  694.     SYNTAX       RowStatus
  695.     MAX-ACCESS   read-create
  696.     STATUS       current
  697.     DESCRIPTION "The status of this conceptual row.
  698.                  Until instances of all corresponding columns are
  699.                  appropriately configured, the value of the
  700.                  corresponding instance of the usmUserStatus column
  701.                  is 'notReady'.
  702.                  In particular, a newly created row for a user who
  703.                  employs authentication, cannot be made active until the
  704.                  corresponding usmUserCloneFrom and usmUserAuthKeyChange
  705.                  have been set.
  706.                  Further, a newly created row for a user who also
  707.                  employs privacy, cannot be made active until the
  708.                  usmUserPrivKeyChange has been set.
  709.                  The RowStatus TC [RFC2579] requires that this
  710.                  DESCRIPTION clause states under which circumstances
  711.                  other objects in this row can be modified:
  712.                  The value of this object has no effect on whether
  713.                  other objects in this conceptual row can be modified,
  714.                  except for usmUserOwnAuthKeyChange and
  715.                  usmUserOwnPrivKeyChange. For these 2 objects, the
  716.                  value of usmUserStatus MUST be active.
  717.                 "
  718.     ::= { usmUserEntry 13 }
  719. -- Conformance Information *******************************************
  720. usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
  721. usmMIBGroups      OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
  722. -- Compliance statements
  723. usmMIBCompliance MODULE-COMPLIANCE
  724.     STATUS       current
  725.     DESCRIPTION "The compliance statement for SNMP engines which
  726.                  implement the SNMP-USER-BASED-SM-MIB.
  727.                 "
  728.     MODULE       -- this module
  729.         MANDATORY-GROUPS { usmMIBBasicGroup }
  730.         OBJECT           usmUserAuthProtocol
  731.         MIN-ACCESS       read-only
  732.         DESCRIPTION     "Write access is not required."
  733.         OBJECT           usmUserPrivProtocol
  734.         MIN-ACCESS       read-only
  735.         DESCRIPTION     "Write access is not required."
  736.     ::= { usmMIBCompliances 1 }
  737. -- Units of compliance
  738. usmMIBBasicGroup OBJECT-GROUP
  739.     OBJECTS     {
  740.                   usmStatsUnsupportedSecLevels,
  741.                   usmStatsNotInTimeWindows,
  742.                   usmStatsUnknownUserNames,
  743.                   usmStatsUnknownEngineIDs,
  744.                   usmStatsWrongDigests,
  745.                   usmStatsDecryptionErrors,
  746.                   usmUserSpinLock,
  747.                   usmUserSecurityName,
  748.                   usmUserCloneFrom,
  749.                   usmUserAuthProtocol,
  750.                   usmUserAuthKeyChange,
  751.                   usmUserOwnAuthKeyChange,
  752.                   usmUserPrivProtocol,
  753.                   usmUserPrivKeyChange,
  754.                   usmUserOwnPrivKeyChange,
  755.                   usmUserPublic,
  756.                   usmUserStorageType,
  757.                   usmUserStatus
  758.                 }
  759.     STATUS       current
  760.     DESCRIPTION "A collection of objects providing for configuration
  761.                  of an SNMP engine which implements the SNMP
  762.                  User-based Security Model.
  763.                 "
  764.     ::= { usmMIBGroups 1 }
  765. END