1SNMP-USER-BASED-SM-MIB(7)             MIB            SNMP-USER-BASED-SM-MIB(7)
2
3
4
5SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
6
7IMPORTS
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;
17
18snmpUsmMIB 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
25                  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
33                  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
41                  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
57    REVISION     "9711200000Z"            -- 20 Nov 1997, midnight
58    DESCRIPTION  "Initial version, published as RFC2274"
59
60    ::= { snmpModules 15 }
61
62-- Administrative assignments ****************************************
63
64usmMIBObjects     OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
65usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
66
67-- Identification of Authentication and Privacy Protocols ************
68
69usmNoAuthProtocol OBJECT-IDENTITY
70    STATUS        current
71    DESCRIPTION  "No Authentication Protocol."
72    ::= { snmpAuthProtocols 1 }
73
74usmHMACMD5AuthProtocol 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 }
83
84usmHMACSHAAuthProtocol 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 }
93
94usmNoPrivProtocol OBJECT-IDENTITY
95    STATUS        current
96    DESCRIPTION  "No Privacy Protocol."
97    ::= { snmpPrivProtocols 1 }
98
99usmDESPrivProtocol 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
108                  - Data Encryption Algorithm, American National
109                    Standards Institute.  ANSI X3.92-1981,
110                    (December, 1980).
111
112                  - DES Modes of Operation, National Institute of
113                    Standards and Technology.  Federal Information
114                    Processing Standard (FIPS) Publication 81,
115                    (December, 1980).
116
117                  - Data Encryption Algorithm - Modes of Operation,
118                    American National Standards Institute.
119                    ANSI X3.106-1983, (May 1983).
120                 "
121    ::= { snmpPrivProtocols 2 }
122
123
124-- Textual Conventions ***********************************************
125
126
127KeyChange ::=     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
134          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
138          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
142          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
156          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
162           - 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
184           For example, using MD5 as the hash algorithm H:
185
186              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
197          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
201          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
204           - 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
227           For example, using MD5 as the hash algorithm H:
228
229              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
240          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
244          Note that the keyOld and keyNew are the localized keys.
245
246          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
253
254-- Statistics for the User-based Security Model **********************
255
256
257usmStats         OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
258
259
260usmStatsUnsupportedSecLevels 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 }
270
271usmStatsNotInTimeWindows 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 }
280
281usmStatsUnknownUserNames 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 }
290
291usmStatsUnknownEngineIDs 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 }
300
301usmStatsWrongDigests 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 }
310
311usmStatsDecryptionErrors 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
321-- The usmUser Group ************************************************
322
323usmUser          OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
324
325usmUserSpinLock  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
336-- The table of valid users for the User-based Security Model ********
337
338usmUserTable     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
345                 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
349                   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
356                 If the new user is to use privacy:
357
358                   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
369                 If the new user will never use privacy:
370
371                   7)  SET(usmUserPrivProtocol=usmNoPrivProtocol)
372
373                 If the new user is to use authentication:
374
375                   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
386                 If the new user will never use authentication:
387
388                   12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
389
390                 Finally, activate the new user:
391
392                   13) SET(usmUserStatus=active)
393
394                 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
399                 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 }
404
405usmUserEntry     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 }
417
418UsmUserEntry ::= 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    }
434
435usmUserEngineID  OBJECT-TYPE
436    SYNTAX       SnmpEngineID
437    MAX-ACCESS   not-accessible
438    STATUS       current
439    DESCRIPTION "An SNMP engine's administratively-unique identifier.
440
441                 In a simple agent, this value is always that agent's
442                 own snmpEngineID value.
443
444                 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 }
449
450usmUserName      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
457                 This is the (User-based Security) Model dependent
458                 security ID.
459                "
460    ::= { usmUserEntry 2 }
461
462usmUserSecurityName 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
469                 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 }
475
476usmUserCloneFrom 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
484                 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
493                 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
499                 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
509                 When this object is read, the ZeroDotZero OID
510                 is returned.
511                "
512    ::= { usmUserEntry 4 }
513
514usmUserAuthProtocol 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
523                 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
529                 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
533                 The value will be overwritten/set when a set operation
534                 is performed on the corresponding instance of
535                 usmUserCloneFrom.
536
537                 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
541                 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
546                 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 }
557
558usmUserAuthKeyChange 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
569                 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
575                 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
581                 When the value of the corresponding usmUserAuthProtocol
582                 is usmNoAuthProtocol, then a set is successful, but
583                 effectively is a no-op.
584
585                 When this object is read, the zero-length (empty)
586                 string is returned.
587
588                 The recommended way to do a key change is as follows:
589
590                   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
595                 If you do the key change on behalf of another user:
596
597                   3) SET(usmUserSpinLock.0=sValue,
598                          usmUserAuthKeyChange=kcValue
599                          usmUserPublic=randomValue)
600
601                 If you do the key change for yourself:
602
603                   4) SET(usmUserSpinLock.0=sValue,
604                          usmUserOwnAuthKeyChange=kcValue
605                          usmUserPublic=randomValue)
606
607                 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 }
619
620usmUserOwnAuthKeyChange 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
634                 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
639                 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
644                 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 }
649
650usmUserPrivProtocol 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
659                 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
665                 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
669                 The value will be overwritten/set when a set operation
670                 is performed on the corresponding instance of
671                 usmUserCloneFrom.
672
673                 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
677                 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
682                 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 }
692
693usmUserPrivKeyChange 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
703                 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
709                 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
715                 When the value of the corresponding usmUserPrivProtocol
716                 is usmNoPrivProtocol, then a set is successful, but
717                 effectively is a no-op.
718
719                 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 }
726
727usmUserOwnPrivKeyChange 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
739                 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
744                 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
749                 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 }
754
755usmUserPublic    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 }
767
768usmUserStorageType OBJECT-TYPE
769    SYNTAX       StorageType
770    MAX-ACCESS   read-create
771    STATUS       current
772    DESCRIPTION "The storage type for this conceptual row.
773
774                 Conceptual rows having the value 'permanent' must
775                 allow write-access at a minimum to:
776
777                 - 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
784                 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
788                 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
795                 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 }
803
804usmUserStatus    OBJECT-TYPE
805    SYNTAX       RowStatus
806    MAX-ACCESS   read-create
807    STATUS       current
808    DESCRIPTION "The status of this conceptual row.
809
810                 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
815                 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
820                 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
824                 The RowStatus TC [RFC1903] requires that this
825                 DESCRIPTION clause states under which circumstances
826                 other objects in this row can be modified:
827
828                 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
836-- Conformance Information *******************************************
837
838usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
839usmMIBGroups      OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
840
841-- Compliance statements
842
843usmMIBCompliance MODULE-COMPLIANCE
844    STATUS       current
845    DESCRIPTION "The compliance statement for SNMP engines which
846                 implement the SNMP-USER-BASED-SM-MIB.
847                "
848
849    MODULE       -- this module
850        MANDATORY-GROUPS { usmMIBBasicGroup }
851
852        OBJECT           usmUserAuthProtocol
853        MIN-ACCESS       read-only
854        DESCRIPTION     "Write access is not required."
855
856        OBJECT           usmUserPrivProtocol
857        MIN-ACCESS       read-only
858        DESCRIPTION     "Write access is not required."
859
860    ::= { usmMIBCompliances 1 }
861
862-- 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 }
890
891END
892
893
894
895
896Erlang/OTP                           SNMP            SNMP-USER-BASED-SM-MIB(7)
Impressum