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
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.
この文書では、SNMPアーキテクチャで使用するために簡易ネットワーク管理プロトコルのバージョン3のためのセキュリティサブシステムであるユーザベースセキュリティモデル（USM）に記載のプロトコルを補完する対称暗号化プロトコルを記述します。この文書に記載され、対称暗号化プロトコルは、128ビットの鍵サイズと、暗号フィードバックモード（CFB）で使用されるのAdvanced Encryption Standard（AES）暗号化アルゴリズムに基づいています。
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
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.
SNMPv3のインターネット管理フレームワーク[RFC3411]、ユーザベースのセキュリティモデル（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の使用を記載しています。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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（Advanced Encryption Standard）[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]で定義されるように、ローカライズされたキーは、ユーザが認証およびプライバシーパスワードの唯一のペア（およびキーの結果としてのみ、1対）を有することができるにもかかわらず、ユーザ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]
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のMODULE-IDENTITY LAST-UPDATED "200406140000Z" ORGANIZATION "IETF" CONTACT-INFO「ウリブルーメンソールルーセント・テクノロジーズ/ベル研究所67ホイッパニーRdの。14D-318ホイッパニー、NJ 07981、USA 973-386-2163 uri@bell-labs.com
Fabio Maino
Andiamo Systems, Inc.
375 East Tasman Drive
San Jose, CA 95134, USA
408-853-7530
fmaino@andiamo.com
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706, USA
キースMcCloghrieシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706、USA
408-526-5260 kzm@cisco.com" DESCRIPTION "Definitions of Object Identities needed for the use of AES by SNMP's User-based Security Model.
SNMPのユーザベースセキュリティモデルによるAESを使用するために必要なオブジェクトのアイデンティティの408-526-5260 kzm@cisco.com「説明」の定義。
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."
このMIBモジュールのこのバージョンはRFC 3826の一部です。完全な適法な通知についてはRFC自体を参照してください。補足情報はhttp://www.ietf.org/copyrights/ianamib.htmlに利用できます。」
REVISION "200406140000Z" DESCRIPTION "Initial version, published as RFC3826"
REVISION "200406140000Z" DESCRIPTION "初期バージョン、RFC3826として公開"
::= { 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).
usmAesCfb128Protocol OBJECT-IDENTITYステータス現在の説明 "CFB128-AES-128プライバシープロトコル。" REFERENCE「 - 。高度暗号化標準連邦情報処理標準（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 }
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.
このセクションでは、128ビットのサイズと暗号化キーを使用して、AES暗号アルゴリズム[FIPS-AES]、[AES-MODE]に記載されているように暗号フィードバックモードで使用されるに基づいて対称暗号化プロトコルを記載しています。
This protocol is identified by usmAesCfb128PrivProtocol.
このプロトコルはusmAesCfb128PrivProtocolによって識別されます。
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（Advanced Encryption Standard）はNIST（米国国立標準技術研究所）はDES（データ暗号化規格）の交換用として4年間の競争過程で選択した対称暗号アルゴリズムです。
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は、連邦情報処理標準に完全に高度暗号化標準を指定し、[FIPS-AES]を含む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).
電子コードブック（ECB）、暗号ブロック連鎖（CBC）、暗号フィードバック（CFB）、出力フィードバック（OFB）、カウンタ：は、NIST Special Publication 800-38A [AES-MODE]はAESで使用するための操作の5つの機密モードをお勧めします（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.
このメモに記載の対称暗号化プロトコルは、[AES-MODE]で与えられたCFBモードの定義に従ってS（フィードバックビット数）は128に設定されたパラメータとCFBモードでAESを使用します。このモードでは、暗号アルゴリズムのブロックサイズと同じサイズで初期化ベクトル（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-MODE]に推奨されているように、このメモで説明暗号化プロトコルではAESは、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ユーザの局所キー（クル）の大きさは、正式の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.
ローカライズされたキークルの最初の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.
32ビットのsnmpEngineBootsが第4オクテット（最上位バイト）に変換され、32ビットsnmpEngineTimeが後続4つのオクテット（最上位バイト）、および64ビットに変換され、次のようにIVが連結されています整数は、最後の8つのオクテット（最上位バイトが最初）に変換されます。 64ビット整数は、次に、長さ8つのオクテットのオクテット文字列として符号化さmsgPrivacyParametersフィールドに入れられます。整数は、後続のメッセージのために修正されます。我々は、それはそれがラップされた時点でその最大値に達するまで、それは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.
実装は、選択された方法は、同じキーの重複IVを生成することはありません提供する、ローカルの64ビット整数の値を変化させる任意の方法を使用することができます。
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ビット整数は、正しいIVを計算するために、メッセージを解読するために受信エンティティを有効にするprivParametersフィールドに配置しなければなりません。この64ビット値は、このドキュメントの「塩」と呼ばれています。
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の値、および（それぞれmsgAuthoritativeEngineBoots、msgAuthoritativeEngineTime、及びprivParametersフィールドに）関連するメッセージに含まれる64ビットの整数を使用しなければなりません。
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モードの定義に応じて128に設定さsのデータは、暗号フィードバックモードで暗号化されています。暗号化および復号化プロセスの明確な図は[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であり、順方向暗号化動作は、第1の出力ブロックを生成するIVに適用されます。第一の暗号文ブロックは、排他的論理和することにより、第1の出力ブロックと最初の平文ブロックを生成します。暗号文ブロックはまた、後続の順方向暗号操作の入力ブロックとして使用されます。
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ビットの最後の平文セグメント（rは以下128に等しい）が生成されます。
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は、最初の暗号文を第二の入力ブロックのために使用される第一の入力ブロックであり、第二の暗号文は、順方向暗号関数は、出力を生成するために、各入力ブロックに適用される第3の入力ブロック、等のために使用されますブロック。出力ブロックは、平文ブロックを回復するために、対応する暗号文ブロックと排他的論理和です。
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エンジンは、そのユーザの知識を持っている必要があることを、EN /特定のSNMPエンジンで復号化しなければなりません。別のSNMPエンジンと通信する必要があるSNMPエンジンは、そのユーザーの該当属性の知識を含めて、そのSNMPエンジンに知られているユーザーの知識を持っている必要があります。
A user and its attributes are defined as follows:
次のようにユーザーとその属性が定義されています。
<userName> An octet string representing the name of the user.
<ユーザー名>のユーザーの名前を表すオクテット文字列。
<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]).
認証されたメッセージに含まmsgAuthoritativeEngineID値（SNMPアーキテクチャ文書[RFC3411]でのsnmpEngineIDの定義を参照）、その特定のメッセージのための正式のSNMPエンジンを指定します。
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.
このプライバシープロトコルを使用したメッセージは、msgSecurityParametersの一部としてmsgPrivacyParametersフィールドを運びます。このプロトコルでは、privParametersフィールドはIVを作成するために使用された「塩」を表す連載されたOCTET STRINGです。
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プライバシープロトコルはprivKeyの選択は、発信者によって行われていること、および呼び出し側が使用するローカライズされた秘密鍵を渡していることを前提としています。
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とmsgPrivacyParametersはOCTET STRINGとしてエンコードされ、statusInformationをを返し。原始的な抽象サービスは以下のとおりです。
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を= - 成功または失敗のencryptData（サービスプロバイダーによって記入さencryptKey、IN - dataToEncryptにおける暗号化のための秘密鍵 - データが（たscopedPDU）OUTはEncryptedDataを暗号化する - - 暗号化されたデータ（encryptedPDU）OUT privParameters）
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.
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プライバシープロトコルはprivKeyの選択は、発信者によって行われていることと、発信者が使用するローカライズされた秘密鍵を渡していることを前提としています。
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をを返します。原始的な抽象サービスは以下のとおりです。
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（はEncryptedDataワイヤ上で受信した - - decryptKey IN - privParameters、IN復号用の秘密鍵暗号化されたデータ（encryptedPDU）OUT decryptedData - 復号化されたデータ（たscopedPDU））
The abstract data elements are:
抽象データ要素は次のとおりです。
statusInformation An indication of whether the data was successfully decrypted, and if not, an indication of the error.
、エラーの表示をデータが正常に復号化されたかどうかの表示をステータス情報、そうでない場合。
decryptKey The secret key to be used by the decryption algorithm. The length of this key MUST be 16 octets.
解読アルゴリズムが使用する秘密鍵decryptKey。このキーの長さは16個のオクテットでなければなりません。
privParameters The 64-bit integer to be used to calculate the IV.
IVを計算するために使用される64ビット整数をprivParameters。
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.
このセクションでは、usmAesCfb128PrivProtocolを使用して発信メッセージの一部を暗号化しなければならないたびにSNMPエンジンの処理手順を記述しています。
1) The secret encryptKey is used to construct the AES encryption key, as described in section 3.1.2.1.
セクション3.1.2.1に記載されているように1）秘密encryptKeyは、AES暗号化キーを構築するために使用されます。
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フィールドは、セクション3.1.2.1に記載されているようにIVに使用される64ビット整数を表すオクテット文字列の[RFC3417]の規則に従ってシリアル化に設定されています。
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で説明したように）と暗号化されたデータはOCTET STRINGとして[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）privParametersとstatusInformationを示す成功と共に暗号化されたscopedPDUを表す連載されたOCTET STRINGは、呼び出し側モジュールに戻されます。
This section describes the procedure followed by an SNMP engine whenever it must decrypt part of an incoming message using the usmAesCfb128PrivProtocol.
このセクションでは、usmAesCfb128PrivProtocolを使用して着信メッセージの一部を復号化しなければならないたびにSNMPエンジンの処理手順を記述しています。
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オクテットオクテットSTRING、エラー表示（decryptionErrorない場合）呼び出し側モジュールに戻されます。
2) The 64-bit integer is extracted from the privParameters field.
2）64ビット整数がprivParametersフィールドから抽出されます。
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）秘密decryptKeyと64ビットの整数は、次に、AES復号鍵とセクション3.1.2.1に記載されるように計算されるIVを構築するために使用されます。
4) The encryptedPDU is then decrypted (as described in section 3.1.4).
セクション3.1.4に記載したように4）encryptedPDUはその後）（復号されます。
5) If the encryptedPDU cannot be decrypted, then an error indication (decryptionError) is returned to the calling module.
encryptedPDUを復号できない場合5）、エラー表示（decryptionError）は、呼び出し側モジュールに戻されます。
6) The decrypted scopedPDU and statusInformation indicating success are returned to the calling module.
6）復号化されたscopedPDUとstatusInformationを示す成功は呼ぶモジュールに返されます。
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モードのセキュリティは、同じ鍵[CRYPTO-B]を用いて暗号化された各メッセージの一意のIVの使用に依存します。 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ビット整数（塩）からIVを導出する手順を定義します。実装は、選択された方法は、同じキーの重複IVを生成することはありません提供する、ローカルの64ビット整数の値を変化させる任意の方法を使用することができます。
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の手順は、すべてのメッセージの一意のIVを生成するローカルの64ビット整数値を変化させる方法が提案されています。この方法は、複数のマネージャは、秒以内に同じ64ビット整数を選択し、両方の誤っ、単一の権威機関と通信することを非常に低い場合に重複IVをもたらすことができます。このようなイベントの確率は非常に低く、大幅提案メカニズムの堅牢性に影響を与えることはありません。
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.
CFB暗号化モードは、暗号文の変更を検出しないので、このAESベースのプライバシープロトコルは、RFC 3414で、または（完全性を含む）同等の機能を提供するアルゴリズム/プロトコルで定義された認証プロトコルのいずれかと共に使用されなければなりません。
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はhttp://www.iana.org/assignments/smi-numbersにレジストリ内に維持、snmpModulesサブツリーの下snmpUsmAesMIBモジュールのOID 20が割り当てられています。
IANA has assigned OID 4 for the usmAesCfb128Protocol under the snmpPrivProtocols registration point, as defined in RFC 3411 [RFC3411].
RFC 3411 [RFC3411]で定義されるようにIANAは、snmpPrivProtocols登録地点下usmAesCfb128Protocolため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 WGメンバー、特にウェスHardaker、スティーブ・モールトン、ランディPresuhn、デビッド・タウン、およびバートWijnenの多くに感謝しています。スティーブ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 Special Publication 800-38A、2001年12月。
[FIPS-AES] "Specification for the ADVANCED ENCRYPTION STANDARD (AES)", Federal Information Processing Standard (FIPS) Publication 197, November 2001.
[FIPS-AES]、連邦情報処理標準（FIPS）出版197、2001年11月 "のAdvanced Encryption Standard（AES）のための仕様"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、パーキンス、D.およびJ. Schoenwaelder、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[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]ハリントン、D.、Presuhnと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.
、STD 62、RFC 3414、2002年12月 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）" [RFC3414]ブルーメンソール、U.とB. Wijnenの、。
[RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417] Presuhn、R.、エド。、 "簡易ネットワーク管理プロトコル（SNMP）のためのマッピングを輸送します"、STD 62、RFC 3417、2002年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セキュリティプロトコルの考え平文解読」、ネットワーク上のシンポジウムと分散システムセキュリティ、サンディエゴ、CA、頁155〜160、1997年2月。
Uri Blumenthal Lucent Technologies / Bell Labs 67 Whippany Rd. 14D-318 Whippany, NJ 07981, USA
ウリブルーメンソールルーセント・テクノロジーズ/ベル研究所67ホイッパニーRdを。 14D-318ホイッパニー、NJ 07981、USA
Phone: +1-973-386-2163 EMail: uri@bell-labs.com
電話：+ 1-973-386-2163 Eメール：uri@bell-labs.com
Fabio Maino Andiamo Systems, Inc. 375 East Tasman Drive San Jose, CA. 95134 USA
ファビオ・メイノーアンディアモSystems、Inc.の375東タスマン・ドライブサンノゼ、CA。 95134 USA
Phone: +1-408-853-7530 EMail: fmaino@andiamo.com
電話：+ 1-408-853-7530 Eメール：fmaino@andiamo.com
Keith McCloghrie Cisco Systems, Inc. 170 East Tasman Drive San Jose, CA. 95134-1706 USA
キースMcCloghrieシスコシステムズ、株式会社170東タスマン・ドライブサンノゼ、CA。 95134-1706 USA
Phone: +1-408-526-5260 EMail: kzm@cisco.com
電話：+ 1-408-526-5260 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。