1SNMP-USER-BASED-SM-MIB(7) MIB SNMP-USER-BASED-SM-MIB(7)
2SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
6IMPORTS
8 MODULE-IDENTITY, OBJECT-TYPE,
9 OBJECT-IDENTITY,
10 snmpModules, Counter32 FROM SNMPv2-SMI
11 TEXTUAL-CONVENTION, TestAndIncr,
12 RowStatus, RowPointer,
13 StorageType, AutonomousType FROM SNMPv2-TC
14 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
15 SnmpAdminString, SnmpEngineID,
16 snmpAuthProtocols, snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB;
17snmpUsmMIB MODULE-IDENTITY
19 LAST-UPDATED "9901200000Z" -- 20 Jan 1999, midnight
20 ORGANIZATION "SNMPv3 Working Group"
21 CONTACT-INFO "WG-email: snmpv3@tis.com
22 Subscribe: majordomo@tis.com
23 In msg body: subscribe snmpv3
24 Chair: Russ Mundy
26 Trusted Information Systems
27 postal: 3060 Washington Rd
28 Glenwood MD 21738
29 USA
30 email: mundy@tis.com
31 phone: +1-301-854-6889
32 Co-editor Uri Blumenthal
34 IBM T. J. Watson Research
35 postal: 30 Saw Mill River Pkwy,
36 Hawthorne, NY 10532
37 USA
38 email: uri@watson.ibm.com
39 phone: +1-914-784-7964
40 Co-editor: Bert Wijnen
42 IBM T. J. Watson Research
43 postal: Schagen 33
44 3461 GL Linschoten
45 Netherlands
46 email: wijnen@vnet.ibm.com
47 phone: +31-348-432-794
48 "
49 DESCRIPTION "The management information definitions for the
50 SNMP User-based Security Model.
51 "
52-- Revision history
53 REVISION "9901200000Z" -- 20 Jan 1999, midnight
54 -- RFC-Editor assigns RFCxxxx
55 DESCRIPTION "Clarifications, published as RFCxxxx"
56 REVISION "9711200000Z" -- 20 Nov 1997, midnight
58 DESCRIPTION "Initial version, published as RFC2274"
59 ::= { snmpModules 15 }
61-- Administrative assignments ****************************************
63usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
65usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
66-- Identification of Authentication and Privacy Protocols ************
68usmNoAuthProtocol OBJECT-IDENTITY
70 STATUS current
71 DESCRIPTION "No Authentication Protocol."
72 ::= { snmpAuthProtocols 1 }
73usmHMACMD5AuthProtocol OBJECT-IDENTITY
75 STATUS current
76 DESCRIPTION "The HMAC-MD5-96 Digest Authentication Protocol."
77 REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti HMAC:
78 Keyed-Hashing for Message Authentication,
79 RFC2104, Feb 1997.
80 - Rivest, R., Message Digest Algorithm MD5, RFC1321.
81 "
82 ::= { snmpAuthProtocols 2 }
83usmHMACSHAAuthProtocol OBJECT-IDENTITY
85 STATUS current
86 DESCRIPTION "The HMAC-SHA-96 Digest Authentication Protocol."
87 REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti, HMAC:
88 Keyed-Hashing for Message Authentication,
89 RFC2104, Feb 1997.
90 - Secure Hash Algorithm. NIST FIPS 180-1.
91 "
92 ::= { snmpAuthProtocols 3 }
93usmNoPrivProtocol OBJECT-IDENTITY
95 STATUS current
96 DESCRIPTION "No Privacy Protocol."
97 ::= { snmpPrivProtocols 1 }
98usmDESPrivProtocol OBJECT-IDENTITY
100 STATUS current
101 DESCRIPTION "The CBC-DES Symmetric Encryption Protocol."
102 REFERENCE "- Data Encryption Standard, National Institute of
103 Standards and Technology. Federal Information
104 Processing Standard (FIPS) Publication 46-1.
105 Supersedes FIPS Publication 46,
106 (January, 1977; reaffirmed January, 1988).
107 - Data Encryption Algorithm, American National
109 Standards Institute. ANSI X3.92-1981,
110 (December, 1980).
111 - DES Modes of Operation, National Institute of
113 Standards and Technology. Federal Information
114 Processing Standard (FIPS) Publication 81,
115 (December, 1980).
116 - Data Encryption Algorithm - Modes of Operation,
118 American National Standards Institute.
119 ANSI X3.106-1983, (May 1983).
120 "
121 ::= { snmpPrivProtocols 2 }
122-- Textual Conventions ***********************************************
125KeyChange ::= TEXTUAL-CONVENTION
128 STATUS current
129 DESCRIPTION
130 "Every definition of an object with this syntax must identify
131 a protocol P, a secret key K, and a hash algorithm H
132 that produces output of L octets.
133 The object's value is a manager-generated, partially-random
135 value which, when modified, causes the value of the secret
136 key K, to be modified via a one-way function.
137 The value of an instance of this object is the concatenation
139 of two components: first a 'random' component and then a
140 'delta' component.
141 The lengths of the random and delta components
143 are given by the corresponding value of the protocol P;
144 if P requires K to be a fixed length, the length of both the
145 random and delta components is that fixed length; if P
146 allows the length of K to be variable up to a particular
147 maximum length, the length of the random component is that
148 maximum length and the length of the delta component is any
149 length less than or equal to that maximum length.
150 For example, usmHMACMD5AuthProtocol requires K to be a fixed
151 length of 16 octets and L - of 16 octets.
152 usmHMACSHAAuthProtocol requires K to be a fixed length of
153 20 octets and L - of 20 octets. Other protocols may define
154 other sizes, as deemed appropriate.
155 When a requester wants to change the old key K to a new
157 key keyNew on a remote entity, the 'random' component is
158 obtained from either a true random generator, or from a
159 pseudorandom generator, and the 'delta' component is
160 computed as follows:
161 - a temporary variable is initialized to the existing value
163 of K;
164 - if the length of the keyNew is greater than L octets,
165 then:
166 - the random component is appended to the value of the
167 temporary variable, and the result is input to the
168 the hash algorithm H to produce a digest value, and
169 the temporary variable is set to this digest value;
170 - the value of the temporary variable is XOR-ed with
171 the first (next) L-octets (16 octets in case of MD5)
172 of the keyNew to produce the first (next) L-octets
173 (16 octets in case of MD5) of the 'delta' component.
174 - the above two steps are repeated until the unused
175 portion of the keyNew component is L octets or less,
176 - the random component is appended to the value of the
177 temporary variable, and the result is input to the
178 hash algorithm H to produce a digest value;
179 - this digest value, truncated if necessary to be the same
180 length as the unused portion of the keyNew, is XOR-ed
181 with the unused portion of the keyNew to produce the
182 (final portion of the) 'delta' component.
183 For example, using MD5 as the hash algorithm H:
185 iterations = (lenOfDelta - 1)/16; /* integer division */
187 temp = keyOld;
188 for (i = 0; i < iterations; i++) {
189 temp = MD5 (temp || random);
190 delta[i*16 .. (i*16)+15] =
191 temp XOR keyNew[i*16 .. (i*16)+15];
192 }
193 temp = MD5 (temp || random);
194 delta[i*16 .. lenOfDelta-1] =
195 temp XOR keyNew[i*16 .. lenOfDelta-1];
196 The 'random' and 'delta' components are then concatenated as
198 described above, and the resulting octet string is sent to
199 the recipient as the new value of an instance of this object.
200 At the receiver side, when an instance of this object is set
202 to a new value, then a new value of K is computed as follows:
203 - a temporary variable is initialized to the existing value
205 of K;
206 - if the length of the delta component is greater than L
207 octets, then:
208 - the random component is appended to the value of the
209 temporary variable, and the result is input to the
210 hash algorithm H to produce a digest value, and the
211 temporary variable is set to this digest value;
212 - the value of the temporary variable is XOR-ed with
213 the first (next) L-octets (16 octets in case of MD5)
214 of the delta component to produce the first (next)
215 L-octets (16 octets in case of MD5) of the new value
216 of K.
217 - the above two steps are repeated until the unused
218 portion of the delta component is L octets or less,
219 - the random component is appended to the value of the
220 temporary variable, and the result is input to the
221 hash algorithm H to produce a digest value;
222 - this digest value, truncated if necessary to be the same
223 length as the unused portion of the delta component, is
224 XOR-ed with the unused portion of the delta component to
225 produce the (final portion of the) new value of K.
226 For example, using MD5 as the hash algorithm H:
228 iterations = (lenOfDelta - 1)/16; /* integer division */
230 temp = keyOld;
231 for (i = 0; i < iterations; i++) {
232 temp = MD5 (temp || random);
233 keyNew[i*16 .. (i*16)+15] =
234 temp XOR delta[i*16 .. (i*16)+15];
235 }
236 temp = MD5 (temp || random);
237 keyNew[i*16 .. lenOfDelta-1] =
238 temp XOR delta[i*16 .. lenOfDelta-1];
239 The value of an object with this syntax, whenever it is
241 retrieved by the management protocol, is always the zero
242 length string.
243 Note that the keyOld and keyNew are the localized keys.
245 Note that it is probably wise that when an SNMP entity sends
247 a SetRequest to change a key, that it keeps a copy of the old
248 key until it has confirmed that the key change actually
249 succeeded.
250 "
251 SYNTAX OCTET STRING
252-- Statistics for the User-based Security Model **********************
255usmStats OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
258usmStatsUnsupportedSecLevels OBJECT-TYPE
261 SYNTAX Counter32
262 MAX-ACCESS read-only
263 STATUS current
264 DESCRIPTION "The total number of packets received by the SNMP
265 engine which were dropped because they requested a
266 securityLevel that was unknown to the SNMP engine
267 or otherwise unavailable.
268 "
269 ::= { usmStats 1 }
270usmStatsNotInTimeWindows OBJECT-TYPE
272 SYNTAX Counter32
273 MAX-ACCESS read-only
274 STATUS current
275 DESCRIPTION "The total number of packets received by the SNMP
276 engine which were dropped because they appeared
277 outside of the authoritative SNMP engine's window.
278 "
279 ::= { usmStats 2 }
280usmStatsUnknownUserNames OBJECT-TYPE
282 SYNTAX Counter32
283 MAX-ACCESS read-only
284 STATUS current
285 DESCRIPTION "The total number of packets received by the SNMP
286 engine which were dropped because they referenced a
287 user that was not known to the SNMP engine.
288 "
289 ::= { usmStats 3 }
290usmStatsUnknownEngineIDs OBJECT-TYPE
292 SYNTAX Counter32
293 MAX-ACCESS read-only
294 STATUS current
295 DESCRIPTION "The total number of packets received by the SNMP
296 engine which were dropped because they referenced an
297 snmpEngineID that was not known to the SNMP engine.
298 "
299 ::= { usmStats 4 }
300usmStatsWrongDigests OBJECT-TYPE
302 SYNTAX Counter32
303 MAX-ACCESS read-only
304 STATUS current
305 DESCRIPTION "The total number of packets received by the SNMP
306 engine which were dropped because they didn't
307 contain the expected digest value.
308 "
309 ::= { usmStats 5 }
310usmStatsDecryptionErrors OBJECT-TYPE
312 SYNTAX Counter32
313 MAX-ACCESS read-only
314 STATUS current
315 DESCRIPTION "The total number of packets received by the SNMP
316 engine which were dropped because they could not be
317 decrypted.
318 "
319 ::= { usmStats 6 }
320-- The usmUser Group ************************************************
322usmUser OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
324usmUserSpinLock OBJECT-TYPE
326 SYNTAX TestAndIncr
327 MAX-ACCESS read-write
328 STATUS current
329 DESCRIPTION "An advisory lock used to allow several cooperating
330 Command Generator Applications to coordinate their
331 use of facilities to alter secrets in the
332 usmUserTable.
333 "
334 ::= { usmUser 1 }
335-- The table of valid users for the User-based Security Model ********
337usmUserTable OBJECT-TYPE
339 SYNTAX SEQUENCE OF UsmUserEntry
340 MAX-ACCESS not-accessible
341 STATUS current
342 DESCRIPTION "The table of users configured in the SNMP engine's
343 Local Configuration Datastore (LCD).
344 To create a new user (i.e., to instantiate a new
346 conceptual row in this table), it is recommended to
347 follow this procedure:
348 1) GET(usmUserSpinLock.0) and save in sValue.
350 2) SET(usmUserSpinLock.0=sValue,
351 usmUserCloneFrom=templateUser,
352 usmUserStatus=createAndWait)
353 You should use a template user to clone from
354 which has the proper auth/priv protocol defined.
355 If the new user is to use privacy:
357 3) generate the keyChange value based on the secret
359 privKey of the clone-from user and the secret key
360 to be used for the new user. Let us call this
361 pkcValue.
362 4) GET(usmUserSpinLock.0) and save in sValue.
363 5) SET(usmUserSpinLock.0=sValue,
364 usmUserPrivKeyChange=pkcValue
365 usmUserPublic=randomValue1)
366 6) GET(usmUserPulic) and check it has randomValue1.
367 If not, repeat steps 4-6.
368 If the new user will never use privacy:
370 7) SET(usmUserPrivProtocol=usmNoPrivProtocol)
372 If the new user is to use authentication:
374 8) generate the keyChange value based on the secret
376 authKey of the clone-from user and the secret key
377 to be used for the new user. Let us call this
378 akcValue.
379 9) GET(usmUserSpinLock.0) and save in sValue.
380 10) SET(usmUserSpinLock.0=sValue,
381 usmUserAuthKeyChange=akcValue
382 usmUserPublic=randomValue2)
383 11) GET(usmUserPulic) and check it has randomValue2.
384 If not, repeat steps 9-11.
385 If the new user will never use authentication:
387 12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
389 Finally, activate the new user:
391 13) SET(usmUserStatus=active)
393 The new user should now be available and ready to be
395 used for SNMPv3 communication. Note however that access
396 to MIB data must be provided via configuration of the
397 SNMP-VIEW-BASED-ACM-MIB.
398 The use of usmUserSpinlock is to avoid conflicts with
400 another SNMP command responder application which may
401 also be acting on the usmUserTable.
402 "
403 ::= { usmUser 2 }
404usmUserEntry OBJECT-TYPE
406 SYNTAX UsmUserEntry
407 MAX-ACCESS not-accessible
408 STATUS current
409 DESCRIPTION "A user configured in the SNMP engine's Local
410 Configuration Datastore (LCD) for the User-based
411 Security Model.
412 "
413 INDEX { usmUserEngineID,
414 usmUserName
415 }
416 ::= { usmUserTable 1 }
417UsmUserEntry ::= SEQUENCE
419 {
420 usmUserEngineID SnmpEngineID,
421 usmUserName SnmpAdminString,
422 usmUserSecurityName SnmpAdminString,
423 usmUserCloneFrom RowPointer,
424 usmUserAuthProtocol AutonomousType,
425 usmUserAuthKeyChange KeyChange,
426 usmUserOwnAuthKeyChange KeyChange,
427 usmUserPrivProtocol AutonomousType,
428 usmUserPrivKeyChange KeyChange,
429 usmUserOwnPrivKeyChange KeyChange,
430 usmUserPublic OCTET STRING,
431 usmUserStorageType StorageType,
432 usmUserStatus RowStatus
433 }
434usmUserEngineID OBJECT-TYPE
436 SYNTAX SnmpEngineID
437 MAX-ACCESS not-accessible
438 STATUS current
439 DESCRIPTION "An SNMP engine's administratively-unique identifier.
440 In a simple agent, this value is always that agent's
442 own snmpEngineID value.
443 The value can also take the value of the snmpEngineID
445 of a remote SNMP engine with which this user can
446 communicate.
447 "
448 ::= { usmUserEntry 1 }
449usmUserName OBJECT-TYPE
451 SYNTAX SnmpAdminString (SIZE(1..32))
452 MAX-ACCESS not-accessible
453 STATUS current
454 DESCRIPTION "A human readable string representing the name of
455 the user.
456 This is the (User-based Security) Model dependent
458 security ID.
459 "
460 ::= { usmUserEntry 2 }
461usmUserSecurityName OBJECT-TYPE
463 SYNTAX SnmpAdminString
464 MAX-ACCESS read-only
465 STATUS current
466 DESCRIPTION "A human readable string representing the user in
467 Security Model independent format.
468 The default transformation of the User-based Security
470 Model dependent security ID to the securityName and
471 vice versa is the identity function so that the
472 securityName is the same as the userName.
473 "
474 ::= { usmUserEntry 3 }
475usmUserCloneFrom OBJECT-TYPE
477 SYNTAX RowPointer
478 MAX-ACCESS read-create
479 STATUS current
480 DESCRIPTION "A pointer to another conceptual row in this
481 usmUserTable. The user in this other conceptual
482 row is called the clone-from user.
483 When a new user is created (i.e., a new conceptual
485 row is instantiated in this table), the privacy and
486 authentication parameters of the new user must be
487 cloned from its clone-from user. These parameters are:
488 - authentication protocol (usmUserAuthProtocol)
489 - privacy protocol (usmUserPrivProtocol)
490 They will be copied regardless of what the current
491 value is.
492 Cloning also causes the initial values of the secret
494 authentication key (authKey) and the secret encryption
495 key (privKey) of the new user to be set to the same
496 value as the corresponding secret of the clone-from
497 user.
498 The first time an instance of this object is set by
500 a management operation (either at or after its
501 instantiation), the cloning process is invoked.
502 Subsequent writes are successful but invoke no
503 action to be taken by the receiver.
504 The cloning process fails with an 'inconsistentName'
505 error if the conceptual row representing the
506 clone-from user does not exist or is not in an active
507 state when the cloning process is invoked.
508 When this object is read, the ZeroDotZero OID
510 is returned.
511 "
512 ::= { usmUserEntry 4 }
513usmUserAuthProtocol OBJECT-TYPE
515 SYNTAX AutonomousType
516 MAX-ACCESS read-create
517 STATUS current
518 DESCRIPTION "An indication of whether messages sent on behalf of
519 this user to/from the SNMP engine identified by
520 usmUserEngineID, can be authenticated, and if so,
521 the type of authentication protocol which is used.
522 An instance of this object is created concurrently
524 with the creation of any other object instance for
525 the same user (i.e., as part of the processing of
526 the set operation which creates the first object
527 instance in the same conceptual row).
528 If an initial set operation (i.e. at row creation time)
530 tries to set a value for an unknown or unsupported
531 protocol, then a 'wrongValue' error must be returned.
532 The value will be overwritten/set when a set operation
534 is performed on the corresponding instance of
535 usmUserCloneFrom.
536 Once instantiated, the value of such an instance of
538 this object can only be changed via a set operation to
539 the value of the usmNoAuthProtocol.
540 If a set operation tries to change the value of an
542 existing instance of this object to any value other
543 than usmNoAuthProtocol, then an 'inconsistentValue'
544 error must be returned.
545 If a set operation tries to set the value to the
547 usmNoAuthProtocol while the usmUserPrivProtocol value
548 in the same row is not equal to usmNoPrivProtocol,
549 then an 'inconsistentValue' error must be returned.
550 That means that an SNMP command generator application
551 must first ensure that the usmUserPrivProtocol is set
552 to the usmNoPrivProtocol value before it can set
553 the usmUserAuthProtocol value to usmNoAuthProtocol.
554 "
555 DEFVAL { usmNoAuthProtocol }
556 ::= { usmUserEntry 5 }
557usmUserAuthKeyChange OBJECT-TYPE
559 SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5
560 -- typically (SIZE (0 | 40)) for HMACSHA
561 MAX-ACCESS read-create
562 STATUS current
563 DESCRIPTION "An object, which when modified, causes the secret
564 authentication key used for messages sent on behalf
565 of this user to/from the SNMP engine identified by
566 usmUserEngineID, to be modified via a one-way
567 function.
568 The associated protocol is the usmUserAuthProtocol.
570 The associated secret key is the user's secret
571 authentication key (authKey). The associated hash
572 algorithm is the algorithm used by the user's
573 usmUserAuthProtocol.
574 When creating a new user, it is an 'inconsistentName'
576 error for a set operation to refer to this object
577 unless it is previously or concurrently initialized
578 through a set operation on the corresponding instance
579 of usmUserCloneFrom.
580 When the value of the corresponding usmUserAuthProtocol
582 is usmNoAuthProtocol, then a set is successful, but
583 effectively is a no-op.
584 When this object is read, the zero-length (empty)
586 string is returned.
587 The recommended way to do a key change is as follows:
589 1) GET(usmUserSpinLock.0) and save in sValue.
591 2) generate the keyChange value based on the old
592 (existing) secret key and the new secret key,
593 let us call this kcValue.
594 If you do the key change on behalf of another user:
596 3) SET(usmUserSpinLock.0=sValue,
598 usmUserAuthKeyChange=kcValue
599 usmUserPublic=randomValue)
600 If you do the key change for yourself:
602 4) SET(usmUserSpinLock.0=sValue,
604 usmUserOwnAuthKeyChange=kcValue
605 usmUserPublic=randomValue)
606 If you get a response with error-status of noError,
608 then the SET succeeded and the new key is active.
609 If you do not get a response, then you can issue a
610 GET(usmUserPublic) and check if the value is equal
611 to the randomValue you did send in the SET. If so, then
612 the key change succeeded and the new key is active
613 (probably the response got lost). If not, then the SET
614 request probably never reached the target and so you
615 can start over with the procedure above.
616 "
617 DEFVAL { ''H } -- the empty string
618 ::= { usmUserEntry 6 }
619usmUserOwnAuthKeyChange OBJECT-TYPE
621 SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5
622 -- typically (SIZE (0 | 40)) for HMACSHA
623 MAX-ACCESS read-create
624 STATUS current
625 DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one
626 notable difference: in order for the set operation
627 to succeed, the usmUserName of the operation
628 requester must match the usmUserName that
629 indexes the row which is targeted by this
630 operation.
631 In addition, the USM security model must be
632 used for this operation.
633 The idea here is that access to this column can be
635 public, since it will only allow a user to change
636 his own secret authentication key (authKey).
637 Note that this can only be done once the row is active.
638 When a set is received and the usmUserName of the
640 requester is not the same as the umsUserName that
641 indexes the row which is targeted by this operation,
642 then a 'noAccess' error must be returned.
643 When a set is received and the security model in use
645 is not USM, then a 'noAccess' error must be returned.
646 "
647 DEFVAL { ''H } -- the empty string
648 ::= { usmUserEntry 7 }
649usmUserPrivProtocol OBJECT-TYPE
651 SYNTAX AutonomousType
652 MAX-ACCESS read-create
653 STATUS current
654 DESCRIPTION "An indication of whether messages sent on behalf of
655 this user to/from the SNMP engine identified by
656 usmUserEngineID, can be protected from disclosure,
657 and if so, the type of privacy protocol which is used.
658 An instance of this object is created concurrently
660 with the creation of any other object instance for
661 the same user (i.e., as part of the processing of
662 the set operation which creates the first object
663 instance in the same conceptual row).
664 If an initial set operation (i.e. at row creation time)
666 tries to set a value for an unknown or unsupported
667 protocol, then a 'wrongValue' error must be returned.
668 The value will be overwritten/set when a set operation
670 is performed on the corresponding instance of
671 usmUserCloneFrom.
672 Once instantiated, the value of such an instance of
674 this object can only be changed via a set operation to
675 the value of the usmNoPrivProtocol.
676 If a set operation tries to change the value of an
678 existing instance of this object to any value other
679 than usmNoPrivProtocol, then an 'inconsistentValue'
680 error must be returned.
681 Note that if any privacy protocol is used, then you
683 must also use an authentication protocol. In other
684 words, if usmUserPrivProtocol is set to anything else
685 than usmNoPrivProtocol, then the corresponding instance
686 of usmUserAuthProtocol cannot have a value of
687 usmNoAuthProtocol. If it does, then an
688 'inconsistentValue' error must be returned.
689 "
690 DEFVAL { usmNoPrivProtocol }
691 ::= { usmUserEntry 8 }
692usmUserPrivKeyChange OBJECT-TYPE
694 SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES
695 MAX-ACCESS read-create
696 STATUS current
697 DESCRIPTION "An object, which when modified, causes the secret
698 encryption key used for messages sent on behalf
699 of this user to/from the SNMP engine identified by
700 usmUserEngineID, to be modified via a one-way
701 function.
702 The associated protocol is the usmUserPrivProtocol.
704 The associated secret key is the user's secret
705 privacy key (privKey). The associated hash
706 algorithm is the algorithm used by the user's
707 usmUserAuthProtocol.
708 When creating a new user, it is an 'inconsistentName'
710 error for a set operation to refer to this object
711 unless it is previously or concurrently initialized
712 through a set operation on the corresponding instance
713 of usmUserCloneFrom.
714 When the value of the corresponding usmUserPrivProtocol
716 is usmNoPrivProtocol, then a set is successful, but
717 effectively is a no-op.
718 When this object is read, the zero-length (empty)
720 string is returned.
721 See the description clause of usmUserAuthKeyChange for
722 a recommended procedure to do a key change.
723 "
724 DEFVAL { ''H } -- the empty string
725 ::= { usmUserEntry 9 }
726usmUserOwnPrivKeyChange OBJECT-TYPE
728 SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES
729 MAX-ACCESS read-create
730 STATUS current
731 DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one
732 notable difference: in order for the Set operation
733 to succeed, the usmUserName of the operation
734 requester must match the usmUserName that indexes
735 the row which is targeted by this operation.
736 In addition, the USM security model must be
737 used for this operation.
738 The idea here is that access to this column can be
740 public, since it will only allow a user to change
741 his own secret privacy key (privKey).
742 Note that this can only be done once the row is active.
743 When a set is received and the usmUserName of the
745 requester is not the same as the umsUserName that
746 indexes the row which is targeted by this operation,
747 then a 'noAccess' error must be returned.
748 When a set is received and the security model in use
750 is not USM, then a 'noAccess' error must be returned.
751 "
752 DEFVAL { ''H } -- the empty string
753 ::= { usmUserEntry 10 }
754usmUserPublic OBJECT-TYPE
756 SYNTAX OCTET STRING (SIZE(0..32))
757 MAX-ACCESS read-create
758 STATUS current
759 DESCRIPTION "A publicly-readable value which can be written as part
760 of the procedure for changing a user's secret
761 authentication and/or privacy key, and later read to
762 determine whether the change of the secret was
763 effected.
764 "
765 DEFVAL { ''H } -- the empty string
766 ::= { usmUserEntry 11 }
767usmUserStorageType OBJECT-TYPE
769 SYNTAX StorageType
770 MAX-ACCESS read-create
771 STATUS current
772 DESCRIPTION "The storage type for this conceptual row.
773 Conceptual rows having the value 'permanent' must
775 allow write-access at a minimum to:
776 - usmUserAuthKeyChange, usmUserOwnAuthKeyChange
778 and usmUserPublic for a user who employs
779 authentication, and
780 - usmUserPrivKeyChange, usmUserOwnPrivKeyChange
781 and usmUserPublic for a user who employs
782 privacy.
783 Note that any user who employs authentication or
785 privacy must allow its secret(s) to be updated and
786 thus cannot be 'readOnly'.
787 If an initial set operation tries to set the value to
789 'readOnly' for a user who employs authentication or
790 privacy, then an 'inconsistentValue' error must be
791 returned. Note that if the value has been previously
792 set (implicit or explicit) to any value, then the rules
793 as defined in the StorageType Textual Convention apply.
794 It is an implementation issue to decide if a SET for
796 a readOnly or permanent row is accepted at all. In some
797 contexts this may make sense, in others it may not. If
798 a SET for a readOnly or permanent row is not accepted
799 at all, then a 'wrongValue' error must be returned.
800 "
801 DEFVAL { nonVolatile }
802 ::= { usmUserEntry 12 }
803usmUserStatus OBJECT-TYPE
805 SYNTAX RowStatus
806 MAX-ACCESS read-create
807 STATUS current
808 DESCRIPTION "The status of this conceptual row.
809 Until instances of all corresponding columns are
811 appropriately configured, the value of the
812 corresponding instance of the usmUserStatus column
813 is 'notReady'.
814 In particular, a newly created row for a user who
816 employs authentication, cannot be made active until the
817 corresponding usmUserCloneFrom and usmUserAuthKeyChange
818 have been set.
819 Further, a newly created row for a user who also
821 employs privacy, cannot be made active until the
822 usmUserPrivKeyChange has been set.
823 The RowStatus TC [RFC1903] requires that this
825 DESCRIPTION clause states under which circumstances
826 other objects in this row can be modified:
827 The value of this object has no effect on whether
829 other objects in this conceptual row can be modified,
830 except for usmUserOwnAuthKeyChange and
831 usmUserOwnPrivKeyChange. For these 2 objects, the
832 value of usmUserStatus MUST be active.
833 "
834 ::= { usmUserEntry 13 }
835-- Conformance Information *******************************************
837usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
839usmMIBGroups OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
840-- Compliance statements
842usmMIBCompliance MODULE-COMPLIANCE
844 STATUS current
845 DESCRIPTION "The compliance statement for SNMP engines which
846 implement the SNMP-USER-BASED-SM-MIB.
847 "
848 MODULE -- this module
850 MANDATORY-GROUPS { usmMIBBasicGroup }
851 OBJECT usmUserAuthProtocol
853 MIN-ACCESS read-only
854 DESCRIPTION "Write access is not required."
855 OBJECT usmUserPrivProtocol
857 MIN-ACCESS read-only
858 DESCRIPTION "Write access is not required."
859 ::= { usmMIBCompliances 1 }
861-- Units of compliance
863usmMIBBasicGroup OBJECT-GROUP
864 OBJECTS {
865 usmStatsUnsupportedSecLevels,
866 usmStatsNotInTimeWindows,
867 usmStatsUnknownUserNames,
868 usmStatsUnknownEngineIDs,
869 usmStatsWrongDigests,
870 usmStatsDecryptionErrors,
871 usmUserSpinLock,
872 usmUserSecurityName,
873 usmUserCloneFrom,
874 usmUserAuthProtocol,
875 usmUserAuthKeyChange,
876 usmUserOwnAuthKeyChange,
877 usmUserPrivProtocol,
878 usmUserPrivKeyChange,
879 usmUserOwnPrivKeyChange,
880 usmUserPublic,
881 usmUserStorageType,
882 usmUserStatus
883 }
884 STATUS current
885 DESCRIPTION "A collection of objects providing for configuration
886 of an SNMP engine which implements the SNMP
887 User-based Security Model.
888 "
889 ::= { usmMIBGroups 1 }
890END
892Erlang/OTP SNMP SNMP-USER-BASED-SM-MIB(7)