1
SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
4
MODULE-IDENTITY, OBJECT-TYPE,
6
snmpModules, Counter32 FROM SNMPv2-SMI
7
TEXTUAL-CONVENTION, TestAndIncr,
9
StorageType, AutonomousType FROM SNMPv2-TC
10
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
11
SnmpAdminString, SnmpEngineID,
12
snmpAuthProtocols, snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB;
14
snmpUsmMIB MODULE-IDENTITY
15
LAST-UPDATED "9901200000Z" -- 20 Jan 1999, midnight
16
ORGANIZATION "SNMPv3 Working Group"
17
CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
18
Subscribe: majordomo@lists.tislabs.com
19
In msg body: subscribe snmpv3
22
Trusted Information Systems
23
postal: 3060 Washington Rd
26
email: mundy@tislabs.com
27
phone: +1-301-854-6889
29
Co-editor Uri Blumenthal
31
IBM T. J. Watson Research
32
postal: 30 Saw Mill River Pkwy,
35
email: uri@watson.ibm.com
36
phone: +1-914-784-7964
38
Co-editor: Bert Wijnen
39
IBM T. J. Watson Research
43
email: wijnen@vnet.ibm.com
44
phone: +31-348-432-794
46
DESCRIPTION "The management information definitions for the
47
SNMP User-based Security Model.
51
REVISION "9901200000Z" -- 20 Jan 1999, midnight
52
DESCRIPTION "Clarifications, published as RFC2574"
54
REVISION "9711200000Z" -- 20 Nov 1997, midnight
55
DESCRIPTION "Initial version, published as RFC2274"
56
::= { snmpModules 15 }
58
-- Administrative assignments ****************************************
60
usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
61
usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
63
-- Identification of Authentication and Privacy Protocols ************
65
usmNoAuthProtocol OBJECT-IDENTITY
67
DESCRIPTION "No Authentication Protocol."
68
::= { snmpAuthProtocols 1 }
70
usmHMACMD5AuthProtocol OBJECT-IDENTITY
72
DESCRIPTION "The HMAC-MD5-96 Digest Authentication Protocol."
73
REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti HMAC:
74
Keyed-Hashing for Message Authentication,
76
- Rivest, R., Message Digest Algorithm MD5, RFC1321.
78
::= { snmpAuthProtocols 2 }
80
usmHMACSHAAuthProtocol OBJECT-IDENTITY
82
DESCRIPTION "The HMAC-SHA-96 Digest Authentication Protocol."
83
REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti, HMAC:
84
Keyed-Hashing for Message Authentication,
86
- Secure Hash Algorithm. NIST FIPS 180-1.
88
::= { snmpAuthProtocols 3 }
90
usmNoPrivProtocol OBJECT-IDENTITY
92
DESCRIPTION "No Privacy Protocol."
93
::= { snmpPrivProtocols 1 }
95
usmDESPrivProtocol OBJECT-IDENTITY
97
DESCRIPTION "The CBC-DES Symmetric Encryption Protocol."
98
REFERENCE "- Data Encryption Standard, National Institute of
99
Standards and Technology. Federal Information
100
Processing Standard (FIPS) Publication 46-1.
101
Supersedes FIPS Publication 46,
102
(January, 1977; reaffirmed January, 1988).
104
- Data Encryption Algorithm, American National
105
Standards Institute. ANSI X3.92-1981,
108
- DES Modes of Operation, National Institute of
109
Standards and Technology. Federal Information
110
Processing Standard (FIPS) Publication 81,
113
- Data Encryption Algorithm - Modes of Operation,
114
American National Standards Institute.
115
ANSI X3.106-1983, (May 1983).
117
::= { snmpPrivProtocols 2 }
119
-- Textual Conventions ***********************************************
121
KeyChange ::= TEXTUAL-CONVENTION
124
"Every definition of an object with this syntax must identify
125
a protocol P, a secret key K, and a hash algorithm H
126
that produces output of L octets.
128
The object's value is a manager-generated, partially-random
129
value which, when modified, causes the value of the secret
130
key K, to be modified via a one-way function.
132
The value of an instance of this object is the concatenation
133
of two components: first a 'random' component and then a
136
The lengths of the random and delta components
137
are given by the corresponding value of the protocol P;
138
if P requires K to be a fixed length, the length of both the
139
random and delta components is that fixed length; if P
140
allows the length of K to be variable up to a particular
141
maximum length, the length of the random component is that
142
maximum length and the length of the delta component is any
143
length less than or equal to that maximum length.
144
For example, usmHMACMD5AuthProtocol requires K to be a fixed
145
length of 16 octets and L - of 16 octets.
146
usmHMACSHAAuthProtocol requires K to be a fixed length of
147
20 octets and L - of 20 octets. Other protocols may define
148
other sizes, as deemed appropriate.
150
When a requester wants to change the old key K to a new
151
key keyNew on a remote entity, the 'random' component is
152
obtained from either a true random generator, or from a
153
pseudorandom generator, and the 'delta' component is
156
- a temporary variable is initialized to the existing value
158
- if the length of the keyNew is greater than L octets,
160
- the random component is appended to the value of the
161
temporary variable, and the result is input to the
162
the hash algorithm H to produce a digest value, and
163
the temporary variable is set to this digest value;
164
- the value of the temporary variable is XOR-ed with
165
the first (next) L-octets (16 octets in case of MD5)
166
of the keyNew to produce the first (next) L-octets
167
(16 octets in case of MD5) of the 'delta' component.
168
- the above two steps are repeated until the unused
169
portion of the keyNew component is L octets or less,
170
- the random component is appended to the value of the
171
temporary variable, and the result is input to the
173
hash algorithm H to produce a digest value;
174
- this digest value, truncated if necessary to be the same
175
length as the unused portion of the keyNew, is XOR-ed
176
with the unused portion of the keyNew to produce the
177
(final portion of the) 'delta' component.
179
For example, using MD5 as the hash algorithm H:
181
iterations = (lenOfDelta - 1)/16; /* integer division */
183
for (i = 0; i < iterations; i++) {
184
temp = MD5 (temp || random);
185
delta[i*16 .. (i*16)+15] =
186
temp XOR keyNew[i*16 .. (i*16)+15];
188
temp = MD5 (temp || random);
189
delta[i*16 .. lenOfDelta-1] =
190
temp XOR keyNew[i*16 .. lenOfDelta-1];
192
The 'random' and 'delta' components are then concatenated as
193
described above, and the resulting octet string is sent to
194
the recipient as the new value of an instance of this object.
196
At the receiver side, when an instance of this object is set
197
to a new value, then a new value of K is computed as follows:
199
- a temporary variable is initialized to the existing value
201
- if the length of the delta component is greater than L
203
- the random component is appended to the value of the
204
temporary variable, and the result is input to the
205
hash algorithm H to produce a digest value, and the
206
temporary variable is set to this digest value;
207
- the value of the temporary variable is XOR-ed with
208
the first (next) L-octets (16 octets in case of MD5)
209
of the delta component to produce the first (next)
210
L-octets (16 octets in case of MD5) of the new value
212
- the above two steps are repeated until the unused
213
portion of the delta component is L octets or less,
214
- the random component is appended to the value of the
215
temporary variable, and the result is input to the
216
hash algorithm H to produce a digest value;
217
- this digest value, truncated if necessary to be the same
218
length as the unused portion of the delta component, is
219
XOR-ed with the unused portion of the delta component to
220
produce the (final portion of the) new value of K.
222
For example, using MD5 as the hash algorithm H:
224
iterations = (lenOfDelta - 1)/16; /* integer division */
226
for (i = 0; i < iterations; i++) {
227
temp = MD5 (temp || random);
228
keyNew[i*16 .. (i*16)+15] =
229
temp XOR delta[i*16 .. (i*16)+15];
231
temp = MD5 (temp || random);
232
keyNew[i*16 .. lenOfDelta-1] =
233
temp XOR delta[i*16 .. lenOfDelta-1];
235
The value of an object with this syntax, whenever it is
236
retrieved by the management protocol, is always the zero
239
Note that the keyOld and keyNew are the localized keys.
241
Note that it is probably wise that when an SNMP entity sends
242
a SetRequest to change a key, that it keeps a copy of the old
243
key until it has confirmed that the key change actually
248
-- Statistics for the User-based Security Model **********************
250
usmStats OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
252
usmStatsUnsupportedSecLevels OBJECT-TYPE
256
DESCRIPTION "The total number of packets received by the SNMP
257
engine which were dropped because they requested a
258
securityLevel that was unknown to the SNMP engine
259
or otherwise unavailable.
263
usmStatsNotInTimeWindows OBJECT-TYPE
267
DESCRIPTION "The total number of packets received by the SNMP
268
engine which were dropped because they appeared
269
outside of the authoritative SNMP engine's window.
273
usmStatsUnknownUserNames OBJECT-TYPE
277
DESCRIPTION "The total number of packets received by the SNMP
278
engine which were dropped because they referenced a
279
user that was not known to the SNMP engine.
283
usmStatsUnknownEngineIDs OBJECT-TYPE
287
DESCRIPTION "The total number of packets received by the SNMP
288
engine which were dropped because they referenced an
289
snmpEngineID that was not known to the SNMP engine.
293
usmStatsWrongDigests OBJECT-TYPE
297
DESCRIPTION "The total number of packets received by the SNMP
298
engine which were dropped because they didn't
299
contain the expected digest value.
303
usmStatsDecryptionErrors OBJECT-TYPE
307
DESCRIPTION "The total number of packets received by the SNMP
308
engine which were dropped because they could not be
313
-- The usmUser Group ************************************************
315
usmUser OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
317
usmUserSpinLock OBJECT-TYPE
319
MAX-ACCESS read-write
321
DESCRIPTION "An advisory lock used to allow several cooperating
322
Command Generator Applications to coordinate their
323
use of facilities to alter secrets in the
328
-- The table of valid users for the User-based Security Model ********
330
usmUserTable OBJECT-TYPE
331
SYNTAX SEQUENCE OF UsmUserEntry
332
MAX-ACCESS not-accessible
334
DESCRIPTION "The table of users configured in the SNMP engine's
335
Local Configuration Datastore (LCD).
337
To create a new user (i.e., to instantiate a new
338
conceptual row in this table), it is recommended to
339
follow this procedure:
341
1) GET(usmUserSpinLock.0) and save in sValue.
342
2) SET(usmUserSpinLock.0=sValue,
343
usmUserCloneFrom=templateUser,
344
usmUserStatus=createAndWait)
345
You should use a template user to clone from
346
which has the proper auth/priv protocol defined.
348
If the new user is to use privacy:
350
3) generate the keyChange value based on the secret
351
privKey of the clone-from user and the secret key
352
to be used for the new user. Let us call this
354
4) GET(usmUserSpinLock.0) and save in sValue.
355
5) SET(usmUserSpinLock.0=sValue,
356
usmUserPrivKeyChange=pkcValue
357
usmUserPublic=randomValue1)
358
6) GET(usmUserPulic) and check it has randomValue1.
359
If not, repeat steps 4-6.
361
If the new user will never use privacy:
363
7) SET(usmUserPrivProtocol=usmNoPrivProtocol)
365
If the new user is to use authentication:
367
8) generate the keyChange value based on the secret
368
authKey of the clone-from user and the secret key
369
to be used for the new user. Let us call this
371
9) GET(usmUserSpinLock.0) and save in sValue.
372
10) SET(usmUserSpinLock.0=sValue,
373
usmUserAuthKeyChange=akcValue
374
usmUserPublic=randomValue2)
375
11) GET(usmUserPulic) and check it has randomValue2.
376
If not, repeat steps 9-11.
378
If the new user will never use authentication:
380
12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
382
Finally, activate the new user:
384
13) SET(usmUserStatus=active)
386
The new user should now be available and ready to be
387
used for SNMPv3 communication. Note however that access
388
to MIB data must be provided via configuration of the
389
SNMP-VIEW-BASED-ACM-MIB.
391
The use of usmUserSpinlock is to avoid conflicts with
392
another SNMP command responder application which may
393
also be acting on the usmUserTable.
397
usmUserEntry OBJECT-TYPE
399
MAX-ACCESS not-accessible
401
DESCRIPTION "A user configured in the SNMP engine's Local
402
Configuration Datastore (LCD) for the User-based
405
INDEX { usmUserEngineID,
408
::= { usmUserTable 1 }
410
UsmUserEntry ::= SEQUENCE
413
usmUserEngineID SnmpEngineID,
414
usmUserName SnmpAdminString,
415
usmUserSecurityName SnmpAdminString,
416
usmUserCloneFrom RowPointer,
417
usmUserAuthProtocol AutonomousType,
418
usmUserAuthKeyChange KeyChange,
419
usmUserOwnAuthKeyChange KeyChange,
420
usmUserPrivProtocol AutonomousType,
421
usmUserPrivKeyChange KeyChange,
422
usmUserOwnPrivKeyChange KeyChange,
423
usmUserPublic OCTET STRING,
424
usmUserStorageType StorageType,
425
usmUserStatus RowStatus
428
usmUserEngineID OBJECT-TYPE
430
MAX-ACCESS not-accessible
432
DESCRIPTION "An SNMP engine's administratively-unique identifier.
434
In a simple agent, this value is always that agent's
435
own snmpEngineID value.
437
The value can also take the value of the snmpEngineID
438
of a remote SNMP engine with which this user can
441
::= { usmUserEntry 1 }
443
usmUserName OBJECT-TYPE
444
SYNTAX SnmpAdminString (SIZE(1..32))
445
MAX-ACCESS not-accessible
447
DESCRIPTION "A human readable string representing the name of
450
This is the (User-based Security) Model dependent
453
::= { usmUserEntry 2 }
455
usmUserSecurityName OBJECT-TYPE
456
SYNTAX SnmpAdminString
459
DESCRIPTION "A human readable string representing the user in
461
Security Model independent format.
463
The default transformation of the User-based Security
464
Model dependent security ID to the securityName and
465
vice versa is the identity function so that the
466
securityName is the same as the userName.
468
::= { usmUserEntry 3 }
470
usmUserCloneFrom OBJECT-TYPE
472
MAX-ACCESS read-create
474
DESCRIPTION "A pointer to another conceptual row in this
475
usmUserTable. The user in this other conceptual
476
row is called the clone-from user.
478
When a new user is created (i.e., a new conceptual
479
row is instantiated in this table), the privacy and
480
authentication parameters of the new user must be
481
cloned from its clone-from user. These parameters are:
482
- authentication protocol (usmUserAuthProtocol)
483
- privacy protocol (usmUserPrivProtocol)
484
They will be copied regardless of what the current
487
Cloning also causes the initial values of the secret
488
authentication key (authKey) and the secret encryption
489
key (privKey) of the new user to be set to the same
490
value as the corresponding secret of the clone-from
493
The first time an instance of this object is set by
494
a management operation (either at or after its
495
instantiation), the cloning process is invoked.
496
Subsequent writes are successful but invoke no
497
action to be taken by the receiver.
498
The cloning process fails with an 'inconsistentName'
499
error if the conceptual row representing the
500
clone-from user does not exist or is not in an active
501
state when the cloning process is invoked.
503
When this object is read, the ZeroDotZero OID
506
::= { usmUserEntry 4 }
508
usmUserAuthProtocol OBJECT-TYPE
509
SYNTAX AutonomousType
510
MAX-ACCESS read-create
512
DESCRIPTION "An indication of whether messages sent on behalf of
513
this user to/from the SNMP engine identified by
514
usmUserEngineID, can be authenticated, and if so,
515
the type of authentication protocol which is used.
517
An instance of this object is created concurrently
518
with the creation of any other object instance for
519
the same user (i.e., as part of the processing of
520
the set operation which creates the first object
521
instance in the same conceptual row).
523
If an initial set operation (i.e. at row creation time)
524
tries to set a value for an unknown or unsupported
525
protocol, then a 'wrongValue' error must be returned.
527
The value will be overwritten/set when a set operation
528
is performed on the corresponding instance of
531
Once instantiated, the value of such an instance of
532
this object can only be changed via a set operation to
533
the value of the usmNoAuthProtocol.
535
If a set operation tries to change the value of an
536
existing instance of this object to any value other
537
than usmNoAuthProtocol, then an 'inconsistentValue'
538
error must be returned.
540
If a set operation tries to set the value to the
541
usmNoAuthProtocol while the usmUserPrivProtocol value
542
in the same row is not equal to usmNoPrivProtocol,
543
then an 'inconsistentValue' error must be returned.
544
That means that an SNMP command generator application
545
must first ensure that the usmUserPrivProtocol is set
546
to the usmNoPrivProtocol value before it can set
547
the usmUserAuthProtocol value to usmNoAuthProtocol.
549
DEFVAL { usmNoAuthProtocol }
550
::= { usmUserEntry 5 }
552
usmUserAuthKeyChange OBJECT-TYPE
553
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5
554
-- typically (SIZE (0 | 40)) for HMACSHA
555
MAX-ACCESS read-create
557
DESCRIPTION "An object, which when modified, causes the secret
558
authentication key used for messages sent on behalf
559
of this user to/from the SNMP engine identified by
560
usmUserEngineID, to be modified via a one-way
563
The associated protocol is the usmUserAuthProtocol.
564
The associated secret key is the user's secret
565
authentication key (authKey). The associated hash
566
algorithm is the algorithm used by the user's
569
When creating a new user, it is an 'inconsistentName'
570
error for a set operation to refer to this object
571
unless it is previously or concurrently initialized
572
through a set operation on the corresponding instance
575
When the value of the corresponding usmUserAuthProtocol
576
is usmNoAuthProtocol, then a set is successful, but
577
effectively is a no-op.
579
When this object is read, the zero-length (empty)
582
The recommended way to do a key change is as follows:
584
1) GET(usmUserSpinLock.0) and save in sValue.
585
2) generate the keyChange value based on the old
586
(existing) secret key and the new secret key,
587
let us call this kcValue.
589
If you do the key change on behalf of another user:
591
3) SET(usmUserSpinLock.0=sValue,
592
usmUserAuthKeyChange=kcValue
593
usmUserPublic=randomValue)
595
If you do the key change for yourself:
597
4) SET(usmUserSpinLock.0=sValue,
598
usmUserOwnAuthKeyChange=kcValue
599
usmUserPublic=randomValue)
601
If you get a response with error-status of noError,
602
then the SET succeeded and the new key is active.
603
If you do not get a response, then you can issue a
604
GET(usmUserPublic) and check if the value is equal
606
to the randomValue you did send in the SET. If so, then
607
the key change succeeded and the new key is active
608
(probably the response got lost). If not, then the SET
609
request probably never reached the target and so you
610
can start over with the procedure above.
612
DEFVAL { ''H } -- the empty string
613
::= { usmUserEntry 6 }
615
usmUserOwnAuthKeyChange OBJECT-TYPE
616
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5
617
-- typically (SIZE (0 | 40)) for HMACSHA
618
MAX-ACCESS read-create
620
DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one
621
notable difference: in order for the set operation
622
to succeed, the usmUserName of the operation
623
requester must match the usmUserName that
624
indexes the row which is targeted by this
626
In addition, the USM security model must be
627
used for this operation.
629
The idea here is that access to this column can be
630
public, since it will only allow a user to change
631
his own secret authentication key (authKey).
632
Note that this can only be done once the row is active.
634
When a set is received and the usmUserName of the
635
requester is not the same as the umsUserName that
636
indexes the row which is targeted by this operation,
637
then a 'noAccess' error must be returned.
639
When a set is received and the security model in use
640
is not USM, then a 'noAccess' error must be returned.
642
DEFVAL { ''H } -- the empty string
643
::= { usmUserEntry 7 }
645
usmUserPrivProtocol OBJECT-TYPE
646
SYNTAX AutonomousType
647
MAX-ACCESS read-create
649
DESCRIPTION "An indication of whether messages sent on behalf of
650
this user to/from the SNMP engine identified by
651
usmUserEngineID, can be protected from disclosure,
652
and if so, the type of privacy protocol which is used.
654
An instance of this object is created concurrently
655
with the creation of any other object instance for
656
the same user (i.e., as part of the processing of
657
the set operation which creates the first object
658
instance in the same conceptual row).
660
If an initial set operation (i.e. at row creation time)
661
tries to set a value for an unknown or unsupported
662
protocol, then a 'wrongValue' error must be returned.
664
The value will be overwritten/set when a set operation
665
is performed on the corresponding instance of
668
Once instantiated, the value of such an instance of
669
this object can only be changed via a set operation to
670
the value of the usmNoPrivProtocol.
672
If a set operation tries to change the value of an
673
existing instance of this object to any value other
674
than usmNoPrivProtocol, then an 'inconsistentValue'
675
error must be returned.
677
Note that if any privacy protocol is used, then you
678
must also use an authentication protocol. In other
679
words, if usmUserPrivProtocol is set to anything else
680
than usmNoPrivProtocol, then the corresponding instance
681
of usmUserAuthProtocol cannot have a value of
682
usmNoAuthProtocol. If it does, then an
683
'inconsistentValue' error must be returned.
685
DEFVAL { usmNoPrivProtocol }
686
::= { usmUserEntry 8 }
688
usmUserPrivKeyChange OBJECT-TYPE
689
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES
690
MAX-ACCESS read-create
692
DESCRIPTION "An object, which when modified, causes the secret
693
encryption key used for messages sent on behalf
694
of this user to/from the SNMP engine identified by
695
usmUserEngineID, to be modified via a one-way
698
The associated protocol is the usmUserPrivProtocol.
699
The associated secret key is the user's secret
700
privacy key (privKey). The associated hash
701
algorithm is the algorithm used by the user's
705
When creating a new user, it is an 'inconsistentName'
706
error for a set operation to refer to this object
707
unless it is previously or concurrently initialized
708
through a set operation on the corresponding instance
711
When the value of the corresponding usmUserPrivProtocol
712
is usmNoPrivProtocol, then a set is successful, but
713
effectively is a no-op.
715
When this object is read, the zero-length (empty)
717
See the description clause of usmUserAuthKeyChange for
718
a recommended procedure to do a key change.
720
DEFVAL { ''H } -- the empty string
721
::= { usmUserEntry 9 }
723
usmUserOwnPrivKeyChange OBJECT-TYPE
724
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES
725
MAX-ACCESS read-create
727
DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one
728
notable difference: in order for the Set operation
729
to succeed, the usmUserName of the operation
730
requester must match the usmUserName that indexes
731
the row which is targeted by this operation.
732
In addition, the USM security model must be
733
used for this operation.
735
The idea here is that access to this column can be
736
public, since it will only allow a user to change
737
his own secret privacy key (privKey).
738
Note that this can only be done once the row is active.
740
When a set is received and the usmUserName of the
741
requester is not the same as the umsUserName that
742
indexes the row which is targeted by this operation,
743
then a 'noAccess' error must be returned.
745
When a set is received and the security model in use
746
is not USM, then a 'noAccess' error must be returned.
748
DEFVAL { ''H } -- the empty string
749
::= { usmUserEntry 10 }
751
usmUserPublic OBJECT-TYPE
752
SYNTAX OCTET STRING (SIZE(0..32))
753
MAX-ACCESS read-create
755
DESCRIPTION "A publicly-readable value which can be written as part
756
of the procedure for changing a user's secret
757
authentication and/or privacy key, and later read to
758
determine whether the change of the secret was
761
DEFVAL { ''H } -- the empty string
762
::= { usmUserEntry 11 }
764
usmUserStorageType OBJECT-TYPE
766
MAX-ACCESS read-create
768
DESCRIPTION "The storage type for this conceptual row.
770
Conceptual rows having the value 'permanent' must
771
allow write-access at a minimum to:
773
- usmUserAuthKeyChange, usmUserOwnAuthKeyChange
774
and usmUserPublic for a user who employs
776
- usmUserPrivKeyChange, usmUserOwnPrivKeyChange
777
and usmUserPublic for a user who employs
780
Note that any user who employs authentication or
781
privacy must allow its secret(s) to be updated and
782
thus cannot be 'readOnly'.
784
If an initial set operation tries to set the value to
785
'readOnly' for a user who employs authentication or
786
privacy, then an 'inconsistentValue' error must be
787
returned. Note that if the value has been previously
788
set (implicit or explicit) to any value, then the rules
789
as defined in the StorageType Textual Convention apply.
791
It is an implementation issue to decide if a SET for
792
a readOnly or permanent row is accepted at all. In some
793
contexts this may make sense, in others it may not. If
794
a SET for a readOnly or permanent row is not accepted
795
at all, then a 'wrongValue' error must be returned.
797
DEFVAL { nonVolatile }
798
::= { usmUserEntry 12 }
800
usmUserStatus OBJECT-TYPE
802
MAX-ACCESS read-create
804
DESCRIPTION "The status of this conceptual row.
806
Until instances of all corresponding columns are
807
appropriately configured, the value of the
808
corresponding instance of the usmUserStatus column
811
In particular, a newly created row for a user who
812
employs authentication, cannot be made active until the
813
corresponding usmUserCloneFrom and usmUserAuthKeyChange
816
Further, a newly created row for a user who also
817
employs privacy, cannot be made active until the
818
usmUserPrivKeyChange has been set.
820
The RowStatus TC [RFC2579] requires that this
821
DESCRIPTION clause states under which circumstances
822
other objects in this row can be modified:
824
The value of this object has no effect on whether
825
other objects in this conceptual row can be modified,
826
except for usmUserOwnAuthKeyChange and
827
usmUserOwnPrivKeyChange. For these 2 objects, the
828
value of usmUserStatus MUST be active.
830
::= { usmUserEntry 13 }
832
-- Conformance Information *******************************************
834
usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
835
usmMIBGroups OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
837
-- Compliance statements
839
usmMIBCompliance MODULE-COMPLIANCE
841
DESCRIPTION "The compliance statement for SNMP engines which
842
implement the SNMP-USER-BASED-SM-MIB.
845
MODULE -- this module
846
MANDATORY-GROUPS { usmMIBBasicGroup }
848
OBJECT usmUserAuthProtocol
850
DESCRIPTION "Write access is not required."
852
OBJECT usmUserPrivProtocol
854
DESCRIPTION "Write access is not required."
855
::= { usmMIBCompliances 1 }
857
-- Units of compliance
858
usmMIBBasicGroup OBJECT-GROUP
860
usmStatsUnsupportedSecLevels,
861
usmStatsNotInTimeWindows,
862
usmStatsUnknownUserNames,
863
usmStatsUnknownEngineIDs,
864
usmStatsWrongDigests,
865
usmStatsDecryptionErrors,
870
usmUserAuthKeyChange,
871
usmUserOwnAuthKeyChange,
873
usmUserPrivKeyChange,
874
usmUserOwnPrivKeyChange,
880
DESCRIPTION "A collection of objects providing for configuration
881
of an SNMP engine which implements the SNMP
882
User-based Security Model.
884
::= { usmMIBGroups 1 }
added
removed
install-files/bin/php/php5.2.5/extras/mibs/SNMP-USER-BASED-SM-MIB.txt
