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