RFC3826 日本語訳
3826 The Advanced Encryption Standard (AES) Cipher Algorithm in theSNMP User-based Security Model. U. Blumenthal, F. Maino, K.McCloghrie. June 2004. (Format: TXT=32821 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループU.ブルーメンソル要求をネットワークでつないでください: 3826年のルーセントテクノロジーズカテゴリ: 標準化過程F.MainoアンディアモシステムInc.K.McCloghrieシスコシステムズInc.2004年6月
The Advanced Encryption Standard (AES) Cipher Algorithm
in the SNMP User-based Security Model
SNMPユーザベースの機密保護モデルのエー・イー・エス(AES)暗号アルゴリズム
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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 Architectureにおける使用のためのSimple Network Managementプロトコルのバージョン3のためのSecurity SubsystemであるUserベースのSecurity Model(USM)で説明されたプロトコルを補う左右対称の暗号化プロトコルについて説明します。 本書では説明された左右対称の暗号化プロトコルはCipher FeedBack Mode(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. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 目標と規制。 . . . . . . . . . . . . . . . . 2 1.2. 主要なローカライズ. . . . . . . . . . . . . . . . . . . 3 1.3。 パスワードエントロピーとストレージ. . . . . . . . . . . . . 3 2。 定義。 . . . . . . . . . . . . . . . . . . . . . . . . 4 3. CFB128-AES-128の左右対称の暗号化プロトコル. . . . . . . . 5 3.1。 メカニズム. . . . . . . . . . . . . . . . . . . . . . 5 3.1.1。 AESベースの左右対称の暗号化プロトコル. . 6 3.1.2。 キー、AES暗号化キー、および初期設定ベクトル. . . . . . . . . . . . . 7 3.1.3であるとローカライズされます。 データ暗号化. . . . . . . . . . . . . . . . 8 3.1.4。 データ復号. . . . . . . . . . . . . . . . 8
Blumenthal, et al. Standards Track [Page 1] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[1ページ]。
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. AESプライバシープロトコル. . . . . . . . . 9 3.2.1のもののElements。 ユーザ.93.2.2msgAuthoritativeEngineID。 . . . . . . . . . . . 9 3.2.3. SNMP Messages UsingはこのPrivacyプロトコル. . . 10 3.2.4です。 AESプライバシーモジュールで提供されたサービス。 . 10 3.3. 手順のElements。 . . . . . . . . . . . . . . . . 11 3.3.1. 送信されるメッセージを処理します。 . . . . . . . . 12 3.3.2. 入力メッセージを処理します。 . . . . . . . . 12 4. セキュリティ問題。 . . . . . . . . . . . . . . . . . . 13 5. IANA問題。 . . . . . . . . . . . . . . . . . . . . 13 6. 承認. . . . . . . . . . . . . . . . . . . . . . 14 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1。 引用規格. . . . . . . . . . . . . . . . . 14 7.2。 有益な参照. . . . . . . . . . . . . . . . 14 8。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 15 9。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
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.
インターネットManagement Frameworks[RFC3411]について説明するためのArchitectureの中では、SNMPv3のためのUserベースのSecurity Model(USM)[RFC3414]はSNMPエンジンの中にSecurity Subsystemと定義されます。 RFC3414は初期のプライバシープロトコルとして初期の認証プロトコル、およびCBC-DESの使用としてHMAC-MD5-96とHMAC-SHA-96の使用を記述します。 の代わりにする、しかしながら、UserベースのSecurity Modelが、他のそのようなプロトコルが使用されるのを許容する、同時に、これらのプロトコル。
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].
このメモはUserベースのSecurity Modelのために代替のプライバシープロトコルとしてCFB128-AES-128の使用を記述します。 キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.1. Goals and Constraints
1.1. 目標と規制
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.
与えられたユーザのために、RFC3414で定義される認証プロトコルの1つか同等な機能性を提供するアルゴリズム/プロトコルと共にAESベースのプライバシープロトコルを使用しなければなりません。
Blumenthal, et al. Standards Track [Page 2] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[2ページ]。
1.2. Key Localization
1.2. 主要なローカライズ
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組の認証とプライバシーパスワード(そして、その結果1組のキーだけ)しかないかもしれませんが、ローカライズしているキーはユーザUと1台の正式のSNMPエンジンE.Evenの間で共有された秘密鍵です、そして、実際の秘密はユーザを平等に割り当てました、そして、それぞれの正式の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で説明された二段構えの体制によると、主要なローカライズは実行されます。
1.3. Password Entropy and Storage
1.3. パスワードエントロピーとストレージ
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.
- パスワードの長さのSHOULDは少なくともそうです。12の八重奏。 - 禁止されたそうがそのパスワードであったならSHOULDを共有するパスワードが複数のSNMPユーザの中で共有されません。 - 実装SHOULDは、より強いフォームのセキュリティとして手当たりしだいに発生しているパスワードの使用をサポートします。
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]で指定されるようにユーザのパスワードか非ローカライズしているキーが明らかにされると主要なローカライズが助けないで、ネットワークセキュリティが感染されたかもしれないのを覚えている価値があります。 したがって、管理されたデバイス/ノードの上にユーザのパスワードか非ローカライズしているキーを保存してはいけません。 代わりに、デバイスが感染されるといけないのでどんな他のものも管理しなかったように保存されるか(せいぜい)、またはデバイスを管理することであるローカライズしている主要なSHALLは感染されます。
Blumenthal, et al. Standards Track [Page 3] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[3ページ]。
2. Definitions
2. 定義
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定義:、:= SNMPv2-SMIから輸入モジュールアイデンティティ、オブジェクトアイデンティティ、snmpModulesを始めてください--SNMPフレームワークMIBからの[RFC2578]snmpPrivProtocols -- [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"コンタクトインフォメーション「ユリブルーメンソルルーセントテクノロジーズ/ベル研究所67ウィッパニー通り」をアップデートしました。 14D-318ウィッパニー、ニュージャージー 07981、米国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
ファビオMaino AndiamoシステムInc.375の東タスマン・Driveサンノゼ、カリフォルニア 95134、米国408-853-7530 fmaino@andiamo.com
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706, USA
西タスマン・Driveサンノゼ、キースMcCloghrieシスコシステムズ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.
「Object Identitiesの定義がSNMPのUserベースのSecurity ModelによるAESの使用に必要だった」「408-526-5260 kzm@cisco.com 」記述。
Copyright (C) The Internet Society (2004).
Copyright(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モジュールのこのバージョンはRFC3826の一部です。 完全な法定の通知に関してRFC自身を見てください。 「補助情報は http://www.ietf.org/copyrights/ianamib.html で利用可能であるかもしれません。」
Blumenthal, et al. Standards Track [Page 4] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[4ページ]。
REVISION "200406140000Z"
DESCRIPTION "Initial version, published as RFC3826"
「初期のバージョンであって、RFC3826として発行された」REVISION"200406140000Z"記述
::= { snmpModules 20 }
::= snmpModules20
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).
「CFB128-AES-128プライバシーは議定書の中で述べる」usmAesCfb128Protocol OBJECT-IDENTITY STATUSの現在の記述。 参照、「-、エー・イー・エスのための仕様、」 連邦情報処理基準(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 }
- ドーキン、M.、ブロック暗号運転モード、メソッド、およびテクニックのためのNIST推薦。 NISTの特別な公表800-38A(2001年12月)。 " ::= snmpPrivProtocols4
END
終わり
3. CFB128-AES-128 Symmetric Encryption Protocol
3. CFB128-AES-128の左右対称の暗号化プロトコル
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-MODE]で説明されるようにCipher Feedback Modeで使用されるAES暗号アルゴリズム[FIPS-AES]に基づくSymmetric Encryptionプロトコルについて説明します。
This protocol is identified by usmAesCfb128PrivProtocol.
このプロトコルはusmAesCfb128PrivProtocolによって特定されます。
The protocol usmAesCfb128PrivProtocol is an alternative to the privacy protocol defined in [RFC3414].
プロトコルusmAesCfb128PrivProtocolは[RFC3414]で定義されたプライバシープロトコルへの代替手段です。
3.1. Mechanisms
3.1. メカニズム
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.
データの機密性を支持して、暗号化アルゴリズムが必要です。 メッセージの適切な部分は伝えられる前に、暗号化されます。 UserベースのSecurity Modelは、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ビットの整数は、(ローカライズされます)アン/復号化キーと初期化ベクトルを作成するのに使用されます。
Blumenthal, et al. Standards Track [Page 5] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[5ページ]。
3.1.1. The AES-based Symmetric Encryption Protocol
3.1.1. AESベースの左右対称の暗号化プロトコル
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.
このメモで定義されたSymmetric Encryptionプロトコルはデータの機密性のサポートを提供します。 メッセージの一部が受取人に発信したので、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(データ暗号化規格)のためのReplacementとして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.
エー・イー・エスを完全に指定する連邦情報処理基準[FIPS-AES]を含んでいて、AESホームページ( http://www.nist.gov/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暗号の関連特性の記述を含んでいます。
3.1.1.1. Mode of operation
3.1.1.1. 運転モード
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 Publication800-38A[AES-MODE]はAESとの使用のための5つの秘密性運転モードを推薦します: 電子符号表(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.
[AES-MODE]で与えられたCFBモードの定義に従って、このメモで説明された左右対称の暗号化プロトコルはパラメタS(フィードバックされたビットの数)セットでCFBモードでAESを128まで使用します。 このモードは暗号アルゴリズムのブロック・サイズと同じサイズである初期設定Vector(IV)を必要とします。
3.1.1.2. Key Size
3.1.1.2. 主要なサイズ
In the encryption protocol described by this memo AES is used with a key size of 128 bits, as recommended in [AES-MODE].
このメモで説明された暗号化プロトコルでは、AESは128ビットの主要なサイズと共に使用されます、[AES-MODE]で推薦されるように。
3.1.1.3. Block Size and Padding
3.1.1.3. ブロック・サイズと詰め物
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暗号アルゴリズムのブロック・サイズは128ビットです、[AES- MODE]で推薦されるように。
Blumenthal, et al. Standards Track [Page 6] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[6ページ]。
3.1.1.4. Rounds
3.1.1.4. ラウンド
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ラウンドを使用します。
3.1.2. Localized Key, AES Encryption Key, and Initialization Vector
3.1.2. キーと、AES暗号化キーと、初期設定ベクトルであるとローカライズされます。
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ユーザのLocalized Key(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]で説明された認証プロトコルはこの要件を満たします。
3.1.2.1. AES Encryption Key and IV
3.1.2.1. AES暗号化キーとIV
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暗号化キーとして使用されます。 正式のSNMPエンジンの32ビットのsnmpEngineBoots、SNMPエンジンの32ビットのsnmpEngineTime、および地方の64ビットの整数の連結として128ビットのIVを得ます。 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つの八重奏(ほとんどのSignificant Byte1番目)に変換されます、そして、32ビットのsnmpEngineTimeはその後の4つの八重奏(ほとんどのSignificant Byte1番目)に変換されます、そして、次に、64ビットの整数はベスト8八重奏(ほとんどのSignificant Byte1番目)に変換されます。 そして、長さの8八重奏のOCTET STRINGとしてコード化されたmsgPrivacyParameters分野に64ビットの整数を入れます。 そして、整数はその後のメッセージのために変更されます。 それが最大値(それはそれの時に包装される)に達するまで、私たちは、それが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は複数のマネージャ、単一の正式のエンジンによる交信が1秒以内に偶然ともに同じ64ビットの整数に選択する非常にありそうもないイベントをもたらすことができます。 そのようなイベントの確率は、非常に低く、提案されたメカニズムの丈夫さにかなり影響しません。
Blumenthal, et al. Standards Track [Page 7] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[7ページ]。
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.
受信実体が正しいIVを計算して、メッセージを解読するのを可能にするために64ビットの整数を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を作成するのに使用される個々のコンポーネントの同じ値を使用しなければならないことに注意してください。 特に、送付者と受信機必須の両方が関連メッセージ(msgAuthoritativeEngineBoots、msgAuthoritativeEngineTime、およびprivParametersがそれぞれさばくコネ)に含まれているsnmpEngineBoots、snmpEngineTime、および64ビットの整数の値を使用します。
3.1.3. Data Encryption
3.1.3. データ暗号化
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にCipher Feedbackモードで暗号化されます。 [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に適用されます。 最初の暗号文ブロックは排他的なORingによって生産されて、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.
最後の暗号文ブロックは排他的なORingによって作り出されます。最後に出力されたブロックのr最上位ビットのセグメントがあるrビット(rは128以下である)の最後の平文セグメント。
3.1.4. Data Decryption
3.1.4. データ復号
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番目の入力ブロックに使用されますなど。 前進の暗号関数は、出力ブロックを作り出すためにそれぞれの入力ブロックに適用されます。 出力ブロックは平文ブロックを回収する対応する暗号文ブロックがある排他的なORedです。
Blumenthal, et al. Standards Track [Page 8] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[8ページ]。
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最上位ビットのセグメントがある排他的なORedです。
3.2. Elements of the AES Privacy Protocol
3.2. AESプライバシープロトコルのElements
This section contains definitions required to realize the privacy modules defined by this memo.
このセクションはこのメモで定義されたプライバシーモジュールがわかるのに必要である定義を含みます。
3.2.1. Users
3.2.1. ユーザ
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.
このSymmetric Encryptionプロトコルを使用するデータアン/復号化がuserNamesの定義されたセットを利用します。 メッセージがに代わっているに違いないどんなユーザに関してはも、その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>An八重奏ストリング。
<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>。
3.2.2. msgAuthoritativeEngineID
3.2.2. msgAuthoritativeEngineID
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 Architectureドキュメント[RFC3411]のSnmpEngineIDの定義を見てください)。
Blumenthal, et al. Standards Track [Page 9] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[9ページ]。
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はアン/復号化プロセスのために適切なキーを選択するのに使用されます。
3.2.3. SNMP Messages Using this Privacy Protocol
3.2.3. SNMP Messages UsingはこのPrivacyプロトコルです。
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です。
3.2.4. Services provided by the AES Privacy Modules
3.2.4. AESプライバシーモジュールで提供されたサービス
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.
UserベースのSecurityモジュールがサービスのためのAES Privacyモジュールの1つを呼び出すとき、このセクションはAES Privacyモジュールが予想して、作り出す入力と出力について説明します。
3.2.4.1. Services for Encrypting Outgoing Data
3.2.4.1. 発信データを暗号化するためのサービス
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:
完成のときに、プライバシーモジュールは暗号化プロセスがうまくいったときのOCTET STRINGとしてコード化されたstatusInformation、encryptedPDU、およびmsgPrivacyParametersを返します。 抽象的なサービス基関数は以下の通りです。
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(IN 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.
暗号化プロセスの成否のstatusInformation Anしるし。 失敗の場合には、それは誤りのしるしです。
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、暗号化しなければならないデータ。
Blumenthal, et al. Standards Track [Page 10] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[10ページ]。
encryptedData
The encrypted data upon successful completion.
encryptedData、無事終了に関する暗号化されたデータ。
privParameters
The privParameters encoded as an OCTET STRING.
privParametersがOCTET STRINGとしてコード化したprivParameters。
3.2.4.2. Services for Decrypting Incoming Data
3.2.4.2. 受信データを解読するためのサービス
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:
完成のときに、プライバシーモジュールはプレーンテキストで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)
)
statusInformationはdecryptDataと等しいです。(データ(scopedPDU)であると解読されたワイヤIN encryptedData(暗号化されたデータ(encryptedPDU)OUT decryptedData)に受け取られるIN decryptKey(復号化IN privParametersのための秘密鍵))
The abstract data elements are:
抽象的なデータ要素は以下の通りです。
statusInformation
An indication of whether the data was successfully decrypted, and
if not, an indication of the error.
そして、データが首尾よく解読されたかどうかstatusInformation Anしるし、そうでなければ、誤りのしるし。
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、解読されたデータ。
3.3. Elements of Procedure
3.3. 手順のElements
This section describes the procedures for the AES privacy protocol for SNMP's User-based Security Model.
このセクションはSNMPのUserベースのSecurity ModelのためのAESプライバシープロトコルのために手順について説明します。
Blumenthal, et al. Standards Track [Page 11] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[11ページ]。
3.3.1. Processing an Outgoing Message
3.3.1. 送信されるメッセージを処理します。
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) 秘密のencryptKeyは、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分野はセクション3.1.2で.1に説明されるようにIVで使用される64ビットの整数を表すOCTET STRINGの[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]の規則に従って、暗号化されたデータはOCTET STRINGとして連載されます。
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を呼ぶモジュールに返します。
3.3.2. Processing an Incoming Message
3.3.2. 入力メッセージを処理します。
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 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) そして、セクション3.1.2で.1に説明されて、秘密のdecryptKeyと64ビットの整数は、AES復号化キーとそれが計算されるIVを組み立てるのに使用されます。
4) The encryptedPDU is then decrypted (as described in section
3.1.4).
4) そして、encryptedPDUは解読されます(セクション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とstatusInformationを呼ぶモジュールに返します。
Blumenthal, et al. Standards Track [Page 12] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[12ページ]。
4. Security Considerations
4. セキュリティ問題
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.3SHOULDで続かれてください。推薦、選択されたパスワードに最大のエントロピーを確実にして、保存されている間、パスワードを保護するために。
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 ブート時間でIVを(塩)が初期化した地方の64ビットの整数から擬似ランダム値まで引き出すために手順を定義します。 実装は地方の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.
.1がメソッドを示すセクション3.1.2の手順はあらゆるメッセージのためにユニークなIVsを生成する地方の64ビットの整数値を変えます。 このメソッドは複数のマネージャ、単一の正式のエンジンによる交信が1秒以内に偶然ともに同じ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.
RFC3414で定義される認証プロトコルの1つか同等な機能性を提供するアルゴリズム/プロトコルと共にこのAESベースのプライバシープロトコルを使用しなければなりません(保全を含んでいて)、CFB暗号化モードが暗号文変更を検出しないので。
For further security considerations, the reader is encouraged to read [RFC3414], and the documents that describe the actual cipher algorithms.
さらなるセキュリティ問題において、読者が[RFC3414]、および実際の暗号アルゴリズムを説明するドキュメントを読むよう奨励されます。
5. IANA Considerations
5. IANA問題
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はsnmpUsmAesMIBモジュールのために http://www.iana.org/assignments/smi-numbers での登録で維持されたsnmpModules下位木の下でOID20を割り当てました。
IANA has assigned OID 4 for the usmAesCfb128Protocol under the snmpPrivProtocols registration point, as defined in RFC 3411 [RFC3411].
IANAはsnmpPrivProtocols登録ポイントの下のusmAesCfb128ProtocolのためにRFC3411[RFC3411]で定義されるようにOID4を割り当てました。
Blumenthal, et al. Standards Track [Page 13] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[13ページ]。
6. Acknowledgements
6. 承認
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]から平気で撤廃されました。 作者は彼らの助け、特にウェスHardaker、スティーブ・モールトン、ランディPresuhn、デヴィッドTown、およびバートWijnenにSNMPv3 WGメンバーの多くに感謝しています。 スティーブBellovinとのセキュリティ議論は、このプロトコルを能率化するのを助けました。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[AES-MODE] Dworkin, M., "NIST Recommendation for Block Cipher Modes
of Operation, Methods and Techniques", NIST Special
Publication 800-38A, December 2001.
[AES-モード] ドーキン、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] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(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] ハリントンとD.とPresuhnとR.とB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411、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]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、STD62、RFC3414、2002年12月。
[RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3417,
December 2002.
[RFC3417] Presuhn、R.、エド、「簡単なネットワーク管理プロトコル(SNMP)のための輸送マッピング」、STD62、RFC3417、12月2002日
7.2. Informative References
7.2. 有益な参照
[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セキュリティー・プロトコルのありえそうな平文暗号文解読術」、Networkの上のSymposiumとDistributed System Security、サンディエゴ(カリフォルニア)のページのProceedings 155-160と、1997年2月。
Blumenthal, et al. Standards Track [Page 14] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[14ページ]。
8. Authors' Addresses
8. 作者のアドレス
Uri Blumenthal Lucent Technologies / Bell Labs 67 Whippany Rd. 14D-318 Whippany, NJ 07981, USA
ユリブルーメンソルルーセントテクノロジーズ/ベル研究所67ウィッパニー通り 14D-318ウィッパニー、ニュージャージー 07981、米国
Phone: +1-973-386-2163 EMail: uri@bell-labs.com
以下に電話をしてください。 +1-973-386-2163 メールしてください: uri@bell-labs.com
Fabio Maino Andiamo Systems, Inc. 375 East Tasman Drive San Jose, CA. 95134 USA
ファビオMainoアンディアモSystemsのInc.375の東タスマン・Driveサンノゼ(カリフォルニア)。 95134 米国
Phone: +1-408-853-7530 EMail: fmaino@andiamo.com
以下に電話をしてください。 +1-408-853-7530 メールしてください: fmaino@andiamo.com
Keith McCloghrie Cisco Systems, Inc. 170 East Tasman Drive San Jose, CA. 95134-1706 USA
キースMcCloghrieシスコシステムズInc.170の東タスマン・Driveサンノゼ(カリフォルニア)。 95134-1706 米国
Phone: +1-408-526-5260 EMail: kzm@cisco.com
以下に電話をしてください。 +1-408-526-5260 メールしてください: kzm@cisco.com
Blumenthal, et al. Standards Track [Page 15] RFC 3826 AES for SNMP's USM June 2004
ブルーメンソル、他 規格は2004年6月にSNMPのUSMのためにRFC3826AESを追跡します[15ページ]。
9. Full Copyright Statement
9. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Blumenthal, et al. Standards Track [Page 16]
ブルーメンソル、他 標準化過程[16ページ]
一覧
スポンサーリンク
