[要約] RFC 2404は、ESPとAH内でHMAC-SHA-1-96の使用に関するガイドラインを提供しています。目的は、データの整合性と認証を確保するために、セキュリティプロトコルでHMAC-SHA-1-96を使用する方法を定義することです。
Network Working Group C. Madson
Request for Comments: 2404 Cisco Systems Inc.
Category: Standards Track R. Glenn
NIST
November 1998
The Use of HMAC-SHA-1-96 within ESP and AH
ESPおよびAH内でのHMAC-SHA-1-96の使用
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 Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This memo describes the use of the HMAC algorithm [RFC-2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 provides data origin authentication and integrity protection.
このメモは、改訂されたIPSECカプセル化セキュリティペイロード[ESP]および改訂されたIPSEC認証ヘッダー[ AH]。 SHA-1を備えたHMACは、データ発信元認証と整合性保護を提供します。
Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].
ESPおよびAHの実装に必要なその他のコンポーネントの詳細は、[Thayer97a]から提供されています。
This memo specifies the use of SHA-1 [FIPS-180-1] combined with HMAC [RFC-2104] as a keyed authentication mechanism within the context of the Encapsulating Security Payload and the Authentication Header. The goal of HMAC-SHA-1-96 is to ensure that the packet is authentic and cannot be modified in transit.
このメモは、SHA-1 [FIPS-180-1]とHMAC [RFC-2104]の組み合わせを、カプセル化セキュリティペイロードと認証ヘッダーのコンテキスト内のキー付き認証メカニズムとして使用することを指定しています。 HMAC-SHA-1-96の目的は、パケットが本物であり、送信中に変更できないことを保証することです。
HMAC is a secret key authentication algorithm. Data integrity and data origin authentication as provided by HMAC are dependent upon the scope of the distribution of the secret key. If only the source and destination know the HMAC key, this provides both data origin authentication and data integrity for packets sent between the two parties; if the HMAC is correct, this proves that it must have been added by the source.
HMACは秘密鍵認証アルゴリズムです。 HMACによって提供されるデータ整合性とデータ発信元認証は、秘密鍵の配布の範囲に依存します。送信元と宛先だけがHMACキーを知っている場合、これは、2つのパーティ間で送信されるパケットのデータ発信元認証とデータ整合性の両方を提供します。 HMACが正しい場合、これは、それがソースによって追加されたに違いないことを証明します。
In this memo, HMAC-SHA-1-96 is used within the context of ESP and AH. For further information on how the various pieces of ESP - including the confidentiality mechanism -- fit together to provide security services, refer to [ESP] and [Thayer97a]. For further information on AH, refer to [AH] and [Thayer97a].
このメモでは、HMAC-SHA-1-96がESPおよびAHのコンテキスト内で使用されています。機密保持メカニズムを含むESPのさまざまな部分がどのように組み合わされてセキュリティサービスを提供するかについての詳細は、[ESP]および[Thayer97a]を参照してください。 AHの詳細については、[AH]および[Thayer97a]を参照してください。
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 [RFC 2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC 2119]で説明されているように解釈されます。
[FIPS-180-1] describes the underlying SHA-1 algorithm, while [RFC-2104] describes the HMAC algorithm. The HMAC algorithm provides a framework for inserting various hashing algorithms such as SHA-1.
[FIPS-180-1]は基礎となるSHA-1アルゴリズムを説明し、[RFC-2104]はHMACアルゴリズムを説明します。 HMACアルゴリズムは、SHA-1などのさまざまなハッシュアルゴリズムを挿入するためのフレームワークを提供します。
HMAC-SHA-1-96 operates on 64-byte blocks of data. Padding requirements are specified in [FIPS-180-1] and are part of the SHA-1 algorithm. If you build SHA-1 according to [FIPS-180-1] you do not need to add any additional padding as far as HMAC-SHA-1-96 is concerned. With regard to "implicit packet padding" as defined in [AH] no implicit packet padding is required.
HMAC-SHA-1-96は、64バイトのデータブロックで動作します。パディング要件は[FIPS-180-1]で指定されており、SHA-1アルゴリズムの一部です。 [FIPS-180-1]に従ってSHA-1を構築する場合、HMAC-SHA-1-96に関する限り、追加のパディングを追加する必要はありません。 [AH]で定義されている「暗黙のパケットパディング」に関しては、暗黙のパケットパディングは必要ありません。
HMAC-SHA-1-96 produces a 160-bit authenticator value. This 160-bit value can be truncated as described in RFC2104. For use with either ESP or AH, a truncated value using the first 96 bits MUST be supported. Upon sending, the truncated value is stored within the authenticator field. Upon receipt, the entire 160-bit value is computed and the first 96 bits are compared to the value stored in the authenticator field. No other authenticator value lengths are supported by HMAC-SHA-1-96.
HMAC-SHA-1-96は、160ビットの認証値を生成します。この160ビットの値は、RFC2104で説明されているように切り捨てることができます。 ESPまたはAHで使用するには、最初の96ビットを使用して切り捨てられた値をサポートする必要があります。送信すると、切り捨てられた値はオーセンティケーターフィールドに格納されます。受信すると、160ビットの値全体が計算され、最初の96ビットが認証フィールドに格納されている値と比較されます。 HMAC-SHA-1-96では、他の認証値の長さはサポートされていません。
The length of 96 bits was selected because it is the default authenticator length as specified in [AH] and meets the security requirements described in [RFC-2104].
[AH]で指定されているデフォルトのオーセンティケーターの長さであり、[RFC-2104]で説明されているセキュリティ要件を満たすため、96ビットの長さが選択されました。
[Bellare96a] states that "(HMAC) performance is essentially that of the underlying hash function". As of this writing no detailed performance analysis has been done of SHA-1, HMAC or HMAC combined with SHA-1.
[Bellare96a]は、「（（HMAC）パフォーマンスは基本的にハッシュ関数のパフォーマンスである」と述べています。これを書いている時点では、SHA-1、HMAC、またはSHA-1と組み合わせたHMACの詳細なパフォーマンス分析は行われていません。
[RFC-2104] outlines an implementation modification which can improve per-packet performance without affecting interoperability.
[RFC-2104]は、相互運用性に影響を与えずにパケットごとのパフォーマンスを向上させることができる実装の変更を概説しています。
HMAC-SHA-1-96 is a secret key algorithm. While no fixed key length is specified in [RFC-2104], for use with either ESP or AH a fixed key length of 160-bits MUST be supported. Key lengths other than 160- bits MUST NOT be supported (i.e. only 160-bit keys are to be used by HMAC-SHA-1-96). A key length of 160-bits was chosen based on the recommendations in [RFC-2104] (i.e. key lengths less than the authenticator length decrease security strength and keys longer than the authenticator length do not significantly increase security strength).
HMAC-SHA-1-96は秘密鍵アルゴリズムです。 [RFC-2104]では固定キーの長さは指定されていませんが、ESPまたはAHのいずれかで使用するには、160ビットの固定キー長をサポートする必要があります。 160ビット以外のキーの長さはサポートされてはならない（MUST NOT）（すなわち、160ビットのキーのみがHMAC-SHA-1-96で使用される）。 [RFC-2104]の推奨事項に基づいて、160ビットのキーの長さが選択されました（つまり、キーの長さがオーセンティケーターの長さより短いとセキュリティ強度が低下し、オーセンティケーターの長さより長いキーはセキュリティ強度が大幅に増加しません）。
[RFC-2104] discusses requirements for key material, which includes a discussion on requirements for strong randomness. A strong pseudo-random function MUST be used to generate the required 160-bit key.
[RFC-2104]は、強力なランダム性の要件に関する議論を含む、主要な資料の要件について説明します。強力な疑似ランダム関数を使用して、必要な160ビットの鍵を生成する必要があります。
At the time of this writing there are no specified weak keys for use with HMAC. This does not mean to imply that weak keys do not exist. If, at some point, a set of weak keys for HMAC are identified, the use of these weak keys must be rejected followed by a request for replacement keys or a newly negotiated Security Association.
この記事の執筆時点では、HMACで使用するための特定の弱い鍵はありません。これは、弱いキーが存在しないことを意味するものではありません。ある時点で、HMACの弱いキーのセットが識別された場合、これらの弱いキーの使用を拒否してから、交換キーまたは新しくネゴシエートされたセキュリティアソシエーションを要求する必要があります。
[ARCH] describes the general mechanism for obtaining keying material when multiple keys are required for a single SA (e.g. when an ESP SA requires a key for confidentiality and a key for authentication).
[ARCH]は、単一のSAに複数のキーが必要な場合（例：ESP SAが機密性のキーと認証用のキーを必要とする場合）にキー情報を取得する一般的なメカニズムを説明しています。
In order to provide data origin authentication, the key distribution mechanism must ensure that unique keys are allocated and that they are distributed only to the parties participating in the communication.
データ発信元認証を提供するために、キー配布メカニズムは、一意のキーが割り当てられ、それらが通信に参加している関係者にのみ配布されることを保証する必要があります。
[RFC-2104] makes the following recommendation with regard to rekeying. Current attacks do not indicate a specific recommended frequency for key changes as these attacks are practically infeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, reduces the information avaliable to a cryptanalyst, and limits the damage of an exposed key.
[RFC-2104]は、キーの再生成に関して次のことを推奨しています。これらの攻撃は実際には実行不可能であるため、現在の攻撃は、主要な変更の特定の推奨頻度を示していません。ただし、定期的なキーの更新は、機能とキーの潜在的な脆弱性を防ぎ、暗号解読者が入手できる情報を減らし、公開されたキーの損傷を制限する基本的なセキュリティ対策です。
As of this writing, there are no known issues which preclude the use of the HMAC-SHA-1-96 algorithm with any specific cipher algorithm.
これを書いている時点では、特定の暗号化アルゴリズムでHMAC-SHA-1-96アルゴリズムを使用できなくなる既知の問題はありません。
The security provided by HMAC-SHA-1-96 is based upon the strength of HMAC, and to a lesser degree, the strength of SHA-1. At the time of this writing there are no practical cryptographic attacks against HMAC-SHA-1-96.
HMAC-SHA-1-96によって提供されるセキュリティは、HMACの強さに基づいており、SHA-1の強さに基づいています。この記事の執筆時点では、HMAC-SHA-1-96に対する実用的な暗号攻撃はありません。
[RFC-2104] states that for "minimally reasonable hash functions" the "birthday attack" is impractical. For a 64-byte block hash such as HMAC-SHA-1-96, an attack involving the successful processing of 2**80 blocks would be infeasible unless it were discovered that the underlying hash had collisions after processing 2**30 blocks. A hash with such weak collision-resistance characteristics would generally be considered to be unusable.
[RFC-2104]は、「最小限の妥当なハッシュ関数」では「誕生日の攻撃」は非現実的であると述べています。 HMAC-SHA-1-96などの64バイトブロックハッシュの場合、2 ** 30ブロックの処理後に基礎となるハッシュが衝突していることが発見されない限り、2 ** 80ブロックの正常な処理を伴う攻撃は実行不可能です。このような弱い耐衝突特性を持つハッシュは、一般的に使用不可能と見なされます。
It is also important to consider that while SHA-1 was never developed to be used as a keyed hash algorithm, HMAC had that criteria from the onset.
また、SHA-1はキー付きハッシュアルゴリズムとして使用するために開発されたことはありませんが、HMACには最初からその基準があったことを考慮することも重要です。
[RFC-2104] also discusses the potential additional security which is provided by the truncation of the resulting hash. Specifications which include HMAC are strongly encouraged to perform this hash truncation.
[RFC-2104]は、結果のハッシュの切り捨てによって提供される潜在的な追加のセキュリティについても説明しています。 HMACを含む仕様では、このハッシュの切り捨てを実行することを強くお勧めします。
As [RFC-2104] provides a framework for incorporating various hash algorithms with HMAC, it is possible to replace SHA-1 with other algorithms such as MD5. [RFC-2104] contains a detailed discussion on the strengths and weaknesses of HMAC algorithms.
[RFC-2104]はHMACにさまざまなハッシュアルゴリズムを組み込むためのフレームワークを提供するため、SHA-1をMD5などの他のアルゴリズムに置き換えることが可能です。 [RFC-2104]には、HMACアルゴリズムの長所と短所に関する詳細な説明が含まれています。
As is true with any cryptographic algorithm, part of its strength lies in the correctness of the algorithm implementation, the security of the key management mechanism and its implementation, the strength of the associated secret key, and upon the correctness of the implementation in all of the participating systems. [RFC-2202] contains test vectors and example code to assist in verifying the correctness of HMAC-SHA-1-96 code.
他の暗号アルゴリズムと同様に、その強さの一部は、アルゴリズム実装の正確さ、鍵管理メカニズムとその実装のセキュリティ、関連する秘密鍵の強さ、およびすべての実装の正確さにあります参加システム。 [RFC-2202]には、HMAC-SHA-1-96コードの正当性を検証するのに役立つテストベクトルとサンプルコードが含まれています。
This document is derived in part from previous works by Jim Hughes, those people that worked with Jim on the combined DES/CBC+HMAC-MD5 ESP transforms, the ANX bakeoff participants, and the members of the IPsec working group.
このドキュメントは、Jim Hughes、DES / CBC + HMAC-MD5 ESP変換を組み合わせてJimと協力した人々、ANXベークオフ参加者、およびIPsecワーキンググループのメンバーによる以前の作品から一部派生しています。
We would also like to thank Hugo Krawczyk for his comments and recommendations regarding some of the cryptographic specific text in this document.
また、このドキュメントの暗号化固有のテキストのいくつかに関するコメントと推奨事項について、Hugo Krawczyk氏に感謝します。
[FIPS-180-1] NIST, FIPS PUB 180-1: Secure Hash Standard,
April 1995.
http://csrc.nist.gov/fips/fip180-1.txt (ascii)
http://csrc.nist.gov/fips/fip180-1.ps (postscript)
[RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC-2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[Bellare96a] Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash Functions for Message Authentication", Advances in Cryptography, Crypto96 Proceeding, June 1996.
[Bellare96a] Bellare、M.、Canetti、R。、およびH. Krawczyk、「Keying Hash Functions for Message Authentication」、Advance of Cryptography、Crypto96 Proceeding、1996年6月。
[ARCH] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[ESP]ケント、S。、およびR.アトキンソン、「IPカプセル化セキュリティペイロード」、RFC 2406、1998年11月。
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]ケント、S。、およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[Thayer97a] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[Thayer97a] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[RFC-2202] Cheng, P., and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 2202, March 1997.
[RFC-2202] Cheng、P。、およびR. Glenn、「HMAC-MD5およびHMAC-SHA-1のテストケース」、RFC 2202、1997年3月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
Cheryl Madson Cisco Systems, Inc.
シェリルマドソンCisco Systems、Inc.
EMail: cmadson@cisco.com
Rob Glenn NIST
ロブグレンNIST
EMail: rob.glenn@nist.gov
The IPsec working group can be contacted through the chairs:
IPsecワーキンググループは、議長を通じて連絡を取ることができます。
Robert Moskowitz ICSA
ロバートモスコウィッツICSA
EMail: rgm@icsa.net
Ted T'so Massachusetts Institute of Technology
Ted T'soマサチューセッツ工科大学
EMail: tytso@mit.edu
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。