RFC5288 日本語訳
5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS. J. Salowey,A. Choudhury, D. McGrew. August 2008. (Format: TXT=16468 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Salowey
Request for Comments: 5288 A. Choudhury
Category: Standards Track D. McGrew
Cisco Systems, Inc.
August 2008
Saloweyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5288年のA.チョウドリカテゴリ: 標準化過程D.マグリューシスコシステムズInc.2008年8月
AES Galois Counter Mode (GCM) Cipher Suites for TLS
TLSのためのAESガロアカウンタモード(GCM)暗号スイート
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
要約
This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms.
Transport Layer Security(TLS)が暗号化操作を認証したので、このメモはガロア/カウンタMode(GCM)におけるエー・イー・エス(AES)の使用について説明します。 GCMが秘密性とデータの両方に起源認証を提供して、1秒あたり10のギガビットの速度のためのハードウェアと上で効率的に実行されていて、また、ソフトウェア実行に十分合うことができます。 このメモはRSA、DSA、およびディフィー・ヘルマンベースの主要な交換メカニズムがあるAES-GCMを使用するTLS暗号スイートを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 2
4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6.1. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 4
6.2. Recommendations for Multiple Encryption Processors . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 コンベンションは本書では.2 3を使用しました。 AES-GCMはスイート. . . . . . . . . . . . . . . . . . . . . 2 4を解きます。 TLSバージョン. . . . . . . . . . . . . . . . . . . . . . . . . 3 5。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 4 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 4 6.1。 再利用. . . . . . . . . . . . . . . . . . . . . . . 4 6.2に対抗してください。 複数の暗号化プロセッサ. . . . 4 7のための推薦 承認. . . . . . . . . . . . . . . . . . . . . . . 5 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 6 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 6
Salowey, et al. Standards Track [Page 1] RFC 5288 AES-GCM Cipher suites August 2008
Salowey、他 規格Track[1ページ]RFC5288AES-GCM Cipherスイート2008年8月
1. Introduction
1. 序論
This document describes the use of AES [AES] in Galois Counter Mode (GCM) [GCM] (AES-GCM) with various key exchange mechanisms as a cipher suite for TLS. AES-GCM is an authenticated encryption with associated data (AEAD) cipher (as defined in TLS 1.2 [RFC5246]) providing both confidentiality and data origin authentication. The following sections define cipher suites based on RSA, DSA, and Diffie-Hellman key exchanges; ECC-based (Elliptic Curve Cryptography) cipher suites are defined in a separate document [RFC5289].
このドキュメントは、様々な主要な交換メカニズムがあるガロアCounter Mode(GCM)[GCM](AES-GCM)におけるAES[AES]の使用をTLSのための暗号スイートと説明します。 AES-GCMは関連データ(AEAD)暗号(TLS1.2[RFC5246]で定義されるように)が秘密性とデータの両方に起源認証を提供している認証された暗号化です。 以下のセクションはRSA、DSA、およびディフィー-ヘルマンの主要な交換に基づく暗号スイートを定義します。 ECCベース(楕円形のCurve Cryptography)の暗号スイートは別々のドキュメント[RFC5289]で定義されます。
AES-GCM is not only efficient and secure, but hardware implementations can achieve high speeds with low cost and low latency, because the mode can be pipelined. Applications that require high data throughput can benefit from these high-speed implementations. AES-GCM has been specified as a mode that can be used with IPsec ESP [RFC4106] and 802.1AE Media Access Control (MAC) Security [IEEE8021AE].
AES-GCMは効率的であるだけであって安全ではありませんが、ハードウェア実装は低価格と低遅延で高速を実現できます、モードをpipelinedされることができるので。 高いデータスループットを必要とするアプリケーションはこれらの高速実現の利益を得ることができます。 AES-GCMはIPsec超能力[RFC4106]と802.1AEメディアAccess Control(MAC)セキュリティ[IEEE8021AE]と共に使用できるモードとして指定されました。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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]で説明されるように本書では解釈されることであるべきですか?
3. AES-GCM Cipher Suites
3. AES-GCM暗号スイート
The following cipher suites use the new authenticated encryption modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
以下の暗号スイートはガロアCounter Mode(GCM)[GCM]のAESと共にTLS1.2で定義された新しい認証された暗号化モードを使用します:
CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}
CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}
CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}
CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}
CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0xA0}
CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0xA1}
CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}
CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}
CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA4}
CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA5}
CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}
CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}
等しい..0×00..等しい..0×00..等しい..0×00..等しい..0×00..等しい..0×00..等しい..0×00; DSS..等しい..0×00..DSS..等しい..0×00..DSS..等しい..0×00..DSS..等しい..0×00..やがて..等しい..0×00..やがて0×00、0xA7
These cipher suites use the AES-GCM authenticated encryption with associated data (AEAD) algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in [RFC5116]. Note that each of these AEAD algorithms uses a 128-bit authentication tag with GCM (in particular, as described in Section 3.5 of [RFC4366], the
これらの暗号スイートは関連データ(AEAD)アルゴリズムのAEAD_AES_128_GCMとAEAD_AES_256_GCMとの認証された暗号化が[RFC5116]で説明したAES-GCMを使用します。 それぞれのこれらのAEADアルゴリズムがGCMがある128ビットの認証タグを使用することに注意してください、([RFC4366]のセクション3.5で特に説明されるように
Salowey, et al. Standards Track [Page 2] RFC 5288 AES-GCM Cipher suites August 2008
Salowey、他 規格Track[2ページ]RFC5288AES-GCM Cipherスイート2008年8月
"truncated_hmac" extension does not have an effect on cipher suites that do not use HMAC). The "nonce" SHALL be 12 bytes long consisting of two parts as follows: (this is an example of a "partially explicit" nonce; see Section 3.2.1 in [RFC5116]).
HMACを使用しない拡大が効果を持っていない「端が欠けている_hmac」暗号スイート) 「一回だけ」のSHALL、以下の2つの部品から成る12バイト長になってください: (これは「部分的に明白な」一回だけに関する例です。 [RFC5116)でセクション3.2.1を見てください。
struct {
opaque salt[4];
opaque nonce_explicit[8];
} GCMNonce;
struct不透明な塩[4]; 不透明な一回だけの_明白な[8];のGCMNonce。
The salt is the "implicit" part of the nonce and is not sent in the packet. Instead, the salt is generated as part of the handshake process: it is either the client_write_IV (when the client is sending) or the server_write_IV (when the server is sending). The salt length (SecurityParameters.fixed_iv_length) is 4 octets.
塩は、一回だけの「暗黙」の部分であり、パケットで送られません。 代わりに、塩は握手の過程の一部として発生します: それは_が_IVに書くと_IV(クライアントが発信するとき)かサーバ_に書くクライアント(サーバが発信するとき)です。 塩の長さ(SecurityParameters.fixed_iv_の長さ)は4つの八重奏です。
The nonce_explicit is the "explicit" part of the nonce. It is chosen by the sender and is carried in each TLS record in the GenericAEADCipher.nonce_explicit field. The nonce_explicit length (SecurityParameters.record_iv_length) is 8 octets.
一回だけの_明白であるのは、一回だけの「明白な」部分です。 それは、送付者によって選ばれていて、GenericAEADCipher.nonceの_の明白な分野でそれぞれのTLS記録で運ばれます。 一回だけの_明白な長さ(SecurityParameters.record_iv_の長さ)は8つの八重奏です。
Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.
一回だけの_の各値、明白である、GCMのそれぞれの異なった実施がどんな固定キーのためにも機能をコード化するので、異ならなければならなくなってください。 このユニークさの必要条件を満たさない場合、セキュリティをかなり下がらせることができます。 一回だけの_明白な5月は64によって噛み付きにされます。一連番号。
The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges are performed as defined in [RFC5246].
RSA、DHE_RSA、DH_RSA、DHE_DSS、DH_DSS、およびDH_はやがて、交換を合わせます。[RFC5246]で定義されるように、実行されます。
The Pseudo Random Function (PRF) algorithms SHALL be as follows:
Pseudo Random Function(PRF)アルゴリズムSHALL、以下の通りになってください:
For cipher suites ending with _SHA256, the PRF is the TLS PRF
[RFC5246] with SHA-256 as the hash function.
_SHA256と共に終わる暗号スイートに関しては、PRFはハッシュ関数としてのSHA-256とTLS PRF[RFC5246]です。
For cipher suites ending with _SHA384, the PRF is the TLS PRF
[RFC5246] with SHA-384 as the hash function.
_SHA384と共に終わる暗号スイートに関しては、PRFはハッシュ関数としてのSHA-384とTLS PRF[RFC5246]です。
Implementations MUST send TLS Alert bad_record_mac for all types of failures encountered in processing the AES-GCM algorithm.
実現はすべてのタイプの失敗のためのmacが処理で遭遇したTLS Alertの悪い_記録_にAES-GCMアルゴリズムを送らなければなりません。
4. TLS Versions
4. TLSバージョン
These cipher suites make use of the authenticated encryption with additional data defined in TLS 1.2 [RFC5246]. They MUST NOT be negotiated in older versions of TLS. Clients MUST NOT offer these cipher suites if they do not offer TLS 1.2 or later. Servers that select an earlier version of TLS MUST NOT select one of these cipher suites. Because TLS has no way for the client to indicate that it
これらの暗号スイートはTLS1.2[RFC5246]で定義される追加データと共に認証された暗号化を利用します。 TLSの旧式のバージョンでそれらを交渉してはいけません。 TLS1.2以降を提供しないなら、クライアントはこれらの暗号スイートを提供してはいけません。 TLS MUST NOTの以前のバージョンを選択するサーバがこれらの暗号スイートの1つを選択します。 TLSにはクライアントがそれを示す方法が全くない、それ
Salowey, et al. Standards Track [Page 3] RFC 5288 AES-GCM Cipher suites August 2008
Salowey、他 規格Track[3ページ]RFC5288AES-GCM Cipherスイート2008年8月
supports TLS 1.2 but not earlier, a non-compliant server might potentially negotiate TLS 1.1 or earlier and select one of the cipher suites in this document. Clients MUST check the TLS version and generate a fatal "illegal_parameter" alert if they detect an incorrect version.
より早い不従順なサーバではなく、TLS1.2が潜在的にそうするかもしれないサポートは、TLS1.1以前を交渉して、本書では暗号スイートの1つを選択します。 彼らが不正確なバージョンを検出するなら、クライアントは、TLSバージョンをチェックして、致命的な「不法な_パラメタ」警戒を発生させなければなりません。
5. IANA Considerations
5. IANA問題
IANA has assigned the following values for the cipher suites defined in this document:
IANAは本書では定義された暗号スイートに以下の値を割り当てました:
CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}
CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}
CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}
CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}
CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0xA0}
CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0xA1}
CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}
CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}
CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA4}
CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA5}
CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}
CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}
等しい..0×00..等しい..0×00..等しい..0×00..等しい..0×00..等しい..0×00..等しい..0×00; DSS..等しい..0×00..DSS..等しい..0×00..DSS..等しい..0×00..DSS..等しい..0×00..やがて..等しい..0×00..やがて0×00、0xA7
6. Security Considerations
6. セキュリティ問題
The security considerations in [RFC5246] apply to this document as well. The remainder of this section describes security considerations specific to the cipher suites described in this document.
[RFC5246]のセキュリティ問題はまた、このドキュメントに適用されます。 このセクションの残りは本書では説明された暗号スイートに特定のセキュリティ問題について説明します。
6.1. Counter Reuse
6.1. カウンタ再利用
AES-GCM security requires that the counter is never reused. The IV construction in Section 3 is designed to prevent counter reuse.
AES-GCMセキュリティは、カウンタが決して再利用されないのを必要とします。 セクション3におけるIV工事は、カウンタ再利用を防ぐように設計されています。
Implementers should also understand the practical considerations of IV handling outlined in Section 9 of [GCM].
また、Implementersは[GCM]のセクション9に概説されたIV取り扱いの実用的な問題を理解しているはずです。
6.2. Recommendations for Multiple Encryption Processors
6.2. 複数の暗号化プロセッサのための推薦
If multiple cryptographic processors are in use by the sender, then the sender MUST ensure that, for a particular key, each value of the nonce_explicit used with that key is distinct. In this case, each encryption processor SHOULD include, in the nonce_explicit, a fixed value that is distinct for each processor. The recommended format is
複数の暗号のプロセッサが送付者で使用中であるなら、送付者は特定のキー、一回だけの_の各値のために明白な状態でそれを確実にしなければなりません。それと共に使用されて、キーは異なっています。 この場合SHOULDが各プロセッサにおいて、異なった明白な一回だけの_a一定の価値に含むそれぞれの暗号化プロセッサ。 お勧めの形式はそうです。
nonce_explicit = FixedDistinct || Variable
一回だけの_明白な=FixedDistinct|| 変数
Salowey, et al. Standards Track [Page 4] RFC 5288 AES-GCM Cipher suites August 2008
Salowey、他 規格Track[4ページ]RFC5288AES-GCM Cipherスイート2008年8月
where the FixedDistinct field is distinct for each encryption processor, but is fixed for a given processor, and the Variable field is distinct for each distinct nonce used by a particular encryption processor. When this method is used, the FixedDistinct fields used by the different processors MUST have the same length.
FixedDistinct分野がそれぞれの暗号化プロセッサにおいて異なりますが、与えられたプロセッサのために固定されていて、特定の暗号化プロセッサによって使用されるそれぞれの異なった一回だけにおいて、Variable分野が異なっているところ。 この方法が使用されているとき、異なったプロセッサによって使用されるFixedDistinct分野は同じ長さを持たなければなりません。
In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common part of the nonce (it is fixed, and it is common across all encryption processors), the FixedDistinct field exactly corresponds to the Fixed-Distinct field, the Variable field corresponds to the Counter field, and the explicit part exactly corresponds to the nonce_explicit.
[RFC5116]の図2の用語で、Saltは一回だけのFixed一般的な部分(それは固定されています、そして、すべての暗号化プロセッサの向こう側に一般的である)です、そして、FixedDistinct分野はまさにFixed異なった分野に対応しています、そして、Variable分野はCounter分野に対応しています、そして、明白な部分はまさに一回だけの_に明白な状態で対応しています。
For clarity, we provide an example for TLS in which there are two distinct encryption processors, each of which uses a one-byte FixedDistinct field:
明快ために、私たちはそれのそれぞれが1バイトのFixedDistinct分野を使用する2台の異なった暗号化プロセッサがあるTLSのための例を提供します:
Salt = eedc68dc
FixedDistinct = 01 (for the first encryption processor)
FixedDistinct = 02 (for the second encryption processor)
01(最初の暗号化プロセッサのための)塩=eedc68dc FixedDistinct=FixedDistinct=02(2番目の暗号化プロセッサのための)
The GCMnonces generated by the first encryption processor, and their corresponding nonce_explicit, are:
最初の暗号化プロセッサ、および彼らの対応する一回だけ_によって明白な状態で発生したGCMnoncesは以下の通りです。
GCMNonce nonce_explicit
------------------------ ----------------------------
eedc68dc0100000000000000 0100000000000000
eedc68dc0100000000000001 0100000000000001
eedc68dc0100000000000002 0100000000000002
...
GCMNonceの一回だけの_明白です。------------------------ ---------------------------- eedc68dc0100000000000000 0100000000000000 eedc68dc0100000000000001 0100000000000001 eedc68dc0100000000000002 0100000000000002…
The GCMnonces generated by the second encryption processor, and their corresponding nonce_explicit, are
2番目の暗号化プロセッサ、および彼らの対応する一回だけ_によって明白な状態で発生したGCMnoncesがあります。
GCMNonce nonce_explicit
------------------------ ----------------------------
eedc68dc0200000000000000 0200000000000000
eedc68dc0200000000000001 0200000000000001
eedc68dc0200000000000002 0200000000000002
...
GCMNonceの一回だけの_明白です。------------------------ ---------------------------- eedc68dc0200000000000000 0200000000000000 eedc68dc0200000000000001 0200000000000001 eedc68dc0200000000000002 0200000000000002…
7. Acknowledgements
7. 承認
This document borrows heavily from [RFC5289]. The authors would like to thank Alex Lam, Simon Josefsson, and Pasi Eronen for providing useful comments during the review of this document.
このドキュメントは[RFC5289]から大いに借ります。 作者は、このドキュメントのレビューの間、役に立つコメントを提供して頂いて、アレックス・ラム、サイモンJosefsson、およびパシEronenに感謝したがっています。
Salowey, et al. Standards Track [Page 5] RFC 5288 AES-GCM Cipher suites August 2008
Salowey、他 規格Track[5ページ]RFC5288AES-GCM Cipherスイート2008年8月
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[AES] National Institute of Standards and Technology,
"Advanced Encryption Standard (AES)", FIPS 197,
November 2001.
2001年11月の[AES]米国商務省標準技術局、「エー・イー・エス(AES)」FIPS197。
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC",
National Institute of Standards and Technology SP 800-
38D, November 2007.
[GCM]ドーキン、M.、「ブロックのための推薦は運転モードを解きます」。 「ガロア/カウンタモード(GCM)とGMAC」、米国商務省標準技術局SP800- 38D、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月。
[RFC5116] McGrew, D., "An Interface and Algorithms for
Authenticated Encryption", RFC 5116, January 2008.
[RFC5116] マグリューと、D.と、「認証された暗号化のためのインタフェースとアルゴリズム」、RFC5116、1月2008日
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
[RFC5246] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2008年8月にバージョン1.2インチ、RFC5246について議定書の中で述べます」。
8.2. Informative References
8.2. 有益な参照
[IEEE8021AE] Institute of Electrical and Electronics Engineers,
"Media Access Control Security", IEEE Standard 802.1AE,
August 2006.
[IEEE8021AE]米国電気電子技術者学会、「メディアアクセス管理セキュリティ」、IEEEの標準の802.1AE、2006年8月。
[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月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
J., and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4366]ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、2006年4月。
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with
SHA-256/384 and AES Galois Counter Mode", RFC 5289,
August 2008.
[RFC5289]レスコラ、E.、「SHA-256/384とAESガロアカウンタモードがあるTLS楕円曲線暗号スイート」、RFC5289、2008年8月。
Salowey, et al. Standards Track [Page 6] RFC 5288 AES-GCM Cipher suites August 2008
Salowey、他 規格Track[6ページ]RFC5288AES-GCM Cipherスイート2008年8月
Authors' Addresses
作者のアドレス
Joseph Salowey Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA
ジョゼフSaloweyシスコシステムズInc.2901 3番目。 Aveワシントン98121シアトル(米国)
EMail: jsalowey@cisco.com
メール: jsalowey@cisco.com
Abhijit Choudhury Cisco Systems, Inc. 3625 Cisco Way San Jose, CA 95134 USA
AbhijitチョウドリシスコシステムズInc.3625コクチマスWayサンノゼ(カリフォルニア)95134米国
EMail: abhijitc@cisco.com
メール: abhijitc@cisco.com
David McGrew Cisco Systems, Inc. 170 W Tasman Drive San Jose, CA 95134 USA
デヴィッドマグリューシスコシステムズInc.170Wタスマン・Driveカリフォルニア95134サンノゼ(米国)
EMail: mcgrew@cisco.com
メール: mcgrew@cisco.com
Salowey, et al. Standards Track [Page 7] RFC 5288 AES-GCM Cipher suites August 2008
Salowey、他 規格Track[7ページ]RFC5288AES-GCM Cipherスイート2008年8月
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に情報を記述してください。
Salowey, et al. Standards Track [Page 8]
Salowey、他 標準化過程[8ページ]
一覧
スポンサーリンク
