ネットワークワーキンググループ
Request for Comments: 2085
分類: スタンダードトラック

M. Oehler
NSA
R. Glenn
NIST

1997年2月

HMAC-MD5 リプレイ防止機能付き IP 認証
(HMAC-MD5 IP Authentication with Replay Prevention)

このメモの位置付け

この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを規定するとともに、それを改良するための議論や提言を求めるものである。
このプロトコルの標準化状態、およびステータスについては、"Internet Official Protocol Standards" (STD 1) の最新版を参照すること。
このメモの配布に制限はない。
要旨
この文書では IP 認証ヘッダ [RFC-1826] と関連して使用される、鍵付 MD5 変換について記述する。
この変換は、[HMAC-MD5] に基づいている。
また、リプレイ攻撃を防ぐためのオプションについても指定する。
目次
1. はじめに
1.1 用語
1.2 鍵
1.3 データ長

2. パケット形式
2.1 リプレイ防止
2.2 認証データの計算

3. セキュリティに関する考慮事項

謝辞
参考文献
著者の連絡先

1. はじめに
認証ヘッダ(Authentication Header:AH)[RFC-1826] は、IP データグラムに対してインテグリティと認証の機能を提供するものである。
この文書で指定される変換は、鍵付 MD5 の仕組み [HMAC-MD5] を使用する。
その仕組みは、メッセージダイジェストを生成する(鍵なし)MD5 ハッシュ関数 [RFC-1321] を使用する。
これに AH 鍵を組み合わせることで認証データが生成される。
この値は、AH [RFC-1826] の認証データフィールドに置かれる。
この値は AH プロトコルによって提供されるデータインテグリティサービスの基礎となるものである。

リプレイ攻撃に対する保護を提供するために、変換オプションとしてリプレイ防止フィールドが含まれる。
このフィールドは、メッセージが蓄積され、そのオリジナルを置き換えたり繰り返したりして、後に再利用されるような攻撃を防ぐために利用される。
このオプションを AH に含めるかどうかを決定するために、セキュリティパラメータインデックス(SPI)[RFC-1825] が利用される。

次の文書の内容を熟知していると仮定する:"Security Architecture for the Internet Protocol" [RFC-1825]、"IP Authentication Header" [RFC-1826]、そして "HMAC-MD5: Keyed-MD5 for Message Authentication" [HMAC-MD5]

IP 認証ヘッダの仕様 [RFC-1826] に準拠するすべての実装は、この HMAC-MD5 変換を実装しなければならない(MUST)。

1.1 用語
この文書では、ある特別な要求事項の重要性を明確にするために使用する単語を、通常、大文字で表記する。これらの単語は以下の通りである。

- しなければならない(MUST)

この単語、あるいは「要求される(REQUIRED)」という形容詞は、この項目が仕様の絶対的な要求事項であることを意味する。

- する必要がある(SHOULD)

この単語、あるいは「推奨される(RECOMMENDED)」という形容詞は、ある特別な状況では、この項目を無視できるような有効な理由が存在する可能性があることを意味する。
しかし、そこに含まれている意味はすべて理解されるべきであり、別の方法を取る前に、その状況を慎重に考えるべきである。

1.2 鍵
「AH 鍵」が、通信する 2 つの組織の間の共有秘密鍵として使用される。
この鍵は、伝統的な意味で使用される「暗号鍵」ではない。
その代わりに、AH 鍵(共有秘密鍵)は、送信されるデータと共にハッシュされ、間に割り込もうとする組織が認証データを複製することが不可能であることを保証する。

たとえ AH 鍵が暗号鍵ではなくても、暗号鍵に関する基本的な事柄は適用される。
出力を生成するために使用するアルゴリズムとデータの大部分が知られていると仮定すると、変換の強度は、その鍵(強い必要がある)と IP データグラム(知られている)の認証データへの単一のマッピングにある。
従って、実装はできるだけ頻繁に AH 鍵を変更するべきである。 鍵は無作為に選ばれるか、ランダムな種を与えた暗号的に強い疑似乱数発生器を使用して生成される必要がある。[HMAC-MD5]

仕様に準拠するすべての実装は、128 ビット以下の鍵長をサポートしなければならない(MUST)。
実装は、それより長い鍵長もサポートする必要がある(SHOULD)。
その鍵長が MD5 のハッシュ出力の 128 ビットとなるようにすることを勧める。
他の鍵長に関しては、以下の事柄が考慮されなければならない(MUST)。

ゼロの鍵長は禁止される。
効果的な認証はゼロの長さの鍵によっては提供されないため、実装はこの変換でゼロの鍵長が使用されることを防がなくてはならない(MUST)。
128 ビット未満の長さの鍵は、その関数のセキュリティの強度が減少するため使用してはならない。
128 ビットより長い鍵は受け入れられるが、その余分の長さは、あまり関数の強度を増さない可能性がある。
その鍵の乱数的性質が疑わしいならば、より長い鍵が勧められるかもしれない。
MD5 は、 64 バイトのブロックごとに動作する。
64 バイトより長い鍵は最初に MD5 でハッシュされ、それから、その結果生じるハッシュが認証データを計算するために使用される。

1.3 データ長
MD5 は、認証データとして使用する 128 ビットの値を生成する。
それは、自然に 64 ビット毎に整列され、母国語が 2 バイトのマシンでもパディングを全く必要としない。
2. パケット形式
  
     +---------------+---------------+---------------+---------------+
     |    次ヘッダ   |     長さ      |             予約              |
     +---------------+---------------+---------------+---------------+
     |                              SPI                              |
     +---------------+---------------+---------------+---------------+
     |                         リプレイ防止                          |
     |                                                               |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     +                          認証データ                           |
     |                                                               |
     +---------------+---------------+---------------+---------------+
      1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
