913 lines
38 KiB
Plaintext
913 lines
38 KiB
Plaintext
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
|