ネットワークワーキンググループ
Request for Comments: 2857
分類: スタンダードトラック
A. Keromytis
University of Pennsylvania
N. Provos
Center for Information Technology Integration
2000年6月

ESP および AH での HMAC-RIPEMD-160-96 の使用法
(The Use of HMAC-RIPEMD-160-96 within ESP and AH)

このメモの位置付け 
この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態およびステータスについては、「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] にて提供されている。

1. はじめに 
このメモでは、暗号ペイロードおよび認証ヘッダでの鍵付き認証の仕組みとして、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] における定義に沿って解釈されるものとする。

2. アルゴリズムとモード 
基本となる 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] で説明されているセキュリティの要求条件に合致するためである。

2.1 性能 
[Bellare96a] では、「(HMACの)性能は本質的に、その基本となるハッシュ関数による」と説明されている。
[RIPEMD-160] では、(RIPEMD-160の)性能に関する分析がされている。
この文書の執筆時点では、HMAC および HMAC-RIPEMD-160 に対しての性能の分析は行われていない。

[RFC 2104] では、相互接続性に影響することなくパケット単位での性能を改善できる、実装時における修正について説明されている。

3. 鍵素材 
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 バイトのブロックハッシュでは、基本となるハッシュに 2**30 ブロックを処理した後に衝突があったことが発見されない限り、2**64 ブロックの処理が必要とされる攻撃は実現不可能である。
(このような弱い衝突抵抗特性を持つハッシュは、利用不可能であると考えるのが一般的である。)
この文書では、時間ベースの攻撃については議論されていない。

頻繁に鍵を変更することは、やはり、暗号という観点から見て賢明であるが、現在、HMAC-RIPEMD における鍵の生存期間に対する推奨値が記述された文献は存在しない。
HMAC-RIPEMD における鍵の生存期間に対する推奨値が発表された場合には、それらの推奨値がこの文書の改訂版に含まれるだろう。

4. ESP 暗号メカニズムとの影響 
この文書の執筆時点では、特定の暗号アルゴリズムとともに HMAC-RIPEMD-160-96 アルゴリズムを使用することを妨げる問題は知られていない。
5. セキュリティに関する考慮事項 
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 コードの正確さを確認するためのテストベクトルとサンプルコードが含まれている。

6. 謝辞 
この文書は、C. Madson と R. Glenn による作業から得られた。そして、Jim Hughes、DES/CBC と HMAC-MD5 の組み合わせ ESP 変換に関して Jim と作業した人々、ANX ベイクオフ参加者、そして、IPsec ワーキンググループのメンバーによるこれまでの作業の一部を参考としている。
7. 参考文献 
[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: Keyed-Hashing for Message Authentication", RFC 2104, September, 1997.

[Bellare96a] Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash Functions for Message Authentication", Advances in Cryptography, Crypto96 Proceeding, June 1996.

[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[Thayer97a] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.

[Kapp97] Kapp, J., "Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128", RFC 2286, March 1998.

[RFC 1750] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.

[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

8. 著者の連絡先 
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 ワーキンググループへは、以下のチェアを介してコンタクトをとることが可能である。

Robert Moskowitz
International Computer Security Association

EMail: rgm@icsa.net
 

Ted T'so
VA Linux Systems

EMail: tytso@valinux.com
 

翻訳者

東京都中央区新川1-21-2 茅場町タワー
株式会社 NTTデータ
技術開発本部
馬場 達也

EMail: babatt@nttdata.co.jp

9.著作権表示全文 
Copyright (C) The Internet Society (2000). All Rights Reserved.

本文書とその翻訳は、複製および他に提供することができる。
また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。
ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。
インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。
その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。

謝辞 
現在、RFC エディタの機能に対する資金は、インターネットソサエティによって提供されている。