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 "200210160000Z" -- 16 Oct 2002, 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
Network Associates Laboratories
23
postal: 15204 Omega Drive, Suite 300
24
Rockville, MD 20850-4601
26
email: mundy@tislabs.com
28
phone: +1 301-947-7107
30
Co-Chair: David Harrington
32
Postal: 35 Industrial Way
34
Rochester, New Hampshire 03866-5005
36
EMail: dbh@enterasys.com
37
Phone: +1 603-337-2614
39
Co-editor Uri Blumenthal
41
postal: 67 Whippany Rd.
45
phone: +1-973-386-2163
47
Co-editor: Bert Wijnen
52
email: bwijnen@lucent.com
53
phone: +31-348-480-685
55
DESCRIPTION "The management information definitions for the
56
SNMP User-based Security Model.
58
Copyright (C) The Internet Society (2002). This
59
version of this MIB module is part of RFC 3414;
60
see the RFC itself for full legal notices.
63
REVISION "200210160000Z" -- 16 Oct 2002, midnight
64
DESCRIPTION "Changes in this revision:
65
- Updated references and contact info.
66
- Clarification to usmUserCloneFrom DESCRIPTION
68
- Fixed 'command responder' into 'command generator'
69
in last para of DESCRIPTION clause of
71
This revision published as RFC3414.
73
REVISION "199901200000Z" -- 20 Jan 1999, midnight
74
DESCRIPTION "Clarifications, published as RFC2574"
76
REVISION "199711200000Z" -- 20 Nov 1997, midnight
77
DESCRIPTION "Initial version, published as RFC2274"
78
::= { snmpModules 15 }
81
usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
82
usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
85
usmNoAuthProtocol OBJECT-IDENTITY
87
DESCRIPTION "No Authentication Protocol."
88
::= { snmpAuthProtocols 1 }
90
usmHMACMD5AuthProtocol OBJECT-IDENTITY
92
DESCRIPTION "The HMAC-MD5-96 Digest Authentication Protocol."
93
REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti HMAC:
94
Keyed-Hashing for Message Authentication,
96
- Rivest, R., Message Digest Algorithm MD5, RFC1321.
98
::= { snmpAuthProtocols 2 }
100
usmHMACSHAAuthProtocol OBJECT-IDENTITY
102
DESCRIPTION "The HMAC-SHA-96 Digest Authentication Protocol."
103
REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti, HMAC:
104
Keyed-Hashing for Message Authentication,
106
- Secure Hash Algorithm. NIST FIPS 180-1.
108
::= { snmpAuthProtocols 3 }
110
usmNoPrivProtocol OBJECT-IDENTITY
112
DESCRIPTION "No Privacy Protocol."
113
::= { snmpPrivProtocols 1 }
115
usmDESPrivProtocol OBJECT-IDENTITY
117
DESCRIPTION "The CBC-DES Symmetric Encryption Protocol."
118
REFERENCE "- Data Encryption Standard, National Institute of
119
Standards and Technology. Federal Information
120
Processing Standard (FIPS) Publication 46-1.
122
Supersedes FIPS Publication 46,
123
(January, 1977; reaffirmed January, 1988).
125
- Data Encryption Algorithm, American National
126
Standards Institute. ANSI X3.92-1981,
129
- DES Modes of Operation, National Institute of
130
Standards and Technology. Federal Information
131
Processing Standard (FIPS) Publication 81,
134
- Data Encryption Algorithm - Modes of Operation,
135
American National Standards Institute.
136
ANSI X3.106-1983, (May 1983).
138
::= { snmpPrivProtocols 2 }
141
KeyChange ::= TEXTUAL-CONVENTION
144
"Every definition of an object with this syntax must identify
145
a protocol P, a secret key K, and a hash algorithm H
146
that produces output of L octets.
148
The object's value is a manager-generated, partially-random
149
value which, when modified, causes the value of the secret
150
key K, to be modified via a one-way function.
152
The value of an instance of this object is the concatenation
153
of two components: first a 'random' component and then a
156
The lengths of the random and delta components
157
are given by the corresponding value of the protocol P;
158
if P requires K to be a fixed length, the length of both the
159
random and delta components is that fixed length; if P
160
allows the length of K to be variable up to a particular
161
maximum length, the length of the random component is that
162
maximum length and the length of the delta component is any
163
length less than or equal to that maximum length.
164
For example, usmHMACMD5AuthProtocol requires K to be a fixed
165
length of 16 octets and L - of 16 octets.
166
usmHMACSHAAuthProtocol requires K to be a fixed length of
167
20 octets and L - of 20 octets. Other protocols may define
168
other sizes, as deemed appropriate.
170
When a requester wants to change the old key K to a new
171
key keyNew on a remote entity, the 'random' component is
172
obtained from either a true random generator, or from a
173
pseudorandom generator, and the 'delta' component is
176
- a temporary variable is initialized to the existing value
178
- if the length of the keyNew is greater than L octets,
180
- the random component is appended to the value of the
181
temporary variable, and the result is input to the
182
the hash algorithm H to produce a digest value, and
183
the temporary variable is set to this digest value;
184
- the value of the temporary variable is XOR-ed with
185
the first (next) L-octets (16 octets in case of MD5)
186
of the keyNew to produce the first (next) L-octets
187
(16 octets in case of MD5) of the 'delta' component.
188
- the above two steps are repeated until the unused
189
portion of the keyNew component is L octets or less,
190
- the random component is appended to the value of the
191
temporary variable, and the result is input to the
192
hash algorithm H to produce a digest value;
193
- this digest value, truncated if necessary to be the same
194
length as the unused portion of the keyNew, is XOR-ed
195
with the unused portion of the keyNew to produce the
196
(final portion of the) 'delta' component.
198
For example, using MD5 as the hash algorithm H:
200
iterations = (lenOfDelta - 1)/16; /* integer division */
202
for (i = 0; i < iterations; i++) {
203
temp = MD5 (temp || random);
204
delta[i*16 .. (i*16)+15] =
205
temp XOR keyNew[i*16 .. (i*16)+15];
207
temp = MD5 (temp || random);
208
delta[i*16 .. lenOfDelta-1] =
209
temp XOR keyNew[i*16 .. lenOfDelta-1];
211
The 'random' and 'delta' components are then concatenated as
212
described above, and the resulting octet string is sent to
213
the recipient as the new value of an instance of this object.
215
At the receiver side, when an instance of this object is set
216
to a new value, then a new value of K is computed as follows:
218
- a temporary variable is initialized to the existing value
220
- if the length of the delta component is greater than L
222
- the random component is appended to the value of the
223
temporary variable, and the result is input to the
224
hash algorithm H to produce a digest value, and the
225
temporary variable is set to this digest value;
226
- the value of the temporary variable is XOR-ed with
227
the first (next) L-octets (16 octets in case of MD5)
228
of the delta component to produce the first (next)
229
L-octets (16 octets in case of MD5) of the new value
231
- the above two steps are repeated until the unused
232
portion of the delta component is L octets or less,
233
- the random component is appended to the value of the
234
temporary variable, and the result is input to the
235
hash algorithm H to produce a digest value;
236
- this digest value, truncated if necessary to be the same
237
length as the unused portion of the delta component, is
238
XOR-ed with the unused portion of the delta component to
239
produce the (final portion of the) new value of K.
241
For example, using MD5 as the hash algorithm H:
243
iterations = (lenOfDelta - 1)/16; /* integer division */
245
for (i = 0; i < iterations; i++) {
246
temp = MD5 (temp || random);
247
keyNew[i*16 .. (i*16)+15] =
248
temp XOR delta[i*16 .. (i*16)+15];
250
temp = MD5 (temp || random);
251
keyNew[i*16 .. lenOfDelta-1] =
252
temp XOR delta[i*16 .. lenOfDelta-1];
254
The value of an object with this syntax, whenever it is
255
retrieved by the management protocol, is always the zero
258
Note that the keyOld and keyNew are the localized keys.
260
Note that it is probably wise that when an SNMP entity sends
261
a SetRequest to change a key, that it keeps a copy of the old
262
key until it has confirmed that the key change actually
268
usmStats OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
270
usmStatsUnsupportedSecLevels OBJECT-TYPE
274
DESCRIPTION "The total number of packets received by the SNMP
275
engine which were dropped because they requested a
276
securityLevel that was unknown to the SNMP engine
277
or otherwise unavailable.
281
usmStatsNotInTimeWindows OBJECT-TYPE
285
DESCRIPTION "The total number of packets received by the SNMP
286
engine which were dropped because they appeared
287
outside of the authoritative SNMP engine's window.
291
usmStatsUnknownUserNames OBJECT-TYPE
295
DESCRIPTION "The total number of packets received by the SNMP
296
engine which were dropped because they referenced a
297
user that was not known to the SNMP engine.
301
usmStatsUnknownEngineIDs OBJECT-TYPE
305
DESCRIPTION "The total number of packets received by the SNMP
306
engine which were dropped because they referenced an
307
snmpEngineID that was not known to the SNMP engine.
311
usmStatsWrongDigests OBJECT-TYPE
315
DESCRIPTION "The total number of packets received by the SNMP
316
engine which were dropped because they didn't
317
contain the expected digest value.
321
usmStatsDecryptionErrors OBJECT-TYPE
325
DESCRIPTION "The total number of packets received by the SNMP
326
engine which were dropped because they could not be
332
usmUser OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
334
usmUserSpinLock OBJECT-TYPE
336
MAX-ACCESS read-write
338
DESCRIPTION "An advisory lock used to allow several cooperating
339
Command Generator Applications to coordinate their
340
use of facilities to alter secrets in the
346
usmUserTable OBJECT-TYPE
347
SYNTAX SEQUENCE OF UsmUserEntry
348
MAX-ACCESS not-accessible
350
DESCRIPTION "The table of users configured in the SNMP engine's
351
Local Configuration Datastore (LCD).
353
To create a new user (i.e., to instantiate a new
354
conceptual row in this table), it is recommended to
355
follow this procedure:
357
1) GET(usmUserSpinLock.0) and save in sValue.
359
2) SET(usmUserSpinLock.0=sValue,
360
usmUserCloneFrom=templateUser,
361
usmUserStatus=createAndWait)
362
You should use a template user to clone from
363
which has the proper auth/priv protocol defined.
365
If the new user is to use privacy:
367
3) generate the keyChange value based on the secret
368
privKey of the clone-from user and the secret key
369
to be used for the new user. Let us call this
371
4) GET(usmUserSpinLock.0) and save in sValue.
372
5) SET(usmUserSpinLock.0=sValue,
373
usmUserPrivKeyChange=pkcValue
374
usmUserPublic=randomValue1)
375
6) GET(usmUserPulic) and check it has randomValue1.
376
If not, repeat steps 4-6.
378
If the new user will never use privacy:
380
7) SET(usmUserPrivProtocol=usmNoPrivProtocol)
382
If the new user is to use authentication:
384
8) generate the keyChange value based on the secret
385
authKey of the clone-from user and the secret key
386
to be used for the new user. Let us call this
388
9) GET(usmUserSpinLock.0) and save in sValue.
389
10) SET(usmUserSpinLock.0=sValue,
390
usmUserAuthKeyChange=akcValue
391
usmUserPublic=randomValue2)
392
11) GET(usmUserPulic) and check it has randomValue2.
393
If not, repeat steps 9-11.
395
If the new user will never use authentication:
397
12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
399
Finally, activate the new user:
401
13) SET(usmUserStatus=active)
403
The new user should now be available and ready to be
404
used for SNMPv3 communication. Note however that access
405
to MIB data must be provided via configuration of the
406
SNMP-VIEW-BASED-ACM-MIB.
408
The use of usmUserSpinlock is to avoid conflicts with
409
another SNMP command generator application which may
410
also be acting on the usmUserTable.
414
usmUserEntry OBJECT-TYPE
416
MAX-ACCESS not-accessible
418
DESCRIPTION "A user configured in the SNMP engine's Local
419
Configuration Datastore (LCD) for the User-based
422
INDEX { usmUserEngineID,
425
::= { usmUserTable 1 }
427
UsmUserEntry ::= SEQUENCE
429
usmUserEngineID SnmpEngineID,
430
usmUserName SnmpAdminString,
431
usmUserSecurityName SnmpAdminString,
432
usmUserCloneFrom RowPointer,
433
usmUserAuthProtocol AutonomousType,
434
usmUserAuthKeyChange KeyChange,
435
usmUserOwnAuthKeyChange KeyChange,
436
usmUserPrivProtocol AutonomousType,
437
usmUserPrivKeyChange KeyChange,
438
usmUserOwnPrivKeyChange KeyChange,
439
usmUserPublic OCTET STRING,
440
usmUserStorageType StorageType,
441
usmUserStatus RowStatus
444
usmUserEngineID OBJECT-TYPE
446
MAX-ACCESS not-accessible
448
DESCRIPTION "An SNMP engine's administratively-unique identifier.
450
In a simple agent, this value is always that agent's
451
own snmpEngineID value.
453
The value can also take the value of the snmpEngineID
454
of a remote SNMP engine with which this user can
457
::= { usmUserEntry 1 }
459
usmUserName OBJECT-TYPE
460
SYNTAX SnmpAdminString (SIZE(1..32))
461
MAX-ACCESS not-accessible
463
DESCRIPTION "A human readable string representing the name of
466
This is the (User-based Security) Model dependent
469
::= { usmUserEntry 2 }
471
usmUserSecurityName OBJECT-TYPE
472
SYNTAX SnmpAdminString
475
DESCRIPTION "A human readable string representing the user in
476
Security Model independent format.
478
The default transformation of the User-based Security
479
Model dependent security ID to the securityName and
480
vice versa is the identity function so that the
481
securityName is the same as the userName.
483
::= { usmUserEntry 3 }
485
usmUserCloneFrom OBJECT-TYPE
487
MAX-ACCESS read-create
489
DESCRIPTION "A pointer to another conceptual row in this
490
usmUserTable. The user in this other conceptual
491
row is called the clone-from user.
493
When a new user is created (i.e., a new conceptual
494
row is instantiated in this table), the privacy and
495
authentication parameters of the new user must be
496
cloned from its clone-from user. These parameters are:
497
- authentication protocol (usmUserAuthProtocol)
498
- privacy protocol (usmUserPrivProtocol)
499
They will be copied regardless of what the current
502
Cloning also causes the initial values of the secret
503
authentication key (authKey) and the secret encryption
505
key (privKey) of the new user to be set to the same
506
values as the corresponding secrets of the clone-from
507
user to allow the KeyChange process to occur as
508
required during user creation.
510
The first time an instance of this object is set by
511
a management operation (either at or after its
512
instantiation), the cloning process is invoked.
513
Subsequent writes are successful but invoke no
514
action to be taken by the receiver.
515
The cloning process fails with an 'inconsistentName'
516
error if the conceptual row representing the
517
clone-from user does not exist or is not in an active
518
state when the cloning process is invoked.
520
When this object is read, the ZeroDotZero OID
523
::= { usmUserEntry 4 }
525
usmUserAuthProtocol OBJECT-TYPE
526
SYNTAX AutonomousType
527
MAX-ACCESS read-create
529
DESCRIPTION "An indication of whether messages sent on behalf of
530
this user to/from the SNMP engine identified by
531
usmUserEngineID, can be authenticated, and if so,
532
the type of authentication protocol which is used.
534
An instance of this object is created concurrently
535
with the creation of any other object instance for
536
the same user (i.e., as part of the processing of
537
the set operation which creates the first object
538
instance in the same conceptual row).
540
If an initial set operation (i.e. at row creation time)
541
tries to set a value for an unknown or unsupported
542
protocol, then a 'wrongValue' error must be returned.
544
The value will be overwritten/set when a set operation
545
is performed on the corresponding instance of
548
Once instantiated, the value of such an instance of
549
this object can only be changed via a set operation to
550
the value of the usmNoAuthProtocol.
552
If a set operation tries to change the value of an
554
existing instance of this object to any value other
555
than usmNoAuthProtocol, then an 'inconsistentValue'
556
error must be returned.
558
If a set operation tries to set the value to the
559
usmNoAuthProtocol while the usmUserPrivProtocol value
560
in the same row is not equal to usmNoPrivProtocol,
561
then an 'inconsistentValue' error must be returned.
562
That means that an SNMP command generator application
563
must first ensure that the usmUserPrivProtocol is set
564
to the usmNoPrivProtocol value before it can set
565
the usmUserAuthProtocol value to usmNoAuthProtocol.
567
DEFVAL { usmNoAuthProtocol }
568
::= { usmUserEntry 5 }
570
usmUserAuthKeyChange OBJECT-TYPE
571
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5
572
-- typically (SIZE (0 | 40)) for HMACSHA
573
MAX-ACCESS read-create
575
DESCRIPTION "An object, which when modified, causes the secret
576
authentication key used for messages sent on behalf
577
of this user to/from the SNMP engine identified by
578
usmUserEngineID, to be modified via a one-way
581
The associated protocol is the usmUserAuthProtocol.
582
The associated secret key is the user's secret
583
authentication key (authKey). The associated hash
584
algorithm is the algorithm used by the user's
587
When creating a new user, it is an 'inconsistentName'
588
error for a set operation to refer to this object
589
unless it is previously or concurrently initialized
590
through a set operation on the corresponding instance
593
When the value of the corresponding usmUserAuthProtocol
594
is usmNoAuthProtocol, then a set is successful, but
595
effectively is a no-op.
597
When this object is read, the zero-length (empty)
600
The recommended way to do a key change is as follows:
602
1) GET(usmUserSpinLock.0) and save in sValue.
603
2) generate the keyChange value based on the old
604
(existing) secret key and the new secret key,
605
let us call this kcValue.
607
If you do the key change on behalf of another user:
609
3) SET(usmUserSpinLock.0=sValue,
610
usmUserAuthKeyChange=kcValue
611
usmUserPublic=randomValue)
613
If you do the key change for yourself:
615
4) SET(usmUserSpinLock.0=sValue,
616
usmUserOwnAuthKeyChange=kcValue
617
usmUserPublic=randomValue)
619
If you get a response with error-status of noError,
620
then the SET succeeded and the new key is active.
621
If you do not get a response, then you can issue a
622
GET(usmUserPublic) and check if the value is equal
623
to the randomValue you did send in the SET. If so, then
624
the key change succeeded and the new key is active
625
(probably the response got lost). If not, then the SET
626
request probably never reached the target and so you
627
can start over with the procedure above.
629
DEFVAL { ''H } -- the empty string
630
::= { usmUserEntry 6 }
632
usmUserOwnAuthKeyChange OBJECT-TYPE
633
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5
634
-- typically (SIZE (0 | 40)) for HMACSHA
635
MAX-ACCESS read-create
637
DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one
638
notable difference: in order for the set operation
639
to succeed, the usmUserName of the operation
640
requester must match the usmUserName that
641
indexes the row which is targeted by this
643
In addition, the USM security model must be
644
used for this operation.
646
The idea here is that access to this column can be
647
public, since it will only allow a user to change
648
his own secret authentication key (authKey).
649
Note that this can only be done once the row is active.
651
When a set is received and the usmUserName of the
652
requester is not the same as the umsUserName that
653
indexes the row which is targeted by this operation,
654
then a 'noAccess' error must be returned.
656
When a set is received and the security model in use
657
is not USM, then a 'noAccess' error must be returned.
659
DEFVAL { ''H } -- the empty string
660
::= { usmUserEntry 7 }
662
usmUserPrivProtocol OBJECT-TYPE
663
SYNTAX AutonomousType
664
MAX-ACCESS read-create
666
DESCRIPTION "An indication of whether messages sent on behalf of
667
this user to/from the SNMP engine identified by
668
usmUserEngineID, can be protected from disclosure,
669
and if so, the type of privacy protocol which is used.
671
An instance of this object is created concurrently
672
with the creation of any other object instance for
673
the same user (i.e., as part of the processing of
674
the set operation which creates the first object
675
instance in the same conceptual row).
677
If an initial set operation (i.e. at row creation time)
678
tries to set a value for an unknown or unsupported
679
protocol, then a 'wrongValue' error must be returned.
681
The value will be overwritten/set when a set operation
682
is performed on the corresponding instance of
685
Once instantiated, the value of such an instance of
686
this object can only be changed via a set operation to
687
the value of the usmNoPrivProtocol.
689
If a set operation tries to change the value of an
690
existing instance of this object to any value other
691
than usmNoPrivProtocol, then an 'inconsistentValue'
692
error must be returned.
694
Note that if any privacy protocol is used, then you
695
must also use an authentication protocol. In other
696
words, if usmUserPrivProtocol is set to anything else
697
than usmNoPrivProtocol, then the corresponding instance
698
of usmUserAuthProtocol cannot have a value of
700
usmNoAuthProtocol. If it does, then an
701
'inconsistentValue' error must be returned.
703
DEFVAL { usmNoPrivProtocol }
704
::= { usmUserEntry 8 }
706
usmUserPrivKeyChange OBJECT-TYPE
707
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES
708
MAX-ACCESS read-create
710
DESCRIPTION "An object, which when modified, causes the secret
711
encryption key used for messages sent on behalf
712
of this user to/from the SNMP engine identified by
713
usmUserEngineID, to be modified via a one-way
716
The associated protocol is the usmUserPrivProtocol.
717
The associated secret key is the user's secret
718
privacy key (privKey). The associated hash
719
algorithm is the algorithm used by the user's
722
When creating a new user, it is an 'inconsistentName'
723
error for a set operation to refer to this object
724
unless it is previously or concurrently initialized
725
through a set operation on the corresponding instance
728
When the value of the corresponding usmUserPrivProtocol
729
is usmNoPrivProtocol, then a set is successful, but
730
effectively is a no-op.
732
When this object is read, the zero-length (empty)
734
See the description clause of usmUserAuthKeyChange for
735
a recommended procedure to do a key change.
737
DEFVAL { ''H } -- the empty string
738
::= { usmUserEntry 9 }
740
usmUserOwnPrivKeyChange OBJECT-TYPE
741
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES
742
MAX-ACCESS read-create
744
DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one
745
notable difference: in order for the Set operation
746
to succeed, the usmUserName of the operation
747
requester must match the usmUserName that indexes
749
the row which is targeted by this operation.
750
In addition, the USM security model must be
751
used for this operation.
753
The idea here is that access to this column can be
754
public, since it will only allow a user to change
755
his own secret privacy key (privKey).
756
Note that this can only be done once the row is active.
758
When a set is received and the usmUserName of the
759
requester is not the same as the umsUserName that
760
indexes the row which is targeted by this operation,
761
then a 'noAccess' error must be returned.
763
When a set is received and the security model in use
764
is not USM, then a 'noAccess' error must be returned.
766
DEFVAL { ''H } -- the empty string
767
::= { usmUserEntry 10 }
769
usmUserPublic OBJECT-TYPE
770
SYNTAX OCTET STRING (SIZE(0..32))
771
MAX-ACCESS read-create
773
DESCRIPTION "A publicly-readable value which can be written as part
774
of the procedure for changing a user's secret
775
authentication and/or privacy key, and later read to
776
determine whether the change of the secret was
779
DEFVAL { ''H } -- the empty string
780
::= { usmUserEntry 11 }
782
usmUserStorageType OBJECT-TYPE
784
MAX-ACCESS read-create
786
DESCRIPTION "The storage type for this conceptual row.
788
Conceptual rows having the value 'permanent' must
789
allow write-access at a minimum to:
791
- usmUserAuthKeyChange, usmUserOwnAuthKeyChange
792
and usmUserPublic for a user who employs
794
- usmUserPrivKeyChange, usmUserOwnPrivKeyChange
795
and usmUserPublic for a user who employs
798
Note that any user who employs authentication or
799
privacy must allow its secret(s) to be updated and
800
thus cannot be 'readOnly'.
802
If an initial set operation tries to set the value to
803
'readOnly' for a user who employs authentication or
804
privacy, then an 'inconsistentValue' error must be
805
returned. Note that if the value has been previously
806
set (implicit or explicit) to any value, then the rules
807
as defined in the StorageType Textual Convention apply.
809
It is an implementation issue to decide if a SET for
810
a readOnly or permanent row is accepted at all. In some
811
contexts this may make sense, in others it may not. If
812
a SET for a readOnly or permanent row is not accepted
813
at all, then a 'wrongValue' error must be returned.
815
DEFVAL { nonVolatile }
816
::= { usmUserEntry 12 }
818
usmUserStatus OBJECT-TYPE
820
MAX-ACCESS read-create
822
DESCRIPTION "The status of this conceptual row.
824
Until instances of all corresponding columns are
825
appropriately configured, the value of the
826
corresponding instance of the usmUserStatus column
829
In particular, a newly created row for a user who
830
employs authentication, cannot be made active until the
831
corresponding usmUserCloneFrom and usmUserAuthKeyChange
834
Further, a newly created row for a user who also
835
employs privacy, cannot be made active until the
836
usmUserPrivKeyChange has been set.
838
The RowStatus TC [RFC2579] requires that this
839
DESCRIPTION clause states under which circumstances
840
other objects in this row can be modified:
842
The value of this object has no effect on whether
843
other objects in this conceptual row can be modified,
844
except for usmUserOwnAuthKeyChange and
845
usmUserOwnPrivKeyChange. For these 2 objects, the
847
value of usmUserStatus MUST be active.
849
::= { usmUserEntry 13 }
852
usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
853
usmMIBGroups OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
856
usmMIBCompliance MODULE-COMPLIANCE
858
DESCRIPTION "The compliance statement for SNMP engines which
859
implement the SNMP-USER-BASED-SM-MIB.
862
MODULE -- this module
863
MANDATORY-GROUPS { usmMIBBasicGroup }
865
OBJECT usmUserAuthProtocol
867
DESCRIPTION "Write access is not required."
869
OBJECT usmUserPrivProtocol
871
DESCRIPTION "Write access is not required."
872
::= { usmMIBCompliances 1 }
874
usmMIBBasicGroup OBJECT-GROUP
876
usmStatsUnsupportedSecLevels,
877
usmStatsNotInTimeWindows,
878
usmStatsUnknownUserNames,
879
usmStatsUnknownEngineIDs,
880
usmStatsWrongDigests,
881
usmStatsDecryptionErrors,
886
usmUserAuthKeyChange,
887
usmUserOwnAuthKeyChange,
889
usmUserPrivKeyChange,
890
usmUserOwnPrivKeyChange,
896
DESCRIPTION "A collection of objects providing for configuration
897
of an SNMP engine which implements the SNMP
898
User-based Security Model.
900
::= { usmMIBGroups 1 }
added
removed
mibs/SNMP-USER-BASED-SM-MIB.txt
