[要約] 要約：RFC 3826は、SNMPユーザベースのセキュリティモデルで使用されるAES暗号アルゴリズムについて説明しています。 目的：このRFCの目的は、SNMPセキュリティモデルで使用されるAES暗号アルゴリズムの詳細な仕様を提供し、セキュリティの向上を図ることです。
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）The Internet Society（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）で使用される高度な暗号化標準（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.
インターネット管理フレームワーク[RFC3411]を説明するためのアーキテクチャ内で、SNMPV3のユーザーベースのセキュリティモデル（USM）[RFC3414]は、SNMPエンジン内のセキュリティサブシステムとして定義されます。RFC 3414は、HMAC-MD5-96およびHMAC-SHA-96を初期認証プロトコルとして使用し、CBC-DEを初期プライバシープロトコルとして使用することを説明しています。ただし、ユーザーベースのセキュリティモデルでは、これらのプロトコルではなく、または同時に他のこのようなプロトコルを使用できます。
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の使用について説明しています。「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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と1つの権威ある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]で定義されている認証プロトコルの1つである場合、[RFC3414]のセクション2.6で説明されている2段階のプロセスに従って重要なローカリゼーションが実行されます。
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モジュールのアイデンティティ最後の「200406140000z」組織 "IETF" contact-info "uri Blumenthal Lucent Technologies / bell Labs 67 WhippanyRd。14d-318 Whippany、NJ 07981、USA 973-386-2163 Uri@bell-Labsscomcom
Fabio Maino Andiamo Systems, Inc. 375 East Tasman Drive San Jose, CA 95134, USA 408-853-7530 fmaino@andiamo.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
Keith McCloghrie Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 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.com「説明」SNMPのユーザーベースのセキュリティモデルによるAESの使用に必要なオブジェクトアイデンティティの定義。
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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"
リビジョン「200406140000Z」説明「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オブジェクトアイデンティティステータス現在の説明「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 }
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-Mode]で説明されているように、128ビットのサイズの暗号化キーを使用して、暗号フィードバックモードで使用されるAES暗号アルゴリズム[FIPS-AES]に基づく対称暗号化プロトコルについて説明します。
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暗号化標準）は、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).
NIST Special Publication 800-38A [AES-Mode]は、AESで使用する5つの機密性操作モードを推奨しています。電子コードブック（ECB）、暗号ブロックチェーン（CBC）、暗号フィードバック（CFB）、出力フィードバック（OF）、およびカウンター（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モード]で指定された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ユーザーのローカライズされたキー（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ビット整数は、長さ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.
実装では、任意の方法を使用してローカル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ビット整数を1秒以内に選択する可能性が低いイベントをもたらす可能性があります。このようなイベントの確率は非常に低く、提案されたメカニズムの堅牢性に大きな影響を与えません。
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ビット値は、このドキュメントの「塩」と呼ばれます。
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の作成に使用される個々のコンポーネントの同じ値を使用する必要があることに注意してください。特に、送信者と受信機の両方が、関連するメッセージに含まれるSnmpengineboot、SnmpengineTime、および64ビット整数の値を使用する必要があります（MSGAuthoritativeEngineBoot、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に適用され、最初の出力ブロックが生成されます。最初のciphertextブロックは、最初の出力ブロックを備えた最初のプレーンテキストブロックを排他的に固定することによって生成されます。ciphertextブロックは、後続の前方暗号操作の入力ブロックとしても使用されます。
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以下）を排他的に固定することによって生成され、最後の出力ブロックの最も重要なビットのセグメントが生成されます。
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は最初の入力ブロックであり、最初の暗号文は2番目の入力ブロックに使用され、2番目の暗号文は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.
この対称暗号化プロトコルを使用したデータEN/復号化により、定義されたユーザー名セットが使用されます。メッセージを特定のSNMPエンジンでen/decryptedする必要があるユーザーの場合、その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]).
認証されたメッセージに含まれるMSGAuthoritativeEngineID値は、その特定のメッセージの権威ある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を使用してEN/復号化プロセスの適切なキーを選択します。
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の作成に使用された「塩」を表すシリアル化されたオクテット文字列です。
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プライバシーモジュールの1つを呼び出すときに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:
完了すると、プライバシーモジュールはStatusInformationを返し、暗号化プロセスが成功した場合、暗号化されたPDUとMSGPRIVACYPARAMETERSがOctet Stringとしてエンコードされます。抽象サービスプリミティブは次のとおりです。
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.
暗号化されたデータは、正常に完了すると暗号化されたデータを暗号化しました。
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:
完了すると、プライバシーモジュールはStatusInformationを返し、復号化プロセスが成功した場合、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.
ステータス情報データが正常に復号化されたかどうか、そうでない場合はエラーの兆候を示しています。
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.
PrivParameterは、IVを計算するために使用される64ビット整数を使用します。
encryptedData The data to be decrypted.
暗号化されるデータを復号化するデータ。
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.
1) Secret EncryptKeyは、セクション3.1.2.1で説明されているように、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で説明されているように）、暗号化されたデータは、[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を表すシリアル化されたOctet文字列と、成功を示すPrivParametersとステータス情報が呼び出しモジュールに返されます。
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オクテットのOctet文字列でない場合、エラー表示（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) 次に、Secret Decryptkeyと64ビット整数を使用して、AES復号化キーとセクション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) 暗号化されたPDUを解読できない場合、エラー表示（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モードのセキュリティは、同じキー[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を導出する手順を定義します。実装では、任意の方法を使用してローカル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の手順は、すべてのメッセージに対して一意のIVを生成するローカル64ビット整数値を変える方法を提案しています。この方法は、単一の権威あるエンジンと通信する複数のマネージャーが誤って同じ64ビット整数を1秒以内に選択する可能性が低いイベントで重複した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.
このAESベースのプライバシープロトコルは、CFB暗号化モードがCiphertextの変更を検出しないため、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].
IANAは、RFC 3411 [RFC3411]で定義されているように、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]からab然と解除されました。著者は、SNMPV3 WGメンバーの多く、特にウェス・ハーデイカー、スティーブ・モールトン、ランディ・プレスフン、デイビッド・タウン、バート・ウィジネンの多くに感謝しています。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 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]「高度な暗号化標準（AES）の仕様」、連邦情報処理標準（FIPS）Publication 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. Schoenwaelder、「管理情報の構造バージョン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.、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.
[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] Presuhn、R.、ed。、「Simple Network Management Protocol（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セキュリティプロトコルの可能性のある平文単位分析」、ネットワークおよび分散型システムセキュリティに関するシンポジウムの議事録、カリフォルニア州サンディエゴ、155-160ページ、1997年2月。
Uri Blumenthal Lucent Technologies / Bell Labs 67 Whippany Rd. 14D-318 Whippany, NJ 07981, USA
Uri Blumenthal Lucent Technologies / Bell Labs 67 Whippany Rd。14D-318 Whippany、NJ 07981、米国
Phone: +1-973-386-2163
EMail: uri@bell-labs.com
Fabio Maino Andiamo Systems, Inc. 375 East Tasman Drive San Jose, CA. 95134 USA
Fabio Maino Andiamo Systems、Inc。375 East Tasman Drive San Jose、CA。95134 USA
Phone: +1-408-853-7530
EMail: fmaino@andiamo.com
Keith McCloghrie Cisco Systems, Inc. 170 East Tasman Drive San Jose, CA. 95134-1706 USA
Keith McCloghrie Cisco Systems、Inc。170 East Tasman Drive San Jose、CA。95134-1706 USA
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。