RFC4835 日本語訳
4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH).V. Manral. April 2007. (Format: TXT=21492 bytes) (Obsoletes RFC4305) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Manral Request for Comments: 4835 IP Infusion Inc. Obsoletes: 4305 April 2007 Category: Standards Track
Manralがコメントのために要求するワーキンググループV.をネットワークでつないでください: 株式会社が時代遅れにする4835年のIP注入: 4305 2007年4月のカテゴリ: 標準化過程
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 IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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のために現在のセットの実装するために義務的なアルゴリズムを定義します。
Manral Standards Track [Page 1] RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Manral規格がRFC4835暗号アルゴリズムを追跡する、[1ページ]ああ、超能力と2007年4月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Encapsulating Security Payload . . . . . . . . . . . . . . 4
3.1.1. ESP Encryption and Authentication Algorithms . . . . . 4
3.1.2. ESP Combined Mode Algorithms . . . . . . . . . . . . . 5
3.2. Authentication Header . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. Changes from RFC 2402 and RFC 2406 to RFC 4305 . . . . . . . . 7
7. Changes from RFC 4305 . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 要件用語. . . . . . . . . . . . . . . . . . . 3 3 アルゴリズム選択. . . . . . . . . . . . . . . . . . . . . . 4 3.1。 セキュリティ有効搭載量. . . . . . . . . . . . . . 4 3.1が.1であるとカプセル化します。 超能力暗号化と認証アルゴリズム. . . . . 4 3.1.2。 超能力はモードアルゴリズム. . . . . . . . . . . . . 5 3.2を結合しました。 認証ヘッダー. . . . . . . . . . . . . . . . . . . 5 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 6 5。 承認. . . . . . . . . . . . . . . . . . . . . . . 6 6。 RFC2402とRFC2406からのRFC4305.7 7への変化。 RFC4305.7 8からの変化。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 8 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 9
Manral Standards Track [Page 2] RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Manral規格がRFC4835暗号アルゴリズムを追跡する、[2ページ]ああ、超能力と2007年4月
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) [RFC4301], [RFC4302]. 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)[RFC4301][RFC4302]の上に送られるデータを保護するのに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 in 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 no guarantee that the algorithms that we (today) believe 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.
理想的に、明日の実装するために義務的なアルゴリズムはそれを義務的にする時までにIPsecのほとんどの実装で既に利用可能であるべきです。 これを容易にするために、私たちは、本書では、そのようなアルゴリズム(それらが今日知られているように)を特定するのを試みるつもりです。 したがって、事実上、私たち(今日)が将来義務的であるかもしれないと信じているアルゴリズムがなるという保証が全くありません。 今日知られているすべてのアルゴリズムが、暗号の攻撃を受けることがあって、将来、壊れているかもしれません。
2. Requirements Terminology
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]で説明されるように本書では解釈されることであるべきですか?
Manral Standards Track [Page 3] RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Manral規格がRFC4835暗号アルゴリズムを追跡する、[3ページ]ああ、超能力と2007年4月
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用語はSHOULDと同じであることを意味します。 しかしながら、SHOULD+がaである何らかの将来の時間に促進されるのでマークされたアルゴリズムはそうしなければならなそうです。
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.
SHOULDは、今期にSHOULDと同じであることを意味します。 しかしながら、SHOULDとしてマークされたアルゴリズムがこのドキュメントの将来のバージョンで5月に推奨しないか、または、より悪くなるのは、ありそうです。
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.
-、今期が同じであることを意味する. しかしながら、私たちは、このアルゴリズムがもう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], [RFC4306]) or pre-establishment.
IPsec実装が共同利用するために、それらは一般的の1つ以上のセキュリティアルゴリズムをサポートしなければなりません。 このセクションは規格conformant超能力とAH実装のためのセキュリティアルゴリズム実装要件を指定します。 どんな特定の超能力やAHセキュリティ協会にも実際に使用されるセキュリティアルゴリズムは交渉メカニズムで決定します、インターネット・キー・エクスチェンジ(IKE[RFC2409]、[RFC4306])やプレ設立のように。
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を見てください。
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 [RFC2410] (1)
MUST AES-CBC with 128-bit keys [RFC3602]
MUST- TripleDES-CBC [RFC2451]
SHOULD AES-CTR [RFC3686]
SHOULD NOT DES-CBC [RFC2405] (2)
要件暗号化アルゴリズム(注意)----------- -------------------------- 128ビットのキー[RFC3602]があるMUST NULL[RFC2410](1)MUST AES-CBC、-、TripleDES-CBC[RFC2451]SHOULD AES-CTR[RFC3686]SHOULD NOT DES-CBCでなければならない[RFC2405](2)
Manral Standards Track [Page 4] RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Manral規格がRFC4835暗号アルゴリズムを追跡する、[4ページ]ああ、超能力と2007年4月
Requirement Authentication Algorithm (notes)
----------- -----------------------------
MUST HMAC-SHA1-96 [RFC2404] (3)
SHOULD+ AES-XCBC-MAC-96 [RFC3566]
MAY NULL (1)
MAY HMAC-MD5-96 [RFC2403] (4)
要件認証アルゴリズム(注意)----------- ----------------------------- 必須HMAC-SHA1-96[RFC2404](3)がそうするべきである、+ AES-XCBC Mac96[RFC3566]5月のヌル(1)5月のHMAC-MD5-96[RFC2403](4)
Notes:
注意:
(1) Since ESP encryption is optional, support for the "NULL"
algorithm is required to maintain consistency with the way
services are negotiated. Note that while authentication and
encryption can each be "NULL", they MUST NOT both be "NULL"
[RFC4301].
(1) 超能力暗号化が任意であるので、「ヌル」のアルゴリズムのサポートがサービスが交渉される方法がある一貫性を維持するのに必要です。 認証と暗号化がそれぞれ「ヌルであることができる」間それらがともに「ヌル」[RFC4301]であるはずがないと述べてください。
(2) DES, with its small key size and publicly demonstrated and
open-design special-purpose cracking hardware, is of questionable
security for general use.
(2) その小さい主要なサイズと公的に示されて、開いているデザインの専用分解ハードウェアで、DESは一般的使用のために疑わしく安全です。
(3) Weaknesses have become apparent in SHA-1 [SHA1-COLL]; however,
these should not affect the use of SHA1 with HMAC.
(3) 弱点はSHA-1[SHA1-コル]で明らかになりました。 しかしながら、これらはHMACとのSHA1の使用に影響するべきではありません。
(4) Weaknesses have become apparent in MD5 [MD5-COLL]; however,
these should not affect the use of MD5 with HMAC.
(4) 弱点はMD5[MD5-コル]で明らかになりました。 しかしながら、これらはHMACとのMD5の使用に影響するべきではありません。
3.1.2. ESP Combined Mode Algorithms
3.1.2. 超能力の結合したモードアルゴリズム
As specified in [RFC4303], 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 [RFC4309] and AES-GCM [RFC4106] are of interest. AES-CCM has been adopted as the preferred mode in IEEE 802.11 [802.11i], and AES- GCM has been adopted as the preferred mode in IEEE 802.1ae [802.1ae].
[RFC4303]で指定されるように、秘密性と認証サービスの両方を提供する結合したモードアルゴリズムがサポートされます。 そのようなアルゴリズムのサポートは超能力実装の適切な構造を必要とするでしょう。 多くの状況で、結合したモードアルゴリズムは重要な効率とスループット利点を提供します。 このとき、どんな示されたか必要な結合したアルゴリズムもありませんが、AES-CCM[RFC4309]とAES-GCM[RFC4106]は興味があります。 AES-CCMはIEEE802.11[802.11i]の最もよく使われる方法として採用されました、そして、AES- GCMはIEEE 802.1ae[802.1ae]の最もよく使われる方法として採用されました。
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を見てください。 あなたが疑うように、これらのアルゴリズムのすべてが認証アルゴリズムです。
Manral Standards Track [Page 5] RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Manral規格がRFC4835暗号アルゴリズムを追跡する、[5ページ]ああ、超能力と2007年4月
Requirement Algorithm (notes)
----------- ----------------
MUST HMAC-SHA1-96 [RFC2404] (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)
Note:
以下に注意してください。
(1) Weaknesses have become apparent in SHA-1 [SHA1-COLL]; however,
these should not affect the use of SHA1 with HMAC.
(1) 弱点はSHA-1[SHA1-コル]で明らかになりました。 しかしながら、これらはHMACとのSHA1の使用に影響するべきではありません。
(2) Weaknesses have become apparent in MD5 [MD5-COLL]; however,
these should not affect the use of MD5 with HMAC.
(2) 弱点はMD5[MD5-コル]で明らかになりました。 しかしながら、これらはHMACとのMD5の使用に影響するべきではありません。
4. Security Considerations
4. セキュリティ問題
The security of cryptography-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. Acknowledgements
5. 承認
Much of the wording herein was adapted from RFC 4305, the parent document of this document. RFC 4305 itself borrows text from [RFC4307], "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2", by Jeffrey I. Schiller.
言葉遣いの多くがRFC4305、このドキュメントの親ドキュメントからここに適合させられました。 RFC4305自身は[RFC4307]「インターネットキーにおける使用のための暗号アルゴリズムはバージョン2インチを交換します、ジェフリー・I.シラー」テキストを借ります。
Thanks to the following people for reporting or responding to reports of the errors in RFC 4305: Paul Hoffman, Stephen Kent, Paul Koning, and Lars Volker. Helpful Last-Call comments were received from Russ Housley, Elwyn Davies, Nicolas Williams, and Alfred Hoenes.
RFC4305で誤りのレポートに報告してくださってありがとうございますか、または以下の人々に応じてくださってありがとうございます: ポール・ホフマン、スティーブン・ケント、ポール・コウニング、およびラース・ボルカー。 ラスHousley、Elwynデイヴィース、ニコラス・ウィリアムズ、およびアルフレッドHoenesから役立っているLast-呼び出しコメントを受けました。
Manral Standards Track [Page 6] RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Manral規格がRFC4835暗号アルゴリズムを追跡する、[6ページ]ああ、超能力と2007年4月
6. Changes from RFC 2402 and RFC 2406 to RFC 4305
6. RFC2402とRFC2406からRFC4305までの変化
[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 [RFC4302] and [RFC4303], which do not specify cryptographic algorithm implementation requirements, and this document, which specifies such requirements for both [RFC4302] and [RFC4303].
[RFC2402]と[RFC2406]はIPsec Authentication HeaderとIPsec Encapsulating Security有効搭載量を定義しました。 それぞれがそれらのそれぞれのプロトコルに暗号アルゴリズムのための実装要件を指定しました。 現在、それらを[RFC4302]と[RFC4303]とこのドキュメントに取り替えました。(]は暗号アルゴリズム実装要件を指定しません)。(それは、[RFC4302]と[RFC4303]の両方のためのそのような要件を指定します)。
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]). [RFC4305] represented 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
[DES-WDRAW] 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を提供すると指定することによって、[RFC4305]はその不賛成の最初の標準化過程認識を表しました。 米国政府米国商務省標準技術局(NIST)は米国政府Standardとしてそれを引っ込めるよう提案しながら発表された[デス-WDRAW]通知で正式に独身のDESの弱点を認識しました。 三重のDESはIETFとNISTの両方によって承認されたままで残っています。
7. Changes from RFC 4305
7. RFC4305からの変化
This document obsoletes [RFC4305]. The document incorporates changes for the support for the NULL Authentication Algorithm making the support from a MUST to a MAY. This change is made to make this document consistent with [RFC4301]. Text for SHA-1 collision attacks as well as the future use of AES-GCM and AES-CCM is added.
このドキュメントは[RFC4305]を時代遅れにします。 ドキュメントはaからサポートをすると5月までそうしなければならないNULL Authentication Algorithmのサポートのために変化を取り入れます。 この変更でこのドキュメントが[RFC4301]と一致するようになると行われます。 未来と同様に攻撃が使用するAES-GCMとAES-CCMのSHA-1衝突のためのテキストは加えられます。
Manral Standards Track [Page 7] RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Manral規格がRFC4835暗号アルゴリズムを追跡する、[7ページ]ああ、超能力と2007年4月
The changed implementation requirement resulting from the above changes is listed below:
上の変化から生じる変えられた実装要件は以下にリストアップされています:
Old Old New
Req. RFC(s) Requirement Algorithm (notes)
---- ------ ----------- -----------------
MUST 2406 MAY NULL Authentication
MUST 2406 MUST NULL Encryption
SHOULD+ 4305 MUST AES-CBC Encryption
後期高齢者の新しいReq。 RFC(s)要件アルゴリズム(注意)---- ------ ----------- ----------------- 必須2406の5月のヌル認証必須2406必須ヌル暗号化がそうするべきである、+ 4305年の必須AES-CBC暗号化
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP14, RFC2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm
and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410] グレン、R.、S.ケント、および「ヌル暗号化アルゴリズムとIPsecとのその使用」、RFC2410、11月1998日
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC2451] ペレイラとR.とR.アダムス、「超能力CBC-モード暗号アルゴリズム」、RFC2451、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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302
Manral Standards Track [Page 8] RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Manral規格がRFC4835暗号アルゴリズムを追跡する、[8ページ]ああ、超能力と2007年4月
December 2005.
2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP)
and Authentication Header (AH)", RFC 4305,
December 2005.
[RFC4305] イーストレーク、D.、「セキュリティが有効搭載量(超能力)と認証ヘッダー(ああ)であるとカプセル化するための暗号アルゴリズム実装要件」、RFC4305、2005年12月。
8.2. Informative References
8.2. 有益な参照
[802.11i] "LAN/MAN Specific Requirements Part 11: Wireless Medium
Access Control (MAC) and physical layer (PHY)
specifications", IEEE Standard Medium Access Control
(MAC) Security, IEEE Std 802.11i, June 2004.
[802.11i] 「LAN/男性決められた一定の要求は11を分けます」。 「ワイヤレスのMedium Access Control(MAC)と物理的な層(PHY)の仕様」、IEEE Standard Medium Access Control(MAC)セキュリティ、IEEE Std 802.11i(2004年6月)。
[802.1ae] "Media Access Control (MAC) Security", IEEE
Standard Medium Access Control (MAC) Security, IEEE Std
802.1ae, June 2006.
[802.1ae]「メディアアクセス制御(MAC)セキュリティ」、IEEEの標準の媒体アクセス制御(MAC)セキュリティ、IEEE Std 802.1ae、2006年6月。
[DES-WDRAW] "Announcing Proposed Withdrawal of Federal Information
Processing Standard (FIPS) for the Data Encryption
Standard (DES) and Request for Comments", FIPS
Notice Docket No. 040602169-4169-01, July 2004.
[デス-WDRAW] 「コメントを求めるデータ暗号化規格(DES)と要求のために連邦情報処理基準(FIPS)の提案された退出を発表し」て、FIPSは訴訟事件表No.040602169-4169-01(2004年7月)に気付きます。
[MD5-COLL] Klima, V., "Finding MD5 Collisions - a Toy For a
Notebook", Cryptology ePrint Archive Medium Report 2005/
075, March 2005.
[MD5-コル] クリマ、V.、「MD5に衝突を見つけます--aはノートのために遊びます」、暗号理論のePrintのアーカイブの中型のレポート2005/ 075、2005年3月。
[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月。
[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月。
[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月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、2005年12月。
Manral Standards Track [Page 9] RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Manral規格がRFC4835暗号アルゴリズムを追跡する、[9ページ]ああ、超能力と2007年4月
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[RFC4307] シラー、J.、「インターネット・キー・エクスチェンジバージョン2(IKEv2)における使用のための暗号アルゴリズム」、RFC4307、2005年12月。
[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月。
[SHA1-COLL] Rijmen, V. and E. Oswald, "Update on SHA-1", Cryptology
ePrint Archive Report 2005/010, January 2005.
[SHA1-コル]Rijmen(V.とE.オスワルド)は「SHA-1インチ、暗号理論ePrintでは、アーカイブレポート2005/010、2005年1月に、アップデートします」。
Author's Address
作者のアドレス
Vishwas Manral IP Infusion Inc. Bamankhola, Bansgali, Almora, Uttarakhand 263601 India
Vishwas Manral IP注入株式会社Bamankhola、Bansgali、アルモラUttarakhand263601インド
Phone: +91-98456-61911 EMail: vishwas@ipinfusion.com
以下に電話をしてください。 +91-98456-61911はメールされます: vishwas@ipinfusion.com
Manral Standards Track [Page 10] RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Manral規格がRFC4835暗号アルゴリズムを追跡する、[10ページ]ああ、超能力と2007年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Manral Standards Track [Page 11]
Manral標準化過程[11ページ]
一覧
スポンサーリンク