次ヘッダ、予約、SPI フィールドは、[RFC 1826] にて指定される。
長さフィールドには、32 ビットワードでのリプレイ防止フィールドと認証データの長さが入る。
2.1 リプレイ防止
リプレイ防止フィールドは、2 つの組織の間で交換された各パケットが、互いに異なるものであることを保証するために利用される 64 ビットの値である。
各 IPsec セキュリティアソシエーションは、リプレイ防止をそのセキュリティアソシエーションで利用するかどうかを指定する。
リプレイ防止が利用されないのであれば、認証データフィールドは直接 SPI フィールドの後に続く。

この 64 ビットのフィールドは、値 1 から始まるアップカウンタである。

このカウンタが一周する間、すなわち 2^64 以上のパケットを送る間、秘密共有鍵を一つの鍵で使用してはならない。

受信時には、リプレイ値が増加していることが保証される。
実装は、順番の異なるパケットを受け取る可能性がある。
異なる順番で受け取るパケットの数は実装による。
もし、「順番違いウィンドウ」がサポートされるならば、その実装は、異なる順番で受け取ったいくつかの、あるいはすべてのパケットが、以前に到着していないという保証を確実なものとする。
すなわち、実装は一回しかパケットを受け取らない。

その宛先アドレスがマルチキャストアドレスであり、リプレイ防止が利用され、そして複数の送信者が、そのマルチキャスト宛先アドレスに対して同じ IPsec セキュリティアソシエーションを共有する場合、リプレイ防止は有効にしないほうが良い(SHOULD NOT)。
リプレイ防止が、同じマルチキャスト宛先アドレスに対して複数の送信者を持つマルチキャストセッションで要求される場合、各送信者は、自分自身の IPsec セキュリティアソシエーションを持つ必要がある(SHOULD)。

[ESP-DES-MD5] では、それがどのように動作するのかを示すために、32 パケット分のリプレイウィンドウを実装した見本のコードとテストルーチンを提供している。

2.2 認証データの計算
認証データは、認証アルゴリズム(MD5)の出力である。
この値は、IP データグラム全体に渡って計算される。
データグラム中の配送中に変更されるフィールドとその認証データフィールド自身は、その計算の前にすべてゼロを含むようにしなければならない [RFC-1826]
リプレイ防止フィールドが存在する場合は、それはその計算に含まれる。

MD5 の定義と参考のための実装は、[RFC-1321] に存在する。
HMAC-MD5 が適用されるデータを 'text' とし、複数の組織によって共有されるメッセージ認証秘密鍵を K とする。
もし K が 64 バイトよりも長ければ、最初に MD5 でハッシュしなければならない(MUST)。
この場合、K はその結果生じるハッシュとなる。

以下のように 2 つの異なる固定文字列 ipad と opad を定義する(その 'i' と 'o' は、inner と outer を連想させるように付けてある):

ipad = バイト値 0x36 を 64 回繰り返した文字列
opad = バイト値 0x5C を 64 回繰り返した文字列

データ `text' に対して HMAC-MD5 を計算するためには、以下のようにする。

MD5(K XOR opad, MD5(K XOR ipad, text))


すなわち、

  1. 64 バイトの文字列を作るように K の終わりまでゼロを追加する。

  2. (例えば、K が 16 バイトの長さであるならば、48 個のゼロのバイト値 0x00 が追加される)
  3. ステップ (1) で計算された 64 バイトの文字列と ipad との XOR (ビット毎の排他的論理和) を計算する。
  4. ステップ (2) の結果生じた 64 バイトの文字列に、データ `text' のストリームを追加する。
  5. ステップ (3) で生成されたストリームに MD5 を適用する。
  6. ステップ (1) で計算された 64 バイトの文字列と opad との XOR (ビット毎の排他的論理和) を計算する。
  7. ステップ (5) の結果生じた 64 バイトの文字列に、ステップ (4) の MD5 の結果を追加する。
  8. ステップ (6) で生成されたストリームに MD5 を適用し、その結果を出力する。

この計算は、見本のコードと性能の改善についての考察とともに、[HMAC-MD5] にてより詳細に記述されている。
実装者は、暗号ハッシュ関数に鍵を適用する手法についてさらなる情報を得るためには、[HMAC-MD5] を調べるべきである。
3. セキュリティに関する考慮事項
この変換によって提供されるセキュリティは、MD5 の強度、アルゴリズムの実装の正確さ、鍵管理の仕組みとその実装のセキュリティ、関係する秘密鍵の強度、そしてすべての参加システムにおける実装の正確さに基づいている。
[HMAC-MD5] では、MD5 の強度と欠点に関する詳細な議論についても記述されている。
謝辞
この文書は、主に Hugo Krawczyk によって書かれた文章に基づいている。
利用されている形式は、William Simpson と Perry Metzger による成果から得られたものである。
リプレイ防止についての文章は、Jim Hughes による成果から直接得られたものである。
参考文献
[RFC-1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1852, Naval Research Laboratory, July 1995.

[RFC-1826] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.

[RFC-1828] Metzger, P., and W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August 1995.

[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.

[HMAC-MD5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.

[ESP-DES-MD5] Hughes, J., "Combined DES-CBC, MD5, and Replay Prevention Security Transform", Work in Progress.

著者の連絡先
Michael J. Oehler
National Security Agency
Atn: R23, INFOSEC Research and Development
9800 Savage Road
Fort Meade, MD 20755

EMail: mjo@tycho.ncsc.mil

Robert Glenn
NIST
Building 820, Room 455
Gaithersburg, MD 20899

EMail: rob.glenn@nist.gov

翻訳者

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

EMail: babatt@nttdata.co.jp

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

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.