RFC4305 日本語訳
4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH).D. Eastlake 3rd. December 2005. (Format: TXT=17991 bytes) (Obsoletes RFC2402, RFC2406) (Obsoleted by RFC4835) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Eastlake 3rd Request for Comments: 4305 Motorola Laboratories Obsoletes: 2404, 2406 December 2005 Category: Standards Track
コメントを求めるワーキンググループのD.イーストレーク第3要求をネットワークでつないでください: 4305のモトローラ研究所が以下を時代遅れにします。 2404、2406年2005年12月のカテゴリ: 標準化過程
Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) and Authentication Header (AH)
セキュリティが有効搭載量(超能力)であるとカプセル化するための暗号アルゴリズム実装要件と認証ヘッダー(ああ)
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time.
プロトコルのIPsecシリーズは、セキュリティー・サービスを提供するのに様々な暗号アルゴリズムを利用します。 Encapsulating Security有効搭載量(超能力)とAuthentication Header(AH)はIPsec Security Association(SA)の上に送られるデータを保護するのに2つのメカニズムを提供します。 異種の実装の間の相互運用性を確実にするために、義務的のセットを指定するのが必要です。-それを確実にするために、道具アルゴリズムには、すべての実装が利用可能にする少なくとも1つのアルゴリズムがあります。 このドキュメントはそれらが何らかの将来の時間義務的に促進されるかもしれないので実装されるべきであるアルゴリズムを指定することと同様に超能力とAHのために現在のセットの実装するために義務的なアルゴリズムを定義します。
Eastlake Standards Track [Page 1] RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
ああ、超能力と2005年12月のためのイーストレーク標準化過程[1ページ]RFC4305暗号アルゴリズム
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Terminology ........................................3
3. Algorithm Selection .............................................3
3.1. Encapsulating Security Payload .............................3
3.1.1. ESP Encryption and Authentication Algorithms ........4
3.1.2. ESP Combined Mode Algorithms ........................4
3.2. Authentication Header ......................................5
4. Security Considerations .........................................5
5. Acknowledgement .................................................5
6. Changes from RFC 2402 and 2406 ..................................6
7. Normative References ............................................6
8. Informative References ..........................................7
1. 序論…2 2. 要件用語…3 3. アルゴリズム選択…3 3.1. セキュリティが有効搭載量であるとカプセル化します…3 3.1.1. 超能力暗号化と認証アルゴリズム…4 3.1.2. 超能力はモードアルゴリズムを結合しました…4 3.2. 認証ヘッダー…5 4. セキュリティ問題…5 5. 承認…5 6. RFC2402と2406年からの変化…6 7. 標準の参照…6 8. 有益な参照…7
1. Introduction
1. 序論
The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA) [IPsec, ESP, AH]. To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to- implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time.
Encapsulating Security有効搭載量(超能力)とAuthentication Header(AH)はIPsec Security Association(SA)[IPsec、超能力、AH]の上に送られるデータを保護するのに2つのメカニズムを提供します。 異種の実装の間の相互運用性を確実にするために、すべての実装が利用可能にする少なくとも1つのアルゴリズムがあるのを保証するために1セットの実装するために義務的なアルゴリズムを指定するのが必要です。 このドキュメントは義務的の現在のセットを定義します。-道具に、それらがいつかの未来義務的に促進されるかもしれないので実装されるべきであるアルゴリズムを指定することと同様に超能力とAHのためのアルゴリズムは調節されます。
The nature of cryptography is that new algorithms surface continuously and existing algorithms are continuously attacked. An algorithm believed to be strong today may be demonstrated to be weak tomorrow. Given this, the choice of mandatory-to-implement algorithm should be conservative so as to minimize the likelihood of it being compromised quickly. Thought should also be given to performance considerations as many uses of IPsec will be in environments where performance is a concern.
暗号の本質は絶え間なくその新しいアルゴリズムの表面です、そして、既存のアルゴリズムは絶え間なく攻撃されます。 今日の強いと信じられているアルゴリズムは、明日弱くなるように示されるかもしれません。 これを考えて、実装するために義務的なアルゴリズムの選択は、それの見込みを最小にするためにすぐに感染されながら、保守的であるべきです。 また、環境にはIPsecの多くの用途が性能が関心であるところにあるので、性能問題に考えを与えるべきです。
Finally, we need to recognize that the mandatory-to-implement algorithm(s) may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms is not included the main IPsec, ESP, or AH specifications. It is instead placed in this document. As the choice of algorithm changes, only this document should need to be updated.
最終的に、私たちは、実装するために義務的なアルゴリズムが、時間がたつにつれて変化世界に順応するために変化する必要であるかもしれないと認める必要があります。 アルゴリズムはこの理由、実装するために義務的の選択のための、そうです。主なIPsec、超能力、またはAH仕様を含んでいませんでした。 それは代わりに本書では置かれます。 アルゴリズム変化の選択として、このドキュメントだけが、アップデートする必要があるはずです。
Ideally, the mandatory-to-implement algorithm of tomorrow should already be available in most implementations of IPsec by the time it is made mandatory. To facilitate this, we will attempt to identify such algorithms (as they are known today) in this document. There is
理想的に、明日の実装するために義務的なアルゴリズムはそれを義務的にする時までにIPsecのほとんどの実装で既に利用可能であるべきです。 これを容易にするために、私たちは、本書では、そのようなアルゴリズム(それらが今日知られているように)を特定するのを試みるつもりです。 あります。
Eastlake Standards Track [Page 2] RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
ああ、超能力と2005年12月のためのイーストレーク標準化過程[2ページ]RFC4305暗号アルゴリズム
no guarantee that the algorithms we believe today may be mandatory in the future will in fact become so. All algorithms known today are subject to cryptographic attack and may be broken in the future.
したがって、事実上、私たちが今日信じているアルゴリズムが将来義務的であるかもしれないという保証は全くならないでしょう。 今日知られているすべてのアルゴリズムが、暗号の攻撃を受けることがあって、将来、壊れているかもしれません。
2. Requirements Terminology
2. 要件用語
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」 現れる「5月」は中[RFC2119]で説明されるように本書では解釈されることになっているべきです。
We define some additional terms here:
私たちはここでいくつかの追加用語を定義します:
SHOULD+ This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD+ will be
promoted at some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD- will be
deprecated to a MAY or worse in a future version of this
document.
MUST- This term means the same as MUST. However, we expect
that at some point in the future this algorithm will no
longer be a MUST.
SHOULD+This用語はSHOULDと同じであることを意味します。 aはそうしなければなりません。しかしながら、SHOULD+意志としてマークされたアルゴリズムはSHOULDが、今期にSHOULDと同じであることを意味するということである何らかの将来の時間に促進されそうです。 しかしながら、SHOULDとしてマークされたアルゴリズムがこのドキュメントの将来のバージョンで5月に推奨しないか、または、より悪くなるのは、ありそうです。 -、今期が同じであることを意味する. しかしながら、私たちは、このアルゴリズムがもうaにならない未来の何らかのポイントのそれがそうしなければならないと予想しなければなりません。
3. Algorithm Selection
3. アルゴリズム選択
For IPsec implementations to interoperate, they must support one or more security algorithms in common. This section specifies the security algorithm implementation requirements for standards- conformant ESP and AH implementations. The security algorithms actually used for any particular ESP or AH security association are determined by a negotiation mechanism, such as the Internet Key Exchange (IKE [RFC2409, IKEv2]) or pre-establishment.
IPsec実装が共同利用するために、それらは一般的の1つ以上のセキュリティアルゴリズムをサポートしなければなりません。 このセクションは規格conformant超能力とAH実装のためのセキュリティアルゴリズム実装要件を指定します。 どんな特定の超能力やAHセキュリティ協会にも実際に使用されるセキュリティアルゴリズムは交渉メカニズムで決定します、インターネット・キー・エクスチェンジ(IKE[RFC2409、IKEv2])やプレ設立のように。
Of course, additional standard and proprietary algorithms beyond those listed below can be implemented.
もちろん、以下に記載されたものを超えた追加標準の、そして、独占であるアルゴリズムを実装することができます。
3.1. Encapsulating Security Payload
3.1. セキュリティが有効搭載量であるとカプセル化します。
The implementation conformance requirements for security algorithms for ESP are given in the tables below. See Section 2 for definitions of the values in the "Requirement" column.
テーブルで超能力のためのセキュリティアルゴリズムのための実装順応要件を以下に与えます。 「要件」コラムとの値の定義に関してセクション2を見てください。
Eastlake Standards Track [Page 3] RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
ああ、超能力と2005年12月のためのイーストレーク標準化過程[3ページ]RFC4305暗号アルゴリズム
3.1.1. ESP Encryption and Authentication Algorithms
3.1.1. 超能力暗号化と認証アルゴリズム
These tables list encryption and authentication algorithms for the IPsec Encapsulating Security Payload protocol.
これらのテーブルはIPsec Encapsulating Security有効搭載量プロトコルのために暗号化と認証アルゴリズムを記載します。
Requirement Encryption Algorithm (notes)
----------- --------------------
MUST NULL (1)
MUST- TripleDES-CBC [RFC2451]
SHOULD+ AES-CBC with 128-bit keys [RFC3602]
SHOULD AES-CTR [RFC3686]
SHOULD NOT DES-CBC [RFC2405] (3)
要件暗号化アルゴリズム(注意)----------- -------------------- MUST NULL(1)、-、128ビットのキー[RFC3602]SHOULD AES-CTR[RFC3686]SHOULD NOT DES-CBC[RFC2405]とTripleDES-CBC[RFC2451]SHOULD+AES-CBCでなければならない(3)
Requirement Authentication Algorithm (notes)
----------- ------------------------
MUST HMAC-SHA1-96 [RFC2404]
MUST NULL (1)
SHOULD+ AES-XCBC-MAC-96 [RFC3566]
MAY HMAC-MD5-96 [RFC2403] (2)
要件認証アルゴリズム(注意)----------- ------------------------ 必須HMAC-SHA1-96[RFC2404]必須ヌル(1)がそうするべきである、+ AES-XCBC Mac96[RFC3566]5月のHMAC-MD5-96[RFC2403](2)
Notes:
注意:
(1) Since ESP encryption and authentication are optional, support for
the two "NULL" algorithms is required to maintain consistency
with the way these services are negotiated. Note that while
authentication and encryption can each be "NULL", they MUST NOT
both be "NULL".
(2) Weaknesses have become apparent in MD5; however, these should not
affect the use of MD5 with HMAC.
(3) DES, with its small key size and publicly demonstrated and open-
design special-purpose cracking hardware, is of questionable
security for general use.
(1) 超能力暗号化と認証が任意であるので、2つの「ヌル」のアルゴリズムのサポートがこれらのサービスが交渉される方法がある一貫性を維持するのに必要です。 認証と暗号化がそれぞれ「ヌルであることができる」間それらがともに「ヌルであってはいけない」と述べてください。 (2) 弱点はMD5で明らかになりました。 しかしながら、これらはHMACとのMD5の使用に影響するべきではありません。 (3) その小さい主要なサイズと公的に示されて、開いているデザイン特別な目的分解ハードウェアで、DESは一般的使用のために疑わしく安全です。
3.1.2. ESP Combined Mode Algorithms
3.1.2. 超能力の結合したモードアルゴリズム
As specified in [ESP], combined mode algorithms are supported that provide both confidentiality and authentication services. Support of such algorithms will require proper structuring of ESP implementations. Under many circumstances, combined mode algorithms provide significant efficiency and throughput advantages. Although there are no suggested or required combined algorithms at this time, AES-CCM [CCM], which has been adopted as the preferred mode for security in IEEE 802.11 [802.11i], is expected to be of interest in the near future.
[超能力]で指定されるように、秘密性と認証サービスの両方を提供する結合したモードアルゴリズムがサポートされます。 そのようなアルゴリズムのサポートは超能力実装の適切な構造を必要とするでしょう。 多くの状況で、結合したモードアルゴリズムは重要な効率とスループット利点を提供します。 このとき、どんな示されたか必要な結合したアルゴリズムもありませんが、近い将来、AES-CCM[CCM](IEEE802.11[802.11i]のセキュリティのための最もよく使われる方法として採用された)は興味があると予想されます。
Eastlake Standards Track [Page 4] RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
ああ、超能力と2005年12月のためのイーストレーク標準化過程[4ページ]RFC4305暗号アルゴリズム
3.2. Authentication Header
3.2. 認証ヘッダー
The implementation conformance requirements for security algorithms for AH are given below. See Section 2 for definitions of the values in the "Requirement" column. As you would suspect, all of these algorithms are authentication algorithms.
AHのためのセキュリティアルゴリズムのための実装順応要件を以下に与えます。 「要件」コラムとの値の定義に関してセクション2を見てください。 あなたが疑うように、これらのアルゴリズムのすべてが認証アルゴリズムです。
Requirement Algorithm (notes)
----------- ---------
MUST HMAC-SHA1-96 [RFC2404]
SHOULD+ AES-XCBC-MAC-96 [RFC3566]
MAY HMAC-MD5-96 [RFC2403] (1)
要件アルゴリズム(注意)----------- --------- 必須HMAC-SHA1-96[RFC2404]がそうするべきである、+ AES-XCBC Mac96[RFC3566]5月のHMAC-MD5-96[RFC2403](1)
Note:
以下に注意してください。
(1) Weaknesses have become apparent in MD5; however, these should not
affect the use of MD5 with HMAC.
(1) 弱点はMD5で明らかになりました。 しかしながら、これらはHMACとのMD5の使用に影響するべきではありません。
4. Security Considerations
4. セキュリティ問題
The security of cryptographic-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering and administration of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.
暗号ベースのシステムのセキュリティは選ばれた暗号アルゴリズムの強さとそれらのアルゴリズムで使用されるキーの強さの両方に依存します。また、セキュリティはシステムによって使用される、総合体系のセキュリティを迂回させるどんな非暗号の方法もないのを保証するプロトコルの工学と管理に頼っています。
This document concerns itself with the selection of cryptographic algorithms for the use of ESP and AH, specifically with the selection of mandatory-to-implement algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research so far leads us to believe that they will likely remain secure into the foreseeable future. However, this is not necessarily forever. We would therefore expect that new revisions of this document will be issued from time to time that reflect the current best practice in this area.
このドキュメントは超能力とAHの使用のための暗号アルゴリズムの品揃えに携わります、そして、特に実装するために義務的の選択で. アルゴリズムが本書では「実装しなければならない」ように特定したか、または「SHOULDは実装する」アルゴリズムを現在の時間に壊れさせるのは知られないで、暗号の研究は今までのところ、私たちが、それらが予見できる未来までおそらく安全なままで残ると信じているように導きます。 しかしながら、必ずいつまでも、これはそうではありません。したがって、私たちは、現在のこの領域で最も良い習慣を反映するこのドキュメントの新しい改正が時々発行されると予想するでしょう。
5. Acknowledgement
5. 承認
Much of the wording herein was adapted from RFC 4307, "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2", by Jeffrey I. Schiller.
言葉遣いの多くがRFC4307「インターネットキーにおける使用のための暗号アルゴリズムはバージョン2インチを交換します、ジェフリー・I.シラー」ここに適合させられました。
Eastlake Standards Track [Page 5] RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
ああ、超能力と2005年12月のためのイーストレーク標準化過程[5ページ]RFC4305暗号アルゴリズム
6. Changes from RFC 2402 and 2406
6. RFC2402と2406年からの変化
[RFC2402] and [RFC2406] defined the IPsec Authentication Header and IPsec Encapsulating Security Payload. Each specified the implementation requirements for cryptographic algorithms for their respective protocols. They have now been replaced with [AH] and [ESP], which do not specify cryptographic algorithm implementation requirements, and this document, which specifies such requirements for both [AH] and [ESP].
[RFC2402]と[RFC2406]はIPsec Authentication HeaderとIPsec Encapsulating Security有効搭載量を定義しました。 それぞれがそれらのそれぞれのプロトコルに暗号アルゴリズムのための実装要件を指定しました。 現在、それらを[AH]と[超能力]に取り替えました。(それは、暗号アルゴリズム実装要件、およびこのドキュメントを指定しません)。(それは、[AH]と[超能力]の両方のためのそのような要件を指定します)。
The implementation requirements are compared below:
実装要件は以下と比較されます:
Old Old New Req. RFC(s) Requirement Algorithm (notes) --- ------ ----------- --------- MUST 2406 SHOULD NOT DES-CBC [RFC2405] (1) MUST 2402 2406 MAY HMAC-MD5-96 [RFC2403] MUST 2402 2406 MUST HMAC-SHA1-96 [RFC2404]
後期高齢者の新しいReq。 RFC(s)要件アルゴリズム(注意)--- ------ ----------- --------- デス-CBC[RFC2405](1)必須2402 2406 5月のHMAC-MD5-96[RFC2403]必須2402 2406必須HMAC-SHA1-96ではなく、2406がそうするべきである必須[RFC2404]
Note:
以下に注意してください。
(1) The IETF deprecated the use of single DES years ago and has not
included it in any new standard for some time (see IESG note on
the first page of [RFC2407]). But this document represents the
first standards-track recognition of that deprecation by
specifying that implementations SHOULD NOT provide single DES.
The US Government National Institute of Standards and Technology
(NIST) has formally recognized the weakness of single DES by a
notice published in the 26 July 2004 US Government Federal
Register (Docket No. 040602169-4169-01) proposing to withdraw it
as a US Government Standard. Triple DES remains approved by both
the IETF and NIST.
(1) IETF、推奨しなさ、いずれでも新しい状態でそれを単一のDES年前を使用して、しばらく標準で([RFC2407]の最初のページでのIESG注意を見ます)含んでいません。 しかし、実装SHOULD NOTが独身のDESを提供すると指定することによって、このドキュメントはその不賛成の最初の標準化過程認識を表します。 米国政府米国商務省標準技術局(NIST)は米国政府Standardとしてそれを引っ込めるよう提案しながら2004年7月26日の米国政府官報(訴訟事件表No.040602169-4169-01)で発表された通知で正式に独身のDESの弱点を認識しました。 三重のDESはIETFとNISTの両方によって承認されたままで残っています。
7. Normative References
7. 引用規格
[AH] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[ああ] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[超能力] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[IPsec] Kent, S., "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[IPsec] ケント、S.、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[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月。
Eastlake Standards Track [Page 6] RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
ああ、超能力と2005年12月のためのイーストレーク標準化過程[6ページ]RFC4305暗号アルゴリズム
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
そして、[RFC2403] マドソン、C.、およびR.グレン、「超能力の中のHMAC-MD5-96の使用、ああ、」、RFC2403、11月1998日
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
そして、[RFC2404] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405] マドソンとC.とN.Doraswamy、「明白なIVがある超能力DES-CBC暗号アルゴリズム」、RFC2405、1998年11月。
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
Algorithm and Its Use With IPsec", RFC 3566, September
2003.
[RFC3566] フランケル、S.、H.ハーバート、および「AES-XCBC-MAC-96アルゴリズムとIPsecとのその使用」、RFC3566、9月2003日
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September
2003.
[RFC3602] フランケル、S.、グレン、R.、およびS.ケリー、「AES-CBCはIPsecと共にアルゴリズムとその使用を解きます」、RFC3602、2003年9月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC3686]Housley、R.、「IPsecが、セキュリティが有効搭載量(超能力)であるとカプセル化しているエー・イー・エス(AES)カウンタモードを使用します」、RFC3686、2004年1月。
8. Informative References
8. 有益な参照
[802.11i] LAN/MAN Specific Requirements Part 11: Wireless Medium
Access Control (MAC) and physical layer (PHY)
specifications: Medium Access Control (MAC) Security
Enhancements, IEEE Std 802.11i, June 2004.
[802.11i]LAN/男性決められた一定の要求は11を分けます: ワイヤレスのMedium Access Control(MAC)と物理的な層(PHY)の仕様: 媒体アクセス制御(MAC)セキュリティ増進、IEEE Std 802.11i、2004年6月。
[JIS] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[JIS] シラー、J.、「インターネット・キー・エクスチェンジバージョン2(IKEv2)における使用のための暗号アルゴリズム」、RFC4307、2005年12月。
[CCM] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[立方センチメートル]Housley、R.、「IPsecが、セキュリティが有効搭載量(超能力)であるとカプセル化しているエー・イー・エス(AES)カウンタモードを使用します」、RFC3686、2004年1月。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[IKEv2] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
Eastlake Standards Track [Page 7] RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
ああ、超能力と2005年12月のためのイーストレーク標準化過程[7ページ]RFC4305暗号アルゴリズム
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
Author's Address
作者のアドレス
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ研究所155ビーバー通りMA01757ミルフォード(米国)
Phone: +1-508-786-7554 (w)
+1-508-634-2066 (h)
EMail: Donald.Eastlake@Motorola.com
以下に電話をしてください。 +1-508-786-7554 (w) +1-508-634-2066 (h) メールしてください: Donald.Eastlake@Motorola.com
Eastlake Standards Track [Page 8] RFC 4305 Cryptographic Algorithms for ESP & AH December 2005
ああ、超能力と2005年12月のためのイーストレーク標準化過程[8ページ]RFC4305暗号アルゴリズム
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 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機能のための基金は現在、インターネット協会によって提供されます。
Eastlake Standards Track [Page 9]
イーストレーク標準化過程[9ページ]
一覧
スポンサーリンク
