Network Working Group A. Keromytis
Request for Comments: 2857 University of Pennsylvania
Category: Standards Track N. Provos
Center for Information Technology Integration
June 2000
The Use of HMAC-RIPEMD-160-96 within ESP and 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 Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This memo describes the use of the HMAC algorithm [RFC 2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection.
このメモは、改訂されたIPSEC暗号ペイロード[ESP]と改訂IPSEC認証ヘッダ[AH]内認証メカニズムとしてRIPEMD-160アルゴリズム[RIPEMD-160]と連動してHMACアルゴリズム[RFC 2104]の使用を記載しています。 RIPEMD-160との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 RIPEMD-160 [RIPEMD-160] 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-RIPEMD-160-96 is to ensure that the packet is authentic and cannot be modified in transit.
このメモは、カプセル化セキュリティペイロードと認証ヘッダのコンテキスト内の鍵付き認証メカニズムとしてHMAC [RFC 2104]と組み合わせたRIPEMD-160 [RIPEMD-160]の使用を指定します。 HMAC-RIPEMD-160-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鍵を知っている場合、これは両当事者間で送信されるパケットのためのデータ発信元認証とデータの整合性の両方を提供します。 HMACが正しければ、これはソースによって追加されている必要があることを証明しています。
In this memo, HMAC-RIPEMD-160-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-RIPEMD-160から96は、ESPおよびAHのコンテキスト内で使用されています。機密保持機構を備えた - - ESPの様々な部分が方法の詳細についてのセキュリティサービスを提供するために一緒にフィットし、[Thayer97a] [ESP]を参照してくださいと。 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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC 2119]に記載されているように解釈されます。
[RIPEMD-160] describes the underlying RIPEMD-160 algorithm, while [RFC 2104] describes the HMAC algorithm. The HMAC algorithm provides a framework for inserting various hashing algorithms such as RIPEMD-160.
[RFC 2104] HMACアルゴリズムを説明しながら、[RIPEMD-160]は、基礎となるRIPEMD-160アルゴリズムを記載しています。 HMACアルゴリズムは、RIPEMD-160などの様々なハッシュアルゴリズムを挿入するためのフレームワークを提供します。
HMAC-RIPEMD-160-96 operates on 64-byte blocks of data. Padding requirements are specified in [RIPEMD-160] and are part of the RIPEMD-160 algorithm. Padding bits are only necessary in computing the HMAC-RIPEMD-160 authenticator value and MUST NOT be included in the packet.
HMAC-RIPEMD-160-96は、データの64バイトブロック上で動作します。パディング要件は[RIPEMD-160]で指定し、RIPEMD-160アルゴリズムの一部です。パディングビットは、HMAC-RIPEMD-160認証値を計算する際にのみ必要であり、パケットに含まれてはいけません。
HMAC-RIPEMD-160-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-RIPEMD-160-96.
HMAC-RIPEMD-160から96は、160ビットの認証値を生成します。 RFC2104に記載されているように、この160ビットの値が切り捨てられることができます。 ESPまたはAHのどちらかで使用するために、最初の96ビットを使用して、切り捨てられた値がサポートしなければなりません。送信時には、切り捨てられた値が認証子フィールド内に格納されています。受信すると、全体の160ビットの値が計算され、最初の96ビットは、認証子フィールドに格納された値と比較されます。他のオーセンティケータ値の長さは、HMAC-RIPEMD-160から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". [RIPEMD-160] provides some performance analysis. As of this writing no detailed performance analysis has been done of HMAC or HMAC combined with RIPEMD-160.
【Bellare96a]では、「（HMAC）性能は、本質的にその基礎となるハッシュ関数である」と述べています。 [RIPEMD-160]いくつかのパフォーマンス分析を提供します。これを書いているように詳細なパフォーマンス分析は、RIPEMD-160と組み合わせたHMACまたはHMACの行われていません。
[RFC 2104] outlines an implementation modification which can improve per-packet performance without affecting interoperability.
[RFC 2104]相互運用性に影響を与えることなく、パケットごとのパフォーマンスを向上させることができ、実装の変更を概説します。
HMAC-RIPEMD-160-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 SHALL NOT be supported. 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-RIPEMD-160-96は、秘密鍵アルゴリズムです。決まったキーの長さが[RFC 2104]で指定されていないが、ESPまたはAHのどちらかで使用するための160ビットの固定鍵長をサポートしなければなりません。 160ビット以外の鍵長がサポートされていないものとします。 160ビットの鍵長は、[RFC 2104]の推奨事項に基づいて選択した（オーセンティケータの長さ減少セキュリティ強度よりすなわち、キーの長さ以下であり、オーセンティケータの長さよりも長いキーが大幅セキュリティ強度を増加させません）。
[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. Implementors should refer to RFC 1750 for guidance on the requirements for such functions.
[RFC 2104]強いランダムための要件の説明を含む鍵材料の要件について説明します。強い擬似ランダム関数は、必要な160ビットの鍵を生成するために使用されなければなりません。実装者は、このような機能のための要件に関するガイダンスについては、RFC 1750を参照してください。
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のための弱い鍵のセットが特定された場合、これらの弱い鍵の使用は、代替キーの要求や、新たに交渉セキュリティ協会が続く拒絶しなければなりません。
[ESP] describes the general mechanism to obtain keying material for the ESP transform. The derivation of the key from some amount of keying material does not differ between the manual and automatic key management mechanisms.
[ESP] ESP変換のための材料を合わせる得るための一般的なメカニズムを説明しています。鍵材料のいくつかの量からキーの導出は、手動および自動鍵管理メカニズムとの間に違いはありません。
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] states that for "minimally reasonable hash functions" the "birthday attack" is impractical. For a 64-byte block hash such as HMAC-RIPEMD-160-96, an attack involving the successful processing of 2**64 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.) No time-based attacks are discussed in the document.
[RFC 2104]は、「最低限の合理的なハッシュ関数」の「誕生日攻撃」は非現実的であると述べています。それは根本的なハッシュは、2つの** 30ブロックを処理した後に衝突があったことが発見されない限り、このような-160-96 HMAC-RIPEMDとして64バイトのブロックハッシュについては、2 ** 64ブロックの処理が必要とされる攻撃は実現不可能でしょう。 （例えば弱衝突耐性特性を持つハッシュは、一般的に使用不能であると考えられる。）は時間ベースの攻撃は、ドキュメントで説明されていません。
While it it still cryptographically prudent to perform frequent rekeying, current literature does not include any recommended key lifetimes for HMAC-RIPEMD. When recommendations for HMAC-RIPEMD key lifetimes become available they will be included in a revised version of this document.
それはそれはまだ、暗号慎重頻繁に再キーイングを実行する一方で、現在の文献は、HMAC-RIPEMDのための任意の推奨キーの有効期間が含まれていません。 HMAC-RIPEMDキー寿命のための推奨事項が利用可能になったとき、彼らは、この文書の改訂版に含まれます。
As of this writing, there are no known issues which preclude the use of the HMAC-RIPEMD-160-96 algorithm with any specific cipher algorithm.
これを書いている時点で、特定の暗号アルゴリズムとともにHMAC-RIPEMD-160-96アルゴリズムを使用することを妨げる問題は知られていません。
The security provided by HMAC-RIPEMD-160-96 is based upon the strength of HMAC, and to a lesser degree, the strength of RIPEMD-160. At the time of this writing there are no known practical cryptographic attacks against RIPEMD-160.
HMAC-RIPEMD-160から96によって提供されるセキュリティは、HMACの強度に基づいており、より少ない程度に、RIPEMD-160の強度。この記事の執筆時点ではRIPEMD-160に対する既知の実用的な暗号攻撃は存在しません。
It is also important to consider that while RIPEMD-160 was never developed to be used as a keyed hash algorithm, HMAC had that criteria from the onset.
RIPEMD-160は、鍵付きハッシュアルゴリズムとして使用するために開発されなかった一方で、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 RIPEMD-160 with other algorithms such as SHA-1. [RFC 2104] contains a detailed discussion on the strengths and weaknesses of HMAC algorithms.
[RFC 2104] HMACと様々なハッシュアルゴリズムを組み込むためのフレームワークを提供するように、そのようなSHA-1などの他のアルゴリズムとRIPEMD-160を交換することが可能です。 [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. [Kapp97] contains test vectors and example code to assist in verifying the correctness of HMAC-RIPEMD-160-96 code.
任意の暗号化アルゴリズムと真実であるとして、その強度の一部は、アルゴリズムの実装の正確さ、すべてにおいて鍵管理メカニズムのセキュリティとその実装、関連する秘密鍵の強さ、および実装の正確さに応じ参加システム。 【Kapp97] HMAC-RIPEMD-160から96コードの正しさを検証することを支援するためのテストベクトルとサンプルコードが含まれています。
This document is derived from work by C. Madson and R. Glenn and 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.
この文書は、ジム・ヒューズによってC. MadsonおよびR.グレンにより、前の作業から派生し、組み合わせたDES / CBC + HMAC-MD5 ESPにジムで働いていた人々は、変換、ANXのbakeoffの参加者、およびのメンバーIPsecワーキンググループ。
[RIPEMD-160] 3.ISO/IEC 10118-3:1998, "Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions," International Organization for Standardization, Geneva, Switzerland, 1998.
[RIPEMD-160] 3.ISO / IEC 10118-3：1998、 "情報技術 - セキュリティ技術 - ハッシュ関数 - 第3部：専用ハッシュ関数、" 国際標準化機構、ジュネーブ、スイス、1998。
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, September, 1997.
[RFC 2104] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年9月。
[Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash Functions for Message Authentication", Advances in Cryptography, Crypto96 Proceeding, June 1996.
【Bellare96a]ではベラー、M.、カネッティ、R.、Krawczyk、H.、 "メッセージ認証のためのキーイングハッシュ関数" は、暗号化、Crypto96進行、1996年6月進歩します。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、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]セイヤー、R.、Doraswamy、N.とR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[Kapp97] Kapp, J., "Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128", RFC 2286, March 1998.
【Kapp97] KAPP、J.、 "HMAC-RIPEMD160とHMAC-RIPEMD128のテストケース"、RFC 2286、1998年3月。
[RFC 1750] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC 1750]イーストレイク3日、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Angelos D. Keromytis
Distributed Systems Lab
Computer and Information Science Department
University of Pennsylvania
200 S. 33rd Street
Philadelphia, PA 19104 - 6389
EMail: angelos@dsl.cis.upenn.edu
メールアドレス：angelos@dsl.cis.upenn.edu
Niels Provos Center for Information Technology Integration University of Michigan 519 W. William Ann Arbor, Michigan 48103 USA
ミシガン州の情報技術統合大学519 W.ウィリアムアナーバーのためのニールス・プロボスセンター、ミシガン州48103 USA
EMail: provos@citi.umich.edu
メールアドレス：provos@citi.umich.edu
The IPsec working group can be contacted through the chairs:
IPsecワーキンググループは椅子を通じて接触させることができます。
Robert Moskowitz International Computer Security Association
ロバート・モスコウィッツ国際コンピュータセキュリティ協会
EMail: rgm@icsa.net
メールアドレス：rgm@icsa.net
Ted T'so VA Linux Systems
テッドT'so VA Linuxシステム
EMail: tytso@valinux.com
メールアドレス：tytso@valinux.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。