Network Working Group U. Blumenthal
Request for Comments: 3414 B. Wijnen
STD: 62 Lucent Technologies
Obsoletes: 2574 December 2002
Category: Standards Track
Network Working Group U. Blumenthal
Request for Comments: 3414 B. Wijnen
STD: 62 Lucent Technologies
Obsoletes: 2574 December 2002
Category: Standards Track
User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
简单网络管理协议（SNMPv3）版本3的基于用户的安全模型（USM）
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574.
本文档介绍用于SNMP体系结构的简单网络管理协议（SNMP）版本3的基于用户的安全模型（USM）。它定义了用于提供SNMP消息级安全性的过程元素。本文档还包括一个管理信息库（MIB），用于远程监视/管理此安全模型的配置参数。本文件废除了RFC 2574。
Table of Contents
目录
1. Introduction.......................................... 4
1.1. Threats............................................... 4
1.2. Goals and Constraints................................. 6
1.3. Security Services..................................... 6
1.4. Module Organization................................... 7
1.4.1. Timeliness Module..................................... 8
1.4.2. Authentication Protocol............................... 8
1.4.3. Privacy Protocol...................................... 8
1.5. Protection against Message Replay, Delay
and Redirection....................................... 9
1.5.1. Authoritative SNMP engine............................. 9
1.5.2. Mechanisms............................................ 9
1.6. Abstract Service Interfaces........................... 11
1. Introduction.......................................... 4
1.1. Threats............................................... 4
1.2. Goals and Constraints................................. 6
1.3. Security Services..................................... 6
1.4. Module Organization................................... 7
1.4.1. Timeliness Module..................................... 8
1.4.2. Authentication Protocol............................... 8
1.4.3. Privacy Protocol...................................... 8
1.5. Protection against Message Replay, Delay
and Redirection....................................... 9
1.5.1. Authoritative SNMP engine............................. 9
1.5.2. Mechanisms............................................ 9
1.6. Abstract Service Interfaces........................... 11
1.6.1. User-based Security Model Primitives
for Authentication.................................... 11
1.6.2. User-based Security Model Primitives
for Privacy........................................... 12
2. Elements of the Model................................. 12
2.1. User-based Security Model Users....................... 12
2.2. Replay Protection..................................... 13
2.2.1. msgAuthoritativeEngineID.............................. 14
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...... 20
2.6. Key Localization Algorithm............................ 22
3. Elements of Procedure................................. 22
3.1. Generating an Outgoing SNMP Message................... 22
3.2. Processing an Incoming SNMP Message................... 26
4. Discovery............................................. 31
5. Definitions........................................... 32
6. HMAC-MD5-96 Authentication Protocol................... 51
6.1. Mechanisms............................................ 51
6.1.1. Digest Authentication Mechanism....................... 51
6.2. Elements of the Digest Authentication Protocol........ 52
6.2.1. Users................................................. 52
6.2.2. msgAuthoritativeEngineID.............................. 53
6.2.3. SNMP Messages Using this Authentication Protocol...... 53
6.2.4. Services provided by the HMAC-MD5-96
Authentication Module................................. 53
6.2.4.1. Services for Generating an Outgoing SNMP Message...... 53
6.2.4.2. Services for Processing an Incoming SNMP Message...... 54
6.3. Elements of Procedure................................. 55
6.3.1. Processing an Outgoing Message........................ 55
6.3.2. Processing an Incoming Message........................ 56
7. HMAC-SHA-96 Authentication Protocol................... 57
7.1. Mechanisms............................................ 57
7.1.1. Digest Authentication Mechanism....................... 57
7.2. Elements of the HMAC-SHA-96 Authentication Protocol... 58
7.2.1. Users................................................. 58
7.2.2. msgAuthoritativeEngineID.............................. 58
7.2.3. SNMP Messages Using this Authentication Protocol...... 59
7.2.4. Services provided by the HMAC-SHA-96
Authentication Module................................. 59
7.2.4.1. Services for Generating an Outgoing SNMP Message...... 59
7.2.4.2. Services for Processing an Incoming SNMP Message...... 60
7.3. Elements of Procedure................................. 61
1.6.1. User-based Security Model Primitives
for Authentication.................................... 11
1.6.2. User-based Security Model Primitives
for Privacy........................................... 12
2. Elements of the Model................................. 12
2.1. User-based Security Model Users....................... 12
2.2. Replay Protection..................................... 13
2.2.1. msgAuthoritativeEngineID.............................. 14
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...... 20
2.6. Key Localization Algorithm............................ 22
3. Elements of Procedure................................. 22
3.1. Generating an Outgoing SNMP Message................... 22
3.2. Processing an Incoming SNMP Message................... 26
4. Discovery............................................. 31
5. Definitions........................................... 32
6. HMAC-MD5-96 Authentication Protocol................... 51
6.1. Mechanisms............................................ 51
6.1.1. Digest Authentication Mechanism....................... 51
6.2. Elements of the Digest Authentication Protocol........ 52
6.2.1. Users................................................. 52
6.2.2. msgAuthoritativeEngineID.............................. 53
6.2.3. SNMP Messages Using this Authentication Protocol...... 53
6.2.4. Services provided by the HMAC-MD5-96
Authentication Module................................. 53
6.2.4.1. Services for Generating an Outgoing SNMP Message...... 53
6.2.4.2. Services for Processing an Incoming SNMP Message...... 54
6.3. Elements of Procedure................................. 55
6.3.1. Processing an Outgoing Message........................ 55
6.3.2. Processing an Incoming Message........................ 56
7. HMAC-SHA-96 Authentication Protocol................... 57
7.1. Mechanisms............................................ 57
7.1.1. Digest Authentication Mechanism....................... 57
7.2. Elements of the HMAC-SHA-96 Authentication Protocol... 58
7.2.1. Users................................................. 58
7.2.2. msgAuthoritativeEngineID.............................. 58
7.2.3. SNMP Messages Using this Authentication Protocol...... 59
7.2.4. Services provided by the HMAC-SHA-96
Authentication Module................................. 59
7.2.4.1. Services for Generating an Outgoing SNMP Message...... 59
7.2.4.2. Services for Processing an Incoming SNMP Message...... 60
7.3. Elements of Procedure................................. 61
7.3.1. Processing an Outgoing Message........................ 61
7.3.2. Processing an Incoming Message........................ 61
8. CBC-DES Symmetric Encryption Protocol................. 63
8.1. Mechanisms............................................ 63
8.1.1. Symmetric Encryption Protocol......................... 63
8.1.1.1. DES key and Initialization Vector..................... 64
8.1.1.2. Data Encryption....................................... 65
8.1.1.3. Data Decryption....................................... 65
8.2. Elements of the DES Privacy Protocol.................. 65
8.2.1. Users................................................. 65
8.2.2. msgAuthoritativeEngineID.............................. 66
8.2.3. SNMP Messages Using this Privacy Protocol............. 66
8.2.4. Services provided by the DES Privacy Module........... 66
8.2.4.1. Services for Encrypting Outgoing Data................. 66
8.2.4.2. Services for Decrypting Incoming Data................. 67
8.3. Elements of Procedure................................. 68
8.3.1. Processing an Outgoing Message........................ 68
8.3.2. Processing an Incoming Message........................ 69
9. Intellectual Property................................. 69
10. Acknowledgements...................................... 70
11. Security Considerations............................... 71
11.1. Recommended Practices................................. 71
11.2. Defining Users........................................ 73
11.3. Conformance........................................... 74
11.4. Use of Reports........................................ 75
11.5. Access to the SNMP-USER-BASED-SM-MIB.................. 75
12. References............................................ 75
A.1. SNMP engine Installation Parameters................... 78
A.2. Password to Key Algorithm............................. 80
A.2.1. Password to Key Sample Code for MD5................... 81
A.2.2. Password to Key Sample Code for SHA................... 82
A.3. Password to Key Sample Results........................ 83
A.3.1. Password to Key Sample Results using MD5.............. 83
A.3.2. Password to Key Sample Results using SHA.............. 83
A.4. Sample encoding of msgSecurityParameters.............. 83
A.5. Sample keyChange Results.............................. 84
A.5.1. Sample keyChange Results using MD5.................... 84
A.5.2. Sample keyChange Results using SHA.................... 85
B. Change Log............................................ 86
Editors' Addresses.................................... 87
Full Copyright Statement.............................. 88
7.3.1. Processing an Outgoing Message........................ 61
7.3.2. Processing an Incoming Message........................ 61
8. CBC-DES Symmetric Encryption Protocol................. 63
8.1. Mechanisms............................................ 63
8.1.1. Symmetric Encryption Protocol......................... 63
8.1.1.1. DES key and Initialization Vector..................... 64
8.1.1.2. Data Encryption....................................... 65
8.1.1.3. Data Decryption....................................... 65
8.2. Elements of the DES Privacy Protocol.................. 65
8.2.1. Users................................................. 65
8.2.2. msgAuthoritativeEngineID.............................. 66
8.2.3. SNMP Messages Using this Privacy Protocol............. 66
8.2.4. Services provided by the DES Privacy Module........... 66
8.2.4.1. Services for Encrypting Outgoing Data................. 66
8.2.4.2. Services for Decrypting Incoming Data................. 67
8.3. Elements of Procedure................................. 68
8.3.1. Processing an Outgoing Message........................ 68
8.3.2. Processing an Incoming Message........................ 69
9. Intellectual Property................................. 69
10. Acknowledgements...................................... 70
11. Security Considerations............................... 71
11.1. Recommended Practices................................. 71
11.2. Defining Users........................................ 73
11.3. Conformance........................................... 74
11.4. Use of Reports........................................ 75
11.5. Access to the SNMP-USER-BASED-SM-MIB.................. 75
12. References............................................ 75
A.1. SNMP engine Installation Parameters................... 78
A.2. Password to Key Algorithm............................. 80
A.2.1. Password to Key Sample Code for MD5................... 81
A.2.2. Password to Key Sample Code for SHA................... 82
A.3. Password to Key Sample Results........................ 83
A.3.1. Password to Key Sample Results using MD5.............. 83
A.3.2. Password to Key Sample Results using SHA.............. 83
A.4. Sample encoding of msgSecurityParameters.............. 83
A.5. Sample keyChange Results.............................. 84
A.5.1. Sample keyChange Results using MD5.................... 84
A.5.2. Sample keyChange Results using SHA.................... 85
B. Change Log............................................ 86
Editors' Addresses.................................... 87
Full Copyright Statement.............................. 88
The Architecture for describing Internet Management Frameworks [RFC3411] describes that an SNMP engine is composed of:
描述Internet管理框架的体系结构[RFC3411]描述了SNMP引擎由以下部分组成：
1) a Dispatcher, 2) a Message Processing Subsystem, 3) a Security Subsystem, and 4) an Access Control Subsystem.
1) 调度器、2）消息处理子系统、3）安全子系统和4）访问控制子系统。
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 [RFC3411].
理解SNMP体系结构和体系结构的术语对于理解本文档中描述的安全模型在体系结构中的位置以及与体系结构中的其他子系统的交互非常重要。读者应已阅读并理解[RFC3411]中定义的SNMP体系结构描述。
This memo 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.
本备忘录描述了SNMP体系结构中使用的基于用户的安全模型。其主要思想是，我们使用传统的用户（由用户名标识）概念来关联安全信息。
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.
本备忘录描述了使用HMAC-MD5-96和HMAC-SHA-96作为身份验证协议，以及使用CBC-DES作为隐私协议。然而，基于用户的安全模型允许使用其他此类协议来代替这些协议或与这些协议并发。因此，HMAC-MD5-96、HMAC-SHA-96和CBC-DES的描述在单独的章节中，以反映其自包含的性质，并表明它们可以在将来被替换或补充。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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.
网络协议的几个经典威胁适用于网络管理问题，因此适用于任何SNMP安全模型。其他威胁不适用于网络管理问题。本节讨论主要威胁、次要威胁和次要威胁。
The principal threats against which this SNMP Security Model should provide protection are:
此SNMP安全模型应提供保护的主要威胁包括：
- 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 principal in such a way as to effect unauthorized management operations, including falsifying the value of an object.
- 修改信息修改威胁是指某些未经授权的实体可能以影响未经授权的管理操作的方式更改代表授权主体生成的传输中SNMP消息的危险，包括伪造对象的值。
- 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.
- 披露披露威胁是指在受管代理和管理站之间的交换中窃听的危险。作为当地政策的一项内容，可能需要针对这种威胁进行保护。
- 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.
- 消息流修改SNMP协议通常基于无连接传输服务，该服务可在任何子网服务上运行。消息的重新排序、延迟或重播可以并且确实通过许多这样的子网服务的自然操作发生。消息流修改威胁是指消息可能被恶意重新排序、延迟或重播到比通过子网服务的自然操作可能发生的程度更大的程度，从而影响未经授权的管理操作的危险。
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:
SNMP安全模型至少有两种不需要保护的威胁。本备忘录中定义的安全协议不针对以下情况提供保护：
- 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.
- 拒绝服务此SNMP安全模型不试图解决代表授权用户的服务被拒绝的广泛攻击。事实上，这种拒绝服务攻击在许多情况下与任何可行的网络管理协议都必须处理的网络故障类型无法区分。
- 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.
- 流量分析此SNMP安全模型不尝试解决流量分析攻击。事实上，许多流量模式是可预测的——设备可以由数量相对较少的管理应用程序定期管理——因此，防止流量分析不会带来显著优势。
Based on the foregoing account of threats in the SNMP network management environment, the goals of this SNMP Security Model are as follows.
基于前面对SNMP网络管理环境中的威胁的描述，此SNMP安全模型的目标如下。
1) Provide for verification that each received SNMP message has not been modified during its transmission through the network.
1) 用于验证每个接收到的SNMP消息在通过网络传输期间未被修改。
2) Provide for verification of the identity of the user on whose behalf a received SNMP message claims to have been generated.
2) 用于验证接收到的SNMP消息声称已代表其生成的用户的身份。
3) Provide for detection of received SNMP messages, which request or contain management information, whose time of generation was not recent.
3) 用于检测接收到的SNMP消息，这些消息请求或包含管理信息，其生成时间不是最近的。
4) Provide, when necessary, that the contents of each received SNMP message are protected from disclosure.
4) 必要时，应确保每个接收到的SNMP消息的内容不被泄露。
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:
除了支持安全网络管理的主要目标外，此SNMP安全模型的设计还受到以下约束的影响：
1) When the requirements of effective management in times of network stress are inconsistent with those of security, the design of USM has given preference to the former.
1) 当网络压力下的有效管理要求与安全要求不一致时，USM的设计优先于前者。
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).
2) 安全协议及其底层安全机制都不应依赖于其他网络服务（例如，网络时间协议（NTP）或密钥管理协议）的可用性。
3) A security mechanism should entail no changes to the basic SNMP network management philosophy.
3) 安全机制不应改变基本的SNMP网络管理理念。
The security services necessary to support the goals of this SNMP Security Model are as follows:
支持此SNMP安全模型目标所需的安全服务如下：
- 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.
对于本备忘录中规定的协议，无法确保接收到的SNMP消息的特定发起人；相反，是代表其发起消息的用户进行了身份验证。
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.
在撰写本备忘录时，本备忘录中使用的安全协议被认为是可接受的安全协议。但是，如果需要，这些程序允许在将来指定新的身份验证和隐私方法。
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.
时效性模块针对基于用户的安全模型是固定的，同时提供了多个身份验证和/或隐私模块，每个模块分别实现特定的身份验证或隐私协议。
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.
第3节（过程要素）使用SNMP消息中的及时性值进行及时性检查。仅当对消息应用了身份验证时，才会执行及时性检查。由于已检查完整消息的完整性，因此我们可以假设通过身份验证模块的消息中的及时性值是可信的。
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.
第6节介绍了HMAC-MD5-96身份验证协议，它是基于用户的安全模型必须支持的第一个身份验证协议。第7节介绍了HMAC-SHA-96认证协议，它是另一种基于用户的安全模型应支持的认证协议。将来，随着新需求的出现，可能会定义附加的或替代的认证协议。
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.
对于要进行身份验证的消息，它需要通过身份验证模块的身份验证检查和及时性检查，这是基于用户的安全模型的固定部分。
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.
第8节描述了CBC-DES对称加密协议，它是第一个用于基于用户的安全模型的隐私协议。未来，随着新需求的出现，可能会定义附加或替代隐私协议。
The User-based Security Model prescribes that the scopedPDU is protected from disclosure when a message is sent with privacy.
基于用户的安全模型规定，当发送带有隐私的消息时，scopedPDU受到保护，不会被泄露。
The User-based Security Model also prescribes that a message needs to be authenticated if privacy is in use.
基于用户的安全模型还规定，如果使用隐私，则需要对消息进行身份验证。
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 (those messages that contain a Confirmed Class PDU [RFC3411]), then the receiver of such messages is authoritative. When an SNMP message contains a payload which does not expect a response (those messages that contain an Unconfirmed Class PDU [RFC3411]), then the sender of such a message is authoritative.
为了防止消息重播、延迟和重定向，每个通信中涉及的一个SNMP引擎被指定为权威SNMP引擎。当SNMP消息包含期望响应的有效负载（那些包含确认类PDU[RFC3411]的消息）时，此类消息的接收方具有权威性。当SNMP消息包含不期望响应的有效负载时（那些包含未确认类PDU[RFC3411]的消息），则此类消息的发送方具有权威性。
The following mechanisms are used:
使用以下机制：
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.
1) 为了防止消息延迟或重播的威胁（超过正常操作可能发生的程度），生成的每条消息中都包含一组及时性指示器（用于权威SNMP引擎）。SNMP引擎评估及时性指标，以确定收到的消息是否是最近的。SNMP引擎可以评估及时性指标，以确保接收到的消息至少与从同一来源接收到的最后一条消息相同。非权威SNMP引擎使用接收到的真实消息来推进其在远程权威源的及时性指示器的概念。
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.
SNMP引擎还必须使用一种机制将传入响应与未完成的请求相匹配，并且必须删除与未完成的请求不匹配的任何响应。例如，可以在每条消息中插入msgID以满足此功能。
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 [RFC3418]).
这种针对消息延迟或重播威胁的保护并不意味着也不提供任何针对未经授权删除或抑制消息的保护。此外，如果所涉及的所有消息都在时间窗口间隔内发送，SNMP引擎可能无法检测消息重新排序。独立于安全协议定义的其他机制也可用于检测包含集合操作（例如，MIB变量snmpSetSerialNo[RFC3418]）的消息的重新排序重播、删除或抑制。
2) Verification that a message sent to/from one authoritative SNMP engine cannot be replayed to/as-if-from another authoritative SNMP engine.
2) 验证发送到/来自一个权威SNMP引擎的消息不能重播到/好像从另一个权威SNMP引擎重播。
Included in each message is an identifier unique to the authoritative SNMP engine associated with the sender or intended recipient of the message.
每个消息中都包含与消息的发送者或预期接收者关联的权威SNMP引擎的唯一标识符。
A message containing an Unconfirmed Class PDU 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 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.
包含由权威SNMP引擎发送到一个非权威SNMP引擎的未确认类PDU的消息可能会被重播到另一个非权威SNMP引擎。后一个非权威SNMP引擎可能会（如果它知道权威SNMP引擎中具有相同机密的相同用户名）因此更新其权威SNMP引擎的及时性指标的概念，但这不被视为威胁。在这种情况下，消息处理模型将丢弃报告或响应消息，因为不应该有未完成的请求消息。陷阱可能会被接受。同样，这也不被视为威胁，因为通信是经过验证的，而且是及时的。这就好像权威SNMP引擎被配置为开始向第二个SNMP引擎发送陷阱，理论上，在第二个SNMP引擎不知情的情况下，这可能会发生。无论如何，第二个SNMP引擎可能不会收到此陷阱，但允许查看其中包含的管理信息。
3) Detection of messages which were not recently generated.
3) 检测最近未生成的消息。
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.
消息中包含一组时间指示器，指示生成时间。没有最近时间指示器的消息不被认为是真实的。此外，SNMP引擎必须删除与未完成请求不匹配的任何响应。然而，这是消息处理模型的责任。
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.
此备忘录允许在多个SNMP引擎上定义同一用户。每个SNMP引擎都维护一个值snmpEngineID，该值唯一标识SNMP引擎。此值包含在发送至/来自授权SNMP引擎的每条消息中（请参阅第1.5.1节）。在收到消息时，权威SNMP引擎检查该值以确保它是预期的收件人，而非权威SNMP引擎使用该值以确保使用正确的状态信息处理消息。
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
每个SNMP引擎维护两个值，snmpEngineBoots和snmpEngineTime，这两个值一起提供该SNMP引擎的时间指示。这两个值都包含在发送到该SNMP引擎或从该SNMP引擎接收到的经过身份验证的消息中。收到时，检查值，以确保指示的
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.
为了使SNMP引擎生成权威SNMP引擎将接受为可信的消息，并验证从该权威SNMP引擎接收的消息是否可信，此类SNMP引擎必须首先实现与权威SNMP引擎的实时同步。见第2.3节。
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.
抽象服务接口已定义为描述SNMP实体内各子系统之间的概念接口。类似地，在基于用户的安全模型（USM）中定义了一组抽象服务接口，以描述通用USM服务与自包含身份验证和隐私服务之间的概念接口。
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.
这些抽象服务接口由一组原语定义，这些原语定义所提供的服务以及调用服务时必须传递的抽象数据元素。本节列出了为基于用户的安全模型定义的原语。
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 =
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
)
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
)
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 =
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)
)
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)
)
This section contains definitions required to realize the security model defined by this memo.
本节包含实现本备忘录定义的安全模型所需的定义。
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.
使用此安全模型的管理操作使用一组已定义的用户标识。对于在特定SNMP引擎上授权其管理操作的任何用户，该SNMP引擎必须了解该用户。希望与另一个SNMP引擎通信的SNMP引擎还必须了解该引擎已知的用户，包括该用户的适用属性。
A user and its attributes are defined as follows:
用户及其属性定义如下：
userName A string representing the name of the user.
userName表示用户名称的字符串。
securityName A human-readable string representing the user in a format that is Security Model independent. There is a one-to-one relationship between userName and securityName.
securityName一个可读字符串，以独立于安全模型的格式表示用户。用户名和securityName之间存在一对一的关系。
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:
authProtocol指示是否可以对代表该用户发送的消息进行身份验证，如果可以，则指示所使用的身份验证协议的类型。本备忘录中定义了两个此类协议：
- the HMAC-MD5-96 authentication protocol. - the HMAC-SHA-96 authentication protocol.
- HMAC-MD5-96认证协议HMAC-SHA-96身份验证协议。
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.
authKey如果可以对代表此用户发送的消息进行身份验证，则为与身份验证协议一起使用的（专用）身份验证密钥。请注意，在不同的权威SNMP引擎中，用户的身份验证密钥通常是不同的。无法通过SNMP访问authKey。authKey的长度要求由使用中的authProtocol定义。
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.
authKeyChange和authOwnKeyChange是远程更新身份验证密钥的唯一方法。以安全的方式进行更新，这样更新就可以在不需要隐私保护的情况下完成。
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.
privProtocol指示是否可以保护代表该用户发送的消息不被泄露，如果可以，则指示使用的隐私协议类型。本备忘录中定义了一个这样的协议：CBC-DES对称加密协议。
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.
私钥如果代表该用户发送的消息可以被加密/解密，则为与隐私协议一起使用的（私钥）。请注意，在不同的权威SNMP引擎中，用户的隐私密钥通常是不同的。无法通过SNMP访问私钥。privKey的长度要求由使用中的privKey协议定义。
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.
privKeyChange和privOwnKeyChange是远程更新加密密钥的唯一方法。以安全的方式进行更新，这样更新就可以在不需要隐私保护的情况下完成。
Each SNMP engine maintains three objects:
每个SNMP引擎维护三个对象：
- snmpEngineID, which (at least within an administrative domain) uniquely and unambiguously identifies an SNMP engine.
- snmpEngineID，它（至少在管理域内）唯一且明确地标识SNMP引擎。
- snmpEngineBoots, which is a count of the number of times the SNMP engine has re-booted/re-initialized since snmpEngineID was last configured; and,
- snmpEngineBoots，是自上次配置snmpEngineID以来SNMP引擎重新引导/重新初始化的次数计数；和
- snmpEngineTime, which is the number of seconds since the snmpEngineBoots counter was last incremented.
- snmpEngineTime，是自snmpEngineBoots计数器上次递增以来的秒数。
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.
每个SNMP引擎对于其自己的SNMP实体中的这些对象始终具有权威性。非权威SNMP引擎有责任酌情与权威SNMP引擎同步。
An authoritative SNMP engine is required to maintain the values of its snmpEngineID and snmpEngineBoots in non-volatile storage.
需要权威的SNMP引擎在非易失性存储中维护其snmpEngineID和snmpEngineBoots的值。
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.
经过身份验证的消息中包含的msgauthoritiveengineid值用于抵御攻击，在这种攻击中，从一个SNMP引擎到另一个SNMP引擎的消息被重播到另一个SNMP引擎。它表示参与消息交换的权威SNMP引擎上的snmpEngineID。
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 [RFC3411]).
首次安装权威SNMP引擎时，它会根据特定于企业的算法设置其snmpEngineID的本地值（请参阅SNMP体系结构文档[RFC3411]中snmpEngineID文本约定的定义）。
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.
经过身份验证的消息中包含的msgAuthoritativeEngineBoots和msgAuthoritativeEngineTime值用于抵御攻击，在这些攻击中，当消息不再有效时，会重播消息。它们表示参与消息交换的权威SNMP引擎上的snmpEngineBoots和snmpEngineTime值。
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.
通过使用snmpEngineBoots和snmpEngineTime，SNMP引擎不需要具有非易失性时钟，即使在SNMP引擎断电时，该时钟也会滴答作响（即，随着时间的推移而增加）。相反，每次SNMP引擎重新引导时，它都会检索、增加snmpEngineBoots，然后将其存储在非易失性存储器中，并将snmpEngineTime重置为零。
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.
首次安装SNMP引擎时，它会将其snmpEngineBoots和snmpEngineTime的本地值设置为零。如果snmpEngineTime曾经达到其最大值（2147483647），则snmpEngineBoots将递增，就像SNMP引擎已重新启动一样，snmpEngineTime重置为零并再次开始递增。
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.
每次权威SNMP引擎重新引导时，持有该权威SNMP引擎的snmpEngineBoots和snmpEngineTime值的任何SNMP引擎都需要在向该权威SNMP引擎发送正确验证的消息之前重新同步（有关（重新）同步过程，请参阅第2.3节）。但是，请注意，这些过程确实提供了一个通知，当由自接收SNMP引擎上次（重新）同步以来已重新启动的权威SNMP引擎发送时，接收SNMP引擎将接受该通知作为真实的通知。
If an authoritative SNMP engine is ever unable to determine its latest snmpEngineBoots value, then it must set its snmpEngineBoots value to 2147483647.
如果权威SNMP引擎无法确定其最新的snmpEngineBoots值，则必须将其snmpEngineBoots值设置为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.
每当snmpEngineBoots的本地值具有值2147483647时，它就会锁定该值，并且经过身份验证的消息总是导致notInTimeWindow身份验证失败。
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 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.
要重置snmpEngineBoots值已达到值2147483647的SNMP引擎，需要手动干预。必须使用新的snmpEngineID值或该SNMP引擎已知的所有用户的身份验证和隐私协议的新秘密值对引擎进行物理访问和重新配置。请注意，即使SNMP引擎每秒重新引导一次，也需要大约68年才能达到2147483647的最大值。
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.
时间窗口是一个值，用于指定代表任何用户生成的消息在其中有效的时间窗口。此备忘录指定对所有用户使用相同的时间窗口值150秒。
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
当非权威SNMP引擎从权威SNMP引擎获得权威SNMP引擎的snmpEngineBoots和snmpEngineTime值的本地概念时，就发生了非权威SNMP引擎为继续进行真实通信所需的时间同步。这些值必须（并保持）在权威SNMP引擎的时间窗口内。因此，权威SNMP引擎值的本地概念必须与存储在权威SNMP引擎中的值保持松散的同步。除了保留来自权威SNMP引擎的snmpEngineBoots和snmpEngineTime的本地副本外，非权威SNMP引擎还必须保留一个副本
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.
局部变量，latestReceivedEngineTime。此值记录非权威SNMP引擎从权威SNMP引擎接收到的snmpEngineTime的最高值，用于消除重播消息的可能性，从而阻止非权威SNMP引擎对snmpEngineTime的概念向前发展。
A non-authoritative SNMP engine must keep local notions of these values (snmpEngineBoots, snmpEngineTime and latestReceivedEngineTime) 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.
非权威SNMP引擎必须为其希望与之通信的每个权威SNMP引擎保留这些值的本地概念（snmpEngineBoots、snmpEngineTime和latestreeceivedEnginetime）。由于每个权威SNMP引擎都由其snmpEngineID值唯一且明确地标识，因此非权威SNMP引擎可以使用该值作为密钥，以便缓存这些值的本地概念。
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 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.
时间同步是接收SNMP消息过程的一部分（第3.2节，步骤7b）。因此，非权威SNMP引擎不需要显式的时间同步过程。请注意，无论何时更改snmpEngineID的本地值（例如，通过发现）或首次与权威SNMP引擎建立安全通信，snmpEngineBoots和latestreeceivedEnginetime的本地值都应设置为零。这将导致在收到下一条真实消息时发生时间同步。
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 [RFC3412]).
使用此安全模型的SNMP消息的语法遵循特定版本的消息处理模型文档（例如[RFC3412]）中定义的消息格式。
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:
SNMPv3消息中的msgSecurityParameters字段的数据类型为八位字节字符串。其值是以下ASN.1序列的BER序列化：
USMSecurityParametersSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN
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(0..32)),
-- authentication protocol specific parameters
msgAuthenticationParameters OCTET STRING,
-- privacy protocol specific parameters
msgPrivacyParameters OCTET STRING
UsmSecurityParameters ::=
SEQUENCE {
-- global User-based security parameters
msgAuthoritativeEngineID OCTET STRING,
msgAuthoritativeEngineBoots INTEGER (0..2147483647),
msgAuthoritativeEngineTime INTEGER (0..2147483647),
msgUserName OCTET STRING (SIZE(0..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.
- msgauthoritiveengineid指定参与消息交换的权威SNMP引擎的snmpEngineID。
- The msgAuthoritativeEngineBoots specifies the snmpEngineBoots value at the authoritative SNMP engine involved in the exchange of the message.
- msgauthoritiveengineboots指定消息交换所涉及的权威SNMP引擎上的snmpEngineBoots值。
- The msgAuthoritativeEngineTime specifies the snmpEngineTime value at the authoritative SNMP engine involved in the exchange of the message.
- msgAuthoritativeEngineTime指定消息交换所涉及的权威SNMP引擎上的snmpEngineTime值。
- The msgUserName specifies the user (principal) on whose behalf the message is being exchanged. Note that a zero-length userName will not match any user, but it can be used for snmpEngineID discovery.
- msgUserName指定代表其交换消息的用户（主体）。请注意，长度为零的用户名不会与任何用户匹配，但它可以用于snmpEngineID发现。
- 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.
- msgAuthenticationParameters由消息使用的身份验证协议定义，如usmUserTable中用户条目中的usmUserAuthProtocol列所定义。
- 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).
- MsgPrivacParameters由用于消息的隐私协议定义，如usmUserTable中用户条目中的usmUserPrivProtocol列所定义）。
See appendix A.4 for an example of the BER encoding of field msgSecurityParameters.
有关字段msgSecurityParameters的BER编码示例，请参见附录A.4。
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.
服务被描述为抽象服务接口的原语，输入和输出被描述为在这些抽象服务原语中传递的抽象数据元素。
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:
当消息处理（MP）子系统调用基于用户的安全模块来保护传出的SNMP消息时，它必须使用安全模块提供的适当服务。提供这两项服务：
1) A service to generate a Request message. The abstract service primitive is:
1) 用于生成请求消息的服务。抽象服务原语是：
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
)
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:
2) 用于生成响应消息的服务。抽象服务原语是：
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
)
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.
状态信息指示消息的编码和安全性是否成功。如果不是，则表明存在问题。
messageProcessingModel The SNMP version number for the message to be generated. This data is not used by the User-based Security module.
messageProcessingModel要生成的消息的SNMP版本号。基于用户的安全模块不使用此数据。
globalData The message header (i.e., its administrative information). This data is not used by the User-based Security module.
globalData消息头（即其管理信息）。基于用户的安全模块不使用此数据。
maxMessageSize The maximum message size as included in the message. This data is not used by the User-based Security module.
maxMessageSize消息中包含的最大消息大小。基于用户的安全模块不使用此数据。
securityParameters These are the security parameters. They will be filled in by the User-based Security module.
securityParameters这些是安全参数。它们将由基于用户的安全模块填写。
securityModel The securityModel in use. Should be User-based Security Model. This data is not used by the User-based Security module.
securityModel正在使用的securityModel。应该是基于用户的安全模型。基于用户的安全模块不使用此数据。
securityName Together with the snmpEngineID it identifies a row in the usmUserTablethat 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.
securityName与snmpEngineID一起标识USMUserTable中用于保护消息的行。securityName的格式独立于安全模型。在响应的情况下，将忽略此参数，并使用缓存中的值。
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.
securityLevel基于用户的安全模块确定是否需要保护消息不被泄露以及是否需要对消息进行身份验证的安全级别。
securityEngineID The snmpEngineID of the authoritative SNMP engine to which a dateRequest 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.
securityEngineID要向其发送日期请求消息的权威SNMP引擎的snmpEngineID。在响应的情况下，它意味着是处理SNMP引擎的snmpEngineID，因此如果指定了它，那么它将被忽略。
scopedPDU The message payload. The data is opaque as far as the User-based Security Model is concerned.
scopedPDU指定消息负载。就基于用户的安全模型而言，数据是不透明的。
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.
securityStateReference在保护传出响应消息时要使用的cachedSecurityData的句柄/引用。这与基于用户的安全模块在处理作为响应消息的传入请求消息时生成的句柄/引用完全相同。
wholeMsg The fully encoded and secured message ready for sending on the wire.
wholeMsg是完全编码和安全的消息，可以通过网络发送。
wholeMsgLength The length of the encoded and secured message (wholeMsg).
wholeMsgLength编码和安全消息（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.
流程完成后，基于用户的安全模块返回状态信息。如果该过程成功，则返回已完成的消息，如果指定的securityLevel请求了隐私和身份验证，则返回该消息。如果该过程未成功，则返回错误指示。
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:
当消息处理（MP）子系统调用基于用户的安全模块来验证传入消息的正确安全性时，它必须使用为传入消息提供的服务。抽象服务原语是：
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
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU
OUT securityStateReference -- reference to security state
) -- information, needed for response
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
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.
状态信息指示进程是否成功。如果不是，则状态信息包括OID和递增的错误计数器的值。
messageProcessingModel The SNMP version number as received in the message. This data is not used by the User-based Security module.
messageProcessingModel消息中接收到的SNMP版本号。基于用户的安全模块不使用此数据。
maxMessageSize The maximum message size as included in the message. The User-bas User-based Security module uses this value to calculate the maxSizeResponseScopedPDU.
maxMessageSize消息中包含的最大消息大小。用户bas基于用户的安全模块使用此值计算maxSizeResponseScopedPDU。
securityParameters These are the security parameters as received in the message.
securityParameters这些是在消息中接收到的安全参数。
securityModel The securityModel in use. Should be the User-based Security Model. This data is not used by the User-based Security module.
securityModel正在使用的securityModel。应该是基于用户的安全模型。基于用户的安全模块不使用此数据。
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.
securityLevel基于用户的安全模块确定是否需要保护消息不被泄露以及是否需要对消息进行身份验证的安全级别。
wholeMsg The whole message as it was received.
wholeMsg在收到整个消息时将其删除。
wholeMsgLength The length of the message as it was received (wholeMsg).
wholeMsgLength消息接收时的长度（wholeMsg）。
securityEngineID The snmpEngineID that was extracted from the field msgAuthoritativeEngineID and that was used to lookup the secrets in the usmUserTable.
securityEngineID从msgauthoritiveengineid字段中提取的snmpEngineID，用于在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.
securityName表示代表其接收消息的用户的安全名称。securityName的格式独立于安全模型。
scopedPDU The message payload. The data is opaque as far as the User-based Security Model is concerned.
scopedPDU指定消息负载。就基于用户的安全模型而言，数据是不透明的。
maxSizeResponseScopedPDU The maximum size of a scopedPDU to be included in a possible Response message. The User-based Security module calculates this size based on the msgMaxSize (as received in the message) and the space required for the message header (including the securityParameters) for such a Response message.
maxSizeResponseScopedPDU要包含在可能的响应消息中的scopedPDU的最大大小。基于用户的安全模块基于msgMaxSize（在消息中接收）和此类响应消息的消息头（包括securityParameters）所需的空间计算此大小。
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
securityStateReference在保护传出响应消息时要使用的cachedSecurityData的句柄/引用。当消息处理子系统调用基于用户的安全模块生成
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.
流程完成后，基于用户的安全模块返回状态信息，如果流程成功，则返回用于进一步处理消息的附加数据元素。如果该过程未成功，则会显示错误指示，可能带有递增的错误计数器的OID和值对。
2.6. Key Localization Algorithm.
2.6. 密钥定位算法。
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].
本地化密钥是用户U和一个权威SNMP引擎E之间共享的密钥。即使用户可能只有一个密码，因此整个网络只有一个密钥，但用户和每个权威SNMP引擎之间共享的实际密钥将不同。这是通过密钥本地化[本地化密钥]实现的。
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.
首先，如果用户使用密码，则使用附录a.2.1和a.2.2中描述的两种算法之一将用户密码转换为密钥Ku。
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.
要将密钥Ku转换为权威SNMP引擎E处用户U的本地化密钥Kul，需要将权威SNMP引擎的snmpEngineID附加到密钥Ku，然后将密钥Ku附加到结果，从而将snmpEngineID封装在用户密钥Ku的两个副本中。然后运行一个安全哈希函数（该函数取决于在权威SNMP引擎E上为此用户U定义的身份验证协议；本文档定义了两个身份验证协议及其基于MD5和SHA的关联算法）。散列函数的输出是权威SNMP引擎E上用户U的本地化密钥Kul。
This section describes the security related procedures followed by an SNMP engine when processing SNMP messages according to the User-based Security Model.
本节介绍SNMP引擎根据基于用户的安全模型处理SNMP消息时遵循的安全相关过程。
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.
本节介绍SNMP引擎在代表用户生成包含管理操作（如请求、响应、通知或报告）的消息时所遵循的过程，该消息具有特定的安全级别。
1) a) If any securityStateReference is passed (Response or Report message), then information concerning the user is extracted from the cachedSecurityData. The cachedSecurityData can now be discarded. The securityEngineID is set to the local snmpEngineID. The securityLevel is set to the value specified by the calling module.
1) a） 如果传递了任何securityStateReference（响应或报告消息），则将从cachedSecurityData中提取有关用户的信息。缓存的安全数据现在可以丢弃。securityEngineID设置为本地snmpEngineID。securityLevel设置为调用模块指定的值。
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.
b) 基于securityName，从本地配置数据存储（LCD，usmUserTable）中提取由securityEngineID指定的与目标snmpEngineID处的用户有关的信息。如果LCD中缺少有关用户的信息，则会向调用模块返回错误指示（unknownSecurityName）。
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.
2) 如果securityLevel指定要保护消息不被泄露，但用户不支持身份验证和隐私协议，则无法发送消息。错误指示（unsupportedSecurityLevel）返回给调用模块。
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.
3) 如果securityLevel指定要对消息进行身份验证，但用户不支持身份验证协议，则无法发送消息。错误指示（unsupportedSecurityLevel）返回给调用模块。
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:
4) a） 如果securityLevel指定要保护消息不被泄露，则表示序列化scopedPDU的八位字节序列将根据用户的隐私协议进行加密。为此，将调用隐私模块，该模块根据抽象原语实现用户的隐私协议：
statusInformation = -- success or failure
encryptData(
IN encryptKey -- user's localized privKey
IN dataToEncrypt -- serialized scopedPDU
OUT encryptedData -- serialized encryptedPDU
OUT privParameters -- serialized privacy parameters
)
statusInformation = -- success or failure
encryptData(
IN encryptKey -- user's localized privKey
IN dataToEncrypt -- serialized scopedPDU
OUT encryptedData -- serialized encryptedPDU
OUT privParameters -- serialized privacy parameters
)
statusInformation indicates if the encryption process was successful or not.
statusInformation指示加密过程是否成功。
encryptKey the user's localized private privKey is the secret key that can be used by the encryption algorithm.
encryptKey用户的本地化私钥是加密算法可以使用的密钥。
dataToEncrypt the serialized scopedPDU is the data to be encrypted.
dataToEncrypt序列化的scopedPDU是要加密的数据。
encryptedData the encryptedPDU represents the encrypted scopedPDU, encoded as an OCTET STRING.
encryptedData encryptedPDU表示加密的scopedPDU，编码为八位字节字符串。
privParameters the privacy parameters, encoded as an OCTET STRING.
privParameters隐私参数，编码为八位字节字符串。
If the privacy module returns failure, then the message cannot be sent and an error indication (encryptionError) is returned to the calling module.
如果隐私模块返回失败，则无法发送消息，并向调用模块返回错误指示（encryptionError）。
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.
如果隐私模块返回success，则返回的privParameters将被放入securityParameters的msgprivacParameters字段中，encryptedPDU将用作正在准备的消息的有效负载。
Otherwise,
否则
b) If the securityLevel specifies that the message is not to be be protected from disclosure, then a zero-length OCTET STRING is encoded into the msgPrivacyParameters field of the securityParameters and the plaintext scopedPDU serves as the payload of the message being prepared.
b) 如果securityLevel指定不保护消息不被泄露，则将零长度八位字节字符串编码到securityParameters的MsgPrivacParameters字段中，明文scopedPDU用作正在准备的消息的有效负载。
5) The securityEngineID is encoded as an OCTET STRING into the msgAuthoritativeEngineID field of the securityParameters. Note that an empty (zero length) securityEngineID is OK for a Request message, because that will cause the remote (authoritative) SNMP engine to return a Report PDU with the proper securityEngineID included in the msgAuthoritativeEngineID in the securityParameters of that returned Report PDU.
5) securityEngineID作为八位字节字符串编码到securityParameters的msgAuthoritativeEngineID字段中。请注意，对于请求消息，空（零长度）securityEngineID是可以的，因为这将导致远程（权威）SNMP引擎返回一个报告PDU，该报告PDU的securityParameters中的MSGauthoritiveEngineID包含正确的securityEngineID。
6) a) If the securityLevel specifies that the message is to be authenticated, then the current values of snmpEngineBoots and snmpEngineTime corresponding to the securityEngineID from the LCD are used.
6) a） 如果securityLevel指定要对消息进行身份验证，则使用与LCD中securityEngineID对应的snmpingineboots和snmpEngineTime的当前值。
Otherwise,
否则
b) If this is a Response or Report message, then the current value of snmpEngineBoots and snmpEngineTime corresponding to the local snmpEngineID from the LCD are used.
b) 如果这是响应或报告消息，则使用与来自LCD的本地snmpEngineID相对应的snmpEngineBoots和snmpEngineTime的当前值。
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.
c) 如果这是一条请求消息，那么snmpEngineBoots和snmpEngineTime都使用零值。如果snmpEngineID为空，则使用此零值。
The values are encoded as INTEGER respectively into the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields of the securityParameters.
这些值分别作为整数编码到securityParameters的MsgAuthorityVengineBoots和MsgAuthorityVengineTime字段中。
7) The userName is encoded as an OCTET STRING into the msgUserName field of the securityParameters.
7) 用户名作为八位字节字符串编码到securityParameters的msgUserName字段中。
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:
8) a） 如果securityLevel指定要对消息进行身份验证，则根据用户的身份验证协议对消息进行身份验证。为此，将调用身份验证模块，该模块根据抽象服务原语实现用户的身份验证协议：
statusInformation = authenticateOutgoingMsg( IN authKey -- the user's localized authKey IN wholeMsg -- unauthenticated message OUT authenticatedWholeMsg -- authenticated complete message )
statusInformation=authenticateOutgoingMsg（在authKey中--用户在wholeMsg中的本地化authKey--未经验证的消息输出authenticatedWholeMsg--已验证的完整消息）
statusInformation indicates if authentication was successful or not.
statusInformation指示身份验证是否成功。
authKey the user's localized private authKey is the secret key that can be used by the authentication algorithm.
authKey用户的本地化私有authKey是身份验证算法可以使用的密钥。
wholeMsg the complete serialized message to be authenticated.
wholeMsg要验证的完整序列化消息。
authenticatedWholeMsg the same as the input given to the authenticateOutgoingMsg service, but with msgAuthenticationParameters properly filled in.
authenticatedWholeMsg与提供给authenticateOutgoingMsg服务的输入相同，但正确填写了msgAuthenticationParameters。
If the authentication module returns failure, then the message cannot be sent and an error indication (authenticationFailure) is returned to the calling module.
如果身份验证模块返回失败，则无法发送消息，并向调用模块返回错误指示（authenticationFailure）。
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.
如果身份验证模块返回success，则msgAuthenticationParameters字段将放入securityParameters中，authenticatedWholeMsg表示正在准备的已验证消息的序列化。
Otherwise,
否则
b) If the securityLevel specifies that the message is not to be authenticated then a zero-length OCTET STRING is encoded into the msgAuthenticationParameters field of the securityParameters. The wholeMsg is now serialized and then represents the unauthenticated message being prepared.
b) 如果securityLevel指定消息不进行身份验证，则将零长度八位字节字符串编码到securityParameters的msgAuthenticationParameters字段中。wholeMsg现在被序列化，然后表示正在准备的未经验证的消息。
9) The completed message with its length is returned to the calling module with the statusInformation set to success.
9) 完成的消息及其长度将返回给调用模块，状态信息设置为success。
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.
本节介绍SNMP引擎在接收到包含代表用户的管理操作（具有特定安全级别）的消息时所遵循的过程。
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, an error indication can return an OID and value for an incremented counter and optionally a value for securityLevel, and values for contextEngineID or contextName for the counter. In addition, the securityStateReference data is returned if any such information is available at the point where the error is detected.
为了简化过程的元素，并不总是明确指定状态信息的发布。作为一般规则，如果在丢弃消息时状态信息可用，则还应释放状态信息。此外，错误指示可以返回递增计数器的OID和值，还可以选择返回securityLevel的值，以及计数器的contextEngineID或contextName的值。此外，如果在检测到错误的点上有任何此类信息可用，则返回securityStateReference数据。
1) If the received securityParameters is not the serialization (according to the conventions of [RFC3417]) of an OCTET STRING formatted according to the UsmSecurityParameters defined in section 2.4, then the snmpInASNParseErrs counter [RFC3418] 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.
1) 如果收到的securityParameters不是根据第2.4节中定义的UsmSecurityParameters格式化的八位字节字符串的序列化（根据[RFC3417]约定），则SNMPinasnParsers计数器[RFC3418]递增，并向调用模块返回错误指示（parseError）。注意，我们返回时没有OID和递增计数器的值，因为在这种情况下，没有足够的信息生成报告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:
2) 安全参数字段的值从securityParameters中提取。要返回给调用方的securityEngineID是msgAuthoritativeEngineID字段的值。已准备cachedSecurityData，并准备securityStateReference来引用此数据。要缓存的值包括：
msgUserName
msgUserName
3) If the value of the msgAuthoritativeEngineID field in the securityParameters is unknown then:
3) 如果securityParameters中MsgAuthorityVengineId字段的值未知，则：
a) a non-authoritative SNMP engine that performs discovery may optionally create a new entry in its Local Configuration Datastore (LCD) and continue processing;
a) 执行发现的非权威SNMP引擎可以选择在其本地配置数据存储（LCD）中创建新条目并继续处理；
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.
b) USMStatsUnknowneEngineId计数器递增，错误指示（UnknowneEngineId）连同递增计数器的OID和值一起返回给调用模块。
Note in the event that a zero-length, or other illegally sized msgAuthoritativeEngineID is received, b) should be chosen to facilitate engineID discovery. Otherwise the choice between a) and b) is an implementation issue.
注意：如果接收到长度为零或其他非法大小的MSGauthoritiveEngineid，则应选择b）以便于engineID发现。否则，a）和b）之间的选择是一个实现问题。
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.
4) 有关msgUserName和msgAuthoritativeEngineID字段值的信息从本地配置数据存储（LCD，usmUserTable）中提取。如果用户没有可用信息，则usmStatsUnknownUserNames计数器将递增，并将错误指示（unknownSecurityName）以及递增计数器的OID和值返回给调用模块。
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.
5) 如果有关用户的信息表明它不支持调用者请求的securityLevel，则USMStatsSupportedSecLevel计数器将递增，并将错误指示（unsupportedSecurityLevel）以及递增计数器的OID和值返回给调用模块。
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:
6) 如果securityLevel指定要对消息进行身份验证，则根据用户的身份验证协议对消息进行身份验证。为此，将调用身份验证模块，该模块根据抽象服务原语实现用户的身份验证协议：
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 = -- 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.
statusInformation指示身份验证是否成功。
authKey the user's localized private authKey is the secret key that can be used by the authentication algorithm.
authKey用户的本地化私有authKey是身份验证算法可以使用的密钥。
wholeMsg the complete serialized message to be authenticated.
wholeMsg要验证的完整序列化消息。
authenticatedWholeMsg the same as the input given to the authenticateIncomingMsg service, but after authentication has been checked.
authenticatedWholeMsg与提供给authenticateIncomingMsg服务的输入相同，但在检查了身份验证之后。
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.
如果身份验证模块返回失败，则消息不可信，因此usmStatsWrongDigests计数器将递增，并将错误指示（authenticationFailure）以及递增计数器的OID和值返回给调用模块。
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, snmpEngineTime and latestReceivedEngineTime corresponding to the value of the msgAuthoritativeEngineID field are extracted from the Local Configuration Datastore.
7) 如果securityLevel指示经过身份验证的消息，则从本地配置数据存储中提取与msgAuthoritativeEngineID字段的值相对应的snmpEngineBoots、snmpEngineTime和LateStreeceivedEnginetime的本地值。
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:
a) 如果msgauthoritiveengineid的提取值与处理SNMP引擎的snmpEngineID的值相同（意味着这是权威SNMP引擎），则如果以下任一条件为真，则该消息被视为在时间窗口之外：
- the local value of snmpEngineBoots is 2147483647;
- snmpEngineBoots的本地值为2147483647；
- the value of the msgAuthoritativeEngineBoots field differs from the local value of snmpEngineBoots; or,
- MsgAuthorityVengineboots字段的值不同于snmpEngineBoots的本地值；或
- the value of the msgAuthoritativeEngineTime field differs from the local notion of snmpEngineTime by more than +/- 150 seconds.
- MsgAuthorityVengineTime字段的值与snmpEngineTime的本地概念的差异超过+/-150秒。
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, the value of the incremented counter, and an indication that
如果消息被认为在时间窗口之外，则USMStatsNotimeWindows计数器将递增，并显示错误指示（notInTimeWindow）、OID、递增计数器的值以及
the error must be reported with a securityLevel of authNoPriv, is returned to the calling module
必须使用securityLevel authNoPriv报告错误，并将其返回给调用模块
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:
b) 如果msgauthoritiveengineid的提取值与处理SNMP引擎的snmpEngineID值不同（这意味着这不是权威SNMP引擎），则：
1) if at least one of the following conditions is true:
1) 如果至少下列条件之一为真：
- the extracted value of the msgAuthoritativeEngineBoots field is greater than the local notion of the value of snmpEngineBoots; or,
- MsgAuthorityVengineboots字段的提取值大于snmpEngineBoots值的本地概念；或
- the extracted value of the msgAuthoritativeEngineBoots field is equal to the local notion of the value of snmpEngineBoots, and the extracted value of msgAuthoritativeEngineTime field is greater than the value of latestReceivedEngineTime,
- MsgAuthorityVengineBoots字段的提取值等于snmpingineBoots值的本地概念，MsgAuthorityVengineTime字段的提取值大于latestReceivedEngineTime的值，
then the LCD entry corresponding to the extracted value of the msgAuthoritativeEngineID field is updated, by setting:
然后，通过设置以下内容，更新与msgAuthoritativeEngineID字段的提取值相对应的LCD条目：
- the local notion of the value of snmpEngineBoots to the value of the msgAuthoritativeEngineBoots field,
- snmpEngineBoots值与msgauthoritiveengineboots字段值的局部概念，
- the local notion of the value of snmpEngineTime to the value of the msgAuthoritativeEngineTime field, and
- snmpEngineTime值与msgauthoritiveenginetime字段值之间的局部概念，以及
- the latestReceivedEngineTime to the value of the value of the msgAuthoritativeEngineTime field.
- 将latestReceivedEngineTime设置为msgAuthoritativeEngineTime字段值的值。
2) if any of the following conditions is true, then the message is considered to be outside of the Time Window:
2) 如果以下任一条件为真，则该消息被视为在时间窗口之外：
- the local notion of the value of snmpEngineBoots is 2147483647;
- snmpEngineBoots价值的本地概念为2147483647；
- the value of the msgAuthoritativeEngineBoots field is less than the local notion of the value of snmpEngineBoots; or,
- MsgAuthorityVengineboots字段的值小于snmpEngineBoots值的本地概念；或
- 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 the value of snmpEngineTime.
- MsgAuthorityVengineBoots字段的值等于snmpEngineBoots值的本地概念，MsgAuthorityVengineTime字段的值比snmpEngineTime值的本地概念小150秒以上。
If the message is considered to be outside of the Time Window then an error indication (notInTimeWindow) is returned to the calling module.
如果消息被认为在时间窗口之外，则会向调用模块返回错误指示（notInTimeWindow）。
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 when received from an authoritative SNMP engine that has re-booted since the receiving SNMP engine last (re-)synchronized.
请注意，此过程允许消息中MsgAuthorityVengineboots的值大于snmpEngineBoots值的本地概念，以允许从自接收SNMP引擎上次（重新）同步以来重新启动的权威SNMP引擎接收消息时，接收到的消息被接受为真实消息。
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:
8) a） 如果securityLevel指示消息受到保护，不被泄露，则表示加密PDU的八位字节字符串将根据用户的隐私协议进行解密，以获得未加密的序列化scopedPDU值。为此，将调用隐私模块，该模块根据抽象原语实现用户的隐私协议：
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 = -- 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.
statusInformation指示解密过程是否成功。
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.
privParameters MSGPRIVAcParameters，编码为八位字节字符串。
encryptedData the encryptedPDU represents the encrypted scopedPDU, encoded as an OCTET STRING.
encryptedData encryptedPDU表示加密的scopedPDU，编码为八位字节字符串。
decryptedData the serialized scopedPDU if decryption is successful.
decryptedData如果解密成功，则返回序列化的scopedPDU。
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.
如果隐私模块返回失败，则无法处理消息，因此usmStatsDecryptionErrors计数器将递增，并将错误指示（decryptionError）以及递增计数器的OID和值返回给调用模块。
If the privacy module returns success, then the decrypted scopedPDU is the message payload to be returned to the calling module.
如果隐私模块返回success，则解密的scopedPDU是要返回给调用模块的消息负载。
Otherwise,
否则
b) The scopedPDU component is assumed to be in plain text and is the message payload to be returned to the calling module.
b) scopedPDU组件假定为纯文本，并且是要返回给调用模块的消息负载。
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.
9) 计算最大SizeResponseScopedPDU。这是scopedPDU允许的可能响应消息的最大大小。为允许与接收到的请求具有相同安全级别的消息头做了准备。
10) The securityName for the user is retrieved from the usmUserTable.
10） 用户的securityName是从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. Information to be saved/cached is as follows:
11） 安全数据缓存为cachedSecurityData，因此对此消息的可能响应可以并且将使用相同的身份验证和隐私机密。要保存/缓存的信息如下所示：
msgUserName, usmUserAuthProtocol, usmUserAuthKey usmUserPrivProtocol, usmUserPrivKey
msgUserName、usmUserAuthProtocol、usmUserAuthKey usmUserPrivProtocol、usmUserPrivKey
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.
12） statusInformation设置为success，并向调用模块返回processIncomingMsg原语中指定的OUT参数。
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 zero-length, 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
基于用户的安全模型要求发现过程获得有关其他SNMP引擎的足够信息，以便与它们通信。发现要求非权威SNMP引擎在继续通信之前学习权威SNMP引擎的snmpEngineID值。这可以通过生成securityLevel为noAuthNoPriv的请求消息、长度为零的msgUserName、长度为零的msgauthoritiveengineid值以及保留为空的varBindList来实现。对此消息的响应将是一条报告消息，其中包含权威SNMP引擎的snmpEngineID，作为msgSecurityParameters中MsgAuthorityVeengineId字段的值
field. It contains a Report PDU with the usmStatsUnknownEngineIDs counter in the varBindList.
领域它包含一个报告PDU，其中varBindList中包含USMStatSunKnowneEngineIds计数器。
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 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. For an authenticated Request message, a valid userName must be used in the msgUserName field. 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.
如果需要经过身份验证的通信，则发现过程还应与权威SNMP引擎建立时间同步。这可以通过发送一条经过身份验证的请求消息来实现，该消息的值msgauthoritiveengineid设置为新学习的snmpEngineID，msgauthoritiveengineboots和msgauthoritiveenginetime设置为零。对于经过身份验证的请求消息，必须在msgUserName字段中使用有效的用户名。对此经过身份验证的消息的响应将是一条报告消息，其中包含权威SNMP引擎的snmpEngineBoots和snmpEngineTime的最新值，分别作为MsgAuthoritativeEngineeboots和msgAuthoritativeEngineTime字段的值。它还包含报表PDU的varBindList中的USMStatsNotTimeWindows计数器。然后，作为第3.2节步骤7b中程序的一部分，时间同步会自动进行。另见第2.3节。
SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
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;
从SNMPv2 SMI文本约定、TestAndIncr、RowStatus、RowPointer、StorageType、AutonomousType从SNMPv2 TC MODULE-COMPLIANCE导入模块标识、对象类型、对象标识、snmpModules、计数器32从SNMPv2 CONF导入SNMPAdministring、SnmpEngineID、snmpAuthProtocols、snmpPrivProtocols从SNMP-FRAMEWORK-MIB导入；
snmpUsmMIB MODULE-IDENTITY LAST-UPDATED "200210160000Z" -- 16 Oct 2002, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In msg body: subscribe snmpv3
snmpUsmMIB模块-身份最新更新“200210160000Z”-2002年10月16日，午夜组织“SNMPv3工作组”联系信息工作组电子邮件：snmpv3@lists.tislabs.com订阅：majordomo@lists.tislabs.com在消息正文中：订阅snmpv3
Chair: Russ Mundy Network Associates Laboratories postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA email: mundy@tislabs.com
主席：Russ Mundy Network Associates Laboratories邮政：美国马里兰州罗克维尔市欧米茄大道15204号300室20850-4601电子邮件：mundy@tislabs.com
phone: +1 301-947-7107
电话：+1 301-947-7107
Co-Chair: David Harrington Enterasys Networks Postal: 35 Industrial Way P. O. Box 5004 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com Phone: +1 603-337-2614
联席主席：David Harrington Enterasys Networks邮政：美国新罕布什尔州罗切斯特市工业路35号邮政信箱5004 03866-5005电子邮件：dbh@enterasys.com电话：+1603-337-2614
Co-editor Uri Blumenthal Lucent Technologies postal: 67 Whippany Rd. Whippany, NJ 07981 USA email: uri@lucent.com phone: +1-973-386-2163
联合编辑Uri Blumenthal-Lucent Technologies邮政：新泽西州惠帕尼路67号惠帕尼07981美国电子邮件：uri@lucent.com电话：+1-973-386-2163
Co-editor: Bert Wijnen Lucent Technologies postal: Schagen 33 3461 GL Linschoten Netherlands email: bwijnen@lucent.com phone: +31-348-480-685 " DESCRIPTION "The management information definitions for the SNMP User-based Security Model.
合编：Bert Wijnen-Lucent Technologies邮政：Schagen 33 3461 GL Linschoten荷兰电子邮件：bwijnen@lucent.com电话：+31-348-480-685“说明”基于SNMP用户的安全模型的管理信息定义。
Copyright (C) The Internet Society (2002). This version of this MIB module is part of RFC 3414; see the RFC itself for full legal notices. " -- Revision history
版权所有（C）互联网协会（2002年）。此版本的MIB模块是RFC 3414的一部分；有关完整的法律通知，请参见RFC本身。“--修订历史
REVISION "200210160000Z" -- 16 Oct 2002, midnight DESCRIPTION "Changes in this revision: - Updated references and contact info. - Clarification to usmUserCloneFrom DESCRIPTION clause - Fixed 'command responder' into 'command generator' in last para of DESCRIPTION clause of usmUserTable. This revision published as RFC3414. " REVISION "199901200000Z" -- 20 Jan 1999, midnight DESCRIPTION "Clarifications, published as RFC2574"
修订版“200210160000Z”-2002年10月16日，午夜描述“本修订版中的更改：-更新的参考资料和联系信息。-向USMUSERCONE澄清从描述条款-修正usmUserTable描述条款最后一段中的“命令响应者”到“命令生成器”。本修订版发布为RFC3414。“修订版“199901200000Z”--1999年1月20日，午夜描述“澄清，发布为RFC2574”
REVISION "199711200000Z" -- 20 Nov 1997, midnight DESCRIPTION "Initial version, published as RFC2274"
修订版“199711200000Z”-1997年11月20日，午夜描述“初始版本，发布为RFC2274”
::= { snmpModules 15 }
::= { snmpModules 15 }
-- Administrative assignments ****************************************
-- Administrative assignments ****************************************
usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
-- Identification of Authentication and Privacy Protocols ************
-- Identification of Authentication and Privacy Protocols ************
usmNoAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "No Authentication Protocol."
::= { snmpAuthProtocols 1 }
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 }
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 }
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 }
usmNoPrivProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "No Privacy Protocol."
::= { snmpPrivProtocols 1 }
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.
usmDESPrivProtocol对象标识状态当前描述“CBC-DES对称加密协议。”参考-数据加密标准，国家标准与技术研究所。联邦信息处理标准（FIPS）出版物46-1。
Supersedes FIPS Publication 46, (January, 1977; reaffirmed January, 1988).
取代FIPS第46号出版物（1977年1月；1988年1月重申）。
- Data Encryption Algorithm, American National Standards Institute. ANSI X3.92-1981, (December, 1980).
- 数据加密算法，美国国家标准协会。ANSI X3.92-1981（1980年12月）。
- DES Modes of Operation, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 81, (December, 1980).
- DES操作模式，国家标准与技术研究所。联邦信息处理标准（FIPS）第81号出版物（1980年12月）。
- Data Encryption Algorithm - Modes of Operation,
American National Standards Institute.
ANSI X3.106-1983, (May 1983).
"
::= { snmpPrivProtocols 2 }
- Data Encryption Algorithm - Modes of Operation,
American National Standards Institute.
ANSI X3.106-1983, (May 1983).
"
::= { snmpPrivProtocols 2 }
-- Textual Conventions ***********************************************
-- 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.
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.
对象的值是管理器生成的部分随机值，当修改该值时，通过单向函数修改密钥K的值。
The value of an instance of this object is the concatenation of two components: first a 'random' component and then a 'delta' component.
此对象实例的值是两个组件的串联：首先是“随机”组件，然后是“增量”组件。
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.
随机分量和增量分量的长度由协议P的相应值给出；如果P要求K是固定长度，则随机分量和增量分量的长度都是该固定长度；如果P允许K的长度可变至特定的最大长度，则随机分量的长度为该最大长度，而δ分量的长度为小于或等于该最大长度的任何长度。例如，usmHMACMD5AuthProtocol要求K为16个八位字节的固定长度，L为16个八位字节的固定长度。USMHMacShaauth协议要求K为20个八位字节的固定长度，L为20个八位字节的固定长度。其他协议可定义其他尺寸（视情况而定）。
When a requester 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:
当请求者希望将远程实体上的旧密钥K更改为新密钥keyNew时，“随机”分量从真随机生成器或伪随机生成器获得，并且“增量”分量的计算如下：
- 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 keyNew 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.
- 将临时变量初始化为现有值K；-如果keyNew的长度大于L个八位字节，则：-将随机分量附加到临时变量的值，并将结果输入哈希算法H以生成摘要值，并且将临时变量设置为此摘要值；-临时变量的值与keyNew的第一个（下一个）L-八位字节（MD5时为16个八位字节）异或，以生成“增量”分量的第一个（下一个）L-八位字节（MD5时为16个八位字节）。-重复上述两个步骤，直到keyNew组件的未使用部分为L个八位字节或更少，-随机组件被附加到临时变量的值，并且结果被输入到哈希算法H以产生摘要值；-此摘要值（必要时被截断为与keyNew的未使用部分长度相同）与keyNew的未使用部分异或，以生成“delta”组件的（最终部分）。
For example, using MD5 as the hash algorithm H:
例如，使用MD5作为哈希算法H：
iterations = (lenOfDelta - 1)/16; /* integer division */
temp = keyOld;
for (i = 0; i < iterations; i++) {
temp = MD5 (temp || random);
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];
iterations = (lenOfDelta - 1)/16; /* integer division */
temp = keyOld;
for (i = 0; i < iterations; i++) {
temp = MD5 (temp || random);
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 recipient 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:
在接收器端，当该对象的实例被设置为新值时，新值K的计算如下：
- 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 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.
- 将临时变量初始化为现有值K；-如果增量分量的长度大于L个八位字节，则：-将随机分量附加到临时变量的值，并将结果输入哈希算法H以生成摘要值，并且将临时变量设置为此摘要值；-临时变量的值与增量分量的第一个（下一个）L-八位字节（MD5情况下为16个八位字节）异或，以产生新值K的第一个（下一个）L-八位字节（MD5情况下为16个八位字节）。重复上述两个步骤，直到增量分量的未使用部分等于或小于L个八位字节，-将随机分量附加到临时变量的值上，并将结果输入哈希算法H以生成摘要值；-该摘要值（必要时被截断为与增量分量的未使用部分长度相同）与增量分量的未使用部分异或，以产生新的（增量分量的最终部分）值K。
For example, using MD5 as the hash algorithm H:
例如，使用MD5作为哈希算法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);
keyNew[i*16 .. lenOfDelta-1] =
temp XOR delta[i*16 .. lenOfDelta-1];
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);
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.
每当管理协议检索到具有此语法的对象时，该对象的值始终为零长度字符串。
Note that the keyOld and keyNew are the localized keys.
请注意，keyOld和keyNew是本地化键。
Note that it is probably wise that when an SNMP entity sends a SetRequest to change a key, that it keeps a copy of the old key until it has confirmed that the key change actually succeeded. " SYNTAX OCTET STRING
请注意，当SNMP实体发送更改密钥的SetRequest时，它可能会保留旧密钥的副本，直到确认密钥更改实际成功为止。语法八位组字符串
-- Statistics for the User-based Security Model **********************
-- Statistics for the User-based Security Model **********************
usmStats OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
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 }
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 }
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 }
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
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 }
usmStatsUnknownEngineIDs 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 an
snmpEngineID that was not known to the SNMP engine.
"
::= { usmStats 4 }
usmStatsWrongDigests OBJECT-TYPE
usmstatswrongs对象类型摘要
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 }
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 }
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 ************************************************
-- The usmUser Group ************************************************
usmUser OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
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 }
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 ********
-- The table of valid users for the User-based Security Model ********
usmUserTable OBJECT-TYPE SYNTAX SEQUENCE OF UsmUserEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of users configured in the SNMP engine's Local Configuration Datastore (LCD).
usmUserTable UsmUserEntry MAX-ACCESS的对象类型语法序列不可访问状态当前描述“SNMP引擎本地配置数据存储（LCD）中配置的用户表”。
To create a new user (i.e., to instantiate a new conceptual row in this table), it is recommended to follow this procedure:
要创建新用户（即，在此表中实例化一个新的概念行），建议遵循以下步骤：
1) GET(usmUserSpinLock.0) and save in sValue.
1) 获取（usmUserSpinLock.0）并保存在sValue中。
2) SET(usmUserSpinLock.0=sValue, usmUserCloneFrom=templateUser, usmUserStatus=createAndWait) You should use a template user to clone from which has the proper auth/priv protocol defined.
2) SET（usmUserSpinLock.0=sValue，usmUserCloneFrom=templateUser，usmUserStatus=createAndWait）您应该使用一个模板用户进行克隆，从中定义了正确的auth/priv协议。
If the new user is to use privacy:
如果新用户要使用隐私：
3) generate the keyChange value based on the secret privKey of the clone-from user and the secret key to be used for the new user. Let us call this pkcValue. 4) GET(usmUserSpinLock.0) and save in sValue. 5) SET(usmUserSpinLock.0=sValue, usmUserPrivKeyChange=pkcValue usmUserPublic=randomValue1) 6) GET(usmUserPulic) and check it has randomValue1. If not, repeat steps 4-6.
3) 根据来自用户的克隆的密钥和用于新用户的密钥生成密钥更改值。让我们称之为pkc值。4） 获取（usmUserSpinLock.0）并保存在sValue中。5） 设置（usmUserSpinLock.0=sValue，usmUserPrivKeyChange=pkcValue usmUserPublic=randomValue1）6）获取（usmUserPulic）并检查其是否具有randomValue1。如果没有，重复步骤4-6。
If the new user will never use privacy:
如果新用户永远不会使用隐私：
7) SET(usmUserPrivProtocol=usmNoPrivProtocol)
7) 设置（usmUserPrivProtocol=usmNoPrivProtocol）
If the new user is to use authentication:
如果新用户要使用身份验证：
8) generate the keyChange value based on the secret authKey of the clone-from user and the secret key to be used for the new user. Let us call this akcValue. 9) GET(usmUserSpinLock.0) and save in sValue. 10) SET(usmUserSpinLock.0=sValue, usmUserAuthKeyChange=akcValue usmUserPublic=randomValue2) 11) GET(usmUserPulic) and check it has randomValue2. If not, repeat steps 9-11.
8) 根据来自用户的克隆的密钥authKey和用于新用户的密钥生成密钥更改值。让我们称之为AKC值。9） 获取（usmUserSpinLock.0）并保存在sValue中。10） 设置（usmUserSpinLock.0=sValue，usmUserAuthKeyChange=akcValue usmUserPublic=randomValue2）11）获取（usmUserPulic）并检查其是否具有randomValue2。如果没有，重复步骤9-11。
If the new user will never use authentication:
如果新用户永远不会使用身份验证：
12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
12） 设置（USMUSERAUTH协议=USMNOAUTH协议）
Finally, activate the new user:
最后，激活新用户：
13) SET(usmUserStatus=active)
13） 设置（usmUserStatus=活动）
The new user should now be available and ready to be used for SNMPv3 communication. Note however that access to MIB data must be provided via configuration of the SNMP-VIEW-BASED-ACM-MIB.
新用户现在应该可用，并准备好用于SNMPv3通信。但是请注意，必须通过配置SNMP-VIEW-BASED-ACM-MIB来提供对MIB数据的访问。
The use of usmUserSpinlock is to avoid conflicts with
another SNMP command generator application which may
also be acting on the usmUserTable.
"
::= { usmUser 2 }
The use of usmUserSpinlock is to avoid conflicts with
another SNMP command generator application which may
also be acting on the usmUserTable.
"
::= { 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 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
}
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.
usmUserEngineID对象类型语法SnmpEngineID MAX-ACCESS不可访问状态当前描述“SNMP引擎的管理唯一标识符。
In a simple agent, this value is always that agent's own snmpEngineID value.
在简单代理中，该值始终是该代理自己的snmpEngineID值。
The value can also take the value of the snmpEngineID of a remote SNMP engine with which this user can communicate.
该值还可以采用该用户可以与其通信的远程SNMP引擎的snmpEngineID的值。
"
::= { usmUserEntry 1 }
"
::= { 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.
usmUserName对象类型语法SnmpAdminString（大小（1..32））MAX-ACCESS not accessible STATUS current DESCRIPTION“表示用户名称的可读字符串。
This is the (User-based Security) Model dependent
security ID.
"
::= { usmUserEntry 2 }
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.
usmUserSecurityName对象类型语法SnmpAdminString MAX-ACCESS只读状态current DESCRIPTION“以独立于安全模型的格式表示用户的可读字符串。
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 }
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.
usmUserCloneFrom对象类型语法RowPointer MAX-ACCESS read create STATUS current DESCRIPTION“指向此usmUserTable中另一概念行的指针。此另一概念行中的用户称为克隆自用户。
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 must be cloned from its clone-from user. These parameters are: - authentication protocol (usmUserAuthProtocol) - privacy protocol (usmUserPrivProtocol) They will be copied regardless of what the current value is.
创建新用户时（即，此表中实例化了一个新的概念行），新用户的隐私和身份验证参数必须从其“从用户克隆”中克隆。这些参数是：-身份验证协议（usmUserAuthProtocol）-隐私协议（usmUserPrivProtocol）。无论当前值是什么，都将复制这些参数。
Cloning also causes the initial values of the secret authentication key (authKey) and the secret encryption
克隆还会导致秘密身份验证密钥（authKey）和秘密加密的初始值
key (privKey) of the new user to be set to the same values as the corresponding secrets of the clone-from user to allow the KeyChange process to occur as required during user creation.
要将新用户的密钥（privKey）设置为与来自用户的克隆的相应机密相同的值，以允许在用户创建期间根据需要执行密钥更改过程。
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' error if the conceptual row representing the clone-from user does not exist or is not in an active state when the cloning process is invoked.
第一次通过管理操作设置此对象的实例时（在其实例化时或之后），将调用克隆过程。后续写入成功，但不会调用接收方要采取的任何操作。如果在调用克隆过程时表示来自用户的克隆的概念行不存在或不处于活动状态，则克隆过程将失败，并出现“不一致名称”错误。
When this object is read, the ZeroDotZero OID
is returned.
"
::= { usmUserEntry 4 }
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.
usmUserAuthProtocol对象类型语法AutonomousType MAX-ACCESS读取创建状态当前描述”指示是否可以对代表此用户发送到/从usmUserEngineID标识的SNMP引擎发送的消息进行身份验证，如果可以，则指示使用的身份验证协议类型。
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).
该对象的实例与为同一用户创建任何其他对象实例同时创建（即，作为在同一概念行中创建第一个对象实例的set操作处理的一部分）。
If an initial set operation (i.e. at row creation time) tries to set a value for an unknown or unsupported protocol, then a 'wrongValue' error must be returned.
如果初始设置操作（即在行创建时）尝试为未知或不受支持的协议设置值，则必须返回“错误值”错误。
The value will be overwritten/set when a set operation is performed on the corresponding instance of usmUserCloneFrom.
当对USMUSERCLONEFORM的相应实例执行set操作时，该值将被覆盖/设置。
Once instantiated, the value of such an instance of this object can only be changed via a set operation to the value of the usmNoAuthProtocol.
一旦实例化，这个对象的实例的值只能通过set操作更改为usmNoAuthProtocol的值。
If a set operation tries to change the value of an
如果集合操作试图更改
existing instance of this object to any value other than usmNoAuthProtocol, then an 'inconsistentValue' error must be returned.
将此对象的现有实例设置为usmNoAuthProtocol以外的任何值，则必须返回“不一致值”错误。
If a set operation tries to set the value to the
usmNoAuthProtocol while the usmUserPrivProtocol value
in the same row is not equal to usmNoPrivProtocol,
then an 'inconsistentValue' error must be returned.
That means that an SNMP command generator application
must first ensure that the usmUserPrivProtocol is set
to the usmNoPrivProtocol value before it can set
the usmUserAuthProtocol value to usmNoAuthProtocol.
"
DEFVAL { usmNoAuthProtocol }
::= { usmUserEntry 5 }
If a set operation tries to set the value to the
usmNoAuthProtocol while the usmUserPrivProtocol value
in the same row is not equal to usmNoPrivProtocol,
then an 'inconsistentValue' error must be returned.
That means that an SNMP command generator application
must first ensure that the usmUserPrivProtocol is set
to the usmNoPrivProtocol value before it can set
the usmUserAuthProtocol value to usmNoAuthProtocol.
"
DEFVAL { usmNoAuthProtocol }
::= { usmUserEntry 5 }
usmUserAuthKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5 -- typically (SIZE (0 | 40)) for HMACSHA 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.
usmUserAuthKeyChange对象类型语法KeyChange——通常用于HMACMD5（大小（0 | 32））——通常用于HMACSHA MAX-ACCESS读取创建状态当前描述（大小（0 | 40））“一个对象，当被修改时，会通过单向函数修改用于代表该用户向usmUserEngineID标识的SNMP引擎发送/从该引擎发送消息的机密身份验证密钥。”。
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.
相关协议是USMUSERAUTH协议。关联的密钥是用户的秘密身份验证密钥（authKey）。关联的哈希算法是用户的USMUSERAUTH协议使用的算法。
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 instance of usmUserCloneFrom.
创建新用户时，set操作引用此对象是一个“不一致名称”错误，除非它以前或同时通过usmUserCloneFrom的相应实例上的set操作初始化。
When the value of the corresponding usmUserAuthProtocol is usmNoAuthProtocol, then a set is successful, but effectively is a no-op.
当相应的usmUserAuthProtocol的值为usmNoAuthProtocol时，集合成功，但实际上是一个no-op。
When this object is read, the zero-length (empty) string is returned.
读取此对象时，返回零长度（空）字符串。
The recommended way to do a key change is as follows:
执行密钥更改的建议方法如下所示：
1) GET(usmUserSpinLock.0) and save in sValue. 2) generate the keyChange value based on the old (existing) secret key and the new secret key, let us call this kcValue.
1) 获取（usmUserSpinLock.0）并保存在sValue中。2） 基于旧（现有）密钥和新密钥生成keyChange值，我们称之为kcValue。
If you do the key change on behalf of another user:
如果您代表其他用户更改密钥：
3) SET(usmUserSpinLock.0=sValue, usmUserAuthKeyChange=kcValue usmUserPublic=randomValue)
3) 设置（usmUserSpinLock.0=sValue，usmUserAuthKeyChange=kcValue usmUserPublic=randomValue）
If you do the key change for yourself:
如果您自己更改密钥：
4) SET(usmUserSpinLock.0=sValue, usmUserOwnAuthKeyChange=kcValue usmUserPublic=randomValue)
4) 设置（usmUserSpinLock.0=sValue，usmuserownautheychange=kcValue usmUserPublic=randomValue）
If you get a response with error-status of noError,
then the SET succeeded and the new key is active.
If you do not get a response, then you can issue a
GET(usmUserPublic) and check if the value is equal
to the randomValue you did send in the SET. If so, then
the key change succeeded and the new key is active
(probably the response got lost). If not, then the SET
request probably never reached the target and so you
can start over with the procedure above.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 6 }
If you get a response with error-status of noError,
then the SET succeeded and the new key is active.
If you do not get a response, then you can issue a
GET(usmUserPublic) and check if the value is equal
to the randomValue you did send in the SET. If so, then
the key change succeeded and the new key is active
(probably the response got lost). If not, then the SET
request probably never reached the target and so you
can start over with the procedure above.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 6 }
usmUserOwnAuthKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5 -- typically (SIZE (0 | 40)) for HMACSHA 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. In addition, the USM security model must be used for this operation.
USMUSEROWNAUTKEYCHANGE对象类型语法KeyChange——通常用于HMACMD5（大小（0 | 32））——通常用于HMACSHA MAX-ACCESS读取创建状态当前描述（大小（0 | 40））“行为与usmUserAuthKeyChange完全相同，但有一个显著区别：为了使set操作成功，操作请求者的usmUserName必须与索引此操作目标行的usmUserName匹配。此外，此操作必须使用USM安全模型。
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). Note that this can only be done once the row is active.
这里的想法是，对该列的访问可以是公开的，因为它只允许用户更改自己的秘密身份验证密钥（authKey）。请注意，这只能在行处于活动状态时执行。
When a set is received and the usmUserName of the requester is not the same as the umsUserName that indexes the row which is targeted by this operation, then a 'noAccess' error must be returned.
当接收到一个集合且请求者的usmUserName与索引此操作所针对行的umsUserName不同时，则必须返回“noAccess”错误。
When a set is received and the security model in use
is not USM, then a 'noAccess' error must be returned.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 7 }
When a set is received and the security model in use
is not USM, then a 'noAccess' error must be returned.
"
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.
usmUserPrivProtocol对象类型语法AutonomousType MAX-ACCESS读取创建状态当前描述”指示是否可以保护代表此用户向usmUserEngineID标识的SNMP引擎发送或从该引擎发送的消息不被泄露，如果可以，则指示使用的隐私协议类型。
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).
该对象的实例与为同一用户创建任何其他对象实例同时创建（即，作为在同一概念行中创建第一个对象实例的set操作处理的一部分）。
If an initial set operation (i.e. at row creation time) tries to set a value for an unknown or unsupported protocol, then a 'wrongValue' error must be returned.
如果初始设置操作（即在行创建时）尝试为未知或不受支持的协议设置值，则必须返回“错误值”错误。
The value will be overwritten/set when a set operation is performed on the corresponding instance of usmUserCloneFrom.
当对USMUSERCLONEFORM的相应实例执行set操作时，该值将被覆盖/设置。
Once instantiated, the value of such an instance of this object can only be changed via a set operation to the value of the usmNoPrivProtocol.
一旦实例化，该对象的实例的值只能通过set操作更改为usmNoPrivProtocol的值。
If a set operation tries to change the value of an existing instance of this object to any value other than usmNoPrivProtocol, then an 'inconsistentValue' error must be returned.
如果集合操作试图将此对象的现有实例的值更改为usmNoPrivProtocol以外的任何值，则必须返回“不一致值”错误。
Note that if any privacy protocol is used, then you must also use an authentication protocol. In other words, if usmUserPrivProtocol is set to anything else than usmNoPrivProtocol, then the corresponding instance of usmUserAuthProtocol cannot have a value of
请注意，如果使用任何隐私协议，则还必须使用身份验证协议。换句话说，如果将usmUserPrivProtocol设置为usmNoPrivProtocol以外的任何其他值，则usmUserAuthProtocol的相应实例的值不能为
usmNoAuthProtocol. If it does, then an
'inconsistentValue' error must be returned.
"
DEFVAL { usmNoPrivProtocol }
::= { usmUserEntry 8 }
usmNoAuthProtocol. If it does, then an
'inconsistentValue' error must be returned.
"
DEFVAL { usmNoPrivProtocol }
::= { usmUserEntry 8 }
usmUserPrivKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES 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.
usmUserPrivKeyChange对象类型语法KeyChange——DES MAX-ACCESS read create STATUS current DESCRIPTION的典型值（大小（0 | 32））“一个对象，当被修改时，会导致用于代表该用户向usmUserEngineID标识的SNMP引擎发送的消息的秘密加密密钥通过单向函数进行修改。
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.
相关协议是usmUserPrivProtocol。关联的密钥是用户的秘密隐私密钥（privKey）。关联的哈希算法是用户的USMUSERAUTH协议使用的算法。
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 instance of usmUserCloneFrom.
创建新用户时，set操作引用此对象是一个“不一致名称”错误，除非它以前或同时通过usmUserCloneFrom的相应实例上的set操作初始化。
When the value of the corresponding usmUserPrivProtocol is usmNoPrivProtocol, then a set is successful, but effectively is a no-op.
当相应的usmUserPrivProtocol的值为usmNoPrivProtocol时，集合成功，但实际上是一个no-op。
When this object is read, the zero-length (empty)
string is returned.
See the description clause of usmUserAuthKeyChange for
a recommended procedure to do a key change.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 9 }
When this object is read, the zero-length (empty)
string is returned.
See the description clause of usmUserAuthKeyChange for
a recommended procedure to do a key change.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 9 }
usmUserOwnPrivKeyChange OBJECT-TYPE SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES 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
USMUSERROWNPRIVKEYCHANGE对象类型语法KeyChange——DES MAX-ACCESS read create STATUS current DESCREATE“的通常（大小（0 | 32））与usmUserPrivKeyChange的行为完全相同，但有一个显著区别：为了使Set操作成功，操作请求者的usmUserName必须与索引的usmUserName匹配
the row which is targeted by this operation. In addition, the USM security model must be used for this operation.
此操作的目标行。此外，此操作必须使用USM安全模型。
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). Note that this can only be done once the row is active.
这里的想法是，对该专栏的访问可以是公开的，因为它只允许用户更改自己的秘密隐私密钥（privKey）。请注意，这只能在行处于活动状态时执行。
When a set is received and the usmUserName of the requester is not the same as the umsUserName that indexes the row which is targeted by this operation, then a 'noAccess' error must be returned.
当接收到一个集合且请求者的usmUserName与索引此操作所针对行的umsUserName不同时，则必须返回“noAccess”错误。
When a set is received and the security model in use
is not USM, then a 'noAccess' error must be returned.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 10 }
When a set is received and the security model in use
is not USM, then a 'noAccess' error must be returned.
"
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 can be 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 }
usmUserPublic OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A publicly-readable value which can be 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.
usmUserStorageType对象类型语法StorageType MAX-ACCESS read create STATUS current DESCRIPTION“此概念行的存储类型。
Conceptual rows having the value 'permanent' must allow write-access at a minimum to:
值为“permanent”的概念行必须至少允许对以下内容进行写访问：
- usmUserAuthKeyChange, usmUserOwnAuthKeyChange and usmUserPublic for a user who employs authentication, and - usmUserPrivKeyChange, usmUserOwnPrivKeyChange and usmUserPublic for a user who employs privacy.
- 对于使用身份验证的用户，请使用usmUserAuthKeyChange、USMUSEROWNAUTKEYCHANGE和usmUserPublic；对于使用隐私的用户，请使用-usmUserPrivKeyChange、usmUserOwnPrivKeyChange和usmUserPublic。
Note that any user who employs authentication or privacy must allow its secret(s) to be updated and thus cannot be 'readOnly'.
请注意，任何使用身份验证或隐私的用户都必须允许更新其机密，因此不能为“只读”。
If an initial set operation tries to set the value to 'readOnly' for a user who employs authentication or privacy, then an 'inconsistentValue' error must be returned. Note that if the value has been previously set (implicit or explicit) to any value, then the rules as defined in the StorageType Textual Convention apply.
如果初始设置操作试图为采用身份验证或隐私的用户将值设置为“只读”，则必须返回“不一致值”错误。请注意，如果之前已将该值（隐式或显式）设置为任何值，则将应用StorageType文本约定中定义的规则。
It is an implementation issue to decide if a SET for
a readOnly or permanent row is accepted at all. In some
contexts this may make sense, in others it may not. If
a SET for a readOnly or permanent row is not accepted
at all, then a 'wrongValue' error must be returned.
"
DEFVAL { nonVolatile }
::= { usmUserEntry 12 }
It is an implementation issue to decide if a SET for
a readOnly or permanent row is accepted at all. In some
contexts this may make sense, in others it may not. If
a SET for a readOnly or permanent row is not accepted
at all, then a 'wrongValue' error must be returned.
"
DEFVAL { nonVolatile }
::= { usmUserEntry 12 }
usmUserStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row.
usmUserStatus对象类型语法RowStatus MAX-ACCESS read create STATUS current DESCRIPTION“此概念行的状态。
Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the usmUserStatus column is 'notReady'.
在正确配置所有相应列的实例之前，usmUserStatus列的相应实例的值为“notReady”。
In particular, a newly created row for a user who employs authentication, cannot be made active until the corresponding usmUserCloneFrom and usmUserAuthKeyChange have been set.
特别是，在设置相应的usmUserCloneFrom和usmUserAuthKeyChange之前，无法激活为使用身份验证的用户新建的行。
Further, a newly created row for a user who also employs privacy, cannot be made active until the usmUserPrivKeyChange has been set.
此外，在设置usmUserPrivKeyChange之前，不能激活为同时使用隐私的用户新建的行。
The RowStatus TC [RFC2579] requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified:
RowStatus TC[RFC2579]要求此描述条款说明在何种情况下可以修改此行中的其他对象：
The value of this object has no effect on whether other objects in this conceptual row can be modified, except for usmUserOwnAuthKeyChange and usmUserOwnPrivKeyChange. For these 2 objects, the
此对象的值对是否可以修改此概念行中的其他对象没有影响，但USMuseRowNautheyChange和usmUserOwnPrivKeyChange除外。对于这两个对象
value of usmUserStatus MUST be active.
"
::= { usmUserEntry 13 }
value of usmUserStatus MUST be active.
"
::= { usmUserEntry 13 }
-- Conformance Information *******************************************
-- Conformance Information *******************************************
usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
usmMIBGroups OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
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. "
usmMIBCompliance MODULE-COMPLIANCE STATUS当前描述“实现SNMP-USER-BASED-SM-MIB的SNMP引擎的符合性声明。”
MODULE -- this module MANDATORY-GROUPS { usmMIBBasicGroup }
MODULE——此模块为强制组{usmMIBBasicGroup}
OBJECT usmUserAuthProtocol MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象usmUserAuthProtocol MIN-ACCESS只读描述“不需要写访问。”
OBJECT usmUserPrivProtocol MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象usmUserPrivProtocol MIN-ACCESS只读描述“不需要写访问。”
::= { usmMIBCompliances 1 }
::= { usmMIBCompliances 1 }
-- Units of compliance usmMIBBasicGroup OBJECT-GROUP OBJECTS { usmStatsUnsupportedSecLevels, usmStatsNotInTimeWindows, usmStatsUnknownUserNames, usmStatsUnknownEngineIDs, usmStatsWrongDigests, usmStatsDecryptionErrors, usmUserSpinLock, usmUserSecurityName, usmUserCloneFrom, usmUserAuthProtocol, usmUserAuthKeyChange, usmUserOwnAuthKeyChange, usmUserPrivProtocol, usmUserPrivKeyChange, usmUserOwnPrivKeyChange,
--符合性单位usmMIBBasicGroup对象组对象{USMStatsSupportedSevels、USMStatsNotTimeWindows、usmStatsUnknownUserNames、USMStatsUnknowneEngineids、USMStatsFrong摘要、usmStatsDecryptionErrors、usmUserSpinLock、USMusersSecurityName、usmUserCloneFrom、usmUserAuthProtocol、USMuserauthUnothKeyChange、USMuserauthPrivProtocol、USMuseraurPrivKeyChange、USMuseraurrowPrivKeyChange、，
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 }
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
终止
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 [RFC1321], in HMAC mode described in [RFC2104], truncating the output to 96 bits.
本节介绍HMAC-MD5-96身份验证协议。此身份验证协议是第一个为基于用户的安全模型定义的协议。它使用[RFC1321]中描述的MD5哈希函数，在[RFC2104]中描述的HMAC模式下，将输出截断为96位。
This protocol is identified by usmHMACMD5AuthProtocol.
该协议由usmHMACMD5AuthProtocol标识。
Over time, other authentication protocols may be defined either as a replacement of this protocol or in addition to this protocol.
随着时间的推移，可以将其他认证协议定义为该协议的替代协议或该协议的补充协议。
- 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.
- 为了支持数据完整性，需要一个消息摘要算法。摘要通过SNMP消息的适当部分进行计算，并作为发送给收件人的消息的一部分包括在内。
- 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.
- 为了支持数据源身份验证和数据完整性，在计算摘要之前，在SNMP消息中预先添加一个秘密值；在传输之前，计算的摘要部分插入SNMP消息中，并且不传输预先指定的值。机密值由所有授权代表适当用户发起消息的SNMP引擎共享。
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.
只有授权代表用户生成消息的SNMP引擎才知道的秘密值在HMAC模式下使用（请参见[RFC2104]）。它还建议截断用作消息身份验证代码的哈希函数输出。
This protocol uses the MD5 [RFC1321] 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.
此协议使用MD5[RFC1321]消息摘要算法。在SNMP消息的指定部分上以特殊（HMAC）方式计算128位MD5摘要，此摘要的前96位作为发送给收件人的消息的一部分。消息中包含的摘要大小为12个八位字节。私有身份验证密钥（秘密）的大小为16个八位字节。有关详细信息，请参见第6.3节。
This section contains definitions required to realize the authentication module defined in this section of this memo.
本节包含实现本备忘录本节中定义的身份验证模块所需的定义。
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.
使用此身份验证协议的身份验证使用一组已定义的用户名。对于任何必须在特定SNMP引擎上对消息进行身份验证的用户，该SNMP引擎必须了解该用户。希望与另一个SNMP引擎通信的SNMP引擎还必须了解该引擎已知的用户，包括该用户的适用属性。
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.
<userName>表示用户名称的字符串<authKey>计算摘要时要使用的用户密钥。MD5的长度必须为16个八位字节。
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 [RFC3411]).
经过身份验证的消息中包含的msgauthoritiveengineid值指定该特定消息的权威SNMP引擎（请参阅SNMP体系结构文档[RFC3411]中SnmpEngineID的定义）。
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.
每个权威SNMP引擎的用户（私有）身份验证密钥通常不同，因此snmpEngineID用于为身份验证过程选择适当的密钥。
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.
使用此身份验证协议的消息将MSG身份验证参数字段作为MSG安全参数的一部分。对于该协议，msgAuthenticationParameters字段是表示HMAC-MD5-96输出的前12个八位字节的序列化八位字节字符串，该八位字节字符串在整个MSG上完成。
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.
摘要是在整个SG上计算的，因此如果消息经过身份验证，这也意味着消息中的所有字段都是完整的，没有被篡改。
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.
本节描述了当基于用户的安全模块调用HMAC-MD5-96身份验证模块进行服务时，HMAC-MD5-96身份验证模块期望和产生的输入和输出。
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.
HMAC-MD5-96身份验证协议假定authKey的选择由调用方完成，并且调用方传递要使用的密钥。
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
)
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.
statusInformation指示身份验证过程是否成功。如果不是，则表明存在问题。
authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 16 octets.
authKey身份验证算法要使用的密钥。此密钥的长度必须为16个八位字节。
wholeMsg The message to be authenticated.
wholeMsg要验证的消息。
authenticatedWholeMsg The authenticated message (including inserted digest) on output.
authenticatedWholeMsg在输出上显示经过身份验证的消息（包括插入的摘要）。
Note, that authParameters field is filled by the authentication module and this module and this field should be already present in the wholeMsg before the Message Authentication Code (MAC) is generated.
请注意，authParameters字段由身份验证模块填写，在生成消息身份验证代码（MAC）之前，此模块和此字段应已存在于wholeMsg中。
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.
HMAC-MD5-96身份验证协议假定authKey的选择由调用方完成，并且调用方传递要使用的密钥。
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
)
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.
statusInformation指示身份验证过程是否成功。如果不是，则表明存在问题。
authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 16 octets.
authKey身份验证算法要使用的密钥。此密钥的长度必须为16个八位字节。
authParameters The authParameters from the incoming message.
authParameters传入消息中的authParameters。
wholeMsg The message to be authenticated on input and the authenticated message on output.
wholeMsg输入时要验证的消息，输出时要验证的消息。
authenticatedWholeMsg The whole message after the authentication check is complete.
authenticatedWholeMsg在身份验证检查完成后显示整个消息。
This section describes the procedures for the HMAC-MD5-96 authentication protocol.
本节介绍HMAC-MD5-96认证协议的程序。
This section describes the procedure followed by an SNMP engine whenever it must authenticate an outgoing message using the usmHMACMD5AuthProtocol.
本节介绍SNMP引擎在必须使用usmHMACMD5AuthProtocol对传出消息进行身份验证时所遵循的过程。
1) The msgAuthenticationParameters field is set to the serialization, according to the rules in [RFC3417], of an OCTET STRING containing 12 zero octets.
1) 根据[RFC3417]中的规则，msgAuthenticationParameters字段设置为包含12个零八位字节的八位字节字符串的序列化。
2) From the secret authKey, two keys K1 and K2 are derived:
2) 根据机密身份验证密钥，派生出两个密钥K1和K2：
a) extend the authKey to 64 octets by appending 48 zero octets; save it as extendedAuthKey
a) 通过添加48个零八位字节，将authKey扩展到64个八位字节；将其另存为extendedAuthKey
b) obtain IPAD by replicating the octet 0x36 64 times;
b) 通过复制八位字节0x36 64次获得IPAD；
c) obtain K1 by XORing extendedAuthKey with IPAD;
c) 使用IPAD XORing extendedAuthKey获取K1；
d) obtain OPAD by replicating the octet 0x5C 64 times;
d) 通过将八位字节0x5C复制64次获得OPAD；
e) obtain K2 by XORing extendedAuthKey with OPAD.
e) 通过将extendedAuthKey与OPAD异或获得K2。
3) Prepend K1 to the wholeMsg and calculate MD5 digest over it according to [RFC1321].
3) 将K1预先添加到整个SG中，并根据[RFC1321]计算MD5摘要。
4) Prepend K2 to the result of the step 4 and calculate MD5 digest over it according to [RFC1321]. Take the first 12 octets of the final digest - this is Message Authentication Code (MAC).
4) 在步骤4的结果前加上K2，并根据[RFC1321]计算MD5摘要。以最终摘要的前12个八位字节为例——这是消息身份验证码（MAC）。
5) Replace the msgAuthenticationParameters field with MAC obtained in the step 4.
5) 用步骤4中获得的MAC替换msgAuthenticationParameters字段。
6) The authenticatedWholeMsg is then returned to the caller together with statusInformation indicating success.
6) 然后，authenticatedWholeMsg与指示成功的状态信息一起返回给调用方。
This section describes the procedure followed by an SNMP engine whenever it must authenticate an incoming message using the usmHMACMD5AuthProtocol.
本节介绍SNMP引擎在必须使用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.
1) 如果msgAuthenticationParameters字段中接收到的摘要长度不是12个八位字节，则会向调用模块返回故障和错误指示（authenticationError）。
2) The MAC received in the msgAuthenticationParameters field is saved.
2) 将保存在msgAuthenticationParameters字段中接收的MAC。
3) The digest in the msgAuthenticationParameters field is replaced by the 12 zero octets.
3) msgAuthenticationParameters字段中的摘要将替换为12个零八位字节。
4) From the secret authKey, two keys K1 and K2 are derived:
4) 根据机密身份验证密钥，派生出两个密钥K1和K2：
a) extend the authKey to 64 octets by appending 48 zero octets; save it as extendedAuthKey
a) 通过添加48个零八位字节，将authKey扩展到64个八位字节；将其另存为extendedAuthKey
b) obtain IPAD by replicating the octet 0x36 64 times;
b) 通过复制八位字节0x36 64次获得IPAD；
c) obtain K1 by XORing extendedAuthKey with IPAD;
c) 使用IPAD XORing extendedAuthKey获取K1；
d) obtain OPAD by replicating the octet 0x5C 64 times;
d) 通过将八位字节0x5C复制64次获得OPAD；
e) obtain K2 by XORing extendedAuthKey with OPAD.
e) 通过将extendedAuthKey与OPAD异或获得K2。
5) The MAC is calculated over the wholeMsg:
5) MAC在整个SG上计算：
a) prepend K1 to the wholeMsg and calculate the MD5 digest over it;
a) 将K1预先添加到整个SG中，并计算其上的MD5消化；
b) prepend K2 to the result of step 5.a and calculate the MD5 digest over it;
b) 将K2添加到步骤5.a的结果之前，并在其上计算MD5消化物；
c) first 12 octets of the result of step 5.b is the MAC.
c) 步骤5.b结果的前12个八位字节是MAC。
The msgAuthenticationParameters field is replaced with the MAC value that was saved in step 2.
msgAuthenticationParameters字段将替换为步骤2中保存的MAC值。
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.
6) 然后将新计算的MAC与步骤2中保存的MAC进行比较。如果它们不匹配，则会向调用模块返回故障和错误指示（authenticationFailure）。
7) The authenticatedWholeMsg and statusInformation indicating success are then returned to the caller.
7) 然后将authenticatedWholeMsg和指示成功的状态信息返回给调用方。
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.
本节介绍HMAC-SHA-96认证协议。该协议使用[SHA-NIST]中描述的SHA哈希函数，在[RFC2104]中描述的HMAC模式下，将输出截断为96位。
This protocol is identified by usmHMACSHAAuthProtocol.
该协议由usmHMACSHAAuthProtocol标识。
Over time, other authentication protocols may be defined either as a replacement of this protocol or in addition to this protocol.
随着时间的推移，可以将其他认证协议定义为该协议的替代协议或该协议的补充协议。
- 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.
- 为了支持数据完整性，需要一个消息摘要算法。摘要通过SNMP消息的适当部分进行计算，并作为发送给收件人的消息的一部分包括在内。
- 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.
- 为了支持数据源身份验证和数据完整性，在计算摘要之前，在SNMP消息中预先加入一个秘密值；然后，在传输之前，将计算出的摘要部分插入到消息中。事先准备好的秘密不会被传播。机密值由所有授权代表适当用户发起消息的SNMP引擎共享。
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.
只有授权代表用户生成消息的SNMP引擎才知道的秘密值在HMAC模式下使用（请参见[RFC2104]）。它还建议截断用作消息身份验证代码的哈希函数输出。
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.
该机制使用SHA[SHA-NIST]消息摘要算法。通过SNMP消息的指定部分，以特殊（HMAC）方式计算160位SHA摘要，该摘要的前96位作为发送给收件人的消息的一部分。消息中包含的摘要大小为12个八位字节。私人身份验证密钥（秘密）的大小为20个八位字节。有关详细信息，请参见第7.3节。
This section contains definitions required to realize the authentication module defined in this section of this memo.
本节包含实现本备忘录本节中定义的身份验证模块所需的定义。
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.
使用此身份验证协议的身份验证使用一组已定义的用户名。对于任何必须在特定SNMP引擎上对消息进行身份验证的用户，该SNMP引擎必须了解该用户。希望与另一个SNMP引擎通信的SNMP引擎还必须了解该引擎已知的用户，包括该用户的适用属性。
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.
<userName>表示用户名称的字符串<authKey>计算摘要时要使用的用户密钥。SHA的长度必须是20个八位组。
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 [RFC3411]).
经过身份验证的消息中包含的msgauthoritiveengineid值指定该特定消息的权威SNMP引擎（请参阅SNMP体系结构文档[RFC3411]中SnmpEngineID的定义）。
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.
每个权威SNMP引擎的用户（私有）身份验证密钥通常不同，因此snmpEngineID用于为身份验证过程选择适当的密钥。
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.
使用此身份验证协议的消息将MSG身份验证参数字段作为MSG安全参数的一部分。对于该协议，msgAuthenticationParameters字段是表示HMAC-SHA-96输出在整个MSG上的前12个八位字节的序列化八位字节字符串。
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.
摘要是在整个SG上计算的，因此如果消息经过身份验证，这也意味着消息中的所有字段都是完整的，没有被篡改。
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.
本节描述了当基于用户的安全模块调用HMAC-SHA-96身份验证模块进行服务时，HMAC-SHA-96身份验证模块期望和产生的输入和输出。
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.
HMAC-SHA-96身份验证协议假定authKey的选择由调用方完成，并且调用方传递要使用的密钥。
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
)
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.
statusInformation指示身份验证过程是否成功。如果不是，则表明存在问题。
authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 20 octets.
authKey身份验证算法要使用的密钥。此密钥的长度必须为20个八位字节。
wholeMsg The message to be authenticated.
wholeMsg要验证的消息。
authenticatedWholeMsg The authenticated message (including inserted digest) on output.
authenticatedWholeMsg在输出上显示经过身份验证的消息（包括插入的摘要）。
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.
请注意，authParameters字段由身份验证模块填充，在生成消息身份验证码（MAC）之前，该字段应该已经存在于wholeMsg中。
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.
HMAC-SHA-96身份验证协议假定authKey的选择由调用方完成，并且调用方传递要使用的密钥。
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
)
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.
statusInformation指示身份验证过程是否成功。如果不是，则表明存在问题。
authKey The secret key to be used by the authentication algorithm. The length of this key MUST be 20 octets.
authKey身份验证算法要使用的密钥。此密钥的长度必须为20个八位字节。
authParameters The authParameters from the incoming message.
authParameters传入消息中的authParameters。
wholeMsg The message to be authenticated on input and the authenticated message on output.
wholeMsg输入时要验证的消息，输出时要验证的消息。
authenticatedWholeMsg The whole message after the authentication check is complete.
authenticatedWholeMsg在身份验证检查完成后显示整个消息。
This section describes the procedures for the HMAC-SHA-96 authentication protocol.
本节介绍HMAC-SHA-96认证协议的程序。
This section describes the procedure followed by an SNMP engine whenever it must authenticate an outgoing message using the usmHMACSHAAuthProtocol.
本节介绍SNMP引擎必须使用USMHMACSHAAUTH协议对传出消息进行身份验证时所遵循的过程。
1) The msgAuthenticationParameters field is set to the serialization, according to the rules in [RFC3417], of an OCTET STRING containing 12 zero octets.
1) 根据[RFC3417]中的规则，msgAuthenticationParameters字段设置为包含12个零八位字节的八位字节字符串的序列化。
2) From the secret authKey, two keys K1 and K2 are derived:
2) 根据机密身份验证密钥，派生出两个密钥K1和K2：
a) extend the authKey to 64 octets by appending 44 zero octets; save it as extendedAuthKey
a) 通过添加44个零八位字节，将authKey扩展到64个八位字节；将其另存为extendedAuthKey
b) obtain IPAD by replicating the octet 0x36 64 times;
b) 通过复制八位字节0x36 64次获得IPAD；
c) obtain K1 by XORing extendedAuthKey with IPAD;
c) 使用IPAD XORing extendedAuthKey获取K1；
d) obtain OPAD by replicating the octet 0x5C 64 times;
d) 通过将八位字节0x5C复制64次获得OPAD；
e) obtain K2 by XORing extendedAuthKey with OPAD.
e) 通过将extendedAuthKey与OPAD异或获得K2。
3) Prepend K1 to the wholeMsg and calculate the SHA digest over it according to [SHA-NIST].
3) 将K1预先添加到整个SG中，并根据[SHA-NIST]计算其上的SHA摘要。
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).
4) 在步骤4的结果前加K2，并根据[SHA-NIST]计算其SHA消化。以最终摘要的前12个八位字节为例——这是消息身份验证码（MAC）。
5) Replace the msgAuthenticationParameters field with MAC obtained in the step 5.
5) 用步骤5中获得的MAC替换msgAuthenticationParameters字段。
6) The authenticatedWholeMsg is then returned to the caller together with statusInformation indicating success.
6) 然后，authenticatedWholeMsg与指示成功的状态信息一起返回给调用方。
This section describes the procedure followed by an SNMP engine whenever it must authenticate an incoming message using the usmHMACSHAAuthProtocol.
本节介绍SNMP引擎在必须使用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.
1) 如果msgAuthenticationParameters字段中接收到的摘要长度不是12个八位字节，则会向调用模块返回故障和错误指示（authenticationError）。
2) The MAC received in the msgAuthenticationParameters field is saved.
2) 将保存在msgAuthenticationParameters字段中接收的MAC。
3) The digest in the msgAuthenticationParameters field is replaced by the 12 zero octets.
3) msgAuthenticationParameters字段中的摘要将替换为12个零八位字节。
4) From the secret authKey, two keys K1 and K2 are derived:
4) 根据机密身份验证密钥，派生出两个密钥K1和K2：
a) extend the authKey to 64 octets by appending 44 zero octets; save it as extendedAuthKey
a) 通过添加44个零八位字节，将authKey扩展到64个八位字节；将其另存为extendedAuthKey
b) obtain IPAD by replicating the octet 0x36 64 times;
b) 通过复制八位字节0x36 64次获得IPAD；
c) obtain K1 by XORing extendedAuthKey with IPAD;
c) 使用IPAD XORing extendedAuthKey获取K1；
d) obtain OPAD by replicating the octet 0x5C 64 times;
d) 通过将八位字节0x5C复制64次获得OPAD；
e) obtain K2 by XORing extendedAuthKey with OPAD.
e) 通过将extendedAuthKey与OPAD异或获得K2。
5) The MAC is calculated over the wholeMsg:
5) MAC在整个SG上计算：
a) prepend K1 to the wholeMsg and calculate the SHA digest over it;
a) 将K1预先添加到整个SG中，并计算其上的SHA摘要；
b) prepend K2 to the result of step 5.a and calculate the SHA digest over it;
b) 将K2添加到步骤5.a的结果之前，并计算其上的SHA摘要；
c) first 12 octets of the result of step 5.b is the MAC.
c) 步骤5.b结果的前12个八位字节是MAC。
The msgAuthenticationParameters field is replaced with the MAC value that was saved in step 2.
msgAuthenticationParameters字段将替换为步骤2中保存的MAC值。
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.
6) 将新计算的MAC与步骤2中保存的MAC进行比较。如果它们不匹配，则会向调用模块返回失败和错误指示（authenticationFailure）。
7) The authenticatedWholeMsg and statusInformation indicating success are then returned to the caller.
7) 然后将authenticatedWholeMsg和指示成功的状态信息返回给调用方。
This section describes the CBC-DES Symmetric Encryption Protocol. This protocol is the first privacy protocol defined for the User-based Security Model.
本节介绍CBC-DES对称加密协议。该协议是为基于用户的安全模型定义的第一个隐私协议。
This protocol is identified by usmDESPrivProtocol.
此协议由usmDESPrivProtocol标识。
Over time, other privacy protocols may be defined either as a replacement of this protocol or in addition to this protocol.
随着时间的推移，其他隐私协议可能被定义为本协议的替代协议或本协议的补充协议。
- 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.
- 为了支持数据保密性，需要一种加密算法。消息的适当部分在传输之前被加密。基于用户的安全模型指定scopedPDU是消息中需要加密的部分。
- 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.
- 结合时间值的秘密值用于创建en/解密密钥和初始化向量。机密值由所有授权代表适当用户发起消息的SNMP引擎共享。
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.
本备忘录中定义的对称加密协议为数据保密提供了支持。SNMP消息的指定部分经过加密，并作为发送给收件人的消息的一部分包含在内。
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).
两个组织发布了定义DES的规范：国家标准与技术研究所（NIST）[DES-NIST]和美国国家标准研究所[DES-ANSI]。每个定义都有相应的操作模式规范（[DESO-NIST]和[DESO-ANSI]）。
The NIST has published three additional documents that implementors may find useful.
NIST还发布了三份实施者可能认为有用的文件。
- 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].
- 有一份文件包含实施和使用DES的指南，包括DES及其运行模式的功能规范[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.
- DES[DEST-NIST]有一个验证测试套件规范。该套件旨在测试DES的所有方面，并有助于查明具体问题。
- 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.
- DES[DESM-NIST]有维护测试规范。该测试使用最少的数据量和处理来测试DES的所有组件。它提供了正确操作的简单是或否指示，可作为初始化步骤的一部分运行，例如，当计算机重新引导时。
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.
16个八位组密钥（私钥）的前8个八位组用作DES密钥。由于DES仅使用56位，因此忽略每个八位字节中的最低有效位。
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.
16个八位密码（私钥）中的最后8个八位密码用作pre-IV。
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.
为了确保由相同密钥加密的两个不同数据包的IV不相同（即，IV不重复），我们需要使用每个数据包的唯一性来“盐”预IV。使用8个八位字节的字符串作为“salt”。生成SNMP引擎的32位snmpEngineBoots和加密引擎维护的本地32位整数的串联输入到“salt”。32位整数在启动时初始化为任意值。
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 to obtain the 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.
32位snmpEngineBoots被转换为“salt”的前4个八位字节（最高有效字节优先）。然后将32位整数转换为“salt”的最后4个八位字节（首先是最高有效字节）。然后将得到的“salt”与pre IV进行异或运算以获得IV。然后将8个八位组的“salt”放入编码为八位组字符串的privParameters字段中。然后修改“salt”整数。我们建议将其递增1，并在达到最大值时进行换行。
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.
只要采取措施避免产生重复的IV，“盐”（以及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.
“salt”必须放在privParameters字段中，以使接收实体能够计算正确的IV并解密消息。
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.
要加密的数据被视为八位字节序列。它的长度应该是8的整数倍，如果不是，则根据需要在末尾填充数据。实际的焊盘值是不相关的。
The data is encrypted in Cipher Block Chaining mode.
数据以密码块链接模式加密。
The plaintext is divided into 64-bit blocks.
明文被分成64位块。
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.
对于第一个块，使用初始化向量代替前一个块的密文。
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.
在解密之前，验证加密的数据长度。如果要解密的八位字节字符串的长度不是8个八位字节的整数倍，则解密过程将停止，并记录相应的异常。解密时，将忽略填充。
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.
对于每个后续块，将解密密文块，解密输出与前一个密文块异或，结果为明文块。
This section contains definitions required to realize the privacy module defined by this memo.
本节包含实现本备忘录定义的隐私模块所需的定义。
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
使用此对称加密协议的数据加密/解密使用一组已定义的用户名。对于任何必须在特定SNMP引擎上对其代表的消息进行加密/解密的用户，该SNMP引擎必须了解该用户。一个SNMP引擎
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.
要与另一个SNMP引擎通信，还必须了解该SNMP引擎已知的用户，包括该用户的适用属性。
A user and its attributes are defined as follows:
用户及其属性定义如下：
<userName> An octet string representing the name of the user.
<userName>表示用户名称的八位字节字符串。
<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.
<privKey>用户的密钥，用作DES密钥和IV的输入。该密钥的长度必须为16个八位字节。
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 [RFC3411]).
经过身份验证的消息中包含的msgauthoritiveengineid值指定该特定消息的权威SNMP引擎（请参阅SNMP体系结构文档[RFC3411]中SnmpEngineID的定义）。
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.
每个权威SNMP引擎的用户（私有）隐私密钥通常不同，因此snmpEngineID用于为加密/解密过程选择适当的密钥。
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.
使用此隐私协议的消息包含一个MSGPrivacParameters字段，作为msgSecurityParameters的一部分。对于该协议，msgprivacParameters字段是表示用于创建IV的“salt”的序列化八位字节字符串。
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.
本节描述了基于用户的安全模块调用DES隐私模块提供服务时DES隐私模块期望和产生的输入和输出。
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.
此DES隐私协议假定私钥的选择由调用方完成，并且调用方传递要使用的私钥。
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:
完成后，隐私模块返回状态信息，如果加密过程成功，则加密PDU和msgPrivacyParameters将编码为八位字节字符串。抽象服务原语是：
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
)
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.
encryptKey加密算法要使用的密钥。此密钥的长度必须为16个八位字节。
dataToEncrypt The data that must be encrypted.
dataToEncrypt必须加密的数据。
encryptedData The encrypted data upon successful completion.
encryptedData在成功完成后对加密数据进行加密。
privParameters The privParameters encoded as an OCTET STRING.
privParameters编码为八位字节字符串的privParameters。
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.
此DES隐私协议假定私钥的选择由调用方完成，并且调用方传递要使用的私钥。
Upon completion the privacy module returns statusInformation and, if the decryption process was successful, the scopedPDU in plain text. The abstract service primitive is:
完成后，隐私模块返回状态信息，如果解密过程成功，则返回纯文本形式的scopedPDU。抽象服务原语是：
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)
)
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.
statusInformation指示数据是否已成功解密，如果未成功，则指示错误。
decryptKey The secret key to be used by the decryption algorithm. The length of this key MUST be 16 octets.
解密密钥解密算法要使用的密钥。此密钥的长度必须为16个八位字节。
privParameters The "salt" to be used to calculate the IV.
用于计算IV的“盐”。
encryptedData The data to be decrypted.
encryptedData要解密的数据。
decryptedData The decrypted data.
decryptedData已解密的数据。
8.3. Elements of Procedure.
8.3. 程序要素。
This section describes the procedures for the DES privacy protocol.
本节介绍DES隐私协议的程序。
This section describes the procedure followed by an SNMP engine whenever it must encrypt part of an outgoing message using the usmDESPrivProtocol.
本节介绍SNMP引擎在必须使用USMDESPRIV协议加密部分传出消息时所遵循的过程。
1) The secret cryptKey is used to construct the DES encryption key, the "salt" and the DES pre-IV (from which the IV is computed as described in section 8.1.1.1).
1) 秘密密钥用于构造DES加密密钥、“salt”和DES pre IV（根据第8.1.1.1节中的描述计算IV）。
2) The privParameters field is set to the serialization according to the rules in [RFC3417] of an OCTET STRING representing the "salt" string.
2) privParameters字段根据[RFC3417]中表示“salt”字符串的八位字节字符串的规则设置为序列化。
3) The scopedPDU is encrypted (as described in section 8.1.1.2) and the encrypted data is serialized according to the rules in [RFC3417] as an OCTET STRING.
3) scopedPDU被加密（如第8.1.1.2节所述），加密数据根据[RFC3417]中的规则被序列化为八位字节字符串。
4) The serialized OCTET STRING representing the encrypted scopedPDU together with the privParameters and statusInformation indicating success is returned to the calling module.
4) 表示加密scopedPDU的序列化八位字节字符串以及指示成功的privParameters和statusInformation返回给调用模块。
This section describes the procedure followed by an SNMP engine whenever it must decrypt part of an incoming message using the usmDESPrivProtocol.
本节介绍SNMP引擎在必须使用USMDESPRIV协议解密部分传入消息时所遵循的过程。
1) If the privParameters field is not an 8-octet OCTET STRING, then an error indication (decryptionError) is returned to the calling module.
1) 如果privParameters字段不是8个八位字节的字符串，则会向调用模块返回错误指示（decryptionError）。
2) The "salt" is extracted from the privParameters field.
2) “salt”是从privParameters字段中提取的。
3) The secret cryptKey and the "salt" are then used to construct the DES decryption key and pre-IV (from which the IV is computed as described in section 8.1.1.1).
3) 然后使用秘密密钥和“salt”构造DES解密密钥和pre IV（根据第8.1.1.1节中的描述计算IV）。
4) The encryptedPDU is then decrypted (as described in section 8.1.1.3).
4) 然后对加密的PDU进行解密（如第8.1.1.3节所述）。
5) If the encryptedPDU cannot be decrypted, then an error indication (decryptionError) is returned to the calling module.
5) 如果无法解密encryptedPDU，则会向调用模块返回错误指示（decryptionError）。
6) The decrypted scopedPDU and statusInformation indicating success are returned to the calling module.
6) 解密后的scopedPDU和指示成功的状态信息返回给调用模块。
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 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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
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:
本文件是SNMPv3工作组努力的结果。特别感谢以下SNMPv3工作组成员：
Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services) Paul Berrevoets (SWI Systemware/Halcyon Inc.) Martin Bjorklund (Ericsson) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) Mike Daniele (Compaq Computer Corporation)) T. Max Devlin (Eltrax Systems) John Flick (Hewlett Packard) Rob Frye (MCI) Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) David Harrington (Cabletron Systems Inc.) Lauren Heintz (BMC Software, Inc.) N.C. Hien (IBM T.J. Watson Research Center) Michael Kirkham (InterWorking Labs, Inc.) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Joe Marzot (Nortel Networks) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Bob Moore (IBM) Russ Mundy (TIS Labs at Network Associates) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reeder (TIS Labs at Network Associates) David Reid (SNMP Research, Inc.) Aleksey Romanov (Quality Quorum) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T.J. Watson Research Center)
Harald Tveit Alvestrand（Maxware）Dave Battle（SNMP Research，Inc.）Alan Beard（迪士尼全球服务）Paul Berrevoets（SWI Systemware/Halcyon Inc.）Martin Bjorklund（爱立信）Uri Blumenthal（IBM T.J.Watson研究中心）Jeff Case（SNMP Research，Inc.）John Curran（BBN）Mike Daniele（康柏电脑公司））T.Max Devlin（Eltrax Systems）John Flick（惠普）Rob Frye（MCI）Wes Hardaker（加州大学戴维斯分校，信息技术研究所）David Harrington（Cabletron Systems Inc.）Lauren Heintz（BMC Software，Inc.）N.C.Hien（IBM T.J.Watson研究中心）Michael Kirkham（InterWorking Labs，Inc.）Dave Levi（SNMP Research，Inc.）Louis A MamakosJoe Marzot（北电网络）Paul Meyer（安全计算公司）Keith McCloghrie（思科系统）Bob Moore（IBM）Russ Mundy（网络协会实验室）Bob Natale（ACE*通信公司）Mike O'Dell（北电网络技术公司）Dave Perkins（桌面对话）Peter Polkinghorne（布鲁内尔大学）Randy Presuhn（BMC软件公司）大卫·里德（网络协会的实验室）大卫·里德（SNMP研究公司）阿列克西·罗曼诺夫（质量法定人数）肖恩·劳希尔（尾声）尤尔根·肖恩瓦埃尔德（TU Braunschweig）鲍勃·斯图尔特（思科系统）迈克·撒切尔（独立顾问）伯特·维恩（IBM T.J.沃森研究中心）
The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were:
本文件基于IETF安全和管理框架演进SNMP咨询团队的建议。该咨询小组的成员是：
David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco Systems) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research Center)
David Harrington（Cabletron Systems Inc.）Jeff Johnson（Cisco Systems）David Levi（SNMP Research Inc.）John Linn（Openvision）Russ Mundy（Trusted Information Systems）Shawn Routhier（尾声）Glenn Waters（Nortel）Bert Wijnen（IBM T.J.Watson研究中心）
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*:
根据咨询小组和SNMPv3工作组章程的建议，该设计尽可能多地结合了先前RFC和草案中的实际内容。因此，我们特别感谢以前设计的SNMPv2u和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.)
Jeff Case（SNMP Research，Inc.）David Harrington（Cabletron Systems Inc.）David Levi（SNMP Research，Inc.）Keith McCloghrie（Cisco Systems）Brian O'Keefe（惠普）Marshall T.Rose（多佛海滩咨询）Jon Saperia（BGS Systems Inc.）Steve Waldbusser（国际网络服务）Glenn W.Waters（贝尔北方研究有限公司）
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.
- SNMP引擎必须丢弃与任何当前未完成的请求消息不对应的SNMP响应消息。消息处理模块负责处理此问题。例如，它可以为此使用msgID。
An SNMP Command Generator Application must discard any Response Class PDU for which there is no currently outstanding Confirmed Class PDU; for example for SNMPv2 [RFC3416] PDUs, the request-id component in the PDU can be used to correlate Responses to outstanding Requests.
SNMP命令生成器应用程序必须放弃当前没有未完成的确认类PDU的任何响应类PDU；例如，对于SNMPv2[RFC3416]PDU，PDU中的请求id组件可用于将响应与未完成的请求关联起来。
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).
虽然SNMP引擎和SNMP命令生成器应用程序通常会理所当然地执行此操作，但在使用这些安全协议时，由于存在消息复制（恶意或其他）的可能性，这一点非常重要。
- 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.
- 如果SNMP引擎使用msgID将响应消息与未完成的请求消息关联起来，则它必须在一个时间窗口（150秒）期间发送的所有此类请求消息中使用不同的msgID。
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.
命令生成器或通知发起人应用程序必须在其在时间窗口（150秒）期间发出的所有请求PDU中使用不同的请求ID。
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.
例如，使用msgID和/或请求id值为零启动操作不是一个好主意。用一个不可预测的数字初始化它们（这样它们在每次重新启动后启动时就不一样了），然后再递增1是可以接受的。
- An SNMP engine should perform time synchronization using authenticated messages in order to protect against the possibility of message duplication (malicious or otherwise).
- SNMP引擎应使用经过身份验证的消息执行时间同步，以防止消息复制（恶意或其他）的可能性。
- 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.
- 向托管权威SNMP引擎发送状态更改消息时，命令生成器应用程序应延迟向该托管SNMP引擎发送连续消息，直到收到前一条消息的肯定确认或前一条消息过期。
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.
SNMP不强制消息排序。消息可以按照与生成时间相关的任何顺序接收，并且每个消息都将按照已接收的顺序进行处理。请注意，当向受管SNMP引擎发送经过身份验证的消息时，在正常情况下，该消息的有效期约为150秒，在此期间可能会被重播。事实上，SNMP引擎和SNMP命令生成器应用程序必须理所当然地处理由于网络异常而导致的消息丢失和重新排序。
However, a managed object, snmpSetSerialNo [RFC3418], 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.
但是，管理对象snmpSetSerialNo[RFC3418]是专门定义用于SNMP集操作的，目的是提供一种机制，以确保SNMP消息的处理按特定顺序进行。
- 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.
保护秘密不被泄露对协议的整体安全至关重要。频繁使用一个秘密提供了一个持续的数据源，这可能有助于密码分析师利用算法中已知或感知的弱点。频繁更改密码可以避免此漏洞。
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.
同样要注意的是，在本地环境中，泄露的威胁可能不太明显，因此，更改机密的频率可能较低。然而，当使用公共数据网络作为通信路径时，更为谨慎。
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.
本文档中定义的机制采用了代表其发送消息的用户的概念。如何定义“用户”取决于网络管理局的安全策略。例如，用户可以是个人（例如，“joe”或“jane”），或特定角色（例如，“operator”或“administrator”），或组合（例如，“joe operator”、“jane operator”或“joe admin”）。此外，用户可以是逻辑实体，例如SNMP应用程序或一组SNMP应用程序，代表个人或角色、个人集合或角色集合，包括组合。
Appendix A describes an algorithm for mapping a user "password" to a 16/20 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/20 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. Please note that longer passwords with repetitive strings may result in exactly the same key. For example, a password 'bertbert' will result in exactly the same key as password 'bertbertbert'.
附录A描述了一种将用户“密码”映射到16/20八位字节值的算法，以用作用户的身份验证密钥或隐私密钥（或两者兼有）。但是，请注意，在身份验证和隐私中使用相同的密码（因此使用相同的密钥）是非常糟糕的安全做法，应该强烈反对。密码通常由人工生成、记忆和输入。人工生成的密码可能小于身份验证和隐私协议所需的16/20八位字节，并且暴力攻击在相对较短的ASCII字符集上非常容易。因此，算法是附录A对密码执行转换。如果使用附录A算法，SNMP实现（和SNMP配置应用程序）必须确保密码长度至少为8个字符。请注意，带有重复字符串的较长密码可能会产生完全相同的密钥。例如，密码“bertbert”将产生与密码“bertbert”完全相同的密钥。
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.
因为附录A算法（几乎）直接使用了这样的密码，所以它们不容易被猜测是非常重要的。建议它们由大小写字母数字和标点符号混合组成，这些字符不会构成字典中可能找到的单词或短语。更长的密码可以提高系统的安全性。用户可能希望输入多单词短语，以使其密码字符串更长，同时确保其值得记忆。
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 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.
由于人类用户不可能为每个SNMP引擎维护不同的密码，但安全要求强烈反对为多个SNMP引擎使用相同的密钥，因此基于用户的安全模型采用了[本地化密钥]中提出的折衷方案。它从用户密码派生SNMP引擎的用户密钥，从而实际上无法从SNMP引擎上的任何用户密钥组合确定用户密码或另一个SNMP引擎的用户密钥。
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.
但请注意，如果用户密码被泄露，则密钥本地化将无济于事，在这种情况下，网络安全可能会受到损害。因此，用户的密码或非本地化密钥不得存储在受管设备/节点上。相反，应存储本地化密钥（如果有的话），以便在设备确实受损的情况下，其他受管或管理设备不会受损。
To be termed a "Secure SNMP implementation" based on the User-based Security Model, an SNMP implementation MUST:
要称为基于基于用户的安全模型的“安全SNMP实现”，SNMP实现必须：
- 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.
- 实现一个或多个身份验证协议。本备忘录中定义的HMAC-MD5-96和HMAC-SHA-96认证协议就是此类协议的示例。
- 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.
- 在所有情况下，尽最大可能禁止访问其在本地配置数据存储（LCD）中维护信息的每个用户的机密，除非生成和/或验证有关该用户的SNMP消息。
- implement the key-localization mechanism.
- 实现密钥本地化机制。
- implement the SNMP-USER-BASED-SM-MIB.
- 实现SNMP-USER-BASED-SM-MIB。
In addition, an authoritative SNMP engine SHOULD provide initial configuration in accordance with Appendix A.1.
此外，权威SNMP引擎应根据附录A.1提供初始配置。
Implementation of a Privacy Protocol (the DES Symmetric Encryption Protocol defined in this memo is one such protocol) is optional.
隐私协议的实施（本备忘录中定义的DES对称加密协议就是此类协议之一）是可选的。
The use of unsecure reports (i.e., sending them with a securityLevel of noAuthNoPriv) potentially exposes a non-authoritative SNMP engine to some form of attacks. Some people consider these denial of service attacks, others don't. An installation should evaluate the risk involved before deploying unsecure Report PDUs.
使用不安全报告（即，以安全级别noAuthNoPriv发送报告）可能会使非权威SNMP引擎遭受某种形式的攻击。有些人认为这些拒绝服务攻击，其他人则不这样认为。在部署不安全报告PDU之前，安装应评估所涉及的风险。
The objects in this MIB may be considered sensitive in many environments. Specifically the objects in the usmUserTable contain information about users and their authentication and privacy protocols. It is important to closely control (both read and write) access to these MIB objects by using appropriately configured Access Control models (for example the View-based Access Control Model as specified in [RFC3415]).
在许多环境中，此MIB中的对象可能被视为敏感对象。具体来说，usmUserTable中的对象包含有关用户及其身份验证和隐私协议的信息。通过使用适当配置的访问控制模型（例如，[RFC3415]中规定的基于视图的访问控制模型），密切控制（读写）对这些MIB对象的访问非常重要。
[RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“消息摘要算法MD5”，RFC13211992年4月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[RFC3412]Case，J.，Harrington，D.，Presohn，R.和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月。
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415]Wijnen，B.，Presohn，R.和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
[RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416]Presohn，R.，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMP）的协议操作版本2”，STD 62，RFC 3416，2002年12月。
[RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417]Presohn，R.，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月。
[RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418]Presohn，R.，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[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-NIST]数据加密标准，国家标准与技术研究所。联邦信息处理标准（FIPS）出版物46-1。取代FIPS第46号出版物（1977年1月；1988年1月重申）。
[DESO-NIST] DES Modes of Operation, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 81, (December, 1980).
[DESO-NIST]DES操作模式，国家标准与技术研究所。联邦信息处理标准（FIPS）第81号出版物（1980年12月）。
[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)
[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)
[Localized-Key] U. Blumenthal, N. C. Hien, B. Wijnen "Key Derivation for Network Management Applications" IEEE Network Magazine, April/May issue, 1997.
[本地化密钥]U.Blumenthal，N.C.Hien，B.Wijnen“网络管理应用程序的密钥推导”，IEEE网络杂志，1997年4月/5月号。
[DES-ANSI] Data Encryption Algorithm, American National Standards Institute. ANSI X3.92-1981, (December, 1980).
[DES-ANSI]数据加密算法，美国国家标准协会。ANSI X3.92-1981（1980年12月）。
[DESO-ANSI] Data Encryption Algorithm - Modes of Operation, American National Standards Institute. ANSI X3.106- 1983, (May 1983).
[DESO-ANSI]数据加密算法-操作模式，美国国家标准协会。ANSI X3.106-1983（1983年5月）。
[DESG-NIST] Guidelines for Implementing and Using the NBS Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 74, (April, 1981).
[DESG-NIST]国家标准与技术研究所NBS数据加密标准实施和使用指南。联邦信息处理标准（FIPS）第74号出版物（1981年4月）。
[DEST-NIST] Validating the Correctness of Hardware Implementations of the NBS Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-20.
[DEST-NIST]验证国家标准与技术研究所NBS数据加密标准硬件实现的正确性。特别出版物500-20。
[DESM-NIST] Maintenance Testing for the Data Encryption Standard, National Institute of Standards and Technology. Special Publication 500-61, (August, 1980).
[DESM-NIST]数据加密标准维护测试，国家标准与技术研究所。特别出版物500-61（1980年8月）。
[RFC3174] Eastlake, D. 3rd and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake，D.3rd和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
APPENDIX A - Installation
附录A-安装
During installation, an authoritative SNMP engine SHOULD (in the meaning as defined in [RFC2119]) be configured with several initial parameters. These include:
在安装过程中，权威SNMP引擎（按照[RFC2119]中的定义）应配置多个初始参数。这些措施包括：
1) A Security Posture
1) 安全姿态
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
2) 一个或多个秘密
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 [RFC1321]. The resulting digest, termed "digest1", is used in the next step.
- 根据需要经常重复密码的值，相应地截断，并将结果字符串用作MD5算法的输入，从而形成长度为1048576个八位字节的字符串[RFC1321]。生成的摘要称为“摘要1”，将在下一步中使用。
- 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 [RFC1321].
- 第二个字符串由SNMP引擎的snmpEngineID值digest1和digest1连接而成。此字符串用作MD5算法[RFC1321]的输入。
The resulting digest is the required secret (see Appendix A.2).
由此产生的摘要是所需的机密（见附录A.2）。
With these configured parameters, the SNMP engine instantiates the following usmUserEntry in the usmUserTable:
通过这些配置参数，SNMP引擎在usmUserTable中实例化以下usmUserEntry：
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
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
It is recommended to also instantiate a set of template usmUserEntries which can be used as clone-from users for newly created usmUserEntries. These are the two suggested entries:
建议还实例化一组模板usmUserEntries，该模板可用作新创建usmUserEntries的用户克隆。以下是两个建议条目：
no privacy support privacy support
------------------ ---------------
usmUserEngineID localEngineID localEngineID
usmUserName "templateMD5" "templateMD5"
usmUserSecurityName "templateMD5" "templateMD5"
usmUserCloneFrom ZeroDotZero ZeroDotZero
usmUserAuthProtocol usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol
usmUserAuthKeyChange "" ""
usmUserOwnAuthKeyChange "" ""
usmUserPrivProtocol none usmDESPrivProtocol
usmUserPrivKeyChange "" ""
usmUserOwnPrivKeyChange "" ""
usmUserPublic "" ""
usmUserStorageType permanent permanent
usmUserStatus active active
no privacy support privacy support
------------------ ---------------
usmUserEngineID localEngineID localEngineID
usmUserName "templateMD5" "templateMD5"
usmUserSecurityName "templateMD5" "templateMD5"
usmUserCloneFrom ZeroDotZero ZeroDotZero
usmUserAuthProtocol usmHMACMD5AuthProtocol usmHMACMD5AuthProtocol
usmUserAuthKeyChange "" ""
usmUserOwnAuthKeyChange "" ""
usmUserPrivProtocol none usmDESPrivProtocol
usmUserPrivKeyChange "" ""
usmUserOwnPrivKeyChange "" ""
usmUserPublic "" ""
usmUserStorageType permanent permanent
usmUserStatus active active
no privacy support privacy support
------------------ ---------------
usmUserEngineID localEngineID localEngineID
usmUserName "templateSHA" "templateSHA"
usmUserSecurityName "templateSHA" "templateSHA"
usmUserCloneFrom ZeroDotZero ZeroDotZero
usmUserAuthProtocol usmHMACSHAAuthProtocol usmHMACSHAAuthProtocol
usmUserAuthKeyChange "" ""
usmUserOwnAuthKeyChange "" ""
usmUserPrivProtocol none usmDESPrivProtocol
usmUserPrivKeyChange "" ""
usmUserOwnPrivKeyChange "" ""
usmUserPublic "" ""
usmUserStorageType permanent permanent
usmUserStatus active active
no privacy support privacy support
------------------ ---------------
usmUserEngineID localEngineID localEngineID
usmUserName "templateSHA" "templateSHA"
usmUserSecurityName "templateSHA" "templateSHA"
usmUserCloneFrom ZeroDotZero ZeroDotZero
usmUserAuthProtocol usmHMACSHAAuthProtocol usmHMACSHAAuthProtocol
usmUserAuthKeyChange "" ""
usmUserOwnAuthKeyChange "" ""
usmUserPrivProtocol none usmDESPrivProtocol
usmUserPrivKeyChange "" ""
usmUserOwnPrivKeyChange "" ""
usmUserPublic "" ""
usmUserStorageType permanent permanent
usmUserStatus active active
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].
示例代码片段（第A.2.1节）演示了密码到密钥算法，该算法可在使用MD5将密码映射到身份验证密钥或隐私密钥时使用。MD5的参考源代码见[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).
另一个示例代码片段（第A.2.2节）演示了密码到密钥算法，该算法可在使用SHA（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.3节），实现者可以使用该示例检查其实现是否产生相同的结果。
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;
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 */
MD5Init (&MD); /* initialize MD5 */
/**********************************************/
/* 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 */
/**********************************************/
/* 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+16+engineLength, key, 16);
/*****************************************************/
/* 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+16+engineLength, key, 16);
MD5Init(&MD);
MD5Update(&MD, password_buf, 32+engineLength);
MD5Final(key, &MD);
return;
}
MD5Init(&MD);
MD5Update(&MD, password_buf, 32+engineLength);
MD5Final(key, &MD);
return;
}
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;
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;
SHAInit (&SH); /* initialize SHA */
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 */
/**********************************************/
/* 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+20+engineLength, key, 20);
/*****************************************************/
/* 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+20+engineLength, key, 20);
SHAInit(&SH);
SHAUpdate(&SH, password_buf, 40+engineLength);
SHAFinal(key, &SH);
return;
}
SHAInit(&SH);
SHAUpdate(&SH, password_buf, 40+engineLength);
SHAFinal(key, &SH);
return;
}
The following shows a sample output of the password to key algorithm for a 16-octet key using MD5.
下面显示了使用MD5的16位八位组密钥的密码到密钥算法的示例输出。
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:
如果密码为“maple糖浆”，则在使用SNMP引擎的snmpEngineID对密钥进行本地化之前，密码到密钥算法的输出为：
'9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H
'9f af 32 83 88 4e 92 83 4e bc 98 47 d8 ed d9 63'H
After the intermediate key (shown above) is localized with the snmpEngineID value of:
使用snmpEngineID值本地化中间键（如上所示）后：
'00 00 00 00 00 00 00 00 00 00 00 02'H
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
'52 6f 5e ed 9f cc e2 6f 89 64 c2 93 07 87 d8 2b'H
The following shows a sample output of the password to key algorithm for a 20-octet key using SHA.
下面显示了使用SHA的20个八位组密钥的密码到密钥算法的示例输出。
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:
如果密码为“maple糖浆”，则在使用SNMP引擎的snmpEngineID对密钥进行本地化之前，密码到密钥算法的输出为：
'9f b5 cc 03 81 49 7b 37 93 52 89 39 ff 78 8d 5d 79 14 52 11'H
'9f b5 cc 03 81 49 7b 37 93 52 89 39 ff 78 8d 5d 79 14 52 11'H
After the intermediate key (shown above) is localized with the snmpEngineID value of:
使用snmpEngineID值本地化中间键（如上所示）后：
'00 00 00 00 00 00 00 00 00 00 00 02'H
00 00 00 00 02'H
the final output of the password to key algorithm is:
密码到密钥算法的最终输出为：
'66 95 fe bc 92 88 e3 62 82 23 5f c7 15 1f 12 84 97 b3 8f 3f'H
'66 95 fe bc 92 88 e3 62 82 23 5f c7 15 1f 12 84 97 b3 8f 3f'H
The msgSecurityParameters in an SNMP message are represented as an OCTET STRING. This OCTET STRING should be considered opaque outside a specific Security Model.
SNMP消息中的msgSecurityParameters表示为八位字节字符串。在特定的安全模型之外，应将此八位字节字符串视为不透明的。
The User-based Security Model defines the contents of the OCTET STRING as a SEQUENCE (see section 2.4).
基于用户的安全模型将八位字节字符串的内容定义为一个序列（参见第2.4节）。
Given these two properties, the following is an example of they msgSecurityParameters for the User-based Security Model, encoded as an OCTET STRING:
给定这两个属性，以下是基于用户的安全模型的msgSecurityParameters示例，编码为八位字节字符串：
04 <length>
30 <length>
04 <length> <msgAuthoritativeEngineID>
02 <length> <msgAuthoritativeEngineBoots>
02 <length> <msgAuthoritativeEngineTime>
04 <length> <msgUserName>
04 0c <HMAC-MD5-96-digest>
04 08 <salt>
04 <length>
30 <length>
04 <length> <msgAuthoritativeEngineID>
02 <length> <msgAuthoritativeEngineBoots>
02 <length> <msgAuthoritativeEngineTime>
04 <length> <msgUserName>
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):
下面是一个示例，但现在是实际值（msgAuthenticationParameters中的摘要和MSGPrivacParameters中的salt除外，它们取决于我们在此未定义的变量数据）：
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
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
Let us assume that a user has a current password of "maplesyrup" as in section A.3.1. and let us also assume the snmpEngineID of 12 octets:
假设用户的当前密码为“Maplegloop”，如第a.3.1节所述。我们也假设12个八位组的snmpEngineID：
'00 00 00 00 00 00 00 00 00 00 00 02'H
00 00 00 00 02'H
If we now want to change the password to "newsyrup", then we first calculate the key for the new password. It is as follows:
如果我们现在想将密码更改为“newsyrup”，那么我们首先计算新密码的密钥。详情如下:
'01 ad d2 73 10 7c 4e 59 6b 4b 00 f8 2b 1d 42 a7'H
'01 ad d2 73 10 7c 4e 59 6b 4b 00 f8 2b 1d 42 a7'H
If we localize it for the above snmpEngineID, then the localized new key becomes:
如果我们将其本地化为上述snmpEngineID，则本地化的新密钥将变为：
'87 02 1d 7b d9 d1 01 ba 05 ea 6e 3b f9 d9 bd 4a'H
'87 02 1d 7b d9 d1 01 ba 05 ea 6e 3b f9 d9 bd 4a'H
If we then use a (not so good, but easy to test) random value of:
如果我们使用（不太好，但易于测试）随机值：
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H
00 00 00 00 00 00 00 00'H
Then the value we must send for keyChange is:
那么我们必须为keyChange发送的值是：
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 88 05 61 51 41 67 6c c9 19 61 74 e7 42 a3 25 51'H
'00 00 00 00 00 00 88 05 61 51 41 67 6c c9 19 61 74 e7 42 a3 25 51'H
If this were for the privacy key, then it would be exactly the same.
如果这是隐私密钥，那么它将完全相同。
Let us assume that a user has a current password of "maplesyrup" as in section A.3.2. and let us also assume the snmpEngineID of 12 octets:
假设用户的当前密码为“Maplegloop”，如第a.3.2节所述。我们也假设12个八位组的snmpEngineID：
'00 00 00 00 00 00 00 00 00 00 00 02'H
00 00 00 00 02'H
If we now want to change the password to "newsyrup", then we first calculate the key for the new password. It is as follows:
如果我们现在想将密码更改为“newsyrup”，那么我们首先计算新密码的密钥。详情如下:
'3a 51 a6 d7 36 aa 34 7b 83 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H
'3a 51 a6 d7 36 aa 34 7b 83 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H
If we localize it for the above snmpEngineID, then the localized new key becomes:
如果我们将其本地化为上述snmpEngineID，则本地化的新密钥将变为：
'78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63 91 f1 cd 25'H
'78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63 91 f1 cd 25'H
If we then use a (not so good, but easy to test) random value of:
如果我们使用（不太好，但易于测试）随机值：
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H
00 00 00 00 00 00 00 00'H
Then the value we must send for keyChange is:
那么我们必须为keyChange发送的值是：
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9c 10 17 f4 fd 48 3d 2d e8 d5 fa db f8 43 92 cb 06 45 70 51'
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
For the key used for privacy, the new nonlocalized key would be:
对于用于隐私的密钥，新的非本地化密钥为：
'3a 51 a6 d7 36 aa 34 7b 83 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H
'3a 51 a6 d7 36 aa 34 7b 83 dc 4a 87 e3 e5 5e e4 d6 98 ac 71'H
For the key used for privacy, the new localized key would be (note that they localized key gets truncated to 16 octets for DES):
对于用于隐私的密钥，新的本地化密钥为（注意，对于DES，本地化密钥被截断为16个八位字节）：
'78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63'H
'78 e2 dc ce 79 d5 94 03 b5 8c 1b ba a5 bf f4 63'H
If we then use a (not so good, but easy to test) random value of:
如果我们使用（不太好，但易于测试）随机值：
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'H
00 00 00 00 00 00 00 00'H
Then the value we must send for keyChange for the privacy key is:
那么我们必须为隐私密钥的密钥更改发送的值为：
'00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '7e f8 d8 a4 c9 cd b2 6b 47 59 1c d8 52 ff 88 b5'H
‘00 00 00 00 00 00’7e f8 d8 a4 c9 cd b2 6b 47 59 1c d8 52 ff 88 b5'H
B. Change Log
B.更改日志
Changes made since RFC2574:
自RFC2574以来所做的更改：
- Updated references - Updated contact info - Clarifications - to first constraint item 1) on page 6. - to usmUserCloneFrom DESCRIPTION clause - to securityName in section 2.1 - Fixed "command responder" into "command generator" in last para of DESCRIPTION clause of usmUserTable.
- 更新参考资料-更新联系信息-澄清-第6页第一个约束项1）至USMUSERCONE从描述条款-至第2.1节中的安全名称-将usmUserTable描述条款最后一段中的“命令响应程序”固定至“命令生成器”。
Changes made since RFC2274:
自RFC2274以来所做的更改：
- Fixed msgUserName to allow size of zero and explain that this can be used for snmpEngineID discovery. - Clarified section 3.1 steps 4.b, 5, 6 and 8.b. - Clarified section 3.2 paragraph 2. - Clarified section 3.2 step 7.a last paragraph, step 7.b.1 second bullet and step 7.b.2 third bullet. - Clarified section 4 to indicate that discovery can use a userName of zero length in unAuthenticated messages, whereas a valid userName must be used in authenticated messages. - Added REVISION clauses to MODULE-IDENTITY - Clarified KeyChange TC by adding a note that localized keys must be used when calculating a KeyChange value. - Added clarifying text to the DESCRIPTION clause of usmUserTable. Added text describes a recommended procedure for adding a new user. - Clarified the use of usmUserCloneFrom object.
- 修正了允许大小为零的msgUserName，并解释了这可以用于snmpEngineID发现。-澄清了第3.1节步骤4.b、5、6和8.b.-澄清了第3.2节第2段。-澄清了第3.2节步骤7.a最后一段、步骤7.b.1第二个项目符号和步骤7.b.2第三个项目符号。-澄清了第4节，指出discovery可以在未经身份验证的消息中使用长度为零的用户名，而在经过身份验证的消息中必须使用有效的用户名。-在MODULE-IDENTITY中添加了修订条款-通过添加注释澄清了KeyChange TC，说明在计算KeyChange值时必须使用本地化键。-在usmUserTable的DESCRIPTION子句中添加了澄清文本。添加的文本描述了添加新用户的建议步骤。-阐明了usmUserCloneFrom对象的用法。
- Clarified how and under which conditions the usmUserAuthProtocol and usmUserPrivProtocol can be initialized and/or changed. - Added comment on typical sizes for usmUserAuthKeyChange and usmUserPrivKeyChange. Also for usmUserOwnAuthKeyChange and usmUserOwnPrivKeyChange. - Added clarifications to the DESCRIPTION clauses of usmUserAuthKeyChange, usmUserOwnAuthKeychange, usmUserPrivKeyChange and usmUserOwnPrivKeychange. - Added clarification to DESCRIPTION clause of usmUserStorageType. - Added clarification to DESCRIPTION clause of usmUserStatus. - Clarified IV generation procedure in section 8.1.1.1 and in addition clarified section 8.3.1 step 1 and section 8.3.2. step 3. - Clarified section 11.2 and added a warning that different size passwords with repetitive strings may result in same key. - Added template users to appendix A for cloning process. - Fixed C-code examples in Appendix A. - Fixed examples of generated keys in Appendix A. - Added examples of KeyChange values to Appendix A. - Used PDU Classes instead of RFC1905 PDU types. - Added text in the security section about Reports and Access Control to the MIB. - Removed a incorrect note at the end of section 3.2 step 7. - Added a note in section 3.2 step 3. - Corrected various spelling errors and typos. - Corrected procedure for 3.2 step 2.a) - various clarifications. - Fixed references to new/revised documents - Change to no longer cache data that is not used
- 阐明了如何以及在何种条件下初始化和/或更改usmUserAuthProtocol和usmUserPrivProtocol。-增加了对usmUserAuthKeyChange和usmUserPrivKeyChange典型尺寸的注释。也适用于USMuseRowNautheyChange和usmUserOwnPrivKeyChange。-对USMUSERAUTHEYCHANGE、USMUSEROWNAUTHEYCHANGE、usmUserPrivKeyChange和usmUserOwnPrivKeychange的说明条款进行了澄清。-增加了对usmUserStorageType说明条款的澄清。-增加了对usmUserStatus说明条款的澄清。-澄清了第8.1.1.1节中的IV生成程序，并澄清了第8.3.1节步骤1和第8.3.2节。第3步-澄清了第11.2节，并添加了一条警告，即具有重复字符串的不同大小的密码可能会导致相同的密钥。-在附录A中添加了用于克隆过程的模板用户。-修正了附录A中的C代码示例。-修正了附录A中生成的密钥示例。-在附录A中添加了密钥更改值示例。-使用了PDU类而不是RFC1905 PDU类型。-在安全部分添加了关于MIB报告和访问控制的文本。-删除了第3.2节第7步末尾的错误注释。-在第3.2节第3步中添加注释。-更正了各种拼写错误和打字错误3.2步骤2.a）的纠正程序-各种澄清-修复了对新文档/修订文档的引用-更改为不再缓存未使用的数据
Editors' Addresses
编辑地址
Uri Blumenthal Lucent Technologies 67 Whippany Rd. Whippany, NJ 07981 USA
美国新泽西州惠帕尼市惠帕尼路67号乌里·布鲁门塔尔·朗讯科技公司，邮编：07981
Phone: +1-973-386-2163
EMail: uri@lucent.com
Phone: +1-973-386-2163
EMail: uri@lucent.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands
Bert Wijnen-Lucent Technologies Schagen 33 3461德国劳埃德船级社荷兰
Phone: +31-348-480-685
EMail: bwijnen@lucent.com
Phone: +31-348-480-685
EMail: bwijnen@lucent.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。