idnits 2.17.1 draft-ietf-snmpv3-usec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 69) being 77 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([SNMPng-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2979 has weird spacing: '...support priva...' == Line 2984 has weird spacing: '...rotocol use...' == Line 2985 has weird spacing: '...rotocol non...' == Line 2993 has weird spacing: '...support priva...' == Line 3006 has weird spacing: '...support priva...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (09 May 1997) is 9849 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Localized-key' is mentioned on line 2821, but not defined == Missing Reference: 'RFC1321' is mentioned on line 3021, but not defined -- Looks like a reference, but probably isn't: '64' on line 3030 == Unused Reference: 'RFC1902' is defined on line 2860, but no explicit reference was found in the text == Unused Reference: 'RFC1905' is defined on line 2865, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 2880, but no explicit reference was found in the text == Unused Reference: 'SNMPv3-MPC' is defined on line 2891, but no explicit reference was found in the text == Unused Reference: 'SNMPv3-LPM' is defined on line 2897, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1905 (ref. 'RFC1902') (Obsoleted by RFC 3416) -- Duplicate reference: RFC1905, mentioned in 'RFC1905', was also mentioned in 'RFC1902'. ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (Obsoleted by RFC 2576) == Outdated reference: A later version (-06) exists of draft-ietf-snmpv3-next-gen-arch-00 == Outdated reference: A later version (-05) exists of draft-ietf-snmpv3-mpc-00 == Outdated reference: A later version (-01) exists of draft-ietf-snmpv3-lpm-00 -- Possible downref: Normative reference to a draft: ref. 'SNMPv3-LPM' == Outdated reference: A later version (-01) exists of draft-ietf-snmpv3-usec-00 -- Possible downref: Normative reference to a draft: ref. 'SNMPv3-USEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'Localized-Key' -- Possible downref: Non-RFC (?) normative reference: ref. 'KEYED-MD5' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'DES-NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES-ANSI' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESO-NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESO-ANSI' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESG-NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'DEST-NIST' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESM-NIST' Summary: 17 errors (**), 0 flaws (~~), 19 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 User-based Security Model for version 3 of the 3 Simple Network Management Protocol (SNMPv3) 5 09 May 1997 7 U. Blumenthal 8 IBM T. J. Watson Research 9 uri@watson.ibm.com 11 B. Wijnen 12 IBM T. J. Watson Research 13 wijnen@vnet.ibm.com 15 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 31 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 32 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 34 Abstract 36 This document describes the User-based Security Model (USEC) for SNMP 37 version 3 for use in the SNMPng architecture [SNMPng-ARCH]. This 38 document defines the Elements of Procedure for providing SNMP message 39 level security. This document also includes a MIB for remotely 40 monitoring/managing the configuration parameters for this Security 41 model. 43 Blumenthal/Wijnen Expires November 1997 [Page 1] 44 0. Change Log 46 [version 1.0] 47 - first version posted to the v3editors mailing list. 48 - based on v2adv slides, v2adv items and issues list and on 49 RFC1910 and SNMPv2u and SNMPv2* documents. 50 - various iterations were done by the authors via private email. 52 Blumenthal/Wijnen Expires November 1997 [Page 2] 53 1. Introduction 55 Please refer to the introduction of the SNMP Architectural model 56 [SNMPng-ARCH] for an overall introduction to the SNMP components. 57 That same document explains the terminology in the various SNMP 58 components and documents. 60 This memo [SNMPv3-USEC] describes the User-Based Security model 61 as it is used within the SNMPng Architectural model. The main idea 62 is that we use the traditional concept of a user (identified by a 63 userName) to associate security information with. 65 This memo describes the use of Keyed-MD5 as the authentication 66 protocol and the use of CBC-DES as the privacy protocol. 67 The User-based Security model however allows for other such 68 protocols to be used instead of or concurrent with these protocols. 69 So the description of Keyed-MD5 and CBC-DES are in separate sections. 70 That way it shows that they are supposed to be self-contained 71 pieces that can be replaced or supplemented in the future. 73 1.1. Threats 75 Several of the classical threats to network protocols are applicable 76 to the network management problem and therefore would be applicable 77 to any SNMPv3 security model. Other threats are not applicable to 78 the network management problem. This section discusses principal 79 threats, secondary threats, and threats which are of lesser 80 importance. 82 The principal threats against which this SNMPv3 security model 83 should provide protection are: 85 - Modification of Information 86 The modification threat is the danger that some unauthorized entity 87 may alter in-transit SNMPv3 messages generated on behalf of an 88 authorized user in such a way as to effect unauthorized management 89 operations, including falsifying the value of an object. 91 - Masquerade 92 The masquerade threat is the danger that management operations not 93 authorized for some user may be attempted by assuming the identity 94 of another user that has the appropriate authorizations. 96 Two secondary threats are also identified. The security protocols 97 defined in this memo provide limited protection against: 99 - Disclosure 100 The disclosure threat is the danger of eavesdropping on the 101 exchanges between managed agents and a management station. 102 Protecting against this threat may be required as a matter of local 103 policy. 105 Blumenthal/Wijnen Expires November 1997 [Page 3] 106 - Message Stream Modification 107 The SNMPv3 protocol is typically based upon a connection-less 108 transport service which may operate over any sub-network service. 109 The re-ordering, delay or replay of messages can and does occur 110 through the natural operation of many such sub-network services. 111 The message stream modification threat is the danger that messages 112 may be maliciously re-ordered, delayed or replayed to an extent 113 which is greater than can occur through the natural operation of a 114 sub-network service, in order to effect unauthorized management 115 operations. 117 There are at least two threats that an SNMPv3 security protocol need 118 not protect against. The security protocols defined in this memo do 119 not provide protection against: 121 - Denial of Service 122 An SNMPv3 security protocol need not attempt to address the broad 123 range of attacks by which service on behalf of authorized users is 124 denied. Indeed, such denial-of-service attacks are in many cases 125 indistinguishable from the type of network failures with which any 126 viable network management protocol must cope as a matter of course. 127 - Traffic Analysis 128 In addition, an SNMPv3 security protocol need not attempt to 129 address traffic analysis attacks. Indeed, many traffic patterns 130 are predictable - agents may be managed on a regular basis by a 131 relatively small number of management stations - and therefore 132 there is no significant advantage afforded by protecting against 133 traffic analysis. 135 1.2. Goals and Constraints 137 Based on the foregoing account of threats in the SNMP network 138 management environment, the goals of this SNMPv3 security model are 139 as follows. 141 1) The protocol should provide for verification that each received 142 SNMPv3 message has not been modified during its transmission 143 through the network in such a way that an unauthorized management 144 operation might result. 146 2) The protocol should provide for verification of the identity of 147 the user on whose behalf a received SNMPv3 message claims to have 148 been generated. 150 3) The protocol should provide for detection of received SNMPv3 151 messages, which request or contain management information, whose 152 time of generation was not recent. 154 4) The protocol should provide, when necessary, that the contents of 155 each received SNMPv3 message are protected from disclosure. 157 Blumenthal/Wijnen Expires November 1997 [Page 4] 158 In addition to the principal goal of supporting secure network 159 management, the design of this SNMPv3 security model is also 160 influenced by the following constraints: 162 1) When the requirements of effective management in times of network 163 stress are inconsistent with those of security, the design should 164 prefer the former. 166 2) Neither the security protocol nor its underlying security 167 mechanisms should depend upon the ready availability of other 168 network services (e.g., Network Time Protocol (NTP) or key 169 management protocols). 171 3) A security mechanism should entail no changes to the basic SNMP 172 network management philosophy. 174 1.3. Security Services 176 The security services necessary to support the goals of an SNMPv3 177 security model are as follows. 179 - Data Integrity 180 is the provision of the property that data has not been altered or 181 destroyed in an unauthorized manner, nor have data sequences been 182 altered to an extent greater than can occur non-maliciously. 184 - Data Origin Authentication 185 is the provision of the property that the claimed identity of the 186 user on whose behalf received data was originated is corroborated. 188 - Data Confidentiality 189 is the provision of the property that information is not made 190 available or disclosed to unauthorized individuals, entities, or 191 processes. 193 For the protocols specified in this memo, it is not possible to 194 assure the specific originator of a received SNMPv3 message; rather, 195 it is the user on whose behalf the message was originated that is 196 authenticated. 198 For these protocols, it not possible to obtain data integrity without 199 data origin authentication, nor is it possible to obtain data origin 200 authentication without data integrity. Further, there is no 201 provision for data confidentiality without both data integrity and 202 data origin authentication. 204 The security protocols used in this memo are considered acceptably 205 secure at the time of writing. However, the procedures allow for new 206 authentication and privacy methods to be specified at a future time 207 if the need arises. 209 Blumenthal/Wijnen Expires November 1997 [Page 5] 210 1.4. Implementation Organization 212 The security protocols defined in this memo are implemented in three 213 different modules and each have their specific responsibilities such 214 that together they realize the goals and security services described 215 above: 217 - The timeliness module must provide for: 219 - Protection against message delay or replay (to an extent greater 220 than can occur through normal operation) 222 - The authentication module must provide for: 224 - Data Integrity, 226 - Data Origin Authentication 228 - The privacy module must provide for 230 - Protection against disclosure of the message payload. 232 The timeliness module is fixed for this User-based Security model 233 while there is provision for multiple authentication and/or privacy 234 modules, each of which implements a specific authentication or 235 privacy protocol respectively. 237 1.4.1. Timeliness Module 239 Section 3 (Elements of procedure) uses the time values in an SNMPv3 240 message to do timeliness checking. The timeliness check is only 241 performed if authentication is applied to the message. Since the 242 complete message is checked for integrity, we can assume that the 243 time values in a message that passes the authentication module are 244 trustworthy. 246 1.4.2. Authentication Protocol 248 Section 6 describes the Keyed-MD5 authentication protocol which is 249 the first authentication protocol to be used with the User-based 250 Security model. In the future additional or replacement 251 authentication protocols may be defined as new needs arise. 253 This User-based Security model prescribes that the complete message 254 is checked for integrity in the authentication module. 256 For a message to be authenticated, it needs to pass authentication 257 check by the authentication module and the timeliness check which 258 is a fixed part of this User-based Security model. 260 Blumenthal/Wijnen Expires November 1997 [Page 6] 261 1.4.3. Privacy Protocol 263 Section 7 describes the CBC-DES Symmetric Encryption Protocol which 264 the first privacy protocol to be used with the User-based Security 265 model. In the future additional or replacement privacy protocols 266 may be defined as new needs arise. 268 This User-based Security model prescribes that the scopedPDU 269 is protected from disclosure when a message is sent with privacy. 271 This User-based Security model also prescribes that a message needs 272 to be authenticated if privacy is in use. 274 1.5 Mechanisms to protect against Message Replay, Delay and Redirection 275 1.5.1 Authoritative SNMP Engine 277 In order to protect against message replay, delay and redirection, 278 one of the SNMP engines involved in each communication is designated 279 to be the authoritative engine. For messages with a GET, GETNEXT, 280 GETBULK, SET or INFORM request as the payload, the receiver of such 281 messages is authoritative. For messages with a SNMPv2-TRAP, 282 RESPONSE or REPORT as the payload, the sender is authoritative. 284 1.5.2 The following mechanisms are used: 286 - To protect against the threat of message delay or replay (to an 287 extent greater than can occur through normal operation), a set of 288 time (at the authoritative source) indicators and a request-id are 289 included in each message generated. An SNMPv3 engine evaluates 290 the time indicators to determine if a received message is recent. 291 An SNMPv3 engine may evaluate the time indicators to ensure that 292 a received message is at least as recent as the last message it 293 received from the same source. A non-authoritative SNMPv3 engine 294 uses received authentic messages to advance its notion of time at 295 the remote authoritative source. An SNMPv3 engine also evaluates 296 the request-id in received Response messages and discards messages 297 which do not correspond to outstanding requests. 299 These mechanisms provide for the detection of messages whose time 300 of generation was not recent in all but one circumstance; this 301 circumstance is the delay or replay of a Report message (sent to a 302 receiver) when the receiver has has not recently communicated with 303 the source of the Report message. In this circumstance, the 304 detection guarantees only that the Report message is more recent 305 than the last communication between source and destination of the 306 Report message. However, Report messages do not request or contain 307 management information, and thus, goal #3 in Section 1.2 above is 308 met; further, Report messages can at most cause the receiver to 309 advance its notion of time (at the source) by less than the proper 310 amount. 312 Blumenthal/Wijnen Expires November 1997 [Page 7] 313 This protection against the threat of message delay or replay does 314 not imply nor provide any protection against unauthorized deletion 315 or suppression of messages. Also, an SNMPv3 engine may not be able 316 to detect message reordering if all the messages involved are sent 317 within the Time Window interval. Other mechanisms defined 318 independently of the security protocol can also be used to detect 319 the re-ordering replay, deletion, or suppression of messages 320 containing set operations (e.g., the MIB variable snmpSetSerialNo 321 [RFC1907]). 323 - verifying that a message sent to/from one SNMPv3 engine cannot be 324 replayed to/as-if-from another SNMPv3 engine. 326 Included in each message is an identifier unique to the SNMPv3 327 engine associated with the sender or intended recipient of the 328 message. Also, each message containing a Response PDU contains a 329 request-id which associates the message to a recently generated 330 request. 332 A Report message sent by one SNMPv3 engine to a second SNMPv3 333 engine can potentially be replayed to another SNMPv3 engine. 334 However, Report messages do not request or contain management 335 information, and thus, goal #3 in Section 1.2 above is met; 336 further, Report messages can at most cause the receiver to advance 337 its notion of time (at the authoritative source) by less than the 338 correct amount. 340 - detecting messages which were not recently generated. 342 A set of time indicators are included in the message, indicating 343 the time of generation. Messages (other than those containing 344 Report PDUs) without recent time indicators are not considered 345 authentic. In addition, messages containing Response PDUs have a 346 request-id; if the request-id does not match that of a recently 347 generated request, then the message is not considered to be 348 authentic. 350 A Report message sent by an SNMPv3 engine can potentially be 351 replayed at a later time to an SNMPv3 engine which has not 352 recently communicated with that source engine. However, Report 353 messages do not request or contain management information, and 354 thus, goal #3 in Section 1.2 above is met; further, Report 355 messages can at most cause the receiver to advance its notion of 356 time (at the authoritative source) by less than the correct amount. 357 This memo allows the same user to be defined on multiple SNMPv3 358 engines. Each SNMPv3 engine maintains a value, snmpEngineID, 359 which uniquely identifies the engine. This value is included in each 360 message sent to/from the engine that is authoritative (see section 361 1.5.1). On receipt of a message, an authoritative engine checks the 362 value to ensure it is the intended recipient, and a non-authoritative 363 engine uses the value to ensure that the message is processed 365 Blumenthal/Wijnen Expires November 1997 [Page 8] 366 using the correct state information. 368 Each SNMPv3 engine maintains two values, engineBoots and engineTime, 369 which taken together provide an indication of time at that engine. 370 Both of these values are included in an authenticated message sent 371 to/received from that engine. On receipt, the values are checked to 372 ensure that the indicated time is within a time window of the 373 current time. The time window represents an administrative upper 374 bound on acceptable delivery delay for protocol messages. 376 For an SNMPv3 engine to generate a message which an authoritative 377 engine will accept as authentic, and to verify that a message 378 received from that authoritative engine is authentic, such an engine 379 must first achieve time synchronization with the authoritative 380 engine. 382 Blumenthal/Wijnen Expires November 1997 [Page 9] 383 2. Elements of the Model 385 This section contains definitions required to realize the security 386 model defined by this memo. 388 2.1. SNMPv3 Users 390 Management operations using this security model make use of a defined 391 set of user identities. For any SNMPv3 user on whose behalf 392 management operations are authorized at a particular SNMPv3 engine, 393 that engine must have knowledge of that user. An SNMPv3 engine that 394 wishes to communicate with another SNMPv3 engine must also have 395 knowledge of a user known to that engine, including knowledge of the 396 applicable attributes of that user. 398 A user and its attributes are defined as follows: 400 401 An octet string representing the name of the user. 403 404 An octet string representing the group that the user belongs to. 406 407 An indication of whether messages sent on behalf of this user can 408 be authenticated, and if so, the type of authentication protocol 409 which is used. One such protocol is defined in this memo: the 410 Digest Authentication Protocol. 412 413 An indication of whether messages sent on behalf of this user can 414 be protected from disclosure, and if so, the type of privacy 415 protocol which is used. One such protocol is defined in this memo: 416 the Symmetric Encryption Protocol. 418 2.2. Replay Protection 420 Each SNMPv3 engine maintains three objects: 422 - snmpEngineID, which is an identifier unique among all SNMPv3 423 engines in (at least) an administrative domain; 425 - engineBoots, which is a count of the number of times the engine has 426 re-booted/re-initialized since snmpEngineID was last configured; 427 and, 429 - engineTime, which is the number of seconds since engineBoots was 430 last incremented. 432 Each SNMPv3 engine is always authoritative with respect to these 433 objects in its own engine. It is the responsibility of a non- 434 authoritative SNMPv3 engine to synchronize with the authoritative 435 engine, as appropriate. 437 An authoritative SNMPv3 engine is required to maintain the values of 438 its snmpEngineID and engineBoots in non-volatile storage. 440 2.2.1. snmpEngineID 442 The engineID value contained in an authenticated message is used to 443 defeat attacks in which messages from one engine to another engine 444 are replayed to a different engine. 446 When an authoritative engine is first installed, it sets its local 447 value of snmpEngineID according to a enterprise-specific algorithm 448 (see the definition of engineID in the SNMPng Architectural model 449 document [SNMPng-ARCH]). 451 2.2.2. engineBoots and engineTime 453 The engineBoots and engineTime values contained in an authenticated 454 message are used to defeat attacks in which messages are replayed 455 when they are no longer valid. Through use of engineBoots and 456 engineTime, there is no requirement for an SNMPv3 engine to have a 457 non-volatile clock which ticks (i.e., increases with the passage of 458 time) even when the engine is powered off. Rather, each time an 459 SNMPv3 engine re-boots, it retrieves, increments, and then stores 460 engineBoots in non-volatile storage, and resets engineTime to zero. 462 When an SNMPv3 engine is first installed, it sets its local values 463 of engineBoots and engineTime to zero. If engineTime ever 464 reaches its maximum value (2147483647), then engineBoots is 465 incremented as if the engine has re-booted and engineTime is reset to 466 zero and starts incrementing again. 468 Each time an authoritative SNMPv3 engine re-boots, any SNMPv3 engines 469 holding that authoritative engine's values of engineBoots and 470 engineTime need to re-synchronize prior to sending correctly 471 authenticated messages to that authoritative engine (see Section 472 2.4 for (re-)synchronization procedures). Note, however, that the 473 procedures do provide for a notification to be accepted as authentic 474 by a receiving engine, when sent by an authoritative engine which has 475 re-booted since the receiving engine last (re-)synchronized. 477 If an authoritative SNMPv3 engine is ever unable to determine its 478 latest engineBoots value, then it must set its engineBoots value to 479 0xffffffff. 481 Whenever the local value of engineBoots has the value 0xffffffff, it 482 latches at that value and an authenticated message always causes an 483 usecStatsNotInTimeWindows authentication failure. 485 In order to reset an engine whose engineBoots value has reached the 486 value 0xffffffff, manual intervention is required. The engine must 487 be physically visited and re-configured, either with a new 488 snmpEngineID value, or with new secret values for the authentication 489 and privacy protocols of all users known to that engine. 491 2.2.3. Time Window 493 The Time Window is a value that specifies the window of time in which 494 a message generated on behalf of any user is valid. This memo 495 specifies that the same value of the Time Window, 150 seconds, is 496 used for all users. 498 2.3. Error Reporting 500 While processing a received communication, an SNMPv3 engine may 501 determine that the message is unacceptable (see Section 3). In 502 this case, the appropriate counter from the snmpGroup [RFC1907] or 503 usecStatsGroup object groups is incremented and an error indication 504 is returned to the calling module. 506 If an SNMPv3 engine acting in the authoritative role makes such a 507 determination and the reportableFlag indicates that a report may be 508 generated, then after incrementing the appropriate counter, it is 509 required to generate a message containing a report PDU, with the 510 same userName as in the received message, and to send it to the 511 transport address which originated the received message. For all 512 report PDUs, except those generated due to incrementing the 513 usecStatsNotInTimeWindows counter, the report PDU is unauthenticated. 514 For those generated due to incrementing usecStatsNotInTimeWindows, 515 the report PDU is authenticated only if the received message was 516 authenticated. 518 The reportableFlag in a message may only be set if the message 519 contains a Get, GetNext, GetBulk, Set, Inform operation. The 520 reportableFlag should never be set for a message that contains a 521 Response, SNMPv2-Trap or Report operation. 523 2.4. Time Synchronization 525 Time synchronization, required by a non-authoritative engine (see 526 section 5.1.1) in order to proceed with authentic communications, 527 has occurred when the non-authoritative engine has obtained local 528 values of engineBoots and engineTime from the authoritative engine 529 that are within the authoritative engine's time window. To remain 530 synchronized, the local values must remain within the authoritative 531 engine's time window and thus must be kept loosely synchronized 532 with the values stored at the authoritative engine. 533 In addition to keeping a local version of engineBoots and engineTime, 534 a non-authoritative engine must also keep one other local variable, 535 latestReceivedEngineTime. This value records the highest value of 536 engineTime that was received by the non-authoritative engine from 537 the authoritative engine and is used to eliminate the possibility 538 of replaying messages that would prevent the non-authoritative 539 engine's notion of the engineTime from advancing. 541 Time synchronization occurs as part of the procedures of receiving a 542 message (Section 3.2, step 7b). As such, no explicit time 543 synchronization procedure is required by a non-authoritative engine. 544 Note, that whenever the local value of snmpEngineID is changed (e.g., 545 through discovery) or when a new secret is configured, the local 546 values of engineBoots and latestReceivedEngineTime should be set to 547 zero. This will cause the time synchronization to occur when the 548 next authentic message is received. 550 2.5. SNMPv3 Messages Using this Model 552 The syntax of an SNMPv3 message using this security model adheres 553 to the message format defined in the SNMPng Architectural model 554 document [SNMPng-ARCH]. The securityParameters in the message are 555 defined as an OCTET STRING. The format of that OCTET STRING for 556 the User-based Security model is as follows: 558 securityParameters ::= 559 SEQUENCE { 560 -- global parameters 561 engineID 562 OCTET STRING (SIZE(12)), 563 engineBoots 564 Unsigned32 (0..4294967295), 565 engineTime 566 Unsigned32 (0..2147483647), 567 userName 568 OCTET STRING (SIZE(1..16)), 569 authParameters 570 OCTET STRING, 571 privParameters 572 OCTET STRING, 573 } 574 END 576 The authParameters are defined by the authentication protocol in 577 use for the message (as defined by the authProtocol column in 578 the user's entry in the usecUserTable). 580 The privParameters are defined by the privacy protocol in 581 use for the message (as defined by the privProtocol column in 582 the user's entry in the usecUserTable). 584 2.6 Input and Output of the User-based Security Module 586 This section describes the inputs and outputs that the User-based 587 Security module expects and produces when the Message Processing 588 and Control module (MPC) invokes the User-base Security module for 589 services. 591 2.6.1 Input and Output when generating an SNMPv3 Message 593 When the Message Processing and Control module (MPC) invokes the 594 User-based Security module to secure an outgoing SNMPv3 message, 595 it must pass as arguments: 597 598 this is the global data in the message. The important piece of 599 information is the Level of Security (LoS) from which the 600 User-based Security module determines if the message needs to be 601 protected from disclosure and if the message needs to be 602 authenticated. 604 605 this is the message payload. The data is opaque as far as the 606 User-based Security module is concerned. 608 609 this is an implementation specific handle that identifies an 610 entry in the usecUserTable. 612 613 cached security data to be used when securing an outgoing 614 response. If no cachedSecurityData exists, then the 615 securityCookie is used. 617 -- Editor's note: 618 It is important that a response uses the same auth and priv 619 protocols and secrets as the incoming request. The security 620 module is not supposed to look at the PDU-type. 621 So it seems we need to cache the protocols and secrets either as 622 part of the securityCookie or it needs to be cached as info that 623 is attached to the msgID. We think we prefer the latter, because 624 the MPC also needs to cache certain info (like msgID, origin 625 addressing info) about a message that may result in a response. 626 So it seems we need one more in/output to the MPC. We will use 627 this cached data in the remainder of the text, assuming that 628 for now this is the best way to do it. 629 -- End Editor's note 631 Upon completion of the process, the User-based Security module will 632 return either and error indication or the completed message with 633 privacy and authentication applied if such was requested by the 634 Level of Security (LoS) flags passed as part of the . 636 2.6.1 Input and Output when receiving an SNMPv3 Message 637 When the Message Processing and Control module (MPC) invokes the 638 User-based Security module to verify proper security of an incoming 639 SNMPv3 message, it must pass as arguments: 641 642 this is the global data in the message. The important piece of 643 information is the Level of Security (LoS) from which the 644 User-based Security module determines if the message has been 645 protected from disclosure and if the message has to be checked 646 for authentication. Another piece of information used by the 647 User-based Security module is the Maximum Message Size (MMS) in 648 order to calculate the MMS that a scopedPDU can use in a 649 potential response. 651 652 this is the octet string that contains the User-based Security 653 model specific security parameters. See section 2.5 for details. 655 656 this is the complete message as it was received by the Message 657 Processing and Control module (MPC). In the case of 658 authentication, a digest needs to be calculated over the complete 659 message. 661 Upon completion of the process, the User-based Security module will 662 return either and error indication or these pieces of 663 information/data: 665 666 this is the maximum message size that a possible response PDU 667 may use. The User-based Security module calculates this size such 668 that there is always space available for any security parameters 669 that need to be added to the response message. 671 672 this is the group to which the user belongs. The User-base 673 Security module retrieves this information from the usecUserTable. 675 676 this is an implementation specific handle that identifies an 677 entry in the usecUserTable. It is to be used later when a response 678 message must be secured. 680 681 cached security data to be used when securing a possible outgoing 682 response to this request. 684 685 this is the message payload. The data is opaque as far as the 686 User-based Security module is concerned. But if the data was 687 encrypted because privacy protection was in effect, then upon 688 return from the User-based Security module the data will have 689 been decrypted. 691 3. Elements of Procedure 693 This section describes the security related procedures followed by 694 an SNMPv3 engine when processing SNMPv3 messages according to the 695 User-based Security model. 697 3.1. Processing an Outgoing Message 699 This section describes the procedure followed by an SNMPv3 engine 700 whenever it generates a message containing a management operation 701 (either a request, a response, a notification, or a report) on 702 behalf of a user, with a particular Level of Security (LoS). 704 1) - If any cachedSecurityData exists for this message, then 705 information concerning the user is extracted from the 706 cachedSecurityData. 707 - Otherwise, based on the information in the securityCookie, 708 information concerning the user at the destination engineID 709 is extracted from the Security Configuration Datastore 710 (SCD, usecUserTable). 712 2) If the Level of Security (LoS) specifies that the message is to 713 be protected from disclosure, but the user does not support both 714 an authentication and a privacy protocol then the message cannot 715 be sent. An error indication is returned to the calling module. 717 3) If the Level of Security (LoS) specifies that the message is to 718 be authenticated, but the user does not support an authentication 719 protocol, then the message cannot be sent. An error indication 720 is returned to the calling module. 722 4) If the Level of Security (LoS) specifies that the message is to 723 be protected from disclosure, then the octet sequence 724 representing the serialized scopedPDU is encrypted according to 725 the user's privacy protocol. To do so a call is made to the 726 privacy module that implements the user's privacy protocol. 727 Input passed to the privacy module is: 729 730 the engineID of the authoritative SNMPv3 engine as it will be 731 included in the message. 732 733 the user on whose behalf the message is to be encrypted. 734 735 the engineTime value as it will be included in the message. 736 -- Editor's note: 737 This has been added as an additional input so that the 738 privacy protocol can use it if it so wishes/needs. Turns 739 out that this value is a good value for the IV for DES. 740 -- End Editor's note 741 742 the possible cached security data if this is a response to an 743 earlier request message. 744 745 the data to be encrypted. 747 Upon completion the privacy module must return either an error 748 indication or: 750 751 the encrypted scopedPDU (encoded as an octet string). 752 753 The privacy parameters (encoded as an octet string) that need 754 to be sent in the outgoing message. 756 If an error indication is returned by the privacy module then the 757 message cannot be sent and an error indication is returned to the 758 calling module. 759 If the privacy module returns success, then the 760 field is put into the securityParameters and the 761 serves as the payload of the message being prepared. 763 5) If the Level of Security (LoS) specifies that the message is not 764 to be protected from disclosure, then the NULL string is encoded 765 as an octet string into the field of the 766 securityParameters and the scopedPDU serves as the payload of 767 the message being prepared. 769 6) The engineID is encoded as an octet string into the 770 field of the securityParameters. 772 7) If the Level of Security (LoS) specifies that the message is to 773 be authenticated, then the current values of engineBoots, and 774 engineTime corresponding to engineID from the SCD are used. 775 Otherwise, a zero value is used for engineBoots and engineTime. 776 The values are encoded as Unsigned32 into the and 777 fields of the securityParameters. 779 8) The userName is encoded as an octet string into the 780 field of the securityParameters. 782 9) If the Level of Security (LoS) specifies that the message is to 783 be authenticated, the message is authenticated according to the 784 user's authentication protocol. To do so, a call is made to the 785 authentication module that implements the user's authentication 786 protocol. Input passed to the authentication module is: 788 789 the engineID of the authoritative SNMPv3 engine as it will be 790 included in the message. 791 792 the user on whose behalf the message is to be authenticated. 794 795 the possible cached security data if this is a response to an 796 earlier request message. 797 798 the authParameters, to be filled by the authentication module. 799 800 the message to be authenticated. 802 Output expected from the authentication module is an error 803 indication or the completed message. 804 If an error indication is returned by the authentication module, 805 then the message cannot be sent and an error indication is 806 returned to the calling module. 808 10) If the Level of Security (LoS) specifies that the message is not 809 to be authenticated then the NULL string is encoded as an octet 810 string into the field of the securityParameters. 812 11) The completed message is returned to the calling module. 814 3.2. Processing an Incoming Message 816 This section describes the procedure followed by an SNMPv3 engine 817 whenever it receives a message containing a management operation 818 on behalf of a user, with a particular Level of Security (LoS). 820 1) If the received securityParameters is not the serialization 821 (according to the conventions of [RFC1906]) of an OCTET STRING 822 formatted according to the securityParameters defined in section 823 2.5, then the snmpInASNParseErrs counter [RFC1907] is 824 incremented, and an error indication is returned to the calling 825 module. 827 2) The values of the security parameter fields are extracted from 828 the securityParameters. 830 3) If the field contained in the securityParameters is 831 unknown then: 833 - a manager that performs discovery may optionally create a new 834 entry in its Security Configuration Database (SCD) and continue 835 processing; or 837 - the usecStatsUnknownEngineIDs counter is incremented, a report 838 PDU is generated, and an error indication is returned to the 839 calling module. 841 4) Information about the value of the and 842 fields is extracted from the local Security Configuration 843 Database (SCD, usecUserTable). If no information is available 844 for this user, then the usecStatsUnknownUserNames counter is 845 incremented, a report PDU is generated, and an error indication 846 is returned to the calling module. 848 5) If the information about the user indicates that it does not 849 support the Level of Security indicated by the field in 850 the globalData, then the usecStatsUnsupportedLoS counter is 851 incremented, a report PDU is generated, and an error indication 852 is returned to the calling module. 854 6) If the Lever of Security (LoS) specifies that the message is to 855 be authenticated, then the message is authenticated according to 856 the user's authentication protocol. To do so, a call is made to 857 the authentication module that implements the user's 858 authentication protocol. Input passed to the authentication 859 module is: 861 862 the engineID of the authoritative SNMPv3 engine as it was 863 included in the message. 864 865 the user on whose behalf the message is to be authenticated. 866 867 the authParameters. 868 869 the message to be authenticated. 871 If the message is not authentic according to the authentication 872 protocol module (i.e. it returns an error indication), then an 873 error indication is returned to the calling module. 875 Otherwise the authentication module must return these pieces of 876 information/data: 878 879 the cached security data so that it can be used later when 880 a response to a request message must be secured. 881 -- Editor's note: 882 If we are not supposed to look at the PDU type, then it 883 seems we must always cache the security data. But that then 884 makes it problematic as to who gets rid of the cache and 885 when..... or do we consider that an implementation issue? 886 -- End Editor's note 888 7) If the field indicates an authenticated message, then 889 the local values of engineBoots and engineTime corresponding to 890 the value of the field are extracted from the 891 Security Configuration Database (SCD). 893 a) If the value is the same as the engineID of 894 the processing SNMPv3 engine (meaning that this is the 895 authoritative engine), then if any of the following 896 conditions is true, then the message is considered to be 897 outside of the Time Window: 899 - the local value of engineBoots is 0xffffffff; 901 - the field differs from the local value of 902 engineBoots; or, 904 - the value of the field differs from the local 905 notion of engineTime by more than +/- 150 seconds. 907 If the message is considered to be outside of the Time Window 908 then the usecStatsNotInTimeWindows counter is incremented, an 909 authenticated report PDU is generated (see section 2.3), and 910 an error indication is returned to the calling module. 912 b) If the value is not the same as the engineID of 913 the processing SNMPv3 engine (meaning that this engine is not 914 the authoritative engine), then: 916 - if all of the following conditions are true: 918 - if the field indicates that privacy is not in use; 920 - the SNMPv2 operation type determined from the ASN.1 tag 921 value associated with the PDU's component is a Report; 923 -- Editor's note: 924 So it turns out we do need to look at the PDU data 925 Mmmm... this is against our own rules of cohesion and encapsulation 926 -- End Editor's note 928 - the Report was generated due to a 929 usecStatsNotInTimeWindows error condition; and, 931 - the field is greater than the local value of 932 engineBoots, or the field is equal to the 933 local value of engineBoots and the field is 934 greater than the value of latestReceivedEngineTime, 936 then the SCD entry corresponding to the value of the 937 field is updated, by setting the local value of 938 engineBoots from the field, the value 939 latestReceivedEngineTime from the field, and 940 the local value of engineTime from the field. 942 - if any of the following conditions is true, then the message 943 is considered to be outside of the Time Window: 945 - the local value of engineBoots is 0xffffffff; 946 - the field is less than the local value of 947 engineBoots; or, 949 - the field is equal to the local value of 950 engineBoots and the field is more than 150 951 seconds less than the local notion of engineTime. 953 If the message is considered to be outside of the Time 954 Window then the usecStatsNotInTimeWindows counter is 955 incremented, and an error indication is returned to the 956 calling module; however, time synchronization procedures 957 may be invoked. 958 Note that this procedure allows for to be 959 greater than the local value of engineBoots to allow for 960 received messages to be accepted as authentic when received 961 from an authoritative SNMPv3 engine that has re-booted since 962 the receiving SNMPv3 engine last re-synchronized. 964 - if at least one of the following conditions is true: 966 - the field is greater than the local value of 967 engineBoots; or, 969 - the field is equal to the local value of 970 engineBoots and the field is greater than the 971 value of latestReceivedEngineTime, 973 then the SCD entry corresponding to the value of the 974 field is updated, by setting the local value of 975 engineBoots from the field, the local value 976 latestReceivedEngineTime from the field, and 977 the local value of engineTime from the field. 979 8) If the field indicates that the message was protected from 980 disclosure, then the octet sequence representing the 981 is decrypted according to the user's privacy protocol to obtain 982 a serialized scopedPDUs value. Otherwise the data component is 983 assumed to directly contain the scopedPDUs value. To do the 984 decryption, a call is made to the privacy module that implements 985 the user's privacy protocol. Input passed to the privacy module 986 is: 988 989 the engineID of the authoritative SNMPv3 engine as it was 990 included in the message. 991 992 the user on whose behalf the message is to be decrypted. 993 994 the engineTime value as it was included in the message. 995 996 the data to be decrypted 998 Output expected from the privacy module is an error code or: 1000 1001 the cached security data so that it can be used later when 1002 1003 the decrypted scopedPDU. 1005 If an error code is returned by the privacy module, then an error 1006 indication is returned to the calling module. 1008 9) The scopedPDU-MMS is calculated. 1010 10) The groupName is retrieved from the usecUserTable. 1012 11) The is retrieved from the usecUserTable 1014 12) A return is made to the calling module, passing these values: 1016 1017 the maximum message size that a possible response may use. 1019 1020 the name of the group that the user, on whose behalf the 1021 message was sent, belongs to. 1023 1024 this is an implementation specific handle that identifies an 1025 entry in the usecUserTable. It is to be used later when a 1026 response message must be secured. 1028 1029 the cached security data so that it can be used later when 1031 1032 the scopedPDU (message payload) 1034 4. Discovery 1036 This security model requires that a discovery process obtain 1037 sufficient information about other SNMPv3 entities in order to 1038 communicate with them. Discovery requires the SNMPv3 manager to 1039 learn the engine's snmpEngineID value before communication may 1040 proceed. This may be accomplished by formulating a get-request 1041 communication with the LoS set to noAuth/noPriv, the userName set 1042 to "public", the snmpEngineID set to all zeros (binary), and the 1043 varBindList left empty. The response to this message will be a 1044 report PDU that contains the snmpEngineID within the 1045 field (and containing the 1046 usecStatsUnknownEngineIDs counter in the varBindList). 1047 If authenticated communication is required then the 1048 discovery process may invoke the procedure described in Section 2.4 1049 to synchronize the clocks. 1051 5. Definitions 1053 SNMPv3-USEC-MIB DEFINITIONS ::= BEGIN 1055 IMPORTS 1056 Counter32, Unsigned32, 1057 MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI 1058 TEXTUAL-CONVENTION, TestAndIncr, 1059 RowStatus, AutonomousType, StorageType, 1060 TDomain, TAddress FROM SNMPv2-TC 1061 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF, 1062 SnmpV3GroupName, SnmpV3ContextName, 1063 SnmpV3LoS, SnmpV3EngineID, 1064 SnmpV3SecurityModel, SnmpV3SecurityCookie FROM SNMPv3-MIB; 1066 -- Editor's note: 1067 Not sure if the above are all in SNMPv3-MIB, need to see 1068 how the complete MPC document will look like. 1069 -- End Editor's note 1071 snmpV3UsecMIB MODULE-IDENTITY 1072 LAST-UPDATED "9705090000Z" -- 09 May 1997, midnight 1073 ORGANIZATION "SNMPv3 Working Group" 1074 CONTACT-INFO "WG-email: snmpv3@tis.com 1075 Subscribe: majordomo@tis.com 1076 In msg body: subscribe snmpv3 1078 Chair: Russ Mundy 1079 Trutsed Information Systems 1080 postal: 3060 Washington Rd 1081 Glenwood MD 21738 1082 email: mundy@tis.com 1083 phone: 301-854-6889 1085 Co-editor Uri Blumenthal 1086 IBM T. J. Watson Research 1087 postal: 30 Saw Mill River Pkwy, 1088 Hawthorne, NY 10532 1089 USA 1090 email: uri@watson.ibm.com 1091 phone: +1.914.784.7964 1093 Co-editor: Bert Wijnen 1094 IBM T. J. Watson Research 1095 postal: Schagen 33 1096 3461 GL Linschoten 1097 Netherlands 1098 email: wijnen@vnet.ibm.com 1099 phone: +31-348-412-498 1100 " 1102 DESCRIPTION "The management information definitions for the 1103 SNMPv3 User-based Security model. 1104 " 1105 ::= { snmpModules xx } 1107 -- Administrative assignments **************************************** 1109 snmpV3UsecAdmin OBJECT IDENTIFIER ::= { snmpV3UsecMIB 1 } 1110 snmpV3UsecMIBObjects OBJECT IDENTIFIER ::= { snmpV3UsecMIB 2 } 1111 snmpV3UsecMIBConformance OBJECT IDENTIFIER ::= { snmpV3UsecMIB 3 } 1113 usecAuthProtocols OBJECT IDENTIFIER ::= { snmpV3UsecAdmin 1 } 1115 -- no Authentication Protocol 1116 usecNoAuthProtocol OBJECT IDENTIFIER ::= { usecAuthProtocols 1 } 1118 -- the Digest Authentication Protocol 1119 usecMD5AuthProtocol OBJECT IDENTIFIER ::= { usecAuthProtocols 2 } 1121 -- Privacy Protocols 1122 usecPrivProtocols OBJECT IDENTIFIER ::= { usecAdmin 2 } 1124 -- no Privacy Protocol 1125 usecNoPrivProtocol OBJECT IDENTIFIER ::= { usecPrivProtocols 1 } 1127 -- the Symmetric Encryption Protocol 1128 usecDESPrivProtocol OBJECT IDENTIFIER ::= { usecPrivProtocols 2 } 1130 -- Editor's note: 1131 We picked these up from earlier MIBs. 1132 It all seems a bit overdone though. If a user has no auth 1133 or priv protocol, we could just put the NULL OID { 0 0 } 1134 in the usecUserPrivProtocol or usecUserAuthProtocol column. 1135 There also seems no need to split between auth and priv 1136 protocols. How about the following (simpler) scheme: 1138 usecProtocols OBJECT IDENTIFIER ::= { snmpV3UsecAdmin 1 } 1139 -- the Digest Authentication Protocol 1140 usecMD5AuthProtocol OBJECT IDENTIFIER ::= { usecProtocols 1 } 1141 -- the Symmetric Encryption Protocol 1142 usecDESPrivProtocol OBJECT IDENTIFIER ::= { usecProtocols 2 } 1143 -- End Editor's note 1145 -- Each engine has authoritative values for itself ******************* 1147 snmpEngine OBJECT IDENTIFIER ::= { snmpV3UsecMIBObjects 1 } 1149 snmpEngineID OBJECT-TYPE 1150 SYNTAX SnmpEngineID 1151 MAX-ACCESS read-only 1152 STATUS current 1153 DESCRIPTION "The SNMP engine's administratively-unique identifier." 1154 ::= { snmpEngine 1 } 1156 snmpEngineBoots OBJECT-TYPE 1157 SYNTAX Unsigned32 1158 MAX-ACCESS read-only 1159 STATUS current 1160 DESCRIPTION "The number of times that the engine has re-initialized 1161 itself since its initial configuration. 1162 " 1163 ::= { snmpEngine 2 } 1165 snmpEngineTime OBJECT-TYPE 1166 SYNTAX Unsigned32 (0..2147483647) 1167 UNITS "seconds" 1168 MAX-ACCESS read-only 1169 STATUS current 1170 DESCRIPTION "The number of seconds since the engine last 1171 incremented the snmpEngineBoots object. 1172 " 1173 ::= { snmpEngine 3 } 1175 -- Statistics for the User-based Security model *********************** 1177 usecStats OBJECT IDENTIFIER ::= { snmpV3UsecMIBObjects 2 } 1179 usecStatsUnsupportedLoS OBJECT-TYPE 1180 SYNTAX Counter32 1181 MAX-ACCESS read-only 1182 STATUS current 1183 DESCRIPTION "The total number of packets received by the SNMPv3 1184 engine which were dropped because they requested a 1185 Level of Security that was unknown to the engine or 1186 otherwise unavailable. 1187 " 1188 ::= { usecStats 1 } 1190 usecStatsNotInTimeWindows OBJECT-TYPE 1191 SYNTAX Counter32 1192 MAX-ACCESS read-only 1193 STATUS current 1194 DESCRIPTION "The total number of packets received by the SNMPv3 1195 engine which were dropped because they appeared 1196 outside of the engine's window. 1197 " 1198 ::= { usecStats 2 } 1200 usecStatsUnknownUserNames OBJECT-TYPE 1201 SYNTAX Counter32 1202 MAX-ACCESS read-only 1203 STATUS current 1204 DESCRIPTION "The total number of packets received by the SNMPv3 1205 engine which were dropped because they referenced a 1206 user that was not known to the engine. 1207 " 1208 ::= { usecStats 3 } 1210 usecStatsUnknownEngineIDs OBJECT-TYPE 1211 SYNTAX Counter32 1212 MAX-ACCESS read-only 1213 STATUS current 1214 DESCRIPTION "The total number of packets received by the SNMPv3 1215 engine which were dropped because they referenced an 1216 engineID that was not known to the engine. 1217 " 1218 ::= { usecStats 4 } 1220 -- Textual Conventions *********************************************** 1222 UserName ::= TEXTUAL-CONVENTION 1223 STATUS current 1224 DESCRIPTION "An octet string representing the name of a user for 1225 use in accordance with the SNMPv3 User-based Security 1226 model. 1227 " 1228 SYNTAX OCTET STRING (SIZE(1..16)) 1230 -- The valid users for the User-based Security model ****************** 1232 usecUser OBJECT IDENTIFIER ::= { snmpV3UsecMIBObjects 3 } 1234 usecUserTable OBJECT-TYPE 1235 SYNTAX SEQUENCE OF UsecUserEntry 1236 MAX-ACCESS not-accessible 1237 STATUS current 1238 DESCRIPTION "The table of users configured in the SNMPv3 entity's 1239 security configuration datastore (SCD)." 1240 ::= { usecUser 1 } 1242 usecUserEntry OBJECT-TYPE 1243 SYNTAX UsecUserEntry 1244 MAX-ACCESS not-accessible 1245 STATUS current 1246 DESCRIPTION "A user configured in the SNMPv3 entity's security 1247 configuration datastore (SCD) for the User-based 1248 Security model. 1249 " 1250 INDEX { usecUserEngineID, 1251 IMPLIED usecUserName 1252 } 1253 ::= { usecUserTable 1 } 1255 UsecUserEntry ::= SEQUENCE { 1256 usecUserEngineID SnmpEngineID, 1257 usecUserName UserName, 1258 usecUserGroupName SnmpV3GroupName, 1259 usecUserAuthProtocol OBJECT IDENTIFIER, 1260 usecUserPrivProtocol OBJECT IDENTIFIER, 1261 usecUserStorageType StorageType, 1262 usecUserSecurityCookie SnmpV3SecurityCookie, 1263 usecUserStatus RowStatus 1264 } 1266 usecUserEngineID OBJECT-TYPE 1267 SYNTAX SnmpEngineID 1268 MAX-ACCESS not-accessible 1269 STATUS current 1270 DESCRIPTION "An SNMPv3 engine's administratively-unique identifier. 1272 In a simple agent, this value is always that agent's 1273 own snmpEngineID value. 1275 This value can also take the value of the snmpEngineID 1276 of a remote SNMP engine with which this user can 1277 communicate. 1278 " 1279 ::= { usecUserEntry 1 } 1281 usecUserName OBJECT-TYPE 1282 SYNTAX UserName 1283 MAX-ACCESS not-accessible 1284 STATUS current 1285 DESCRIPTION "An octet string representing the name of the user." 1286 ::= { usecUserEntry 2 } 1288 usecUserGroupName OBJECT-TYPE 1289 SYNTAX SnmpV3GroupName 1290 MAX-ACCESS read-write 1291 STATUS current 1292 DESCRIPTION "An octet string representing the group to which the 1293 user belongs. A group name of zero length indicates 1294 that the user is not [perhaps yet] a member of any 1295 group, possibly because the entry has not yet been 1296 completely configured. Users which are not a part 1297 of any group are effectively disabled to perform any 1298 SNMP operations. 1299 " 1300 DEFVAL { ''H } -- the empty string 1301 ::= { usecUserEntry 3 } 1303 usecUserAuthProtocol OBJECT-TYPE 1304 SYNTAX OBJECT IDENTIFIER 1305 MAX-ACCESS read-create 1306 STATUS current 1307 DESCRIPTION "An indication of whether messages sent on behalf of 1308 this user to/from the engine identified by 1309 usecUserEngineID, can be authenticated, and if so, 1310 the type of authentication protocol which is used. 1312 An instance of this object is created concurrently 1313 with the creation of any other object instance for 1314 the same user (i.e., as part of the processing of 1315 the set operation which creates the first object 1316 instance in the same conceptual row). Once created, 1317 the value of an instance of this object can not be 1318 changed. 1319 " 1320 DEFVAL { usecMD5AuthProtocol } 1321 ::= { usecUserEntry 4 } 1323 usecUserPrivProtocol OBJECT-TYPE 1324 SYNTAX OBJECT IDENTIFIER 1325 MAX-ACCESS read-create 1326 STATUS current 1327 DESCRIPTION "An indication of whether messages sent on behalf of 1328 this user to/from the engine identified by 1329 usecUserEngineID, can be protected from disclosure, 1330 and if so, the type of privacy protocol which is used. 1332 An instance of this object is created concurrently 1333 with the creation of any other object instance for 1334 the same user (i.e., as part of the processing of 1335 the set operation which creates the first object 1336 instance in the same conceptual row). Once created, 1337 the value of an instance of this object can not be 1338 changed. 1339 " 1340 DEFVAL { usecNoPrivProtocol } 1341 ::= { usecUserEntry 5 } 1343 usecUserStorageType OBJECT-TYPE 1344 SYNTAX StorageType 1345 MAX-ACCESS read-create 1346 STATUS current 1347 DESCRIPTION "The storage type for this conceptual row." 1348 DEFVAL { nonVolatile } 1349 ::= { usecUserEntry 7 } 1351 usecUserSecurityCookie OBJECT-TYPE 1352 SYNTAX SnmpV3SecurityCookie 1353 MAX-ACCESS read-only 1354 STATUS current 1355 DESCRIPTION "An implementation specific handle that identifies 1356 the User-based Security model and this entry in the 1357 usecUserTable. 1358 " 1359 DEFVAL { nonVolatile } 1360 ::= { usecUserEntry 7 } 1362 usecUserStatus OBJECT-TYPE 1363 SYNTAX RowStatus 1364 MAX-ACCESS read-create 1365 STATUS current 1366 DESCRIPTION "The status of this conceptual row. Until instances 1367 of all corresponding columns are appropriately 1368 configured, the value of the corresponding instance 1369 of the usecUserStatus column is 'notReady'. 1371 For those columnar objects which permit write-access, 1372 their value in an existing conceptual row can be 1373 changed irrespective of the value of usecUserStatus 1374 for that row. 1375 " 1376 ::= { usecUserEntry 8 } 1378 -- Conformance Information ******************************************* 1380 snmpV3UsecMIBCompliances 1381 OBJECT IDENTIFIER ::= { snmpV3UsecMIBConformance 1 } 1382 snmpV3UsecMIBGroups 1383 OBJECT IDENTIFIER ::= { snmpV3UsecMIBConformance 2 } 1385 -- Compliance statements 1387 snmpV3UsecMIBCompliance MODULE-COMPLIANCE 1388 STATUS current 1389 DESCRIPTION "The compliance statement for SNMPv3 engines which 1390 implement the SNMPv3 USEC MIB. 1391 " 1393 MODULE -- this module 1394 MANDATORY-GROUPS { snmpV3UsecMIBBasicGroup } 1396 OBJECT usecUserGroupName 1397 MIN-ACCESS read-only 1398 DESCRIPTION "Write access is not required." 1400 OBJECT usecUserAuthProtocol 1401 MIN-ACCESS read-only 1402 DESCRIPTION "Write access is not required." 1404 OBJECT usecUserPrivProtocol 1405 MIN-ACCESS read-only 1406 DESCRIPTION "Write access is not required." 1408 ::= { snmpV3UsecMIBCompliances 1 } 1410 -- Units of compliance 1412 snmpV3UsecMIBBasicGroup OBJECT-GROUP 1413 OBJECTS { snmpEngineID, 1414 snmpEngineBoots, 1415 snmpEngineTime, 1416 usecStatsUnsupportedLoS, 1417 usecStatsNotInTimeWindows, 1418 usecStatsUnknownUserNames, 1419 usecStatsUnknownEngineIDs, 1420 usecUserGroupName, 1421 usecUserAuthProtocol, 1422 usecUserPrivProtocol, 1423 usecUserSecurityCookie, 1424 usecUserStorageType, 1425 usecUserStatus 1426 } 1427 STATUS current 1428 DESCRIPTION "A collection of objects providing for configuration 1429 of an SNMPv3 entity which implements the SNMPv3 1430 User-based Security model. 1431 " 1432 ::= { snmpV3UsecMIBGroups 1 } 1434 END 1435 6. MD5 Authentication Protocol 1437 This section describes the Keyed-MD5 authentication protocol. 1438 This protocol is the first authentication protocol defined for 1439 the User-based Security model. 1440 Over time, other authentication protocols may be defined either 1441 as a replacement of this protocol or in addition to this protocol. 1443 6.1 Mechanisms 1445 - In support of data integrity, a message digest algorithm is 1446 required. A digest is calculated over an appropriate portion 1447 of an SNMPv3 message and included as part of the message sent 1448 to the recipient. 1450 - In support of data origin authentication and data integrity, a 1451 secret value is both inserted into, and appended to, the SNMPv3 1452 message prior to computing the digest; the inserted value is 1453 overwritten prior to transmission, and the appended value is not 1454 transmitted. The secret value is shared by all SNMPv3 engines 1455 authorized to originate messages on behalf of the appropriate 1456 user. 1458 - In order to not expose the shared secrets (keys) at all SNMPv3 1459 engines in case one of the engines is compromised, such secrets 1460 (keys) are localized for each authoritative SNMPv3 engine, see 1461 [Localized-Key]. 1463 6.1.1. Digest Authentication Protocol 1465 The Digest Authentication Protocol defined in this memo provides for: 1467 - verifying the integrity of a received message (i.e., the message 1468 received is the message sent). 1470 The integrity of the message is protected by computing a digest 1471 over an appropriate portion of a message. The digest is computed 1472 by the originator of the message, transmitted with the message, and 1473 verified by the recipient of the message. 1475 - verifying the user on whose behalf the message was generated. 1477 A secret value known only to SNMPv3 engines authorized to generate 1478 messages on behalf of a user is both inserted into, and appended 1479 to, the message prior to the digest computation. Thus, the 1480 verification of the user is implicit with the verification of the 1481 digest. (Note that the use of two copies of the secret, one near 1482 the start and one at the end, is recommended by [KEYED-MD5].) 1484 This protocol uses the MD5 [MD5] message digest algorithm. A 128-bit 1485 digest is calculated over the designated portion of an SNMPv3 message 1486 and included as part of the message sent to the recipient. The size 1487 of both the digest carried in a message and the private 1488 authentication key (the secret) is 16 octets. 1490 6.2 Elements of the Digest Authentication Protocol 1492 This section contains definitions required to realize the 1493 authentication module defined by this memo. 1495 6.2.1. SNMPv3 Users 1497 Authentication using this Digest Authentication protocol makes use 1498 of a defined set of user identities. For any SNMPv3 user on whose 1499 behalf a message must be authenticated at a particular SNMPv3 engine, 1500 that engine must have knowledge of that user. An SNMPv3 engine that 1501 wishes to communicate with another SNMPv3 engine must also have 1502 knowledge of a user known to that engine, including knowledge of the 1503 applicable attributes of that user. 1505 A user and its attributes are defined as follows: 1507 1508 An octet string representing the name of the user. 1510 1511 If messages sent on behalf of this user can be authenticated, the 1512 (private) authentication key for use with the authentication 1513 protocol. Note that a user's authentication key will normally be 1514 different at different authoritative engines. 1516 6.2.2. EngineID 1518 The engineID value contained in an authenticated message specifies 1519 the authoritative SNMPv3 engine for that particular message. 1520 (see the definition of engineID in the SNMPng Architectural model 1521 document [SNMPng-ARCH]). 1523 The user's (private) authentication key is normally different at 1524 each authoritative SNMPv3 engine and so the snmpEngineID is used 1525 to select the proper key for the authentication process. 1527 6.2.3. SNMPv3 Messages Using this Authentication Protocol 1529 Messages using this authentication protocol carry an authParameters 1530 field as part of the securityParameters. For this protocol, the 1531 authParameters field is the serialized octet string representing 1532 the MD5 digest of the wholeMessage. 1534 The digest is calculated over the wholeMessage so if a message is 1535 authenticated, that also means that all the fields in the message 1536 are intact and have not been tampered with. 1538 6.2.4 Input and Output of the MD5 Authentication Module 1540 This section describes the inputs and outputs that the MD5 1541 Authentication module expects and produces when the User-based 1542 Security module invokes the MD5 Authentication module for 1543 services. 1545 6.2.4.1 Input and Output when generating an SNMPv3 Message 1547 When the User-based Security module invokes the MD5 Authentication 1548 module to authenticate an outgoing message, it must pass as 1549 arguments: 1551 1552 the engineID of the authoritative SNMPv3 engine as it will be 1553 included in the message. 1554 1555 the user on whose behalf the message is to be authenticated. 1556 1557 the possible cached security data if this is a response to an 1558 earlier request message. 1559 1560 the authParameters, to be filled by the authentication module. 1561 1562 the message to be authenticated. 1564 Output from the MD5 Authentication module is an error indication or 1565 the completed wholeMessage (that is with the digest inserted into 1566 the authParameters field). If an error indication is returned by 1567 the MD5 Authentication module, then the message cannot be sent. 1569 6.2.4.2 Input and Output when receiving an SNMPv3 Message 1571 When the User-based Security module invokes the MD5 Authentication 1572 module to authenticate an incoming message, it must pass as 1573 arguments: 1575 1576 the engineID of the authoritative SNMPv3 engine as it was 1577 included in the message. 1578 1579 the user on whose behalf the message is to be authenticated. 1580 1581 the authParameters. 1582 1583 the message to be authenticated. 1585 Output from the MD5 Authentication module is an error indication or 1586 the authentic wholeMessage plus any cachedSecurityData that may be 1587 needed when authenticating a possible outgoing response to this 1588 (request) message. 1590 If an error indication is returned by the MD5 Authentication module, 1591 then the message cannot be trusted. In the case that there was not 1592 enough information in the Security Configuration Database (SCD) to 1593 actually perform the authentication process, then a report PDU may 1594 have been generated to inform the sender about the error condition. 1596 6.3 Elements of Procedure 1598 This section describes the procedures for the Keyed-MD5 1599 authentication protocol. 1601 6.3.1 Processing an Outgoing Message 1603 This section describes the procedure followed by an SNMPv3 engine 1604 whenever it must authenticate an outgoing message using the 1605 usecMD5AuthProtocol. 1607 1) - If any cachedSecurityData exists for this message, then 1608 information concerning the user is extracted from the 1609 cachedSecurityData. 1610 - Otherwise, the engineID and the userName are used to extract 1611 the information concerning the user from the Security 1612 Configuration Datastore (SCD, authMD5Table). 1614 2) If the engineID is not known by this authentication module, 1615 then the message cannot be sent. An error indication is 1616 returned to the calling module. 1618 3) If the userName is not known by this authentication module, 1619 then the message cannot be sent. An error indication is 1620 returned to the calling module. 1622 4) The authParameters field is set to the serialization according 1623 to the rules in [RFC1907] of an octet string representing the 1624 secret (localized) key of the user. 1626 5) The secret (localized) key of the user is then appended to the 1627 end of the wholeMessage. 1629 6) The MD5-Digest is calculated according to [MD5]. Then the 1630 authParameters field is replaced with the calculated digest. 1632 7) The wholeMessage (excluding the appended secret key) is then 1633 returned to the caller. 1635 6.3.2 Processing an Incoming Message 1637 This section describes the procedure followed by an SNMPv3 engine 1638 whenever it must authenticate an incoming message using the 1639 usecMD5AuthProtocol. 1641 1) If the engineID is not known by this authentication module, 1642 then the authMD5StatsUnknownEngineIDs counter is incremented, 1643 a report PDU is generated and an error indication is returned 1644 to the calling module. 1646 2) If the userName is not known by this authentication module, 1647 then the authMD5StatsUnknownUserNames counter is incremented, 1648 a report PDU is generated and an error indication is returned 1649 to the calling module. 1651 3) If the digest received in the authParameters field is not 1652 16 octets long, then the authMD5StatsWrongDigests counter is 1653 incremented, a report PDU is generated and an error indication 1654 is returned to the calling module. 1656 4) The digest received in the authParameters field is saved. 1658 5) The engineID and the userName are used to extract information 1659 concerning the user from the Security Configuration Datastore 1660 (SCD, authMD5Table). 1662 6) The digest in the authParameters field is replaced by the user's 1663 secret (localized) key. 1665 7) The secret (localized) key of the user is then appended to the 1666 end of the wholeMessage. 1668 8) The MD5-Digest is calculated according to [MD5]. 1669 The authParameters field is replaced with the digest value 1670 that was saved in step 4). 1672 9) Then the newly calculated digest is compared with the digest 1673 saved in step 4). If the digests do not match, then the 1674 authMD5StatsUnknownUserNames counter is incremented, a report 1675 PDU is generated and an error indication is returned to the 1676 calling module. 1678 10) The secret key (used for calculating the digest) is cached 1679 as part of the cachedSecurityData. 1681 11) The wholeMessage (excluding the appended secret key) and the 1682 cachedSecurityData is then returned to the caller. 1684 6.4 Definitions 1686 SNMPv3-AUTH-MD5-MIB DEFINITIONS ::= BEGIN 1688 IMPORTS 1689 Counter32, Unsigned32, 1690 MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI 1691 TEXTUAL-CONVENTION, TestAndIncr, 1692 RowStatus, AutonomousType, StorageType, 1693 TDomain, TAddress, RowPointer FROM SNMPv2-TC 1694 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF, 1695 SnmpV3GroupName, SnmpV3ContextName, 1696 SnmpV3LoS, SnmpV3EngineID, 1697 SnmpV3SecurityModel FROM SNMPv3-MIB, 1698 UserName, usecMD5AuthProtocol FROM SNMPv3-USEC-MIB; 1700 authMD5MIB MODULE-IDENTITY 1701 LAST-UPDATED "9705090000Z" -- 09 May 1997, midnight 1702 ORGANIZATION "SNMPv3 Working Group" 1703 CONTACT-INFO "WG-email: snmpv3@tis.com 1704 Subscribe: majordomo@tis.com 1705 In msg body: subscribe snmpv3 1707 Chair: Russ Mundy 1708 Trutsed Information Systems 1709 postal: 3060 Washington Rd 1710 Glenwood MD 21738 1711 email: mundy@tis.com 1712 phone: 301-854-6889 1714 Co-editor Uri Blumenthal 1715 IBM T. J. Watson Research 1716 postal: 30 Saw Mill River Pkwy, 1717 Hawthorne, NY 10532 1718 USA 1719 email: uri@watson.ibm.com 1720 phone: +1.914.784.7964 1722 Co-editor: Bert Wijnen 1723 IBM T. J. Watson Research 1724 postal: Schagen 33 1725 3461 GL Linschoten 1726 Netherlands 1727 email: wijnen@vnet.ibm.com 1728 phone: +31-348-412-498 1729 " 1731 DESCRIPTION "The management information definitions for the 1732 Keyed-MD5 authentication protocol for use with the 1733 SNMPv3 User-based Security model. 1734 " 1736 ::= { snmpModules xx } 1738 -- Administrative assignments **************************************** 1740 authMD5Admin OBJECT IDENTIFIER ::= { authMD5MIB 1 } 1741 authMD5MIBObjects OBJECT IDENTIFIER ::= { authMD5MIB 2 } 1742 authMD5MIBConformance OBJECT IDENTIFIER ::= { authMD5MIB 3 } 1744 -- Textual Conventions ********************************************** 1746 -- Editor's note: 1747 -- Do we need to define this so generic. 1748 -- Maybe we can just assume the usecAuthMD5Protocol 1749 -- If we make it generic, then we can use this TC with several 1750 -- ciphers - those we use now, and those people might want to 1751 -- use in the future, like IDEA, Blowfish, SEAL, whatever... 1752 -- But certainly for now it makes this TC more complicated then 1753 -- what we need now. 1754 -- End Editor's note 1756 KeyChange ::= TEXTUAL-CONVENTION 1757 STATUS current 1758 DESCRIPTION 1759 "Every definition of an object with this syntax must identify 1760 a protocol, P, and a secret key, K. The object's value is a 1761 manager-generated, partially-random value which, when 1762 modified, causes the value of the secret key, K, to be 1763 modified via a one-way function. 1765 The value of an instance of this object is the concatenation 1766 of two components: a 'random' component and a 'delta' 1767 component. The lengths of the random and delta components are 1768 given by the corresponding value of the protocol, P; if P 1769 requires K to be a fixed length, the length of both the random 1770 and delta components is that fixed length; if P allows the 1771 length of K to be variable up to a particular maximum length, 1772 the length of the random component is that maximum length and 1773 the length of the delta component is any length less than or 1774 equal to that maximum length. For example, 1775 usecMD5AuthProtocol requires K to be a fixed length of 16 1776 octets. Other protocols may define other sizes, as deemed 1777 appropriate. 1779 When an instance of this object is modified to have a new 1780 value by the management protocol, the agent generates a new 1781 value of K as follows: 1783 - a temporary variable is initialized to the existing value 1784 of K; 1785 - if the length of the delta component is greater than 16 1786 bytes, then: 1788 - the random component is appended to the value of the 1789 temporary variable, and the result is input to the MD5 1790 hash algorithm to produce a digest value, and the 1791 temporary variable is set to this digest value; 1792 - the value of the temporary variable is XOR-ed with the 1793 first (next) 16-bytes of the delta component to produce 1794 the first (next) 16-bytes of the new value of K. 1795 - the above two steps are repeated until the unused 1796 portion of the delta component is 16 bytes or less, 1797 - the random component is appended to the value of the 1798 temporary variable, and the result is input to the MD5 1799 hash algorithm to produce a digest value; 1800 - this digest value, truncated if necessary to be the same 1801 length as the unused portion of the delta component, is 1802 XOR-ed with the unused portion of the delta component to 1803 produce the (final portion of the) new value of K. 1805 i.e., 1807 iterations = (lenOfDelta - 1)/16; /* integer division */ 1808 temp = keyOld; 1809 for (i = 0; i < iterations; i++) { 1810 temp = MD5 (temp || random); 1811 keyNew[i*16 .. (i*16)+15] = 1812 temp XOR delta[i*16 .. (i*16)+15]; 1813 } 1814 temp = MD5 (temp || random); 1815 keyNew[i*16 .. lenOfDelta-1] = 1816 temp XOR delta[i*16 .. lenOfDelta-1]; 1818 The value of an object with this syntax, whenever it is 1819 retrieved by the management protocol, is always the zero- 1820 length string." 1821 SYNTAX OCTET STRING 1823 -- ******************************************************************* 1825 authMD5Stats OBJECT IDENTIFIER ::= { authMD5MIBObjects 1 } 1827 authMD5StatsUnknownUserNames OBJECT-TYPE 1828 SYNTAX Counter32 1829 MAX-ACCESS read-only 1830 STATUS current 1831 DESCRIPTION "The total number of packets received by the SNMPv3 1832 engine which were dropped because they referenced a 1833 user that was not known to the MD5 authentication 1834 module in the engine. 1835 " 1836 ::= { authMD5Stats 1 } 1838 authMD5StatsUnknownEngineIDs OBJECT-TYPE 1839 SYNTAX Counter32 1840 MAX-ACCESS read-only 1841 STATUS current 1842 DESCRIPTION "The total number of packets received by the SNMPv3 1843 engine which were dropped because they referenced an 1844 engineID that was not known to the MD5 authentication 1845 module in the engine. 1846 " 1847 ::= { authMD5Stats 2 } 1849 authMD5StatsWrongDigests OBJECT-TYPE 1850 SYNTAX Counter32 1851 MAX-ACCESS read-only 1852 STATUS current 1853 DESCRIPTION "The total number of packets received by the SNMPv3 1854 engine which were dropped because they didn't 1855 contain the expected digest value. 1856 " 1857 ::= { authMD5Stats 3 } 1859 -- ******************************************************************* 1861 authMD5Table OBJECT-TYPE 1862 SYNTAX SEQUENCE OF AuthMD5TableEntry 1863 MAX-ACCESS not-accessible 1864 STATUS current 1865 DESCRIPTION "The SNMPv3 security configuration database (SCD) for 1866 authentication information for users who use the 1867 usecAuthMD5Protocol as the authentication protocol. 1868 " 1869 ::= { authMD5MIBObjects 2 } 1871 authMD5TableEntry OBJECT-TYPE 1872 SYNTAX AuthMD5TableEntry 1873 MAX-ACCESS not-accessible 1874 STATUS current 1875 DESCRIPTION "An entry for a particular SNMPv3 user and engineID." 1876 INDEX { authMD5EngineID, 1877 IMPLIED authMD5UserName 1878 } 1879 ::= { authMD5Table 1 } 1881 AuthMD5TableEntry ::= SEQUENCE { 1882 authMD5EngineID SnmpV3EngineID, 1883 authMD5UserName UserName, 1884 authMD5KeyChange KeyChange, 1885 authMD5CloneFrom RowPointer, 1886 authMD5Public OCTET STRING, 1887 authMD5StorageType StorageType, 1888 authMD5Status RowStatus 1889 } 1890 authMD5EngineID OBJECT-TYPE 1891 SYNTAX SnmpEngineID 1892 MAX-ACCESS not-accessible 1893 STATUS current 1894 DESCRIPTION "An SNMPv3 engine's administratively-unique identifier. 1896 In a simple agent, this value is always that agent's 1897 own snmpEngineID value. 1899 This value can also take the value of the snmpEngineID 1900 of a remote SNMP engine with which this user can 1901 communicate. 1902 " 1903 ::= { authMD5TableEntry 1 } 1905 authMD5UserName OBJECT-TYPE 1906 SYNTAX UserName 1907 MAX-ACCESS not-accessible 1908 STATUS current 1909 DESCRIPTION "An octet string representing the name of the user." 1910 ::= { authMD5TableEntry 2 } 1912 authMD5KeyChange OBJECT-TYPE 1913 SYNTAX KeyChange -- typically (SIZE (0..32)) 1914 MAX-ACCESS read-create 1915 STATUS current 1916 DESCRIPTION "An object, which when modified, causes the secret 1917 authentication key used for messages sent on behalf 1918 of this user to/from the engine identified by 1919 authMD5EngineID, to be modified via a one-way function. 1921 The associated protocol is the usecAuthMD5Protocol. 1922 The associated secret key is the user's secret 1923 authentication key. 1925 When creating a new user, it is an 'inconsistentName' 1926 error for a set operation to refer to this object 1927 unless it is previously or concurrently initialized 1928 through a set operation on the corresponding value 1929 of authMD5CloneFrom. 1930 " 1931 DEFVAL { ''H } -- the empty string 1932 ::= { authMD5TableEntry 3 } 1934 authMD5CloneFrom OBJECT-TYPE 1935 SYNTAX RowPointer 1936 MAX-ACCESS read-create 1937 STATUS current 1938 DESCRIPTION "A pointer to another conceptual row in this 1939 authMD5Table. The user in this other conceptual row 1940 is called the clone-from user. 1942 When a new user is created (i.e., a new conceptual row 1943 is instantiated in this table), the authentication 1944 parameters of the new user are cloned from its 1945 clone-from user. 1947 The first time an instance of this object is set by a 1948 management operation (either at or after its 1949 instantiation), the cloning process is invoked. 1950 Subsequent writes are successful but invoke no action 1951 to be taken by the agent. 1952 The cloning process fails with an 'inconsistentName' 1953 error if the conceptual row representing the 1954 clone-from user is not in an active state when the 1955 cloning process is invoked. 1957 Cloning also causes the initial values of the secret 1958 authentication key of the new user to be set to the 1959 same value as the corresponding secret of the 1960 clone-from user. 1962 When this object is read, the zero length string is 1963 returned. 1964 " 1965 ::= { authMD5TableEntry 4 } 1967 authMD5Public OBJECT-TYPE 1968 SYNTAX OCTET STRING (SIZE(0..32)) 1969 MAX-ACCESS read-create 1970 STATUS current 1971 DESCRIPTION "A publicly-readable value which is written as part 1972 of the procedure for changing a user's secret key, 1973 and later read to determine whether the change of 1974 the secrets was effected. 1975 " 1976 DEFVAL { ''H } -- the empty string 1977 ::= { authMD5TableEntry 5 } 1979 authMD5StorageType OBJECT-TYPE 1980 SYNTAX StorageType 1981 MAX-ACCESS read-create 1982 STATUS current 1983 DESCRIPTION "The storage type for this conceptual row. 1985 Conceptual rows having the value 'permanent' must allow 1986 write-access at a minimum to authMD5KeyChange and 1987 authMD5Public. 1989 Note that any user which employs authentication must 1990 allow its secret to be updated and thus an entry in 1991 this table cannot be 'readOnly'. 1992 " 1993 DEFVAL { nonVolatile } 1994 ::= { authMD5TableEntry 6 } 1996 authMD5Status OBJECT-TYPE 1997 SYNTAX RowStatus 1998 MAX-ACCESS read-create 1999 STATUS current 2000 DESCRIPTION "The status of this conceptual row. Until instances of 2001 all corresponding columns are appropriately configured, 2002 the value of the corresponding instance of the 2003 authMD5Status column is 'notReady'. In particular, 2004 a value must have been written to the authMD5CloneFrom 2005 column. 2007 For those columnar objects which permit write-access, 2008 their value in an existing conceptual row can be 2009 changed irrespective of the value of authMD5Status for 2010 that row. 2011 " 2012 ::= { authMD5TableEntry 7 } 2014 authMD5SecretSpinLock OBJECT-TYPE 2015 SYNTAX TestAndIncr 2016 MAX-ACCESS read-write 2017 STATUS current 2018 DESCRIPTION "An advisory lock used to allow several cooperating 2019 SNMPv3 engines, all acting in a manager role, to 2020 coordinate their use of facilities to alter secrets 2021 in the authMD5Table. 2022 " 2023 ::= { authMD5MIBObjects 3 } 2025 -- Conformance Information ******************************************* 2027 authMD5MIBCompliances 2028 OBJECT IDENTIFIER ::= { authMD5MIBConformance 1 } 2029 authMD5MIBGroups 2030 OBJECT IDENTIFIER ::= { authMD5MIBConformance 2 } 2032 -- Compliance statements 2034 authMD5MIBCompliance MODULE-COMPLIANCE 2035 STATUS current 2036 DESCRIPTION "The compliance statement for SNMPv3 engines which 2037 implement the SNMPv3 authMD5 MIB. 2038 " 2040 MODULE -- this module 2041 MANDATORY-GROUPS { authMD5MIBBasicGroup } 2043 ::= { authMD5MIBCompliances 1 } 2045 -- Units of compliance 2047 authMD5MIBBasicGroup OBJECT-GROUP 2048 OBJECTS { authMD5StatsUnknownUserNames, 2049 authMD5StatsUnknownEngineIDs, 2050 authMD5StatsWrongDigests, 2051 authMD5KeyChange, 2052 authMD5CloneFrom, 2053 authMD5Public, 2054 authMD5StorageType, 2055 authMD5Status, 2056 authMD5SecretSpinLock 2057 } 2058 STATUS current 2059 DESCRIPTION "A collection of objects providing for configuration 2060 of an SNMPv3 entity which implements the SNMPv3 2061 MD5 Authentication Protocol. 2062 " 2063 ::= { authMD5MIBGroups 1 } 2065 END 2066 7. DES Privacy Protocol 2068 This section describes the DES privacy protocol. 2069 This protocol is the first privacy protocol defined for the 2070 User-based Security model. 2071 Over time, other privacy protocols may be defined either 2072 as a replacement of this protocol or in addition to this protocol. 2074 7.1 Mechanisms 2076 - In support of data confidentiality, an encryption algorithm is 2077 required. An appropriate portion of the message is encrypted 2078 prior to being transmitted. The User-based Security model 2079 specifies that the scopedPDU is the portion of the message 2080 that needs to be encrypted. 2082 - A secret value is in combination with a time value is used to 2083 create the en/decryption key and the initialization vector. 2084 The secret value is shared by all SNMPv3 engines authorized to 2085 originate messages on behalf of the appropriate user. 2087 - In order to not expose the shared secrets (keys) at all SNMPv3 2088 engines in case one of the engines is compromised, such secrets 2089 (keys) are localized for each authoritative SNMPv3 engine, see 2090 [Localized-Key]. 2092 7.1.1. Symmetric Encryption Protocol 2094 The Symmetric Encryption Protocol defined in this memo provides 2095 support for data confidentiality. The designated portion of an 2096 SNMPv3 message is encrypted and included as part of the message 2097 sent to the recipient. 2099 This memo requires that if data confidentiality is supported by 2100 an SNMPv3 engine, this engine must implement at least the Data 2101 Encryption Standard (DES) in the Cipher Block Chaining mode of 2102 operation. 2104 Two organizations have published specifications defining the DES: the 2105 National Institute of Standards and Technology (NIST) [DES-NIST] and 2106 the American National Standards Institute [DES-ANSI]. There is a 2107 companion Modes of Operation specification for each definition 2108 (see [DESO-NIST] and [DESO-ANSI], respectively). 2110 The NIST has published three additional documents that implementers 2111 may find useful. 2113 - There is a document with guidelines for implementing and using the 2114 DES, including functional specifications for the DES and its modes 2115 of operation [DESG-NIST]. 2117 - There is a specification of a validation test suite for the DES 2118 [DEST-NIST]. The suite is designed to test all aspects of the DES 2119 and is useful for pinpointing specific problems. 2121 - There is a specification of a maintenance test for the DES 2122 [DESM-NIST]. The test utilizes a minimal amount of data and 2123 processing to test all components of the DES. It provides a 2124 simple yes-or-no indication of correct operation and is useful 2125 to run as part of an initialization step, e.g., when a computer 2126 re-boots. 2128 7.1.1.1 DES key and Initialization Vector. 2130 The first 8 bytes of the 16-byte secret (private privacy key) are 2131 used as a DES key. 2132 Since DES uses only 56 bits, the Least Significant Bit in each 2133 byte is disregarded. 2135 The Initialization Vector for encryption is obtained using the 2136 following procedure. 2137 The last 8 bytes of the 16-byte secret (private privacy key) are 2138 used as pre-IV. The 32-bit engineTime is converted to a 4-byte 2139 octet string, Most Significant Byte first. This octet string is 2140 XOR-ed with the first four bytes of the pre-IV. The result is the 2141 Initialization Vector to be used in the subsequent encryption. 2142 The engine must ensure that the same value of engineTime is encoded 2143 in the securityParameters structure. 2145 -- Editor's note: 2146 Possibly, if we want to keep things clean and properly separated, 2147 then the engineTime should be duplicated in the privParameters. 2148 The engineTime in the header of the securityParameters is used for 2149 the timeliness checks, and so is used/handled in a different module. 2150 Do we want those extra bytes on the wire? 2151 -- End Editor's note 2153 7.1.1.2 Data Encryption. 2155 The data to be encrypted is treated as sequence of octets. Its 2156 length should be an integral multiple of 8 - and if not, the 2157 data is padded at the end as necessary. The actual pad value 2158 is irrelevant. 2160 The data is encrypted in Cipher Block Chaining mode. 2161 The plaintext is divided into 64-bit blocks. 2163 The plaintext for each block is XOR-ed with the ciphertext 2164 of the previous block, the result is encrypted and the output 2165 of the encryption is the ciphertext for the block. 2166 This procedure is repeated until there are no more plaintext 2167 blocks. 2169 For the very first block, the Initialization Vector is used 2170 instead of the ciphertext of the previous block. 2172 7.1.1.3 Data Decryption 2174 Before decryption, the encrypted data length is verified. 2175 If the length of the octet sequence to be decrypted is not an 2176 integral multiple of 8 octets, the processing of the octet sequence 2177 is halted and an appropriate exception noted. When decrypting, the 2178 padding is ignored. 2180 The first ciphertext block is decrypted, the decryption output is 2181 XOR-ed with the Initialization Vector, and the result is the first 2182 plaintext block. 2184 For each subsequent block, the ciphertext block is decrypted, 2185 the decryption output is XOR-ed with the previous ciphertext 2186 block and the result is the plaintext block. 2188 7.2 Elements of the DES Privacy Protocol 2190 This section contains definitions required to realize the privacy 2191 module defined by this memo. 2193 7.2.1. SNMPv3 Users 2195 Data En/Decryption using this Symmetric Encryption Protocol makes use 2196 of a defined set of user identities. For any SNMPv3 user on whose 2197 behalf a message must be en/decrypted at a particular SNMPv3 engine, 2198 that engine must have knowledge of that user. An SNMPv3 engine that 2199 wishes to communicate with another SNMPv3 engine must also have 2200 knowledge of a user known to that engine, including knowledge of the 2201 applicable attributes of that user. 2203 A user and its attributes are defined as follows: 2205 2206 An octet string representing the name of the user. 2208 2209 If messages sent on behalf of this user can be en/decrypted, the 2210 (private) privacy key for use with the privacy protocol. Note that 2211 a user's privacy key will normally be different at different 2212 authoritative engines. 2214 7.2.2. EngineID 2216 The engineID value contained in an authenticated message specifies 2217 the authoritative SNMPv3 engine for that particular message. 2218 (see the definition of engineID in the SNMPng Architectural model 2219 document [SNMPng-ARCH]). 2221 The user's (private) authentication key is normally different at 2222 each authoritative SNMPv3 engine and so the snmpEngineID is used 2223 to select the proper key for the authentication process. 2225 7.2.3. SNMPv3 Messages Using this Privacy Protocol 2227 Messages using this privacy protocol carry a privParameters 2228 field as part of the securityParameters. For this protocol, the 2229 privParameters field is the serialized octet string representing 2230 a NULL (zero length) string. 2232 7.2.4 Input and Output of the DES Privacy Module 2234 This section describes the inputs and outputs that the DES Privacy 2235 module expects and produces when the User-based Security module 2236 invokes the DES Privacy module for services. 2238 7.2.4.1 Input and Output when generating an SNMPv3 Message 2240 When the User-based Security module invokes the DES Privacy module 2241 to encrypt part of an outgoing message, it must pass as arguments: 2243 2244 the engineID of the authoritative SNMPv3 engine as it will be 2245 included in the message. 2246 2247 the user on whose behalf the message is to be encrypted. 2248 2249 the engineTime value as it will be included in the message. 2250 2251 the possible cached security data if this is a response to an 2252 earlier request message. 2253 2254 the data to be encrypted. 2256 Upon completion the privacy module must return either an error 2257 indication or: 2259 2260 the encrypted scopedPDU (encoded as an octet string). 2261 2262 The privacy parameters (encoded as an octet string) that need 2263 to be sent in the outgoing message. 2265 7.2.4.2 Input and Output when receiving an SNMPv3 Message 2267 When the User-based Security module invokes the DES Privacy module 2268 to decrypt part of an incoming message, it must pass as arguments: 2270 2271 the engineID of the authoritative SNMPv3 engine as it was 2272 included in the message. 2273 2274 the user on whose behalf the message is to be decrypted. 2275 2276 the engineTime value as it was included in the message. 2277 2278 the data to be decrypted 2280 Output expected from the privacy module is an error code or: 2282 2283 the cached security data so that it can be used later when 2284 2285 the decrypted scopedPDU. 2287 If an error indication is returned by the DES Privacy module, then 2288 the message cannot be decrypted and so the data is unusable and 2289 cannot be trusted. In the case that there was not enough 2290 information in the Security Configuration Database (SCD) to 2291 actually perform the privacy process, then a report PDU may 2292 have been generated to inform the sender about the error condition. 2294 7.3 Elements of Procedure. 2296 This section describes the procedures for the DES privacy protocol. 2298 7.3.1 Processing an Outgoing Message 2300 This section describes the procedure followed by an SNMPv3 engine 2301 whenever it must encrypt part of an outgoing message using the 2302 usecDESPrivProtocol. 2304 1) - If any cachedSecurityData exists for this message, then 2305 information concerning the user is extracted from the 2306 cachedSecurityData. 2307 - Otherwise, the engineID and the userName are used to extract 2308 the information concerning the user from the Security 2309 Configuration Datastore (SCD, privDESTable). 2311 2) If the engineID is not known by this privacy module, 2312 then the message cannot be sent. An error indication is 2313 returned to the calling module. 2315 3) If the userName is not known by this privacy module, 2316 then the message cannot be sent. An error indication is 2317 returned to the calling module. 2319 4) The authParameters field is set to the serialization according 2320 to the rules in [RFC1907] of an octet string representing the 2321 the NULL (zero length) string. 2323 5) The secret (localized) key of the user and the engineTime are 2324 then used to construct the DES encryption key and pre-IV (as 2325 described in 7.1.1.1). 2327 6) The scopedPDU is encrypted (as described in 7.1.1.2) and the 2328 encrypted data is serialized according to the rules in [RFC1907] 2329 as an octet string. 2331 7) The the serialized octet string representing the encrypted 2332 scopedPDU and the cachedSecurityData together with the 2333 privParameters is returned to the caller. 2335 7.3.2 Processing an Incoming Message 2337 This section describes the procedure followed by an SNMPv3 engine 2338 whenever it must decrypt part of an incoming message using the 2339 usecDESPrivProtocol. 2341 1) If the engineID is not known by this privacy module, then the 2342 privDESStatsUnknownEngineIDs counter is incremented, a report 2343 PDU is generated and an error indication is returned to the 2344 calling module. 2346 2) If the userName is not known by this privacy module, then the 2347 privDESStatsUnknownUserNames counter is incremented, a report 2348 PDU is generated and an error indication is returned to the 2349 calling module. 2351 3) If the privParameters field is not the NULL (zero length) string, 2352 then the privDESStatsDecryptionErrors counter is incremented, 2353 a report PDU is generated and an error indication is returned 2354 to the calling module. 2356 4) The engineID and the userName are used to extract information 2357 concerning the user from the Security Configuration Datastore 2358 (SCD, privDESTable). 2360 5) The secret (localized) key of the user and the engineTime are 2361 then used to construct the DES decryption key and pre-IV (as 2362 described in 7.1.1.1). 2364 6) The encryptedPDU is decrypted (as described in 7.1.1.3). 2366 7) If the encryptedPDU cannot be decrypted, then the 2367 privDESStatsDecryptionErrors counter is incremented, a report 2368 PDU is generated and an error indication is returned to the 2369 calling module. 2371 8) The secret (localized) key (used for constructing the DES 2372 decryption key and the pre-IV) is cached as part of the 2373 cachedSecurityData. 2375 9) The decrypted data is returned to the calling module as the 2376 scopedPDU together with the cachedSecurityData. 2378 7.4 Definitions 2380 SNMPv3-PRIV-DES-MIB DEFINITIONS ::= BEGIN 2382 IMPORTS 2383 Counter32, Unsigned32, 2384 MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI 2385 TEXTUAL-CONVENTION, TestAndIncr, 2386 RowStatus, AutonomousType, StorageType, 2387 TDomain, TAddress, RowPointer FROM SNMPv2-TC 2388 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF, 2389 SnmpV3GroupName, SnmpV3ContextName, 2390 SnmpV3LoS, SnmpV3EngineID, 2391 SnmpV3SecurityModel FROM SNMPv3-MIB, 2392 UserName, usecDESPrivProtocol FROM SNMPv3-USEC-MIB, 2393 KeyChange FROM SNMPv3-AUTH-MD5-MIB; 2394 privDESMIB MODULE-IDENTITY 2395 LAST-UPDATED "9705090000Z" -- 09 May 1997, midnight 2396 ORGANIZATION "SNMPv3 Working Group" 2397 CONTACT-INFO "WG-email: snmpv3@tis.com 2398 Subscribe: majordomo@tis.com 2399 In msg body: subscribe snmpv3 2401 Chair: Russ Mundy 2402 Trutsed Information Systems 2403 postal: 3060 Washington Rd 2404 Glenwood MD 21738 2405 email: mundy@tis.com 2406 phone: 301-854-6889 2408 Co-editor Uri Blumenthal 2409 IBM T. J. Watson Research 2410 postal: 30 Saw Mill River Pkwy, 2411 Hawthorne, NY 10532 2412 USA 2413 email: uri@watson.ibm.com 2414 phone: +1.914.784.7964 2416 Co-editor: Bert Wijnen 2417 IBM T. J. Watson Research 2418 postal: Schagen 33 2419 3461 GL Linschoten 2420 Netherlands 2421 email: wijnen@vnet.ibm.com 2422 phone: +31-348-412-498 2423 " 2425 DESCRIPTION "The management information definitions for the 2426 Keyed-MD5 authentication protocol for use with the 2427 SNMPv3 User-based Security model. 2428 " 2430 ::= { snmpModules xx } 2432 -- Administrative assignments **************************************** 2434 privDESAdmin OBJECT IDENTIFIER ::= { privDESMIB 1 } 2435 privDESMIBObjects OBJECT IDENTIFIER ::= { privDESMIB 2 } 2436 privDESMIBConformance OBJECT IDENTIFIER ::= { privDESMIB 3 } 2438 -- ******************************************************************* 2440 privDESStats OBJECT IDENTIFIER ::= { privDESMIBObjects 1 } 2442 privDESStatsUnknownUserNames OBJECT-TYPE 2443 SYNTAX Counter32 2444 MAX-ACCESS read-only 2445 STATUS current 2446 DESCRIPTION "The total number of packets received by the SNMPv3 2447 engine which were dropped because they referenced a 2448 user that was not known to the DES privacy module 2449 in the engine. 2450 " 2451 ::= { privDESStats 1 } 2453 privDESStatsUnknownEngineIDs OBJECT-TYPE 2454 SYNTAX Counter32 2455 MAX-ACCESS read-only 2456 STATUS current 2457 DESCRIPTION "The total number of packets received by the SNMPv3 2458 engine which were dropped because they referenced an 2459 engineID that was not known to the DES privacy module 2460 in the engine. 2461 " 2462 ::= { privDESStats 2 } 2464 privDESStatsDecryptionErrors OBJECT-TYPE 2465 SYNTAX Counter32 2466 MAX-ACCESS read-only 2467 STATUS current 2468 DESCRIPTION "The total number of packets received by the SNMPv3 2469 engine which were dropped because they could not be 2470 decrypted. 2471 " 2472 ::= { privDESStats 3 } 2474 -- ******************************************************************* 2476 privDESTable OBJECT-TYPE 2477 SYNTAX SEQUENCE OF PrivDESTableEntry 2478 MAX-ACCESS not-accessible 2479 STATUS current 2480 DESCRIPTION "The SNMPv3 security configuration database (SCD) for 2481 privacy information for users who use the 2482 usecDESPrivProtocol as the privacy protocol. 2483 " 2484 ::= { privDESMIBObjects 2 } 2486 privDESTableEntry OBJECT-TYPE 2487 SYNTAX PrivDESTableEntry 2488 MAX-ACCESS not-accessible 2489 STATUS current 2490 DESCRIPTION "An entry for a particular SNMPv3 user and engineID." 2491 INDEX { privDESEngineID, 2492 IMPLIED privDESUserName 2493 } 2494 ::= { privDESTable 1 } 2496 PrivDESTableEntry ::= SEQUENCE { 2497 privDESEngineID SnmpV3EngineID, 2498 privDESUserName UserName, 2499 privDESKeyChange KeyChange, 2500 privDESCloneFrom RowPointer, 2501 privDESPublic OCTET STRING, 2502 privDESStorageType StorageType, 2503 privDESStatus RowStatus 2504 } 2506 privDESEngineID OBJECT-TYPE 2507 SYNTAX SnmpEngineID 2508 MAX-ACCESS not-accessible 2509 STATUS current 2510 DESCRIPTION "An SNMPv3 engine's administratively-unique identifier. 2512 In a simple agent, this value is always that agent's 2513 own snmpEngineID value. 2515 This value can also take the value of the snmpEngineID 2516 of a remote SNMP engine with which this user can 2517 communicate. 2518 " 2519 ::= { privDESTableEntry 1 } 2521 privDESUserName OBJECT-TYPE 2522 SYNTAX UserName 2523 MAX-ACCESS not-accessible 2524 STATUS current 2525 DESCRIPTION "An octet string representing the name of the user." 2526 ::= { privDESTableEntry 2 } 2528 privDESKeyChange OBJECT-TYPE 2529 SYNTAX KeyChange -- typically (SIZE (0..32)) 2530 MAX-ACCESS read-create 2531 STATUS current 2532 DESCRIPTION "An object, which when modified, causes the secret 2533 privacy key used for messages sent on behalf of this 2534 user to/from the engine identified by privDESEngineID, 2535 to be modified via a one-way function. 2537 The associated protocol is the usecDESPrivProtocol. 2538 The associated secret key is the user's secret 2539 privacy key. 2541 When creating a new user, it is an 'inconsistentName' 2542 error for a set operation to refer to this object 2543 unless it is previously or concurrently initialized 2544 through a set operation on the corresponding value 2545 of privDESCloneFrom. 2546 " 2547 DEFVAL { ''H } -- the empty string 2548 ::= { privDESTableEntry 3 } 2550 privDESCloneFrom OBJECT-TYPE 2551 SYNTAX RowPointer 2552 MAX-ACCESS read-create 2553 STATUS current 2554 DESCRIPTION "A pointer to another conceptual row in this 2555 privDESTable. The user in this other conceptual row 2556 is called the clone-from user. 2558 When a new user is created (i.e., a new conceptual row 2559 is instantiated in this table), the privacy parameters 2560 of the new user are cloned from its clone-from user. 2562 The first time an instance of this object is set by a 2563 management operation (either at or after its 2564 instantiation), the cloning process is invoked. 2565 Subsequent writes are successful but invoke no action 2566 to be taken by the agent. 2567 The cloning process fails with an 'inconsistentName' 2568 error if the conceptual row representing the 2569 clone-from user is not in an active state when the 2570 cloning process is invoked. 2572 Cloning also causes the initial values of the secret 2573 privacy key of the new user to be set to the same 2574 value as the corresponding secret of the clone-from 2575 user. 2577 When this object is read, the zero length string is 2578 returned. 2579 " 2580 ::= { privDESTableEntry 4 } 2582 privDESPublic OBJECT-TYPE 2583 SYNTAX OCTET STRING (SIZE(1..32)) 2584 MAX-ACCESS read-create 2585 STATUS current 2586 DESCRIPTION "A publicly-readable value which is written as part 2587 of the procedure for changing a user's secret key, 2588 and later read to determine whether the change of 2589 the secrets was effected. 2590 " 2591 DEFVAL { ''H } -- the empty string 2592 ::= { privDESTableEntry 5 } 2594 privDESStorageType OBJECT-TYPE 2595 SYNTAX StorageType 2596 MAX-ACCESS read-create 2597 STATUS current 2598 DESCRIPTION "The storage type for this conceptual row. 2600 Conceptual rows having the value 'permanent' must allow 2601 write-access at a minimum to privDESKeyChange and 2602 privDESPublic. 2604 Note that any user which employs privacy must allow 2605 its secret to be updated and thus an entry in this 2606 table cannot be 'readOnly'. 2607 " 2608 DEFVAL { nonVolatile } 2609 ::= { privDESTableEntry 6 } 2611 privDESStatus OBJECT-TYPE 2612 SYNTAX RowStatus 2613 MAX-ACCESS read-create 2614 STATUS current 2615 DESCRIPTION "The status of this conceptual row. Until instances of 2616 all corresponding columns are appropriately configured, 2617 the value of the corresponding instance of the 2618 privDESStatus column is 'notReady'. In particular, 2619 a value must have been written to the privDESCloneFrom 2620 column. 2622 For those columnar objects which permit write-access, 2623 their value in an existing conceptual row can be 2624 changed irrespective of the value of privDESStatus 2625 for that row. 2626 " 2627 ::= { privDESTableEntry 7 } 2629 privDESSecretSpinLock OBJECT-TYPE 2630 SYNTAX TestAndIncr 2631 MAX-ACCESS read-write 2632 STATUS current 2633 DESCRIPTION "An advisory lock used to allow several cooperating 2634 SNMPv3 engines, all acting in a manager role, to 2635 coordinate their use of facilities to alter secrets 2636 in the privDESTable. 2637 " 2638 ::= { privDESMIBObjects 3 } 2640 -- Conformance Information ******************************************* 2642 privDESMIBCompliances 2643 OBJECT IDENTIFIER ::= { privDESMIBConformance 1 } 2644 privDESMIBGroups 2645 OBJECT IDENTIFIER ::= { privDESMIBConformance 2 } 2647 -- Compliance statements 2649 privDESMIBCompliance MODULE-COMPLIANCE 2650 STATUS current 2651 DESCRIPTION "The compliance statement for SNMPv3 engines which 2652 implement the SNMPv3 privDES MIB. 2653 " 2655 MODULE -- this module 2656 MANDATORY-GROUPS { privDESMIBBasicGroup } 2658 ::= { privDESMIBCompliances 1 } 2660 -- Units of compliance 2662 privDESMIBBasicGroup OBJECT-GROUP 2663 OBJECTS { privDESStatsUnknownUserNames, 2664 privDESStatsUnknownEngineIDs, 2665 privDESStatsDecryptionErrors, 2666 privDESKeyChange, 2667 privDESCloneFrom, 2668 privDESPublic, 2669 privDESStorageType, 2670 privDESStatus, 2671 privDESSecretSpinLock 2672 } 2673 STATUS current 2674 DESCRIPTION "A collection of objects providing for configuration 2675 of an SNMPv3 entity which implements the SNMPv3 2676 DES Privacy Protocol. 2677 " 2678 ::= { privDESMIBGroups 1 } 2680 END 2681 8. Editor's Addresses 2683 Co-editor Uri Blumenthal 2684 IBM T. J. Watson Research 2685 postal: 30 Saw Mill River Pkwy, 2686 Hawthorne, NY 10532 2687 USA 2688 email: uri@watson.ibm.com 2689 phone: +1-914-784-7064 2691 Co-editor: Bert Wijnen 2692 IBM T. J. Watson Research 2693 postal: Schagen 33 2694 3461 GL Linschoten 2695 Netherlands 2696 email: wijnen@vnet.ibm.com 2697 phone: +31-348-432-794 2699 9. Acknowledgements 2701 This document is based on the recommendations of the SNMP Security and 2702 Administrative Framework Evolution team, comprised of 2704 David Harrington (Cabletron Systems Inc.) 2705 Jeff Johnson (Cisco) 2706 David Levi (SNMP Research Inc.) 2707 John Linn (Openvision) 2708 Russ Mundy (Trusted Information Systems) chair 2709 Shawn Routhier (Epilogue) 2710 Glenn Waters (Nortel) 2711 Bert Wijnen (IBM T. J. Watson Research) 2713 Further a lot of "cut and paste" material comes from RFC1910 and from 2714 earlier draft documents from the SNMPv2u and SNMPv2* series. 2716 Further more a special thanks is due to the SNMPv3 WG, specifically: 2717 .... 2719 10. Security Considerations 2721 10.1. Recommended Practices 2723 This section describes practices that contribute to the secure, 2724 effective operation of the mechanisms defined in this memo. 2726 - A management station must discard SNMPv3 responses for which 2727 neither the msgID nor the request-id component or the represented 2728 management information corresponds to any currently outstanding 2729 request. 2731 Although it would be typical for a management station to do this 2732 as a matter of course, when using these security protocols it is 2733 significant due to the possibility of message duplication 2734 (malicious or otherwise). 2736 - A management station must generate unpredictable msgIDs and 2737 request-ids in authenticated messages in order to protect against 2738 the possibility of message duplication (malicious or otherwise). 2740 - A management station should perform time synchronization using 2741 authenticated messages in order to protect against the possibility 2742 of message duplication (malicious or otherwise). 2744 - When sending state altering messages to a managed agent, a 2745 management station should delay sending successive messages to the 2746 managed agent until a positive acknowledgement is received for the 2747 previous message or until the previous message expires. 2749 No message ordering is imposed by the SNMPv3. Messages may be 2750 received in any order relative to their time of generation and 2751 each will be processed in the ordered received. Note that when an 2752 authenticated message is sent to a managed agent, it will be valid 2753 for a period of time of approximately 150 seconds under normal 2754 circumstances, and is subject to replay during this period. 2755 Indeed, a management station must cope with the loss and 2756 re-ordering of messages resulting from anomalies in the network 2757 as a matter of course. 2759 However, a managed object, snmpSetSerialNo [RFC1907], is 2760 specifically defined for use with SNMPv2 set operations in order 2761 to provide a mechanism to ensure the processing of SNMPv2 messages 2762 occurs in a specific order. 2764 - The frequency with which the secrets of an SNMPv3 user should be 2765 changed is indirectly related to the frequency of their use. 2767 Protecting the secrets from disclosure is critical to the overall 2768 security of the protocols. Frequent use of a secret provides a 2769 continued source of data that may be useful to a cryptanalyst in 2770 exploiting known or perceived weaknesses in an algorithm. 2771 Frequent changes to the secret avoid this vulnerability. 2773 Changing a secret after each use is generally regarded as the most 2774 secure practice, but a significant amount of overhead may be 2775 associated with that approach. 2777 Note, too, in a local environment the threat of disclosure may be 2778 less significant, and as such the changing of secrets may be less 2779 frequent. However, when public data networks are the 2780 communication paths, more caution is prudent. 2782 10.2 Defining Users 2784 The mechanisms defined in this document employ the notion of "users" 2785 which map into "groups" and such "groups" have access rights. 2786 How "users" are defined is subject to the security policy of the 2787 network administration. For example, users could be individuals 2788 (e.g., "joe" or "jane"), or a particular role (e.g., "operator" or 2789 "administrator"), or a combination (e.g., "joe-operator", 2790 "jane-operator" or "joe-admin"). Furthermore, a "user" may be a 2791 logical entity, such as a manager station application or set 2792 of manager station applications, acting on behalf of an individual 2793 or role, or set of individuals, or set of roles, including 2794 combinations. 2796 Appendix A describes an algorithm for mapping a user "password" to a 2797 16 octet value for use as either a user's authentication key or 2798 privacy key (or both). Note however, that using the same password 2799 (and therefore the same key) for both authentication and privacy is 2800 very poor security practice and should be strongly discouraged. 2801 Passwords are often generated, remembered, and input by a human. 2802 Human-generated passwords may be less than the 16 octets required 2803 by the authentication and privacy protocols, and brute force 2804 attacks can be quite easy on a relatively short ASCII character set. 2805 Therefore, the algorithm is Appendix A performs a transformation on 2806 the password. If the Appendix A algorithm is used, SNMP 2807 implementations (and SNMP configuration applications) must ensure 2808 that passwords are at least 8 characters in length. 2810 Because the Appendix A algorithm uses such passwords (nearly) 2811 directly, it is very important that they not be easily guessed. It 2812 is suggested that they be composed of mixed-case alphanumeric and 2813 punctuation characters that don't form words or phrases that might 2814 be found in a dictionary. Longer passwords improve the security of 2815 the system. Users may wish to input multiword phrases to make their 2816 password string longer while ensuring that it is memorable. 2818 Since it is infeasible for human users to maintain different 2819 passwords for every engine, but security requirements strongly 2820 discourage having the same key for more than one engine, SNMPv3 2821 employs a compromise proposed in [Localized-key]. 2822 It derives the user keys for the SNMPv3 engines from user's password 2823 in such a way that it is practically impossible to either determine 2824 the user's password, or user's key for another SNMPv3 engine from 2825 any combination of user's keys on SNMPv3 engines. 2827 Note however, that if user's password is disclosed, key localization 2828 will not help and network security may be compromised in this case. 2830 10.3. Conformance 2832 To be termed a "Secure SNMPv3 implementation" based on the User-base 2833 Security model, an SNMPv3 implementation: 2835 - must implement one or more Authentication Protocol(s). The MD5 2836 Authentication Protocol defined in this memo is one such protocol. 2838 - must, to the maximal extent possible, prohibit access to the 2839 secret(s) of each user about which it maintains information in a 2840 Security Configuration Database (SCD) under all circumstances 2841 except as required to generate and/or validate SNMPv3 messages 2842 with respect to that user. 2844 - must implement these MIBs: 2845 - SNMPv3 USEC MIB. 2846 - the authentication MIB for the authentication protocol(s) in 2847 use. The SNMPv3 AUTH-MD5 MIB defined in this memo is one such 2848 MIB. 2850 In addition, an SNMPv3 agent must provide initial configuration in 2851 accordance with Appendix A.1. 2853 Implementation of a Privacy Protocol (the Symmetric Encryption 2854 Protocol defined in this memo is one such protocol) and its related 2855 MIB (the SNMPv3 PRIV-DES MIB defined in this memo is one such MIB) 2856 is optional. 2858 11. References 2860 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2861 Rose, M., and S., Waldbusser, "Structure of Management 2862 Information for Version 2 of the Simple Network Management 2863 Protocol (SNMPv2)", RFC 1905, January 1996. 2865 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2866 Rose, M., and S., Waldbusser, "Protocol Operations for 2867 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2868 RFC 1905, January 1996. 2870 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2871 Rose, M., and S. Waldbusser, "Transport Mappings for 2872 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2873 RFC 1906, January 1996. 2875 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2876 Rose, M., and S. Waldbusser, "Management Information Base for 2877 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2878 RFC 1907 January 1996. 2880 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2881 Rose, M., and S. Waldbusser, "Coexistence between Version 1 2882 and Version 2 of the Internet-standard Network Management 2883 Framework", RFC 1908, January 1996. 2885 [SNMPng-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B., 2886 "Architectural Model for the Next Generation Simple Network 2887 Managememt Protocol (SNMPng)", 2888 draft-ietf-snmpv3-next-gen-arch-00.txt, 2889 March 1997. 2891 [SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D., 2892 "Message Processing and Control Model for version 3 of the Simple 2893 Network Management Protocol (SNMPv3)", 2894 draft-ietf-snmpv3-mpc-00.txt, 2895 March 1997. 2897 [SNMPv3-LPM] The SNMPv3 Working Group, Wijnen, B., Harrington, D., 2898 "Local Processing Model for version 3 of the Simple Network 2899 Management Protocol (SNMPv3)", 2900 draft-ietf-snmpv3-lpm-00.txt, 2901 March 1997. 2903 [SNMPv3-USEC] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B. 2904 "User-Based Security Model for version 3 of the Simple Network 2905 Managememt Protocol (SNMPv3)", 2906 draft-ietf-snmpv3-usec-00.txt, April 1997. 2908 [Localized-Key] U. Blumenthal, N. C. Hien, B. Wijnen 2909 "Key Derivation for Network Management Applications" 2910 IEEE Network Magazine, April/May issue, 1997. 2912 [KEYED-MD5] Krawczyk, H., 2913 "Keyed-MD5 for Message Authentication", 2914 Work in Progress, IBM, June 1995. 2916 [MD5] Rivest, R. 2917 "Message Digest Algorithm MD5" 2918 RFC 1321. 2920 [DES-NIST] Data Encryption Standard, National Institute of Standards 2921 and Technology. Federal Information Processing Standard (FIPS) 2922 Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; 2923 reaffirmed January, 1988). 2925 [DES-ANSI] Data Encryption Algorithm, American National Standards 2926 Institute. ANSI X3.92-1981, (December, 1980). 2928 [DESO-NIST] DES Modes of Operation, National Institute of Standards and 2929 Technology. Federal Information Processing Standard (FIPS) 2930 Publication 81, (December, 1980). 2932 [DESO-ANSI] Data Encryption Algorithm - Modes of Operation, American 2933 National Standards Institute. ANSI X3.106-1983, (May 1983). 2935 [DESG-NIST] Guidelines for Implementing and Using the NBS Data 2936 Encryption Standard, National Institute of Standards and 2937 Technology. Federal Information Processing Standard (FIPS) 2938 Publication 74, (April, 1981). 2940 [DEST-NIST] Validating the Correctness of Hardware Implementations of 2941 the NBS Data Encryption Standard, National Institute of Standards 2942 and Technology. Special Publication 500-20. 2944 [DESM-NIST] Maintenance Testing for the Data Encryption Standard, 2945 National Institute of Standards and Technology. 2946 Special Publication 500-61, (August, 1980). 2948 APPENDIX A - Installation 2950 A.1. Engine Installation Parameters 2952 During installation, an SNMPv3 engine acting in an authoritative role 2953 is configured with several parameters. These include: 2955 (1) one or more secrets 2957 These are the authentication/privacy secrets for the first user 2958 to be configured. 2960 One way to accomplish this is to have the installer enter a 2961 "password" for each required secret. The password is then 2962 algorithmically converted into the required secret by: 2964 - forming a string of length 1,048,576 octets by repeating the 2965 value of the password as often as necessary, truncating 2966 accordingly, and using the resulting string as the input to 2967 the MD5 algorithm [MD5]. The resulting digest, termed "digest1", 2968 is used in the next step. 2970 - a second string of length 44 octets is formed by concatenating 2971 digest1, the SNMPv3 engine's snmpEngineID value, and digest1. 2972 This string is used as input to the MD5 algorithm [MD5]. 2974 The resulting digest is the required secret (see Appendix A.2). 2976 With these configured parameters, the SNMPv3 engine instantiates 2977 the following usecUserEntry in the usecUserTable: 2979 no privacy support privacy support 2980 ------------------ --------------- 2981 usecUserEngineID localEngineID localEngineID 2982 usecUserName "public" "public" 2983 usecUserGroupName "public" "public" 2984 usecUserAuthProtocol usecMD5AuthProtocol usecMD5AuthProtocol 2985 usecUserPrivProtocol none usecDESPrivProtocol 2986 usecUserStorageType permanent permanent 2987 usecUserSecurityCookie 2988 usecUserStatus active active 2990 With these configured parameters, the SNMPv3 engine instantiates 2991 the following authMD5TableEntry in the authMD5Table: 2993 no privacy support privacy support 2994 ------------------ --------------- 2995 authMD5EngineID localEngineID localEngineID 2996 authMD5UserName "public" "public" 2997 authMD5KeyChange "" "" 2998 authMD5CloneFrom ZeroDotZero ZeroDotZero 2999 authMD5Public "" "" 3000 authMD5StorageType permanent permanent 3001 authMD5Status active active 3003 With these configured parameters, the SNMPv3 engine instantiates 3004 the following authMD5TableEntry in the authMD5Table: 3006 no privacy support privacy support 3007 ------------------ --------------- 3008 authMD5EngineID localEngineID 3009 authMD5UserName "public" 3010 authMD5KeyChange "" 3011 authMD5CloneFrom ZeroDotZero 3012 authMD5Public "" 3013 authMD5StorageType permanent 3014 authMD5Status active 3016 A.2. Password to Key Algorithm 3018 The following code fragment demonstrates the password to key 3019 algorithm which can be used when mapping a password to an 3020 authentication or privacy key. The calls to MD5 are as 3021 documented in RFC1321 [RFC1321] 3023 void password_to_key( 3024 u_char *password, /* IN */ 3025 u_int passwordlen, /* IN */ 3026 u_char *agentID, /* IN - ptr to 12 octet long snmpEngineID */ 3027 u_char *key) /* OUT - caller's pointer to 16-byte buffer */ 3028 { 3029 MD5_CTX MD; 3030 u_char *cp, password_buf[64]; 3031 u_long password_index = 0; 3032 u_long count = 0, i; 3034 MD5Init (&MD); /* initialize MD5 */ 3036 /**********************************************/ 3037 /* Use while loop until we've done 1 Megabyte */ 3038 /**********************************************/ 3039 while (count < 1048576) { 3040 cp = password_buf; 3041 for (i = 0; i < 64; i++) { 3042 /*************************************************/ 3043 /* Take the next byte of the password, wrapping */ 3044 /* to the beginning of the password as necessary.*/ 3045 /*************************************************/ 3046 *cp++ = password[password_index++ % passwordlen]; 3047 } 3048 MDupdate (&MD, password_buf, 64); 3049 count += 64; 3050 } 3051 MD5Final (key, &MD); /* tell MD5 we're done */ 3053 /*****************************************************/ 3054 /* Now localize the key with the agentID and pass */ 3055 /* through MD5 to produce final key */ 3056 /*****************************************************/ 3057 memcpy(password_buf, key, 16); 3058 memcpy(password_buf+16, agentID, 12); 3059 memcpy(password_buf+28, key, 16); 3061 MD5Init(&MD); 3062 MDupdate(&MD, password_buf, 44); 3063 MD5Final(key, &MD); 3065 return; 3066 } 3067 A.3. Password to Key Sample 3069 The following shows a sample output of the password to key algorithm. 3071 With a password of "maplesyrup" the output of the password to key 3072 algorithm before the key is localized with the engine's engineID is: 3074 '9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H 3076 After the intermediate key (shown above) is localized with the 3077 snmpEngineID value of: 3079 '00 00 00 00 00 00 00 00 00 00 00 02'H 3081 the final output of the password to key algorithm is: 3083 '52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H 3085 Table of Contents 3087 0. Change Log 2 3088 1. Introduction 3 3089 1.1. Threats 3 3090 1.2. Goals and Constraints 4 3091 1.3. Security Services 5 3092 1.4. Implementation Organization 6 3093 1.4.1. Timeliness Module 6 3094 1.4.2. Authentication Protocol 6 3095 1.4.3. Privacy Protocol 7 3096 1.5 Mechanisms to protect against Message Replay, Delay and Redirection 7 3097 1.5.1 Authoritative SNMP Engine 7 3098 1.5.2 The following mechanisms are used: 7 3099 1.5.1). On receipt of a message, an authoritative engine checks the 8 3100 2. Elements of the Model 10 3101 2.1. SNMPv3 Users 10 3102 2.2. Replay Protection 10 3103 2.2.1. snmpEngineID 11 3104 2.2.2. engineBoots and engineTime 11 3105 2.4 for (re-)synchronization procedures). Note, however, that the 11 3106 2.2.3. Time Window 12 3107 2.3. Error Reporting 12 3108 2.4. Time Synchronization 12 3109 2.5. SNMPv3 Messages Using this Model 13 3110 2.6 Input and Output of the User-based Security Module 13 3111 2.6.1 Input and Output when generating an SNMPv3 Message 14 3112 2.6.1 Input and Output when receiving an SNMPv3 Message 14 3113 3. Elements of Procedure 17 3114 3.1. Processing an Outgoing Message 17 3115 3.2. Processing an Incoming Message 19 3116 2.5, then the snmpInASNParseErrs counter [RFC1907] is 19 3117 4. Discovery 24 3118 5. Definitions 25 3119 6. MD5 Authentication Protocol 33 3120 6.1 Mechanisms 33 3121 6.1.1. Digest Authentication Protocol 33 3122 6.2 Elements of the Digest Authentication Protocol 34 3123 6.2.1. SNMPv3 Users 34 3124 6.2.2. EngineID 34 3125 6.2.3. SNMPv3 Messages Using this Authentication Protocol 34 3126 6.2.4 Input and Output of the MD5 Authentication Module 35 3127 6.2.4.1 Input and Output when generating an SNMPv3 Message 35 3128 6.2.4.2 Input and Output when receiving an SNMPv3 Message 35 3129 6.3 Elements of Procedure 36 3130 6.3.1 Processing an Outgoing Message 36 3131 6.3.2 Processing an Incoming Message 36 3132 6.4 Definitions 38 3133 7. DES Privacy Protocol 46 3134 7.1 Mechanisms 46 3135 7.1.1. Symmetric Encryption Protocol 46 3136 7.1.1.1 DES key and Initialization Vector. 47 3137 7.1.1.2 Data Encryption. 47 3138 7.1.1.3 Data Decryption 48 3139 7.2 Elements of the DES Privacy Protocol 48 3140 7.2.1. SNMPv3 Users 48 3141 7.2.2. EngineID 48 3142 7.2.3. SNMPv3 Messages Using this Privacy Protocol 49 3143 7.2.4 Input and Output of the DES Privacy Module 49 3144 7.2.4.1 Input and Output when generating an SNMPv3 Message 49 3145 7.2.4.2 Input and Output when receiving an SNMPv3 Message 49 3146 7.3 Elements of Procedure. 50 3147 7.3.1 Processing an Outgoing Message 50 3148 7.3.2 Processing an Incoming Message 51 3149 7.4 Definitions 53 3150 8. Editor's Addresses 59 3151 9. Acknowledgements 59 3152 A.1. Engine Installation Parameters 65 3153 A.2. Password to Key Algorithm 67 3154 A.3. Password to Key Sample 68