RFC5282 日本語訳
5282 Using Authenticated Encryption Algorithms with the EncryptedPayload of the Internet Key Exchange version 2 (IKEv2) Protocol. D.Black, D. McGrew. August 2008. (Format: TXT=42137 bytes) (Updates RFC4306) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Black Request for Comments: 5282 EMC Updates: 4306 D. McGrew Category: Standards Track August 2008
コメントを求めるワーキンググループのD.の黒い要求をネットワークでつないでください: 5282のEMCアップデート: 4306年のD.マグリューカテゴリ: 標準化過程2008年8月
Using Authenticated Encryption Algorithms with the Encrypted Payload
of the Internet Key Exchange version 2 (IKEv2) Protocol
インターネット・キー・エクスチェンジバージョン2(IKEv2)プロトコルのEncrypted有効搭載量があるAuthenticated Encryption Algorithmsを使用します。
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol.
認証された暗号化アルゴリズムは暗号化と保全をただ一つの操作に結合します。 また、暗号化暗号か結合したモードアルゴリズムこのドキュメントがインターネット・キー・エクスチェンジバージョン2(IKEv2)プロトコルのEncrypted有効搭載量との認証された暗号化アルゴリズムの使用について説明するとき、そのようなアルゴリズムは結合したモードと呼ばれるかもしれません。
The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload.
また、IKEv2 Encrypted有効搭載量との2つの特定の認証された暗号化アルゴリズムの使用は説明されます。 これらの2つのアルゴリズムが、ガロア/カウンタMode(AES GCM)のエー・イー・エス(AES)とCBC-MAC ModeとCounterのAES(AES CCM)です。 追加ドキュメントはIKEv2 Encrypted有効搭載量との他の認証された暗号化アルゴリズムの使用について説明するかもしれません。
Black & McGrew Standards Track [Page 1] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[1ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Structure of this Document ......................................4
3. IKEv2 Encrypted Payload Data ....................................4
3.1. AES GCM and AES CCM Initialization Vector (IV) .............6
3.2. AES GCM and AES CCM Ciphertext (C) Construction ............6
4. AES GCM and AES CCM Nonce (N) Format ............................7
5. IKEv2 Associated Data (A) .......................................8
5.1. Associated Data (A) Construction ...........................8
5.2. Data Integrity Coverage ....................................8
6. AES GCM and AES CCM Encrypted Payload Expansion .................9
7. IKEv2 Conventions for AES GCM and AES CCM .......................9
7.1. Keying Material and Salt Values ............................9
7.2. IKEv2 Identifiers .........................................10
7.3. Key Length ................................................10
8. IKEv2 Algorithm Selection ......................................11
9. Test Vectors ...................................................11
10. RFC 5116 AEAD_* Algorithms ....................................11
10.1. AES GCM Algorithms with 8- and 12-octet ICVs .............12
10.1.1. AEAD_AES_128_GCM_8 ................................12
10.1.2. AEAD_AES_256_GCM_8 ................................12
10.1.3. AEAD_AES_128_GCM_12 ...............................12
10.1.4. AEAD_AES_256_GCM_12 ...............................12
10.2. AES CCM Algorithms with an 11-octet Nonce ................13
10.2.1. AEAD_AES_128_CCM_SHORT ............................13
10.2.2. AEAD_AES_256_CCM_SHORT ............................14
10.2.3. AEAD_AES_128_CCM_SHORT_8 ..........................14
10.2.4. AEAD_AES_256_CCM_SHORT_8 ..........................14
10.2.5. AEAD_AES_128_CCM_SHORT_12 .........................14
10.2.6. AEAD_AES_256_CCM_SHORT_12 .........................14
10.3. AEAD_* Algorithms and IKEv2 ..............................15
11. Security Considerations .......................................15
12. IANA Considerations ...........................................16
13. Acknowledgments ...............................................16
14. References ....................................................17
14.1. Normative References .....................................17
14.2. Informative References ...................................17
1. 序論…3 1.1. このドキュメントで中古のコンベンション…3 2. このDocumentの構造…4 3. IKEv2は有効搭載量データをコード化しました…4 3.1. AES GCMとAES立方センチメートル初期設定ベクトル(IV)…6 3.2. AES GCMとAES立方センチメートル暗号文(C)工事…6 4. AES GCMとAES立方センチメートル一回だけ(N)形式…7 5. IKEv2はデータ(A)を関連づけました…8 5.1. 関連データ(A)工事…8 5.2. データの保全適用範囲…8 6. AES GCMとAES立方センチメートルは有効搭載量拡大をコード化しました…9 7. AES GCMのためのIKEv2コンベンションとAES立方センチメートル…9 7.1. 材料と塩の値を合わせます…9 7.2. IKEv2識別子…10 7.3. キー長…10 8. IKEv2アルゴリズム選択…11 9. ベクトルをテストしてください…11 10. RFC5116AEAD_*アルゴリズム…11 10.1. 8があるAES GCMアルゴリズムと12八重奏のICVs…12 10.1.1. AEAD_AES_128_GCM_8…12 10.1.2. AEAD_AES_256_GCM_8…12 10.1.3. AEAD_AES_128_GCM_12…12 10.1.4. AEAD_AES_256_GCM_12…12 10.2. 11八重奏の一回だけがあるAES立方センチメートルアルゴリズム…13 10.2.1. AEAD_AES_128_立方センチメートル_短い…13 10.2.2. AEAD_AES_256_立方センチメートル_短い…14 10.2.3. AEAD_AES_128_立方センチメートル_の短い_8…14 10.2.4. AEAD_AES_256_立方センチメートル_の短い_8…14 10.2.5. AEAD_AES_128_立方センチメートル_の短い_12…14 10.2.6. AEAD_AES_256_立方センチメートル_の短い_12…14 10.3. AEAD_*アルゴリズムとIKEv2…15 11. セキュリティ問題…15 12. IANA問題…16 13. 承認…16 14. 参照…17 14.1. 標準の参照…17 14.2. 有益な参照…17
Black & McGrew Standards Track [Page 2] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[2ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
1. Introduction
1. 序論
An authenticated encryption algorithm combines encryption and integrity into a single operation on plaintext data to produce ciphertext that includes an integrity check [RFC5116]. The integrity check may be an Integrity Check Value (ICV) that is logically distinct from the encrypted data, or the integrity check may be incorporated into the encrypted data that is produced. Authenticated encryption algorithms may also be referred to as combined modes of operation of a block cipher or as combined mode algorithms.
認証された暗号化アルゴリズムは、保全チェック[RFC5116]を含んでいる暗号文を生産するために平文データで暗号化と保全をただ一つの操作に結合します。 保全チェックはコード化されたデータと論理的に異なったIntegrity Check Valueであるかもしれません(ICV)か保全チェックが作り出されるコード化されたデータに組み入れられるかもしれません。 また、ブロック暗号の結合した運転モードと呼ばれるか、結合したモードアルゴリズムとして認証された暗号化アルゴリズムがあるかもしれません。
An Authenticated Encryption with Associated Data (AEAD) algorithm also provides integrity protection for additional data that is associated with the plaintext, but which is left unencrypted. This document describes the use of AEAD algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol. The use of two specific AEAD algorithms with the IKEv2 Encrypted Payload is also described; the two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) [GCM] and AES in Counter with CBC-MAC Mode (AES CCM) [CCM].
また、Associated Data(AEAD)アルゴリズムがあるAuthenticated Encryptionは平文に関連していますが、非コード化されるように残される追加データのための保全保護を提供します。 このドキュメントはインターネット・キー・エクスチェンジバージョン2(IKEv2)プロトコルのEncrypted有効搭載量とのAEADアルゴリズムの使用について説明します。 また、IKEv2 Encrypted有効搭載量との2つの特定のAEADアルゴリズムの使用は説明されます。 2つのアルゴリズムが、ガロア/カウンタMode(AES GCM)[GCM]のエー・イー・エス(AES)とCBC-MAC Mode(AES CCM)とCounterのAES[CCM]です。
Version 1 of the Internet Key Exchange protocol (IKEv1) [RFC2409] is based on the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. The E (Encryption) bit in the ISAKMP header specifies that all payloads following the header are encrypted, but any data integrity verification of those payloads is handled by a separate Hash Payload or Signature Payload (see Sections 3.1, 3.11, and 3.12 of [RFC2408]). This separation of encryption from data integrity protection prevents the use of authenticated encryption with IKEv1, thus limiting initial specifications of AES combined mode usage for IPsec to the Encapsulating Security Payload (ESP) [RFC2406]. The current version of ESP is version 3, ESPv3 [RFC4303].
インターネット・キー・エクスチェンジプロトコル(IKEv1)[RFC2409]のバージョン1はインターネットSecurity AssociationとKey Managementプロトコル(ISAKMP)[RFC2408]に基づいています。 ISAKMPヘッダーのE(暗号化)ビットは、ヘッダーに続くすべてのペイロードがコード化されていると指定しますが、それらのペイロードのどんなデータ保全検証も別々のHash有効搭載量かSignature有効搭載量によって扱われます([RFC2408]のセクション3.1、3.11、および3.12を見てください)。 データ保全保護からの暗号化のこの分離はIKEv1との認証された暗号化の使用を防いで、その結果、AESの制限の初期の仕様はEncapsulating Security有効搭載量(超能力)[RFC2406]へのIPsecのための結合したモード用法です。 超能力の最新版はバージョン3、ESPv3[RFC4303]です。
Version 2 of the Internet Key Exchange Protocol (IKEv2) [RFC4306] employs an Encrypted Payload that is based on the design of ESP. The IKEv2 Encrypted Payload associates encryption and data integrity protection in a fashion that makes it possible to use AEAD algorithms.
インターネット・キー・エクスチェンジプロトコル(IKEv2)[RFC4306]のバージョン2は超能力のデザインに基づいているEncrypted有効搭載量を使います。 IKEv2 Encrypted有効搭載量はAEADアルゴリズムを使用するのを可能にするファッションで暗号化とデータ保全保護を関連づけます。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The symbols or variables that designate authenticated encryption and decryption operation inputs and outputs (K, N, P, A, and C) are
入力と出力(K、N、P、A、およびC)に認証された暗号化と復号化操作を指定するシンボルか変数がそうです。
Black & McGrew Standards Track [Page 3] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[3ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
defined in [RFC5116]. The SK_* symbols or variables that designate specific IKEv2 keys are defined in [RFC4306].
[RFC5116]では、定義されます。 特定のIKEv2キーを指定するSK_*シンボルか変数が[RFC4306]で定義されます。
2. Structure of this Document
2. このDocumentの構造
This document is based on the RFCs that describe the usage of AES GCM [RFC4106] and AES CCM [RFC4309] with ESP; hence, the introductory material and specification of the modes in those documents are not repeated here. The structure of this document follows the structure of those documents; many sections of this document indicate which sections of those two documents correspond, and call out any significant differences that implementers should be aware of. Significant portions of the text of this document have been adapted from those two documents.
このドキュメントは超能力でAES GCM[RFC4106]とAES CCM[RFC4309]の使用法を説明するRFCsに基づいています。 したがって、それらのドキュメントのモードの紹介している材料と仕様はここで繰り返されません。 このドキュメントの構造はそれらのドキュメントの構造に従います。 このドキュメントの多くのセクションが、それらの2通のドキュメントのどのセクションが対応するかを示して、implementersが意識しているべきであるどんな著しい違いも呼び出します。 このドキュメントの原本の重要な部分はそれらの2通のドキュメントから適合させられました。
This document is based on the authenticated encryption interfaces, notation, and terminology described in [RFC5116]. An important departure from [RFC4106] and [RFC4309] is that these two RFCs describe separate ciphertext and integrity check outputs of the encryption operation, whereas [RFC5116] specifies a single ciphertext (C) output that includes an integrity check. The latter more general approach encompasses authenticated encryption algorithms that produce a single, expanded ciphertext output into which the integrity check is incorporated, rather than producing separate ciphertext and integrity check outputs.
このドキュメントはインタフェース、記法、および用語が[RFC5116]で説明した認証された暗号化に基づいています。 [RFC4106]と[RFC4309]からの重要な出発はこれらの2RFCsが暗号化操作の別々の暗号文と保全チェック出力について説明しますが、[RFC5116]が保全チェックを含んでいるただ一つの暗号文(C)出力を指定するということです。 後者の、より一般的なアプローチは保全チェックが別々の暗号文を生産するよりむしろ法人組織であるただ一つの、そして、拡張している暗号文出力と保全チェック出力を起こす認証された暗号化アルゴリズムを包含します。
For AES GCM and AES CCM, the [RFC5116] ciphertext (C) output of authenticated encryption consists of the [RFC4106] or [RFC4309] ciphertext output concatenated with the [RFC4106] or [RFC4309] Integrity Check Value (ICV) output. This document does not modify the AES GCM or AES CCM authenticated encryption algorithms specified in [RFC4106] and [RFC4309].
AES GCMとAES CCMに関しては、認証された暗号化の[RFC5116]暗号文(C)出力は[RFC4106]か[RFC4309]保全Check Value(ICV)出力で連結された[RFC4106]か[RFC4309]暗号文出力から成ります。 このドキュメントは認証された暗号化アルゴリズムが[RFC4106]と[RFC4309]で指定したAES GCMかAES CCMを変更しません。
3. IKEv2 Encrypted Payload Data
3. IKEv2は有効搭載量データをコード化しました。
This section is based on [RFC5116] and Section 3.14 of [RFC4306].
このセクションは[RFC4306]の[RFC5116]とセクション3.14に基づいています。
For the use of authenticated encryption algorithms with the IKEv2 Encrypted Payload, this section updates Section 3.14 of [RFC4306] by replacing Figure 21 and the text that follows it (through the end of that section) with the contents of this section. In addition, Section 3.14 of [RFC4306] is also updated to allow the use of a single authenticated encryption algorithm instead of a block cipher and a separate integrity check algorithm. In contrast, Sections 3.1 and 3.2 of this document are specific to the AES GCM and AES CCM algorithms and hence do not update [RFC4306]. The updates to [RFC4306] made by this document have no effect when authenticated encryption algorithms are neither proposed nor used.
IKEv2 Encrypted有効搭載量との認証された暗号化アルゴリズムの使用のために、このセクションは、このセクションのコンテンツでそれ(そのセクションの端までの)に続く図21とテキストを置き換えることによって、[RFC4306]のセクション3.14をアップデートします。 また、さらに、ブロック暗号の代わりにただ一つの認証された暗号化アルゴリズムと別々の保全チェックアルゴリズムの使用を許すために[RFC4306]のセクション3.14をアップデートします。 対照的に、このドキュメントのセクション3.1と3.2は、AES GCMとAES CCMアルゴリズムに特定であり、したがって、[RFC4306]をアップデートしません。 認証された暗号化アルゴリズムが提案されないで、また使用されないとき、このドキュメントによって作られた[RFC4306]へのアップデートは効き目がありません。
Black & McGrew Standards Track [Page 4] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[4ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
The IKEv2 Encrypted Payload Data structure applies to all
authenticated encryption algorithms, and it is the same structure
that is used with ESP. When an authenticated encryption algorithm is
used, the IKEv2 Encrypted Payload is composed of the payload header
fields, followed by an Initialization Vector (IV) field and a
Ciphertext (C) field that includes an integrity check as shown in
Figure 1.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initialization Vector !
! (length is specified by authenticated encryption algorithm) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ciphertext ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IKEv2 Encrypted有効搭載量Data構造はすべての認証された暗号化アルゴリズムに適用されます、そして、それは超能力と共に使用される同じ構造です。 認証された暗号化アルゴリズムが使用されているとき、IKEv2 Encrypted有効搭載量は初期設定Vector(IV)分野と図1に示されるように保全チェックを含んでいるCiphertext(C)分野があとに続いたペイロードヘッダーフィールドで構成されます。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 有効搭載量..初期設定..長さ..指定..認証..暗号化..アルゴリズム
Figure 1. IKEv2 Encrypted Payload Data for Authenticated Encryption
図1。 IKEv2は認証された暗号化のための有効搭載量データをコード化しました。
The Next Payload, C bit, and Payload Length fields are unchanged from [RFC4306].
Next有効搭載量、Cビット、および有効搭載量Length分野は[RFC4306]から変わりがありません。
The contents of the Initialization Vector (IV) field are specified by the authenticated encryption algorithm; see Sections 3.1 and 4 (below) for AES GCM and AES CCM.
初期設定Vector(IV)分野の内容は認証された暗号化アルゴリズムで指定されます。 AES GCMとAES CCMに関してセクション3.1と4(below)を見てください。
The Ciphertext field is the output of an authenticated encryption operation (see Section 2.1 of [RFC5116]) on the following inputs:
以下の入力のときにCiphertext分野は認証された暗号化操作([RFC5116]のセクション2.1を見る)の出力です:
o The secret key (K) is the cipher key obtained from the SK_ei or
SK_er key, whichever is appropriate, see [RFC4306]. The
authenticated encryption algorithm describes how to obtain the
cipher key from SK_ei or SK_er; for AES GCM and AES CCM, see
Section 7.1 (below).
o 秘密鍵(K)がSK_eiかSK_から入手された暗号キーである、えー、どれが適切であっても、キーは[RFC4306]を見ます。 認証された暗号化アルゴリズムがSK_eiかSK_から主要な暗号を得る方法を説明する、えー。 AES GCMとAES CCMに関しては、セクション7.1(below)を見てください。
o The nonce (N) is specified by the authenticated encryption
algorithm; for AES GCM and AES CCM, see Section 4 (below). When
decrypting an Encrypted Payload, a receiver constructs the nonce
based on the IV in the Encrypted Payload, using rules that are
specific to the authenticated encryption algorithm; see Sections
3.1 and 4 (below) for AES GCM and AES CCM.
o 一回だけ(N)は認証された暗号化アルゴリズムで指定されます。 AES GCMとAES CCMに関しては、セクション4(below)を見てください。 Encrypted有効搭載量を解読するとき、受信機はEncrypted有効搭載量におけるIVに基づく一回だけを組み立てます、認証された暗号化アルゴリズムに特定の規則を使用して。 AES GCMとAES CCMに関してセクション3.1と4(below)を見てください。
o The plaintext (P) consists of the concatenation of the IKE
Payloads to be encrypted with the Padding (if any) and the Pad
Length, as shown in Figure 2 (below). The plaintext structure in
Figure 2 applies to all encryption algorithms used with the IKEv2
Encrypted Payload, and is unchanged from [RFC4306].
o 平文(P)はPadding(もしあれば)とPad Lengthと共にコード化されるためにIKE有効搭載量の連結から成ります、図2(below)に示されるように。 図2の平文構造は、IKEv2 Encrypted有効搭載量と共に使用されるすべての暗号化アルゴリズムに適用して、[RFC4306]から変わりがありません。
Black & McGrew Standards Track [Page 5] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[5ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
o The associated data (A) is described in Section 5 (below).
o 関連データ(A)はセクション5(below)で説明されます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IKE Payloads to be Encrypted ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! Padding (0-255 octets) !
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
! ! Pad Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
有効搭載量..八重奏
Figure 2. IKEv2 Encrypted Payload Plaintext (P)
図2。 IKEv2は有効搭載量平文をコード化しました。(p)
The IKE Payloads are as specified in [RFC4306].
IKE有効搭載量が[RFC4306]で指定されるようにあります。
Padding MAY contain any value chosen by the sender.
詰め物は送付者によって選ばれたどんな値も含むかもしれません。
Pad Length is the number of octets in the Padding field. There are no alignment requirements on the length of the Padding field; the recipient MUST accept any amount of Padding up to 255 octets.
パッドLengthはPadding分野の八重奏の数です。 整列要求が全くPadding分野の長さにありません。 受取人はどんな量のPadding最大255八重奏も受け入れなければなりません。
The ciphertext output of authenticated encryption algorithms, as defined by [RFC5116], incorporates data that allows checks on the integrity and authenticity of the ciphertext and associated data. Thus, there is no need for a separate Integrity Check Value (ICV) field in the IKEv2 Encrypted Payload Data structure.
[RFC5116]によって定義される認証された暗号化アルゴリズムの暗号文出力は暗号文の保全と信憑性のチェックを許すデータと関連データを取り入れます。 したがって、別々のIntegrity Check Value(ICV)分野の必要は全くIKEv2 Encrypted有効搭載量Data構造にありません。
3.1. AES GCM and AES CCM Initialization Vector (IV)
3.1. AES GCMとAES立方センチメートル初期設定ベクトル(IV)
This section is based on Section 3.1 of [RFC4106] and Section 3.1 of [RFC4309]. The Initialization Vector requirements are common to AES GCM and AES CCM, and are the same as the requirements for ESP.
このセクションは[RFC4106]のセクション3.1と[RFC4309]のセクション3.1に基づいています。 初期設定Vector要件は、AES GCMとAES CCMに共通であり、超能力のための要件と同じです。
The Initialization Vector (IV) MUST be eight octets. The IV MUST be chosen by the encryptor in a manner that ensures that the same IV value is used only once for a given key. The encryptor MAY generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs).
初期設定Vector(IV)は8つの八重奏であるに違いありません。 暗号化する人は同じIV値が与えられたキーに一度だけ使用されるのを確実にする方法でIVを選ばなければなりません。 暗号化する人はユニークさを確実にするどんな方法でもIVを発生させるかもしれません。 IV世代への一般的なアプローチは、各パケットと直線的なフィードバック・シフト・レジスタ(LFSRs)のためにカウンタを増加するのを含んでいます。
3.2. AES GCM and AES CCM Ciphertext (C) Construction
3.2. AES GCMとAES立方センチメートル暗号文(C)工事
This section is based on Section 6 of [RFC4106] and Section 3.1 of [RFC4309] with generalizations to match the interfaces specified in [RFC5116]. The constructions for AES GCM and AES CCM are different, but in each case, the construction is the same as for ESP.
このセクションは一般化で[RFC4106]のセクション6と[RFC4309]のセクション3.1に基づいていて、[RFC5116]で指定されたインタフェースを合わせます。 AES GCMとAES CCMのための構造は異なっていますが、その都度、工事は超能力のように同じです。
Black & McGrew Standards Track [Page 6] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[6ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
For AES GCM and AES CCM, the Ciphertext field consists of the output of the authenticated encryption algorithm. (Note that this field incorporates integrity check data.)
AES GCMとAES CCMに関しては、Ciphertext分野は認証された暗号化アルゴリズムの出力から成ります。 (この分野が保全チェックデータを取り入れることに注意してください。)
The AES GCM ICV consists solely of the AES GCM Authentication Tag. Implementations MUST support a full-length 16 octet ICV, MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths.
AES GCM ICVは唯一AES GCM Authentication Tagから成ります。 実現は、等身大の16八重奏ICVを支持しなければならなくて、8か12八重奏ICVsを支持するかもしれなくて、他のICVの長さは支持してはいけません。
AES CCM provides an encrypted ICV. Implementations MUST support ICV sizes of 8 octets and 16 octets. Implementations MAY also support 12 octet ICVs and MUST NOT support other ICV lengths.
AES CCMはコード化されたICVを提供します。 実現は8つの八重奏と16の八重奏のICVサイズを支持しなければなりません。 実現は、また、12八重奏ICVsを支持するかもしれなくて、他のICVの長さは支持してはいけません。
4. AES GCM and AES CCM Nonce (N) Format
4. AES GCMとAES立方センチメートル一回だけ(N)形式
Specific authenticated encryption algorithms MAY use different nonce formats, but they SHOULD use the default nonce format specified in this section.
特定の認証された暗号化アルゴリズムは異なった一回だけの形式を使用するかもしれなくて、唯一のそれらはデフォルト一回だけ形式がこのセクションで指定したSHOULD使用です。
The default nonce format uses partially implicit nonces (see Section 3.2.1 of [RFC5116]) as follows:
デフォルト一回だけ形式は以下の部分的に暗黙の一回だけ(.1セクション3.2[RFC5116]を見る)を使用します:
o The implicit portion of the nonce is the salt that is part of the
IKEv2 Keying Material shared by the encryptor and decryptor (see
Section 7.1); the salt is not included in the IKEv2 Encrypted
Payload.
o 一回だけの暗黙の部分は暗号化する人によって共有されたIKEv2 Keying Materialとdecryptorの一部である塩(セクション7.1を見る)です。 塩はIKEv2 Encrypted有効搭載量に含まれていません。
o The explicit portion of the nonce is the IV that is included in
the IKEv2 Encrypted Payload.
o 一回だけの明白な部分はIKEv2 Encrypted有効搭載量に含まれているIVです。
When this default nonce format is used, both the encryptor and decryptor construct the nonce by concatenating the salt with the IV, in that order.
このデフォルト一回だけであるときに、形式が使用されている、暗号化する人とdecryptorの両方がIVと共に塩を連結することによって、一回だけを組み立てます、そのオーダーで。
For the use of AES GCM with the IKEv2 Encrypted Payload, this default nonce format MUST be used and a 12 octet nonce MUST be used. Note that this format matches the one specified in Section 4 of [RFC4106], providing compatibility between the use of AES GCM in IKEv2 and ESP. All of the requirements of Section 4 of [RFC4106] apply to the use of AES GCM with the IKEv2 Encrypted Payload.
IKEv2 Encrypted有効搭載量とのAES GCMの使用のために、このデフォルト一回だけ形式を使用しなければなりません、そして、12八重奏一回だけを使用しなければなりません。 この形式が[RFC4106]のセクション4で指定されたものに合っていることに注意してください、IKEv2と超能力におけるAES GCMの使用の間の互換性を提供して。 [RFC4106]のセクション4の要件のすべてがIKEv2 Encrypted有効搭載量とのAES GCMの使用に適用されます。
For the use of AES CCM with the IKEv2 Encrypted Payload, this default nonce format MUST be used and an 11 octet nonce MUST be used. Note that this format matches the one specified in Section 4 of [RFC4309], providing compatibility between the use of AES CCM in IKEv2 and ESP. All of the requirements of Section 4 of [RFC4309] apply to the use of AES CCM with the IKEv2 Encrypted Payload.
IKEv2 Encrypted有効搭載量とのAES CCMの使用のために、このデフォルト一回だけ形式を使用しなければなりません、そして、11八重奏一回だけを使用しなければなりません。 この形式が[RFC4309]のセクション4で指定されたものに合っていることに注意してください、IKEv2と超能力におけるAES CCMの使用の間の互換性を提供して。 [RFC4309]のセクション4の要件のすべてがIKEv2 Encrypted有効搭載量とのAES CCMの使用に適用されます。
Black & McGrew Standards Track [Page 7] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[7ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
5. IKEv2 Associated Data (A)
5. IKEv2関連データ(A)
This section is based on Section 5 of [RFC4106] and Section 5 of [RFC4309], both of which refer to associated data as Additional Authenticated Data (AAD). The associated data construction described in this section applies to all authenticated encryption algorithms, but differs from the construction used with ESP because IKEv2 requires different data integrity coverage.
このセクションは[RFC4106]のセクション5と[RFC4309]のセクション5に基づいています。その両方がAdditional Authenticated Data(AAD)と関連データを呼びます。 このセクションで説明された関連データ工事は、すべての認証された暗号化アルゴリズムに適用しますが、IKEv2が異なったデータ保全適用範囲を必要とするので超能力と共に使用される工事と異なっています。
5.1. Associated Data (A) Construction
5.1. 関連データ(A)工事
The associated data (A) MUST consist of the partial contents of the IKEv2 message, starting from the first octet of the Fixed IKE Header through the last octet of the Payload Header of the Encrypted Payload (i.e., the fourth octet of the Encrypted Payload), as shown in Figure 3. This includes any payloads that are between the Fixed IKE Header and the Encrypted Payload.
関連データ(A)はIKEv2メッセージの部分的なコンテンツから成らなければなりません、Fixed IKE Headerの最初の八重奏から有効搭載量の最後の八重奏でEncrypted有効搭載量(すなわち、Encrypted有効搭載量の4番目の八重奏)のHeaderを始動して、図3に示されるように。 これはFixed IKE HeaderとEncrypted有効搭載量の間にあるどんなペイロードも含んでいます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IKEv2 Header ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Unencrypted IKE Payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ヘッダー..有効搭載量..次..有効搭載量 ペイロード長!+++++++++++++++++++++++++++++++++を予約します。
Figure 3. IKEv2 Encrypted Payload Associated Data (A) for
Authenticated Encryption
図3。 IKEv2は認証された暗号化のための有効搭載量関連データ(A)をコード化しました。
The Initialization Vector and Ciphertext fields shown in Figure 1 (above) MUST NOT be included in the associated data.
関連データに図1(above)で見せられた初期設定VectorとCiphertext分野を含んではいけません。
5.2. Data Integrity Coverage
5.2. データの保全適用範囲
The data integrity coverage of the IKEv2 Encrypted Payload encompasses the entire IKEv2 message that contains the Encrypted Payload. When an authenticated encryption algorithm is used with the Encrypted Payload, this coverage is realized as follows:
IKEv2 Encrypted有効搭載量のデータ保全適用範囲はEncrypted有効搭載量を含む全体のIKEv2メッセージを包含します。 認証された暗号化アルゴリズムがEncrypted有効搭載量と共に使用されるとき、この適用範囲は以下の通り実感されます:
1. The associated data (A) covers the portion of the IKEv2 message
starting from the first octet of the Fixed IKE Header through the
last octet of the Payload Header of the Encrypted Payload (fourth
octet of the Encrypted Payload). This includes any Payloads
between the Fixed IKE Header and the Encrypted Payload. The
Encrypted Payload is always the last payload in an IKEv2 message
[RFC4306].
1. 関連データ(A)はFixed IKE Headerの最初の八重奏からEncrypted有効搭載量(Encrypted有効搭載量の4番目の八重奏)の有効搭載量Headerの最後の八重奏でIKEv2メッセージ始めの部分をカバーしています。 これはFixed IKE HeaderとEncrypted有効搭載量の間のどんな有効搭載量も含んでいます。 いつもEncrypted有効搭載量はIKEv2メッセージ[RFC4306]で最後のペイロードです。
Black & McGrew Standards Track [Page 8] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[8ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
2. The IV is an input to the authenticated encryption algorithm's
integrity check. A successful integrity check at the receiver
verifies that the correct IV was used, providing data integrity
coverage for the IV.
2. IVは認証された暗号化アルゴリズムの保全チェックへの入力です。 受信機でのうまくいっている保全チェックは、正しいIVが使用されたことを確かめます、データ保全適用範囲をIVに提供して。
3. The plaintext (IKE Payloads, Padding and Pad Length) is covered by
the authenticated encryption algorithm's integrity check.
3. 平文(IKE有効搭載量、Padding、およびPad Length)は認証された暗号化アルゴリズムの保全チェックでカバーされています。
6. AES GCM and AES CCM Encrypted Payload Expansion
6. AES GCMとAES立方センチメートルは有効搭載量拡大をコード化しました。
The expansion described in Section 7 of [RFC4106] and Section 6 of [RFC4309] applies to the use of the AES GCM and AES CCM combined modes with the IKEv2 Encrypted Payload. See Section 7 of [RFC4106] and Section 6 of [RFC4309].
[RFC4106]のセクション7と[RFC4309]のセクション6で説明された拡大はIKEv2 Encrypted有効搭載量でAES GCMとAES CCMの使用に結合したモードを適用します。 [RFC4106]のセクション7と[RFC4309]のセクション6を見てください。
7. IKEv2 Conventions for AES GCM and AES CCM
7. AES GCMのためのIKEv2コンベンションとAES立方センチメートル
This section describes the conventions used to generate keying material and salt values for use with AES GCM and AES CCM using the IKEv2 [RFC4306] protocol. The identifiers and attributes needed to use AES GCM and AES CCM with the IKEv2 Encrypted Payload are also specified.
このセクションはAES GCMとAES CCMがIKEv2[RFC4306]プロトコルを使用している使用のために材料を合わせて、塩の値を発生させるのに使用されるコンベンションについて説明します。 識別子と属性は、AES GCMを使用する必要がありました、そして、また、IKEv2 Encrypted有効搭載量があるAES CCMは指定されます。
7.1. Keying Material and Salt Values
7.1. 材料と塩の値を合わせます。
This section is based on Section 8.1 of [RFC4106] and Section 7.1 of [RFC4309]. The Keying Material and Salt Values for AES GCM and AES CCM are different, but have the same structure as the Keying Material and Salt Values used with ESP.
このセクションは[RFC4106]のセクション8.1と[RFC4309]のセクション7.1に基づいています。 AES GCMとAES CCMのためのKeying MaterialとSalt Valuesは異なっていますが、超能力と共に使用されるKeying MaterialとSalt Valuesと同じ構造を持ってください。
IKEv2 makes use of a Pseudo-Random Function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size, from which keying material for specific uses is extracted without regard to PRF output boundaries; see Section 2.14 of [RFC4306].
IKEv2はPseudo無作為のFunction(PRF)の材料を合わせる引き出す使用をします。 PRFは任意のサイズの材料を合わせるのにおいて繰り返しに派生するのにおいて使用されています。特定の用途のための材料を合わせるのは関係なしでサイズからPRF出力境界に抽出されます。 [RFC4306]のセクション2.14を見てください。
This subsection describes how the key derivation specified in Section 2.14 of [RFC4306] is used to obtain keying material for AES GCM and AES CCM. When AES GCM or AES CCM is used with the IKEv2 Encrypted Payload, the SK_ai and SK_ar integrity protection keys are not used; each key MUST be treated as having a size of zero (0) octets. The size of each of the SK_ei and SK_er encryption keys includes additional salt bytes. The size and format of each of the SK_ei and SK_er encryption keys MUST be:
この小区分は[RFC4306]のセクション2.14で指定された主要な派生がAES GCMのために材料を合わせて、AES CCMを入手するのにどう使用されるかを説明します。 AES GCMかAES CCMがIKEv2 Encrypted有効搭載量と共に使用されるとき、SK_aiとSK_ar保全保護キーは使用されていません。 ゼロ(0)八重奏のサイズを持っているとして各キーを扱わなければなりません。 それぞれのSK_eiとSK_のサイズ、えー、暗号化キーは追加塩からいバイトを含んでいます。 それぞれのSK_eiとSK_のサイズと形式、えー、暗号化キーは以下の通りであるに違いありません。
o For AES GCM, each encryption key has the size and format of the
"KEYMAT requested" material specified in Section 8.1 of [RFC4106]
for the AES key size being used. For example, if the AES key size
o AES GCMに関しては、それぞれの暗号化キーで、[RFC4106]のセクション8.1で「要求されたKEYMAT」材料のサイズと形式を使用されるAESの主要なサイズに指定します。 例えば、AESであるなら、サイズを合わせてください。
Black & McGrew Standards Track [Page 9] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[9ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
is 128 bits, each encryption key is 20 octets, consisting of a
16-octet AES cipher key followed by 4 octets of salt.
128ビット、それぞれの暗号化キーが20の八重奏であるということであり、塩の4つの八重奏があとに続いた16八重奏のAES暗号キーから成ること。
o For AES CCM, each key has the size and format of the "KEYMAT
requested" material specified in Section 7.1 of [RFC4309] for the
AES key size being used. For example, if the AES key size is 128
bits, each encryption key is 19 octets, consisting of a 16-octet
AES cipher key followed by 3 octets of salt.
o AES CCMに関しては、各キーで、[RFC4309]のセクション7.1で「要求されたKEYMAT」材料のサイズと形式を使用されるAESの主要なサイズに指定します。 例えば、それぞれの暗号化キーはAESの主要なサイズが128ビットであるなら、19の八重奏です、塩の3つの八重奏があとに続いた16八重奏のAES暗号キーから成って。
7.2. IKEv2 Identifiers
7.2. IKEv2識別子
This section is unique to the IKEv2 Encrypted Payload usage of AES GCM and AES CCM. It reuses the identifiers used to negotiate ESP usage of AES GCM and AES CCM.
このセクションはAES GCMとAES CCMのIKEv2 Encrypted有効搭載量使用法にユニークです。 それはAES GCMとAES CCMの超能力使用法を交渉するのに使用される識別子を再利用します。
The following identifiers, previously allocated by IANA, are used to negotiate the use of AES GCM and AES CCM as the Encryption (ENCR) Transform for IKEv2 (i.e., for use with the IKEv2 Encrypted Payload):
以下の以前にIANAによって割り当てられた識別子はEncryption(ENCR)がIKEv2(すなわち、IKEv2 Encrypted有効搭載量との使用のための)のために変形するときAES GCMとAES CCMの使用を交渉するのに使用されます:
14 for AES CCM with an 8-octet ICV;
15 for AES CCM with a 12-octet ICV;
16 for AES CCM with a 16-octet ICV;
14 8八重奏のICVがあるAES立方センチメートルのために。 15 12八重奏のICVがあるAES立方センチメートルのために。 16 16八重奏のICVがあるAES立方センチメートルのために。
18 for AES GCM with an 8-octet ICV;
19 for AES GCM with a 12-octet ICV; and
20 for AES GCM with a 16-octet ICV.
18 8八重奏のICVとAES GCMのために。 19 12八重奏のICVとAES GCMのために。 そして、16八重奏のICVとAES GCMのための20。
A 16-octet ICV size SHOULD be used with IKEv2, as the higher level of security that it provides by comparison to smaller ICV sizes is appropriate to IKEv2's key exchange and related functionality.
SHOULDがIKEv2と共に使用されて、より高いレベルのセキュリティとして、16八重奏のICVサイズに、より小さいICVサイズとの比較で提供するのはIKEv2の主要な交換と関連する機能性に適切です。
In general, the use of 12-octet ICVs (values 15 and 19) is NOT RECOMMENDED in order to reduce the number of options for ICV size. If an ICV size larger than 8 octets is appropriate, 16-octet ICVs SHOULD be used.
一般に、12八重奏のICVs(値15と19)の使用は、ICVサイズのためのオプションの数を減少させるNOT RECOMMENDEDです。 8つの八重奏より大きいICVサイズが適切で、16八重奏のICVs SHOULDであるなら、使用されてください。
7.3. Key Length
7.3. キー長
This section is based on Section 8.4 of [RFC4106] and Section 7.4 of [RFC4309]. The Key Length requirements are common to AES GCM and AES CCM and are identical to the key length requirements for ESP.
このセクションは[RFC4106]のセクション8.4と[RFC4309]のセクション7.4に基づいています。 Key Length要件は、AES GCMとAES CCMに共通であり、超能力のためのキー長要件と同じです。
Because the AES supports three key lengths, the Key Length attribute MUST be specified when any of the identifiers for AES GCM or AES CCM, specified in Section 7.2 of this document, is used. The Key Length attribute MUST have a value of 128, 192, or 256. The use of the value 192 is NOT RECOMMENDED. If an AES key larger than 128 bits is
AESが3つのキー長を支持するので、AES GCMかAES CCMのための識別子のこのドキュメントのセクション7.2で指定されたどれかが使用されていると、Key Length属性は指定していなければなりません。 Key Length属性に、128、192、または256の値がなければなりません。 値192の使用はNOT RECOMMENDEDです。 128ビットより大きいAESキーがそうなら
Black & McGrew Standards Track [Page 10] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[10ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
appropriate, a 256-bit AES key SHOULD be used. This reduces the number of options for AES key length.
適切であることで、256ビットのAESはSHOULDを合わせます。使用されます。 これはAESキー長のためのオプションの数を減少させます。
8. IKEv2 Algorithm Selection
8. IKEv2アルゴリズム選択
This section applies to the use of any authenticated encryption algorithm with the IKEv2 Encrypted Payload and is unique to that usage.
このセクションは、IKEv2 Encrypted有効搭載量とのどんな認証された暗号化アルゴリズムの使用にも適用して、その用法にユニークです。
IKEv2 (Section 3.3.3 of [RFC4306]) specifies that both an encryption algorithm and an integrity checking algorithm are required for an IKE SA (Security Association). This document updates [RFC4306] to require that when an authenticated encryption algorithm is selected as the encryption algorithm for any SA (IKE or ESP), an integrity algorithm MUST NOT be selected for that SA. This document further updates [RFC4306] to require that if all of the encryption algorithms in any proposal are authenticated encryption algorithms, then the proposal MUST NOT propose any integrity transforms.
IKEv2(.3セクション3.3[RFC4306])は、暗号化アルゴリズムと保全照合アルゴリズムの両方がIKE SA(セキュリティAssociation)に必要であると指定します。 このドキュメントは、認証された暗号化アルゴリズムがどんなSA(IKEか超能力)のための暗号化アルゴリズムとしても選定されるとき、そのSAのために保全アルゴリズムを選択してはいけないのが必要であるように[RFC4306]をアップデートします。 このドキュメントは、提案がどんな提案でも暗号化アルゴリズムのすべてが認証された暗号化アルゴリズムであるなら少しの保全変換も提案してはいけないのが必要であるようにさらに[RFC4306]をアップデートします。
9. Test Vectors
9. テストベクトル
See Section 9 of [RFC4106] and Section 8 of [RFC4309] for references that provide AES GCM and AES CCM test vectors.
テストベクトルをAES GCMとAES CCMに供給する参照に関して[RFC4106]のセクション9と[RFC4309]のセクション8を見てください。
10. RFC 5116 AEAD_* Algorithms
10. RFC5116AEAD_*アルゴリズム
This section adds new algorithms to the AEAD_* algorithm framework defined in [RFC5116] to encompass the usage of AES GCM and AES CCM with IKEv2. An AEAD_* algorithm does not have any attributes or parameters; each AEAD_* algorithm identifier defined in this document completely specifies the AES key size and the ICV size to be used (e.g., AEAD_AES_128_GCM uses a 128-bit AES key and a 16-octet ICV).
このセクションはIKEv2でAES GCMとAES CCMの使用法を取り巻くために[RFC5116]で定義されたAEAD_*アルゴリズム枠組みに新しいアルゴリズムを追加します。 AEAD_*アルゴリズムには、どんな属性やパラメタもありません。 本書では定義されたそれぞれのAEAD_*アルゴリズム識別子は、使用されるためにAESの主要なサイズとICVサイズを完全に指定します(例えば、AEAD_AES_128_GCMは128ビットのAESキーと16八重奏のICVを使用します)。
AEAD_* algorithm coverage of the AES GCM and AES CCM authenticated encryption algorithms used with IKEv2 requires specification of eight additional AEAD_* algorithms beyond the four algorithms specified in [RFC5116]:
認証された暗号化アルゴリズムがIKEv2と共に使用したAES GCMとAES CCMのAEAD_*アルゴリズム適用範囲は[RFC5116]で指定された4つのアルゴリズムを超えて8つの追加AEAD_*アルゴリズムの仕様を必要とします:
o Four AEAD_* algorithms are specified to allow 8- and 12-octet ICVs
to be used with the AES GCM and AEAD_* algorithms specified in
[RFC5116].
o 4つのAEAD_*アルゴリズムが、8と12八重奏のICVsが[RFC5116]で指定されるAES GCMとAEAD_*アルゴリズムで使用されるのを許容するために指定されます。
o The version of AES CCM used with IPsec (see [RFC4309]) uses an
11-octet nonce instead of the 12-octet nonce used by the version
of AES CCM specified in [RFC5116]. Six AEAD_* algorithms are
specified for this short nonce version of AES CCM.
o IPsec([RFC4309]を見る)と共に使用されるAES CCMのバージョンは[RFC5116]で指定されたAES CCMのバージョンによって使用される12八重奏の一回だけの代わりに11八重奏の一回だけを使用します。 6つのAEAD_*アルゴリズムがAES CCMのこの短い一回だけのバージョンに指定されます。
Black & McGrew Standards Track [Page 11] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[11ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
This document recommends against the use of 192-bit AES keys, and therefore does not specify AEAD_* algorithms for 192-bit AES keys.
このドキュメントは、192ビットのAESキーのためのAEAD_*アルゴリズムを192ビットのAESキーの使用に対して推薦して、したがって、指定しません。
10.1. AES GCM Algorithms with 8- and 12-octet ICVs
10.1. 8があるAES GCMアルゴリズムと12八重奏のICVs
The following four AEAD_* algorithms are identical to the AEAD_* algorithms specified in [RFC5116], except that an 8-octet ICV is used instead of a 16-octet ICV.
以下の4つのAEAD_*アルゴリズムが[RFC5116]で指定されたAEAD_*アルゴリズムと同じです、8八重奏のICVが16八重奏のICVの代わりに使用されるのを除いて。
10.1.1. AEAD_AES_128_GCM_8
10.1.1. AEAD_AES_128_GCM_8
This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_128_GCMと同じです([RFC5116]のセクション5.1を見てください)、タグの長さ(t)が8であり、8つの八重奏(64ビット)の長さがある認証タグが使用されているのを除いて。
An AEAD_AES_128_GCM_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_128_GCM_8暗号文はまさに8です。
10.1.2. AEAD_AES_256_GCM_8
10.1.2. AEAD_AES_256_GCM_8
This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116]), except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_256_GCMと同じです([RFC5116]のセクション5.2を見てください)、タグの長さ(t)が8であり、8つの八重奏(64ビット)の長さがある認証タグが使用されているのを除いて。
An AEAD_AES_256_GCM_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_256_GCM_8暗号文はまさに8です。
10.1.3. AEAD_AES_128_GCM_12
10.1.3. AEAD_AES_128_GCM_12
This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 12, and an authentication tag with a length of 12 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_128_GCMと同じです([RFC5116]のセクション5.1を見てください)、タグの長さ(t)が12であり、12の八重奏(64ビット)の長さがある認証タグが使用されているのを除いて。
An AEAD_AES_128_GCM_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_128_GCM_12暗号文はまさに12です。
10.1.4. AEAD_AES_256_GCM_12
10.1.4. AEAD_AES_256_GCM_12
This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116], except that the tag length, t, is 12 and an authentication tag with a length of 12 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_256_GCMと同じです。([RFC5116]のセクション5.2を見てください、タグの長さ(t)が1212の八重奏(64ビット)の長さが使用されている認証タグであるのを除いて。
An AEAD_AES_256_GCM_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_256_GCM_12暗号文はまさに12です。
Black & McGrew Standards Track [Page 12] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[12ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
10.2. AES CCM Algorithms with an 11-octet Nonce
10.2. 11八重奏の一回だけがあるAES立方センチメートルアルゴリズム
The following four AEAD algorithms employ the AES CCM algorithms with an 11 octet nonce as specified in [RFC4309].
以下の4つのAEADアルゴリズムが[RFC4309]の指定されるとしての11八重奏一回だけと共にAES CCMアルゴリズムを使います。
10.2.1. AEAD_AES_128_CCM_SHORT
10.2.1. AEAD_AES_128_立方センチメートル_短いです。
The AEAD_AES_128_CCM_SHORT authenticated encryption algorithm is identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of [RFC5116]), except that it uses a nonce that is one octet shorter. AEAD_AES_128_CCM_SHORT works as specified in [CCM]. It uses AES-128 as the block cipher by providing the key, nonce, associated data, and plaintext to that mode of operation. The formatting and counter generation function are as specified in Appendix A of [CCM], and the values of the parameters identified in that appendix are as follows:
AEAD_AES_128_CCM_SHORTは暗号化を認証しました。アルゴリズムはAEAD_AES_128_CCMアルゴリズムと同じです([RFC5116]のセクション5.3を見てください)、1つの八重奏より短い一回だけを使用するのを除いて。 AEAD_AES_128_CCM_SHORTは[CCM]で指定されるように働いています。 それは、ブロック暗号として主要で、一回だけの関連データ、および平文をその運転モードに提供することによって、AES-128を使用します。 形式とカウンタ世代機能が[CCM]のAppendix Aで指定されるようにあります、そして、その付録で特定されたパラメタの値は以下の通りです:
the nonce length n is 11,
一回だけの長さnは11です。
the tag length t is 16, and
そしてタグの長さtが16である。
the value of q is 3.
qの値は3です。
An authentication tag with a length of 16 octets (128 bits) is used. The AEAD_AES_128_CCM_SHORT ciphertext consists of the ciphertext output of the CCM encryption operation concatenated with the authentication tag output of the CCM encryption operation. Test cases are provided in [CCM]. The input and output lengths are as follows:
16の八重奏(128ビット)の長さがある認証タグは使用されています。 AEAD_AES_128_CCM_SHORT暗号文はCCM暗号化操作の認証タグ出力で連結されたCCM暗号化操作の暗号文出力から成ります。 [CCM]にテストケースを提供します。 入出力の長さは以下の通りです:
K_LEN is 16 octets,
K_LENは16の八重奏です。
P_MAX is 2^24 - 1 octets,
P_MAXは2^24--1八重奏です。
A_MAX is 2^64 - 1 octets,
_MAXは2^64--1八重奏です。
N_MIN and N_MAX are both 11 octets, and
そしてN_MINとN_MAXが両方の11の八重奏である。
C_MAX is 2^24 + 15 octets.
C_MAXは2^24+15の八重奏です。
An AEAD_AES_128_CCM_SHORT ciphertext is exactly 16 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_128_CCM_SHORT暗号文はまさに16です。
Black & McGrew Standards Track [Page 13] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[13ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
10.2.2. AEAD_AES_256_CCM_SHORT
10.2.2. AEAD_AES_256_立方センチメートル_短いです。
This algorithm is identical to AEAD_AES_128_CCM_SHORT, but with the following differences:
このアルゴリズムは、AEAD_AES_128_CCM_SHORTと同じですが、以下の違いで同じです:
K_LEN is 32 octets, instead of 16, and
そしてK_LENが16の代わりに32の八重奏である。
AES-256 CCM is used instead of AES-128 CCM.
AES-256 CCMはAES-128 CCMの代わりに使用されます。
An AEAD_AES_256_CCM_SHORT ciphertext is exactly 16 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_256_CCM_SHORT暗号文はまさに16です。
10.2.3. AEAD_AES_128_CCM_SHORT_8
10.2.3. AEAD_AES_128_立方センチメートル_の短い_8
This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_128_CCM_SHORTと同じです、タグの長さ(t)が8であり、8つの八重奏(64ビット)の長さがある認証タグが使用されているのを除いて。
An AEAD_AES_128_CCM_SHORT_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_128_CCM_SHORT_8暗号文はまさに8です。
10.2.4. AEAD_AES_256_CCM_SHORT_8
10.2.4. AEAD_AES_256_立方センチメートル_の短い_8
This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_256_CCM_SHORTと同じです、タグの長さ(t)が8であり、8つの八重奏(64ビット)の長さがある認証タグが使用されているのを除いて。
An AEAD_AES_256_CCM_SHORT_8 ciphertext is exactly 8 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_256_CCM_SHORT_8暗号文はまさに8です。
10.2.5. AEAD_AES_128_CCM_SHORT_12
10.2.5. AEAD_AES_128_立方センチメートル_の短い_12
This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that the tag length, t, is 12, and an authentication tag with a length of 12 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_128_CCM_SHORTと同じです、タグの長さ(t)が12であり、12の八重奏(64ビット)の長さがある認証タグが使用されているのを除いて。
An AEAD_AES_128_CCM_SHORT_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_128_CCM_SHORT_12暗号文はまさに12です。
10.2.6. AEAD_AES_256_CCM_SHORT_12
10.2.6. AEAD_AES_256_立方センチメートル_の短い_12
This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that the tag length, t, is 12, and an authentication tag with a length of 8 octets (64 bits) is used.
このアルゴリズムはAEAD_AES_256_CCM_SHORTと同じです、タグの長さ(t)が12であり、8つの八重奏(64ビット)の長さがある認証タグが使用されているのを除いて。
An AEAD_AES_256_CCM_SHORT_12 ciphertext is exactly 12 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_256_CCM_SHORT_12暗号文はまさに12です。
Black & McGrew Standards Track [Page 14] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[14ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
10.3. AEAD_* Algorithms and IKEv2
10.3. AEAD_*アルゴリズムとIKEv2
The following table lists the AES CCM and AES GCM AEAD_* algorithms that can be negotiated by IKEv2 and provides the IKEv2 Encryption (ENCR) Transform Identifier and Key Length Attribute combination that is used to negotiate each algorithm.
以下のテーブルは、IKEv2が交渉できるAES CCMとAES GCM AEAD_*アルゴリズムを記載して、各アルゴリズムを交渉するのに使用されるIdentifierとKey Length Attribute組み合わせを(ENCR)が変えるIKEv2 Encryptionに供給します。
+--------------------------+------------------+-------------+
| AEAD algorithm | ENCR Identifier | Key Length |
+--------------------------+------------------+-------------+
| AEAD_AES_128_GCM | 20 | 128 |
| AEAD_AES_256_GCM | 20 | 256 |
| AEAD_AES_128_GCM_8 | 18 | 128 |
| AEAD_AES_256_GCM_8 | 18 | 256 |
| AEAD_AES_128_GCM_12 | 19 | 128 |
| AEAD_AES_256_GCM_12 | 19 | 256 |
| AEAD_AES_128_CCM_SHORT | 16 | 128 |
| AEAD_AES_256_CCM_SHORT | 16 | 256 |
| AEAD_AES_128_CCM_SHORT_8 | 14 | 128 |
| AEAD_AES_256_CCM_SHORT_8 | 14 | 256 |
| AEAD_AES_128_CCM_SHORT_12| 15 | 128 |
| AEAD_AES_256_CCM_SHORT_12| 15 | 256 |
+--------------------------+------------------+-------------+
+--------------------------+------------------+-------------+ | AEADアルゴリズム| ENCR識別子| キー長| +--------------------------+------------------+-------------+ | AEAD_AES_128_GCM| 20 | 128 | | AEAD_AES_256_GCM| 20 | 256 | | AEAD_AES_128_GCM_8| 18 | 128 | | AEAD_AES_256_GCM_8| 18 | 256 | | AEAD_AES_128_GCM_12| 19 | 128 | | AEAD_AES_256_GCM_12| 19 | 256 | | AEAD_AES_128_立方センチメートル_短いです。| 16 | 128 | | AEAD_AES_256_立方センチメートル_短いです。| 16 | 256 | | AEAD_AES_128_立方センチメートル_の短い_8| 14 | 128 | | AEAD_AES_256_立方センチメートル_の短い_8| 14 | 256 | | AEAD_AES_128_立方センチメートル_の短い_12| 15 | 128 | | AEAD_AES_256_立方センチメートル_の短い_12| 15 | 256 | +--------------------------+------------------+-------------+
Each of the above AEAD_* algorithms is identical to the algorithm designated by the combination of the IKEv2 ENCR Identifier and Key Length Attribute shown on the same line of the table.
それぞれの上のAEAD_*アルゴリズムはテーブルの同じ線の上で見せられたIKEv2 ENCR IdentifierとKey Length Attributeの組み合わせで指定されたアルゴリズムと同じです。
11. Security Considerations
11. セキュリティ問題
For authenticated encryption security considerations, see the entirety of [RFC5116], not just its security considerations section; there are important security considerations that are discussed outside the security considerations section of that document.
認証された暗号化セキュリティ問題に関しては、セキュリティ問題部だけではなく、[RFC5116]の全体を見てください。 そのドキュメントのセキュリティ問題部の外で論じられる重要なセキュリティ問題があります。
The security considerations for the use of AES GCM and AES CCM with ESP apply to the use of these algorithms with the IKEv2 Encrypted Payload, see Section 10 of [RFC4106] and Section 9 of [RFC4309]. Use of AES GCM and AES CCM with IKEv2 does not create additional security considerations beyond those for the use of AES GCM and AES CCM with ESP.
超能力を伴うAES GCMとAES CCMの使用のためのセキュリティ問題はIKEv2 Encrypted有効搭載量とのこれらのアルゴリズムの使用に適用されます、と[RFC4106]のセクション10と[RFC4309]のセクション9は見ます。 IKEv2とAES GCMとAES CCMの使用はAES GCMとAES CCMの使用のために超能力でそれらを超えて追加担保問題を作成しません。
For IKEv2 security considerations, see Section 5 of [RFC4306].
IKEv2セキュリティ問題に関しては、[RFC4306]のセクション5を見てください。
Black & McGrew Standards Track [Page 15] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[15ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
12. IANA Considerations
12. IANA問題
The Encryption Transform identifiers specified in Section 7.2 have been previously assigned by IANA for use with ESP. This document extends their usage to IKEv2 for the Encrypted Payload. No IANA actions are required for this usage extension.
セクション7.2で指定されたEncryption Transform識別子は以前に、超能力との使用のためにIANAによって割り当てられました。 このドキュメントはEncrypted有効搭載量のためにそれらの用法をIKEv2に与えます。 IANA動作は全くこの用法拡大に必要ではありません。
IANA has added the following entries to the Authenticated Encryption with Associated Data (AEAD) Parameters Registry:
IANAはAssociated Data(AEAD)パラメタRegistryと共に以下のエントリーをAuthenticated Encryptionに加えました:
+--------------------------+----------------+--------------------+ | Name | Reference | Numeric Identifier | +--------------------------+----------------+--------------------+ | AEAD_AES_128_GCM_8 | Section 10.1.1 | 5 | | AEAD_AES_256_GCM_8 | Section 10.1.2 | 6 | | AEAD_AES_128_GCM_12 | Section 10.1.3 | 7 | | AEAD_AES_256_GCM_12 | Section 10.1.4 | 8 | | AEAD_AES_128_CCM_SHORT | Section 10.2.1 | 9 | | AEAD_AES_256_CCM_SHORT | Section 10.2.2 | 10 | | AEAD_AES_128_CCM_SHORT_8 | Section 10.2.3 | 11 | | AEAD_AES_256_CCM_SHORT_8 | Section 10.2.4 | 12 | | AEAD_AES_128_CCM_SHORT_12| Section 10.2.5 | 13 | | AEAD_AES_256_CCM_SHORT_12| Section 10.2.6 | 14 | +--------------------------+----------------+--------------------+
+--------------------------+----------------+--------------------+ | 名前| 参照| 数値識別子| +--------------------------+----------------+--------------------+ | AEAD_AES_128_GCM_8| セクション10.1 .1| 5 | | AEAD_AES_256_GCM_8| セクション10.1 .2| 6 | | AEAD_AES_128_GCM_12| セクション10.1 .3| 7 | | AEAD_AES_256_GCM_12| セクション10.1 .4| 8 | | AEAD_AES_128_立方センチメートル_短いです。| セクション10.2 .1| 9 | | AEAD_AES_256_立方センチメートル_短いです。| セクション10.2 .2| 10 | | AEAD_AES_128_立方センチメートル_の短い_8| セクション10.2 .3| 11 | | AEAD_AES_256_立方センチメートル_の短い_8| セクション10.2 .4| 12 | | AEAD_AES_128_立方センチメートル_の短い_12| セクション10.2 .5| 13 | | AEAD_AES_256_立方センチメートル_の短い_12| セクション10.2 .6| 14 | +--------------------------+----------------+--------------------+
An IANA registration of an AEAD algorithm does not constitute an endorsement of that algorithm or its security.
AEADアルゴリズムのIANA登録はそのアルゴリズムかそのセキュリティの裏書きを構成しません。
13. Acknowledgments
13. 承認
See Section 13 of [RFC4106] and Section 12 of [RFC4309] for AES GCM and AES CCM acknowledgments.
AES GCMとAES CCM承認に関して[RFC4106]のセクション13と[RFC4309]のセクション12を見てください。
Also, we thank Charlie Kaufman, Pasi Eronen, Tero Kivinen, Steve Kent, and Alfred Hoenes for their comprehensive reviews of this document.
また、私たちは彼らのこのドキュメントの包括的なレビューについてチャーリー・カウフマン、パシEronen、Tero Kivinen、スティーブ・ケント、およびアルフレッドHoenesに感謝します。
This document was originally prepared using 2-Word-v2.0.template.dot, created by Joe Touch.
ジョーTouchによって作成されて、2がv2.0.template.dotを言い表した状態で、使用は元々、このドキュメントに準備されました。
Black & McGrew Standards Track [Page 16] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[16ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM
Mode for Authentication and Confidentiality", U.S. National
Institute of Standards and Technology,
<http://csrc.nist.gov/publications/nistpubs/800-38C/
SP800-38C.pdf>, updated July 2007.
ドーキン、[立方センチメートル]M.、「NISTの特別な公表800-38C:」 「AuthenticationとConfidentialityのためのCCM Mode」(米国米国商務省標準技術局、<http://csrc.nist.gov/刊行物/nistpubs/800-38C/SP800-38C. pdf>)は2007年7月にアップデートしました。
[GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC.", U.S. National
Institute of Standards and Technology, November 2007,
<http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf>, November 2007.
[GCM]ドーキン、M.、「NISTの特別な公表800-38D:」 ブロック暗号運転モードのための推薦: 「ガロア/カウンタモード(GCM)とGMAC」、米国米国商務省標準技術局、2007年11月、<http://csrc.nist.gov/刊行物/nistpubs/800-38D/SP-800-38D. pdf>、11月2007
[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月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
4106, June 2005.
[RFC4106] ViegaとJ.とD.マグリュー、「セキュリティ有効搭載量(超能力)を要約するIPsecにおけるガロア/カウンタモード(GCM)の使用」、RFC4106、2005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4303]ケント、S.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", RFC
4309, December 2005.
[RFC4309]Housley、R.、「IPsecがセキュリティ有効搭載量(超能力)を要約しているエー・イー・エス(AES)立方センチメートルモードを使用します」、RFC4309、2005年12月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008.
[RFC5116] マグリューと、D.と、「認証された暗号化のためのインタフェースとアルゴリズム」、RFC5116、1月2008日
14.2. Informative References
14.2. 有益な参照
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC2408] Maughan、D.、Schertler、M.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
Black & McGrew Standards Track [Page 17] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[17ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
Author's Addresses
作者のアドレス
David L. Black EMC Corporation 176 South Street Hopkinton, MA 10748
ホプキントン、デヴィッドL.黒のEMC社176の南通りMA 10748
Phone: +1 (508) 293-7953 EMail: black_david@emc.com
以下に電話をしてください。 +1 (508) 293-7953 メールしてください: black_david@emc.com
David A. McGrew Cisco Systems, Inc. 510 McCarthy Blvd. Milpitas, CA 95035
デヴィッドA.マグリューシスコシステムズInc.510マッカーシーBlvd. ミルピタス、カリフォルニア 95035
Phone: +1 (408) 525-8651 EMail: mcgrew@cisco.com
以下に電話をしてください。 +1 (408) 525-8651 メールしてください: mcgrew@cisco.com
Black & McGrew Standards Track [Page 18] RFC 5282 Authenticated Encryption and IKEv2 August 2008
黒とマグリュー標準化過程[18ページ]RFC5282は暗号化とIKEv2 August 2008を認証しました。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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.
このドキュメントは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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Black & McGrew Standards Track [Page 19]
黒とマグリュー標準化過程[19ページ]
一覧
スポンサーリンク
