SNMP-USER-BASED-SM-MIB.txt
上传用户:wxp200602
上传日期:2007-10-30
资源大小:4028k
文件大小:38k
源码类别:
SNMP编程
开发平台:
Unix_Linux
- 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