[要約] RFC 4835は、ESPとAHの暗号アルゴリズムの実装要件に関するものであり、セキュリティプロトコルの安全性と互換性を確保するためのガイドラインを提供します。目的は、ネットワークセキュリティの向上と、ESPとAHの実装に関する一貫性と信頼性の確保です。
Network Working Group V. Manral
Request for Comments: 4835 IP Infusion Inc.
Obsoletes: 4305 April 2007
Category: Standards Track
Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
セキュリティペイロード（ESP）および認証ヘッダー（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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（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シリーズのプロトコルは、セキュリティサービスを提供するために、さまざまな暗号化アルゴリズムを利用しています。カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）は、IPsecセキュリティアソシエーション（SA）経由で送信されるデータを保護するための2つのメカニズムを提供します。異種の実装間の相互運用性を確保するには、実装に必須のアルゴリズムのセットを指定して、すべての実装で使用可能なアルゴリズムが少なくとも1つあることを確認する必要があります。このドキュメントでは、ESPとAHの実装に必須のアルゴリズムの現在のセットを定義し、将来的には必須に昇格する可能性があるため実装する必要があるアルゴリズムを指定します。
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
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.
カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）は、IPsecセキュリティアソシエーション（SA）[RFC4301]、[RFC4302]経由で送信されるデータを保護するための2つのメカニズムを提供します。異種の実装間の相互運用性を確保するには、実装に必須のアルゴリズムのセットを指定して、すべての実装で使用可能なアルゴリズムが少なくとも1つあることを確認する必要があります。このドキュメントでは、ESPと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、ESP、または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のほとんどの実装で、必須になるまでにすでに利用可能であるはずです。これを容易にするために、このドキュメントではそのようなアルゴリズム（今日知られているもの）を特定しようとします。私たち（今日）が将来必須であると信じているアルゴリズムが実際に必須になるという保証はありません。今日知られているすべてのアルゴリズムは、暗号攻撃の対象であり、将来は破壊される可能性があります。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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 +この用語は、SHOULDと同じことを意味します。ただし、SHOULD +としてマークされたアルゴリズムは、将来的には、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.
SHOULD-この用語は、SHOULDと同じことを意味します。ただし、SHOULD-とマークされたアルゴリズムは、このドキュメントの将来のバージョンでMAYまたはそれよりも悪いものに廃止される可能性があります。
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.
MUST-この用語は、MUSTと同じことを意味します。ただし、将来的にこのアルゴリズムは必須ではなくなると予想されます。
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つ以上のセキュリティアルゴリズムをサポートする必要があります。このセクションでは、標準に準拠したESPおよびAH実装のセキュリティアルゴリズム実装要件を指定します。特定のESPまたはAHセキュリティアソシエーションに実際に使用されるセキュリティアルゴリズムは、インターネットキー交換（IKE [RFC2409]、[RFC4306]）などのネゴシエーションメカニズムまたは事前確立によって決定されます。
Of course, additional standard and proprietary algorithms beyond those listed below can be implemented.
もちろん、以下にリストされているものを超える追加の標準および独自のアルゴリズムを実装できます。
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.
ESPのセキュリティアルゴリズムの実装適合要件を以下の表に示します。 「要件」列の値の定義については、セクション2を参照してください。
These tables list encryption and authentication algorithms for the IPsec Encapsulating Security Payload protocol.
これらの表は、IPsecカプセル化セキュリティペイロードプロトコルの暗号化および認証アルゴリズムを示しています。
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)
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)
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）ESP暗号化はオプションであるため、サービスのネゴシエーション方法との一貫性を維持するには、「NULL」アルゴリズムのサポートが必要です。認証と暗号化はそれぞれ「NULL」にすることができますが、両方が「NULL」であってはならないことに注意してください[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-COLL]の弱点が明らかになりました。ただし、これらは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-COLL]で弱点が明らかになりました。ただし、これらはHMACでのMD5の使用に影響を与えません。
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]で指定されているように、機密性と認証サービスの両方を提供する複合モードアルゴリズムがサポートされています。このようなアルゴリズムをサポートするには、ESP実装の適切な構造化が必要です。多くの状況下で、複合モードアルゴリズムは、効率とスループットに大きな利点をもたらします。現時点では、推奨または必須の組み合わせアルゴリズムはありませんが、AES-CCM [RFC4309]およびAES-GCM [RFC4106]が重要です。 AES-CCMはIEEE 802.11 [802.11i]の優先モードとして採用されており、AES-GCMはIEEE 802.1ae [802.1ae]の優先モードとして採用されています。
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] (1)
SHOULD+ AES-XCBC-MAC-96 [RFC3566]
MAY 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-COLL]の弱点が明らかになりました。ただし、これらは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-COLL]で弱点が明らかになりました。ただし、これらはHMACでのMD5の使用に影響を与えません。
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.
このドキュメントは、ESPとAHを使用するための暗号化アルゴリズムの選択、特に必須から実装へのアルゴリズムの選択に関係しています。このドキュメントで「実装する必要がある」または「実装する必要がある」と識別されたアルゴリズムは、現時点では壊れていることがわかっていません。また、これまでのところ、暗号研究により、当面は安全性が維持されると思われます。ただし、これは必ずしも永遠ではありません。そのため、この分野の現在のベストプラクティスを反映した、このドキュメントの新しい改訂版が随時発行されることを期待しています。
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.
ここでの表現の多くは、このドキュメントの親ドキュメントであるRFC 4305を基にしています。 RFC 4305自体は、Jeffrey I. Schillerによる[RFC4307]の「インターネットキーエクスチェンジバージョン2で使用する暗号化アルゴリズム」からテキストを借用しています。
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.
RFC 4305のエラーの報告または報告に対応してくれた、Paul Hoffman、Stephen Kent、Paul Koning、およびLars Volkerに感謝します。 Russ Housley、Elwyn Davies、Nicolas Williams、およびAlfred Hoenesから、役立つラストコールコメントが届きました。
[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認証ヘッダーとIPsecカプセル化セキュリティペイロードを定義しました。それぞれが、それぞれのプロトコルの暗号化アルゴリズムの実装要件を指定しました。これらは現在、暗号化アルゴリズムの実装要件を指定していない[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]
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ノートを参照）。 [RFC4305]は、実装が単一のDESを提供してはならないことを指定することにより、その非推奨の最初の標準トラック認識を表しています。米国政府国立標準技術研究所（NIST）は、単一のDESの弱点を、米国政府標準として撤回することを提案する[DES-WDRAW]で公開された通知により正式に認めています。 Triple DESは、IETFとNISTの両方によって承認されたままです。
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]。このドキュメントには、MUSTからMAYへのサポートを作成するNULL認証アルゴリズムのサポートの変更が組み込まれています。この変更は、このドキュメントを[RFC4301]と整合させるために行われました。 SHA-1衝突攻撃のテキストと、AES-GCMおよびAES-CCMの将来の使用が追加されました。
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP14, RFC2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、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.グレン、「ESPおよびAH内でのHMAC-MD5-96の使用」、RFC 2403、1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404] Madson、C。およびR. Glenn、「The Use of HMAC-SHA-1-96 within ESP and AH」、RFC 2404、1998年11月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405] Madson、C。およびN. Doraswamy、「明示的なIVを使用したESP DES-CBC暗号アルゴリズム」、RFC 2405、1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410] Glenn、R。およびS. Kent、「NULL暗号化アルゴリズムとIPsecでのその使用」、RFC 2410、1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、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でのその使用」、RFC 3566、2003年9月。
[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でのその使用」、RFC 3602、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カプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンターモードの使用」、RFC 3686、2004年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、
December 2005.
2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[RFC4305] Eastlake、D。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4305、2005年12月。
[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 / MAN固有の要件パート11：ワイヤレスメディアアクセスコントロール（MAC）および物理層（PHY）仕様」、IEEE標準メディアアクセスコントロール（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.
[DES-WDRAW]「データ暗号化標準（DES）に対する連邦情報処理標準（FIPS）の撤回案およびコメントの要求」、FIPS通知ドケット番号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-COLL] Klima、V。、「Finding MD5 Collisions-a Toy for a Notebook」、Cryptology ePrint Archive Medium Report 2005/075、March 2005。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S。、およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S。、およびR.アトキンソン、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「インターネットキーエクスチェンジ（IKE）」、RFC 2409、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. McGrew、「IPsecカプセル化セキュリティペイロード（ESP）でのガロア/カウンターモード（GCM）の使用」、RFC 4106、2005年6月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「インターネットキーエクスチェンジ（IKEv2）プロトコル」、RFC 4306、2005年12月。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4307] Schiller、J。、「インターネットキーエクスチェンジバージョン2（IKEv2）で使用する暗号化アルゴリズム」、RFC 4307、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カプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）CCMモードの使用」、RFC 4309、2005年12月。
[SHA1-COLL] Rijmen, V. and E. Oswald, "Update on SHA-1", Cryptology ePrint Archive Report 2005/010, January 2005.
[SHA1-COLL] Rijmen、V。およびE. Oswald、「Update on SHA-1」、Cryptology ePrint Archive Report 2005 / 010、2005年1月。
Author's Address
著者のアドレス
Vishwas Manral IP Infusion Inc. Bamankhola, Bansgali, Almora, Uttarakhand 263601 India
Vishwas Maral Pip Infosysインド263601ウッタラーカンド州バマンコラ、ベンガル語、アルモラ
Phone: +91-98456-61911
EMail: vishwas@ipinfusion.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（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.
このドキュメントはBCP 78に含まれる権利、ライセンス、および制限の対象であり、ここに記載されている場合を除き、著者はすべての権利を保持します。
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は、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
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.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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は、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。