| ネットワーク WG Request for Comments： 2085 分類： スタンダードトラック |
M. Oehler NSA R. Glenn NIST 1997年 2月 |
HMAC-MD5 リプレイ防止機能付き IP 認証
(HMAC-MD5 IP Authentication with Replay Prevention)
このメモの位置付け
要旨
目次
1. はじめに
- 1.1 用語
1.2 鍵
1.3 データ長
- 2.1 リプレイ防止
2.2 認証データの計算
リプレイ攻撃に対する保護を提供するために、変換オプションとしてリプレイ防止フィールドが含まれる。このフィールドは、メッセージが蓄積され、そのオリジナルを置き換えたり繰り返したりして、後に再利用されるような攻撃を防ぐために利用される。このオプションを 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）。
- しなければならない（MUST）
この単語、あるいは「要求される（REQUIRED）」という形容詞は、この項目が仕様の絶対的な要求事項であることを意味する。
- する必要がある（SHOULD）
この単語、あるいは「推奨される（RECOMMENDED）」という形容詞は、ある特別な状況では、この項目を無視できるような有効な理由が存在する可能性があることを意味する。
しかし、そこに含まれている意味はすべて理解されるべきであり、別の方法を取る前に、その状況を慎重に考えるべきである。
たとえ AH
鍵が暗号鍵ではなくても、暗号鍵に関する基本的な事柄は適用される。出力を生成するために使用するアルゴリズムとデータの大部分が知られていると仮定すると、変換の強度は、その鍵（強い必要がある）と
IP
データグラム（知られている）の認証データへの単一のマッピングにある。従って、実装はできるだけ頻繁に AH 鍵を変更するべきである。
鍵は無作為に選ばれるか、ランダムな種を与えた暗号的に強い疑似乱数発生器を使用して生成される必要がある。[HMAC-MD5]
仕様に準拠するすべての実装は、128
ビット以下の鍵長をサポートしなければならない（MUST）。実装は、それより長い鍵長もサポートする必要がある（SHOULD）。その鍵長が MD5 のハッシュ出力の 128
ビットとなるようにすることを勧める。他の鍵長に関しては、以下の事柄が考慮されなければならない（MUST）。
ゼロの鍵長は禁止される。効果的な認証はゼロの長さの鍵によっては提供されないため、実装はこの変換でゼロの鍵長が使用されることを防がなくてはならない（MUST）。128
ビット未満の長さの鍵は、その関数のセキュリティの強度が減少するため使用してはならない。128
ビットより長い鍵は受け入れられるが、その余分の長さは、あまり関数の強度を増さない可能性がある。その鍵の乱数的性質が疑わしいならば、より長い鍵が勧められるかもしれない。MD5 は、 64 バイトのブロックごとに動作する。64 バイトより長い鍵は最初に MD5
でハッシュされ、それから、その結果生じるハッシュが認証データを計算するために使用される。
+---------------+---------------+---------------+---------------+
| 次ヘッダ | 長さ | 予約 |
+---------------+---------------+---------------+---------------+
| 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
ビットワードでのリプレイ防止フィールドと認証データの長さが入る。
この 64 ビットのフィールドは、値 1
から始まるアップカウンタである。
このカウンタが一周する間、すなわち 2^64
以上のパケットを送る間、秘密共有鍵を一つの鍵で使用してはならない。
受信時には、リプレイ値が増加していることが保証される。実装は、順番の異なるパケットを受け取る可能性がある。異なる順番で受け取るパケットの数は実装による。もし、「順番違いウィンドウ」がサポートされるならば、その実装は、異なる順番で受け取ったいくつかの、あるいはすべてのパケットが、以前に到着していないという保証を確実なものとする。すなわち、実装は一回しかパケットを受け取らない。
その宛先アドレスがマルチキャストアドレスであり、リプレイ防止が利用され、そして複数の送信者が、そのマルチキャスト宛先アドレスに対して同じ
IPsec
セキュリティアソシエーションを共有する場合、リプレイ防止は有効にしないほうが良い（SHOULD
NOT）。リプレイ防止が、同じマルチキャスト宛先アドレスに対して複数の送信者を持つマルチキャストセッションで要求される場合、各送信者は、自分自身の IPsec セキュリティアソシエーションを持つ必要がある（SHOULD）。
[ESP-DES-MD5]
では、それがどのように動作するのかを示すために、32
パケット分のリプレイウィンドウを実装した見本のコードとテストルーチンを提供している。
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))
すなわち、
[RFC-1826] Atkinson, R., "IP Authentication Header", RFC 1826, 1995年 8月.
[RFC-1828] Metzger, P., and W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, 1995年 8月.
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1992年 4月.
[HMAC-MD5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, 1997年 2月.
[ESP-DES-MD5] Hughes, J., "Combined DES-CBC, MD5, and Replay Prevention Security Transform", Work in Progress.
EMail： mjo＠tycho.ncsc.mil
Robert Glenn
NIST
Building 820, Room 455
Gaithersburg, MD 20899
EMail： rob.glenn＠nist.gov
翻訳者のアドレス
NTTデータ通信株式会社
馬場 達也EMail： babatt＠nttdata.co.jp
著作権表記全文
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.