HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 12:01:42 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 12 Sep 1995 22:00:00 GMT ETag: "3ddb70-1b1fb-305602e0" Accept-Ranges: bytes Content-Length: 111099 Connection: close Content-Type: text/plain Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 User-Based Symmetric Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2) Fri Sep 08 1995 draft-various-snmpv2-sec-syn-00.txt Tell U. Later snmpv2@tis.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires February 1996 [Page 1] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 running list of open issues reference list reference citations acknowledgements authors author addresses spell check mib needs to be re-checked for rationality with the text improve compliance/conformance statement for the protocols and mib horizontal spacing / column alignment in the mib Expires February 1996 [Page 2] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 1. Introduction A management system contains: several (potentially many) manageable nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol. The management protocol is used to convey management information between the agents and management stations; and, for manager-to-manager communications, between management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. The Administrative Model for SNMPv2 document [@ref v2admin] defines a framework and an administrative model which realizes effective management in a variety of configurations and environments. In the administrative model, there are provisions for multiple authentication and privacy services (identified by the security protocol identifier, sPI) to achieve various objectives. Each manager (including a dual-role entity acting in a manager role) and each agent (including a dual-role entity acting in an agent role) implements one or more of these types of service. Although many such types of authentication and privacy services might be defined, it is the purpose of this document, User-Based Symmetric Security Protocols for SNMPv2, to define three such services; one service supporting neither authentication nor privacy (usecNoAuth(4)), one service supporting authentication but not privacy (usecAuth(5)), and another supporting both authentication and privacy (usecPriv(6)). The model defined by the administrative framework also includes provisions for access control. The enforcement of access rights requires the means to identify the entity on whose behalf a request is generated. That is, authentication is a functional prerequisite to access control. The SNMPv2 security services described herein identify an entity on whose behalf an SNMPv2 message is generated as a "user". For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). This document is a part Expires February 1996 [Page 3] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 of the current framework, termed the SNMP version 2 framework (SNMPv2). Expires February 1996 [Page 4] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 1.1. Threats Several of the classical threats to network protocols are applicable to the management problem and therefore would be applicable to any SNMPv2 security service. Other threats are not applicable to the management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance. The principal threats against which the SNMPv2 security service described herein should provide protection are: Modification of Information The modification threat is the danger that some unauthorized entity may alter in-transit SNMPv2 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 protocols defined in this memo do provide protection against: Message Stream Modification The SNMPv2 protocol is typically based upon a connectionless transport service which may operate over any subnetwork service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such subnetwork 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 subnetwork service, in order to effect unauthorized management operations. Disclosure The disclosure threat is the danger of eavesdropping on the SNMPv2 messages as they are transmitted through the network. Protecting against this threat may be required as a matter of local policy. There are at least two threats that an SNMPv2 security protocol need not protect against. The security protocols defined in this memo do not provide protection against: Expires February 1996 [Page 5] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 Denial of Service An SNMPv2 security protocol need 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 management protocol must cope as a matter of course. Traffic Analysis In addition, an SNMPv2 security protocol need not attempt to address traffic analysis attacks. Indeed, many traffic patterns are predictable - agents may be managed on a regular basis by a relatively small number of management stations - 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 management environment, the goals of the SNMPv2 security protocols described herein are enumerated as follows. (1) The protocol should provide for verification that each received SNMPv2 message has not been modified during its transmission through the network in such a way that an unauthorized management operation might result. (2) The protocol should provide for verification of the identity of the user on whose behalf a received SNMPv2 message claims to have been generated. (3) The protocol should provide for detection of received SNMPv2 messages whose time of generation was not recent. (4) The protocol should provide, when necessary, that the contents of each received SNMPv2 message are protected from disclosure. In addition to the principal goal of supporting secure management, the design of any SNMPv2 security protocol 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. Expires February 1996 [Page 6] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 (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 the Domain Name System (DNS). (3) A security mechanism should entail no changes to the basic SNMP management philosophy. 1.3. Security Services The security services necessary to support the goals of an SNMPv2 security protocol are as follows. Data Integrity is the provision of the property that data have 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. For the protocols specified in this memo, it is not possible to ascertain the specific originator of a received SNMPv2 message; rather, it is the user on whose behalf the message was originated that is authenticated. For these protocols, it is 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 design of the administrative model allows the security protocols described in this memo to be replaced or supplemented with additional security protocols to be specified at a future time if the need arises. Expires February 1996 [Page 7] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 1.4. Mechanisms The security protocols defined in this memo employ several types of mechanisms in order to realize the goals and security services described above: - Data Integrity: A message digest algorithm is utilized in support of data integrity. A digest is calculated over an appropriate portion of an SNMPv2 message and included as part of the message sent to the recipient. - Data Origin Authentication: A secret value is inserted into the SNMPv2 message prior to computing the digest and then overwritten prior to transmission in support of data origin authentication and data integrity. The secret value is shared by all SNMPv2 entities authorized to originate messages on behalf of the appropriate user. - Replay Protection: To protect against the threat of message delay or replay, (to an extent greater than can occur through normal operation), a set of time indicators is included in each message generated. A recipient evaluates the time indicators to determine if the message is 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. Other mechanisms defined independently of the security protocol can also be used to detect message replay (e.g., the request-id [@ref protoops]), or for set operations, the re-ordering, replay, deletion, or suppression of messages (e.g., the MIB variable snmpSetSerialNo [@ref v2mib4v2]). - Data Confidentiality: A symmetric encryption algorithm is utilized in support of data confidentiality. An appropriate portion of the message is encrypted prior to being transmitted. Expires February 1996 [Page 8] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 1.4.1. Digest Authentication Protocol The Digest Authentication Protocol utilizes a message digest algorithm in conjunction with loosely synchronized monotonically increasing time indicators as mechanisms to address the goals of data origin authentication, data integrity, and message delay or replay. The Digest Authentication Protocol defined in this memo provides several functions. These include: - Verifying the integrity of a received message (i.e., the message was not modified during transit). The integrity of the message is protected by computing a digest over an appropriate portion of a message. The digest is computed by the originator of the message, transmitted with the message, and verified by the recipient of the message. The nature of the digest computation is such that undetected alteration of a message is computationally infeasible without knowledge of secret values. - Verifying the user on whose behalf the message was generated. A secret value known only to SNMPv2 entities authorized to generate messages on behalf of this user is inserted into the message prior to the digest computation. Thus, the verification of the user is implicit with the verification of the digest. - Verifying that a message sent to/from one agent or manager cannot be replayed to/as-if-from another agent or manager. Included in each message is an identifier which is unique to the protocol engine of the SNMPv2 protocol entity which is the sender or intended recipient of the message. - Detecting 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. This protocol uses the MD5 [@ref md5] message digest algorithm. A 128- bit digest is calculated over the designated portion of an SNMPv2 message and included as part of the message sent to the recipient. The Expires February 1996 [Page 9] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 size of both the digest carried in a message and the private authentication key is 16 octets. This memo allows the same user to be defined on multiple SNMPv2 agents and managers. Every SNMPv2 protocol entity maintains a value, snmpID, which uniquely and unambiguously identifies the protocol engine. Each SNMPv2 protocol entity which implements the usecNoAuth(4), usecAuth(5), or usecPriv(6) authentication and privacy services maintains a value, authSnmpID, which uniquely and unambiguously identifies the usecNoAuth(4), usecAuth(5), and usecPriv(6) protocol engine of the SNMPv2 protocol entity. The authSnmpID is equal to the snmpID of the protocol entity. For example, each SNMPv2 protocol entity, whether it acts in an agent role, a manager role, or some combined role, has a snmpID, which is used as the authSnmpID for messages to or from that entity that are based on its authoritative authentication information. For traffic to or from an SNMPv2 agent, the value of snmpID for the agent is assigned to authSnmpID in each authenticated message sent to/from the agent. (See [@ref proxyops] for special rules for proxy agents in this regard.) On receipt of a message, an agent checks the value to ensure it is the intended recipient, and a manager uses the value to ensure that the message is processed using the correct state information for that agent. Similar mechanisms are used for traffic between two entities with each acting in a manager role. Each SNMPv2 protocol entity which implements the usecAuth(5) authentication service or the usecPriv(6) authentication and privacy service maintains two additional values, authSnmpBoots and authSnmpTime, which together provide an indication of time at that entity. For example, an SNMPv2 agent maintains both of these values which, when taken together, provide an indication of time at that agent. Both of these values are included in authenticated messages sent to/received from that agent. (See [@ref proxyops] for special rules for proxy agents in this regard.) On receipt, the values are checked to ensure that the indicated time is within a time window of the current time. The time window represents an administrative upper bound on acceptable delivery delay for protocol messages. Similar mechanisms are used for traffic between two entities with each acting in a manager role. Every SNMP transaction is between two protocol entities. Because both entities base their security algorithms on information known to them in their local databases, conflict could arise if those databases are not consistent. Therefore it is useful to resolve conflicts by explicitly identifying one particular database that is correct by definition. An SNMPv2 entity is considered the authoritative source of information, or simply authoritative, for information that it maintains in its Expires February 1996 [Page 10] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 configuration store. Every SNMPv2 message is sent with either the receiver or sender identified as the authoritative source of information upon which that message is based. The non-authoritative participant in any transaction will maintain a database containing the authoritative information for each peer SNMPv2 entity it knows about. When processing a communication, the non-authoritative entity finds that it doesn't have required information about the authoritative entity or that its information is incorrect, it is the responsibility of the non- authoritative entity to acquire the correct information. Every SNMPv2 protocol entity which implements the usecAuth(5) or usecPriv(6) authentication and privacy services maintains values of authSnmpID, authSnmpBoots, and authSnmpTime and is authoritative for those values. Every SNMPv2 message which uses the usecNoAuth(4), usecAuth(5), or usecPriv(6) services contains a authSnmpID value which identifies the snmpID of the entity that is authoritative for that message. When using the authentication and privacy services specified in this memo, time synchronization must be achieved in order for an exchange between two SNMPv2 protocol entities (i.e., a transaction between a manager and an agent, two managers, a manager and a proxy agent, two proxy agents, or a proxy agent and a manager), to be determined to be timely and authentic according to the usecAuth(5) or usecPriv(6) services. [In the case of a multi-hop relationship, (e.g., manager, proxy agent, agent or manager, proxy agent, manager, etc) then the time synchronization is achieved between the endpoints on a hop-by-hop basis.] In order to achieve this time synchronization, the non- authoritative entity must update its notion of the authoritative entity's time. For example, for an SNMPv2 manager to generate a message which an agent will accept as authentic, and to verify that a message received from an agent is authentic, that manager must first achieve time synchronization with that agent. This memo specifies that the usecAuth(5) and usecPriv(6) authentication services use secret keys of length 16 octets in conjunction with that algorithm. Within an authenticated management communication generated by such these services, the size of the authDigest value of that communication (see Section 2.1) is 16 octets. Expires February 1996 [Page 11] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 1.4.2. Symmetric Encryption Protocol In support of data confidentiality, the use of the Data Encryption Standard (DES) in the Cipher Block Chaining mode of operation is chosen. The designated portion of an SNMPv2 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) [@ref des] and the American National Standards Institute [@ref dea]. There is a companion Modes of Operation specification for each definition (see [@ref desmoo] and [@ref deamoo], 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 [@ref desguidelines]. - There is a specification of a validation test suite for the DES [@ref desvalidating]. 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 [@ref desmaintest]. 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 reboots. This memo specifies that the usecPriv(6) authentication and privacy services use secret keys of length 16 octets, of which the first eight octets are a DES key and the second eight octets are a DES Initialization Vector. The 64-bit DES key in the first eight octets of the private key is a 56 bit quantity used directly by the algorithm plus eight parity bits - arranged so that one parity bit is the least significant bit of each octet. The setting of the parity bits is ignored. The length of the octet sequence to be encrypted by the DES must be an integral multiple of eight. When encrypting, the data should be padded at the end as necessary; the actual pad value is irrelevant. However, an implementation should take care to avoid accidental disclosure of information through the inclusion Expires February 1996 [Page 12] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 of uninitialized pad values. Consequently, it is suggested that implementations initialize the padded values to a constant value; zero is recommended as an obvious choice. As described in the Elements of Procedure, if the length of the octet sequence to be decrypted is not an integral multiple of eight octets, the processing of the octet sequence is halted and an appropriate exception noted. Upon decrypting, the padding should be ignored. Expires February 1996 [Page 13] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 2. Elements of the Service This section contains definitions required to realize the authentication and privacy services defined by this memo. 2.1. SNMPv2 Users Management operations using this security model make use of a defined set of user identities. For any SNMPv2 user on whose behalf management operations are authorized at a particular SNMPv2 agent, that agent must have knowledge of that user. A SNMPv2 manager that wishes to communicate with a particular agent must also have knowledge of a user known to that agent, including knowledge of the applicable attributes of that user. A user and its attributes are defined as follows: An octet string representing the name of the user. The name of the set of access rights assigned to this user. The user's (private) authentication key if the usecAuth(5) or usecPriv(6) services are provided and messages sent on behalf of this user can be authenticated. Note that a user's authentication key may be different at different SNMPv2 entities, e.g., managers and agents. The user's (private) privacy key if the usecPriv(6) service is provided and messages sent on behalf of this user can be protected from disclosure. Note that a user's privacy key may be different at different agents. All users are capable of having messages without authentication and privacy generated on their behalf. Users having an authentication key can have messages with authentication but not privacy generated on their behalf. Users having an authentication key and a privacy key can have messages with authentication and privacy generated on their behalf. Authoritative SNMPv2 protocol entities must retain the attributes above for all users in non-volatile storage. Expires February 1996 [Page 14] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 2.2. Values of sPI This memo defines authentication and privacy services associated with three values of sPI, as follows: o 4 usecNoAuth o 5 usecAuth o 6 usecPriv Other values of sPI are allocated as specified in [@ref v2admin]. An implementation may choose to implement the usecNoAuth(4) service, both the usecNoAuth(4) and usecAuth(5) services, or all three services (usecNoAuth(4), usecAuth(5), and usecPriv(6)). No other combinations are valid, i.e., usecNoAuth(4) is a prerequisite for usecAuth(5), and usecAuth(5) is a prerequisite for usecPriv(6). 2.3. Replay Protection Each SNMPv2 protocol entity, i.e., each manager and each agent, which implements the usecAuth(5) or usecPriv(6) services, maintains three objects in support of replay protection: - snmpID, which, among other uses, is used to identify an SNMP protocol entity as authoritative for a transaction, - authSnmpBoots, which is a count of the number of times the SNMPv2 protocol entity has rebooted/re-initialized since authSnmpID was last configured; and, - authSnmpTime, which is the number of seconds since authSnmpBoots was last incremented. SNMPv2 entities are always authoritative with respect to their own values of these variables. They may also have non-authoritative notions of these values for other SNMPv2 entities. Note that an entity will have exactly one instance of the values it is authoritative for, but may have many instances of these values for non-authoritative peers. These non-authoritative notions must be synchronized with the authoritative values from time-to-time as described in a later section. Expires February 1996 [Page 15] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 A SNMPv2 protocol entity is required to maintain the value of snmpID and authSnmpBoots in non-volatile storage. These are critical components of the overall security of the authentication protocol. The SNMPv2 entity must be able to ensure that on each bootup, that authSnmpBoots is larger than it ever was previously. 2.3.1. snmpID The snmpID value contained in an authenticated message is used to defeat attacks in which messages from one SNMPv2 protocol entity are replayed as if from a different SNMPv2 protocol entity. Examples include attacks in which messages from a manager are replayed to a different agent and/or messages from one agent are replayed as if from a different agent. When a SNMPv2 protocol entity is first installed, it sets its local value of snmpID according to a enterprise-specific algorithm (see the definition of snmpID in Section 4.1). 2.3.2. authSnmpBoots and authSnmpTime The authSnmpBoots and authSnmpTime values contained in an authenticated message are used to defeat attacks in which messages from a manager are replayed to the same destination at a time when they are no longer valid. Through use of authSnmpBoots and authSnmpTime, there is no requirement for an SNMPv2 protocol entity to have a non-volatile clock which ticks (i.e., increases with the passage of time) even when the SNMPv2 protocol entity is powered off. Rather, each time an SNMPv2 protocol entity reboots, it retrieves, increments, and then stores authSnmpBoots in non-volatile storage, and resets authSnmpTime to zero. When an SNMPv2 protocol entity is first installed, it sets its local values of authSnmpBoots and authSnmpTime to zero. If authSnmpTime ever reaches its maximum value (2147483647), then authSnmpBoots is incremented as if the SNMPv2 protocol entity has rebooted and authSnmpTime is reset to zero and starts incrementing again. Each time an SNMPv2 protocol entity reboots, any SNMPv2 managers holding that entity's values of authSnmpBoots and authSnmpTime need to re- synchronize prior to sending correctly authenticated messages to that entity. If an SNMPv2 protocol entity is ever unable to determine its latest authSnmpBoots value, then it must set its authSnmpBoots value to 0xffffffff. Expires February 1996 [Page 16] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 Whenever the local value of authSnmpBoots has the value 0xffffffff, it latches at that value and an authenticated message always causes an snmpStatsNotInTimeWindows authentication failure. In order to reset an SNMPv2 protocol entity whose authSnmpBoots value has reached the value 0xffffffff, manual intervention is required. The SNMPv2 protocol entity must be physically visited and re-configured, either with a new snmpID value, or with new secret values for the authentication and privacy keys of all users known to that SNMPv2 protocol entity. 2.3.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.4. Error Reporting While processing a received communication, an SNMPv2 authentication and privacy service may determine that the message is unacceptable. In this case, the appropriate counter in the usecBasicGroup object group of the MIB module contained in this memo is incremented and the requester is advised that the message is unauthentic. If an SNMPv2 protocol entity makes such a determination, and if the reportableFlag is set, then after incrementing the appropriate counter, it is sometimes specified in the elements of procedure that a report PDU should be generated and sent to the transport address which originated the received message. A message containing a report PDU must always be sent with the reportableFlag clear in the security flags. The report PDU sent from the authentication and privacy services defined in this memo are always sent using an sPI value of maint(3) except for the situation in which the incremented counter was snmpStatsNotInTimeWindows, in which case the report PDU is always sent using usecAuth(5). If the entity is able to determine the request-id field of the received PDU, then it uses that value for the request-id field of the report PDU. Otherwise, the value 2147483647 is used. Expires February 1996 [Page 17] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 The error-status and error-index fields of the report PDU are always set to zero. The variable-bindings field contains a single variable: the identity of the statistics counter which was incremented and its new value. A report PDU is never sent in response to a report PDU. A protocol entity makes this determination by examining the reportableFlag of the received message and only sending report PDUs when the reportableFlag is set. Several additional parameters must be provided to the protocol engine to send the reports. For reports which are sent with an sPI value of maint(3), the identityName (and thereby the userName) is "report". For reports which are sent from the authentication and privacy services defined in this memo with an sPI value of usecAuth(5), the userName is set to be the same as the userName in the received message which invoked the report operation. The secret authentication key associated with that user is used in the generation of the authenticated message. In either case, the authSnmpID and contextSnmpID are set to the value of snmpID for the local (generating) SNMPv2 protocol entity. The contextName is set to "default". The message containing the report is then processed in accordance with the procedures specified in the section entitled "Generating an SnmpV2AuthMessage Component", serialized as an SnmpV2Message with the reportableFlag portion of the security flags field set to false, and the sent to the source of the original received message according to the procedures specified in [@ref v2admin]. 2.3.5. Time Synchronization An SNMPv2 entity always has correct time synchronization for those transactions for which it is authoritative. When an SNMPv2 entity is non-authoritative for an authenticated transaction, it must achieve time synchronization with its peer. First, if it has no notion of the authSnmpBoots and authSnmpTime value for its peer, it must initialize both of these values to zero. Then, in any Expires February 1996 [Page 18] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 case, it sends the transaction as it would normally. If the transaction is authenticated (either usecAuth(5) or usecPriv(6)) and otherwise correct but the time is not synchronized, the peer will reply with a message containing a reportPDU which is authenticated with usecAuth(5) using the userName of the request packet. The message conveying the report PDU contains the correct values of authSnmpBoots and authSnmpTime. The receiving protocol engine will update its values of authSnmpBoots and authSnmpTime for that entity if and only if the report PDU was authenticated and contained the correct digest value (but wasn't necessarily within the lifetime). Note that this mechanism can synchronize any SNMPv2 entity, independent of the existence of an agent at either end of the transaction. 2.3.5.1. Time Synchronization for Traps Because traps are not sent in a request-response fashion, another mechanism is required. Traps are sent from an agent, which is authoritative, to a manager. The recommended mechanism for the manager to synchronize time with the agent is to initiate a usecAuth(5) request-response transaction with the agent (a usecAuth(5) Get request of any arbitrary variable is appropriate). This transaction can be executed periodically to keep the timers up to date, or in response to a received trap that was out of lifetime. In the latter case, authentication processing of the trap can be deferred and repeated when the time is resynchronized. 2.4. Local Configuration Datastore (LCD) Each SNMPv2 protocol entity maintains a local conceptual database, called the Local Configuration Datastore (LCD), which holds its known set of information about SNMPv2 users and other associated (e.g., access control) information. It is a local implementation issue as to whether information in the LCD is stored information or whether it is obtained dynamically (e.g., as a part of an SNMPv2 manager's API) on an as-needed basis. 2.5. SnmpV2AuthMessage Format Each authentication and privacy service must define the AuthInfo sequence associated with the service. All three services defined in this memo, e.g., usecNoAuth(4), usecAuth(5), and usecPriv(6), use the same format, which is summarized in Figure 1. Expires February 1996 [Page 19] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 | <------------------------------------ SnmpV2AuthMessage ----------> | | <-------- ScopedPDU ------------> | | authInfo | ContextInfo | PDU | +---------------------------------+---------------+-------------------+ | s | | u | S | S | | s | | | s p | | | e | s | s | n | n | D | e | c S | c | e d | | | q | a n | e | a m | a m | a i | q | o n | o n | q u | | | = | u m | r | u p | u p | u g | = | n m | n a | = | | P | | 0 | t p | N | t B | t T | t e | 0 | t p | t m | t | D | | a | h I | a | h o | h i | h s | a | e I | e e | y | U | | 9 | D | m | o | m | t | a | x D | x | p | | | h | | e | t | e | | h | t | t | e | | | | | | s | | | | | | | | +---------------------------------+---------------+-------------------+ Figure 1: Usec-based SnmpV2AuthMessage Format 2.6. AuthInfo ASN.1 Definition The formal ASN.1 definition for the AuthInfo portion of the SnmpV2AuthMessage is as follows: AuthInfo ::= [9] IMPLICIT SEQUENCE { authSnmpID OCTET STRING (SIZE(12)), userName OCTET STRING (SIZE(1..32)), authSnmpBoots Integer32 (0..2147483647), authSnmpTime Integer32 (0..2147483647), authDigest OCTET STRING (SIZE(0|16)) } This same format is used by all three authentication and privacy services defined in this memo, e.g., usecNoAuth(4), usecAuth(5), and usecPriv(6). Expires February 1996 [Page 20] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 3. Elements of Procedure These procedures, which provide the usecNoAuth(4), usecAuth(5), and usecPriv(6) authentication and privacy services, are invoked on behalf of a user. There are two basic sets of procedures: generating an SnmpV2AuthMessage component from parameters provided by a requester, and processing a received SnmpV2AuthMessage component. 3.1. Generating an SnmpV2AuthMessage Component This section describes the procedure followed by the authentication and privacy service whenever it is requested by an application to generate an SnmpV2AuthMessage component with a sPI value corresponding to usecNoAuth(4), usecAuth(5), or usecPriv(6) on behalf of a user. The requester must provide the following parameters: - sPI, corresponding to any one of usecNoAuth(4), usecAuth(5), or usecPriv(6), a definitive identification of the type of authentication and privacy service requested; - identityName; - authSnmpID, unique identification of an instance of the administrative model, i.e., an SNMPv2 protocol engine; and - a ScopedPDU message component, consisting of context information prepended to a PDU sequence. Upon completion of the required processing, the service provides an SnmpV2AuthMessage value. The basic approach is that the SnmpV2AuthMessage value is generated by first privatizing the PDU, then adding context and authentication information to the result. The detailed steps are as follows. (1) Information concerning the user is extracted from the userNameTable in the LCD. If there is no such information, then the message cannot be sent and the requesting application is suitably advised. Note that the information may have been entered into the LCD by the application shortly before the application requested the generation of this SnmpV2AuthMessage component. If the sPI indicates that the message is to be authenticated, i.e., Expires February 1996 [Page 21] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 the value of sPI corresponds to usecAuth(5) or usecPriv(6), but the authentication key is not configured or is not 16 octets in length, then the message cannot be sent and the requesting application is suitably advised. If the sPI indicates that the message is to be authenticated and protected from disclosure i.e., the value of sPI corresponds to usecPriv(6), but the privacy key is not configured, then the message cannot be sent and the requesting application is suitably advised. (2) A PlainOrEncryptedPDU value [@ref v2admin] is serialized according to the conventions of [@ref tm]: if the sPI specifies that the message is to be protected from disclosure, i.e., the value of sPI corresponds to usecPriv(6), then the octet sequence representing the serialized PDUs value is encrypted using the user's privacy key, and the encrypted string is used as the value of the data component; and if the sPI specifies that the message is not to be protected from disclosure, i.e., the value of sPI corresponds to usecNoAuth(4) or usecAuth(5), then the serialized PDUs value is used directly as the value of the data component. (3) A ScopedPDU value [@ref v2admin] is constructed from the context information provided by the requesting application (contextName and contextSnmpID) and the PlainOrEncryptedPDU value produced in the preceeding step. (4) An AuthInfo value is constructed as follows. The userName is set to the value of identityName provided by the requesting application. The authSnmpID is set to the value provided by the requesting application. If authentication is requested, i.e., the value of sPI corresponds to either usecAuth(5) or usecPriv(6), then - The LCD is consulted to retrieve the current value for authSnmpBoots associated with the provided value of authSnmpID and the retrieved value is assigned to authSnmpBoots. If the LCD has no such value, then the value zero is assigned to authSnmpBoots. - The LCD is consulted to retrieve the current value for authSnmpTime associated with the provided value of authSnmpID and the retrieved value is assigned to authSnmpTime. If the LCD has no such value, then the value zero is assigned to authSnmpTime. Expires February 1996 [Page 22] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 - The LCD is consulted to retrieve the value of the authentication key associated with the userName and authSnmpID. The retrieved value is temporarily assigned to the authDigest. Otherwise, i.e., the value of sPI corresponds to usecNoAuth(4), the values of authSnmpBoots, authSnmpTime, and authDigest are assigned the values 0, 0, and the zero length OCTET STRING, respectively. The AuthInfo value is serialized according to the conventions of [@ref tm]. (5) The constructed SnmpV2AuthMessage value is serialized (i.e., encoded) according to the conventions of [@ref tm]. (6) If and only if authentication is requested, i.e., the sPI corresponds to either usecAuth(5) or usecPriv(6), then an MD5 digest value is computed over the octet sequence representing the serialized SnmpV2AuthMessage value including the outermost tag and length fields of the encoded sequence. The portion of the serialized SnmpV2AuthMessage corresponding to the authDigest value is set to the result of the digest computation. The SnmpV2AuthMessage resulting from these operations is then returned from the authentication and privacy service to the requester. Expires February 1996 [Page 23] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 3.2. Processing a Received Communication This section describes the procedure followed by the authentication and privacy service whenever a requester provides an SnmpV2AuthMessage component with a sPI value which corresponds to usecNoAuth(4), usecAuth(5), or usecPriv(6) to be processed on behalf of a user. The requester must provide the following parameters: - an SnmpV2AuthMessage value as defined by [@ref v2admin]; and - sPI, corresponding to any one of usecNoAuth(4), usecAuth(5), or usecPriv(6), a definitive identification of the type of authentication and privacy service requested. Upon completion of the required processing, the service provides: - an identityName; - a groupName; - an authSnmpID; and - a plaintext ScopedPDU. The basic approach is that the SnmpV2AuthMessage is parsed, checked for authenticity, if appropriate, and decrypted, if appropriate. The detailed steps are as follows: (1) If the received message is not the serialization (according to the conventions of [@ref v2admin]) of an SnmpV2AuthMessage value, then the snmpStatsEncodingErrors counter [@ref v2mib4v2] is incremented, a Report PDU is generated, and the message is discarded without further processing. (2) The values of the individual fields are extracted from the AuthInfo portion of the SnmpV2AuthMessage value, i.e., authSnmpID, userName, authSnmpBoots, authSnmpTime, and authDigest. (3) Information about the user identified by the userName and authSnmpID values is extracted from the LCD. If no such information is available, then the usecStatsUnknownUserNames counter is incremented, a report PDU is generated, and the requester is advised that the message is not authentic. Otherwise, Expires February 1996 [Page 24] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 the identityName is set to the userName, and the groupName is set to the value extracted from the LCD associated with the user. The value of userTransportLabel is extracted, if present. In addition, values are extracted for the user's private authentication and private privacy keys, if any. (4) If the sPI value indicates that the message is not authenticated, i.e., the value of sPI corresponds to usecNoAuth(4), then the values of authSnmpBoots, authSnmpTime, and authDigest are ignored. (5) The source address is then validated. If the extracted value of userTransportLabel is zero octets in length, or not present, which indicate that source address validation is not desired or not implemented, then the source address is considered valid. If the userTransportLabel is non-null, the transportTable [@ref adminmib] is consulted. All entries in the transport table corresponding to the userTransportLabel are examined which match the received transport domain. If, for any one or more entries, the entry's transportAddress logically anded with the entry's transportReceiveMask is equal to the source address of the message anded with the entry's transportReceiveMask, then the values of transportSnmpID, and transportMMS are extracted, and the source address is considered valid. Otherwise, the usecStatsUnknownUserNames counter is incremented, a report PDU is generated, and the requester is advised that the message is not authentic. (6) If the sPI value indicates that the message is authenticated, i.e., the value of sPI corresponds to usecAuth(5) or usecPriv(6), then the message is checked for authenticity: - The received authDigest value is temporarily saved. A new serialized SnmpV2AuthMessage is constructed which differs from that received in exactly one respect: that the authDigest field within it has the value of the user's authentication key extracted from the LCD, above. If the length of the extracted authentication key is not exactly 16 octets, then the usecStatsWrongDigestValues counter is incremented, a report PDU is generated, and the requester is advised that the message is not authentic. Expires February 1996 [Page 25] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 NOTE Because serialization rules are unambiguous but may not be unique, great care must be taken in reconstructing the serialized value prior to computing the digest. Implementations may find it useful to keep a copy of the original serialized value and then simply modify the octets which directly correspond to the placement of the authDigest component, rather than re-applying the serialization algorithm to the new SnmpV2AuthMessage value. An MD5 digest value is computed over the octet sequence representing the new serialized SnmpV2AuthMessage value not including the outermost tag and length fields of the encoded sequence. If the computed digest differs from the saved authDigest value, then the usecStatsWrongDigestValues counter is incremented, a report PDU is generated, and the requester is advised that the message is not authentic. - The LCD is examined to extract local values for authSnmpBoots and authSnmpTime which correspond to the received value of authSnmpID. If the received value of authSnmpBoots is less than the extracted value, or the received value of authSnmpBoots is equal to the extracted value but the received value of authSnmpTime is less than the extracted value by more than 150 seconds, then the snmpStatsNotInTimeWindows counter is incremented, a report PDU is generated, and the requester is advised that the message is not authentic. Note that this step allows for the received value of authSnmpBoots to be greater than the local value of authSnmpBoots. This allows for notifications to be accepted as authentic when received from an agent that has rebooted since the manager last re-synchronized. - The LCD entry corresponding to the value of authSnmpID is updated by setting the local values of authSnmpBoots and authSnmpTime to the received values, if the received values in combination are greater than the local non-authoritative values. (7) If the sPI value indicates that the message is protected from disclosure, i.e., the value of sPI corresponds to usecPriv(6), then Expires February 1996 [Page 26] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 the appropriate portion of the message is decrypted: - The extracted value of the user's private privacy key is examined. If the length of the extracted privacy key is not exactly 16 octets, then the usecStatsBadPrivacys counter is incremented, a report PDU is generated, and the requester is advised that the message is not authentic. - The appropriate portion of the ScopedPDU value is decrypted using the the extracted privacy key and a plaintext ScopedPDU value is produced. However, if the length of the octet sequence is not an integral multiple of eight octets, then the usecStatsBadPrivacys counter is incremented, a report PDU is generated, and the requester is advised that the message is not authentic. (8) The resulting identityName, groupName, authSnmpID, and plaintext ScopedPDU are delivered to the requester and the requester is advised that the message is authentic. 3.3. Discussion of Distribution of Secrets and Time Information Every SNMP protocol engine which implements this specification will have authoritative values of the following: o authSnmpBoots, and o authSnmpTime. o a [possibly null] list of users and associated secrets These authoritative values will be used by that protocol engine whenever the protocol engine receives any of the following operations: o Get, o GetNext, o Set, o GetBulk, and o Inform. Expires February 1996 [Page 27] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 That is, the protocol engine that sends these PDUs must know (or somehow discover), and use, the values that are authoritative in the destination protocol engine. Similarly, the protocol engine that receives these operations, sends responses, and optionally sends traps, must use its authoritative values when validating incoming messages or generating outgoing messages. Note that this means that authoritative information is stored on managers that receive informs as well as on agents. It is instructive to note the symmetry with the Report PDU in that the Report PDU is only sent by a protocol engine when it is reporting that it received information that was inconsistent with its authoritative datastore. Because time information and secrets are authoritative on only one of the two protocol engines involved in an SNMP transaction, it is clear that if both engines do not agree on the information, that the non- authoritative engine is "wrong", and must then seek to conform to the information in the authoritative engine. There is thus no inconsistency when multiple managers are talking to an agent - they must all use the correct time information and secret information for that agent. A protocol engine has at most one record of authoritative information for that protocol engine (note that not all protocol engines need authoritative information, for example a manager that won't receive informs). A protocol engine will also have one or more records of non- authoritative information for any other protocol engines it will communicate with, where each record is identified by the snmpID [@ref adminmib] of the peer protocol engine. The following sections describe how this information is to be created and maintained in a consistent manner. 3.3.1. Initial Configuration Before any communication can begin, it is necessary for the authoritative information to be configured on the protocol engine for which it is authoritative. This configuration can be accomplished through a local mechanism or through a MIB provided for this purpose [@ref adminmib]. Configuration of non-authoritative information can be deferred until the time of use. This is important because managers may be transient and may not even exist when an agent is first configured. There are many Expires February 1996 [Page 28] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 ways to defer the act of configuring of non-authoritative information into a manager. One way that is possible for an interactive management application is for it to prompt the human operator for the information when it is required. 3.3.2. Secret Distribution In order to allow for operational maintenance of users and secrets, especially to maintain a high level of security, users need to be added and deleted, and secrets need to be changed. All of these operations must be able to be performed remotely. The USEC MIB defines objects which may be used to add, delete, and change secret information in both authoritative and non-authoritative protocol engines. Because of the need for privacy when sending secrets over the network and the non-ubiquity of encryption technology, secrets are changed using the userAuthChange and userPrivChange MIB objects, which encrypt a new secret with the previous value of the secret. Two modes of secret maintenance deserve special attention. First, it is possible for a management application to remotely configure a new user into one or more agents and inform receivers around the network, as well as to remotely configure the corresponding information into one or more non-authoritative management stations. A second mode is where the agents and inform receivers are configured remotely and the user simply remembers his secret in the form of a password so that he can supply it to any management station when he requests service of that management station. Note that this second mode is made more simple for the management station and the user if the user has the same userName on all authoritative systems, and if the user's secret is the same on many or all of those systems. Of course, this means that more systems will be compromised by the disclosure of a single secret, but evaluation of the risks due to this tradeoff is left to each operational environment to determine in light of their local security policies. 3.3.3. Cloning The preceding discussion described a mechanism for changing secrets in private by encrypting the new secret with the old secret. Of course, for a new user, there is no old secret, so cloning from a template is introduced to create an initial entry for a user by cloning an entry for another user whose password is known. The secret is then changed to a Expires February 1996 [Page 29] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 different, unrelated value using the userAuthChange and userPrivChange objects. One prime candidate for the data to be cloned is the administrator's entry, because the administrator's secret keys are known to the administrator who does the cloning. However, in some operational environments, it may be worthwhile to clone from a template which has never been used for authenticated traffic on the network because the conventional wisdom is that so doing reduces one's vulnerability to certain kinds of attacks. 3.3.4. Additional Details For the sake of clarity and to prevent the above procedure from being even longer, the following details were omitted from the above procedure. 3.3.4.1. ASN.1 Parsing Errors For ASN.1 parsing errors, the snmpStatsEncodingErrors counter [@ref v2mib4v2] is incremented and a report PDU is generated whenever such an ASN.1 parsing error is discovered. 3.3.4.2. Generation of a Report PDU Some steps specify that the received message is discarded without further processing whenever a report PDU is generated. However, there are some restrictions on the generation of report PDUs. First, a report PDU is never sent in response to a message without the reportableFlag set in the security flags field. This means that reports will never be sent in response to a Report PDU, to a Response PDU, or to a Trap PDU. Second, a generated report PDU must, whenever possible, contain the same request-id value as in the PDU contained in the received message. Meeting these constraints normally requires the message to be further processed just enough so as to extract its security flags (to derive the reportableFlag) and request-id. Even in the case where the SnmpV2AuthMessage is deemed unauthentic, an attempt must be made to extract the SNMPv2 operation type and request-id by assuming the message is not encrypted. With this assumption, the only situation in which the SNMPv2 operation type and request-id cannot be extracted is when an ASN.1 parsing error occurs. Note also that since the ASN.1 tag for an Expires February 1996 [Page 30] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 encrypted PDU is not one of the valid PDU types, an ASN.1 parsing error will always occur if the PDU is encrypted. 3.3.5. Changing A User's Secrets An SNMPv2 manager uses the following procedure to change the authentication secret configured for a user at a particular agent. (1) The management station determines the value for the new secret and generates an unpredictable value: determine desired value for keyNew randomValue = unpredictable() It then computes the appropriate delta value using the following algorithm (where the || symbol represents the concatenation operation): iterations = (lenOfkeyNew - 1) / 16; /* integer division */ temp = keyOld; for (i = 0; i < iterations; i++) { temp = MD5 (temp || randomValue); deltaValue[i*16 .. (i*16)+15] = temp XOR keyNew[i*16 .. (i*16)+15]; } temp = MD5 (temp || randomValue); deltaValue[i*16 .. lenOfkeyNew-1] = temp XOR keyNew[i*16 .. lenOfkeyNew-1]; (2) The management station initializes its knowledge of the current state of the agent using an authenticated get operation, retrying as necessary until a response is received: get ( lastLock = userSpinLock.0, lastNovel = userNovel. ) (3) The management station generates a unique novel value (which must be different from all previous values of lastNovel used with these new secret values). It then concatenates the unpredictable and delta values and conveys them to the agent in a single varbindlist, together with the most recently retrieved value of the advisory lock and the most recently generated unique novel value, using an Expires February 1996 [Page 31] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 authenticated set operation with a previously unused value of request-id. set ( userSpinLock.0 = lastLock, userAuthChange. = , userNovel. = uniqueNovelValue ) If a successful response with the correct request-id value is received, then goto step 4. If no response or an error response (with the correct request-id) is received, then the operation may or may not have been successful, due to duplication and/or loss of the request and/or the response(s). So, - save the error-index and error-status values, - re-issue the get operation in step 2; - retry this get operation as necessary until a response is received, - if this response indicates that userNovel has the unique novel value assigned in the last set operation, goto step 4. Otherwise, the set operation failed, and the saved error values are inspected to determine the cause of the failure. - if no response was received or the error-index indicates a problem with userSpinLock, goto step 2. - if the error-index indicates a problem with userAuthChange or userNovel, the secret cannot be changed to the new value. (4) Record the new secret values in stable storage. The operation is now successfully completed. [Retry counts to prevent endlessly looping in the presence of certain failures were omitted from the above procedure in the interest of brevity.] Note that during the period of time after the request has been sent and before the success of the operation is determined, the management station must keep track of both the old and new secret values. Since the delay may be the result of a network failure, the management station must be prepared to retain both values for an extended period of time, Expires February 1996 [Page 32] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 including across reboots. A user's secret privacy key is changed using the same procedure except that userPrivChange is used instead of userAuthChange. Expires February 1996 [Page 33] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 4. Definitions USEC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, UInteger32 FROM SNMPv2-SMI RowStatus, TestAndIncr FROM SNMPv2-TC KeyChange, MemoryType, TransportLabel, AuthName, SnmpID FROM V2ADMIN-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; usecMIB MODULE-IDENTITY LAST-UPDATED "9508121700" ORGANIZATION "IETF SNMPv2 Working Group" CONTACT-INFO "snmpv2@tis.com Complete contact information to be provided." DESCRIPTION "The MIB module for configuring the USEC security and privacy services." ::= { snmpModules xx } -- -- The usecScalars group. This group contains objects which provide -- time synchronization for the USEC authentication service. -- usecScalars OBJECT IDENTIFIER ::= { usecMIB 1 } snmpBoots OBJECT-TYPE SYNTAX Integer32 (-1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the management system on a device has been re-initialized since its initial configuration." ::= { usecScalars 1 } snmpTime OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION Expires February 1996 [Page 34] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 "The number of seconds since the SNMPv2 protocol entity last incremented the snmpBoots object." ::= { usecScalars 2 } Expires February 1996 [Page 35] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 -- -- The usecCounters group. This group contains objects which provide -- statistics for the USEC security and privacy services. -- usecCounters OBJECT IDENTIFIER ::= { usecMIB 2 } snmpStatsNotInTimeWindows OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of packets that were deemed unauthentic due to the authSnmpBoots or authSnmpTime values being out of lifetime." ::= { usecCounters 1 } usecStatsUnknownUserNames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of packets containing an SPI associated with usecNoAuth(4), usecAuth(5), or usecPriv(6), but whose userNames were not found in the userNameTable." ::= { usecCounters 2 } usecStatsWrongDigestValues OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of packets that were deemed unauthentic due to the digest value being incorrect." ::= { usecCounters 3 } usecStatsBadPrivacys OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of packets received which were encrypted incorrectly." ::= { usecCounters 4 } Expires February 1996 [Page 36] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 -- -- The usecUser group -- usecUser OBJECT IDENTIFIER ::= { usecMIB 3 } userSpinLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "An advisory lock used to allow several cooperating SNMPv2 entities, all acting in a manager role, to coordinate their use of SNMPv2 set operations to entries in the userNameTable. A manager application should include the value of userSpinLock in every set operation which accesses the userNameTable. Since this is an advisory lock, entities acting in an agent role do not enforce the use of userSpinLock." ::= { usecUser 1 } maxUserNameLength OBJECT-TYPE SYNTAX Integer32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum length of userName allowed by this implementation. This value can be probed by a management application prior to attempting a row creation operation in the userNameTable. A value of 0 indicates that the userNameTable does not allow row creation or deletion operations." ::= { usecUser 2 } -- -- The userNameTable contains the database of users who are configured to -- perform SNMP communications via the Usec authentication and privacy service. -- These users are organized into 'groups'. -- The group to which a user belongs is specified in the userGroupName -- object. -- -- Access privileges are assigned in the acTable [@ref adminmib] by group. -- This allows groups of users to share the same privileges, or for individual -- users to have their own unique privileges. -- -- In order to ease the task of configuring SNMPv2 entities, many of the Expires February 1996 [Page 37] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 -- indices used in the following table are textual (human-readable) strings. -- Experience has shown that it is often necessary for a network administrator -- to manually edit the configuration datastore for an SNMPv2 entities. -- Use of textual strings for indices makes the configuration datastore much -- easier for an administrator to maintain. -- An implementation may restrict the lengths of userName and userGroupName -- entries to less than the maximum value. -- The maxUserNameLength variable and maxGroupNameLength [@ref adminmib] -- variables can be used to detect the maximum length of name strings -- supported by a particular implementation. userNameTable OBJECT-TYPE SYNTAX SEQUENCE OF UserNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The SNMPv2 database for usecNoAuth(4), usecAuth(5), and usecPriv(6) users." ::= { usecUser 3 } userNameEntry OBJECT-TYPE SYNTAX UserNameEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular SNMPv2 user." INDEX { userAuthSnmpID, IMPLIED userName } ::= { userNameTable 1 } UserNameEntry ::= SEQUENCE { userAuthSnmpID SnmpID, userName AuthName, userGroupName AuthName, userAuthChange KeyChange, userPrivChange KeyChange, userNovel OCTET STRING, userTransportLabel TransportLabel, userCloneFrom RowPointer, userMemoryType MemoryType, userStatus RowStatus } userAuthSnmpID OBJECT-TYPE SYNTAX SnmpID MAX-ACCESS not-accessible Expires February 1996 [Page 38] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 STATUS current DESCRIPTION "The node's administratively-unique identifier. In a simple agent, this value will always be equal to the agent's snmpID object. In a manager which does not send or receive inform requests, this value will be equal to the snmpID object of the agent with which this user can communicate. In a manager which sends or receives inform requests, this object will be equal to one of three things: - The snmpID of the agent with which this user can communicate. - The snmpID of the manager's local protocol engine. - The snmpID of a remote manager which this user can send inform requests to or receive inform requests from. In a dual-role entity, this value will be some combination of those specified for agents and managers above." ::= { userNameEntry 1 } userName OBJECT-TYPE SYNTAX AuthName (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This variable contains the textual name of a user." ::= { userNameEntry 2 } userGroupName OBJECT-TYPE SYNTAX AuthName (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "This variable contains the textual name of the group to which a user belongs." ::= { userNameEntry 3 } userAuthChange OBJECT-TYPE SYNTAX KeyChange MAX-ACCESS read-create STATUS current Expires February 1996 [Page 39] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 DESCRIPTION "An object, which when modified, causes the user's secret authentication key to be modified via a one-way function. 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 userCloneFrom." DEFVAL { ''H } -- the empty string ::= { userNameEntry 4 } userPrivChange OBJECT-TYPE SYNTAX KeyChange MAX-ACCESS read-create STATUS current DESCRIPTION "An object, which when modified, causes the user's secret privacy key to be modified via a one-way function. When creating a new user, it is a '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 userCloneFrom." DEFVAL { ''H } -- the empty string ::= { userNameEntry 5 } userNovel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..20)) MAX-ACCESS read-create STATUS current DESCRIPTION "This object may be used by a manager as a part of its procedure for altering secret information about a user. By altering the value of an instance of this object in the same SNMPv2 Set-Request used to update secret information, a subsequent Get-Request can determine if the Set-Request was successful in the event that no response to the Set-Request is received. When an instance of this object is created, its value is initialized to a random value. This object need not be stored in non-volatile storage and should be initialized to an unpredictable value upon system re-initialization." Expires February 1996 [Page 40] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 DEFVAL { ''H } -- the empty string ::= { userNameEntry 6 } userTransportLabel OBJECT-TYPE SYNTAX TransportLabel MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies a set of transport endpoints from which an agent will accept management requests. If a management request generated by this user is received on a transport endpoint other than the transport endpoints identified by this object, the request is deemed unauthentic. The transports identified by this object are specified in the transportTable. Entries in the transportTable whose transportLabel value are equal to this object are identified. If the value of this object has zero-length, or if the transportTable is not implemented, then transport endpoints are not checked when authenticating messages generated by this user." DEFVAL { ''H } -- the empty string ::= { userNameEntry 7 } userCloneFrom OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "An indication of the user to clone authentication and privacy parameters from. When read, the value { 0 0 } is returned. This object must be written exactly once, when the associated instance of userStatus either does not exist or has the value `notReady'. Subsequent set operations to this object will succeed, but will not cause the agent to take any action. When first written, the value identifies an instance of a user, the cloning user, whose status column has the value 'active' or 'not in service'. For implementations which support both authentication and privacy, the authentication and privacy secrets of the cloning user are copied to the corresponding authentication and privacy secrets of the user being created. Expires February 1996 [Page 41] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 For implementations which support only authentication, the authentication secret of the cloning user is copied to the corresponding authentication secret of the user being created. For implementations which support neither authentication nor privacy, this object has no effect (and need not be implemented)." ::= { userNameEntry 8 } userMemoryType OBJECT-TYPE SYNTAX MemoryType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the userNameTable. Conceptual rows having the value 'permanent' must allow write-access at a minimum to: userAuthChange and userNovel for users employing authentication; and userPrivChange and userNovel for users employing privacy. Note that any user which employs authentication or privacy must allow its secrets to be updated and thus cannot be 'readOnly'." ::= { userNameEntry 9 } userStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the userNameTable. A user is not qualified for activation until instances of all columns of its userNameEntry row have an appropriate value. In particular, one or more management set operations are required to configure the entry: a value must be written to the user's userCloneFrom object, and ... update of secrets Until instances of all corresponding columns and secrets are appropriately configured, the value of the corresponding instance of the userStatus column is `notReady'." Expires February 1996 [Page 42] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 ::= { userNameEntry 10 } Expires February 1996 [Page 43] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 -- conformance information usecMIBConformance OBJECT IDENTIFIER ::= { usecMIB 4 } usecMIBCompliances OBJECT IDENTIFIER ::= { usecMIBConformance 1 } usecMIBGroups OBJECT IDENTIFIER ::= { usecMIBConformance 2 } -- compliance statements usecMIBNoAuthCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the SNMPv2 USEC MIB with no authentication or privacy protocols." MODULE -- this module MANDATORY-GROUPS { usecNoAuthGroup } ::= { usecMIBCompliances 1 } usecMIBAuthCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the SNMPv2 USEC MIB with authentication and no privacy protocols." MODULE -- this module MANDATORY-GROUPS { usecNoAuthGroup, usecAuthGroup } OBJECT userAuthChange MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { usecMIBCompliances 2 } usecMIBPrivCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the SNMPv2 USEC MIB with both authentication Expires February 1996 [Page 44] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 and privacy protocols." MODULE -- this module MANDATORY-GROUPS { usecNoAuthGroup, usecAuthGroup, usecPrivGroup } OBJECT userAuthChange MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT userPrivChange MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { usecMIBCompliances 3 } Expires February 1996 [Page 45] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 -- units of conformance usecNoAuthGroup OBJECT-GROUP OBJECTS { snmpStatsNotInTimeWindows, usecStatsUnknownUserNames, usecStatsWrongDigestValues, usecStatsBadPrivacys, userSpinLock, userAuthSnmpID, userName, userGroupName, userTransportLabel, userCloneFrom, userMemoryType, userStatus } STATUS current DESCRIPTION "A collection of objects providing for configuration of an SNMPv2 agent which implements the SNMPv2 User-based Security Model." ::= { usecMIBGroups 1 } usecAuthGroup OBJECT-GROUP OBJECTS { userAuthChange, userNovel } STATUS current DESCRIPTION "A collection of objects providing for configuration of an SNMPv2 agent which implements the SNMPv2 User-based Security Model." ::= { usecMIBGroups 2 } usecPrivGroup OBJECT-GROUP OBJECTS { userPrivChange } STATUS current DESCRIPTION "A collection of objects providing for configuration of an SNMPv2 agent which implements the SNMPv2 User-based Security Expires February 1996 [Page 46] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 Model." ::= { usecMIBGroups 3 } END Expires February 1996 [Page 47] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 5. Security Considerations 5.1. Recommended Practices This section describes practices that contribute to the secure, effective operation of the mechanisms defined in this memo. - A management station must discard SNMPv2 responses for which neither the request-id component nor the represented management information corresponds to any currently outstanding request. Although it would be typical for a management station 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). - When sending state altering messages to a managed agent, a management station can increase security by delaying sending successive messages to the managed agent until a positive acknowledgement is received for the previous message or until the previous message expires. No message ordering is imposed by the SNMPv2. 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 agent, 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, a management station 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 [@ref v2mib4v2], is specifically defined for use with SNMPv2 set operations in order to provide a mechanism to ensure the processing of SNMPv2 messages occurs in a specific order. - The frequency with which the secrets of an SNMPv2 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 Expires February 1996 [Page 48] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 changes to the secret avoid this vulnerability. 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 the communication paths, more caution is prudent. 5.2. Defining Users The mechanisms defined in this document employ the notion of "users" having access rights. 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 a manager station application or set of manager station applications, acting on behalf of a 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). 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, agent implementations (and agent 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. Note that there is security risk in configuring the same "user" on multiple systems where the same password is used on each system, since Expires February 1996 [Page 49] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 the compromise of that user's secrets on one system results in the compromise of that user on all other systems having the same password. There is also greater security risk and less accountability in allowing multiple humans to know the password for a given "user". Expires February 1996 [Page 50] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 5.3. Conformance To claim conformance to this memo, an SNMPv2 implementation: - must implement the Digest Authentication Protocol. Otherwise, it is termed an "insecure SNMPv2 implementation" -- one which adheres to the SNMPv2 Administrative Framework but does not support secure operations. - must, to the maximal extent possible, prohibit access to the secret(s) of each user about which it maintains information in a LCD, under all circumstances except as required to generate and/or validate SNMPv2 messages with respect to that user. - must implement the SNMPv2 USEC MIB. Implementation of the Symmetric Encryption Protocol is optional. 6. Acknowledgements To be provided. 7. References To be provided. APPENDIX A - Agent Installation Parameters During installation, an agent is configured with several parameters. These include: (1) a security posture The choice of security posture determines the extent of the view configured for unauthenticated access. One of three possible choices is selected: minimum-secure, semi-secure, or very-secure. (2) one or more transport service addresses These parameters may be specified explicitly, or they may be Expires February 1996 [Page 51] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 specified implicitly as the same set of network-layer addresses configured for other uses by the device together with the well- known transport-layer "port" information for the appropriate transport domain [@ref tm]. The agent listens on each of these transport service addresses for messages sent on behalf of any user it knows about. (3) 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. The resulting digest is the required secret (see Appendix B). With these configured parameters, the agent instantiates the following user, context, views and access rights. This configuration information should be persistent. - One user: privacy not supported privacy supported --------------------- ----------------- "public" "public" authentication key authentication key -- privacy key - One local context with its as the string "default". - One view for authenticated access: - the MIB view is the "internet" subtree. Expires February 1996 [Page 52] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 - A second view for unauthenticated access. This view is configured according to the selected security posture. For the "very-secure" posture: - the MIB view is the union of the "snmpStats" and "usecStats" subtrees. For the "semi-secure" posture: - the MIB view is the union of the "snmpStats", "usecStats" and "system" subtrees. For the "minimum-secure" posture: - the MIB view is the "internet" subtree. - Access rights to allow: - read-only access for unauthenticated messages on behalf of the user "public" to the MIB view of contextSelector "default". - read-write access for authenticated but not private messages on behalf of the user "public" to the MIB view of contextSelector "default". - if privacy is supported, read-write access for authenticated and private messages on behalf of the user "public" to the MIB view of contextSelector "default". Expires February 1996 [Page 53] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 APPENDIX B - Password to Key Algorithm The following code fragment demonstrates the password to key algorithm which can be used when mapping a password to an authentication or privacy key. (The calls to MD5 are as documented in RFC 1321.) void password_to_key(password, passwordlen, key) u_char *password; /* IN */ u_int passwordlen; /* IN */ u_char *key; /* OUT - caller supplies pointer to 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 */ /* loop until we've done 1 Megabyte */ while (count < 1048576) { cp = password_buf; for(i = 0; i < 64; i++) { *cp++ = password[ password_index++ % passwordlen ]; /* * Take the next byte of the password, wrapping to the * beginning of the password as necessary. */ } MDupdate (&MD, password_buf, 64); count += 64; } MD5Final (key, &MD); /* tell MD5 we're done */ return; } Expires February 1996 [Page 54] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 Authors' Addresses Tell U. Later snmpv2@tis.com others To be provided. Expires February 1996 [Page 55] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 Table of Contents 1 Introduction .................................................... 3 1.1 Threats ....................................................... 5 1.2 Goals and Constraints ......................................... 6 1.3 Security Services ............................................. 7 1.4 Mechanisms .................................................... 8 1.4.1 Digest Authentication Protocol .............................. 9 1.4.2 Symmetric Encryption Protocol ............................... 12 2 Elements of the Service ......................................... 14 2.1 SNMPv2 Users .................................................. 14 2.2 Values of sPI ................................................. 15 2.3 Replay Protection ............................................. 15 2.3.1 snmpID ...................................................... 16 2.3.2 authSnmpBoots and authSnmpTime .............................. 16 2.3.3 Time Window ................................................. 17 2.3.4 Error Reporting ............................................. 17 2.3.5 Time Synchronization ........................................ 18 2.3.5.1 Time Synchronization for Traps ............................ 19 2.4 Local Configuration Datastore (LCD) ........................... 19 2.5 SnmpV2AuthMessage Format ...................................... 19 2.6 AuthInfo ASN.1 Definition ..................................... 20 3 Elements of Procedure ........................................... 21 3.1 Generating an SnmpV2AuthMessage Component ..................... 21 3.2 Processing a Received Communication ........................... 24 3.3 Discussion of Distribution of Secrets and Time Information .............................................................. 27 3.3.1 Initial Configuration ....................................... 28 3.3.2 Secret Distribution ......................................... 29 3.3.3 Cloning ..................................................... 29 3.3.4 Additional Details .......................................... 30 3.3.4.1 ASN.1 Parsing Errors ...................................... 30 3.3.4.2 Generation of a Report PDU ................................ 30 3.3.5 Changing A User's Secrets ................................... 31 4 Definitions ..................................................... 34 5 Security Considerations ......................................... 48 5.1 Recommended Practices ......................................... 48 5.2 Defining Users ................................................ 49 5.3 Conformance ................................................... 51 6 Acknowledgements ................................................ 51 7 References ...................................................... 51 Appendix A Agent Installation Parameters .......................... 51 Appendix B Password to Key Algorithm .............................. 54 Authors' Addresses ................................................ 55 Expires February 1996 [Page 56] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 Expires February 1996 [Page 57] ts 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 repeatrogress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Expires February 1996 [Page 1] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 running list of open issues reference list reference citations acknowledgements authors author addresses spell check mib needs to be re-checked for rationality with the text improve compliance/conformance statement for the protocols and mib horizontal spacing / column alignment in the mib Expires February 1996 [Page 2] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 1. Introduction A management system contains: several (potentially many) manageable nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol. The management protocol is used to convey management information between the agents and management stations; and, for manager-to-manager communications, between management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies. Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information. The Administrative Model for SNMPv2 document [@ref v2admin] defines a framework and an administrative model which realizes effective management in a variety of configurations and environments. In the administrative model, there are provisions for multiple authentication and privacy services (identified by the security protocol identifier, sPI) to achieve various objectives. Each manager (including a dual-role entity acting in a manager role) and each agent (including a dual-role entity acting in an agent role) implements one or more of these types of service. Although many such types of authentication and privacy services might be defined, it is the purpose of this document, User-Based Symmetric Security Protocols for SNMPv2, to define three such services; one service supporting neither authentication nor privacy (usecNoAuth(4)), one service supporting authentication but not privacy (usecAuth(5)), and another supporting both authentication and privacy (usecPriv(6)). The model defined by the administrative framework also includes provisions for access control. The enforcement of access rights requires the means to identify the entity on whose behalf a request is generated. That is, authentication is a functional prerequisite to access control. The SNMPv2 security services described herein identify an entity on whose behalf an SNMPv2 message is generated as a "user". For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). This document is a part Expires February 1996 [Page 3] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 of the current framework, termed the SNMP version 2 framework (SNMPv2). Expires February 1996 [Page 4] Internet Draft User-Based Symmetric Security for SNMPv2 September 1995 1.1. Threats Several of the classical threats to network protocols are applicable to the management problem and therefore would be applicable to any SNMPv2 security service. Other threats are not applicable to the management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance. The principal threats against which the SNMPv2 security service described herein should provide protection are: