Network Working Group U. Blumenthal
Request for Comments: 3826 Lucent Technologies
Category: Standards Track F. Maino
Andiamo Systems, Inc.
K. McCloghrie
Cisco Systems, Inc.
June 2004
Network Working Group U. Blumenthal
Request for Comments: 3826 Lucent Technologies
Category: Standards Track F. Maino
Andiamo Systems, Inc.
K. McCloghrie
Cisco Systems, Inc.
June 2004
The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model
基于SNMP用户的安全模型中的高级加密标准（AES）密码算法
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits.
本文档描述了对称加密协议，该协议补充了基于用户的安全模型（USM）中描述的协议，USM是SNMP体系结构中使用的简单网络管理协议版本3的安全子系统。本文档中描述的对称加密协议基于密码反馈模式（CFB）中使用的高级加密标准（AES）密码算法，密钥大小为128位。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Goals and Constraints. . . . . . . . . . . . . . . . . 2
1.2. Key Localization . . . . . . . . . . . . . . . . . . . 3
1.3. Password Entropy and Storage . . . . . . . . . . . . . 3
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. CFB128-AES-128 Symmetric Encryption Protocol . . . . . . . . 5
3.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. The AES-based Symmetric Encryption Protocol . . 6
3.1.2. Localized Key, AES Encryption Key and
Initialization Vector . . . . . . . . . . . . . 7
3.1.3. Data Encryption . . . . . . . . . . . . . . . . 8
3.1.4. Data Decryption . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Goals and Constraints. . . . . . . . . . . . . . . . . 2
1.2. Key Localization . . . . . . . . . . . . . . . . . . . 3
1.3. Password Entropy and Storage . . . . . . . . . . . . . 3
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. CFB128-AES-128 Symmetric Encryption Protocol . . . . . . . . 5
3.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. The AES-based Symmetric Encryption Protocol . . 6
3.1.2. Localized Key, AES Encryption Key and
Initialization Vector . . . . . . . . . . . . . 7
3.1.3. Data Encryption . . . . . . . . . . . . . . . . 8
3.1.4. Data Decryption . . . . . . . . . . . . . . . . 8
3.2. Elements of the AES Privacy Protocol . . . . . . . . . 9
3.2.1. Users . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. msgAuthoritativeEngineID. . . . . . . . . . . . 9
3.2.3. SNMP Messages Using this Privacy Protocol . . . 10
3.2.4. Services provided by the AES Privacy Modules. . 10
3.3. Elements of Procedure. . . . . . . . . . . . . . . . . 11
3.3.1. Processing an Outgoing Message. . . . . . . . . 12
3.3.2. Processing an Incoming Message. . . . . . . . . 12
4. Security Considerations. . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . 14
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
3.2. Elements of the AES Privacy Protocol . . . . . . . . . 9
3.2.1. Users . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. msgAuthoritativeEngineID. . . . . . . . . . . . 9
3.2.3. SNMP Messages Using this Privacy Protocol . . . 10
3.2.4. Services provided by the AES Privacy Modules. . 10
3.3. Elements of Procedure. . . . . . . . . . . . . . . . . 11
3.3.1. Processing an Outgoing Message. . . . . . . . . 12
3.3.2. Processing an Incoming Message. . . . . . . . . 12
4. Security Considerations. . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . 14
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
Within the Architecture for describing Internet Management Frameworks [RFC3411], the User-based Security Model (USM) [RFC3414] for SNMPv3 is defined as a Security Subsystem within an SNMP engine. RFC 3414 describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the initial authentication protocols, and the use of CBC-DES as the initial privacy protocol. The User-based Security Model, however, allows for other such protocols to be used instead of, or concurrently with, these protocols.
在描述Internet管理框架的体系结构[RFC3411]中，SNMPv3的基于用户的安全模型（USM）[RFC3414]被定义为SNMP引擎中的安全子系统。RFC 3414描述了使用HMAC-MD5-96和HMAC-SHA-96作为初始身份验证协议，以及使用CBC-DES作为初始隐私协议。然而，基于用户的安全模型允许使用其他此类协议来代替这些协议或与这些协议同时使用。
This memo describes the use of CFB128-AES-128 as an alternative privacy protocol for the User-based Security Model. 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].
本备忘录描述了使用CFB128-AES-128作为基于用户的安全模型的替代隐私协议。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The main goal of this memo is to provide a new privacy protocol for the USM based on the Advanced Encryption Standard (AES) [FIPS-AES].
本备忘录的主要目标是基于高级加密标准（AES）[FIPS-AES]为USM提供新的隐私协议。
The major constraint is to maintain a complete interchangeability of the new protocol defined in this memo with existing authentication and privacy protocols already defined in USM.
主要限制是保持本备忘录中定义的新协议与USM中已定义的现有认证和隐私协议的完全互换性。
For a given user, the AES-based privacy protocol MUST be used with one of the authentication protocols defined in RFC 3414 or an algorithm/protocol providing equivalent functionality.
对于给定用户，基于AES的隐私协议必须与RFC 3414中定义的认证协议之一或提供等效功能的算法/协议一起使用。
As defined in [RFC3414], 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 pair of authentication and privacy passwords (and consequently only one pair of keys) for the entire network, the actual secrets shared between the user and each authoritative SNMP engine will be different. This is achieved by key localization.
如[RFC3414]中所定义，本地化密钥是用户U和一个权威SNMP引擎E之间共享的秘密密钥。即使用户可能只有一对认证和隐私密码（因此只有一对密钥）用于整个网络，用户和每个权威SNMP引擎之间共享的实际机密将不同。这是通过关键本地化实现的。
If the authentication protocol defined for a user U at the authoritative SNMP engine E is one of the authentication protocols defined in [RFC3414], the key localization is performed according to the two-step process described in section 2.6 of [RFC3414].
如果在权威SNMP引擎E为用户U定义的认证协议是[RFC3414]中定义的认证协议之一，则根据[RFC3414]第2.6节中描述的两步过程执行密钥本地化。
The security of various cryptographic functions lies both in the strength of the functions themselves against various forms of attack, and also, perhaps more importantly, in the keying material that is used with them. While theoretical attacks against cryptographic functions are possible, it is more probable that key guessing is the main threat.
各种密码功能的安全性既取决于功能本身抵御各种形式攻击的能力，也可能更重要的是，取决于与它们一起使用的密钥材料。虽然对密码函数的理论攻击是可能的，但更可能的是密钥猜测是主要威胁。
The following are recommended in regard to user passwords:
以下是关于用户密码的建议：
- Password length SHOULD be at least 12 octets. - Password sharing SHOULD be prohibited so that passwords are not shared among multiple SNMP users. - Implementations SHOULD support the use of randomly generated passwords as a stronger form of security.
- 密码长度应至少为12个八位字节。-应禁止密码共享，以便多个SNMP用户之间不共享密码。-实现应该支持使用随机生成的密码作为更强大的安全形式。
It is worth remembering that, as specified in [RFC3414], if a user's password or a non-localized key is disclosed, then key localization will not help and network security may be compromised. 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.
值得记住的是，如[RFC3414]中所述，如果披露了用户密码或非本地化密钥，则密钥本地化将无济于事，网络安全可能会受到损害。因此，用户的密码或非本地化密钥不得存储在受管设备/节点上。相反，应存储本地化密钥（如果有的话），以便在设备确实受损的情况下，其他受管或管理设备不会受损。
This MIB is written in SMIv2 [RFC2578].
这个MIB是用SMIv2[RFC2578]编写的。
SNMP-USM-AES-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY,
snmpModules FROM SNMPv2-SMI -- [RFC2578]
snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411]
SNMP-USM-AES-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY,
snmpModules FROM SNMPv2-SMI -- [RFC2578]
snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411]
snmpUsmAesMIB MODULE-IDENTITY LAST-UPDATED "200406140000Z" ORGANIZATION "IETF" CONTACT-INFO "Uri Blumenthal Lucent Technologies / Bell Labs 67 Whippany Rd. 14D-318 Whippany, NJ 07981, USA 973-386-2163 uri@bell-labs.com
snmpUsmAesMIB模块标识最新更新的“200406140000Z”组织“IETF”联系信息Uri Blumenthal-Lucent Technologies/Bell Labs 67 Whippany路14D-318 Whippany，NJ 07981，USA 973-386-2163uri@bell-实验室网站
Fabio Maino Andiamo Systems, Inc. 375 East Tasman Drive San Jose, CA 95134, USA 408-853-7530 fmaino@andiamo.com
美国加利福尼亚州圣何塞东塔斯曼大道375号法比奥·梅诺·安迪亚莫系统公司，邮编：95134 408-853-7530fmaino@andiamo.com
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706, USA
Keith McCloghrie Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
408-526-5260 kzm@cisco.com" DESCRIPTION "Definitions of Object Identities needed for the use of AES by SNMP's User-based Security Model.
408-526-5260 kzm@cisco.comSNMP基于用户的安全模型使用AES所需的对象标识的“描述”定义。
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This version of this MIB module is part of RFC 3826;
see the RFC itself for full legal notices.
Supplementary information may be available on
http://www.ietf.org/copyrights/ianamib.html."
This version of this MIB module is part of RFC 3826;
see the RFC itself for full legal notices.
Supplementary information may be available on
http://www.ietf.org/copyrights/ianamib.html."
REVISION "200406140000Z" DESCRIPTION "Initial version, published as RFC3826"
修订版“200406140000Z”说明“初始版本，发布为RFC3826”
::= { snmpModules 20 }
::= { snmpModules 20 }
usmAesCfb128Protocol OBJECT-IDENTITY STATUS current DESCRIPTION "The CFB128-AES-128 Privacy Protocol." REFERENCE "- Specification for the ADVANCED ENCRYPTION STANDARD. Federal Information Processing Standard (FIPS) Publication 197. (November 2001).
USMAESCFB128协议对象身份状态当前描述“CFB128-AES-128隐私协议”。参考-高级加密标准规范。联邦信息处理标准（FIPS）出版物197。（2001年11月）。
- Dworkin, M., NIST Recommendation for Block
Cipher Modes of Operation, Methods and
Techniques. NIST Special Publication 800-38A
(December 2001).
"
::= { snmpPrivProtocols 4 }
- Dworkin, M., NIST Recommendation for Block
Cipher Modes of Operation, Methods and
Techniques. NIST Special Publication 800-38A
(December 2001).
"
::= { snmpPrivProtocols 4 }
END
终止
This section describes a Symmetric Encryption Protocol based on the AES cipher algorithm [FIPS-AES], used in Cipher Feedback Mode as described in [AES-MODE], using encryption keys with a size of 128 bits.
本节描述了基于AES密码算法[FIPS-AES]的对称加密协议，该算法在[AES-Mode]中描述的密码反馈模式下使用，使用128位的加密密钥。
This protocol is identified by usmAesCfb128PrivProtocol.
该协议由USMAESCFB128协议确定。
The protocol usmAesCfb128PrivProtocol is an alternative to the privacy protocol defined in [RFC3414].
协议usmAesCfb128PrivProtocol是[RFC3414]中定义的隐私协议的替代协议。
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 is shared by all SNMP engines which can legitimately originate messages on behalf of the appropriate user. This secret value, in combination with a timeliness value and a 64-bit integer, is used to create the (localized) en/decryption key and the initialization vector.
所有SNMP引擎都共享一个秘密值，这些引擎可以代表适当的用户合法地发起消息。该秘密值与时间值和64位整数结合，用于创建（本地化）en/解密密钥和初始化向量。
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消息的指定部分经过加密，并作为发送给收件人的消息的一部分包含在内。
The AES (Advanced Encryption Standard) is the symmetric cipher algorithm that the NIST (National Institute of Standards and Technology) has selected in a four-year competitive process as Replacement for DES (Data Encryption Standard).
AES（高级加密标准）是NIST（国家标准与技术研究所）在四年竞争过程中选择的对称密码算法，以取代DES（数据加密标准）。
The AES homepage, http://www.nist.gov/aes, contains a wealth of information on AES including the Federal Information Processing Standard [FIPS-AES] that fully specifies the Advanced Encryption Standard.
AES主页，http://www.nist.gov/aes，包含有关AES的大量信息，包括完全指定高级加密标准的联邦信息处理标准[FIPS-AES]。
The following subsections contain descriptions of the relevant characteristics of the AES ciphers used in the symmetric encryption protocol described in this memo.
以下小节包含本备忘录所述对称加密协议中使用的AES密码的相关特征说明。
The NIST Special Publication 800-38A [AES-MODE] recommends five confidentiality modes of operation for use with AES: Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB), and Counter (CTR).
NIST特别出版物800-38A[AES-MODE]推荐了五种用于AES的保密操作模式：电子码本（ECB）、密码块链接（CBC）、密码反馈（CFB）、输出反馈（OFB）和计数器（CTR）。
The symmetric encryption protocol described in this memo uses AES in CFB mode with the parameter S (number of bits fed back) set to 128 according to the definition of CFB mode given in [AES-MODE]. This mode requires an Initialization Vector (IV) that is the same size as the block size of the cipher algorithm.
本备忘录中描述的对称加密协议在CFB模式下使用AES，参数S（反馈的位数）根据[AES-mode]中给出的CFB模式定义设置为128。此模式需要与密码算法的块大小相同的初始化向量（IV）。
In the encryption protocol described by this memo AES is used with a key size of 128 bits, as recommended in [AES-MODE].
在本备忘录描述的加密协议中，AES与[AES-MODE]中建议的128位密钥一起使用。
The block size of the AES cipher algorithms used in the encryption protocol described by this memo is 128 bits, as recommended in [AES-MODE].
根据[AES-MODE]中的建议，本备忘录所述加密协议中使用的AES密码算法的块大小为128位。
This parameter determines how many times a block is encrypted. The encryption protocol described in this memo uses 10 rounds, as recommended in [AES-MODE].
此参数确定块加密的次数。按照[AES-MODE]中的建议，本备忘录中描述的加密协议使用10轮。
The size of the Localized Key (Kul) of an SNMP user, as described in [RFC3414], depends on the authentication protocol defined for that user U at the authoritative SNMP engine E.
如[RFC3414]中所述，SNMP用户的本地化密钥（Kul）的大小取决于在权威SNMP引擎E上为该用户U定义的身份验证协议。
The encryption protocol defined in this memo MUST be used with an authentication protocol that generates a localized key with at least 128 bits. The authentication protocols described in [RFC3414] satisfy this requirement.
此备忘录中定义的加密协议必须与生成至少128位的本地化密钥的身份验证协议一起使用。[RFC3414]中描述的认证协议满足此要求。
The first 128 bits of the localized key Kul are used as the AES encryption key. The 128-bit IV is obtained as the concatenation of the authoritative SNMP engine's 32-bit snmpEngineBoots, the SNMP engine's 32-bit snmpEngineTime, and a local 64-bit integer. The 64- bit integer is initialized to a pseudo-random value at boot time.
本地化密钥Kul的前128位用作AES加密密钥。128位IV作为权威SNMP引擎的32位snmpEngineBoots、SNMP引擎的32位snmpEngineTime和本地64位整数的串联而获得。64位整数在启动时被初始化为伪随机值。
The IV is concatenated as follows: the 32-bit snmpEngineBoots is converted to the first 4 octets (Most Significant Byte first), the 32-bit snmpEngineTime is converted to the subsequent 4 octets (Most Significant Byte first), and the 64-bit integer is then converted to the last 8 octets (Most Significant Byte first). The 64-bit integer is then put into the msgPrivacyParameters field encoded as an OCTET STRING of length 8 octets. The integer is then modified for the subsequent message. We recommend that it is incremented by one until it reaches its maximum value, at which time it is wrapped.
IV按如下方式连接：32位snmpEngineBoots转换为前4个八位字节（首先是最高有效字节），32位snmpEngineTime转换为后续4个八位字节（首先是最高有效字节），然后64位整数转换为最后8个八位字节（首先是最高有效字节）。然后将64位整数放入msgPrivacyParameters字段，该字段编码为长度为8个八位字节的八位字节字符串。然后为后续消息修改整数。我们建议将其递增1，直到达到其最大值，此时它将被包装。
An implementation can use any method to vary the value of the local 64-bit integer, providing the chosen method never generates a duplicate IV for the same key.
一个实现可以使用任何方法来改变本地64位整数的值，前提是所选择的方法不会为同一个密钥生成重复的IV。
A duplicated IV can result in the very unlikely event that multiple managers, communicating with a single authoritative engine, both accidentally select the same 64-bit integer within a second. The probability of such an event is very low, and does not significantly affect the robustness of the mechanisms proposed.
重复的IV可能会导致多个管理器在与单个权威引擎通信时，在一秒钟内意外选择相同的64位整数。发生此类事件的概率非常低，并且不会显著影响所提出机制的鲁棒性。
The 64-bit integer must be placed in the privParameters field to enable the receiving entity to compute the correct IV and to decrypt the message. This 64-bit value is called the "salt" in this document.
64位整数必须放在privParameters字段中，以使接收实体能够计算正确的IV并解密消息。此64位值在本文档中称为“salt”。
Note that the sender and receiver must use the same IV value, i.e., they must both use the same values of the individual components used to create the IV. In particular, both sender and receiver must use the values of snmpEngineBoots, snmpEngineTime, and the 64-bit integer which are contained in the relevant message (in the msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime, and privParameters fields respectively).
请注意，发送方和接收方必须使用相同的IV值，即它们都必须使用用于创建IV的各个组件的相同值。特别是，发送方和接收方都必须使用相关消息中包含的snmpEngineBoots、snmpEngineTime和64位整数的值（分别在MsgAuthoritativeEngineBooks、msgAuthoritativeEngineTime和privParameters字段中）。
The data to be encrypted is treated as a sequence of octets.
要加密的数据被视为八位字节序列。
The data is encrypted in Cipher Feedback mode with the parameter s set to 128 according to the definition of CFB mode given in Section 6.3 of [AES-MODE]. A clear diagram of the encryption and decryption process is given in Figure 3 of [AES-MODE].
根据[AES-mode]第6.3节给出的CFB模式定义，数据以密码反馈模式加密，参数s设置为128。[AES-MODE]的图3给出了加密和解密过程的清晰示意图。
The plaintext is divided into 128-bit blocks. The last block may have fewer than 128 bits, and no padding is required.
明文被分成128位块。最后一个块可能少于128位，并且不需要填充。
The first input block is the IV, and the forward cipher operation is applied to the IV to produce the first output block. The first ciphertext block is produced by exclusive-ORing the first plaintext block with the first output block. The ciphertext block is also used as the input block for the subsequent forward cipher operation.
第一个输入块是IV，正向密码操作应用于IV以产生第一个输出块。第一密文块通过将第一明文块与第一输出块异或产生。密文块还用作后续正向密码操作的输入块。
The process is repeated with the successive input blocks until a ciphertext segment is produced from every plaintext segment.
对连续的输入块重复该过程，直到每个明文段产生一个密文段。
The last ciphertext block is produced by exclusive-ORing the last plaintext segment of r bits (r is less than or equal to 128) with the segment of the r most significant bits of the last output block.
最后一个密文块是通过将r位的最后一个明文段（r小于或等于128）与最后一个输出块的r个最高有效位的段进行异或产生的。
In CFB decryption, the IV is the first input block, the first ciphertext is used for the second input block, the second ciphertext is used for the third input block, etc. The forward cipher function is applied to each input block to produce the output blocks. The output blocks are exclusive-ORed with the corresponding ciphertext blocks to recover the plaintext blocks.
在CFB解密中，IV是第一个输入块，第一个密文用于第二个输入块，第二个密文用于第三个输入块，等等。前向密码函数应用于每个输入块以生成输出块。输出块与相应的密文块进行异或运算，以恢复明文块。
The last ciphertext block (whose size r is less than or equal to 128) is exclusive-ORed with the segment of the r most significant bits of the last output block to recover the last plaintext block of r bits.
最后一个密文块（其大小r小于或等于128）与最后一个输出块的r最高有效位的段进行异或运算，以恢复r位的最后一个明文块。
This section contains definitions required to realize the privacy modules 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 needs 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引擎必须了解该用户。需要与另一个SNMP引擎通信的SNMP引擎还必须了解该SNMP引擎已知的用户，包括该用户的适用属性。
A user and its attributes are defined as follows:
用户及其属性定义如下：
<userName> An octet string representing the name of the user.
<userName>表示用户名称的八位字节字符串。
<privAlg> The algorithm used to protect messages generated on behalf of the user from disclosure.
<privAlg>用于保护代表用户生成的消息不被泄露的算法。
<privKey> The user's secret key to be used as input to the generation of the localized key for encrypting/decrypting messages generated on behalf of the user. The length of this key MUST be greater than or equal to 128 bits (16 octets).
<privKey>要用作生成本地化密钥的输入的用户密钥，用于加密/解密代表用户生成的消息。此密钥的长度必须大于或等于128位（16个八位字节）。
<authAlg> The algorithm used to authenticate messages generated on behalf of the user, which is also used to generate the localized version of the secret key.
<authAlg>用于对代表用户生成的消息进行身份验证的算法，该算法还用于生成密钥的本地化版本。
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 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 privParameters field is the serialized OCTET STRING representing the "salt" that was used to create the IV.
使用此隐私协议的消息包含一个MSGPrivacParameters字段，作为msgSecurityParameters的一部分。对于该协议，privParameters字段是表示用于创建IV的“salt”的序列化八位字节字符串。
This section describes the inputs and outputs that the AES Privacy module expects and produces when the User-based Security module invokes one of the AES Privacy modules for services.
本节描述了当基于用户的安全模块为服务调用其中一个AES隐私模块时，AES隐私模块期望和产生的输入和输出。
The AES privacy protocol assumes that the selection of the privKey is done by the caller, and that the caller passes the localized secret key to be used.
AES隐私协议假定私钥的选择由调用者完成，并且调用者传递要使用的本地化私钥。
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:
完成后，隐私模块返回状态信息，如果加密过程成功，则返回encryptedPDU和编码为八位字节字符串的MSGPRIVAcParameters。抽象服务原语是：
statusInformation = -- success or 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 or 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 AES privacy protocol assumes that the selection of the privKey is done by the caller and that the caller passes the localized secret key to be used.
此AES隐私协议假定私钥的选择由调用者完成，并且调用者传递要使用的本地化私钥。
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 of 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 64-bit integer to be used to calculate the IV.
privParameters用于计算IV的64位整数。
encryptedData The data to be decrypted.
encryptedData要解密的数据。
decryptedData The decrypted data.
decryptedData已解密的数据。
This section describes the procedures for the AES privacy protocol for SNMP's User-based Security Model.
本节介绍用于SNMP的基于用户的安全模型的AES隐私协议的过程。
This section describes the procedure followed by an SNMP engine whenever it must encrypt part of an outgoing message using the usmAesCfb128PrivProtocol.
本节介绍SNMP引擎在必须使用USMAESCFB128PRIVE协议加密部分传出消息时遵循的过程。
1) The secret encryptKey is used to construct the AES encryption key, as described in section 3.1.2.1.
1) 机密加密密钥用于构造AES加密密钥，如第3.1.2.1节所述。
2) The privParameters field is set to the serialization according to the rules in [RFC3417] of an OCTET STRING representing the 64-bit integer that will be used in the IV as described in section 3.1.2.1.
2) privParameters字段根据[RFC3417]中的规则设置为表示将在IV中使用的64位整数的八位字符串的序列化，如第3.1.2.1节所述。
3) The scopedPDU is encrypted (as described in section 3.1.3) and the encrypted data is serialized according to the rules in [RFC3417] as an OCTET STRING.
3) scopedPDU被加密（如第3.1.3节所述），加密数据根据[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 usmAesCfb128PrivProtocol.
本节介绍SNMP引擎必须使用USMAESCFB128PRIVE协议解密部分传入消息时所遵循的过程。
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 64-bit integer is extracted from the privParameters field.
2) 从privParameters字段中提取64位整数。
3) The secret decryptKey and the 64-bit integer are then used to construct the AES decryption key and the IV that is computed as described in section 3.1.2.1.
3) 然后，使用秘密解密密钥和64位整数构造AES解密密钥和IV，并按照第3.1.2.1节中的说明计算IV。
4) The encryptedPDU is then decrypted (as described in section 3.1.4).
4) 然后对加密的PDU进行解密（如第3.1.4节所述）。
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 security of the cryptographic functions defined in this document lies both in the strength of the functions themselves against various forms of attack, and also, perhaps more importantly, in the keying material that is used with them. The recommendations in Section 1.3 SHOULD be followed to ensure maximum entropy to the selected passwords, and to protect the passwords while stored.
本文档中定义的加密函数的安全性既在于函数本身抵御各种形式攻击的强度，也可能更重要的是，在于与它们一起使用的密钥材料。应遵循第1.3节中的建议，以确保所选密码的最大熵，并在存储时保护密码。
The security of the CFB mode relies upon the use of a unique IV for each message encrypted with the same key [CRYPTO-B]. If the IV is not unique, a cryptanalyst can recover the corresponding plaintext.
CFB模式的安全性依赖于对使用相同密钥加密的每条消息使用唯一的IV[CRYPTO-B]。如果IV不是唯一的，密码分析员可以恢复相应的明文。
Section 3.1.2.1 defines a procedure to derive the IV from a local 64-bit integer (the salt) initialized to a pseudo-random value at boot time. An implementation can use any method to vary the value of the local 64-bit integer, providing the chosen method never generates a duplicate IV for the same key.
第3.1.2.1节定义了从引导时初始化为伪随机值的本地64位整数（salt）推导IV的过程。一个实现可以使用任何方法来改变本地64位整数的值，前提是所选择的方法不会为同一个密钥生成重复的IV。
The procedure of section 3.1.2.1 suggests a method to vary the local 64-bit integer value that generates unique IVs for every message. This method can result in a duplicated IV in the very unlikely event that multiple managers, communicating with a single authoritative engine, both accidentally select the same 64-bit integer within a second. The probability of such an event is very low, and does not significantly affect the robustness of the mechanisms proposed.
第3.1.2.1节中的程序建议了一种改变本地64位整数值的方法，该整数值为每条消息生成唯一的IVs。这种方法可能会导致重复的IV，这种情况极不可能发生，即多个管理器与单个权威引擎通信时，都会在一秒钟内意外选择相同的64位整数。发生此类事件的概率非常低，并且不会显著影响所提出机制的鲁棒性。
This AES-based privacy protocol MUST be used with one of the authentication protocols defined in RFC 3414 or with an algorithm/protocol providing equivalent functionality (including integrity), because CFB encryption mode does not detect ciphertext modifications.
此基于AES的隐私协议必须与RFC 3414中定义的认证协议之一或提供等效功能（包括完整性）的算法/协议一起使用，因为CFB加密模式不会检测密文修改。
For further security considerations, the reader is encouraged to read [RFC3414], and the documents that describe the actual cipher algorithms.
出于进一步的安全考虑，鼓励读者阅读[RFC3414]和描述实际密码算法的文档。
IANA has assigned OID 20 for the snmpUsmAesMIB module under the snmpModules subtree, maintained in the registry at http://www.iana.org/assignments/smi-numbers.
IANA已在snmpModules子树下为snmpUsmAesMIB模块分配OID 20，该子树保存在http://www.iana.org/assignments/smi-numbers.
IANA has assigned OID 4 for the usmAesCfb128Protocol under the snmpPrivProtocols registration point, as defined in RFC 3411 [RFC3411].
IANA已根据RFC 3411[RFC3411]中的定义，为SNMPPRIVE协议注册点下的USMAESCFB128协议分配OID 4。
Portions of this text, as well as its general structure, were unabashedly lifted from [RFC3414]. The authors are grateful to many of the SNMPv3 WG members for their help, especially Wes Hardaker, Steve Moulton, Randy Presuhn, David Town, and Bert Wijnen. Security discussions with Steve Bellovin helped to streamline this protocol.
本文的部分内容及其总体结构都是从[RFC3414]中毫不掩饰地删去的。作者感谢许多SNMPv3工作组成员的帮助，特别是韦斯·哈达克、史蒂夫·莫尔顿、兰迪·普雷森、大卫·敦和伯特·维恩。与Steve Bellovin的安全讨论有助于简化该协议。
[AES-MODE] Dworkin, M., "NIST Recommendation for Block Cipher Modes of Operation, Methods and Techniques", NIST Special Publication 800-38A, December 2001.
[AES-MODE]Dworkin，M.“NIST关于分组密码操作模式、方法和技术的建议”，NIST特别出版物800-38A，2001年12月。
[FIPS-AES] "Specification for the ADVANCED ENCRYPTION STANDARD (AES)", Federal Information Processing Standard (FIPS) Publication 197, November 2001.
[FIPS-AES]“高级加密标准（AES）规范”，联邦信息处理标准（FIPS）出版物197，2001年11月。
[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. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.和J.Schoenwaeld，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年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月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）版本3的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
[RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417]Presohn，R.，Ed.“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月。
[CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997.
[CRYPTO-B]Bellovin，S.，“IP安全协议的可能明文密码分析”，网络和分布式系统安全研讨会论文集，加利福尼亚州圣地亚哥，第155-160页，1997年2月。
Uri Blumenthal Lucent Technologies / Bell Labs 67 Whippany Rd. 14D-318 Whippany, NJ 07981, USA
Uri Blumenthal-Lucent Technologies/贝尔实验室美国新泽西州惠帕尼路67号惠帕尼14D-318号，邮编07981
Phone: +1-973-386-2163
EMail: uri@bell-labs.com
Phone: +1-973-386-2163
EMail: uri@bell-labs.com
Fabio Maino Andiamo Systems, Inc. 375 East Tasman Drive San Jose, CA. 95134 USA
美国加利福尼亚州圣何塞东塔斯曼大道375号Fabio Maino Andiamo系统公司，邮编95134
Phone: +1-408-853-7530
EMail: fmaino@andiamo.com
Phone: +1-408-853-7530
EMail: fmaino@andiamo.com
Keith McCloghrie Cisco Systems, Inc. 170 East Tasman Drive San Jose, CA. 95134-1706 USA
基思·麦克洛赫里思科系统公司，美国加利福尼亚州圣何塞市东塔斯曼大道170号，邮编95134-1706
Phone: +1-408-526-5260
EMail: kzm@cisco.com
Phone: +1-408-526-5260
EMail: kzm@cisco.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。