| 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 |
