idnits 2.17.1 draft-ietf-snmpv3-usec-01.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-19) 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 56) being 75 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. ** The abstract seems to contain references ([SNMP-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2410 has weird spacing: '...support priva...' == Line 2417 has weird spacing: '...rotocol imf...' == Line 2420 has weird spacing: '...rotocol non...' == Line 2435 has weird spacing: '... u_int pass...' -- 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 (18 June 1997) is 9802 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 2262, but not defined == Missing Reference: 'RFC1321' is mentioned on line 2431, but not defined -- Looks like a reference, but probably isn't: '64' on line 2440 == Unused Reference: 'RFC1902' is defined on line 2295, but no explicit reference was found in the text == Unused Reference: 'RFC1905' is defined on line 2300, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 2315, but no explicit reference was found in the text == Unused Reference: 'SNMPv3-MPC' is defined on line 2324, but no explicit reference was found in the text == Unused Reference: 'SNMPv3-ACM' is defined on line 2329, 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-02 == Outdated reference: A later version (-05) exists of draft-ietf-snmpv3-mpc-01 == Outdated reference: A later version (-04) exists of draft-ietf-snmpv3-acm-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: 16 errors (**), 0 flaws (~~), 16 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 User-based Security Model for version 3 of the 2 Simple Network Management Protocol (SNMPv3) 4 18 June 1997 6 U. Blumenthal 7 IBM T. J. Watson Research 8 uri@watson.ibm.com 10 B. Wijnen 11 IBM T. J. Watson Research 12 wijnen@vnet.ibm.com 14 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 31 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 33 Abstract 35 This document describes the User-based Security Model (USEC) for SNMP 36 version 3 for use in the SNMP architecture [SNMP-ARCH]. This 37 document defines the Elements of Procedure for providing SNMP message 38 level security. This document also includes a MIB for remotely 39 monitoring/managing the configuration parameters for this Security 40 model. 42 0.1 Issues 43 - Do we indeed want to move all STATS counters to MPC, we 44 have assumed so for now. 45 - Do we need to do group mapping here and pass it back to MPC 46 we have assumed so for now... but other documents do not pass 47 groupName around. 49 Blumenthal/Wijnen Expires December 1997 [Page 1] 50 - Do we want to check reportableFlag to determine if caching 51 of securityData is needed or not. 53 0.2 Change Log 55 [version 1.2] 56 - changed (simplified) time sync in section 3 item 7. 57 - added usecUserMiId 58 - cleaned up text 59 - defined IV "salt" generation 60 - removed Statistics counters (now in MPC) and reportPDU 61 generation (now in MPC) 62 - Removed auth and des MIBs which are now merged into USEC MIB 63 - specified where cachedSecurityData needs to be discarded 64 - added abtract service interface definitions 65 - removed section on error reporting (is MPC responsibility) 66 - removed auth/priv protocol definitions, they are in ARCH now 67 - removed MIB definitions for snmpEngineID,Time,Boots. They 68 are in ARCH now. 70 [version 1.1] 71 - removed . 72 - added , . 73 - added abstract function interface description of 74 inter-module communications. 75 - modified IV generation process to accomodate messages produced 76 faster than one-per-second (still open). 77 - always update the clock regardless of whether incoming message 78 was Report or not (if the message was properly authenticated 79 and its timestamp is ahead of our notion of their clock). 81 [version 1.0] 82 - first version posted to the v3editors mailing list. 83 - based on v2adv slides, v2adv items and issues list and on 84 RFC1910 and SNMPv2u and SNMPv2* documents. 85 - various iterations were done by the authors via private email. 87 Blumenthal/Wijnen Expires December 1997 [Page 2] 88 1. Introduction 90 The Architecture for describing Internet Management Frameworks 91 is composed of multiple subsystems: 92 1) a message processing and control subsystem, 93 2) a security subsystem, 94 3) an access control subsystem, and 95 4) orangelets. 97 It is important to understand the SNMP architecture and the 98 terminology of the architecture to understand where the model 99 described in this document fits into the architecture and interacts 100 with other subsystems within the architecture. The reader is 101 expected to have read and understood the description of the SNMP 102 architecture, as defined in [SNMP-ARCH]. 104 This memo [SNMPv3-USEC] describes the User-Based Security model 105 as it is used within the SNMP Architecture. The main idea is that 106 we use the traditional concept of a user (identified by a userName) 107 to associate security information with. 109 This memo describes the use of Keyed-MD5 as the authentication 110 protocol and the use of CBC-DES as the privacy protocol. 111 The User-based Security model however allows for other such 112 protocols to be used instead of or concurrent with these protocols. 113 So the description of Keyed-MD5 and CBC-DES are in separate sections. 114 That way it shows that they are supposed to be self-contained 115 pieces that can be replaced or supplemented in the future. 117 1.1. Threats 119 Several of the classical threats to network protocols are applicable 120 to the network management problem and therefore would be applicable 121 to any SNMP security model. Other threats are not applicable to 122 the network management problem. This section discusses principal 123 threats, secondary threats, and threats which are of lesser 124 importance. 126 The principal threats against which this SNMPv3 security model 127 should provide protection are: 129 - Modification of Information 130 The modification threat is the danger that some unauthorized entity 131 may alter in-transit SNMPv3 messages generated on behalf of an 132 authorized user in such a way as to effect unauthorized management 133 operations, including falsifying the value of an object. 135 - Masquerade 136 The masquerade threat is the danger that management operations not 137 authorized for some user may be attempted by assuming the identity 138 of another user that has the appropriate authorizations. 140 Blumenthal/Wijnen Expires December 1997 [Page 3] 141 Two secondary threats are also identified. The security protocols 142 defined in this memo provide limited protection against: 144 - Disclosure 145 The disclosure threat is the danger of eavesdropping on the 146 exchanges between managed agents and a management station. 147 Protecting against this threat may be required as a matter of 148 local policy. 150 - Message Stream Modification 151 The SNMPv3 protocol is typically based upon a connection-less 152 transport service which may operate over any sub-network service. 153 The re-ordering, delay or replay of messages can and does occur 154 through the natural operation of many such sub-network services. 155 The message stream modification threat is the danger that messages 156 may be maliciously re-ordered, delayed or replayed to an extent 157 which is greater than can occur through the natural operation of a 158 sub-network service, in order to effect unauthorized management 159 operations. 161 There are at least two threats that an SNMPv3 security protocol need 162 not protect against. The security protocols defined in this memo do 163 not provide protection against: 165 - Denial of Service 166 An SNMPv3 security protocol need not attempt to address the broad 167 range of attacks by which service on behalf of authorized users is 168 denied. Indeed, such denial-of-service attacks are in many cases 169 indistinguishable from the type of network failures with which any 170 viable network management protocol must cope as a matter of course. 171 - Traffic Analysis 172 In addition, an SNMPv3 security protocol need not attempt to 173 address traffic analysis attacks. Indeed, many traffic patterns 174 are predictable - agents may be managed on a regular basis by a 175 relatively small number of management stations - and therefore 176 there is no significant advantage afforded by protecting against 177 traffic analysis. 179 1.2. Goals and Constraints 181 Based on the foregoing account of threats in the SNMP network 182 management environment, the goals of this SNMPv3 security model are 183 as follows. 185 1) The protocol should provide for verification that each received 186 SNMPv3 message has not been modified during its transmission 187 through the network in such a way that an unauthorized management 188 operation might result. 190 2) The protocol should provide for verification of the identity of 192 Blumenthal/Wijnen Expires December 1997 [Page 4] 193 the user on whose behalf a received SNMPv3 message claims to have 194 been generated. 196 3) The protocol should provide for detection of received SNMPv3 197 messages, which request or contain management information, whose 198 time of generation was not recent. 200 4) The protocol should provide, when necessary, that the contents of 201 each received SNMPv3 message are protected from disclosure. 203 In addition to the principal goal of supporting secure network 204 management, the design of this SNMPv3 security model is also 205 influenced by the following constraints: 207 1) When the requirements of effective management in times of network 208 stress are inconsistent with those of security, the design should 209 prefer the former. 211 2) Neither the security protocol nor its underlying security 212 mechanisms should depend upon the ready availability of other 213 network services (e.g., Network Time Protocol (NTP) or key 214 management protocols). 216 3) A security mechanism should entail no changes to the basic SNMP 217 network management philosophy. 219 1.3. Security Services 221 The security services necessary to support the goals of an SNMPv3 222 security model are as follows. 224 - Data Integrity 225 is the provision of the property that data has not been altered or 226 destroyed in an unauthorized manner, nor have data sequences been 227 altered to an extent greater than can occur non-maliciously. 229 - Data Origin Authentication 230 is the provision of the property that the claimed identity of the 231 user on whose behalf received data was originated is corroborated. 233 - Data Confidentiality 234 is the provision of the property that information is not made 235 available or disclosed to unauthorized individuals, entities, or 236 processes. 238 For the protocols specified in this memo, it is not possible to 239 assure the specific originator of a received SNMPv3 message; rather, 240 it is the user on whose behalf the message was originated that is 241 authenticated. 243 For these protocols, it not possible to obtain data integrity without 245 Blumenthal/Wijnen Expires December 1997 [Page 5] 246 data origin authentication, nor is it possible to obtain data origin 247 authentication without data integrity. Further, there is no 248 provision for data confidentiality without both data integrity and 249 data origin authentication. 251 The security protocols used in this memo are considered acceptably 252 secure at the time of writing. However, the procedures allow for new 253 authentication and privacy methods to be specified at a future time 254 if the need arises. 256 1.4. Implementation Organization 258 The security protocols defined in this memo are implemented in three 259 different modules and each have their specific responsibilities such 260 that together they realize the goals and security services described 261 above: 263 - The timeliness module must provide for: 265 - Protection against message delay or replay (to an extent greater 266 than can occur through normal operation) 268 - The authentication module must provide for: 270 - Data Integrity, 272 - Data Origin Authentication 274 - The privacy module must provide for 276 - Protection against disclosure of the message payload. 278 The timeliness module is fixed for this User-based Security model 279 while there is provision for multiple authentication and/or privacy 280 modules, each of which implements a specific authentication or 281 privacy protocol respectively. 283 1.4.1. Timeliness Module 285 Section 3 (Elements of procedure) uses the time values in an SNMPv3 286 message to do timeliness checking. The timeliness check is only 287 performed if authentication is applied to the message. Since the 288 complete message is checked for integrity, we can assume that the 289 time values in a message that passes the authentication module are 290 trustworthy. 292 1.4.2. Authentication Protocol 294 Section 6 describes the Keyed-MD5 authentication protocol which is 295 the first authentication protocol to be used with the User-based 296 Security model. In the future additional or replacement 298 Blumenthal/Wijnen Expires December 1997 [Page 6] 299 authentication protocols may be defined as new needs arise. 301 This User-based Security model prescribes that the complete message 302 is checked for integrity in the authentication module. 304 For a message to be authenticated, it needs to pass authentication 305 check by the authentication module and the timeliness check which 306 is a fixed part of this User-based Security model. 308 1.4.3. Privacy Protocol 310 Section 7 describes the CBC-DES Symmetric Encryption Protocol which 311 the first privacy protocol to be used with the User-based Security 312 model. In the future additional or replacement privacy protocols 313 may be defined as new needs arise. 315 This User-based Security model prescribes that the scopedPDU 316 is protected from disclosure when a message is sent with privacy. 318 This User-based Security model also prescribes that a message needs 319 to be authenticated if privacy is in use. 321 1.5 Protection against Message Replay, Delay and Redirection 323 1.5.1 Authoritative SNMP Engine 325 In order to protect against message replay, delay and redirection, 326 one of the SNMP engines involved in each communication is designated 327 to be the authoritative engine. For messages with a GET, GETNEXT, 328 GETBULK, SET or INFORM request as the payload, the receiver of such 329 messages is authoritative. For messages with a SNMPv2-TRAP, 330 RESPONSE or REPORT as the payload, the sender is authoritative. 332 1.5.2 The following mechanisms are used: 334 - To protect against the threat of message delay or replay (to an 335 extent greater than can occur through normal operation), a set of 336 time (at the authoritative source) indicators and a request-id are 337 included in each message generated. An SNMPv3 engine evaluates 338 the time indicators to determine if a received message is recent. 339 An SNMPv3 engine may evaluate the time indicators to ensure that 340 a received message is at least as recent as the last message it 341 received from the same source. A non-authoritative SNMPv3 engine 342 uses received authentic messages to advance its notion of time at 343 the remote authoritative source. An SNMPv3 engine also evaluates 344 the request-id in received Response messages and discards messages 345 which do not correspond to outstanding requests. 347 These mechanisms provide for the detection of messages whose time 348 of generation was not recent in all but one circumstance; this 349 circumstance is the delay or replay of a Report message (sent to a 351 Blumenthal/Wijnen Expires December 1997 [Page 7] 352 receiver) when the receiver has has not recently communicated with 353 the source of the Report message. In this circumstance, the 354 detection guarantees only that the Report message is more recent 355 than the last communication between source and destination of the 356 Report message. However, Report messages do not request or contain 357 management information, and thus, goal #3 in Section 1.2 above is 358 met; further, Report messages can at most cause the receiver to 359 advance its notion of time (at the source) by less than the proper 360 amount. 362 This protection against the threat of message delay or replay does 363 not imply nor provide any protection against unauthorized deletion 364 or suppression of messages. Also, an SNMPv3 engine may not be able 365 to detect message reordering if all the messages involved are sent 366 within the Time Window interval. Other mechanisms defined 367 independently of the security protocol can also be used to detect 368 the re-ordering replay, deletion, or suppression of messages 369 containing set operations (e.g., the MIB variable snmpSetSerialNo 370 [RFC1907]). 372 - verifying that a message sent to/from one SNMPv3 engine cannot be 373 replayed to/as-if-from another SNMPv3 engine. 375 Included in each message is an identifier unique to the SNMPv3 376 engine associated with the sender or intended recipient of the 377 message. Also, each message containing a Response PDU contains a 378 request-id which associates the message to a recently generated 379 request. 381 A Report message sent by one SNMPv3 engine to a second SNMPv3 382 engine can potentially be replayed to another SNMPv3 engine. 383 However, Report messages do not request or contain management 384 information, and thus, goal #3 in Section 1.2 above is met; 385 further, Report messages can at most cause the receiver to advance 386 its notion of time (at the authoritative source) by less than the 387 correct amount. 389 - detecting messages which were not recently generated. 391 A set of time indicators are included in the message, indicating 392 the time of generation. Messages (other than those containing 393 Report PDUs) without recent time indicators are not considered 394 authentic. In addition, messages containing Response PDUs have a 395 request-id; if the request-id does not match that of a recently 396 generated request, then the message is not considered to be 397 authentic. 399 A Report message sent by an SNMPv3 engine can potentially be 400 replayed at a later time to an SNMPv3 engine which has not 401 recently communicated with that source engine. However, Report 402 messages do not request or contain management information, and 404 Blumenthal/Wijnen Expires December 1997 [Page 8] 405 thus, goal #3 in Section 1.2 above is met; further, Report 406 messages can at most cause the receiver to advance its notion of 407 time (at the authoritative source) by less than the correct 408 amount. 410 This memo allows the same user to be defined on multiple SNMPv3 411 engines. Each SNMPv3 engine maintains a value, snmpEngineID, 412 which uniquely identifies the engine. This value is included in 413 each message sent to/from the engine that is authoritative (see 414 section 1.5.1). On receipt of a message, an authoritative engine 415 checks the value to ensure it is the intended recipient, and a 416 non-authoritative engine uses the value to ensure that the message 417 is processed using the correct state information. 419 Each SNMPv3 engine maintains two values, engineBoots and engineTime, 420 which taken together provide an indication of time at that engine. 421 Both of these values are included in an authenticated message sent 422 to/received from that engine. On receipt, the values are checked to 423 ensure that the indicated time is within a time window of the 424 current time. The time window represents an administrative upper 425 bound on acceptable delivery delay for protocol messages. 427 For an SNMPv3 engine to generate a message which an authoritative 428 engine will accept as authentic, and to verify that a message 429 received from that authoritative engine is authentic, such an engine 430 must first achieve time synchronization with the authoritative 431 engine. 433 Blumenthal/Wijnen Expires December 1997 [Page 9] 434 2. Elements of the Model 436 This section contains definitions required to realize the security 437 model defined by this memo. 439 2.1. SNMPv3 Users 441 Management operations using this security model make use of a defined 442 set of user identities. For any SNMPv3 user on whose behalf 443 management operations are authorized at a particular SNMPv3 engine, 444 that engine must have knowledge of that user. An SNMPv3 engine that 445 wishes to communicate with another SNMPv3 engine must also have 446 knowledge of a user known to that engine, including knowledge of the 447 applicable attributes of that user. 449 A user and its attributes are defined as follows: 451 452 A string representing the name of the user. 454 455 A human-readable string representing a (security) model 456 independent identity for this user. 458 459 A string representing the group that the user belongs to. 461 462 An indication of whether messages sent on behalf of this user can 463 be authenticated, and if so, the type of authentication protocol 464 which is used. One such protocol is defined in this memo: the 465 Digest Authentication Protocol. 467 468 If messages sent on behalf of this user can be authenticated, the 469 (private) authentication key for use with the authentication 470 protocol. Note that a user's authentication key will normally be 471 different at different authoritative engines. Not visible via 472 remote access. 474 475 The only way to remotely update the authentication key. Does that 476 in a secure manner, so that the update can be completed without 477 the need to employ privacy protection. 479 480 An indication of whether messages sent on behalf of this user can 481 be protected from disclosure, and if so, the type of privacy 482 protocol which is used. One such protocol is defined in this memo: 483 the DES-based Encryption Protocol. 485 486 If messages sent on behalf of this user can be en/decrypted, the 487 (private) privacy key for use with the privacy protocol. Note that 488 a user's privacy key will normally be different at different 489 authoritative engines. Not visible via remote access. 491 492 The only way to remotely update the encryption key. Does that 493 in a secure manner, so that the update can be completed without 494 the need to employ privacy protection. 496 2.2. Replay Protection 498 Each SNMPv3 engine maintains three objects: 500 - snmpEngineID, which is an identifier unique among all SNMPv3 501 engines in (at least) an administrative domain; 503 - engineBoots, which is a count of the number of times the engine has 504 re-booted/re-initialized since snmpEngineID was last configured; 505 and, 507 - engineTime, which is the number of seconds since engineBoots was 508 last incremented. 510 Each SNMPv3 engine is always authoritative with respect to these 511 objects in its own engine. It is the responsibility of a non- 512 authoritative SNMPv3 engine to synchronize with the authoritative 513 engine, as appropriate. 515 An authoritative SNMPv3 engine is required to maintain the values of 516 its snmpEngineID and engineBoots in non-volatile storage. 518 2.2.1. snmpEngineID 520 The engineID value contained in an authenticated message is used to 521 defeat attacks in which messages from one engine to another engine 522 are replayed to a different engine. 524 When an authoritative engine is first installed, it sets its local 525 value of snmpEngineID according to a enterprise-specific algorithm 526 (see the definition of engineID in the SNMP Architecture document 527 [SNMP-ARCH]). 529 2.2.2. engineBoots and engineTime 531 The engineBoots and engineTime values contained in an authenticated 532 message are used to defeat attacks in which messages are replayed 533 when they are no longer valid. Through use of engineBoots and 534 engineTime, there is no requirement for an SNMPv3 engine to have a 535 non-volatile clock which ticks (i.e., increases with the passage of 536 time) even when the engine is powered off. Rather, each time an 537 SNMPv3 engine re-boots, it retrieves, increments, and then stores 538 engineBoots in non-volatile storage, and resets engineTime to zero. 540 When an SNMPv3 engine is first installed, it sets its local values 541 of engineBoots and engineTime to zero. If engineTime ever 542 reaches its maximum value (2147483647), then engineBoots is 543 incremented as if the engine has re-booted and engineTime is reset to 544 zero and starts incrementing again. 546 Each time an authoritative SNMPv3 engine re-boots, any SNMPv3 engines 547 holding that authoritative engine's values of engineBoots and 548 engineTime need to re-synchronize prior to sending correctly 549 authenticated messages to that authoritative engine (see Section 550 2.3 for (re-)synchronization procedures). Note, however, that the 551 procedures do provide for a notification to be accepted as authentic 552 by a receiving engine, when sent by an authoritative engine which has 553 re-booted since the receiving engine last (re-)synchronized. 555 If an authoritative SNMPv3 engine is ever unable to determine its 556 latest engineBoots value, then it must set its engineBoots value to 557 0xffffffff. 559 Whenever the local value of engineBoots has the value 0xffffffff, it 560 latches at that value and an authenticated message always causes an 561 notInTimeWindow authentication failure. 563 In order to reset an engine whose engineBoots value has reached the 564 value 0xffffffff, manual intervention is required. The engine must 565 be physically visited and re-configured, either with a new 566 snmpEngineID value, or with new secret values for the authentication 567 and privacy protocols of all users known to that engine. 569 2.2.3. Time Window 571 The Time Window is a value that specifies the window of time in which 572 a message generated on behalf of any user is valid. This memo 573 specifies that the same value of the Time Window, 150 seconds, is 574 used for all users. 576 2.3. Time Synchronization 578 Time synchronization, required by a non-authoritative engine (see 579 section 5.1.1) in order to proceed with authentic communications, 580 has occurred when the non-authoritative engine has obtained local 581 values of engineBoots and engineTime from the authoritative engine 582 that are within the authoritative engine's time window. To remain 583 synchronized, the local values must remain within the authoritative 584 engine's time window and thus must be kept loosely synchronized 585 with the values stored at the authoritative engine. 587 In addition to keeping a local version of engineBoots and engineTime, 588 a non-authoritative engine must also keep one other local variable, 589 latestReceivedEngineTime. This value records the highest value of 590 engineTime that was received by the non-authoritative engine from 591 the authoritative engine and is used to eliminate the possibility 592 of replaying messages that would prevent the non-authoritative 593 engine's notion of the engineTime from advancing. 595 Time synchronization occurs as part of the procedures of receiving 596 a message (Section 3.2, step 7b). As such, no explicit time 597 synchronization procedure is required by a non-authoritative engine. 598 Note, that whenever the local value of snmpEngineID is changed 599 (e.g., through discovery) or when secure communications are first 600 established with this engine, the local values of engineBoots and 601 latestReceivedEngineTime should be set to zero. This will cause 602 the time synchronization to occur when the next authentic message 603 is received. 605 2.4. SNMPv3 Messages Using this Model 607 The syntax of an SNMPv3 message using this security model adheres 608 to the message format defined in the SNMP Architecture document 609 [SNMP-ARCH]. The securityParameters in the message are 610 defined as an OCTET STRING. The format of that OCTET STRING for 611 the User-based Security model is as follows: 613 securityParameters ::= 614 SEQUENCE { 615 -- global parameters 616 engineID 617 OCTET STRING (SIZE(12)), 618 engineBoots 619 Unsigned32 (0..4294967295), 620 engineTime 621 Unsigned32 (0..2147483647), 622 userName 623 OCTET STRING (SIZE(1..16)), 624 authParameters 625 OCTET STRING, 626 privParameters 627 OCTET STRING, 628 } 629 END 631 The authParameters are defined by the authentication protocol in 632 use for the message (as defined by the authProtocol column in 633 the user's entry in the usecUserTable). 635 The privParameters are defined by the privacy protocol in 636 use for the message (as defined by the privProtocol column in 637 the user's entry in the usecUserTable). 639 2.5 Input and Output of the User-based Security Module 641 This section describes the inputs and outputs that the User-based 642 Security module expects and produces when the Message Processing 643 and Control module (MPC) invokes the User-base Security module for 644 services. 646 2.5.1 Input and Output when generating an SNMPv3 Message 648 When the Message Processing and Control module (MPC) invokes the 649 User-based Security module to secure an outgoing SNMPv3 message, 650 there are two possibilities: 652 a) A new request is generated. The abstract service interface is: 654 generateRequestMsg(version, msgID, mms, msgFlags, 655 securityModel, securityParameters, 656 LoS, miId, engineID, scopedPDU) 658 b) A response is generated. The abtract service interface is: 660 generateResponseMsg(version, msgID, mms, msgFlags, 661 securityModel, securityParameters, 662 scopedPDU, cachedSecurityDataReference) 664 Where: 666 version 667 This is the version number for the SNMP message. 668 This data is not used by the USEC module. 669 It is part of the globalData of the message. 670 msgID 671 This is the msgID to be generated. 672 This data is not used by the USEC module. 673 It is part of the globalData of the message. 674 mms 675 This is the maximum message size. 676 This data is not used by the USEC module. 677 It is part of the globalData of the message. 678 msgFlags 679 This is the field containing the msgFlags. 680 This data is not used by the USEC module. 681 It is part of the globalData of the message. 682 It should be consistent with the LoS that is passed. 683 securityModel 684 This is the securityModel in use. Should be the USEC model. 685 This data is not used by the USEC module. 686 It is part of the globalData of the message. 687 securityParameters 688 These are the security parameters. They will be filled in 689 by the User-based Security module. 690 LoS 691 The Level of Security (LoS) from which the User-based Security 692 module determines if the message needs to be protected from 693 disclosure and if the message needs to be authenticated. 694 scopedPDU 695 this is the message payload. The data is opaque as far as the 696 User-based Security module is concerned. 697 miId 698 this is the (security) model independent Identifier. 699 Together with the engineID it identifies a row in the 700 usecUserTable that is to be used for securing the message. 701 engineID 702 the engineID of the authoritative SNMP engine to which the 703 request is to be sent. 704 cachedSecurityDataReference 705 A handle/reference to cached security data to be used when 706 securing an outgoing response. This is the handle/reference 707 that was generated by the USEC module when the incoming 708 request was processed. 710 Upon completion of the process, the User-based Security module 711 returns either and error indication or the completed message 712 with privacy and authentication applied if such was requested 713 by the Level of Security (LoS) flags passed. 715 The abstract service interface is: 717 returnGeneratedMsg(wholeMsg, wholeMsgLen, statusCode) 719 Where: 720 wholeMsg 721 this is fully encoded and secured message ready to be sent on 722 the wire. 723 wholeMsgLen 724 this is the length of the encoded and secured message wholeMsg. 725 statusCode 726 this is the indicator of whether the encoding and securing of 727 the message was successful, and if not it is an indication of 728 the problem. 730 2.5.2 Input and Output when receiving an SNMPv3 Message 732 The Message Processing and Control module (MPC) invokes the 733 User-based Security module to verify proper security of an incoming 734 SNMPv3 message. The abstract service interface is: 736 processMsg(version, msgID, mms, msgFlags, 737 securityModel, securityParameters, 738 LoS, wholeMsg, wholeMsgLen) 740 Where: 742 version 743 This is the version number for the SNMP message. 744 This data is not used by the USEC module. 745 It is part of the globalData of the message. 746 msgID 747 This is the msgID to be generated. 748 This data is not used by the USEC module. 749 It is part of the globalData of the message. 750 mms 751 This is the maximum message size. 752 This data is not used by the USEC module. 753 It is part of the globalData of the message. 754 msgFlags 755 This is the field containing the msgFlags. 756 This data is not used by the USEC module. 757 It is part of the globalData of the message. 758 It should be consistent with the LoS that is passed. 759 securityModel 760 This is the securityModel in use. Should be the USEC model. 761 This data is not used by the USEC module. 762 It is part of the globalData of the message. 763 securityParameters 764 These are the security parameters. They will be filled in 765 by the User-based Security module. 766 LoS 767 The Level of Security (LoS) from which the User-based Security 768 module determines if the message needs to be protected from 769 disclosure and if the message needs to be authenticated. 770 wholeMsg 771 this is the complete message as it was received by the Message 772 Processing and Control module (MPC). 773 wholeMsgLen 774 this is the length of the wholeMsg as received on the wire. 776 Upon completion of the process, the User-based Security module 777 returns a statusCode and in case of success authenticated and 778 decrypted data. The abstract service interface is: 780 returnMsg(miId, groupName, cachedSecurityDataReference, 781 scopedPDUmms, scopedPDU, statusCode) 783 Where: 785 miId 786 this is an Security Model-independent Identifier that identifies 787 an entry in the usecUserTable. It is to be used later when a 788 response message must be secured. 789 groupName 790 this is the group to which the user belongs. The User-based 791 Security module retrieves this information from the usecUserTable. 792 cachedSecurityDataReference 793 cached security data to be used when securing a possible outgoing 794 response to this request. Will have to be released explicitly 795 by the MPC or the application. 796 scopedPDUmms 797 this is the maximum message size that a possible response PDU 798 may use. The User-based Security module calculates this size such 799 that there is always space available for any security parameters 800 that need to be added to the response message. 801 scopedPDU 802 this is the message payload. The data is opaque as far as the 803 User-based Security module is concerned. But if the data was 804 encrypted because privacy protection was in effect, then upon 805 return from the User-based Security module the data will have 806 been decrypted. 807 statusCode 808 this is an indicator of whether the message was parsed, 809 authenticated and possibly decrypted successfully. If 810 it was not - it indicates what the problem was. 812 3. Elements of Procedure 814 This section describes the security related procedures followed by 815 an SNMPv3 engine when processing SNMPv3 messages according to the 816 User-based Security model. 818 3.1. Processing an Outgoing Message 820 This section describes the procedure followed by an SNMPv3 engine 821 whenever it generates a message containing a management operation 822 (either a request, a response, a notification, or a report) on 823 behalf of a user, with a particular Level of Security (LoS). 825 1) - If any cachedSecurityDataReference is passed, then 826 information concerning the user is extracted from the 827 cachedSecurityData. The cachedSecurityData can now be 828 discarded. 829 - Otherwise, based on the miId, information concerning the user 830 at the destination engineID is extracted from the Local 831 (security) Configuration Datastore (LCD, usecUserTable). 832 If information about the user is absent from the LCD, 833 then an error indication (unknownSecurityIdentity) is 834 returned to the calling module. 836 2) If the Level of Security (LoS) specifies that the message is to 837 be protected from disclosure, but the user does not support both 838 an authentication and a privacy protocol then the message cannot 839 be sent. An error indication (unsupportedLoS) is returned to 840 the calling module. 842 3) If the Level of Security (LoS) specifies that the message is to 843 be authenticated, but the user does not support an authentication 844 protocol, then the message cannot be sent. An error indication 845 (unsupportedLoS) is returned to the calling module. 847 4) If the Level of Security (LoS) specifies that the message is to 848 be protected from disclosure, then the octet sequence 849 representing the serialized scopedPDU is encrypted according to 850 the user's privacy protocol. To do so a call is made to the 851 privacy module that implements the user's privacy protocol. 852 The abstract service interface is: 854 encryptMsg(cryptKey, scopedPDU) 856 Where: 858 cryptKey 859 The user's usecUserPrivKey. This is the secret key 860 that can be used by the encryption algorithm. 861 scopedPDU 862 The data to be encrypted. 864 Upon completion the privacy module returns: 866 returnEncryptedMsg(encryptedPDU, privParameters, statusCode) 868 encryptedPDU 869 The encrypted scopedPDU (encoded as an octet string). 870 privParameters 871 The privacy parameters (encoded as an octet string) that 872 need to be sent in the outgoing message. 873 statusCode 874 The indicator of whether the PDU was encrypted successfully 875 and if not, it indicates what went wrong. 877 If an error indication is returned by the privacy module then 878 the message cannot be sent and the error indication is returned 879 to the calling module. 881 If the privacy module returns success, then the privParameters 882 field is put into the securityParameters and the encryptedPDU 883 serves as the payload of the message being prepared. 885 5) If the Level of Security (LoS) specifies that the message is not 886 to be protected from disclosure, then the NULL string is encoded 887 as an octet string into the privParameters field of the 888 securityParameters and the scopedPDU serves as the payload of 889 the message being prepared. 891 6) The engineID is encoded as an octet string into the 892 field of the securityParameters. 894 7) If the Level of Security (LoS) specifies that the message is to 895 be authenticated, then the current values of engineBoots, and 896 engineTime corresponding to engineID from the LCD are used. 897 Otherwise, a zero value is used for engineBoots and engineTime. 898 The values are encoded as Unsigned32 into the engineBoots and 899 engineTime fields of the securityParameters. 901 8) The userName is encoded as an octet string into the userName 902 field of the securityParameters. 904 9) If the Level of Security (LoS) specifies that the message is to 905 be authenticated, the message is authenticated according to the 906 user's authentication protocol. To do so, a call is made to the 907 authentication module that implements the user's authentication 908 protocol. The abstract service interface is: 910 authMsg(authKey, wholeMsg) 912 authKey 913 The user's usecUserAuthKey. This is the secret key 914 that can be used by the authentication algorithm. 915 wholeMsg 916 the message to be authenticated. 918 Upon completion the authentication module returns: 920 returnAuthMsg(wholeMsg, statusCode) 922 wholeMsg 923 Same as in input, but with authParameters properly filled. 924 statusCode 925 The indicator of whether the message was successfully 926 processed by the authentication module. 928 If an error indication is returned by the authentication module, 929 then the message cannot be sent and the error indication is 930 returned to the calling module. 932 10) If the Level of Security (LoS) specifies that the message is not 933 to be authenticated then the NULL string is encoded as an octet 934 string into the authParameters field of the securityParameters. 936 11) The completed message is returned to the calling module with 937 the statusCode set to success. 939 3.2. Processing an Incoming Message 941 This section describes the procedure followed by an SNMPv3 engine 942 whenever it receives a message containing a management operation 943 on behalf of a user, with a particular Level of Security (LoS). 945 1) If the received securityParameters is not the serialization 946 (according to the conventions of [RFC1906]) of an OCTET STRING 947 formated according to the securityParameters defined in section 948 2.4, then the snmpInASNParseErrs counter [RFC1907] is 949 incremented, and an error indication (ASNParseError) is returned 950 to the calling module. 952 2) The values of the security parameter fields are extracted from 953 the securityParameters. 955 3) If the engineID field contained in the securityParameters is 956 unknown then: 958 - a manager that performs discovery may optionally create a 959 new entry in its Local (security) Configuration Database (LCD) 960 and continue processing; or 962 - an error indication (unknownEngineID) is returned to the 963 calling module. 965 4) Information about the value of the userName and engineID 966 fields is extracted from the Local (security) Configuration 967 Database (LCD, usecUserTable). If no information is 968 available for this user, then an error indication 969 (unknownSecurityIdentity) is returned to the calling module. 971 5) If the information about the user indicates that it does not 972 support the Level of Security indicated by the LoS parameter, 973 then and an error indication (unsupportedLoS) is returned to 974 the calling module. 976 6) If the Level of Security (LoS) specifies that the message is to 977 be authenticated, then the message is authenticated according to 978 the user's authentication protocol. To do so, a call is made to 979 the authentication module that implements the user's 980 authentication protocol. The abstract service interface is: 982 authIncomingMsg(authKey, authParameters, wholeMsg) 984 authKey 985 The user's (secret) usecUserAuthKey 986 authParameters 987 the authParameters from the incoming message. 988 wholeMsg 989 the message to be authenticated. 991 The authentication module returns: 993 returnAuthIncomingMsg(wholeMsg, statusCode) 995 If the message is not authentic according to the authentication 996 protocol module (i.e. it returns an error indication), then the 997 error indication is returned to the calling module. 999 Otherwise, the authenticated wholeMsg is used for further 1000 processing. 1002 7) If the LoS field indicates an authenticated message, then 1003 the local values of engineBoots and engineTime corresponding to 1004 the value of the engineID field are extracted from the 1005 Local (security) Configuration Database (LCD). 1007 a) If the engineID value is the same as the snmpEngineID of 1008 the processing SNMPv3 engine (meaning that this is the 1009 authoritative engine), then if any of the following 1010 conditions is true, then the message is considered to be 1011 outside of the Time Window: 1013 - the local value of engineBoots is 0xffffffff; 1015 - the engineBoots field differs from the local value of 1016 engineBoots; or, 1018 - the value of the engineTime field differs from the local 1019 notion of engineTime by more than +/- 150 seconds. 1021 If the message is considered to be outside of the Time Window 1022 then an error indication (notInTimeWindow) is returned to 1023 the calling module. 1025 b) If the engineID value is not the same as the snmpEngineID of 1026 the processing SNMPv3 engine (meaning that this engine is not 1027 the authoritative engine), then: 1029 - if at least one of the following conditions is true: 1031 - the engineBoots field is greater than the local value 1032 of engineBoots; or, 1034 - the engineBoots field is equal to the local value of 1035 engineBoots and the engineTime field is greater than 1036 the value of latestReceivedEngineTime, 1038 then the LCD entry corresponding to the value of the 1039 engineID field is updated, by setting the local value of 1040 engineBoots from the engineBoots field, the local value 1041 latestReceivedEngineTime from the engineTime field, and 1042 the local value of engineTime from the engineTime field. 1044 - if any of the following conditions is true, then the message 1045 is considered to be outside of the Time Window: 1047 - the local value of engineBoots is 0xffffffff; 1049 - the engineBoots field is less than the local value of 1050 engineBoots; or, 1052 - the engineBoots field is equal to the local value of 1053 engineBoots and the engineTime field is more than 150 1054 seconds less than the local notion of engineTime. 1056 If the message is considered to be outside of the Time 1057 Window then an error indication (notInTimeWindow) is 1058 returned to the calling module; 1059 however, time synchronization procedures may be invoked. 1060 Note that this procedure allows for engineBoots in the 1061 message to be greater than the local value of engineBoots 1062 to allow for received messages to be accepted as authentic 1063 when received from an authoritative SNMPv3 engine that 1064 has re-booted since the receiving SNMPv3 engine last 1065 (re-)synchronized. 1067 8) If the LoS field indicates that the message was protected from 1068 disclosure, then the octet sequence representing the scopedPDU 1069 is decrypted according to the user's privacy protocol to obtain 1070 a serialized scopedPDUs value. Otherwise the data component is 1071 assumed to directly contain the scopedPDUs value. To do the 1072 decryption, a call is made to the privacy module that implements 1073 the user's privacy protocol. The abstract service interface is: 1075 decryptMsg(cryptKey, privParameters, encryptedPDU) 1077 cryptKey 1078 The user's secret usecUserPrivKey 1079 privParameters 1080 The privParameters field from the securityParameters from 1081 the incoming message. 1082 encryptedPDU 1083 the data to be decrypted 1085 The privacy module returns: 1087 returnDecryptedMsg(scopedPDU, statusCode) 1089 scopedPDU 1090 The decrypted scopedPDU. 1091 statusCode 1092 The indicator whether the message was successfully decrypted. 1094 If an error indication is returned by the privacy module, then 1095 the error indication is returned to the calling module. 1097 9) The scopedPDU-MMS is calculated. 1099 10) The groupName is retrieved from the usecUserTable 1101 11) The miId is retrieved from the usecUserTable 1103 12) The securityData is cached, so that a possible response to 1104 this message can use the same authentication and privacy 1105 secrets. Information to be saved/cached is as follows: 1107 usecUserName, 1108 usecUserAuthProto, usecUserAuthKey, 1109 usecUserPrivProto, usecUserPrivKey 1111 -- Editor's note: 1112 If we assume SNMPv3, then we could check the reportableFlag and if 1113 it is not set, then we do not need to cache any security data 1114 because then there is no response possible. Do we want to do that? 1115 -- End Editor's note. 1117 13) The statusCode is set to success and a return is made to the 1118 calling module according to this abstract service interface: 1120 returnMsg(miId, groupName, cachedSecurityDataReference, 1121 scopedPDUmms, scopedPDU, statusCode) 1123 4. Discovery 1125 This security model requires that a discovery process obtains 1126 sufficient information about other SNMP engines in order to 1127 communicate with them. Discovery requires the SNMP manager to 1128 learn the engine's snmpEngineID value before communication may 1129 proceed. This may be accomplished by formulating a get-request 1130 communication with the LoS set to noAuth/noPriv, the userName set 1131 to "public", the snmpEngineID set to all zeros (binary), and the 1132 varBindList left empty. The response to this message will be a 1133 report PDU that contains the snmpEngineID within the 1134 securityParameters field (and containing the snmpUnknownEngineIDs 1135 counter in the varBindList). 1136 If authenticated communication is required then the discovery 1137 process may invoke the procedure described in Section 2.3 to 1138 synchronize the timers. 1140 5. Definitions 1142 SNMP-USEC-MIB DEFINITIONS ::= BEGIN 1144 IMPORTS 1145 MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI 1146 TEXTUAL-CONVENTION, TestAndIncr, 1147 RowStatus, StorageType FROM SNMPv2-TC 1148 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF, 1149 SnmpAdminString, SnmpLoS, SnmpEngineID, 1150 SnmpSecurityModel, 1151 imfAuthMD5Protocol, imfNoPrivProtocol FROM IMF-MIB; 1153 snmpUsecMIB MODULE-IDENTITY 1154 LAST-UPDATED "9706180000Z" -- 18 June 1997, midnight 1155 ORGANIZATION "SNMPv3 Working Group" 1156 CONTACT-INFO "WG-email: snmpv3@tis.com 1157 Subscribe: majordomo@tis.com 1158 In msg body: subscribe snmpv3 1160 Chair: Russ Mundy 1161 Trusted Information Systems 1162 postal: 3060 Washington Rd 1163 Glenwood MD 21738 1164 email: mundy@tis.com 1165 phone: 301-854-6889 1167 Co-editor Uri Blumenthal 1168 IBM T. J. Watson Research 1169 postal: 30 Saw Mill River Pkwy, 1170 Hawthorne, NY 10532 1171 USA 1172 email: uri@watson.ibm.com 1173 phone: +1.914.784.7964 1175 Co-editor: Bert Wijnen 1176 IBM T. J. Watson Research 1177 postal: Schagen 33 1178 3461 GL Linschoten 1179 Netherlands 1180 email: wijnen@vnet.ibm.com 1181 phone: +31-348-432-794 1182 " 1184 DESCRIPTION "The management information definitions for the 1185 SNMPv3 User-based Security model. 1186 " 1187 ::= { snmpModules 99 } -- to be assigned 1189 -- Administrative assignments **************************************** 1190 snmpUsecAdmin OBJECT IDENTIFIER ::= { snmpUsecMIB 1 } 1191 snmpUsecMIBObjects OBJECT IDENTIFIER ::= { snmpUsecMIB 2 } 1192 snmpUsecMIBConformance OBJECT IDENTIFIER ::= { snmpUsecMIB 3 } 1194 -- Textual Conventions *********************************************** 1196 UserName ::= TEXTUAL-CONVENTION 1197 STATUS current 1198 DESCRIPTION "A string representing the name of a user for use in 1199 accordance with the SNMP User-based Security model. 1200 " 1201 SYNTAX SnmpAdminString (SIZE(1..16)) 1203 -- Editor's note: 1204 -- A real issue is whether the fact that MD5 is used in the following 1205 -- TC is OK. It might be better to use 3DES for 3DES and IDEA for IDEA. 1206 -- End Editor's note 1208 KeyChange ::= TEXTUAL-CONVENTION 1209 STATUS current 1210 DESCRIPTION 1211 "Every definition of an object with this syntax must identify 1212 a protocol, P, and a secret key, K. The object's value is a 1213 manager-generated, partially-random value which, when 1214 modified, causes the value of the secret key, K, to be 1215 modified via a one-way function. 1217 The value of an instance of this object is the concatenation 1218 of two components: a 'random' component and a 'delta' 1219 component. The lengths of the random and delta components are 1220 given by the corresponding value of the protocol, P; if P 1221 requires K to be a fixed length, the length of both the random 1222 and delta components is that fixed length; if P allows the 1223 length of K to be variable up to a particular maximum length, 1224 the length of the random component is that maximum length and 1225 the length of the delta component is any length less than or 1226 equal to that maximum length. For example, 1227 imfAuthMD5Protocol requires K to be a fixed length of 16 1228 octets. Other protocols may define other sizes, as deemed 1229 appropriate. 1231 When an instance of this object is modified to have a new 1232 value by the management protocol, the agent generates a new 1233 value of K as follows: 1235 - a temporary variable is initialized to the existing value 1236 of K; 1237 - if the length of the delta component is greater than 16 1238 bytes, then: 1239 - the random component is appended to the value of the 1240 temporary variable, and the result is input to the MD5 1241 hash algorithm to produce a digest value, and the 1242 temporary variable is set to this digest value; 1243 - the value of the temporary variable is XOR-ed with the 1244 first (next) 16-bytes of the delta component to produce 1245 the first (next) 16-bytes of the new value of K. 1246 - the above two steps are repeated until the unused 1247 portion of the delta component is 16 bytes or less, 1248 - the random component is appended to the value of the 1249 temporary variable, and the result is input to the MD5 1250 hash algorithm to produce a digest value; 1251 - this digest value, truncated if necessary to be the same 1252 length as the unused portion of the delta component, is 1253 XOR-ed with the unused portion of the delta component to 1254 produce the (final portion of the) new value of K. 1256 i.e., 1258 iterations = (lenOfDelta - 1)/16; /* integer division */ 1259 temp = keyOld; 1260 for (i = 0; i < iterations; i++) { 1261 temp = MD5 (temp || random); 1262 keyNew[i*16 .. (i*16)+15] = 1263 temp XOR delta[i*16 .. (i*16)+15]; 1264 } 1265 temp = MD5 (temp || random); 1266 keyNew[i*16 .. lenOfDelta-1] = 1267 temp XOR delta[i*16 .. lenOfDelta-1]; 1269 The value of an object with this syntax, whenever it is 1270 retrieved by the management protocol, is always the zero- 1271 length string." 1272 SYNTAX OCTET STRING 1274 -- ******************************************************************* 1276 -- The valid users for the User-based Security model ****************** 1278 usecUser OBJECT IDENTIFIER ::= { snmpUsecMIBObjects 1 } 1280 usecUserTable OBJECT-TYPE 1281 SYNTAX SEQUENCE OF UsecUserEntry 1282 MAX-ACCESS not-accessible 1283 STATUS current 1284 DESCRIPTION "The table of users configured in the SNMP engine's 1285 Local (security) Configuration Datastore (LCD)." 1286 ::= { usecUser 1 } 1288 usecUserEntry OBJECT-TYPE 1289 SYNTAX UsecUserEntry 1290 MAX-ACCESS not-accessible 1291 STATUS current 1292 DESCRIPTION "A user configured in the SNMP engine's Local 1293 (security) Configuration Datastore (LCD) for 1294 the User-based Security model. 1295 " 1296 INDEX { usecUserEngineID, 1297 IMPLIED usecUserName 1298 } 1299 ::= { usecUserTable 1 } 1301 UsecUserEntry ::= SEQUENCE { 1302 usecUserEngineID SnmpEngineID, 1303 usecUserName UserName, 1304 usecUserMiId SnmpAdminString, 1305 usecUserGroupName SnmpAdminString, 1306 usecUserCloneFrom RowPointer, 1307 usecUserAuthProtocol OBJECT IDENTIFIER, 1308 usecUserAuthKeyChange KeyChange, 1309 -- usecUserAuthKey OCTET STRING, not visible 1310 usecUserAuthPublic OCTET STRING, 1311 usecUserPrivProtocol OBJECT IDENTIFIER, 1312 usecUserPrivKeyChange KeyChange, 1313 -- usecUserPrivKey OCTET STRING, not visible 1314 usecUserPrivPublic OCTET STRING, 1315 usecUserStorageType StorageType, 1316 usecUserStatus RowStatus 1317 } 1319 usecUserEngineID OBJECT-TYPE 1320 SYNTAX SnmpEngineID 1321 MAX-ACCESS not-accessible 1322 STATUS current 1323 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1325 In a simple agent, this value is always that agent's 1326 own snmpEngineID value. 1328 This value can also take the value of the snmpEngineID 1329 of a remote SNMP engine with which this user can 1330 communicate. 1331 " 1332 ::= { usecUserEntry 1 } 1334 usecUserName OBJECT-TYPE 1335 SYNTAX UserName 1336 MAX-ACCESS not-accessible 1337 STATUS current 1338 DESCRIPTION "A string representing the name of the user. This is 1339 the (User-based security) model dependent identity. 1340 " 1341 ::= { usecUserEntry 2 } 1343 usecUserMiId OBJECT-TYPE 1344 SYNTAX SnmpAdminString 1345 MAX-ACCESS read-only 1346 STATUS current 1347 DESCRIPTION "A string representing the (security) model independent 1348 identity for this user. 1350 The default mapping for the User-based Security model 1351 is that the miId is the same as the userName. 1352 " 1353 ::= { usecUserEntry 3 } 1355 usecUserGroupName OBJECT-TYPE 1356 SYNTAX SnmpAdminString 1357 MAX-ACCESS read-write 1358 STATUS current 1359 DESCRIPTION "A string representing the group to which the user 1360 belongs. A group name of zero length indicates 1361 that the user is not [perhaps yet] a member of any 1362 group, possibly because the entry has not yet been 1363 completely configured. Users which are not a part 1364 of any group are effectively disabled to perform any 1365 SNMP operations. 1366 " 1367 DEFVAL { ''H } -- the empty string 1368 ::= { usecUserEntry 4 } 1370 usecUserCloneFrom OBJECT-TYPE 1371 SYNTAX RowPointer 1372 MAX-ACCESS read-create 1373 STATUS current 1374 DESCRIPTION "A pointer to another conceptual row in this 1375 usecUserTable. The user in this other conceptual row 1376 is called the clone-from user. 1378 When a new user is created (i.e., a new conceptual row 1379 is instantiated in this table), the authentication 1380 parameters of the new user are cloned from its 1381 clone-from user. 1383 The first time an instance of this object is set by a 1384 management operation (either at or after its 1385 instantiation), the cloning process is invoked. 1386 Subsequent writes are successful but invoke no action 1387 to be taken by the agent. 1388 The cloning process fails with an 'inconsistentName' 1389 error if the conceptual row representing the 1390 clone-from user is not in an active state when the 1391 cloning process is invoked. 1393 Cloning also causes the initial values of the secret 1394 authentication key and the secret encryption key of 1395 the new user to be set to the same value as the 1396 corresponding secret of the clone-from user. 1398 When this object is read, the zero length string is 1399 returned. 1400 " 1401 ::= { usecUserEntry 5 } 1403 usecUserAuthProtocol OBJECT-TYPE 1404 SYNTAX OBJECT IDENTIFIER 1405 MAX-ACCESS read-create 1406 STATUS current 1407 DESCRIPTION "An indication of whether messages sent on behalf of 1408 this user to/from the SNMP engine identified by 1409 usecUserEngineID, can be authenticated, and if so, 1410 the type of authentication protocol which is used. 1412 An instance of this object is created concurrently 1413 with the creation of any other object instance for 1414 the same user (i.e., as part of the processing of 1415 the set operation which creates the first object 1416 instance in the same conceptual row). Once created, 1417 the value of an instance of this object can not be 1418 changed. 1419 " 1420 DEFVAL { imfAuthMD5Protocol } 1421 ::= { usecUserEntry 6 } 1423 usecUserAuthKeyChange OBJECT-TYPE 1424 SYNTAX KeyChange -- typically (SIZE (0..32)) 1425 MAX-ACCESS read-create 1426 STATUS current 1427 DESCRIPTION "An object, which when modified, causes the secret 1428 authentication key used for messages sent on behalf 1429 of this user to/from the SNMP engine identified by 1430 usecUserEngineID, to be modified via a one-way 1431 function. 1433 The associated protocol is the usecUserAuthProtocol. 1434 The associated secret key is the user's secret 1435 authentication key (usecUserAuthKey). 1437 When creating a new user, it is an 'inconsistentName' 1438 error for a set operation to refer to this object 1439 unless it is previously or concurrently initialized 1440 through a set operation on the corresponding value 1441 of usecUserCloneFrom. 1442 " 1443 DEFVAL { ''H } -- the empty string 1444 ::= { usecUserEntry 7 } 1446 usecUserAuthPublic OBJECT-TYPE 1447 SYNTAX OCTET STRING -- for MD5 (SIZE(0..32)) 1448 MAX-ACCESS read-create 1449 STATUS current 1450 DESCRIPTION "A publicly-readable value which is written as part 1451 of the procedure for changing a user's secret key, 1452 and later read to determine whether the change of 1453 the secrets was effected. 1454 " 1455 DEFVAL { ''H } -- the empty string 1456 ::= { usecUserEntry 8 } 1458 usecUserPrivProtocol OBJECT-TYPE 1459 SYNTAX OBJECT IDENTIFIER 1460 MAX-ACCESS read-create 1461 STATUS current 1462 DESCRIPTION "An indication of whether messages sent on behalf of 1463 this user to/from the SNMP engine identified by 1464 usecUserEngineID, can be protected from disclosure, 1465 and if so, the type of privacy protocol which is used. 1467 An instance of this object is created concurrently 1468 with the creation of any other object instance for 1469 the same user (i.e., as part of the processing of 1470 the set operation which creates the first object 1471 instance in the same conceptual row). Once created, 1472 the value of an instance of this object can not be 1473 changed. 1474 " 1475 DEFVAL { imfNoPrivProtocol } 1476 ::= { usecUserEntry 9 } 1478 usecUserPrivKeyChange OBJECT-TYPE 1479 SYNTAX KeyChange -- typically (SIZE (0..32)) 1480 MAX-ACCESS read-create 1481 STATUS current 1482 DESCRIPTION "An object, which when modified, causes the secret 1483 encryption key used for messages sent on behalf 1484 of this user to/from the SNMP engine identified by 1485 usecUserEngineID, to be modified via a one-way 1486 function. 1488 The associated protocol is the usecUserPrivProtocol. 1489 The associated secret key is the user's secret 1490 encryption key (usecUserPrivKey). 1492 When creating a new user, it is an 'inconsistentName' 1493 error for a set operation to refer to this object 1494 unless it is previously or concurrently initialized 1495 through a set operation on the corresponding value 1496 of usecUserCloneFrom. 1497 " 1498 DEFVAL { ''H } -- the empty string 1499 ::= { usecUserEntry 10 } 1501 usecUserPrivPublic OBJECT-TYPE 1502 SYNTAX OCTET STRING -- for DES (SIZE(0..16)) 1503 MAX-ACCESS read-create 1504 STATUS current 1505 DESCRIPTION "A publicly-readable value which is written as part 1506 of the procedure for changing a user's secret key, 1507 and later read to determine whether the change of 1508 the secrets was effected. 1509 " 1510 DEFVAL { ''H } -- the empty string 1511 ::= { usecUserEntry 11 } 1513 usecUserStorageType OBJECT-TYPE 1514 SYNTAX StorageType 1515 MAX-ACCESS read-create 1516 STATUS current 1517 DESCRIPTION "The storage type for this conceptual row." 1518 DEFVAL { nonVolatile } 1519 ::= { usecUserEntry 12 } 1521 usecUserStatus OBJECT-TYPE 1522 SYNTAX RowStatus 1523 MAX-ACCESS read-create 1524 STATUS current 1525 DESCRIPTION "The status of this conceptual row. Until instances 1526 of all corresponding columns are appropriately 1527 configured, the value of the corresponding instance 1528 of the usecUserStatus column is 'notReady'. 1530 For those columnar objects which permit write-access, 1531 their value in an existing conceptual row can be 1532 changed irrespective of the value of usecUserStatus 1533 for that row. 1534 " 1535 ::= { usecUserEntry 13 } 1537 usecUserSecretSpinLock OBJECT-TYPE 1538 SYNTAX TestAndIncr 1539 MAX-ACCESS read-write 1540 STATUS current 1541 DESCRIPTION "An advisory lock used to allow several cooperating 1542 SNMPv3 engines, all acting in a manager role, to 1543 coordinate their use of facilities to alter secrets 1544 in the usecUserTable. 1546 " 1547 ::= { usecUser 2 } 1549 --Editor's note 1550 Is it enough to have just one spin-lock for such a table where 1551 several secrets can be modified? Can the protocol ensure the 1552 consistency? Should it? 1553 --End editor's note 1555 -- Conformance Information ******************************************* 1557 snmpUsecMIBCompliances 1558 OBJECT IDENTIFIER ::= { snmpUsecMIBConformance 1 } 1559 snmpUsecMIBGroups 1560 OBJECT IDENTIFIER ::= { snmpUsecMIBConformance 2 } 1562 -- Compliance statements 1564 snmpUsecMIBCompliance MODULE-COMPLIANCE 1565 STATUS current 1566 DESCRIPTION "The compliance statement for SNMP engines which 1567 implement the SNMP USEC MIB. 1568 " 1570 MODULE -- this module 1571 MANDATORY-GROUPS { snmpUsecMIBBasicGroup } 1573 OBJECT usecUserGroupName 1574 MIN-ACCESS read-only 1575 DESCRIPTION "Write access is not required." 1577 OBJECT usecUserAuthProtocol 1578 MIN-ACCESS read-only 1579 DESCRIPTION "Write access is not required." 1581 OBJECT usecUserPrivProtocol 1582 MIN-ACCESS read-only 1583 DESCRIPTION "Write access is not required." 1585 ::= { snmpUsecMIBCompliances 1 } 1587 -- Units of compliance 1589 snmpUsecMIBBasicGroup OBJECT-GROUP 1590 OBJECTS { 1591 usecUserMiId, 1592 usecUserGroupName, 1593 usecUserCloneFrom, 1594 usecUserAuthProtocol, 1595 usecUserAuthKeyChange, 1596 usecUserAuthPublic, 1597 usecUserPrivProtocol, 1598 usecUserPrivKeyChange, 1599 usecUserPrivPublic, 1600 usecUserStorageType, 1601 usecUserStatus 1602 } 1603 STATUS current 1604 DESCRIPTION "A collection of objects providing for configuration 1605 of an SNMP engine which implements the SNMP 1606 User-based Security model. 1607 " 1608 ::= { snmpUsecMIBGroups 1 } 1610 END 1611 6. MD5 Authentication Protocol 1613 This section describes the Keyed-MD5 authentication protocol. 1614 This protocol is the first authentication protocol defined for 1615 the User-based Security model. 1616 Over time, other authentication protocols may be defined either 1617 as a replacement of this protocol or in addition to this protocol. 1619 6.1 Mechanisms 1621 - In support of data integrity, a message digest algorithm is 1622 required. A digest is calculated over an appropriate portion 1623 of an SNMPv3 message and included as part of the message sent 1624 to the recipient. 1626 - In support of data origin authentication and data integrity, a 1627 secret value is both inserted into, and appended to, the SNMPv3 1628 message prior to computing the digest; the inserted value is 1629 overwritten prior to transmission, and the appended value is not 1630 transmitted. The secret value is shared by all SNMPv3 engines 1631 authorized to originate messages on behalf of the appropriate 1632 user. 1634 - In order to not expose the shared secrets (keys) at all SNMPv3 1635 engines in case one of the engines is compromised, such secrets 1636 (keys) are localized for each authoritative SNMPv3 engine, see 1637 [Localized-Key]. 1639 6.1.1. Digest Authentication Protocol 1641 The Digest Authentication Protocol defined in this memo provides for: 1643 - verifying the integrity of a received message (i.e., the message 1644 received is the message sent). 1646 The integrity of the message is protected by computing a digest 1647 over an appropriate portion of a message. The digest is computed 1648 by the originator of the message, transmitted with the message, and 1649 verified by the recipient of the message. 1651 - verifying the user on whose behalf the message was generated. 1653 A secret value known only to SNMPv3 engines authorized to generate 1654 messages on behalf of a user is both inserted into, and appended 1655 to, the message prior to the digest computation. Thus, the 1656 verification of the user is implicit with the verification of the 1657 digest. (Note that the use of two copies of the secret, one near 1658 the start and one at the end, is recommended by [KEYED-MD5].) 1660 This protocol uses the MD5 [MD5] message digest algorithm. A 128-bit 1661 digest is calculated over the designated portion of an SNMPv3 message 1662 and included as part of the message sent to the recipient. The size 1663 of both the digest carried in a message and the private 1664 authentication key (the secret) is 16 octets. 1666 6.2 Elements of the Digest Authentication Protocol 1668 This section contains definitions required to realize the 1669 authentication module defined by this memo. 1671 6.2.1. SNMPv3 Users 1673 Authentication using this Digest Authentication protocol makes use 1674 of a defined set of user identities. For any SNMPv3 user on whose 1675 behalf a message must be authenticated at a particular SNMPv3 engine, 1676 that engine must have knowledge of that user. An SNMPv3 engine that 1677 wishes to communicate with another SNMPv3 engine must also have 1678 knowledge of a user known to that engine, including knowledge of the 1679 applicable attributes of that user. 1681 A user and its attributes are defined as follows: 1683 1684 A string representing the name of the user. 1685 1686 A user's secret key to be used when calculating a digest. 1688 6.2.2. EngineID 1690 The engineID value contained in an authenticated message specifies 1691 the authoritative SNMPv3 engine for that particular message. 1692 (see the definition of engineID in the SNMP Architecture document 1693 [SNMP-ARCH]). 1695 The user's (private) authentication key is normally different at 1696 each authoritative SNMPv3 engine and so the snmpEngineID is used 1697 to select the proper key for the authentication process. 1699 6.2.3. SNMPv3 Messages Using this Authentication Protocol 1701 Messages using this authentication protocol carry an authParameters 1702 field as part of the securityParameters. For this protocol, the 1703 authParameters field is the serialized octet string representing 1704 the MD5 digest of the wholeMsg. 1706 The digest is calculated over the wholeMsg so if a message is 1707 authenticated, that also means that all the fields in the message 1708 are intact and have not been tampered with. 1710 6.2.4 Input and Output of the MD5 Authentication Module 1711 This section describes the inputs and outputs that the MD5 1712 Authentication module expects and produces when the User-based 1713 Security module invokes the MD5 Authentication module for 1714 services. 1716 6.2.4.1 Input and Output when generating an SNMPv3 Message 1718 This MD5 authentication protocol assumes that the selection of the 1719 authKey is done by the caller and that the caller passes 1720 the secret key to be used. The abstract service interface is: 1722 authMsg(authKey, wholeMsg) 1724 Where: 1726 authKey 1727 The secret key to be used by the authentication algorithm. 1728 wholeMsg 1729 the message to be authenticated. 1731 Upon completion the authentication module returns information. 1732 The abstract service interface is: 1734 returnAuthMsg(wholeMsg, statusCode) 1736 Where: 1738 wholeMsg 1739 Same as in input, but with authParameters properly filled. 1740 statusCode 1741 The indicator of whether the message was successfully 1742 processed or not. 1744 Note, that is filled by the authentication module 1745 and this field should be already present in the before 1746 the MAC is generated. 1748 6.2.4.2 Input and Output when receiving an SNMPv3 Message 1750 This MD5 authentication protocol assumes that the selection of the 1751 authKey is done by the caller and that the caller passes 1752 the secret key to be used. The abstract service interface is: 1754 authIncomingMsg(authKey, authParameters, wholeMsg) 1756 Where: 1758 authKey 1759 The secret key to be used by the authentication algorithm. 1760 authParameters 1761 the authParameters from the incoming message. 1763 wholeMsg 1764 the message to be authenticated. 1766 Upon completion the authentication module returns information. 1767 The abstract service interface is: 1769 returnAuthIncomingMsg(wholeMsg, statusCode) 1771 wholeMsg 1772 Same as in input, data has been authenticated. 1773 statusCode 1774 The indicator of whether the message was successfully 1775 processed or not. 1777 6.3 Elements of Procedure 1779 This section describes the procedures for the Keyed-MD5 1780 authentication protocol. 1782 6.3.1 Processing an Outgoing Message 1784 This section describes the procedure followed by an SNMPv3 engine 1785 whenever it must authenticate an outgoing message using the 1786 imfAuthMD5Protocol. 1788 1) The authParameters field is set to the serialization according 1789 to the rules in [RFC1906] of an octet string representing the 1790 secret (localized) authKey. 1792 2) The secret (localized) authKey is then appended to the end of 1793 the wholeMsg. 1795 3) The MD5-Digest is calculated according to [MD5]. Then the 1796 authParameters field is replaced with the calculated digest. 1798 4) The wholeMsg (excluding the appended secret key) is then 1799 returned to the caller together with a statusCode of success. 1801 6.3.2 Processing an Incoming Message 1803 This section describes the procedure followed by an SNMPv3 engine 1804 whenever it must authenticate an incoming message using the 1805 imfAuthMD5Protocol. 1807 1) If the digest received in the authParameters field is not 1808 16 octets long, then an error indication (authenticationError) 1809 is returned to the calling module. 1811 2) The digest received in the authParameters field is saved. 1813 3) The digest in the authParameters field is replaced by the 1814 secret (localized) authKey. 1816 4) The secret (localized) authKey is then appended to the end of 1817 the wholeMsg. 1819 5) The MD5-Digest is calculated according to [MD5]. 1820 The authParameters field is replaced with the digest value 1821 that was saved in step 2). 1823 6) Then the newly calculated digest is compared with the digest 1824 saved in step 2). If the digests do not match, then an error 1825 indication (authenticationError) is returned to the calling 1826 module. 1828 7) The wholeMsg (excluding the appended secret key) and a 1829 statusCode of success are then returned to the caller. 1831 7. DES Privacy Protocol 1833 This section describes the DES privacy protocol. 1834 This protocol is the first privacy protocol defined for the 1835 User-based Security model. 1836 Over time, other privacy protocols may be defined either 1837 as a replacement of this protocol or in addition to this protocol. 1839 7.1 Mechanisms 1841 - In support of data confidentiality, an encryption algorithm is 1842 required. An appropriate portion of the message is encrypted 1843 prior to being transmitted. The User-based Security model 1844 specifies that the scopedPDU is the portion of the message 1845 that needs to be encrypted. 1847 - A secret value is in combination with a time value is used to 1848 create the en/decryption key and the initialization vector. 1849 The secret value is shared by all SNMPv3 engines authorized to 1850 originate messages on behalf of the appropriate user. 1852 - In order to not expose the shared secrets (keys) at all SNMPv3 1853 engines in case one of the engines is compromised, such secrets 1854 (keys) are localized for each authoritative SNMPv3 engine, see 1855 [Localized-Key]. 1857 7.1.1. Symmetric Encryption Protocol 1859 The Symmetric Encryption Protocol defined in this memo provides 1860 support for data confidentiality. The designated portion of an 1861 SNMPv3 message is encrypted and included as part of the message 1862 sent to the recipient. 1864 This memo requires that if data confidentiality is supported by 1865 an SNMPv3 engine, this engine must implement at least the Data 1866 Encryption Standard (DES) in the Cipher Block Chaining mode of 1867 operation. 1869 Two organizations have published specifications defining the DES: the 1870 National Institute of Standards and Technology (NIST) [DES-NIST] and 1871 the American National Standards Institute [DES-ANSI]. There is a 1872 companion Modes of Operation specification for each definition 1873 (see [DESO-NIST] and [DESO-ANSI], respectively). 1875 The NIST has published three additional documents that implementors 1876 may find useful. 1878 - There is a document with guidelines for implementing and using the 1879 DES, including functional specifications for the DES and its modes 1880 of operation [DESG-NIST]. 1882 - There is a specification of a validation test suite for the DES 1883 [DEST-NIST]. The suite is designed to test all aspects of the DES 1884 and is useful for pinpointing specific problems. 1886 - There is a specification of a maintenance test for the DES 1887 [DESM-NIST]. The test utilizes a minimal amount of data and 1888 processing to test all components of the DES. It provides a 1889 simple yes-or-no indication of correct operation and is useful 1890 to run as part of an initialization step, e.g., when a computer 1891 re-boots. 1893 7.1.1.1 DES key and Initialization Vector. 1895 The first 8 bytes of the 16-byte secret (private privacy key) are 1896 used as a DES key. 1897 Since DES uses only 56 bits, the Least Significant Bit in each 1898 byte is disregarded. 1900 The Initialization Vector for encryption is obtained using the 1901 following procedure. 1903 The last 8 bytes of the 16-byte secret (private privacy key) 1904 are used as pre-IV. 1906 In order to ensure that IV for two different packets encrypted 1907 by the same key, are not the same (i.e. IV does not repeat) we 1908 need to "salt" the pre-IV with something unique per packet. 1909 An 8-byte octet string is used as the "salt". The concatenation 1910 of the generating engine's 32-bit snmpEngineBoots and a local 1911 32-bit integer that the encryption engine maintains is input to 1912 the "salt". The 32-bit integer is initialized to a random value 1913 at boot time. The 32-bit snmpEngineBoots is converted to the first 1914 4 bytes (Most Significant Byte first) of our "salt". The 32-bit 1915 integer is then converted to the last 4 bytes (Most Significant 1916 Byte first) of our "salt". The resulting "salt" is then XOR-ed 1917 with the pre-IV. The 8-byte salt is then put into the privParameters 1918 field as an octet-string. The "salt" integer is incremented by one 1919 and wraps when it reaches the maximum value. 1921 The "salt" must be placed in the privParameters field to enable the 1922 receiving entity to compute the correct IV and to decrypt the 1923 message. 1925 How exactly the value of the "salt" (and thus of the IV) varies, 1926 is an implementation issue, as long as the measures are taken to 1927 avoid producing a duplicate IV. 1929 7.1.1.2 Data Encryption. 1931 The data to be encrypted is treated as sequence of octets. Its 1932 length should be an integral multiple of 8 - and if not, the 1933 data is padded at the end as necessary. The actual pad value 1934 is irrelevant. 1936 The data is encrypted in Cipher Block Chaining mode. 1937 The plaintext is divided into 64-bit blocks. 1939 The plaintext for each block is XOR-ed with the ciphertext 1940 of the previous block, the result is encrypted and the output 1941 of the encryption is the ciphertext for the block. 1942 This procedure is repeated until there are no more plaintext 1943 blocks. 1945 For the very first block, the Initialization Vector is used 1946 instead of the ciphertext of the previous block. 1948 7.1.1.3 Data Decryption 1950 Before decryption, the encrypted data length is verified. 1951 If the length of the octet sequence to be decrypted is not an 1952 integral multiple of 8 octets, the processing of the octet sequence 1953 is halted and an appropriate exception noted. When decrypting, the 1954 padding is ignored. 1956 The first ciphertext block is decrypted, the decryption output is 1957 XOR-ed with the Initialization Vector, and the result is the first 1958 plaintext block. 1960 For each subsequent block, the ciphertext block is decrypted, 1961 the decryption output is XOR-ed with the previous ciphertext 1962 block and the result is the plaintext block. 1964 7.2 Elements of the DES Privacy Protocol 1966 This section contains definitions required to realize the privacy 1967 module defined by this memo. 1969 7.2.1. SNMPv3 Users 1971 Data En/Decryption using this Symmetric Encryption Protocol makes use 1972 of a defined set of user identities. For any SNMPv3 user on whose 1973 behalf a message must be en/decrypted at a particular SNMPv3 engine, 1974 that engine must have knowledge of that user. An SNMPv3 engine that 1975 wishes to communicate with another SNMPv3 engine must also have 1976 knowledge of a user known to that engine, including knowledge of the 1977 applicable attributes of that user. 1979 A user and its attributes are defined as follows: 1981 1982 An octet string representing the name of the user. 1984 1985 A user's secret key to be used as input for the DES key and IV. 1987 7.2.2. EngineID 1989 The engineID value contained in an authenticated message specifies 1990 the authoritative SNMPv3 engine for that particular message. 1991 (see the definition of engineID in the SNMP Architecture document 1992 [SNMP-ARCH]). 1994 The user's (private) privacy key is normally different at 1995 each authoritative SNMPv3 engine and so the snmpEngineID is used 1996 to select the proper key for the authentication process. 1998 7.2.3. SNMPv3 Messages Using this Privacy Protocol 2000 Messages using this privacy protocol carry a privParameters 2001 field as part of the securityParameters. For this protocol, the 2002 privParameters field is the serialized octet string representing 2003 the "salt" that was used to create the IV. 2005 7.2.4 Input and Output of the DES Privacy Module 2007 This section describes the inputs and outputs that the DES Privacy 2008 module expects and produces when the User-based Security module 2009 invokes the DES Privacy module for services. 2011 7.2.4.1 Input and Output when generating an SNMPv3 Message 2013 This DES privacy protocol assumes that the selection of the 2014 privKey is done by the caller and that the caller passes 2015 the secret key to be used. The abstract service interface is: 2017 encryptMsg(cryptKey, scopedPDU) 2019 Where: 2021 cryptKey 2022 The secret key to be used by the encryption algorithm. 2023 scopedPDU 2024 The data to be encrypted. 2026 Upon completion the privacy module returns information. 2027 The abstract service interface is: 2029 returnEncryptedMsg(encryptedPDU, privParameters, statusCode) 2030 Where: 2031 encryptedPDU 2032 The encrypted scopedPDU (encoded as an octet string). 2033 privParameters 2034 The privacy parameters (encoded as an octet string) that 2035 need to be sent in the outgoing message. 2036 statusCode 2037 The indicator of whether the PDU was encrypted successfully 2038 and if not, it indicates what went wrong. 2040 7.2.4.2 Input and Output when receiving an SNMPv3 Message 2042 This DES privacy protocol assumes that the selection of the 2043 privKey is done by the caller and that the caller passes 2044 the secret key to be used. The abstract service interface is: 2046 decryptMsg(cryptKey, privParameters, encryptedPDU) 2048 Where: 2050 cryptKey 2051 The secret key to be used by the decryption algorithm. 2052 privParameters 2053 The "salt" to be used to calculate the IV. 2054 encryptedPDU 2055 the data to be decrypted 2057 Upon completion the privacy module returns information. 2058 The abstract service interface is: 2060 returnDecryptedMsg(scopedPDU, statusCode) 2062 Where: 2064 scopedPDU 2065 The decrypted scopedPDU. 2066 statusCode 2067 The indicator whether the message was successfully decrypted. 2069 7.3 Elements of Procedure. 2071 This section describes the procedures for the DES privacy protocol. 2073 7.3.1 Processing an Outgoing Message 2075 This section describes the procedure followed by an SNMPv3 engine 2076 whenever it must encrypt part of an outgoing message using the 2077 imfPrivDESProtocol. 2079 1) The secret (localized) cryptKey are used to construct the DES 2080 encryption key, the "salt" and the DES pre-IV (as described in 2081 7.1.1.1). 2083 2) The authParameters field is set to the serialization according 2084 to the rules in [RFC1906] of an octet string representing the 2085 the "salt" string. 2087 2) The scopedPDU is encrypted (as described in 7.1.1.2) and the 2088 encrypted data is serialized according to the rules in [RFC1906] 2089 as an octet string. 2091 3) The the serialized octet string representing the encrypted 2092 scopedPDU together with the privParameters and a statusCode of 2093 success is returned to the caller. 2095 7.3.2 Processing an Incoming Message 2097 This section describes the procedure followed by an SNMPv3 engine 2098 whenever it must decrypt part of an incoming message using the 2099 imfPrivDESProtocol. 2101 1) If the privParameters field is not an 8-byte octet string, 2102 then an error indication (privacyError) is returned to the 2103 calling module. 2105 2) The "salt" is extracted from the privParameters field. 2107 3) The secret (localized) cryptKey and the "salt" are then used 2108 to construct the DES decryption key and pre-IV 2109 (as described in 7.1.1.1). 2111 4) The encryptedPDU is decrypted (as described in 7.1.1.3). 2113 5) If the encryptedPDU cannot be decrypted, then an error 2114 indication (privacyError) is returned to the calling module. 2116 6) The decrypted scopedPDU and a statusCode of success are returned 2117 to the calling module. 2119 8. Editor's Addresses 2121 Co-editor Uri Blumenthal 2122 IBM T. J. Watson Research 2123 postal: 30 Saw Mill River Pkwy, 2124 Hawthorne, NY 10532 2125 USA 2126 email: uri@watson.ibm.com 2127 phone: +1-914-784-7064 2129 Co-editor: Bert Wijnen 2130 IBM T. J. Watson Research 2131 postal: Schagen 33 2132 3461 GL Linschoten 2133 Netherlands 2134 email: wijnen@vnet.ibm.com 2135 phone: +31-348-432-794 2137 9. Acknowledgements 2139 This document is based on the recommendations of the SNMP Security and 2140 Administrative Framework Evolution team, comprised of 2142 David Harrington (Cabletron Systems Inc.) 2143 Jeff Johnson (Cisco) 2144 David Levi (SNMP Research Inc.) 2145 John Linn (Openvision) 2146 Russ Mundy (Trusted Information Systems) chair 2147 Shawn Routhier (Epilogue) 2148 Glenn Waters (Nortel) 2149 Bert Wijnen (IBM T. J. Watson Research) 2151 Further a lot of "cut and paste" material comes from RFC1910 and from 2152 earlier draft documents from the SNMPv2u and SNMPv2* series. 2154 Further more a special thanks is due to the SNMPv3 WG, specifically: 2155 .... 2157 10. Security Considerations 2159 10.1. Recommended Practices 2161 This section describes practices that contribute to the secure, 2162 effective operation of the mechanisms defined in this memo. 2164 - A management station must discard SNMPv3 responses for which 2165 neither the msgID nor the request-id component or the represented 2166 management information corresponds to any currently outstanding 2167 request. 2169 Although it would be typical for a management station to do this 2170 as a matter of course, when using these security protocols it is 2171 significant due to the possibility of message duplication 2172 (malicious or otherwise). 2174 - A management station must generate unpredictable msgIDs and 2175 request-ids in authenticated messages in order to protect against 2176 the possibility of message duplication (malicious or otherwise). 2177 For example, start operations with msgID and/or request-id 0 is 2178 not a good idea. Initializing them with a pseudorandom number 2179 and then incrementing by one would be acceptable. 2181 - A management station should perform time synchronization using 2182 authenticated messages in order to protect against the possibility 2183 of message duplication (malicious or otherwise). 2185 - When sending state altering messages to a managed agent, a 2186 management station should delay sending successive messages to the 2187 managed agent until a positive acknowledgement is received for the 2188 previous message or until the previous message expires. 2190 No message ordering is imposed by the SNMPv3. Messages may be 2191 received in any order relative to their time of generation and 2192 each will be processed in the ordered received. Note that when an 2193 authenticated message is sent to a managed agent, it will be valid 2194 for a period of time of approximately 150 seconds under normal 2195 circumstances, and is subject to replay during this period. 2196 Indeed, a management station must cope with the loss and 2197 re-ordering of messages resulting from anomalies in the network 2198 as a matter of course. 2200 However, a managed object, snmpSetSerialNo [RFC1907], is 2201 specifically defined for use with SNMPv2 set operations in order 2202 to provide a mechanism to ensure the processing of SNMPv2 messages 2203 occurs in a specific order. 2205 - The frequency with which the secrets of an SNMPv3 user should be 2206 changed is indirectly related to the frequency of their use. 2208 Protecting the secrets from disclosure is critical to the overall 2209 security of the protocols. Frequent use of a secret provides a 2210 continued source of data that may be useful to a cryptanalyst in 2211 exploiting known or perceived weaknesses in an algorithm. 2212 Frequent changes to the secret avoid this vulnerability. 2214 Changing a secret after each use is generally regarded as the most 2215 secure practice, but a significant amount of overhead may be 2216 associated with that approach. 2218 Note, too, in a local environment the threat of disclosure may be 2219 less significant, and as such the changing of secrets may be less 2220 frequent. However, when public data networks are the 2221 communication paths, more caution is prudent. 2223 10.2 Defining Users 2225 The mechanisms defined in this document employ the notion of "users" 2226 which map into "groups" and such "groups" have access rights. 2227 How "users" are defined is subject to the security policy of the 2228 network administration. For example, users could be individuals 2229 (e.g., "joe" or "jane"), or a particular role (e.g., "operator" or 2230 "administrator"), or a combination (e.g., "joe-operator", 2231 "jane-operator" or "joe-admin"). Furthermore, a "user" may be a 2232 logical entity, such as a manager station application or set 2233 of manager station applications, acting on behalf of an individual 2234 or role, or set of individuals, or set of roles, including 2235 combinations. 2237 Appendix A describes an algorithm for mapping a user "password" to a 2238 16 octet value for use as either a user's authentication key or 2239 privacy key (or both). Note however, that using the same password 2240 (and therefore the same key) for both authentication and privacy is 2241 very poor security practice and should be strongly discouraged. 2242 Passwords are often generated, remembered, and input by a human. 2243 Human-generated passwords may be less than the 16 octets required 2244 by the authentication and privacy protocols, and brute force 2245 attacks can be quite easy on a relatively short ASCII character set. 2246 Therefore, the algorithm is Appendix A performs a transformation on 2247 the password. If the Appendix A algorithm is used, SNMP 2248 implementations (and SNMP configuration applications) must ensure 2249 that passwords are at least 8 characters in length. 2251 Because the Appendix A algorithm uses such passwords (nearly) 2252 directly, it is very important that they not be easily guessed. It 2253 is suggested that they be composed of mixed-case alphanumeric and 2254 punctuation characters that don't form words or phrases that might 2255 be found in a dictionary. Longer passwords improve the security of 2256 the system. Users may wish to input multiword phrases to make their 2257 password string longer while ensuring that it is memorable. 2259 Since it is infeasible for human users to maintain different 2260 passwords for every engine, but security requirements strongly 2261 discourage having the same key for more than one engine, SNMPv3 2262 employs a compromise proposed in [Localized-key]. 2263 It derives the user keys for the SNMPv3 engines from user's password 2264 in such a way that it is practically impossible to either determine 2265 the user's password, or user's key for another SNMPv3 engine from 2266 any combination of user's keys on SNMPv3 engines. 2268 Note however, that if user's password is disclosed, key localization 2269 will not help and network security may be compromised in this case. 2271 10.3. Conformance 2273 To be termed a "Secure SNMPv3 implementation" based on the User-base 2274 Security model, an SNMPv3 implementation: 2276 - must implement one or more Authentication Protocol(s). The MD5 2277 Authentication Protocol defined in this memo is one such protocol. 2279 - must, to the maximum extent possible, prohibit access to the 2280 secret(s) of each user about which it maintains information in a 2281 Local (security) Configuration Database (LCD) under all 2282 circumstances except as required to generate and/or validate 2283 SNMPv3 messages with respect to that user. 2285 - must implement the SNMP USEC MIB. 2287 In addition, an authoritative SNMPv3 engine must provide initial 2288 configuration in accordance with Appendix A.1. 2290 Implementation of a Privacy Protocol (the Symmetric Encryption 2291 Protocol defined in this memo is one such protocol) is optional. 2293 11. References 2295 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2296 Rose, M., and S., Waldbusser, "Structure of Management 2297 Information for Version 2 of the Simple Network Management 2298 Protocol (SNMPv2)", RFC 1905, January 1996. 2300 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2301 Rose, M., and S., Waldbusser, "Protocol Operations for 2302 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2303 RFC 1905, January 1996. 2305 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2306 Rose, M., and S. Waldbusser, "Transport Mappings for 2307 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2308 RFC 1906, January 1996. 2310 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2311 Rose, M., and S. Waldbusser, "Management Information Base for 2312 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2313 RFC 1907 January 1996. 2315 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2316 Rose, M., and S. Waldbusser, "Coexistence between Version 1 2317 and Version 2 of the Internet-standard Network Management 2318 Framework", RFC 1908, January 1996. 2320 [SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B., 2321 "An Architecture for describing Internet Management Frameworks", 2322 draft-ietf-snmpv3-next-gen-arch-02.txt, June 1997. 2324 [SNMPv3-MPC] The SNMPv3 Working Group, Wijnen, B., Harrington, D., 2325 "Message Processing and Control Model for version 3 of the Simple 2326 Network Management Protocol (SNMPv3)", 2327 draft-ietf-snmpv3-mpc-01.txt, June 1997. 2329 [SNMPv3-ACM] The SNMPv3 Working Group, Wijnen, B., Harrington, D., 2330 "Access Control Model for Version 3 of the Simple Network 2331 Management Protocol (SNMPv3)", draft-ietf-snmpv3-acm-00.txt, 2332 June 1997. 2334 [SNMPv3-USEC] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B. 2335 "User-Based Security Model for version 3 of the Simple Network 2336 Management Protocol (SNMPv3)", 2337 draft-ietf-snmpv3-usec-01.txt, June 1997. 2339 [Localized-Key] U. Blumenthal, N. C. Hien, B. Wijnen 2340 "Key Derivation for Network Management Applications" 2341 IEEE Network Magazine, April/May issue, 1997. 2343 [KEYED-MD5] Krawczyk, H., 2344 "Keyed-MD5 for Message Authentication", 2345 Work in Progress, IBM, June 1995. 2347 [MD5] Rivest, R. 2348 "Message Digest Algorithm MD5" 2349 RFC 1321. 2351 [DES-NIST] Data Encryption Standard, National Institute of Standards 2352 and Technology. Federal Information Processing Standard (FIPS) 2353 Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; 2354 reaffirmed January, 1988). 2356 [DES-ANSI] Data Encryption Algorithm, American National Standards 2357 Institute. ANSI X3.92-1981, (December, 1980). 2359 [DESO-NIST] DES Modes of Operation, National Institute of Standards and 2360 Technology. Federal Information Processing Standard (FIPS) 2361 Publication 81, (December, 1980). 2363 [DESO-ANSI] Data Encryption Algorithm - Modes of Operation, American 2364 National Standards Institute. ANSI X3.106-1983, (May 1983). 2366 [DESG-NIST] Guidelines for Implementing and Using the NBS Data 2367 Encryption Standard, National Institute of Standards and 2368 Technology. Federal Information Processing Standard (FIPS) 2369 Publication 74, (April, 1981). 2371 [DEST-NIST] Validating the Correctness of Hardware Implementations of 2372 the NBS Data Encryption Standard, National Institute of Standards 2373 and Technology. Special Publication 500-20. 2375 [DESM-NIST] Maintenance Testing for the Data Encryption Standard, 2376 National Institute of Standards and Technology. 2377 Special Publication 500-61, (August, 1980). 2379 APPENDIX A - Installation 2381 A.1. Engine Installation Parameters 2383 During installation, an SNMPv3 engine acting in an authoritative role 2384 is configured with several parameters. These include: 2386 (1) one or more secrets 2388 These are the authentication/privacy secrets for the first user 2389 to be configured. 2391 One way to accomplish this is to have the installer enter a 2392 "password" for each required secret. The password is then 2393 algorithmically converted into the required secret by: 2395 - forming a string of length 1,048,576 octets by repeating the 2396 value of the password as often as necessary, truncating 2397 accordingly, and using the resulting string as the input to 2398 the MD5 algorithm [MD5]. The resulting digest, termed "digest1", 2399 is used in the next step. 2401 - a second string of length 44 octets is formed by concatenating 2402 digest1, the SNMPv3 engine's snmpEngineID value, and digest1. 2403 This string is used as input to the MD5 algorithm [MD5]. 2405 The resulting digest is the required secret (see Appendix A.2). 2407 With these configured parameters, the SNMPv3 engine instantiates 2408 the following usecUserEntry in the usecUserTable: 2410 no privacy support privacy support 2411 ------------------ --------------- 2412 usecUserEngineID localEngineID localEngineID 2413 usecUserName "public" "public" 2414 usecUserMiId "public" "public" 2415 usecUserGroupName "public" "public" 2416 usecUserCloseFrom ZeroDotZero ZeroDotZero 2417 usecUserAuthProtocol imfAuthMD5Protocol imfAuthMD5Protocol 2418 usecUserAuthKeyChange "" "" 2419 usecUserAuthPublic "" "" 2420 usecUserPrivProtocol none imfPrivDESProtocol 2421 usecUserPrivKeyChange "" "" 2422 usecUserrivhPublic "" "" 2423 usecUserStorageType permanent permanent 2424 usecUserStatus active active 2426 A.2. Password to Key Algorithm 2428 The following code fragment demonstrates the password to key 2429 algorithm which can be used when mapping a password to an 2430 authentication or privacy key. The calls to MD5 are as 2431 documented in RFC1321 [RFC1321] 2433 void password_to_key( 2434 u_char *password, /* IN */ 2435 u_int passwordlen, /* IN */ 2436 u_char *engineID, /* IN - ptr to 12 octet long snmpEngineID */ 2437 u_char *key) /* OUT - caller's pointer to 16-byte buffer */ 2438 { 2439 MD5_CTX MD; 2440 u_char *cp, password_buf[64]; 2441 u_long password_index = 0; 2442 u_long count = 0, i; 2444 MD5Init (&MD); /* initialize MD5 */ 2446 /**********************************************/ 2447 /* Use while loop until we've done 1 Megabyte */ 2448 /**********************************************/ 2449 while (count < 1048576) { 2450 cp = password_buf; 2451 for (i = 0; i < 64; i++) { 2452 /*************************************************/ 2453 /* Take the next byte of the password, wrapping */ 2454 /* to the beginning of the password as necessary.*/ 2455 /*************************************************/ 2456 *cp++ = password[password_index++ % passwordlen]; 2457 } 2458 MDupdate (&MD, password_buf, 64); 2459 count += 64; 2460 } 2461 MD5Final (key, &MD); /* tell MD5 we're done */ 2463 /*****************************************************/ 2464 /* Now localize the key with the engineID and pass */ 2465 /* through MD5 to produce final key */ 2466 /*****************************************************/ 2467 memcpy(password_buf, key, 16); 2468 memcpy(password_buf+16, engineID, 12); 2469 memcpy(password_buf+28, key, 16); 2471 MD5Init(&MD); 2472 MDupdate(&MD, password_buf, 44); 2473 MD5Final(key, &MD); 2475 return; 2476 } 2477 A.3. Password to Key Sample 2479 The following shows a sample output of the password to key algorithm. 2481 With a password of "maplesyrup" the output of the password to key 2482 algorithm before the key is localized with the engine's engineID is: 2484 '9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H 2486 After the intermediate key (shown above) is localized with the 2487 snmpEngineID value of: 2489 '00 00 00 00 00 00 00 00 00 00 00 02'H 2491 the final output of the password to key algorithm is: 2493 '52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H 2495 Table of Contents 2497 0.1 Issues 1 2498 0.2 Change Log 2 2499 1. Introduction 3 2500 1.1. Threats 3 2501 1.2. Goals and Constraints 4 2502 1.3. Security Services 5 2503 1.4. Implementation Organization 6 2504 1.4.1. Timeliness Module 6 2505 1.4.2. Authentication Protocol 6 2506 1.4.3. Privacy Protocol 7 2507 1.5 Protection against Message Replay, Delay and Redirection 7 2508 1.5.1 Authoritative SNMP Engine 7 2509 1.5.2 The following mechanisms are used: 7 2510 2. Elements of the Model 10 2511 2.1. SNMPv3 Users 10 2512 2.2. Replay Protection 11 2513 2.2.1. snmpEngineID 11 2514 2.2.2. engineBoots and engineTime 11 2515 2.3 for (re-)synchronization procedures). Note, however, that the 12 2516 2.2.3. Time Window 12 2517 2.3. Time Synchronization 12 2518 2.4. SNMPv3 Messages Using this Model 13 2519 2.5 Input and Output of the User-based Security Module 14 2520 2.5.1 Input and Output when generating an SNMPv3 Message 14 2521 2.5.2 Input and Output when receiving an SNMPv3 Message 15 2522 3. Elements of Procedure 18 2523 3.1. Processing an Outgoing Message 18 2524 3.2. Processing an Incoming Message 20 2525 2.4, then the snmpInASNParseErrs counter [RFC1907] is 20 2526 4. Discovery 25 2527 5. Definitions 26 2528 6. MD5 Authentication Protocol 36 2529 6.1 Mechanisms 36 2530 6.1.1. Digest Authentication Protocol 36 2531 6.2 Elements of the Digest Authentication Protocol 37 2532 6.2.1. SNMPv3 Users 37 2533 6.2.2. EngineID 37 2534 6.2.3. SNMPv3 Messages Using this Authentication Protocol 37 2535 6.2.4 Input and Output of the MD5 Authentication Module 37 2536 6.2.4.1 Input and Output when generating an SNMPv3 Message 38 2537 6.2.4.2 Input and Output when receiving an SNMPv3 Message 38 2538 6.3 Elements of Procedure 39 2539 6.3.1 Processing an Outgoing Message 39 2540 6.3.2 Processing an Incoming Message 39 2541 7. DES Privacy Protocol 41 2542 7.1 Mechanisms 41 2543 7.1.1. Symmetric Encryption Protocol 41 2544 7.1.1.1 DES key and Initialization Vector. 42 2545 7.1.1.2 Data Encryption. 42 2546 7.1.1.3 Data Decryption 43 2547 7.2 Elements of the DES Privacy Protocol 43 2548 7.2.1. SNMPv3 Users 43 2549 7.2.2. EngineID 44 2550 7.2.3. SNMPv3 Messages Using this Privacy Protocol 44 2551 7.2.4 Input and Output of the DES Privacy Module 44 2552 7.2.4.1 Input and Output when generating an SNMPv3 Message 44 2553 7.2.4.2 Input and Output when receiving an SNMPv3 Message 45 2554 7.3 Elements of Procedure. 45 2555 7.3.1 Processing an Outgoing Message 45 2556 7.1.1.1). 45 2557 7.3.2 Processing an Incoming Message 46 2558 8. Editor's Addresses 47 2559 9. Acknowledgements 47 2560 A.1. Engine Installation Parameters 53 2561 A.2. Password to Key Algorithm 54 2562 A.3. Password to Key Sample 55