aboutsummaryrefslogtreecommitdiffstats
path: root/lib/snmp/mibs/SNMP-USER-BASED-SM-MIB.mib
diff options
context:
space:
mode:
Diffstat (limited to 'lib/snmp/mibs/SNMP-USER-BASED-SM-MIB.mib')
-rw-r--r--lib/snmp/mibs/SNMP-USER-BASED-SM-MIB.mib887
1 files changed, 887 insertions, 0 deletions
diff --git a/lib/snmp/mibs/SNMP-USER-BASED-SM-MIB.mib b/lib/snmp/mibs/SNMP-USER-BASED-SM-MIB.mib
new file mode 100644
index 0000000000..50d7011ef7
--- /dev/null
+++ b/lib/snmp/mibs/SNMP-USER-BASED-SM-MIB.mib
@@ -0,0 +1,887 @@
+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 "9901200000Z" -- 20 Jan 1999, midnight
+ ORGANIZATION "SNMPv3 Working Group"
+ CONTACT-INFO "WG-email: [email protected]
+ Subscribe: [email protected]
+ In msg body: subscribe snmpv3
+
+ Chair: Russ Mundy
+ Trusted Information Systems
+ postal: 3060 Washington Rd
+ Glenwood MD 21738
+ USA
+ email: [email protected]
+ phone: +1-301-854-6889
+
+ Co-editor Uri Blumenthal
+ IBM T. J. Watson Research
+ postal: 30 Saw Mill River Pkwy,
+ Hawthorne, NY 10532
+ USA
+ email: [email protected]
+ phone: +1-914-784-7964
+
+ Co-editor: Bert Wijnen
+ IBM T. J. Watson Research
+ postal: Schagen 33
+ 3461 GL Linschoten
+ Netherlands
+ email: [email protected]
+ phone: +31-348-432-794
+ "
+ DESCRIPTION "The management information definitions for the
+ SNMP User-based Security Model.
+ "
+-- Revision history
+ REVISION "9901200000Z" -- 20 Jan 1999, midnight
+ -- RFC-Editor assigns RFCxxxx
+ DESCRIPTION "Clarifications, published as RFCxxxx"
+
+ REVISION "9711200000Z" -- 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 responder 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
+ value as the corresponding secret of the clone-from
+ user.
+
+ 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 [RFC1903] 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-23 23:36:48 +0000