diff options
Diffstat (limited to 'doc/rfc/rfc2264.txt')
| -rw-r--r-- | doc/rfc/rfc2264.txt | 4259 |
1 files changed, 4259 insertions, 0 deletions
diff --git a/doc/rfc/rfc2264.txt b/doc/rfc/rfc2264.txt new file mode 100644 index 0000000..63fff94 --- /dev/null +++ b/doc/rfc/rfc2264.txt @@ -0,0 +1,4259 @@ + + + + + + +Network Working Group U. Blumenthal +Request for Comments: 2264 IBM T. J. Watson Research +Category: Standards Track B. Wijnen + IBM T. J. Watson Research + January 1998 + + + User-based Security Model (USM) for version 3 of the + Simple Network Management Protocol (SNMPv3) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1997). All Rights Reserved. + +Abstract + + This document describes the User-based Security Model (USM) for SNMP + version 3 for use in the SNMP architecture [RFC2261]. It defines the + Elements of Procedure for providing SNMP message level security. + This document also includes a MIB for remotely monitoring/managing + the configuration parameters for this Security Model. + +Table of Contents + +1. Introduction 3 +1.1. Threats 4 +1.2. Goals and Constraints 5 +1.3. Security Services 6 +1.4. Module Organization 7 +1.4.1. Timeliness Module 7 +1.4.2. Authentication Protocol 8 +1.4.3. Privacy Protocol 8 +1.5. Protection against Message Replay, Delay and Redirection 8 +1.5.1. Authoritative SNMP engine 8 +1.5.2. Mechanisms 8 +1.6. Abstract Service Interfaces. 10 +1.6.1. User-based Security Model Primitives for Authentication 11 +1.6.2. User-based Security Model Primitives for Privacy 11 +2. Elements of the Model 12 +2.1. User-based Security Model Users 12 + + + +Blumenthal & Wijnen Standards Track [Page 1] + +RFC 2264 USM for SNMPv3 January 1998 + + +2.2. Replay Protection 13 +2.2.1. msgAuthoritativeEngineID 13 +2.2.2. msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime 14 +2.2.3. Time Window 15 +2.3. Time Synchronization 15 +2.4. SNMP Messages Using this Security Model 16 +2.5. Services provided by the User-based Security Model 17 +2.5.1. Services for Generating an Outgoing SNMP Message 17 +2.5.2. Services for Processing an Incoming SNMP Message 19 +2.6. Key Localization Algorithm. 21 +3. Elements of Procedure 21 +3.1. Generating an Outgoing SNMP Message 22 +3.2. Processing an Incoming SNMP Message 25 +4. Discovery 30 +5. Definitions 31 +6. HMAC-MD5-96 Authentication Protocol 45 +6.1. Mechanisms 45 +6.1.1. Digest Authentication Mechanism 46 +6.2. Elements of the Digest Authentication Protocol 46 +6.2.1. Users 46 +6.2.2. msgAuthoritativeEngineID 47 +6.2.3. SNMP Messages Using this Authentication Protocol 47 +6.2.4. Services provided by the HMAC-MD5-96 Authentication Module 47 +6.2.4.1. Services for Generating an Outgoing SNMP Message 47 +6.2.4.2. Services for Processing an Incoming SNMP Message 48 +6.3. Elements of Procedure 49 +6.3.1. Processing an Outgoing Message 49 +6.3.2. Processing an Incoming Message 50 +7. HMAC-SHA-96 Authentication Protocol 51 +7.1. Mechanisms 51 +7.1.1. Digest Authentication Mechanism 51 +7.2. Elements of the HMAC-SHA-96 Authentication Protocol 52 +7.2.1. Users 52 +7.2.2. msgAuthoritativeEngineID 52 +7.2.3. SNMP Messages Using this Authentication Protocol 53 +7.2.4. Services provided by the HMAC-SHA-96 Authentication Module 53 +7.2.4.1. Services for Generating an Outgoing SNMP Message 53 +7.2.4.2. Services for Processing an Incoming SNMP Message 54 +7.3. Elements of Procedure 54 +7.3.1. Processing an Outgoing Message 55 +7.3.2. Processing an Incoming Message 55 +8. CBC-DES Symmetric Encryption Protocol 56 +8.1. Mechanisms 56 +8.1.1. Symmetric Encryption Protocol 57 +8.1.1.1. DES key and Initialization Vector. 57 +8.1.1.2. Data Encryption. 58 +8.1.1.3. Data Decryption 59 +8.2. Elements of the DES Privacy Protocol 59 + + + +Blumenthal & Wijnen Standards Track [Page 2] + +RFC 2264 USM for SNMPv3 January 1998 + + +8.2.1. Users 59 +8.2.2. msgAuthoritativeEngineID 59 +8.2.3. SNMP Messages Using this Privacy Protocol 60 +8.2.4. Services provided by the DES Privacy Module 60 +8.2.4.1. Services for Encrypting Outgoing Data 60 +8.2.4.2. Services for Decrypting Incoming Data 61 +8.3. Elements of Procedure. 61 +8.3.1. Processing an Outgoing Message 61 +8.3.2. Processing an Incoming Message 62 +9. Intellectual Property 62 +10. Acknowledgements 63 +11. Security Considerations 64 +11.1. Recommended Practices 64 +11.2. Defining Users 66 +11.3. Conformance 67 +12. References 67 +13. Editors' Addresses 69 +A.1. SNMP engine Installation Parameters 70 +A.2. Password to Key Algorithm 71 +A.2.1. Password to Key Sample Code for MD5 71 +A.2.2. Password to Key Sample Code for SHA 72 +A.3. Password to Key Sample Results 73 +A.3.1. Password to Key Sample Results using MD5 73 +A.3.2. Password to Key Sample Results using SHA 74 +A.4. Sample encoding of msgSecurityParameters 74 +B. Full Copyright Statement 76 + +1. Introduction + + The Architecture for describing Internet Management Frameworks + [RFC2261] describes that an SNMP engine is composed of: + + 1) a Dispatcher + 2) a Message Processing Subsystem, + 3) a Security Subsystem, and + 4) an Access Control Subsystem. + + Applications make use of the services of these subsystems. + + It is important to understand the SNMP architecture and the + terminology of the architecture to understand where the Security + Model described in this document fits into the architecture and + interacts with other subsystems within the architecture. The reader + is expected to have read and understood the description of the SNMP + architecture, as defined in [RFC2261]. + + + + + + +Blumenthal & Wijnen Standards Track [Page 3] + +RFC 2264 USM for SNMPv3 January 1998 + + + This memo [RFC2264] describes the User-based Security Model as it is + used within the SNMP Architecture. The main idea is that we use the + traditional concept of a user (identified by a userName) with which + to associate security information. + + This memo describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the + authentication protocols and the use of CBC-DES as the privacy + protocol. The User-based Security Model however allows for other such + protocols to be used instead of or concurrent with these protocols. + Therefore, the description of HMAC-MD5-96, HMAC-SHA-96 and CBC-DES + are in separate sections to reflect their self-contained nature and + to indicate that they can be replaced or supplemented in the future. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.1. Threats + + Several of the classical threats to network protocols are applicable + to the network management problem and therefore would be applicable + to any SNMP Security Model. Other threats are not applicable to the + network management problem. This section discusses principal + threats, secondary threats, and threats which are of lesser + importance. + + The principal threats against which this SNMP Security Model should + provide protection are: + + - Modification of Information + The modification threat is the danger that some unauthorized entity + may alter in-transit SNMP messages generated on behalf of an + authorized user in such a way as to effect unauthorized management + operations, including falsifying the value of an object. + + - Masquerade + The masquerade threat is the danger that management operations not + authorized for some user may be attempted by assuming the identity + of another user that has the appropriate authorizations. + + Two secondary threats are also identified. The Security Model + defined in this memo provides limited protection against: + + - Disclosure + The disclosure threat is the danger of eavesdropping on the + exchanges between managed agents and a management station. + Protecting against this threat may be required as a matter of local + policy. + + + +Blumenthal & Wijnen Standards Track [Page 4] + +RFC 2264 USM for SNMPv3 January 1998 + + + - Message Stream Modification + The SNMP protocol is typically based upon a connection-less + transport service which may operate over any sub-network service. + The re-ordering, delay or replay of messages can and does occur + through the natural operation of many such sub-network services. + The message stream modification threat is the danger that messages + may be maliciously re-ordered, delayed or replayed to an extent + which is greater than can occur through the natural operation of a + sub-network service, in order to effect unauthorized management + operations. + + There are at least two threats that an SNMP Security Model need not + protect against. The security protocols defined in this memo do not + provide protection against: + + - Denial of Service + This SNMP Security Model does not attempt to address the broad + range of attacks by which service on behalf of authorized users is + denied. Indeed, such denial-of-service attacks are in many cases + indistinguishable from the type of network failures with which any + viable network management protocol must cope as a matter of course. + - Traffic Analysis + This SNMP Security Model does not attempt to address traffic + analysis attacks. Indeed, many traffic patterns are predictable - + devices may be managed on a regular basis by a relatively small + number of management applications - and therefore there is no + significant advantage afforded by protecting against traffic + analysis. + +1.2. Goals and Constraints + + Based on the foregoing account of threats in the SNMP network + management environment, the goals of this SNMP Security Model are as + follows. + + 1) Provide for verification that each received SNMP message has + not been modified during its transmission through the network. + + 2) Provide for verification of the identity of the user on whose + behalf a received SNMP message claims to have been generated. + + 3) Provide for detection of received SNMP messages, which request + or contain management information, whose time of generation was + not recent. + + 4) Provide, when necessary, that the contents of each received + SNMP message are protected from disclosure. + + + + +Blumenthal & Wijnen Standards Track [Page 5] + +RFC 2264 USM for SNMPv3 January 1998 + + + In addition to the principal goal of supporting secure network + management, the design of this SNMP Security Model is also influenced + by the following constraints: + + 1) When the requirements of effective management in times of + network stress are inconsistent with those of security, the design + should prefer the former. + + 2) Neither the security protocol nor its underlying security + mechanisms should depend upon the ready availability of other + network services (e.g., Network Time Protocol (NTP) or key + management protocols). + + 3) A security mechanism should entail no changes to the basic + SNMP network management philosophy. + +1.3. Security Services + + The security services necessary to support the goals of this SNMP + Security Model are as follows: + + - Data Integrity + is the provision of the property that data has not been altered or + destroyed in an unauthorized manner, nor have data sequences been + altered to an extent greater than can occur non-maliciously. + + - Data Origin Authentication + is the provision of the property that the claimed identity of the + user on whose behalf received data was originated is corroborated. + + - Data Confidentiality + is the provision of the property that information is not made + available or disclosed to unauthorized individuals, entities, or + processes. + + - Message timeliness and limited replay protection + is the provision of the property that a message whose generation + time is outside of a specified time window is not accepted. Note + that message reordering is not dealt with and can occur in normal + conditions too. + + For the protocols specified in this memo, it is not possible to + assure the specific originator of a received SNMP message; rather, it + is the user on whose behalf the message was originated that is + authenticated. + + + + + + +Blumenthal & Wijnen Standards Track [Page 6] + +RFC 2264 USM for SNMPv3 January 1998 + + + For these protocols, it not possible to obtain data integrity without + data origin authentication, nor is it possible to obtain data origin + authentication without data integrity. Further, there is no + provision for data confidentiality without both data integrity and + data origin authentication. + + The security protocols used in this memo are considered acceptably + secure at the time of writing. However, the procedures allow for new + authentication and privacy methods to be specified at a future time + if the need arises. + +1.4. Module Organization + + The security protocols defined in this memo are split in three + different modules and each has its specific responsibilities such + that together they realize the goals and security services described + above: + + - The authentication module MUST provide for: + + - Data Integrity, + + - Data Origin Authentication + + - The timeliness module MUST provide for: + + - Protection against message delay or replay (to an extent + greater than can occur through normal operation) + + The privacy module MUST provide for + + - Protection against disclosure of the message payload. + + The timeliness module is fixed for the User-based Security Model + while there is provision for multiple authentication and/or privacy + modules, each of which implements a specific authentication or + privacy protocol respectively. + +1.4.1. Timeliness Module + + Section 3 (Elements of Procedure) uses the timeliness values in an + SNMP message to do timeliness checking. The timeliness check is only + performed if authentication is applied to the message. Since the + complete message is checked for integrity, we can assume that the + timeliness values in a message that passes the authentication module + are trustworthy. + + + + + +Blumenthal & Wijnen Standards Track [Page 7] + +RFC 2264 USM for SNMPv3 January 1998 + + +1.4.2. Authentication Protocol + + Section 6 describes the HMAC-MD5-96 authentication protocol which is + the first authentication protocol that MUST be supported with the + User-based Security Model. Section 7 describes the HMAC-SHA-96 + authentication protocol which is another authentication protocol that + SHOULD be supported with the User-based Security Model. In the + future additional or replacement authentication protocols may be + defined as new needs arise. + + The User-based Security Model prescribes that, if authentication is + used, then the complete message is checked for integrity in the + authentication module. + + For a message to be authenticated, it needs to pass authentication + check by the authentication module and the timeliness check which is + a fixed part of this User-based Security model. + +1.4.3. Privacy Protocol + + Section 8 describes the CBC-DES Symmetric Encryption Protocol which + is the first privacy protocol to be used with the User-based Security + Model. In the future additional or replacement privacy protocols may + be defined as new needs arise. + + The User-based Security Model prescribes that the scopedPDU is + protected from disclosure when a message is sent with privacy. + + The User-based Security Model also prescribes that a message needs to + be authenticated if privacy is in use. + +1.5. Protection against Message Replay, Delay and Redirection + +1.5.1. Authoritative SNMP engine + + In order to protect against message replay, delay and redirection, + one of the SNMP engines involved in each communication is designated + to be the authoritative SNMP engine. When an SNMP message contains a + payload which expects a response (for example a Get, GetNext, + GetBulk, Set or Inform PDU), then the receiver of such messages is + authoritative. When an SNMP message contains a payload which does + not expect a response (for example an SNMPv2-Trap, Response or Report + PDU), then the sender of such a message is authoritative. + +1.5.2. Mechanisms + + The following mechanisms are used: + + + + +Blumenthal & Wijnen Standards Track [Page 8] + +RFC 2264 USM for SNMPv3 January 1998 + + + 1) To protect against the threat of message delay or replay (to an + extent greater than can occur through normal operation), a set of + timeliness indicators (for the authoritative SNMP engine) are + included in each message generated. An SNMP engine evaluates the + timeliness indicators to determine if a received message is + recent. An SNMP engine may evaluate the timeliness indicators to + ensure that a received message is at least as recent as the last + message it received from the same source. A non-authoritative + SNMP engine uses received authentic messages to advance its notion + of the timeliness indicators at the remote authoritative source. + + An SNMP engine MUST also use a mechanism to match incoming + Responses to outstanding Requests and it MUST drop any Responses + that do not match an outstanding request. For example, a msgID can + be inserted in every message to cater for this functionality. + + These mechanisms provide for the detection of authenticated + messages whose time of generation was not recent. + + This protection against the threat of message delay or replay does + not imply nor provide any protection against unauthorized deletion + or suppression of messages. Also, an SNMP engine may not be able + to detect message reordering if all the messages involved are sent + within the Time Window interval. Other mechanisms defined + independently of the security protocol can also be used to detect + the re-ordering replay, deletion, or suppression of messages + containing Set operations (e.g., the MIB variable snmpSetSerialNo + [RFC1907]). + + 2) Verification that a message sent to/from one authoritative SNMP + engine cannot be replayed to/as-if-from another authoritative SNMP + engine. + + Included in each message is an identifier unique to the + authoritative SNMP engine associated with the sender or intended + recipient of the message. + + A Report, Response or Trap message sent by an authoritative SNMP + engine to one non-authoritative SNMP engine can potentially be + replayed to another non-authoritative SNMP engine. The latter + non-authoritative SNMP engine might (if it knows about the same + userName with the same secrets at the authoritative SNMP engine) + as a result update its notion of timeliness indicators of the + authoritative SNMP engine, but that is not considered a threat. + In this case, A Report or Response message will be discarded by + the Message Processing Model, because there should not be an + outstanding Request message. A Trap will possibly be accepted. + Again, that is not considered a threat, because the communication + + + +Blumenthal & Wijnen Standards Track [Page 9] + +RFC 2264 USM for SNMPv3 January 1998 + + + was authenticated and timely. It is as if the authoritative SNMP + engine was configured to start sending Traps to the second SNMP + engine, which theoretically can happen without the knowledge of + the second SNMP engine anyway. Anyway, the second SNMP engine may + not expect to receive this Trap, but is allowed to see the + management information contained in it. + + 3) Detection of messages which were not recently generated. + + A set of time indicators are included in the message, indicating + the time of generation. Messages without recent time indicators + are not considered authentic. In addition, an SNMP engine MUST + drop any Responses that do not match an outstanding request. This + however is the responsibility of the Message Processing Model. + + This memo allows the same user to be defined on multiple SNMP + engines. Each SNMP engine maintains a value, snmpEngineID, which + uniquely identifies the SNMP engine. This value is included in each + message sent to/from the SNMP engine that is authoritative (see + section 1.5.1). On receipt of a message, an authoritative SNMP + engine checks the value to ensure that it is the intended recipient, + and a non-authoritative SNMP engine uses the value to ensure that the + message is processed using the correct state information. + + Each SNMP engine maintains two values, snmpEngineBoots and + snmpEngineTime, which taken together provide an indication of time at + that SNMP engine. Both of these values are included in an + authenticated message sent to/received from that SNMP engine. On + receipt, the values are checked to ensure that the indicated + timeliness value is within a Time Window of the current time. The + Time Window represents an administrative upper bound on acceptable + delivery delay for protocol messages. + + For an SNMP engine to generate a message which an authoritative SNMP + engine will accept as authentic, and to verify that a message + received from that authoritative SNMP engine is authentic, such an + SNMP engine must first achieve timeliness synchronization with the + authoritative SNMP engine. See section 2.3. + +1.6. Abstract Service Interfaces. + + Abstract service interfaces have been defined to describe the + conceptual interfaces between the various subsystems within an SNMP + entity. Similarly a set of abstract service interfaces have been + defined within the User-based Security Model (USM) to describe the + conceptual interfaces between the generic USM services and the self- + contained authentication and privacy services. + + + + +Blumenthal & Wijnen Standards Track [Page 10] + +RFC 2264 USM for SNMPv3 January 1998 + + + These abstract service interfaces are defined by a set of primitives + that define the services provided and the abstract data elements that + must be passed when the services are invoked. This section lists the + primitives that have been defined for the User-based Security Model. + +1.6.1. User-based Security Model Primitives for Authentication + + The User-based Security Model provides the following internal + primitives to pass data back and forth between the Security Model + itself and the authentication service: + + statusInformation = + authenticateOutgoingMsg( + IN authKey -- secret key for authentication + IN wholeMsg -- unauthenticated complete message + OUT authenticatedWholeMsg -- complete authenticated message + ) + + statusInformation = + authenticateIncomingMsg( + IN authKey -- secret key for authentication + IN authParameters -- as received on the wire + IN wholeMsg -- as received on the wire + OUT authenticatedWholeMsg -- complete authenticated message + ) + +1.6.2. User-based Security Model Primitives for Privacy + + The User-based Security Model provides the following internal + primitives to pass data back and forth between the Security Model + itself and the privacy service: + + statusInformation = + encryptData( + IN encryptKey -- secret key for encryption + IN dataToEncrypt -- data to encrypt (scopedPDU) + OUT encryptedData -- encrypted data (encryptedPDU) + OUT privParameters -- filled in by service provider + ) + + statusInformation = + decryptData( + IN decryptKey -- secret key for decrypting + IN privParameters -- as received on the wire + IN encryptedData -- encrypted data (encryptedPDU) + OUT decryptedData -- decrypted data (scopedPDU) + ) + + + + +Blumenthal & Wijnen Standards Track [Page 11] + +RFC 2264 USM for SNMPv3 January 1998 + + +2. Elements of the Model + + This section contains definitions required to realize the security + model defined by this memo. + +2.1. User-based Security Model Users + + Management operations using this Security Model make use of a defined + set of user identities. For any user on whose behalf management + operations are authorized at a particular SNMP engine, that SNMP + engine must have knowledge of that user. An SNMP engine that wishes + to communicate with another SNMP engine must also have knowledge of a + user known to that engine, including knowledge of the applicable + attributes of that user. + + A user and its attributes are defined as follows: + + userName + A string representing the name of the user. + + securityName + A human-readable string representing the user in a format that is + Security Model independent. + + authProtocol + An indication of whether messages sent on behalf of this user can + be authenticated, and if so, the type of authentication protocol + which is used. Two such protocols are defined in this memo: + - the HMAC-MD5-96 authentication protocol. + - the HMAC-SHA-96 authentication protocol. + + authKey + If messages sent on behalf of this user can be authenticated, + the (private) authentication key for use with the authentication + protocol. Note that a user's authentication key will normally + be different at different authoritative SNMP engines. The authKey + is not accessible via SNMP. The length requirements of the authKey + are defined by the authProtocol in use. + + authKeyChange and authOwnKeyChange + The only way to remotely update the authentication key. Does + that in a secure manner, so that the update can be completed + without the need to employ privacy protection. + + + + + + + + +Blumenthal & Wijnen Standards Track [Page 12] + +RFC 2264 USM for SNMPv3 January 1998 + + + privProtocol + An indication of whether messages sent on behalf of this user + can be protected from disclosure, and if so, the type of privacy + protocol which is used. One such protocol is defined in this + memo: the CBC-DES Symmetric Encryption Protocol. + + privKey + If messages sent on behalf of this user can be en/decrypted, + the (private) privacy key for use with the privacy protocol. + Note that a user's privacy key will normally be different at + different authoritative SNMP engines. The privKey is not + accessible via SNMP. The length requirements of the privKey are + defined by the privProtocol in use. + + privKeyChange and privOwnKeyChange + The only way to remotely update the encryption key. Does that + in a secure manner, so that the update can be completed without + the need to employ privacy protection. + +2.2. Replay Protection + + Each SNMP engine maintains three objects: + + - snmpEngineID, which (at least within an administrative domain) + uniquely and unambiguously identifies an SNMP engine. + + - snmpEngineBoots, which is a count of the number of times the + SNMP engine has re-booted/re-initialized since snmpEngineID + was last configured; and, + + - snmpEngineTime, which is the number of seconds since the + snmpEngineBoots counter was last incremented. + + Each SNMP engine is always authoritative with respect to these + objects in its own SNMP entity. It is the responsibility of a + non-authoritative SNMP engine to synchronize with the + authoritative SNMP engine, as appropriate. + + An authoritative SNMP engine is required to maintain the values of + its snmpEngineID and snmpEngineBoots in non-volatile storage. + +2.2.1. msgAuthoritativeEngineID + + The msgAuthoritativeEngineID value contained in an authenticated + message is used to defeat attacks in which messages from one SNMP + engine to another SNMP engine are replayed to a different SNMP + engine. It represents the snmpEngineID at the authoritative SNMP + engine involved in the exchange of the message. + + + +Blumenthal & Wijnen Standards Track [Page 13] + +RFC 2264 USM for SNMPv3 January 1998 + + + When an authoritative SNMP engine is first installed, it sets its + local value of snmpEngineID according to a enterprise-specific + algorithm (see the definition of the Textual Convention for + SnmpEngineID in the SNMP Architecture document [RFC2261]). + +2.2.2. msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime + + The msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime + values contained in an authenticated message are used to defeat + attacks in which messages are replayed when they are no longer + valid. They represent the snmpEngineBoots and snmpEngineTime + values at the authoritative SNMP engine involved in the exchange + of the message. + + Through use of snmpEngineBoots and snmpEngineTime, there is no + requirement for an SNMP engine to have a non-volatile clock which + ticks (i.e., increases with the passage of time) even when the + SNMP engine is powered off. Rather, each time an SNMP engine + re-boots, it retrieves, increments, and then stores snmpEngineBoots + in non-volatile storage, and resets snmpEngineTime to zero. + + When an SNMP engine is first installed, it sets its local values + of snmpEngineBoots and snmpEngineTime to zero. If snmpEngineTime + ever reaches its maximum value (2147483647), then snmpEngineBoots + is incremented as if the SNMP engine has re-booted and + snmpEngineTime is reset to zero and starts incrementing again. + + Each time an authoritative SNMP engine re-boots, any SNMP engines + holding that authoritative SNMP engine's values of snmpEngineBoots + and snmpEngineTime need to re-synchronize prior to sending + correctly authenticated messages to that authoritative SNMP engine + (see Section 2.3 for (re-)synchronization procedures). Note, + however, that the procedures do provide for a notification to be + accepted as authentic by a receiving SNMP engine, when sent by an + authoritative SNMP engine which has re-booted since the receiving + SNMP engine last (re-)synchronized. + + If an authoritative SNMP engine is ever unable to determine its + latest snmpEngineBoots value, then it must set its snmpEngineBoots + value to 2147483647. + + Whenever the local value of snmpEngineBoots has the value 2147483647 + it latches at that value and an authenticated message always causes + an notInTimeWindow authentication failure. + + In order to reset an SNMP engine whose snmpEngineBoots value has + reached the value 2147483647, manual intervention is required. + The engine must be physically visited and re-configured, either + + + +Blumenthal & Wijnen Standards Track [Page 14] + +RFC 2264 USM for SNMPv3 January 1998 + + + with a new snmpEngineID value, or with new secret values for the + authentication and privacy protocols of all users known to that + SNMP engine. Note that even if an SNMP engine re-boots once a second + that it would still take approximately 68 years before the max value + of 2147483647 would be reached. + +2.2.3. Time Window + + The Time Window is a value that specifies the window of time in + which a message generated on behalf of any user is valid. This + memo specifies that the same value of the Time Window, 150 seconds, + is used for all users. + +2.3. Time Synchronization + + Time synchronization, required by a non-authoritative SNMP engine + in order to proceed with authentic communications, has occurred + when the non-authoritative SNMP engine has obtained a local notion + of the authoritative SNMP engine's values of snmpEngineBoots and + snmpEngineTime from the authoritative SNMP engine. These values + must be (and remain) within the authoritative SNMP engine's Time + Window. So the local notion of the authoritative SNMP engine's + values must be kept loosely synchronized with the values stored + at the authoritative SNMP engine. In addition to keeping a local + copy of snmpEngineBoots and snmpEngineTime from the authoritative + SNMP engine, a non-authoritative SNMP engine must also keep one + local variable, latestReceivedEngineTime. This value records the + highest value of snmpEngineTime that was received by the + non-authoritative SNMP engine from the authoritative SNMP engine + and is used to eliminate the possibility of replaying messages + that would prevent the non-authoritative SNMP engine's notion of + the snmpEngineTime from advancing. + + A non-authoritative SNMP engine must keep local notions of these + values for each authoritative SNMP engine with which it wishes to + communicate. Since each authoritative SNMP engine is uniquely + and unambiguously identified by its value of snmpEngineID, the + non-authoritative SNMP engine may use this value as a key in + order to cache its local notions of these values. + + Time synchronization occurs as part of the procedures of receiving + an SNMP message (Section 3.2, step 7b). As such, no explicit time + synchronization procedure is required by a non-authoritative SNMP + engine. Note, that whenever the local value of snmpEngineID is + changed (e.g., through discovery) or when secure communications + are first established with an authoritative SNMP engine, the local + + + + + +Blumenthal & Wijnen Standards Track [Page 15] + +RFC 2264 USM for SNMPv3 January 1998 + + + values of snmpEngineBoots and latestReceivedEngineTime should be + set to zero. This will cause the time synchronization to occur + when the next authentic message is received. + +2.4. SNMP Messages Using this Security Model + + The syntax of an SNMP message using this Security Model adheres + to the message format defined in the version-specific Message + Processing Model document (for example [RFC2262]). + + The field msgSecurityParameters in SNMPv3 messages has a data type + of OCTET STRING. Its value is the BER serialization of the + following ASN.1 sequence: + + USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN + + UsmSecurityParameters ::= + SEQUENCE { + -- global User-based security parameters + msgAuthoritativeEngineID OCTET STRING, + msgAuthoritativeEngineBoots INTEGER (0..2147483647), + msgAuthoritativeEngineTime INTEGER (0..2147483647), + msgUserName OCTET STRING (SIZE(1..32)), + -- authentication protocol specific parameters + msgAuthenticationParameters OCTET STRING, + -- privacy protocol specific parameters + msgPrivacyParameters OCTET STRING + } + END + + The fields of this sequence are: + + - The msgAuthoritativeEngineID specifies the snmpEngineID of the + authoritative SNMP engine involved in the exchange of the message. + + - The msgAuthoritativeEngineBoots specifies the snmpEngineBoots + value at the authoritative SNMP engine involved in the exchange of + the message. + + - The msgAuthoritativeEngineTime specifies the snmpEngineTime value + at the authoritative SNMP engine involved in the exchange of the + message. + + - The msgUserName specifies the user (principal) on whose behalf + the message is being exchanged. + + + + + + +Blumenthal & Wijnen Standards Track [Page 16] + +RFC 2264 USM for SNMPv3 January 1998 + + + - The msgAuthenticationParameters are defined by the authentication + protocol in use for the message, as defined by the + usmUserAuthProtocol column in the user's entry in the usmUserTable. + + - The msgPrivacyParameters are defined by the privacy protocol in + use for the message, as defined by the usmUserPrivProtocol column + in the user's entry in the usmUserTable). + + See appendix A.4 for an example of the BER encoding of field + msgSecurityParameters. + +2.5. Services provided by the User-based Security Model + + This section describes the services provided by the User-based + Security Model with their inputs and outputs. + + The services are described as primitives of an abstract service + interface and the inputs and outputs are described as abstract data + elements as they are passed in these abstract service primitives. + +2.5.1. Services for Generating an Outgoing SNMP Message + + When the Message Processing (MP) Subsystem invokes the User-based + Security module to secure an outgoing SNMP message, it must use the + appropriate service as provided by the Security module. These two + services are provided: + + 1) A service to generate a Request message. The abstract service + primitive is: + + statusInformation = -- success or errorIndication + generateRequestMsg( + IN messageProcessingModel -- typically, SNMP version + IN globalData -- message header, admin data + IN maxMessageSize -- of the sending SNMP entity + IN securityModel -- for the outgoing message + IN securityEngineID -- authoritative SNMP entity + IN securityName -- on behalf of this principal + IN securityLevel -- Level of Security requested + IN scopedPDU -- message (plaintext) payload + OUT securityParameters -- filled in by Security Module + OUT wholeMsg -- complete generated message + OUT wholeMsgLength -- length of generated message + ) + + 2) A service to generate a Response message. The abstract service + primitive is: + + + + +Blumenthal & Wijnen Standards Track [Page 17] + +RFC 2264 USM for SNMPv3 January 1998 + + + statusInformation = -- success or errorIndication + generateResponseMsg( + IN messageProcessingModel -- typically, SNMP version + IN globalData -- message header, admin data + IN maxMessageSize -- of the sending SNMP entity + IN securityModel -- for the outgoing message + IN securityEngineID -- authoritative SNMP entity + IN securityName -- on behalf of this principal + IN securityLevel -- Level of Security requested + IN scopedPDU -- message (plaintext) payload + IN securityStateReference -- reference to security state + -- information from original + -- request + OUT securityParameters -- filled in by Security Module + OUT wholeMsg -- complete generated message + OUT wholeMsgLength -- length of generated message + ) + + The abstract data elements passed as parameters in the abstract + service primitives are as follows: + + statusInformation + An indication of whether the encoding and securing of the message + was successful. If not it is an indication of the problem. + essageProcessingModel + The SNMP version number for the message to be generated. This + data is not used by the User-based Security module. + globalData + The message header (i.e., its administrative information). This + data is not used by the User-based Security module. + maxMessageSize + The maximum message size as included in the message. This data is + not used by the User-based Security module. + securityParameters + These are the security parameters. They will be filled in by the + User-based Security module. + securityModel + The securityModel in use. Should be User-based Security Model. + This data is not used by the User-based Security module. + securityName + Together with the snmpEngineID it identifies a row in the + usmUserTable that is to be used for securing the message. The + securityName has a format that is independent of the Security + Model. In case of a response this parameter is ignored and the + value from the cache is used. + securityLevel + The Level of Security from which the User-based Security module + determines if the message needs to be protected from disclosure + + + +Blumenthal & Wijnen Standards Track [Page 18] + +RFC 2264 USM for SNMPv3 January 1998 + + + and if the message needs to be authenticated. In case of a + response this parameter is ignored and the value from the cache is + used. + securityEngineID + The snmpEngineID of the authoritative SNMP engine to which a + Request message is to be sent. In case of a response it is implied + to be the processing SNMP engine's snmpEngineID and so if it is + specified, then it is ignored. + scopedPDU + The message payload. The data is opaque as far as the User-based + Security Model is concerned. + securityStateReference + A handle/reference to cachedSecurityData to be used when securing + an outgoing Response message. This is the exact same + handle/reference as it was generated by the User-based Security + module when processing the incoming Request message to which this + is the Response message. + wholeMsg + The fully encoded and secured message ready for sending on the + wire. + wholeMsgLength + The length of the encoded and secured message (wholeMsg). + + Upon completion of the process, the User-based Security module + returns statusInformation. If the process was successful, the + completed message with privacy and authentication applied if such was + requested by the specified securityLevel is returned. If the process + was not successful, then an errorIndication is returned. + +2.5.2. Services for Processing an Incoming SNMP Message + + When the Message Processing (MP) Subsystem invokes the User-based + Security module to verify proper security of an incoming message, it + must use the service provided for an incoming message. The abstract + service primitive is: + + statusInformation = -- errorIndication or success + -- error counter OID/value if error + processIncomingMsg( + IN messageProcessingModel -- typically, SNMP version + IN maxMessageSize -- of the sending SNMP entity + IN securityParameters -- for the received message + IN securityModel -- for the received message + IN securityLevel -- Level of Security + IN wholeMsg -- as received on the wire + IN wholeMsgLength -- length as received on the wire + OUT securityEngineID -- authoritative SNMP entity + OUT securityName -- identification of the principal + + + +Blumenthal & Wijnen Standards Track [Page 19] + +RFC 2264 USM for SNMPv3 January 1998 + + + OUT scopedPDU, -- message (plaintext) payload + OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU + OUT securityStateReference -- reference to security state + ) -- information, needed for response + + The abstract data elements passed as parameters in the abstract + service primitives are as follows: + + statusInformation + An indication of whether the process was successful or not. If + not, then the statusInformation includes the OID and the value of + the error counter that was incremented. + messageProcessingModel + The SNMP version number as received in the message. This data is + not used by the User-based Security module. + maxMessageSize + The maximum message size as included in the message. The User- + based Security module uses this value to calculate the + maxSizeResponseScopedPDU. + securityParameters + These are the security parameters as received in the message. + securityModel + The securityModel in use. Should be the User-based Security + Model. This data is not used by the User-based Security module. + securityLevel + The Level of Security from which the User-based Security module + determines if the message needs to be protected from disclosure + and if the message needs to be authenticated. + wholeMsg + The whole message as it was received. + wholeMsgLength + The length of the message as it was received (wholeMsg). + securityEngineID + The snmpEngineID that was extracted from the field + msgAuthoritativeEngineID and that was used to lookup the secrets + in the usmUserTable. + securityName + The security name representing the user on whose behalf the + message was received. The securityName has a format that is + independent of the Security Model. + scopedPDU + The message payload. The data is opaque as far as the User-based + Security Model is concerned. + maxSizeResponseScopedPDU + The maximum size of a scopedPDU to be included in a possible + Response message. The User-base Security module calculates + + + + + +Blumenthal & Wijnen Standards Track [Page 20] + +RFC 2264 USM for SNMPv3 January 1998 + + + this size based on the mms (as received in the message) and the + space required for the message header (including the + securityParameters) for such a Response message. + securityStateReference + A handle/reference to cachedSecurityData to be used when securing + an outgoing Response message. When the Message Processing + Subsystem calls the User-based Security module to generate a + response to this incoming message it must pass this + handle/reference. + + Upon completion of the process, the User-based Security module + returns statusInformation and, if the process was successful, the + additional data elements for further processing of the message. If + the process was not successful, then an errorIndication, possibly + with a OID and value pair of an error counter that was incremented. + +2.6. Key Localization Algorithm. + + A localized key is a secret key shared between a user U and one + authoritative SNMP engine E. Even though a user may have only one + password and therefore one key for the whole network, the actual + secrets shared between the user and each authoritative SNMP engine + will be different. This is achieved by key localization [Localized- + key]. + + First, if a user uses a password, then the user's password is + converted into a key Ku using one of the two algorithms described in + Appendices A.2.1 and A.2.2. + + To convert key Ku into a localized key Kul of user U at the + authoritative SNMP engine E, one appends the snmpEngineID of the + authoritative SNMP engine to the key Ku and then appends the key Ku + to the result, thus enveloping the snmpEngineID within the two copies + of user's key Ku. Then one runs a secure hash function (which one + depends on the authentication protocol defined for this user U at + authoritative SNMP engine E; this document defines two authentication + protocols with their associated algorithms based on MD5 and SHA). The + output of the hash-function is the localized key Kul for user U at + the authoritative SNMP engine E. + +3. Elements of Procedure + + This section describes the security related procedures followed by an + SNMP engine when processing SNMP messages according to the User-based + Security Model. + + + + + + +Blumenthal & Wijnen Standards Track [Page 21] + +RFC 2264 USM for SNMPv3 January 1998 + + +3.1. Generating an Outgoing SNMP Message + + This section describes the procedure followed by an SNMP engine + whenever it generates a message containing a management operation + (like a request, a response, a notification, or a report) on behalf + of a user, with a particular securityLevel. + + 1) a) If any securityStateReference is passed (Response message), + then information concerning the user is extracted from the + cachedSecurityData. The securityEngineID and the + securityLevel are extracted from the cachedSecurityData. The + cachedSecurityData can now be discarded. + + Otherwise, + + b) based on the securityName, information concerning the + user at the destination snmpEngineID, specified by the + securityEngineID, is extracted from the Local Configuration + Datastore (LCD, usmUserTable). If information about the user + is absent from the LCD, then an error indication + (unknownSecurityName) is returned to the calling module. + + 2) If the securityLevel specifies that the message is to be + protected from disclosure, but the user does not support both an + authentication and a privacy protocol then the message cannot be + sent. An error indication (unsupportedSecurityLevel) is returned + to the calling module. + + 3) If the securityLevel specifies that the message is to be + authenticated, but the user does not support an authentication + protocol, then the message cannot be sent. An error indication + (unsupportedSecurityLevel) is returned to the calling module. + + 4) a) If the securityLevel specifies that the message is to be + protected from disclosure, then the octet sequence + representing the serialized scopedPDU is encrypted according + to the user's privacy protocol. To do so a call is made to the + privacy module that implements the user's privacy protocol + according to the abstract primitive: + + statusInformation = -- success or failure + encryptData( + IN encryptKey -- user's localized privKey + IN dataToEncrypt -- serialized scopedPDU + OUT encryptedData -- serialized encryptedPDU + OUT privParameters -- serialized privacy parameters + ) + + + + +Blumenthal & Wijnen Standards Track [Page 22] + +RFC 2264 USM for SNMPv3 January 1998 + + + statusInformation + indicates if the encryption process was successful or not. + encryptKey + the user's localized private privKey is the secret key that + can be used by the encryption algorithm. + dataToEncrypt + the serialized scopedPDU is the data that to be encrypted. + encryptedData + the encryptedPDU represents the encrypted scopedPDU, + encoded as an OCTET STRING. + privParameters + the privacy parameters, encoded as an OCTET STRING. + + If the privacy module returns failure, then the message cannot + be sent and an error indication (encryptionError) is returned + to the calling module. + + If the privacy module returns success, then the returned + privParameters are put into the msgPrivacyParameters field of + the securityParameters and the encryptedPDU serves as the + payload of the message being prepared. + + Otherwise, + + b) If the securityLevel specifies that the message is not to be + protected from disclosure, then the NULL string is encoded as + an OCTET STRING and put into the msgPrivacyParameters field of + the securityParameters and the plaintext scopedPDU serves as + the payload of the message being prepared. + + 5) The snmpEngineID is encoded as an OCTET STRING into the + msgAuthoritativeEngineID field of the securityParameters. Note + that an empty (zero length) snmpEngineID is OK for a Request + message, because that will cause the remote (authoritative) SNMP + engine to return a Report PDU with the proper snmpEngineID + included in the msgAuthoritativeEngineID in the + securityParameters of that returned Report PDU. + + 6) a) If the securityLevel specifies that the message is to be + authenticated, then the current values of snmpEngineBoots and + snmpEngineTime corresponding to the snmpEngineID from the LCD + are used. + + Otherwise, + + b) If this is a Response message, then the current value of + snmpEngineBoots and snmpEngineTime corresponding to the local + snmpEngineID from the LCD are used. + + + +Blumenthal & Wijnen Standards Track [Page 23] + +RFC 2264 USM for SNMPv3 January 1998 + + + Otherwise, + + c) If this is a Request message, then a zero value is used + for both snmpEngineBoots and snmpEngineTime. This zero value + gets used if snmpEngineID is empty. + + The values are encoded as INTEGER respectively into the + msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields + of the securityParameters. + + 7) The userName is encoded as an OCTET STRING into the msgUserName + field of the securityParameters. + + 8) a) If the securityLevel specifies that the message is to be + authenticated, the message is authenticated according to the + user's authentication protocol. To do so a call is made to the + authentication module that implements the user's + authentication protocol according to the abstract service + primitive: + + statusInformation = + authenticateOutgoingMsg( + IN authKey -- the user's localized authKey + IN wholeMsg -- unauthenticated message + OUT authenticatedWholeMsg -- authenticated complete message + ) + + statusInformation + indicates if authentication was successful or not. + authKey + the user's localized private authKey is the secret key that + can be used by the authentication algorithm. + wholeMsg + the complete serialized message to be authenticated. + authenticatedWholeMsg + the same as the input given to the authenticateOutgoingMsg + service, but with msgAuthenticationParameters properly + filled in. + + If the authentication module returns failure, then the message + cannot be sent and an error indication (authenticationFailure) + is returned to the calling module. + + If the authentication module returns success, then the + msgAuthenticationParameters field is put into the + securityParameters and the authenticatedWholeMsg represents + the serialization of the authenticated message being prepared. + + + + +Blumenthal & Wijnen Standards Track [Page 24] + +RFC 2264 USM for SNMPv3 January 1998 + + + Otherwise, + + b) If the securityLevel specifies that the message is not to + be authenticated then the NULL string is encoded as an OCTET + STRING into the msgAuthenticationParameters field of the + securityParameters. The wholeMsg is now serialized and then + represents the unauthenticated message being prepared. + + 9) The completed message with its length is returned to the + calling module with the statusInformation set to success. + +3.2. Processing an Incoming SNMP Message + + This section describes the procedure followed by an SNMP engine + whenever it receives a message containing a management operation on + behalf of a user, with a particular securityLevel. + + To simplify the elements of procedure, the release of state + information is not always explicitly specified. As a general rule, if + state information is available when a message gets discarded, the + state information should also be released. Also, when an error + indication with an OID and value for an incremented counter is + returned, then the available information (like + securityStateReference) must be passed back to the caller so it can + generate a Report PDU. + + 1) If the received securityParameters is not the serialization + (according to the conventions of [RFC1906]) of an OCTET STRING + formatted according to the UsmSecurityParameters defined in + section 2.4, then the snmpInASNParseErrs counter [RFC1907] is + incremented, and an error indication (parseError) is returned to + the calling module. Note that we return without the OID and + value of the incremented counter, because in this case there is + not enough information to generate a Report PDU. + + 2) The values of the security parameter fields are extracted from + the securityParameters. The securityEngineID to be returned to + the caller is the value of the msgAuthoritativeEngineID field. + The cachedSecurityData is prepared and a securityStateReference + is prepared to reference this data. Values to be cached are: + + msgUserName + securityEngineID + securityLevel + + 3) If the value of the msgAuthoritativeEngineID field in the + securityParameters is unknown then: + + + + +Blumenthal & Wijnen Standards Track [Page 25] + +RFC 2264 USM for SNMPv3 January 1998 + + + a) a non-authoritative SNMP engine that performs discovery may + optionally create a new entry in its Local Configuration + Datastore (LCD) and continue processing; + + or + + b) the usmStatsUnknownEngineIDs counter is incremented, and + an error indication (unknownEngineID) together with the + OID and value of the incremented counter is returned to + the calling module. + + 4) Information about the value of the msgUserName and + msgAuthoritativeEngineID fields is extracted from the Local + Configuration Datastore (LCD, usmUserTable). If no information + is available for the user, then the usmStatsUnknownUserNames + counter is incremented and an error indication + (unknownSecurityName) together with the OID and value of the + incremented counter is returned to the calling module. + + 5) If the information about the user indicates that it does not + support the securityLevel requested by the caller, then the + usmStatsUnsupportedSecLevels counter is incremented and an + error indication (unsupportedSecurityLevel) together with the + OID and value of the incremented counter is returned to the + calling module. + + 6) If the securityLevel specifies that the message is to be + authenticated, then the message is authenticated according to + the user's authentication protocol. To do so a call is made + to the authentication module that implements the user's + authentication protocol according to the abstract service + primitive: + + statusInformation = -- success or failure + authenticateIncomingMsg( + IN authKey -- the user's localized authKey + IN authParameters -- as received on the wire + IN wholeMsg -- as received on the wire + OUT authenticatedWholeMsg -- checked for authentication + ) + + statusInformation + indicates if authentication was successful or not. + authKey + the user's localized private authKey is the secret key that + can be used by the authentication algorithm. + wholeMsg + the complete serialized message to be authenticated. + + + +Blumenthal & Wijnen Standards Track [Page 26] + +RFC 2264 USM for SNMPv3 January 1998 + + + authenticatedWholeMsg + the same as the input given to the authenticateIncomingMsg + service, but after authentication has been checked. + + If the authentication module returns failure, then the message + cannot be trusted, so the usmStatsWrongDigests counter is + incremented and an error indication (authenticationFailure) + together with the OID and value of the incremented counter is + returned to the calling module. + + If the authentication module returns success, then the message + is authentic and can be trusted so processing continues. + + 7) If the securityLevel indicates an authenticated message, then + the local values of snmpEngineBoots and snmpEngineTime + corresponding to the value of the msgAuthoritativeEngineID + field are extracted from the Local Configuration Datastore. + + a) If the extracted value of msgAuthoritativeEngineID is the + same as the value of snmpEngineID of the processing SNMP + engine (meaning this is the authoritative SNMP engine), + then if any of the following conditions is true, then the + message is considered to be outside of the Time Window: + + - the local value of snmpEngineBoots is 2147483647; + + - the value of the msgAuthoritativeEngineBoots field differs + from the local value of snmpEngineBoots; or, + + - the value of the msgAuthoritativeEngineTime field differs + from the local notion of snmpEngineTime by more than + +/- 150 seconds. + + If the message is considered to be outside of the Time Window + then the usmStatsNotInTimeWindows counter is incremented and + an error indication (notInTimeWindow) together with the OID + and value of the incremented counter is returned to the + calling module. + + b) If the extracted value of msgAuthoritativeEngineID is not the + same as the value snmpEngineID of the processing SNMP engine + (meaning this is not the authoritative SNMP engine), then: + + 1) if at least one of the following conditions is true: + + - the extracted value of the msgAuthoritativeEngineBoots + field is greater than the local notion of the value of + snmpEngineBoots; or, + + + +Blumenthal & Wijnen Standards Track [Page 27] + +RFC 2264 USM for SNMPv3 January 1998 + + + - the extracted value of the msgAuthoritativeEngineBoots + field is equal to the local notion of the value of + snmpEngineBoots, the extracted value of + msgAuthoritativeEngineTime field is greater than the + value of latestReceivedEngineTime, + + then the LCD entry corresponding to the extracted value + of the msgAuthoritativeEngineID field is updated, by + setting: + + - the local notion of the value of snmpEngineBoots to + the value of the msgAuthoritativeEngineBoots field, + - the local notion of the value of snmpEngineTime to + the value of the msgAuthoritativeEngineTime field, + and + - the latestReceivedEngineTime to the value of the + value of the msgAuthoritativeEngineTime field. + + 2) if any of the following conditions is true, then the + message is considered to be outside of the Time Window: + + - the local notion of the value of snmpEngineBoots is + 2147483647; + + - the value of the msgAuthoritativeEngineBoots field is + less than the local notion of the value of + snmpEngineBoots; or, + + - the value of the msgAuthoritativeEngineBoots field is + equal to the local notion of the value of + snmpEngineBoots and the value of the + msgAuthoritativeEngineTime field is more than 150 + seconds less than the local notion of of the value of + snmpEngineTime. + + If the message is considered to be outside of the Time + Window then an error indication (notInTimeWindow) is + returned to the calling module; + + Note that this means that a too old (possibly replayed) + message has been detected and is deemed unauthentic. + + Note that this procedure allows for the value of + msgAuthoritativeEngineBoots in the message to be greater + than the local notion of the value of snmpEngineBoots to + allow for received messages to be accepted as authentic + + + + + +Blumenthal & Wijnen Standards Track [Page 28] + +RFC 2264 USM for SNMPv3 January 1998 + + + when received from an authoritative SNMP engine that has + re-booted since the receiving SNMP engine last + (re-)synchronized. + + Note that this procedure does not allow for automatic + time synchronization if the non-authoritative SNMP engine + has a real out-of-sync situation whereby the authoritative + SNMP engine is more than 150 seconds behind the + non-authoritative SNMP engine. + + 8) a) If the securityLevel indicates that the message was protected + from disclosure, then the OCTET STRING representing the + encryptedPDU is decrypted according to the user's privacy + protocol to obtain an unencrypted serialized scopedPDU value. + To do so a call is made to the privacy module that implements + the user's privacy protocol according to the abstract + primitive: + + statusInformation = -- success or failure + decryptData( + IN decryptKey -- the user's localized privKey + IN privParameters -- as received on the wire + IN encryptedData -- encryptedPDU as received + OUT decryptedData -- serialized decrypted scopedPDU + ) + + statusInformation + indicates if the decryption process was successful or not. + decryptKey + the user's localized private privKey is the secret key that + can be used by the decryption algorithm. + privParameters + the msgPrivacyParameters, encoded as an OCTET STRING. + encryptedData + the encryptedPDU represents the encrypted scopedPDU, encoded + as an OCTET STRING. + decryptedData + the serialized scopedPDU if decryption is successful. + + If the privacy module returns failure, then the message can + not be processed, so the usmStatsDecryptionErrors counter is + incremented and an error indication (decryptionError) together + with the OID and value of the incremented counter is returned + to the calling module. + + If the privacy module returns success, then the decrypted + scopedPDU is the message payload to be returned to the calling + module. + + + +Blumenthal & Wijnen Standards Track [Page 29] + +RFC 2264 USM for SNMPv3 January 1998 + + + Otherwise, + + b) The scopedPDU component is assumed to be in plain text + and is the message payload to be returned to the calling + module. + + 9) The maxSizeResponseScopedPDU is calculated. This is the + maximum size allowed for a scopedPDU for a possible Response + message. Provision is made for a message header that allows the + same securityLevel as the received Request. + + 10) The securityName for the user is retrieved from the + usmUserTable. + + 11) The security data is cached as cachedSecurityData, so that a + possible response to this message can and will use the same + authentication and privacy secrets, the same securityLevel and + the same value for msgAuthoritativeEngineID. Information to be + saved/cached is as follows: + + msgUserName, + usmUserAuthProtocol, usmUserAuthKey + usmUserPrivProtocol, usmUserPrivKey + securityEngineID, securityLevel + + 12) The statusInformation is set to success and a return is made to + the calling module passing back the OUT parameters as specified + in the processIncomingMsg primitive. + +4. Discovery + + The User-based Security Model requires that a discovery process + obtains sufficient information about other SNMP engines in order to + communicate with them. Discovery requires an non-authoritative SNMP + engine to learn the authoritative SNMP engine's snmpEngineID value + before communication may proceed. This may be accomplished by + generating a Request message with a securityLevel of noAuthNoPriv, a + msgUserName of "initial", a msgAuthoritativeEngineID value of zero + length, and the varBindList left empty. The response to this message + will be a Report message containing the snmpEngineID of the + authoritative SNMP engine as the value of the + msgAuthoritativeEngineID field within the msgSecurityParameters + field. It contains a Report PDU with the usmStatsUnknownEngineIDs + counter in the varBindList. + + If authenticated communication is required, then the discovery + process should also establish time synchronization with the + authoritative SNMP engine. This may be accomplished by sending an + + + +Blumenthal & Wijnen Standards Track [Page 30] + +RFC 2264 USM for SNMPv3 January 1998 + + + authenticated Request message with the value of + msgAuthoritativeEngineID set to the newly learned snmpEngineID and + with the values of msgAuthoritativeEngineBoots and + msgAuthoritativeEngineTime set to zero. The response to this + authenticated message will be a Report message containing the up to + date values of the authoritative SNMP engine's snmpEngineBoots and + snmpEngineTime as the value of the msgAuthoritativeEngineBoots and + msgAuthoritativeEngineTime fields respectively. It also contains the + usmStatsNotInTimeWindows counter in the varBindList of the Report + PDU. The time synchronization then happens automatically as part of + the procedures in section 3.2 step 7b. See also section 2.3. + +5. Definitions + +SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, + OBJECT-IDENTITY, + snmpModules, Counter32 FROM SNMPv2-SMI + TEXTUAL-CONVENTION, TestAndIncr, + RowStatus, RowPointer, + StorageType, AutonomousType FROM SNMPv2-TC + MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF + SnmpAdminString, SnmpEngineID, + snmpAuthProtocols, snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; + +snmpUsmMIB MODULE-IDENTITY + LAST-UPDATED "9711200000Z" -- 20 Nov 1997, midnight + ORGANIZATION "SNMPv3 Working Group" + CONTACT-INFO "WG-email: snmpv3@tis.com + Subscribe: majordomo@tis.com + In msg body: subscribe snmpv3 + + Chair: Russ Mundy + Trusted Information Systems + postal: 3060 Washington Rd + Glenwood MD 21738 + USA + email: mundy@tis.com + phone: +1-301-854-6889 + + Co-editor Uri Blumenthal + IBM T. J. Watson Research + postal: 30 Saw Mill River Pkwy, + Hawthorne, NY 10532 + USA + email: uri@watson.ibm.com + + + +Blumenthal & Wijnen Standards Track [Page 31] + +RFC 2264 USM for SNMPv3 January 1998 + + + phone: +1-914-784-7964 + + Co-editor: Bert Wijnen + IBM T. J. Watson Research + postal: Schagen 33 + 3461 GL Linschoten + Netherlands + email: wijnen@vnet.ibm.com + phone: +31-348-432-794 + " + + DESCRIPTION "The management information definitions for the + SNMP User-based Security Model. + " + ::= { snmpModules 4 } + +-- Administrative assignments **************************************** + +usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 } +usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 } + +-- Identification of Authentication and Privacy Protocols ************ + +usmNoAuthProtocol OBJECT-IDENTITY + STATUS current + DESCRIPTION "No Authentication Protocol." + ::= { snmpAuthProtocols 1 } + +usmHMACMD5AuthProtocol OBJECT-IDENTITY + STATUS current + DESCRIPTION "The HMAC-MD5-96 Digest Authentication Protocol." + REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti HMAC: + Keyed-Hashing for Message Authentication, + RFC2104, Feb 1997. + - Rivest, R., Message Digest Algorithm MD5, RFC1321. + " + ::= { snmpAuthProtocols 2 } + +usmHMACSHAAuthProtocol OBJECT-IDENTITY + STATUS current + DESCRIPTION "The HMAC-SHA-96 Digest Authentication Protocol." + REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti, HMAC: + Keyed-Hashing for Message Authentication, + RFC2104, Feb 1997. + - Secure Hash Algorithm. NIST FIPS 180-1. + " + ::= { snmpAuthProtocols 3 } + + + + +Blumenthal & Wijnen Standards Track [Page 32] + +RFC 2264 USM for SNMPv3 January 1998 + + +usmNoPrivProtocol OBJECT-IDENTITY + STATUS current + DESCRIPTION "No Privacy Protocol." + ::= { snmpPrivProtocols 1 } + +usmDESPrivProtocol OBJECT-IDENTITY + STATUS current + DESCRIPTION "The CBC-DES Symmetric Encryption Protocol." + REFERENCE "- Data Encryption Standard, National Institute of + Standards and Technology. Federal Information + Processing Standard (FIPS) Publication 46-1. + Supersedes FIPS Publication 46, + (January, 1977; reaffirmed January, 1988). + + - Data Encryption Algorithm, American National + Standards Institute. ANSI X3.92-1981, + (December, 1980). + + - DES Modes of Operation, National Institute of + Standards and Technology. Federal Information + Processing Standard (FIPS) Publication 81, + (December, 1980). + + - Data Encryption Algorithm - Modes of Operation, + American National Standards Institute. + ANSI X3.106-1983, (May 1983). + " + ::= { snmpPrivProtocols 2 } + + +-- Textual Conventions *********************************************** + + +KeyChange ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Every definition of an object with this syntax must identify + a protocol P, a secret key K, and a hash algorithm H + that produces output of L octets. + + The object's value is a manager-generated, partially-random + value which, when modified, causes the value of the secret + key K, to be modified via a one-way function. + + The value of an instance of this object is the concatenation + of two components: first a 'random' component and then a + 'delta' component. + + + + +Blumenthal & Wijnen Standards Track [Page 33] + +RFC 2264 USM for SNMPv3 January 1998 + + + The lengths of the random and delta components + are given by the corresponding value of the protocol P; + if P requires K to be a fixed length, the length of both the + random and delta components is that fixed length; if P + allows the length of K to be variable up to a particular + maximum length, the length of the random component is that + maximum length and the length of the delta component is any + length less than or equal to that maximum length. + For example, usmHMACMD5AuthProtocol requires K to be a fixed + length of 16 octets and L - of 16 octets. + usmHMACSHAAuthProtocol requires K to be a fixed length of + 20 octets and L - of 20 octets. Other protocols may define + other sizes, as deemed appropriate. + + When a requestor wants to change the old key K to a new + key keyNew on a remote entity, the 'random' component is + obtained from either a true random generator, or from a + pseudorandom generator, and the 'delta' component is + computed as follows: + + - a temporary variable is initialized to the existing value + of K; + - if the length of the keyNew is greater than L octets, + then: + - the random component is appended to the value of the + temporary variable, and the result is input to the + the hash algorithm H to produce a digest value, and + the temporary variable is set to this digest value; + - the value of the temporary variable is XOR-ed with + the first (next) L-octets (16 octets in case of MD5) + of the keyNew to produce the first (next) L-octets + (16 octets in case of MD5) of the 'delta' component. + - the above two steps are repeated until the unused + portion of the delta component is L octets or less, + - the random component is appended to the value of the + temporary variable, and the result is input to the + hash algorithm H to produce a digest value; + - this digest value, truncated if necessary to be the same + length as the unused portion of the keyNew, is XOR-ed + with the unused portion of the keyNew to produce the + (final portion of the) 'delta' component. + + For example, using MD5 as the hash algorithm H: + + iterations = (lenOfDelta - 1)/16; /* integer division */ + temp = keyOld; + for (i = 0; i < iterations; i++) { + temp = MD5 (temp || random); + + + +Blumenthal & Wijnen Standards Track [Page 34] + +RFC 2264 USM for SNMPv3 January 1998 + + + delta[i*16 .. (i*16)+15] = + temp XOR keyNew[i*16 .. (i*16)+15]; + } + temp = MD5 (temp || random); + delta[i*16 .. lenOfDelta-1] = + temp XOR keyNew[i*16 .. lenOfDelta-1]; + + The 'random' and 'delta' components are then concatenated as + described above, and the resulting octet string is sent to + the receipient as the new value of an instance of this + object. + + At the receiver side, when an instance of this object is set + to a new value, then a new value of K is computed as follows: + + - a temporary variable is initialized to the existing value + of K; + - if the length of the delta component is greater than L + octets, then: + - the random component is appended to the value of the + temporary variable, and the result is input to the + the hash algorithm H to produce a digest value, and + the temporary variable is set to this digest value; + - the value of the temporary variable is XOR-ed with + the first (next) L-octets (16 octets in case of MD5) + of the delta component to produce the first (next) + L-octets (16 octets in case of MD5) of the new value + of K. + - the above two steps are repeated until the unused + portion of the delta component is L octets or less, + - the random component is appended to the value of the + temporary variable, and the result is input to the + hash algorithm H to produce a digest value; + - this digest value, truncated if necessary to be the same + length as the unused portion of the delta component, is + XOR-ed with the unused portion of the delta component to + produce the (final portion of the) new value of K. + + For example, using MD5 as the hash algorithm H: + + iterations = (lenOfDelta - 1)/16; /* integer division */ + temp = keyOld; + for (i = 0; i < iterations; i++) { + temp = MD5 (temp || random); + keyNew[i*16 .. (i*16)+15] = + temp XOR delta[i*16 .. (i*16)+15]; + } + temp = MD5 (temp || random); + + + +Blumenthal & Wijnen Standards Track [Page 35] + +RFC 2264 USM for SNMPv3 January 1998 + + + keyNew[i*16 .. lenOfDelta-1] = + temp XOR delta[i*16 .. lenOfDelta-1]; + + The value of an object with this syntax, whenever it is + retrieved by the management protocol, is always the zero + length string. + " + SYNTAX OCTET STRING + + +-- Statistics for the User-based Security Model ********************** + + +usmStats OBJECT IDENTIFIER ::= { usmMIBObjects 1 } + + +usmStatsUnsupportedSecLevels OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The total number of packets received by the SNMP + engine which were dropped because they requested a + securityLevel that was unknown to the SNMP engine + or otherwise unavailable. + " + ::= { usmStats 1 } + +usmStatsNotInTimeWindows OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The total number of packets received by the SNMP + engine which were dropped because they appeared + outside of the authoritative SNMP engine's window. + " + ::= { usmStats 2 } + +usmStatsUnknownUserNames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The total number of packets received by the SNMP + engine which were dropped because they referenced a + user that was not known to the SNMP engine. + " + ::= { usmStats 3 } + +usmStatsUnknownEngineIDs OBJECT-TYPE + + + +Blumenthal & Wijnen Standards Track [Page 36] + +RFC 2264 USM for SNMPv3 January 1998 + + + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The total number of packets received by the SNMP + engine which were dropped because they referenced an + snmpEngineID that was not known to the SNMP engine. + " + ::= { usmStats 4 } + +usmStatsWrongDigests OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The total number of packets received by the SNMP + engine which were dropped because they didn't + contain the expected digest value. + " + ::= { usmStats 5 } + +usmStatsDecryptionErrors OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The total number of packets received by the SNMP + engine which were dropped because they could not be + decrypted. + " + ::= { usmStats 6 } + +-- The usmUser Group ************************************************ + +usmUser OBJECT IDENTIFIER ::= { usmMIBObjects 2 } + +usmUserSpinLock OBJECT-TYPE + SYNTAX TestAndIncr + MAX-ACCESS read-write + STATUS current + DESCRIPTION "An advisory lock used to allow several cooperating + Command Generator Applications to coordinate their + use of facilities to alter secrets in the + usmUserTable. + " + ::= { usmUser 1 } + +-- The table of valid users for the User-based Security Model ******** + +usmUserTable OBJECT-TYPE + SYNTAX SEQUENCE OF UsmUserEntry + + + +Blumenthal & Wijnen Standards Track [Page 37] + +RFC 2264 USM for SNMPv3 January 1998 + + + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "The table of users configured in the SNMP engine's + Local Configuration Datastore (LCD)." + ::= { usmUser 2 } + +usmUserEntry OBJECT-TYPE + SYNTAX UsmUserEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "A user configured in the SNMP engine's Local + Configuration Datastore (LCD) for the User-based + Security Model. + " + INDEX { usmUserEngineID, + usmUserName + } + ::= { usmUserTable 1 } + +UsmUserEntry ::= SEQUENCE + { + usmUserEngineID SnmpEngineID, + usmUserName SnmpAdminString, + usmUserSecurityName SnmpAdminString, + usmUserCloneFrom RowPointer, + usmUserAuthProtocol AutonomousType, + usmUserAuthKeyChange KeyChange, + usmUserOwnAuthKeyChange KeyChange, + usmUserPrivProtocol AutonomousType, + usmUserPrivKeyChange KeyChange, + usmUserOwnPrivKeyChange KeyChange, + usmUserPublic OCTET STRING, + usmUserStorageType StorageType, + usmUserStatus RowStatus + } + +usmUserEngineID OBJECT-TYPE + SYNTAX SnmpEngineID + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "An SNMP engine's administratively-unique identifier. + + In a simple agent, this value is always that agent's + own snmpEngineID value. + + The value can also take the value of the snmpEngineID + of a remote SNMP engine with which this user can + communicate. + + + +Blumenthal & Wijnen Standards Track [Page 38] + +RFC 2264 USM for SNMPv3 January 1998 + + + " + ::= { usmUserEntry 1 } + +usmUserName OBJECT-TYPE + SYNTAX SnmpAdminString (SIZE(1..32)) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION "A human readable string representing the name of + the user. + + This is the (User-based Security) Model dependent + security ID. + " + ::= { usmUserEntry 2 } + +usmUserSecurityName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION "A human readable string representing the user in + Security Model independent format. + + The default transformation of the User-based Security + Model dependent security ID to the securityName and + vice versa is the identity function so that the + securityName is the same as the userName. + " + ::= { usmUserEntry 3 } + +usmUserCloneFrom OBJECT-TYPE + SYNTAX RowPointer + MAX-ACCESS read-create + STATUS current + DESCRIPTION "A pointer to another conceptual row in this + usmUserTable. The user in this other conceptual + row is called the clone-from user. + + When a new user is created (i.e., a new conceptual + row is instantiated in this table), the privacy and + authentication parameters of the new user are cloned + from its clone-from user. + + The first time an instance of this object is set by + a management operation (either at or after its + instantiation), the cloning process is invoked. + Subsequent writes are successful but invoke no + action to be taken by the receiver. + The cloning process fails with an 'inconsistentName' + + + +Blumenthal & Wijnen Standards Track [Page 39] + +RFC 2264 USM for SNMPv3 January 1998 + + + error if the conceptual row representing the + clone-from user is not in an active state when the + cloning process is invoked. + + Cloning also causes the initial values of the secret + authentication key and the secret encryption key of + the new user to be set to the same value as the + corresponding secret of the clone-from user. + + When this object is read, the ZeroDotZero OID + is returned. + " + ::= { usmUserEntry 4 } + +usmUserAuthProtocol OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-create + STATUS current + DESCRIPTION "An indication of whether messages sent on behalf of + this user to/from the SNMP engine identified by + usmUserEngineID, can be authenticated, and if so, + the type of authentication protocol which is used. + + An instance of this object is created concurrently + with the creation of any other object instance for + the same user (i.e., as part of the processing of + the set operation which creates the first object + instance in the same conceptual row). Once created, + the value of an instance of this object can not be + changed. + + If a set operation tries to set a value for an unknown + or unsupported protocol, then a wrongValue error must + be returned. + " + DEFVAL { usmHMACMD5AuthProtocol } + ::= { usmUserEntry 5 } + +usmUserAuthKeyChange OBJECT-TYPE + SYNTAX KeyChange -- typically (SIZE (0..32)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION "An object, which when modified, causes the secret + authentication key used for messages sent on behalf + of this user to/from the SNMP engine identified by + usmUserEngineID, to be modified via a one-way + function. + + + + +Blumenthal & Wijnen Standards Track [Page 40] + +RFC 2264 USM for SNMPv3 January 1998 + + + The associated protocol is the usmUserAuthProtocol. + The associated secret key is the user's secret + authentication key (authKey). The associated hash + algorithm is the algorithm used by the user's + usmUserAuthProtocol. + + When creating a new user, it is an 'inconsistentName' + error for a Set operation to refer to this object + unless it is previously or concurrently initialized + through a set operation on the corresponding value + of usmUserCloneFrom. + " + DEFVAL { ''H } -- the empty string + ::= { usmUserEntry 6 } + +usmUserOwnAuthKeyChange OBJECT-TYPE + SYNTAX KeyChange -- typically (SIZE (0..32)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one + notable difference: in order for the Set operation + to succeed, the usmUserName of the operation + requester must match the usmUserName that + indexes the row which is targeted by this + operation. + + The idea here is that access to this column can be + public, since it will only allow a user to change + his own secret authentication key (authKey). + " + DEFVAL { ''H } -- the empty string + ::= { usmUserEntry 7 } + +usmUserPrivProtocol OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-create + STATUS current + DESCRIPTION "An indication of whether messages sent on behalf of + this user to/from the SNMP engine identified by + usmUserEngineID, can be protected from disclosure, + and if so, the type of privacy protocol which is used. + + An instance of this object is created concurrently + with the creation of any other object instance for + the same user (i.e., as part of the processing of + the set operation which creates the first object + instance in the same conceptual row). Once created, + the value of an instance of this object can not be + + + +Blumenthal & Wijnen Standards Track [Page 41] + +RFC 2264 USM for SNMPv3 January 1998 + + + changed. + + If a set operation tries to set a value for an unknown + or unsupported protocol, then a wrongValue error must + be returned. + " + DEFVAL { usmNoPrivProtocol } + ::= { usmUserEntry 8 } + +usmUserPrivKeyChange OBJECT-TYPE + SYNTAX KeyChange -- typically (SIZE (0..32)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION "An object, which when modified, causes the secret + encryption key used for messages sent on behalf + of this user to/from the SNMP engine identified by + usmUserEngineID, to be modified via a one-way + function. + + The associated protocol is the usmUserPrivProtocol. + The associated secret key is the user's secret + privacy key (privKey). The associated hash + algorithm is the algorithm used by the user's + usmUserAuthProtocol. + + When creating a new user, it is an 'inconsistentName' + error for a set operation to refer to this object + unless it is previously or concurrently initialized + through a set operation on the corresponding value + of usmUserCloneFrom. + " + DEFVAL { ''H } -- the empty string + ::= { usmUserEntry 9 } + +usmUserOwnPrivKeyChange OBJECT-TYPE + SYNTAX KeyChange -- typically (SIZE (0..32)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one + notable difference: in order for the Set operation + to succeed, the usmUserName of the operation + requester must match the usmUserName that indexes + the row which is targeted by this operation. + + The idea here is that access to this column can be + public, since it will only allow a user to change + his own secret privacy key (privKey). + " + + + +Blumenthal & Wijnen Standards Track [Page 42] + +RFC 2264 USM for SNMPv3 January 1998 + + + DEFVAL { ''H } -- the empty string + ::= { usmUserEntry 10 } + +usmUserPublic OBJECT-TYPE + SYNTAX OCTET STRING (SIZE(0..32)) + MAX-ACCESS read-create + STATUS current + DESCRIPTION "A publicly-readable value which is written as part + of the procedure for changing a user's secret + authentication and/or privacy key, and later read to + determine whether the change of the secret was + effected. + " + DEFVAL { ''H } -- the empty string + ::= { usmUserEntry 11 } + +usmUserStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION "The storage type for this conceptual row. + + Conceptual rows having the value 'permanent' + must allow write-access at a minimum to: + + - usmUserAuthKeyChange, usmUserOwnAuthKeyChange + and usmUserPublic for a user who employs + authentication, and + - usmUserPrivKeyChange, usmUserOwnPrivKeyChange + and usmUserPublic for a user who employs + privacy. + + Note that any user who employs authentication or + privacy must allow its secret(s) to be updated and + thus cannot be 'readOnly'. + " + DEFVAL { nonVolatile } + ::= { usmUserEntry 12 } + +usmUserStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION "The status of this conceptual row. + + Until instances of all corresponding columns are + appropriately configured, the value of the + corresponding instance of the usmUserStatus column + + + +Blumenthal & Wijnen Standards Track [Page 43] + +RFC 2264 USM for SNMPv3 January 1998 + + + is 'notReady'. + + In particular, a newly created row cannot be made + active until the corresponding usmUserCloneFrom, + usmUserAuthKeyChange, usmUserOwnAuthKeyChange, + usmUserPrivKeyChange and usmUserOwnPrivKeyChange + have all been set. + + The RowStatus TC [RFC1903] requires that this + DESCRIPTION clause states under which circumstances + other objects in this row can be modified: + + The value of this object has no effect on whether + other objects in this conceptual row can be modified. + " + ::= { usmUserEntry 13 } + +-- Conformance Information ******************************************* + +usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 } +usmMIBGroups OBJECT IDENTIFIER ::= { usmMIBConformance 2 } + +-- Compliance statements + +usmMIBCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION "The compliance statement for SNMP engines which + implement the SNMP-USER-BASED-SM-MIB. + " + + MODULE -- this module + MANDATORY-GROUPS { usmMIBBasicGroup } + + OBJECT usmUserAuthProtocol + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + OBJECT usmUserPrivProtocol + MIN-ACCESS read-only + DESCRIPTION "Write access is not required." + + ::= { usmMIBCompliances 1 } + +-- Units of compliance +usmMIBBasicGroup OBJECT-GROUP + OBJECTS { + usmStatsUnsupportedSecLevels, + usmStatsNotInTimeWindows, + + + +Blumenthal & Wijnen Standards Track [Page 44] + +RFC 2264 USM for SNMPv3 January 1998 + + + usmStatsUnknownUserNames, + usmStatsUnknownEngineIDs, + usmStatsWrongDigests, + usmStatsDecryptionErrors, + usmUserSpinLock, + usmUserSecurityName, + usmUserCloneFrom, + usmUserAuthProtocol, + usmUserAuthKeyChange, + usmUserOwnAuthKeyChange, + usmUserPrivProtocol, + usmUserPrivKeyChange, + usmUserOwnPrivKeyChange, + usmUserPublic, + usmUserStorageType, + usmUserStatus + } + STATUS current + DESCRIPTION "A collection of objects providing for configuration + of an SNMP engine which implements the SNMP + User-based Security Model. + " + ::= { usmMIBGroups 1 } + +END + +6. HMAC-MD5-96 Authentication Protocol + + This section describes the HMAC-MD5-96 authentication protocol. This + authentication protocol is the first defined for the User-based + Security Model. It uses MD5 hash-function which is described in + [MD5], in HMAC mode described in [RFC2104], truncating the output to + 96 bits. + + This protocol is identified by usmHMACMD5AuthProtocol. + + Over time, other authentication protocols may be defined either as a + replacement of this protocol or in addition to this protocol. + +6.1. Mechanisms + + - In support of data integrity, a message digest algorithm is + required. A digest is calculated over an appropriate portion of an + SNMP message and included as part of the message sent to the + recipient. + + + + + + +Blumenthal & Wijnen Standards Track [Page 45] + +RFC 2264 USM for SNMPv3 January 1998 + + + - In support of data origin authentication and data integrity, + a secret value is prepended to SNMP message prior to computing the + digest; the calculated digest is partially inserted into the SNMP + message prior to transmission, and the prepended value is not + transmitted. The secret value is shared by all SNMP engines + authorized to originate messages on behalf of the appropriate user. + +6.1.1. Digest Authentication Mechanism + + The Digest Authentication Mechanism defined in this memo provides + for: + + - verification of the integrity of a received message, i.e., the + message received is the message sent. + + The integrity of the message is protected by computing a digest + over an appropriate portion of the message. The digest is computed + by the originator of the message, transmitted with the message, and + verified by the recipient of the message. + + - verification of the user on whose behalf the message was generated. + + A secret value known only to SNMP engines authorized to generate + messages on behalf of a user is used in HMAC mode (see [RFC2104]). + It also recommends the hash-function output used as Message + Authentication Code, to be truncated. + + This protocol uses the MD5 [MD5] message digest algorithm. A 128-bit + MD5 digest is calculated in a special (HMAC) way over the designated + portion of an SNMP message and the first 96 bits of this digest is + included as part of the message sent to the recipient. The size of + the digest carried in a message is 12 octets. The size of the private + authentication key (the secret) is 16 octets. For the details see + section 6.3. + +6.2. Elements of the Digest Authentication Protocol + + This section contains definitions required to realize the + authentication module defined in this section of this memo. + +6.2.1. Users + + Authentication using this authentication protocol makes use of a + defined set of userNames. For any user on whose behalf a message must + be authenticated at a particular SNMP engine, that SNMP engine must + have knowledge of that user. An SNMP engine that wishes to + + + + + +Blumenthal & Wijnen Standards Track [Page 46] + +RFC 2264 USM for SNMPv3 January 1998 + + + communicate with another SNMP engine must also have knowledge of a + user known to that engine, including knowledge of the applicable + attributes of that user. + + A user and its attributes are defined as follows: + + <userName> + A string representing the name of the user. + <authKey> + A user's secret key to be used when calculating a digest. + It MUST be 16 octets long for MD5. + +6.2.2. msgAuthoritativeEngineID + + The msgAuthoritativeEngineID value contained in an authenticated + message specifies the authoritative SNMP engine for that particular + message (see the definition of SnmpEngineID in the SNMP Architecture + document [RFC2261]). + + The user's (private) authentication key is normally different at each + authoritative SNMP engine and so the snmpEngineID is used to select + the proper key for the authentication process. + +6.2.3. SNMP Messages Using this Authentication Protocol + + Messages using this authentication protocol carry a + msgAuthenticationParameters field as part of the + msgSecurityParameters. For this protocol, the + msgAuthenticationParameters field is the serialized OCTET STRING + representing the first 12 octets of the HMAC-MD5-96 output done over + the wholeMsg. + + The digest is calculated over the wholeMsg so if a message is + authenticated, that also means that all the fields in the message are + intact and have not been tampered with. + +6.2.4. Services provided by the HMAC-MD5-96 Authentication Module + + This section describes the inputs and outputs that the HMAC-MD5-96 + Authentication module expects and produces when the User-based + Security module calls the HMAC-MD5-96 Authentication module for + services. + +6.2.4.1. Services for Generating an Outgoing SNMP Message + + The HMAC-MD5-96 authentication protocol assumes that the selection of + the authKey is done by the caller and that the caller passes the + secret key to be used. + + + +Blumenthal & Wijnen Standards Track [Page 47] + +RFC 2264 USM for SNMPv3 January 1998 + + + Upon completion the authentication module returns statusInformation + and, if the message digest was correctly calculated, the wholeMsg + with the digest inserted at the proper place. The abstract service + primitive is: + + statusInformation = -- success or failure + authenticateOutgoingMsg( + IN authKey -- secret key for authentication + IN wholeMsg -- unauthenticated complete message + OUT authenticatedWholeMsg -- complete authenticated message + ) + + The abstract data elements are: + + statusInformation + An indication of whether the authentication process was + successful. If not it is an indication of the problem. + authKey + The secret key to be used by the authentication algorithm. + The length of this key MUST be 16 octets. + wholeMsg + The message to be authenticated. + authenticatedWholeMsg + The authenticated message (including inserted digest) on output. + + Note, that authParameters field is filled by the authentication + module and this field should be already present in the wholeMsg + before the Message Authentication Code (MAC) is generated. + +6.2.4.2. Services for Processing an Incoming SNMP Message + + The HMAC-MD5-96 authentication protocol assumes that the selection of + the authKey is done by the caller and that the caller passes the + secret key to be used. + + Upon completion the authentication module returns statusInformation + and, if the message digest was correctly calculated, the wholeMsg as + it was processed. The abstract service primitive is: + + statusInformation = -- success or failure + authenticateIncomingMsg( + IN authKey -- secret key for authentication + IN authParameters -- as received on the wire + IN wholeMsg -- as received on the wire + OUT authenticatedWholeMsg -- complete authenticated message + ) + + The abstract data elements are: + + + +Blumenthal & Wijnen Standards Track [Page 48] + +RFC 2264 USM for SNMPv3 January 1998 + + + statusInformation + An indication of whether the authentication process was + successful. If not it is an indication of the problem. + authKey + The secret key to be used by the authentication algorithm. + The length of this key MUST be 16 octets. + authParameters + The authParameters from the incoming message. + wholeMsg + The message to be authenticated on input and the authenticated + message on output. + authenticatedWholeMsg + The whole message after the authentication check is complete. + +6.3. Elements of Procedure + + This section describes the procedures for the HMAC-MD5-96 + authentication protocol. + +6.3.1. Processing an Outgoing Message + + This section describes the procedure followed by an SNMP engine + whenever it must authenticate an outgoing message using the + usmHMACMD5AuthProtocol. + + 1) The msgAuthenticationParameters field is set to the + serialization, according to the rules in [RFC1906], of an OCTET + STRING containing 12 zero octets. + + 2) From the secret authKey, two keys K1 and K2 are derived: + + a) extend the authKey to 64 octets by appending 48 zero + octets; save it as extendedAuthKey + b) obtain IPAD by replicating the octet 0x36 64 times; + c) obtain K1 by XORing extendedAuthKey with IPAD; + d) obtain OPAD by replicating the octet 0x5C 64 times; + e) obtain K2 by XORing extendedAuthKey with OPAD. + + 4) Prepend K1 to the wholeMsg and calculate MD5 digest over it + according to [MD5]. + + 5) Prepend K2 to the result of the step 4 and calculate MD5 digest + over it according to [MD5]. Take the first 12 octets of the final + digest - this is Message Authentication Code (MAC). + + 6) Replace the msgAuthenticationParameters field with MAC obtained + in the step 5. + + + + +Blumenthal & Wijnen Standards Track [Page 49] + +RFC 2264 USM for SNMPv3 January 1998 + + + 7) The authenticatedWholeMsg is then returned to the caller + together with statusInformation indicating success. + +6.3.2. Processing an Incoming Message + + This section describes the procedure followed by an SNMP engine + whenever it must authenticate an incoming message using the + usmHMACMD5AuthProtocol. + + 1) If the digest received in the msgAuthenticationParameters field + is not 12 octets long, then an failure and an errorIndication + (authenticationError) is returned to the calling module. + + 2) The MAC received in the msgAuthenticationParameters field + is saved. + + 3) The digest in the msgAuthenticationParameters field is replaced + by the 12 zero octets. + + 4) From the secret authKey, two keys K1 and K2 are derived: + + a) extend the authKey to 64 octets by appending 48 zero + octets; save it as extendedAuthKey + b) obtain IPAD by replicating the octet 0x36 64 times; + c) obtain K1 by XORing extendedAuthKey with IPAD; + d) obtain OPAD by replicating the octet 0x5C 64 times; + e) obtain K2 by XORing extendedAuthKey with OPAD. + + 5) The MAC is calculated over the wholeMsg: + + a) prepend K1 to the wholeMsg and calculate the MD5 digest + over it; + b) prepend K2 to the result of step 5.a and calculate the + MD5 digest over it; + c) first 12 octets of the result of step 5.b is the MAC. + + The msgAuthenticationParameters field is replaced with the MAC + value that was saved in step 2. + + 6) Then the newly calculated MAC is compared with the MAC + saved in step 2. If they do not match, then an failure and an + errorIndication (authenticationFailure) is returned to the + calling module. + + 7) The authenticatedWholeMsg and statusInformation indicating + success are then returned to the caller. + + + + + +Blumenthal & Wijnen Standards Track [Page 50] + +RFC 2264 USM for SNMPv3 January 1998 + + +7. HMAC-SHA-96 Authentication Protocol + + This section describes the HMAC-SHA-96 authentication protocol. This + protocol uses the SHA hash-function which is described in [SHA-NIST], + in HMAC mode described in [RFC2104], truncating the output to 96 + bits. + + This protocol is identified by usmHMACSHAAuthProtocol. + + Over time, other authentication protocols may be defined either as a + replacement of this protocol or in addition to this protocol. + +7.1. Mechanisms + + - In support of data integrity, a message digest algorithm is + required. A digest is calculated over an appropriate portion of an + SNMP message and included as part of the message sent to the + recipient. + + - In support of data origin authentication and data integrity, + a secret value is prepended to the SNMP message prior to computing + the digest; the calculated digest is then partially inserted into + the message prior to transmission. The prepended secret is not + transmitted. The secret value is shared by all SNMP engines + authorized to originate messages on behalf of the appropriate user. + +7.1.1. Digest Authentication Mechanism + + The Digest Authentication Mechanism defined in this memo provides + for: + + - verification of the integrity of a received message, i.e., the + the message received is the message sent. + + The integrity of the message is protected by computing a digest + over an appropriate portion of the message. The digest is computed + by the originator of the message, transmitted with the message, and + verified by the recipient of the message. + + - verification of the user on whose behalf the message was generated. + + A secret value known only to SNMP engines authorized to generate + messages on behalf of a user is used in HMAC mode (see [RFC2104]). + It also recommends the hash-function output used as Message + Authentication Code, to be truncated. + + + + + + +Blumenthal & Wijnen Standards Track [Page 51] + +RFC 2264 USM for SNMPv3 January 1998 + + + This mechanism uses the SHA [SHA-NIST] message digest algorithm. A + 160-bit SHA digest is calculated in a special (HMAC) way over the + designated portion of an SNMP message and the first 96 bits of this + digest is included as part of the message sent to the recipient. The + size of the digest carried in a message is 12 octets. The size of the + private authentication key (the secret) is 20 octets. For the details + see section 7.3. + +7.2. Elements of the HMAC-SHA-96 Authentication Protocol + + This section contains definitions required to realize the + authentication module defined in this section of this memo. + +7.2.1. Users + + Authentication using this authentication protocol makes use of a + defined set of userNames. For any user on whose behalf a message + must be authenticated at a particular SNMP engine, that SNMP engine + must have knowledge of that user. An SNMP engine that wishes to + communicate with another SNMP engine must also have knowledge of a + user known to that engine, including knowledge of the applicable + attributes of that user. + + A user and its attributes are defined as follows: + + <userName> + A string representing the name of the user. + <authKey> + A user's secret key to be used when calculating a digest. + It MUST be 20 octets long for SHA. + +7.2.2. msgAuthoritativeEngineID + + The msgAuthoritativeEngineID value contained in an authenticated + message specifies the authoritative SNMP engine for that particular + message (see the definition of SnmpEngineID in the SNMP Architecture + document [RFC2261]). + + The user's (private) authentication key is normally different at each + authoritative SNMP engine and so the snmpEngineID is used to select + the proper key for the authentication process. + + + + + + + + + + +Blumenthal & Wijnen Standards Track [Page 52] + +RFC 2264 USM for SNMPv3 January 1998 + + +7.2.3. SNMP Messages Using this Authentication Protocol + + Messages using this authentication protocol carry a + msgAuthenticationParameters field as part of the + msgSecurityParameters. For this protocol, the + msgAuthenticationParameters field is the serialized OCTET STRING + representing the first 12 octets of HMAC-SHA-96 output done over the + wholeMsg. + + The digest is calculated over the wholeMsg so if a message is + authenticated, that also means that all the fields in the message are + intact and have not been tampered with. + +7.2.4. Services provided by the HMAC-SHA-96 Authentication Module + + This section describes the inputs and outputs that the HMAC-SHA-96 + Authentication module expects and produces when the User-based + Security module calls the HMAC-SHA-96 Authentication module for + services. + +7.2.4.1. Services for Generating an Outgoing SNMP Message + + HMAC-SHA-96 authentication protocol assumes that the selection of the + authKey is done by the caller and that the caller passes the secret + key to be used. + + Upon completion the authentication module returns statusInformation + and, if the message digest was correctly calculated, the wholeMsg + with the digest inserted at the proper place. The abstract service + primitive is: + + statusInformation = -- success or failure + authenticateOutgoingMsg( + IN authKey -- secret key for authentication + IN wholeMsg -- unauthenticated complete message + OUT authenticatedWholeMsg -- complete authenticated message + ) + + The abstract data elements are: + + statusInformation + An indication of whether the authentication process was + successful. If not it is an indication of the problem. + authKey + The secret key to be used by the authentication algorithm. + The length of this key MUST be 20 octets. + wholeMsg + The message to be authenticated. + + + +Blumenthal & Wijnen Standards Track [Page 53] + +RFC 2264 USM for SNMPv3 January 1998 + + + authenticatedWholeMsg + The authenticated message (including inserted digest) on output. + + Note, that authParameters field is filled by the authentication + module and this field should be already present in the wholeMsg + before the Message Authentication Code (MAC) is generated. + +7.2.4.2. Services for Processing an Incoming SNMP Message + + HMAC-SHA-96 authentication protocol assumes that the selection of the + authKey is done by the caller and that the caller passes the secret + key to be used. + + Upon completion the authentication module returns statusInformation + and, if the message digest was correctly calculated, the wholeMsg as + it was processed. The abstract service primitive is: + + statusInformation = -- success or failure + authenticateIncomingMsg( + IN authKey -- secret key for authentication + IN authParameters -- as received on the wire + IN wholeMsg -- as received on the wire + OUT authenticatedWholeMsg -- complete authenticated message + ) + + The abstract data elements are: + + statusInformation + An indication of whether the authentication process was + successful. If not it is an indication of the problem. + authKey + The secret key to be used by the authentication algorithm. + The length of this key MUST be 20 octets. + authParameters + The authParameters from the incoming message. + wholeMsg + The message to be authenticated on input and the authenticated + message on output. + authenticatedWholeMsg + The whole message after the authentication check is complete. + +7.3. Elements of Procedure + + This section describes the procedures for the HMAC-SHA-96 + authentication protocol. + + + + + + +Blumenthal & Wijnen Standards Track [Page 54] + +RFC 2264 USM for SNMPv3 January 1998 + + +7.3.1. Processing an Outgoing Message + + This section describes the procedure followed by an SNMP engine + whenever it must authenticate an outgoing message using the + usmHMACSHAAuthProtocol. + + 1) The msgAuthenticationParameters field is set to the + serialization, according to the rules in [RFC1906], of an OCTET + STRING containing 12 zero octets. + + 2) From the secret authKey, two keys K1 and K2 are derived: + + a) extend the authKey to 64 octets by appending 44 zero + octets; save it as extendedAuthKey + b) obtain IPAD by replicating the octet 0x36 64 times; + c) obtain K1 by XORing extendedAuthKey with IPAD; + d) obtain OPAD by replicating the octet 0x5C 64 times; + e) obtain K2 by XORing extendedAuthKey with OPAD. + + 3) Prepend K1 to the wholeMsg and calculate the SHA digest over it + according to [SHA-NIST]. + + 4) Prepend K2 to the result of the step 4 and calculate SHA digest + over it according to [SHA-NIST]. Take the first 12 octets of the + final digest - this is Message Authentication Code (MAC). + + 5) Replace the msgAuthenticationParameters field with MAC obtained + in the step 5. + + 6) The authenticatedWholeMsg is then returned to the caller + together with statusInformation indicating success. + +7.3.2. Processing an Incoming Message + + This section describes the procedure followed by an SNMP engine + whenever it must authenticate an incoming message using the + usmHMACSHAAuthProtocol. + + 1) If the digest received in the msgAuthenticationParameters field + is not 12 octets long, then an failure and an errorIndication + (authenticationError) is returned to the calling module. + + 2) The MAC received in the msgAuthenticationParameters field + is saved. + + 3) The digest in the msgAuthenticationParameters field is + replaced by the 12 zero octets. + + + + +Blumenthal & Wijnen Standards Track [Page 55] + +RFC 2264 USM for SNMPv3 January 1998 + + + 4) From the secret authKey, two keys K1 and K2 are derived: + + a) extend the authKey to 64 octets by appending 44 zero + octets; save it as extendedAuthKey + b) obtain IPAD by replicating the octet 0x36 64 times; + c) obtain K1 by XORing extendedAuthKey with IPAD; + d) obtain OPAD by replicating the octet 0x5C 64 times; + e) obtain K2 by XORing extendedAuthKey with OPAD. + + 5) The MAC is calculated over the wholeMsg: + + a) prepend K1 to the wholeMsg and calculate the SHA digest + over it; + b) prepend K2 to the result of step 5.a and calculate the + SHA digest over it; + c) first 12 octets of the result of step 5.b is the MAC. + + The msgAuthenticationParameters field is replaced with the MAC + value that was saved in step 2. + + 6) The the newly calculated MAC is compared with the MAC saved in + step 2. If they do not match, then a failure and an + errorIndication (authenticationFailure) are returned to the + calling module. + + 7) The authenticatedWholeMsg and statusInformation indicating + success are then returned to the caller. + +8. CBC-DES Symmetric Encryption Protocol + + This section describes the CBC-DES Symmetric Encryption Protocol. + This protocol is the first privacy protocol defined for the User- + based Security Model. + + This protocol is identified by usmDESPrivProtocol. + + Over time, other privacy protocols may be defined either as a + replacement of this protocol or in addition to this protocol. + +8.1. Mechanisms + + - In support of data confidentiality, an encryption algorithm is + required. An appropriate portion of the message is encrypted prior + to being transmitted. The User-based Security Model specifies that + the scopedPDU is the portion of the message that needs to be + encrypted. + + + + + +Blumenthal & Wijnen Standards Track [Page 56] + +RFC 2264 USM for SNMPv3 January 1998 + + + - A secret value in combination with a timeliness value is used + to create the en/decryption key and the initialization vector. The + secret value is shared by all SNMP engines authorized to originate + messages on behalf of the appropriate user. + +8.1.1. Symmetric Encryption Protocol + + The Symmetric Encryption Protocol defined in this memo provides + support for data confidentiality. The designated portion of an SNMP + message is encrypted and included as part of the message sent to the + recipient. + + Two organizations have published specifications defining the DES: the + National Institute of Standards and Technology (NIST) [DES-NIST] and + the American National Standards Institute [DES-ANSI]. There is a + companion Modes of Operation specification for each definition + ([DESO-NIST] and [DESO-ANSI], respectively). + + The NIST has published three additional documents that implementors + may find useful. + + - There is a document with guidelines for implementing and using + the DES, including functional specifications for the DES and its + modes of operation [DESG-NIST]. + + - There is a specification of a validation test suite for the DES + [DEST-NIST]. The suite is designed to test all aspects of the DES + and is useful for pinpointing specific problems. + + - There is a specification of a maintenance test for the DES + [DESM-NIST]. The test utilizes a minimal amount of data and + processing to test all components of the DES. It provides a simple + yes-or-no indication of correct operation and is useful to run as + part of an initialization step, e.g., when a computer re-boots. + +8.1.1.1. DES key and Initialization Vector. + + The first 8 octets of the 16-octet secret (private privacy key) are + used as a DES key. Since DES uses only 56 bits, the Least + Significant Bit in each octet is disregarded. + + The Initialization Vector for encryption is obtained using the + following procedure. + + The last 8 octets of the 16-octet secret (private privacy key) are + used as pre-IV. + + + + + +Blumenthal & Wijnen Standards Track [Page 57] + +RFC 2264 USM for SNMPv3 January 1998 + + + In order to ensure that the IV for two different packets encrypted by + the same key, are not the same (i.e., the IV does not repeat) we need + to "salt" the pre-IV with something unique per packet. An 8-octet + string is used as the "salt". The concatenation of the generating + SNMP engine's 32-bit snmpEngineBoots and a local 32-bit integer, that + the encryption engine maintains, is input to the "salt". The 32-bit + integer is initialized to an arbitrary value at boot time. + + The 32-bit snmpEngineBoots is converted to the first 4 octets (Most + Significant Byte first) of our "salt". The 32-bit integer is then + converted to the last 4 octet (Most Significant Byte first) of our + "salt". The resulting "salt" is then XOR-ed with the pre-IV. The 8- + octet "salt" is then put into the privParameters field encoded as an + OCTET STRING. The "salt" integer is then modified. We recommend + that it be incremented by one and wrap when it reaches the maximum + value. + + How exactly the value of the "salt" (and thus of the IV) varies, is + an implementation issue, as long as the measures are taken to avoid + producing a duplicate IV. + + The "salt" must be placed in the privParameters field to enable the + receiving entity to compute the correct IV and to decrypt the + message. + +8.1.1.2. Data Encryption. + + The data to be encrypted is treated as sequence of octets. Its length + should be an integral multiple of 8 - and if it is not, the data is + padded at the end as necessary. The actual pad value is irrelevant. + + The data is encrypted in Cipher Block Chaining mode. + + The plaintext is divided into 64-bit blocks. + + The plaintext for each block is XOR-ed with the ciphertext of the + previous block, the result is encrypted and the output of the + encryption is the ciphertext for the block. This procedure is + repeated until there are no more plaintext blocks. + + For the very first block, the Initialization Vector is used instead + of the ciphertext of the previous block. + + + + + + + + + +Blumenthal & Wijnen Standards Track [Page 58] + +RFC 2264 USM for SNMPv3 January 1998 + + +8.1.1.3. Data Decryption + + Before decryption, the encrypted data length is verified. If the + length of the OCTET STRING to be decrypted is not an integral + multiple of 8 octets, the decryption process is halted and an + appropriate exception noted. When decrypting, the padding is + ignored. + + The first ciphertext block is decrypted, the decryption output is + XOR-ed with the Initialization Vector, and the result is the first + plaintext block. + + For each subsequent block, the ciphertext block is decrypted, the + decryption output is XOR-ed with the previous ciphertext block and + the result is the plaintext block. + +8.2. Elements of the DES Privacy Protocol + + This section contains definitions required to realize the privacy + module defined by this memo. + +8.2.1. Users + + Data en/decryption using this Symmetric Encryption Protocol makes use + of a defined set of userNames. For any user on whose behalf a + message must be en/decrypted at a particular SNMP engine, that SNMP + engine must have knowledge of that user. An SNMP engine that wishes + to communicate with another SNMP engine must also have knowledge of a + user known to that SNMP engine, including knowledge of the applicable + attributes of that user. + + A user and its attributes are defined as follows: + + <userName> + An octet string representing the name of the user. + <privKey> + A user's secret key to be used as input for the DES key and IV. + The length of this key MUST be 16 octets. + +8.2.2. msgAuthoritativeEngineID + + The msgAuthoritativeEngineID value contained in an authenticated + message specifies the authoritative SNMP engine for that particular + message (see the definition of SnmpEngineID in the SNMP Architecture + document [RFC2261]). + + + + + + +Blumenthal & Wijnen Standards Track [Page 59] + +RFC 2264 USM for SNMPv3 January 1998 + + + The user's (private) privacy key is normally different at each + authoritative SNMP engine and so the snmpEngineID is used to select + the proper key for the en/decryption process. + +8.2.3. SNMP Messages Using this Privacy Protocol + + Messages using this privacy protocol carry a msgPrivacyParameters + field as part of the msgSecurityParameters. For this protocol, the + msgPrivacyParameters field is the serialized OCTET STRING + representing the "salt" that was used to create the IV. + +8.2.4. Services provided by the DES Privacy Module + + This section describes the inputs and outputs that the DES Privacy + module expects and produces when the User-based Security module + invokes the DES Privacy module for services. + +8.2.4.1. Services for Encrypting Outgoing Data + + This DES privacy protocol assumes that the selection of the privKey + is done by the caller and that the caller passes the secret key to be + used. + + Upon completion the privacy module returns statusInformation and, if + the encryption process was successful, the encryptedPDU and the + msgPrivacyParameters encoded as an OCTET STRING. The abstract + service primitive is: + + statusInformation = -- success of failure + encryptData( + IN encryptKey -- secret key for encryption + IN dataToEncrypt -- data to encrypt (scopedPDU) + OUT encryptedData -- encrypted data (encryptedPDU) + OUT privParameters -- filled in by service provider + ) + + The abstract data elements are: + + statusInformation + An indication of the success or failure of the encryption + process. In case of failure, it is an indication of the error. + encryptKey + The secret key to be used by the encryption algorithm. + The length of this key MUST be 16 octets. + dataToEncrypt + The data that must be encrypted. + encryptedData + The encrypted data upon successful completion. + + + +Blumenthal & Wijnen Standards Track [Page 60] + +RFC 2264 USM for SNMPv3 January 1998 + + + privParameters + The privParameters encoded as an OCTET STRING. + +8.2.4.2. Services for Decrypting Incoming Data + + This DES privacy protocol assumes that the selection of the privKey + is done by the caller and that the caller passes the secret key to be + used. + + Upon completion the privacy module returns statusInformation and, if + the decryption process was successful, the scopedPDU in plain text. + The abstract service primitive is: + + statusInformation = + decryptData( + IN decryptKey -- secret key for decryption + IN privParameters -- as received on the wire + IN encryptedData -- encrypted data (encryptedPDU) + OUT decryptedData -- decrypted data (scopedPDU) + ) + + The abstract data elements are: + + statusInformation + An indication whether the data was successfully decrypted + and if not an indication of the error. + decryptKey + The secret key to be used by the decryption algorithm. + The length of this key MUST be 16 octets. + privParameters + The "salt" to be used to calculate the IV. + encryptedData + The data to be decrypted. + decryptedData + The decrypted data. + +8.3. Elements of Procedure. + + This section describes the procedures for the DES privacy protocol. + +8.3.1. Processing an Outgoing Message + + This section describes the procedure followed by an SNMP engine + whenever it must encrypt part of an outgoing message using the + usmDESPrivProtocol. + + 1) The secret cryptKey is used to construct the DES encryption key, + the "salt" and the DES pre-IV (as described in section 8.1.1.1). + + + +Blumenthal & Wijnen Standards Track [Page 61] + +RFC 2264 USM for SNMPv3 January 1998 + + + 2) The privParameters field is set to the serialization according + to the rules in [RFC1906] of an OCTET STRING representing the the + "salt" string. + + 3) The scopedPDU is encrypted (as described in section 8.1.1.2) + and the encrypted data is serialized according to the rules in + [RFC1906] as an OCTET STRING. + + 4) The serialized OCTET STRING representing the encrypted + scopedPDU together with the privParameters and statusInformation + indicating success is returned to the calling module. + +8.3.2. Processing an Incoming Message + + This section describes the procedure followed by an SNMP engine + whenever it must decrypt part of an incoming message using the + usmDESPrivProtocol. + + 1) If the privParameters field is not an 8-octet OCTET STRING, + then an error indication (decryptionError) is returned to the + calling module. + + 2) The "salt" is extracted from the privParameters field. + + 3) The secret cryptKey and the "salt" are then used to construct the + DES decryption key and pre-IV (as described in section 8.1.1.1). + + 4) The encryptedPDU is then decrypted (as described in + section 8.1.1.3). + + 5) If the encryptedPDU cannot be decrypted, then an error + indication (decryptionError) is returned to the calling module. + + 6) The decrypted scopedPDU and statusInformation indicating + success are returned to the calling module. + +9. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + + + +Blumenthal & Wijnen Standards Track [Page 62] + +RFC 2264 USM for SNMPv3 January 1998 + + + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +10. Acknowledgements + + This document is the result of the efforts of the SNMPv3 Working + Group. Some special thanks are in order to the following SNMPv3 WG + members: + + Dave Battle (SNMP Research, Inc.) + Uri Blumenthal (IBM T.J. Watson Research Center) + Jeff Case (SNMP Research, Inc.) + John Curran (BBN) + T. Max Devlin (Hi-TECH Connections) + John Flick (Hewlett Packard) + David Harrington (Cabletron Systems Inc.) + N.C. Hien (IBM T.J. Watson Research Center) + Dave Levi (SNMP Research, Inc.) + Louis A Mamakos (UUNET Technologies Inc.) + Paul Meyer (Secure Computing Corporation) + Keith McCloghrie (Cisco Systems) + Russ Mundy (Trusted Information Systems, Inc.) + Bob Natale (ACE*COMM Corporation) + Mike O'Dell (UUNET Technologies Inc.) + Dave Perkins (DeskTalk) + Peter Polkinghorne (Brunel University) + Randy Presuhn (BMC Software, Inc.) + David Reid (SNMP Research, Inc.) + Shawn Routhier (Epilogue) + Juergen Schoenwaelder (TU Braunschweig) + Bob Stewart (Cisco Systems) + Bert Wijnen (IBM T.J. Watson Research Center) + + The document is based on recommendations of the IETF Security and + Administrative Framework Evolution for SNMP Advisory Team. Members + of that Advisory Team were: + + David Harrington (Cabletron Systems Inc.) + Jeff Johnson (Cisco Systems) + David Levi (SNMP Research Inc.) + John Linn (Openvision) + + + +Blumenthal & Wijnen Standards Track [Page 63] + +RFC 2264 USM for SNMPv3 January 1998 + + + Russ Mundy (Trusted Information Systems) chair + Shawn Routhier (Epilogue) + Glenn Waters (Nortel) + Bert Wijnen (IBM T. J. Watson Research Center) + + As recommended by the Advisory Team and the SNMPv3 Working Group + Charter, the design incorporates as much as practical from previous + RFCs and drafts. As a result, special thanks are due to the authors + of previous designs known as SNMPv2u and SNMPv2*: + + Jeff Case (SNMP Research, Inc.) + David Harrington (Cabletron Systems Inc.) + David Levi (SNMP Research, Inc.) + Keith McCloghrie (Cisco Systems) + Brian O'Keefe (Hewlett Packard) + Marshall T. Rose (Dover Beach Consulting) + Jon Saperia (BGS Systems Inc.) + Steve Waldbusser (International Network Services) + Glenn W. Waters (Bell-Northern Research Ltd.) + +11. Security Considerations + +11.1. Recommended Practices + + This section describes practices that contribute to the secure, + effective operation of the mechanisms defined in this memo. + + - An SNMP engine must discard SNMP Response messages that do not + correspond to any currently outstanding Request message. It is the + responsibility of the Message Processing module to take care of + this. For example it can use a msgID for that. + + An SNMP Command Generator Application must discard any Response PDU + for which there is no currently outstanding Request PDU; for + example for SNMPv2 [RFC1905] PDUs, the request-id component in the + PDU can be used to correlate Responses to outstanding Requests. + + Although it would be typical for an SNMP engine and an SNMP Command + Generator Application to do this as a matter of course, when using + these security protocols it is significant due to the possibility + of message duplication (malicious or otherwise). + + - If an SNMP engine uses a msgID for correlating Response messages + to outstanding Request messages, then it MUST use different msgIDs + in all such Request messages that it sends out during a Time Window + (150 seconds) period. + + + + + +Blumenthal & Wijnen Standards Track [Page 64] + +RFC 2264 USM for SNMPv3 January 1998 + + + A Command Generator or Notification Originator Application MUST use + different request-ids in all Request PDUs that it sends out during + a TimeWindow (150 seconds) period. + + This must be done to protect against the possibility of message + duplication (malicious or otherwise). + + For example, starting operations with a msgID and/or request-id + value of zero is not a good idea. Initializing them with an + unpredictable number (so they do not start out the same after each + reboot) and then incrementing by one would be acceptable. + + - An SNMP engine should perform time synchronization using + authenticated messages in order to protect against the possibility + of message duplication (malicious or otherwise). + + - When sending state altering messages to a managed authoritative + SNMP engine, a Command Generator Application should delay sending + successive messages to that managed SNMP engine until a positive + acknowledgement is received for the previous message or until the + previous message expires. + + No message ordering is imposed by the SNMP. Messages may be + received in any order relative to their time of generation and each + will be processed in the ordered received. Note that when an + authenticated message is sent to a managed SNMP engine, it will be + valid for a period of time of approximately 150 seconds under + normal circumstances, and is subject to replay during this period. + Indeed, an SNMP engine and SNMP Command Generator Applications must + cope with the loss and re-ordering of messages resulting from + anomalies in the network as a matter of course. + + However, a managed object, snmpSetSerialNo [RFC1907], is + specifically defined for use with SNMP Set operations in order to + provide a mechanism to ensure that the processing of SNMP messages + occurs in a specific order. + + - The frequency with which the secrets of a User-based Security + Model user should be changed is indirectly related to the frequency + of their use. + + Protecting the secrets from disclosure is critical to the overall + security of the protocols. Frequent use of a secret provides a + continued source of data that may be useful to a cryptanalyst in + exploiting known or perceived weaknesses in an algorithm. Frequent + changes to the secret avoid this vulnerability. + + + + + +Blumenthal & Wijnen Standards Track [Page 65] + +RFC 2264 USM for SNMPv3 January 1998 + + + Changing a secret after each use is generally regarded as the most + secure practice, but a significant amount of overhead may be + associated with that approach. + + Note, too, in a local environment the threat of disclosure may be + less significant, and as such the changing of secrets may be less + frequent. However, when public data networks are used as the + communication paths, more caution is prudent. + +11.2 Defining Users + + The mechanisms defined in this document employ the notion of users on + whose behalf messages are sent. How "users" are defined is subject + to the security policy of the network administration. For example, + users could be individuals (e.g., "joe" or "jane"), or a particular + role (e.g., "operator" or "administrator"), or a combination (e.g., + "joe-operator", "jane-operator" or "joe-admin"). Furthermore, a user + may be a logical entity, such as an SNMP Application or a set of SNMP + Applications, acting on behalf of an individual or role, or set of + individuals, or set of roles, including combinations. + + Appendix A describes an algorithm for mapping a user "password" to a + 16 octet value for use as either a user's authentication key or + privacy key (or both). Note however, that using the same password + (and therefore the same key) for both authentication and privacy is + very poor security practice and should be strongly discouraged. + Passwords are often generated, remembered, and input by a human. + Human-generated passwords may be less than the 16 octets required by + the authentication and privacy protocols, and brute force attacks can + be quite easy on a relatively short ASCII character set. Therefore, + the algorithm is Appendix A performs a transformation on the + password. If the Appendix A algorithm is used, SNMP implementations + (and SNMP configuration applications) must ensure that passwords are + at least 8 characters in length. + + Because the Appendix A algorithm uses such passwords (nearly) + directly, it is very important that they not be easily guessed. It + is suggested that they be composed of mixed-case alphanumeric and + punctuation characters that don't form words or phrases that might be + found in a dictionary. Longer passwords improve the security of the + system. Users may wish to input multiword phrases to make their + password string longer while ensuring that it is memorable. + + Since it is infeasible for human users to maintain different + passwords for every SNMP engine, but security requirements strongly + discourage having the same key for more than one SNMP engine, the + User-based Security Model employs a compromise proposed in + [Localized-key]. It derives the user keys for the SNMP engines from + + + +Blumenthal & Wijnen Standards Track [Page 66] + +RFC 2264 USM for SNMPv3 January 1998 + + + user's password in such a way that it is practically impossible to + either determine the user's password, or user's key for another SNMP + engine from any combination of user's keys on SNMP engines. + + Note however, that if user's password is disclosed, then key + localization will not help and network security may be compromised in + this case. Therefore a user's password or non-localized key MUST NOT + be stored on a managed device/node. Instead the localized key SHALL + be stored (if at all) , so that, in case a device does get + compromised, no other managed or managing devices get compromised. + +11.3. Conformance + + To be termed a "Secure SNMP implementation" based on the User-based + Security Model, an SNMP implementation MUST: + + - implement one or more Authentication Protocol(s). The HMAC-MD5-96 + and HMAC-SHA-96 Authentication Protocols defined in this memo are + examples of such protocols. + + - to the maximum extent possible, prohibit access to the secret(s) + of each user about which it maintains information in a Local + Configuration Datastore (LCD) under all circumstances except as + required to generate and/or validate SNMP messages with respect to + that user. + + - implement the key-localization mechanism. + + - implement the SNMP-USER-BASED-SM-MIB. + + In addition, an authoritative SNMP engine SHOULD provide initial + configuration in accordance with Appendix A.1. + + Implementation of a Privacy Protocol (the DES Symmetric Encryption + Protocol defined in this memo is one such protocol) is optional. + +12. References + + [RFC1321] Rivest, R., "Message Digest Algorithm MD5", + RFC 1321, April 1992. + + [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Textual Conventions for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1903, January 1996. + + [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Protocol Operations for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1905, January 1996. + + + +Blumenthal & Wijnen Standards Track [Page 67] + +RFC 2264 USM for SNMPv3 January 1998 + + + [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Transport Mappings for Version 2 of the Simple Network Management + Protocol (SNMPv2)", RFC 1906, January 1996. + + [RFC1907] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Management Information Base for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1907 January 1996. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, February + 1997. + + [RFC2028] Hovey, R., and S. Bradner, "The Organizations Involved in + the IETF Standards Process", BCP 11, RFC 2028, October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2261] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for describing SNMP Management Frameworks", RFC 2261, + January 1998. + + [RFC2262] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, + "Message Processing and Dispatching for the Simple Network + Management Protocol (SNMP)", RFC 2262, January 1998. + + [Localized-Key] U. Blumenthal, N. C. Hien, B. Wijnen + "Key Derivation for Network Management Applications" IEEE Network + Magazine, April/May issue, 1997. + + [DES-NIST] Data Encryption Standard, National Institute of Standards + and Technology. Federal Information Processing Standard (FIPS) + Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; + reaffirmed January, 1988). + + [DES-ANSI] Data Encryption Algorithm, American National Standards + Institute. ANSI X3.92-1981, (December, 1980). + + [DESO-NIST] DES Modes of Operation, National Institute of Standards + and Technology. Federal Information Processing Standard (FIPS) + Publication 81, (December, 1980). + + [DESO-ANSI] Data Encryption Algorithm - Modes of Operation, American + National Standards Institute. ANSI X3.106-1983, (May 1983). + + [DESG-NIST] Guidelines for Implementing and Using the NBS Data + Encryption Standard, National Institute of Standards and + Technology. Federal Information Processing Standard (FIPS) + + + +Blumenthal & Wijnen Standards Track [Page 68] + +RFC 2264 USM for SNMPv3 January 1998 + + + Publication 74, (April, 1981). + + [DEST-NIST] Validating the Correctness of Hardware Implementations of + the NBS Data Encryption Standard, National Institute of Standards + and Technology. Special Publication 500-20. + + [DESM-NIST] Maintenance Testing for the Data Encryption Standard, + National Institute of Standards and Technology. Special + Publication 500-61, (August, 1980). + + [SHA-NIST] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) + http://csrc.nist.gov/fips/fip180-1.txt (ASCII) + http://csrc.nist.gov/fips/fip180-1.ps (Postscript) + +13. Editors' Addresses + + Uri Blumenthal + IBM T. J. Watson Research + 30 Saw Mill River Pkwy, + Hawthorne, NY 10532 + USA + + EMail: uri@watson.ibm.com + Phone: +1-914-784-7064 + + + Bert Wijnen + IBM T. J. Watson Research + Schagen 33 + 3461 GL Linschoten + Netherlands + + EMail: wijnen@vnet.ibm.com + Phone: +31-348-432-794 + + + + + + + + + + + + + + + + + +Blumenthal & Wijnen Standards Track [Page 69] + +RFC 2264 USM for SNMPv3 January 1998 + + +APPENDIX A - Installation + +A.1. SNMP engine Installation Parameters + + During installation, an authoritative SNMP engine SHOULD (in the + meaning as defined in [RFC2119]) be configured with several initial + parameters. These include: + + 1) A security posture + + The choice of security posture determines if initial configuration + is implemented and if so how. One of three possible choices is + selected: + + minimum-secure, + semi-secure, + very-secure (i.e., no-initial-configuration) + + In the case of a very-secure posture, there is no initial + configuration, and so the following steps are irrelevant. + +2) one or more secrets + + These are the authentication/privacy secrets for the first user to be + configured. + + One way to accomplish this is to have the installer enter a + "password" for each required secret. The password is then + algorithmically converted into the required secret by: + + - forming a string of length 1,048,576 octets by repeating the + value of the password as often as necessary, truncating + accordingly, and using the resulting string as the input to the MD5 + algorithm [MD5]. The resulting digest, termed "digest1", is used + in the next step. + + - a second string is formed by concatenating digest1, the SNMP + engine's snmpEngineID value, and digest1. This string is used as + input to the MD5 algorithm [MD5]. + + The resulting digest is the required secret (see Appendix A.2). + + With these configured parameters, the SNMP engine instantiates the + following usmUserEntry in the usmUserTable: + + + + + + + +Blumenthal & Wijnen Standards Track [Page 70] + +RFC 2264 USM for SNMPv3 January 1998 + + + no privacy support privacy support + ------------------ --------------- + usmUserEngineID localEngineID localEngineID + usmUserName "initial" "initial" + usmUserSecurityName "initial" "initial" + usmUserCloneFrom ZeroDotZero ZeroDotZero + usmUserAuthProtocol usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol + usmUserAuthKeyChange "" "" + usmUserOwnAuthKeyChange "" "" + usmUserPrivProtocol none usmDESPrivProtocol + usmUserPrivKeyChange "" "" + usmUserOwnPrivKeyChange "" "" + usmUserPublic "" "" + usmUserStorageType anyValidStorageType anyValidStorageType + usmUserStatus active active + +A.2. Password to Key Algorithm + + A sample code fragment (section A.2.1) demonstrates the password to + key algorithm which can be used when mapping a password to an + authentication or privacy key using MD5. The reference source code of + MD5 is available in [RFC1321]. + + Another sample code fragment (section A.2.2) demonstrates the + password to key algorithm which can be used when mapping a password + to an authentication or privacy key using SHA (documented in SHA- + NIST). + + An example of the results of a correct implementation is provided + (section A.3) which an implementor can use to check if his + implementation produces the same result. + +A.2.1. Password to Key Sample Code for MD5 + +void password_to_key_md5( + u_char *password, /* IN */ + u_int passwordlen, /* IN */ + u_char *engineID, /* IN - pointer to snmpEngineID */ + u_int engineLength /* IN - length of snmpEngineID */ + u_char *key) /* OUT - pointer to caller 16-octet buffer */ +{ + MD5_CTX MD; + u_char *cp, password_buf[64]; + u_long password_index = 0; + u_long count = 0, i; + + MD5Init (&MD); /* initialize MD5 */ + + + + +Blumenthal & Wijnen Standards Track [Page 71] + +RFC 2264 USM for SNMPv3 January 1998 + + + /**********************************************/ + /* Use while loop until we've done 1 Megabyte */ + /**********************************************/ + while (count < 1048576) { + cp = password_buf; + for (i = 0; i < 64; i++) { + /*************************************************/ + /* Take the next octet of the password, wrapping */ + /* to the beginning of the password as necessary.*/ + /*************************************************/ + *cp++ = password[password_index++ % passwordlen]; + } + MD5Update (&MD, password_buf, 64); + count += 64; + } + MD5Final (key, &MD); /* tell MD5 we're done */ + + /*****************************************************/ + /* Now localize the key with the engineID and pass */ + /* through MD5 to produce final key */ + /* May want to ensure that engineLength <= 32, */ + /* otherwise need to use a buffer larger than 64 */ + /*****************************************************/ + memcpy(password_buf, key, 16); + memcpy(password_buf+16, engineID, engineLength); + memcpy(password_buf+engineLength, key, 16); + + MD5Init(&MD); + MD5Update(&MD, password_buf, 32+engineLength); + MD5Final(key, &MD); + + return; +} + +A.2.2. Password to Key Sample Code for SHA + +void password_to_key_sha( + u_char *password, /* IN */ + u_int passwordlen, /* IN */ + u_char *engineID, /* IN - pointer to snmpEngineID */ + u_int engineLength /* IN - length of snmpEngineID */ + u_char *key) /* OUT - pointer to caller 20-octet buffer */ +{ + SHA_CTX SH; + u_char *cp, password_buf[72]; + u_long password_index = 0; + u_long count = 0, i; + + + + +Blumenthal & Wijnen Standards Track [Page 72] + +RFC 2264 USM for SNMPv3 January 1998 + + + SHAInit (&SH); /* initialize SHA */ + + /**********************************************/ + /* Use while loop until we've done 1 Megabyte */ + /**********************************************/ + while (count < 1048576) { + cp = password_buf; + for (i = 0; i < 64; i++) { + /*************************************************/ + /* Take the next octet of the password, wrapping */ + /* to the beginning of the password as necessary.*/ + /*************************************************/ + *cp++ = password[password_index++ % passwordlen]; + } + SHAUpdate (&SH, password_buf, 64); + count += 64; + } + SHAFinal (key, &SH); /* tell SHA we're done */ + + /*****************************************************/ + /* Now localize the key with the engineID and pass */ + /* through SHA to produce final key */ + /* May want to ensure that engineLength <= 32, */ + /* otherwise need to use a buffer larger than 72 */ + /*****************************************************/ + memcpy(password_buf, key, 20); + memcpy(password_buf+20, engineID, engineLength); + memcpy(password_buf+engineLength, key, 20); + + SHAInit(&SH); + SHAUpdate(&SH, password_buf, 40+engineLength); + SHAFinal(key, &SH); + + return; +} + +A.3. Password to Key Sample Results + +A.3.1. Password to Key Sample Results using MD5 + + The following shows a sample output of the password to key algorithm + for a 16-octet key using MD5. + + With a password of "maplesyrup" the output of the password to key + algorithm before the key is localized with the SNMP engine's + snmpEngineID is: + + '9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H + + + +Blumenthal & Wijnen Standards Track [Page 73] + +RFC 2264 USM for SNMPv3 January 1998 + + + After the intermediate key (shown above) is localized with the + snmpEngineID value of: + + '00 00 00 00 00 00 00 00 00 00 00 02'H + + the final output of the password to key algorithm is: + + '52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H + +A.3.2. Password to Key Sample Results using SHA + + The following shows a sample output of the password to key + algorithm for a 20-octet key using SHA. + + With a password of "maplesyrup" the output of the password to key + algorithm before the key is localized with the SNMP engine's + snmpEngineID is: + + 'f1 be a9 ae 66 7f 4f b6 34 1e 51 af 06 80 7e 91 e4 3b 01 ac'H + + After the intermediate key (shown above) is localized with the + snmpEngineID value of: + + '00 00 00 00 00 00 00 00 00 00 00 02'H + + the final output of the password to key algorithm is: + + '8a a3 d9 9e 3e 30 56 f2 bf e3 a9 ee f3 45 d5 39 54 91 12 be'H + +A.4. Sample encoding of msgSecurityParameters + + The msgSecurityParameters in an SNMP message are represented as an + OCTET STRING. This OCTET STRING should be considered opaque outside a + specific Security Model. + + The User-based Security Model defines the contents of the OCTET + STRING as a SEQUENCE (see section 2.4). + + Given these two properties, the following is an example of the + msgSecurityParameters for the User-based Security Model, encoded as + an OCTET STRING: + + 04 <length> + 30 <length> + 04 <length> <msgAuthoritativeEngineID> + 02 <length> <msgAuthoritativeEngineBoots> + 02 <length> <msgAuthoritativeEngineTime> + 04 <length> <msgUserName> + + + +Blumenthal & Wijnen Standards Track [Page 74] + +RFC 2264 USM for SNMPv3 January 1998 + + + 04 0c <HMAC-MD5-96-digest> + 04 08 <salt> + + Here is the example once more, but now with real values (except for + the digest in msgAuthenticationParameters and the salt in + msgPrivacyParameters, which depend on variable data that we have not + defined here): + + Hex Data Description + -------------- ----------------------------------------------- + 04 39 OCTET STRING, length 57 + 30 37 SEQUENCE, length 55 + 04 0c 80000002 msgAuthoritativeEngineID: IBM + 01 IPv4 address + 09840301 9.132.3.1 + 02 01 01 msgAuthoritativeEngineBoots: 1 + 02 02 0101 msgAuthoritativeEngineTime: 257 + 04 04 62657274 msgUserName: bert + 04 0c 01234567 msgAuthenticationParameters: sample value + 89abcdef + fedcba98 + 04 08 01234567 msgPrivacyParameters: sample value + 89abcdef + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blumenthal & Wijnen Standards Track [Page 75] + +RFC 2264 USM for SNMPv3 January 1998 + + +B. Full Copyright Statement + + Copyright (C) The Internet Society (1997). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Blumenthal & Wijnen Standards Track [Page 76] + |