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