mirror of
https://github.com/librenms/librenms.git
synced 2024-10-07 16:52:45 +00:00
8fa88ade9f
git-svn-id: http://www.observium.org/svn/observer/trunk@2167 61d68cd4-352d-0410-923a-c4978735b2b8
897 lines
37 KiB
Plaintext
897 lines
37 KiB
Plaintext
-- RFC 2574 : USM for SNMPv3 (April 1999)
|
||
|
||
SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
|
||
|
||
IMPORTS
|
||
MODULE-IDENTITY, OBJECT-TYPE,
|
||
OBJECT-IDENTITY,
|
||
snmpModules, Counter32 FROM SNMPv2-SMI
|
||
TEXTUAL-CONVENTION, TestAndIncr,
|
||
RowStatus, RowPointer,
|
||
StorageType, AutonomousType FROM SNMPv2-TC
|
||
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
|
||
SnmpAdminString, SnmpEngineID,
|
||
snmpAuthProtocols, snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB;
|
||
|
||
snmpUsmMIB MODULE-IDENTITY
|
||
LAST-UPDATED "9901200000Z" -- 20 Jan 1999, midnight
|
||
ORGANIZATION "SNMPv3 Working Group"
|
||
CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
|
||
Subscribe: majordomo@lists.tislabs.com
|
||
In msg body: subscribe snmpv3
|
||
|
||
Chair: Russ Mundy
|
||
Trusted Information Systems
|
||
postal: 3060 Washington Rd
|
||
Glenwood MD 21738
|
||
USA
|
||
email: mundy@tislabs.com
|
||
phone: +1-301-854-6889
|
||
|
||
Co-editor Uri Blumenthal
|
||
|
||
|
||
|
||
Blumenthal & Wijnen Standards Track [Page 31]
|
||
|
||
RFC 2574 USM for SNMPv3 April 1999
|
||
|
||
|
||
IBM T. J. Watson Research
|
||
postal: 30 Saw Mill River Pkwy,
|
||
Hawthorne, NY 10532
|
||
USA
|
||
email: uri@watson.ibm.com
|
||
phone: +1-914-784-7964
|
||
|
||
Co-editor: Bert Wijnen
|
||
IBM T. J. Watson Research
|
||
postal: Schagen 33
|
||
3461 GL Linschoten
|
||
Netherlands
|
||
email: wijnen@vnet.ibm.com
|
||
phone: +31-348-432-794
|
||
"
|
||
DESCRIPTION "The management information definitions for the
|
||
SNMP User-based Security Model.
|
||
"
|
||
-- Revision history
|
||
|
||
REVISION "9901200000Z" -- 20 Jan 1999, midnight
|
||
DESCRIPTION "Clarifications, published as RFC2574"
|
||
|
||
REVISION "9711200000Z" -- 20 Nov 1997, midnight
|
||
DESCRIPTION "Initial version, published as RFC2274"
|
||
|
||
::= { snmpModules 15 }
|
||
|
||
-- Administrative assignments ****************************************
|
||
|
||
usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
|
||
usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
|
||
|
||
-- Identification of Authentication and Privacy Protocols ************
|
||
|
||
usmNoAuthProtocol OBJECT-IDENTITY
|
||
STATUS current
|
||
DESCRIPTION "No Authentication Protocol."
|
||
::= { snmpAuthProtocols 1 }
|
||
|
||
usmHMACMD5AuthProtocol OBJECT-IDENTITY
|
||
STATUS current
|
||
DESCRIPTION "The HMAC-MD5-96 Digest Authentication Protocol."
|
||
REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti HMAC:
|
||
Keyed-Hashing for Message Authentication,
|
||
RFC2104, Feb 1997.
|
||
- Rivest, R., Message Digest Algorithm MD5, RFC1321.
|
||
"
|
||
::= { snmpAuthProtocols 2 }
|
||
|
||
usmHMACSHAAuthProtocol OBJECT-IDENTITY
|
||
STATUS current
|
||
DESCRIPTION "The HMAC-SHA-96 Digest Authentication Protocol."
|
||
REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti, HMAC:
|
||
Keyed-Hashing for Message Authentication,
|
||
RFC2104, Feb 1997.
|
||
- Secure Hash Algorithm. NIST FIPS 180-1.
|
||
"
|
||
::= { snmpAuthProtocols 3 }
|
||
|
||
usmNoPrivProtocol OBJECT-IDENTITY
|
||
STATUS current
|
||
DESCRIPTION "No Privacy Protocol."
|
||
::= { snmpPrivProtocols 1 }
|
||
|
||
usmDESPrivProtocol OBJECT-IDENTITY
|
||
STATUS current
|
||
DESCRIPTION "The CBC-DES Symmetric Encryption Protocol."
|
||
REFERENCE "- Data Encryption Standard, National Institute of
|
||
Standards and Technology. Federal Information
|
||
Processing Standard (FIPS) Publication 46-1.
|
||
Supersedes FIPS Publication 46,
|
||
(January, 1977; reaffirmed January, 1988).
|
||
|
||
- Data Encryption Algorithm, American National
|
||
Standards Institute. ANSI X3.92-1981,
|
||
(December, 1980).
|
||
|
||
- DES Modes of Operation, National Institute of
|
||
Standards and Technology. Federal Information
|
||
Processing Standard (FIPS) Publication 81,
|
||
(December, 1980).
|
||
|
||
- Data Encryption Algorithm - Modes of Operation,
|
||
American National Standards Institute.
|
||
ANSI X3.106-1983, (May 1983).
|
||
"
|
||
::= { snmpPrivProtocols 2 }
|
||
|
||
|
||
-- Textual Conventions ***********************************************
|
||
|
||
|
||
KeyChange ::= TEXTUAL-CONVENTION
|
||
STATUS current
|
||
DESCRIPTION
|
||
"Every definition of an object with this syntax must identify
|
||
a protocol P, a secret key K, and a hash algorithm H
|
||
that produces output of L octets.
|
||
|
||
The object's value is a manager-generated, partially-random
|
||
value which, when modified, causes the value of the secret
|
||
key K, to be modified via a one-way function.
|
||
|
||
The value of an instance of this object is the concatenation
|
||
of two components: first a 'random' component and then a
|
||
'delta' component.
|
||
|
||
The lengths of the random and delta components
|
||
are given by the corresponding value of the protocol P;
|
||
if P requires K to be a fixed length, the length of both the
|
||
random and delta components is that fixed length; if P
|
||
allows the length of K to be variable up to a particular
|
||
maximum length, the length of the random component is that
|
||
maximum length and the length of the delta component is any
|
||
length less than or equal to that maximum length.
|
||
For example, usmHMACMD5AuthProtocol requires K to be a fixed
|
||
length of 16 octets and L - of 16 octets.
|
||
usmHMACSHAAuthProtocol requires K to be a fixed length of
|
||
20 octets and L - of 20 octets. Other protocols may define
|
||
other sizes, as deemed appropriate.
|
||
|
||
When a requester wants to change the old key K to a new
|
||
key keyNew on a remote entity, the 'random' component is
|
||
obtained from either a true random generator, or from a
|
||
pseudorandom generator, and the 'delta' component is
|
||
computed as follows:
|
||
|
||
- a temporary variable is initialized to the existing value
|
||
of K;
|
||
- if the length of the keyNew is greater than L octets,
|
||
then:
|
||
- the random component is appended to the value of the
|
||
temporary variable, and the result is input to the
|
||
the hash algorithm H to produce a digest value, and
|
||
the temporary variable is set to this digest value;
|
||
- the value of the temporary variable is XOR-ed with
|
||
the first (next) L-octets (16 octets in case of MD5)
|
||
of the keyNew to produce the first (next) L-octets
|
||
(16 octets in case of MD5) of the 'delta' component.
|
||
- the above two steps are repeated until the unused
|
||
portion of the keyNew component is L octets or less,
|
||
- the random component is appended to the value of the
|
||
temporary variable, and the result is input to the
|
||
hash algorithm H to produce a digest value;
|
||
- this digest value, truncated if necessary to be the same
|
||
length as the unused portion of the keyNew, is XOR-ed
|
||
with the unused portion of the keyNew to produce the
|
||
(final portion of the) 'delta' component.
|
||
|
||
For example, using MD5 as the hash algorithm H:
|
||
|
||
iterations = (lenOfDelta - 1)/16; /* integer division */
|
||
temp = keyOld;
|
||
for (i = 0; i < iterations; i++) {
|
||
temp = MD5 (temp || random);
|
||
delta[i*16 .. (i*16)+15] =
|
||
temp XOR keyNew[i*16 .. (i*16)+15];
|
||
}
|
||
temp = MD5 (temp || random);
|
||
delta[i*16 .. lenOfDelta-1] =
|
||
temp XOR keyNew[i*16 .. lenOfDelta-1];
|
||
|
||
The 'random' and 'delta' components are then concatenated as
|
||
described above, and the resulting octet string is sent to
|
||
the recipient as the new value of an instance of this object.
|
||
|
||
At the receiver side, when an instance of this object is set
|
||
to a new value, then a new value of K is computed as follows:
|
||
|
||
- a temporary variable is initialized to the existing value
|
||
of K;
|
||
- if the length of the delta component is greater than L
|
||
octets, then:
|
||
- the random component is appended to the value of the
|
||
temporary variable, and the result is input to the
|
||
hash algorithm H to produce a digest value, and the
|
||
temporary variable is set to this digest value;
|
||
- the value of the temporary variable is XOR-ed with
|
||
the first (next) L-octets (16 octets in case of MD5)
|
||
of the delta component to produce the first (next)
|
||
L-octets (16 octets in case of MD5) of the new value
|
||
of K.
|
||
- the above two steps are repeated until the unused
|
||
portion of the delta component is L octets or less,
|
||
- the random component is appended to the value of the
|
||
temporary variable, and the result is input to the
|
||
hash algorithm H to produce a digest value;
|
||
- this digest value, truncated if necessary to be the same
|
||
length as the unused portion of the delta component, is
|
||
XOR-ed with the unused portion of the delta component to
|
||
produce the (final portion of the) new value of K.
|
||
For example, using MD5 as the hash algorithm H:
|
||
|
||
iterations = (lenOfDelta - 1)/16; /* integer division */
|
||
temp = keyOld;
|
||
for (i = 0; i < iterations; i++) {
|
||
temp = MD5 (temp || random);
|
||
keyNew[i*16 .. (i*16)+15] =
|
||
temp XOR delta[i*16 .. (i*16)+15];
|
||
}
|
||
temp = MD5 (temp || random);
|
||
keyNew[i*16 .. lenOfDelta-1] =
|
||
temp XOR delta[i*16 .. lenOfDelta-1];
|
||
|
||
The value of an object with this syntax, whenever it is
|
||
retrieved by the management protocol, is always the zero
|
||
length string.
|
||
|
||
Note that the keyOld and keyNew are the localized keys.
|
||
|
||
Note that it is probably wise that when an SNMP entity sends
|
||
a SetRequest to change a key, that it keeps a copy of the old
|
||
key until it has confirmed that the key change actually
|
||
succeeded.
|
||
"
|
||
SYNTAX OCTET STRING
|
||
|
||
|
||
-- Statistics for the User-based Security Model **********************
|
||
|
||
|
||
usmStats OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
|
||
|
||
|
||
usmStatsUnsupportedSecLevels OBJECT-TYPE
|
||
SYNTAX Counter32
|
||
MAX-ACCESS read-only
|
||
STATUS current
|
||
DESCRIPTION "The total number of packets received by the SNMP
|
||
engine which were dropped because they requested a
|
||
securityLevel that was unknown to the SNMP engine
|
||
or otherwise unavailable.
|
||
"
|
||
::= { usmStats 1 }
|
||
|
||
usmStatsNotInTimeWindows OBJECT-TYPE
|
||
SYNTAX Counter32
|
||
MAX-ACCESS read-only
|
||
STATUS current
|
||
DESCRIPTION "The total number of packets received by the SNMP
|
||
engine which were dropped because they appeared
|
||
outside of the authoritative SNMP engine's window.
|
||
"
|
||
::= { usmStats 2 }
|
||
|
||
usmStatsUnknownUserNames OBJECT-TYPE
|
||
SYNTAX Counter32
|
||
MAX-ACCESS read-only
|
||
STATUS current
|
||
DESCRIPTION "The total number of packets received by the SNMP
|
||
engine which were dropped because they referenced a
|
||
user that was not known to the SNMP engine.
|
||
"
|
||
::= { usmStats 3 }
|
||
|
||
usmStatsUnknownEngineIDs OBJECT-TYPE
|
||
SYNTAX Counter32
|
||
MAX-ACCESS read-only
|
||
STATUS current
|
||
DESCRIPTION "The total number of packets received by the SNMP
|
||
engine which were dropped because they referenced an
|
||
snmpEngineID that was not known to the SNMP engine.
|
||
"
|
||
::= { usmStats 4 }
|
||
|
||
usmStatsWrongDigests OBJECT-TYPE
|
||
SYNTAX Counter32
|
||
MAX-ACCESS read-only
|
||
STATUS current
|
||
DESCRIPTION "The total number of packets received by the SNMP
|
||
engine which were dropped because they didn't
|
||
contain the expected digest value.
|
||
"
|
||
::= { usmStats 5 }
|
||
|
||
usmStatsDecryptionErrors OBJECT-TYPE
|
||
SYNTAX Counter32
|
||
MAX-ACCESS read-only
|
||
STATUS current
|
||
DESCRIPTION "The total number of packets received by the SNMP
|
||
engine which were dropped because they could not be
|
||
decrypted.
|
||
"
|
||
::= { usmStats 6 }
|
||
|
||
-- The usmUser Group ************************************************
|
||
|
||
usmUser OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
|
||
|
||
usmUserSpinLock OBJECT-TYPE
|
||
SYNTAX TestAndIncr
|
||
MAX-ACCESS read-write
|
||
STATUS current
|
||
DESCRIPTION "An advisory lock used to allow several cooperating
|
||
Command Generator Applications to coordinate their
|
||
use of facilities to alter secrets in the
|
||
usmUserTable.
|
||
"
|
||
::= { usmUser 1 }
|
||
|
||
-- The table of valid users for the User-based Security Model ********
|
||
|
||
usmUserTable OBJECT-TYPE
|
||
SYNTAX SEQUENCE OF UsmUserEntry
|
||
MAX-ACCESS not-accessible
|
||
STATUS current
|
||
DESCRIPTION "The table of users configured in the SNMP engine's
|
||
Local Configuration Datastore (LCD).
|
||
|
||
To create a new user (i.e., to instantiate a new
|
||
conceptual row in this table), it is recommended to
|
||
follow this procedure:
|
||
|
||
1) GET(usmUserSpinLock.0) and save in sValue.
|
||
2) SET(usmUserSpinLock.0=sValue,
|
||
usmUserCloneFrom=templateUser,
|
||
usmUserStatus=createAndWait)
|
||
You should use a template user to clone from
|
||
which has the proper auth/priv protocol defined.
|
||
|
||
If the new user is to use privacy:
|
||
|
||
3) generate the keyChange value based on the secret
|
||
privKey of the clone-from user and the secret key
|
||
to be used for the new user. Let us call this
|
||
pkcValue.
|
||
4) GET(usmUserSpinLock.0) and save in sValue.
|
||
5) SET(usmUserSpinLock.0=sValue,
|
||
usmUserPrivKeyChange=pkcValue
|
||
usmUserPublic=randomValue1)
|
||
6) GET(usmUserPulic) and check it has randomValue1.
|
||
If not, repeat steps 4-6.
|
||
|
||
If the new user will never use privacy:
|
||
|
||
7) SET(usmUserPrivProtocol=usmNoPrivProtocol)
|
||
|
||
If the new user is to use authentication:
|
||
|
||
8) generate the keyChange value based on the secret
|
||
authKey of the clone-from user and the secret key
|
||
to be used for the new user. Let us call this
|
||
akcValue.
|
||
9) GET(usmUserSpinLock.0) and save in sValue.
|
||
10) SET(usmUserSpinLock.0=sValue,
|
||
usmUserAuthKeyChange=akcValue
|
||
usmUserPublic=randomValue2)
|
||
11) GET(usmUserPulic) and check it has randomValue2.
|
||
If not, repeat steps 9-11.
|
||
|
||
If the new user will never use authentication:
|
||
|
||
12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
|
||
|
||
Finally, activate the new user:
|
||
|
||
13) SET(usmUserStatus=active)
|
||
|
||
The new user should now be available and ready to be
|
||
used for SNMPv3 communication. Note however that access
|
||
to MIB data must be provided via configuration of the
|
||
SNMP-VIEW-BASED-ACM-MIB.
|
||
|
||
The use of usmUserSpinlock is to avoid conflicts with
|
||
another SNMP command 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
|