|
ネットワーク WG Request for Comments： 2857 分類： スタンダードトラック |
A. Keromytis University of Pennsylvania N. Provos Center for Information Technology Integration 2000年6月 |
この文書は、 インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、 それを改良するための議論や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。 このメモの配布に制限はない。
Copyright (C) The Internet Society (2000). All Rights Reserved.
このメモでは、IPSEC暗号ペイロードの改訂版 [ESP] およびIPSEC認証ヘッダの改訂版 [AH] での認証の仕組みとして、 RIPEMD-160アルゴリズム [RIPEMD-160] と組み合わせたHMACアルゴリズム [RFC 2104] の使用法について説明する。 HMAC-RIPEMD-160は、データ生成元認証とインテグリティ保護を提供する。
ESPおよびAHの実装に必要なその他のコンポーネントに関する詳細情報は、 [Thayer97a] にて提供されている。
このメモでは、 暗号ペイロードおよび認証ヘッダでの鍵付き認証の仕組みとして、 HMAC [RFC 2104] と組み合わせたRIPEMD-160 [RIPEMD-160] の使用法について定義する。 HMAC-RIPEMD-160-96の目的は、パケットが偽造されたものではなく、 配送中に変更ができないことを保証することにある。
HMACは秘密鍵認証アルゴリズムである。 HMACが提供するデータインテグリティとデータ生成元認証は、 秘密鍵の配送範囲に限定される。 送信元と宛先のみがHMAC鍵を知っている場合に、 2つの組織の間で送信されるパケットに対して、 データ生成元認証とデータインテグリティが提供される。 HMACが正しければ、それが送信元によって追加されたことが証明される。
このメモでは、HMAC-RIPEMD-160-96はESPとAHで使用される。 ESPの各部分(機密性の仕組みを含む)がセキュリティサービスの提供のためにどのように相互に結び付くかに関しての詳細については、 [ESP] および [Thayer97a] を参照すること。 AHの詳細については、 [AH] および [Thayer97a] を参照のこと。
この文書において、しなければならない(MUST)、 してはならない(MUST NOT)、することになる(SHALL)、 することはない(SHALL NOT)、する必要がある(SHOULD)、 しないほうがよい(SHOULD NOT)、推奨される(RECOMMENDED)、 してもよい(MAY)、 選択できる(OPTIONAL)のキーワードが使用された場合は、 [RFC-2119] における定義に沿って解釈されるものとする。
基本となるRIPEMD-160アルゴリズムは [RIPEMD-160] に、またHMACアルゴリズムは [RFC 2104] にて定義される。 HMACアルゴリズムでは、 RIPEMD-160に代表される様々なハッシュアルゴリズムを挿入するためのフレームワークが提供される。
HMAC-RIPEMD-160-96は64バイトのデータブロックで動作する。 パディングに関する要求条件は、[RIPEMD-160] において指定され、 その条件はRIPEMD-160アルゴリズムの一部として提供される。 パディングビットは、HMAC-RIPEMD-160の認証値の計算時にのみ必要となり、 パケット中に含まれてはならない(MUST NOT)。
HMAC-RIPEMD-160-96は160ビットの認証値を生成する。 この160ビットの値は、RFC2104に定義されているように、 後ろの部分を切詰めて省略することが可能である。 ESPまたはAHのどちらで使用する場合でも、 最初の96ビットに省略された値をサポートしなければならない(MUST)。 送信時には、この省略された値が認証子フィールドに保存される。 受信時には、160ビットの値全体が計算され、 その最初の96ビットと認証子フィールドに保存された値が比較される。 HMAC-RIPEMD-160-96ではその他の認証値サイズをサポートしない。
96ビットの長さが選択された理由は、 これが [AH] で指定されているデフォルトの認証子の長さであり、 [RFC 2104] で説明されているセキュリティの要求条件に合致するためである。
[Bellare96a] では、 「(HMACの)性能は本質的に、 その基本となるハッシュ関数による」と説明されている。 [RIPEMD-160] では、 (RIPEMD-160の)性能に関する分析がされている。 この文書の執筆時点では、 HMACおよびHMAC-RIPEMD-160に対しての性能の分析は行われていない。
[RFC 2104] では、 相互接続性に影響することなくパケット単位での性能を改善できる、 実装時における修正について説明されている。
HMAC-RIPEMD-160-96は秘密鍵アルゴリズムである。 [RFC 2104] では固定鍵長について指定されていないが、 ESPまたは AHのどちらで使用する場合でも、 160ビットの固定鍵長をサポートしなければならない(MUST)。 160ビット以外の鍵長をサポートすることはない(SHALL NOT)。 160ビットの鍵長は、[RFC 2104] の勧告(すなわち、認証子長より短い鍵長はセキュリティ強度を低下させ、 認証子長より長い鍵はセキュリティ強度を大幅に向上させることはない)を基に選ばれている。
[RFC 2104] では鍵素材に関する要求条件について取り上げられており、 それには強力な無作為性に関する要求条件についての議論が含まれている。 要求される160ビットの鍵を生成するためには、 強力な疑似乱数関数を使用しなければならない(MUST)。 実装者は、このような関数に対する要求条件を知るために、 RFC 1750を参照するべきである。
この文書の執筆時点では、HMACで使用する際の脆弱鍵は特にない。 しかし、これは、脆弱鍵が存在しないということを意味するものではない。 ある点で、HMACの脆弱鍵のセットが発見された場合、 これらの鍵の置き換えの要求や新たに取り決められたセキュリティアソシエーションに従って、 これらの鍵の使用を拒否しなければならない。
[ESP] では、 ESP変換のための鍵素材の取得に関する一般的な仕組みについて説明されている。 いくらかの鍵素材から派生した鍵は、 マニュアル鍵管理と自動鍵管理の場合で異なることはない。
データ生成元認証を提供するために、一意に鍵が割り当てられ、 それが通信を行っている当事者にのみ配送されることが、 鍵配送の仕組みによって保証されなければならない。
[RFC 2104] では、
「実用最低限のハッシュ関数」に対して、
HMACに対して知られている最強の攻撃である「誕生日攻撃」は実行不可能であると説明されている。
HMAC-RIPEMD-160-96のような64バイトのブロックハッシュでは、
基本となるハッシュに230ブロックを処理した後に衝突があったことが発見されない限り、
264ブロックの処理が必要とされる攻撃は実現不可能である。
(このような弱い衝突抵抗特性を持つハッシュは、
利用不可能であると考えるのが一般的である。)
この文書では、時間ベースの攻撃については議論されていない。
頻繁に鍵を変更することは、やはり、 暗号という観点から見て賢明であるが、現在、 HMAC-RIPEMDにおける鍵の生存期間に対する推奨値が記述された文献は存在しない。 HMAC-RIPEMDにおける鍵の生存期間に対する推奨値が発表された場合には、 それらの推奨値がこの文書の改訂版に含まれるだろう。
この文書の執筆時点では、 特定の暗号アルゴリズムとともにHMAC-RIPEMD-160-96アルゴリズムを使用することを妨げる問題は知られていない。
HMAC-RIPEMD-160-96によって提供されるセキュリティは、 HMACの強度、 およびほんのわずかであるがRIPEMD-160の強度がもととなっている。 この文書の執筆時点では、 HMAC-RIPEMD-160-96に対する実際の暗号攻撃は知られていない。
さらに、 RIPEMD-160が鍵付ハッシュアルゴリズムとして使用されるために開発されていないのに対し、 HMACは始めからこの考えに沿っていることを考慮することが重要である。
[RFC 2104] ではまた、 生じたハッシュの省略によって追加される、 潜在的なセキュリティについて取り上げられている。 HMACを含む仕様では、 このハッシュの省略を実行することが強く推奨されている。
[RFC 2104] でHMACに様々なハッシュアルゴリズムを取り込むためのフレームワークが提供されているように、 RIPEMD-160をSHA-1などの他のアルゴリズムに置き換えることが可能である。 [RFC 2104] には、 HMACアルゴリズムの強度と弱点に関する詳細な議論が含まれている。
あらゆる暗号化アルゴリズムで真実であるように、 HMACの強度の一部は、アルゴリズムの実装の正確さ、 鍵管理の仕組みのセキュリティとその実装、使用される秘密鍵の強度、 および通信するすべてのシステムにおける実装の正確さにかかっている。 [Kapp97] には、 HMAC-RIPEMD-160-96コードの正確さを確認するためのテストベクトルとサンプルコードが含まれている。
この文書は、C. MadsonとR. Glennによる作業から得られた。 そして、Jim Hughes、 DES/CBCとHMAC-MD5の組み合わせESP変換に関してJimと作業した人々、 ANXベイクオフ参加者、そして、 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年. |
| [RFC 2104] |
Krawczyk, H., Bellare, M. and R. Canetti, 「HMAC： メッセージ認証のための鍵付ハッシング(HMAC:Keyed-Hashing for Message Authentication)」, RFC 2104, 1997年9月. |
| [Bellare96a] | Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash Functions for Message Authentication", Advances in Cryptography, Crypto96 Proceeding, 1996年6月. |
| [ESP] |
Kent, S. and R. Atkinson, 「IP暗号ペイロード(ESP)(IP Encapsulating Security Payload (ESP))」, RFC 2406, 1998年11月. |
| [AH] |
Kent, S. and R. Atkinson, 「IP認証ヘッダ(IP Authentication Header)」, RFC 2402, 1998年11月. |
| [Thayer97a] |
Thayer, R., Doraswamy, N. and R. Glenn, 「IPSEC文書ロードマップ(IP Security Document Roadmap)」, RFC 2411, 1998年11月. |
| [Kapp97] |
Kapp, J., 「HMAC-RIPEMD160とHMAC-RIPEMD128のためのテストケース(Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128)」, RFC 2286, 1998年3月. |
| [RFC 1750] | Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, 1994年12月. |
| [RFC 2119] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」, 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
Niels Provos
Center for Information Technology Integration
University of Michigan
519 W. William
Ann Arbor, Michigan 48103 USA
EMail： provos＠citi.umich.edu
IPsec WGへは、以下のチェアを介して連絡をとることが可能である。
Robert Moskowitz
International Computer Security Association
EMail： rgm＠icsa.net
Ted T'so
VA Linux Systems
EMail： tytso＠valinux.com
株式会社 NTTデータ
開発本部
馬場 達也
EMail： babatt＠nttdata.co.jp
Copyright (C) The Internet Society (2000). All Rights Reserved.
本文書とその翻訳は、複製および他に提供することができる。 また、この文書に論評や説明を加えたり、その実装を補助するものは、 上記の著作権表示およびこの節を付加していれば、 全体あるいは一部であっても一切の制約を課されることなく作成、複製、 発表、配布できる。 ただし、この文書自体に対して、 著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。 インターネット標準化過程で定義されている著作権のための手続きに従って、 インターネット標準を開発するために必要な場合や、 RFCを英語以外の言語に翻訳する必要がある場合はそのかぎりでない。
上記の制限は永続的なものであり、 インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。
本文書とここに含まれた情報は「無保証」で提供され、 インターネットソサエティおよびIETFはすべての保証を明示的にも暗黙的にもおこなわない。 その中には、この情報がいかなる権利も侵害していないという保証や、 商用利用および特定目的における適合性への保証が含まれる。
現在、RFCエディタの機能に対する資金は、 インターネットソサエティによって提供されている。