RFC2085 日本語訳
2085 HMAC-MD5 IP Authentication with Replay Prevention. M. Oehler, R.Glenn. February 1997. (Format: TXT=13399 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Oehler Request for Comments: 2085 NSA Category: Standards Track R. Glenn NIST February 1997
コメントを求めるワーキンググループM.オーラーの要求をネットワークでつないでください: 2085年のNSAカテゴリ: 標準化過程R.グレンNIST1997年2月
HMAC-MD5 IP Authentication with Replay Prevention
再生防止とのHMAC-MD5IP認証
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks.
このドキュメントは、IP Authentication Header[RFC-1826]に関連して使用されるために合わせられたMD5変換について説明します。 特定の変換は[HMAC-MD5]に基づいています。 また、オプションは、反射攻撃に用心するために指定されます。
Table of Contents
目次
1. Introduction...................................................1 1.1 Terminology.................................................2 1.2 Keys........................................................2 1.3 Data Size...................................................3 2. Packet Format..................................................3 2.1 Replay Prevention...........................................4 2.2 Authentication Data Calculation.............................4 3. Security Considerations........................................5 Acknowledgments....................................................5 References.........................................................6 Authors' Addresses.................................................6
1. 序論…1 1.1用語…2 1.2個のキー…2 1.3 データサイズ…3 2. パケット形式…3 2.1 防止を再演してください…4 2.2 認証データ計算…4 3. セキュリティ問題…5つの承認…5つの参照箇所…6人の作者のアドレス…6
1. Introduction
1. 序論
The Authentication Header (AH) [RFC-1826] provides integrity and authentication for IP datagrams. The transform specified in this document uses a keyed-MD5 mechanism [HMAC-MD5]. The mechanism uses the (key-less) MD5 hash function [RFC-1321] which produces a message digest. When combined with an AH Key, authentication data is produced. This value is placed in the Authentication Data field of the AH [RFC-1826]. This value is also the basis for the data integrity service offered by the AH protocol.
Authentication Header(AH)[RFC-1826]はIPデータグラムのための保全と認証を提供します。本書では指定された変換は合わせられたMD5メカニズム[HMAC-MD5]を使用します。 メカニズムはメッセージダイジェストを作成する(キーなし)のMD5ハッシュ関数[RFC-1321]を使用します。 AH Keyに結合されると、認証データは作り出されます。 この値はAH[RFC-1826]のAuthentication Data分野に置かれます。 また、この値はAHプロトコルによって提供されたデータ保全サービスの基礎です。
Oehler & Glenn Standards Track [Page 1] RFC 2085 HMAC-MD5 February 1997
オーラーとグレン標準化過程[1ページ]RFC2085HMAC-MD5 February 1997
To provide protection against replay attacks, a Replay Prevention field is included as a transform option. This field is used to help prevent attacks in which a message is stored and re-used later, replacing or repeating the original. The Security Parameters Index (SPI) [RFC-1825] is used to determine whether this option is included in the AH.
反射攻撃に対する保護を提供するために、Replay Prevention分野は変換オプションとして含まれています。 この分野は、メッセージが保存される攻撃を防ぐのを助けるのに使用されて、後で再使用されます、オリジナルを置き換えるか、または繰り返して。 Security Parameters Index(SPI)[RFC-1825]は、このオプションがAHに含まれているかどうか決定するのに使用されます。
Familiarity with the following documents is assumed: "Security Architecture for the Internet Protocol" [RFC-1825], "IP Authentication Header" [RFC-1826], and "HMAC-MD5: Keyed-MD5 for Message Authentication" [HMAC-MD5].
以下のドキュメントへの親しみは想定されます: そして、「インターネットプロトコルのためのセキュリティー体系」[RFC-1825]、「IP認証ヘッダー」[RFC-1826]、「HMAC-MD5:」 「通報認証のための合わせられたMD5。」[HMAC-MD5]
All implementations that claim conformance or compliance with the IP Authentication Header specification [RFC-1826] MUST implement this HMAC-MD5 transform.
IP Authentication Header仕様[RFC-1826]への順応かコンプライアンスを要求するすべての実装が、このHMAC-MD5が変換であると実装しなければなりません。
1.1 Terminology
1.1 用語
In this document, the words that are used to define the significance of each particular requirement are usually capitalized. These words are:
本書では、通常、それぞれの特定の要件の意味を定義するのに使用される単語は大文字で書かれます。 これらの単語は以下の通りです。
- MUST
- 必須
This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification.
「必要である」というこの単語か形容詞が、項目が仕様に関する絶対条件であることを意味します。
- SHOULD
- should
This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before taking a different course.
この単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを取る前に慎重に熟慮されたケースであるべきです。
1.2 Keys
1.2 キー
The "AH Key" is used as a shared secret between two communicating parties. The Key is not a "cryptographic key" as used in a traditional sense. Instead, the AH key (shared secret) is hashed with the transmitted data and thus, assures that an intervening party cannot duplicate the authentication data.
「ああ、主要である、」 2の間のパーティーを伝える共有秘密キーとして、使用されます。 Keyは伝統的な意味で使用されるように「暗号化キー」ではありません。 代わりに、AHキー(共有秘密キー)は、伝えられたデータで論じ尽くされて、その結果、仲介者が認証データをコピーできないことを保証します。
Even though an AH key is not a cryptographic key, the rudimentary concerns of cryptographic keys still apply. Consider that the algorithm and most of the data used to produce the output is known. The strength of the transform lies in the singular mapping of the key (which needs to be strong) and the IP datagram (which is known) to the authentication data. Thus, implementations should, and as
AHキーは暗号化キーではありませんが、暗号化キーの初歩的な関心はまだ適用されています。 出力を起こすのに使用されるアルゴリズムとデータの大部分が知られていると考えてください。 認証データには変換の強さがキー(強い必要がある)とIPデータグラム(知られている)のまれなマッピングにあります。 そしてしたがって、実装がそうするべきである。
Oehler & Glenn Standards Track [Page 2] RFC 2085 HMAC-MD5 February 1997
オーラーとグレン標準化過程[2ページ]RFC2085HMAC-MD5 February 1997
frequently as possible, change the AH key. Keys need to be chosen at random, or generated using a cryptographically strong pseudo-random generator seeded with a random seed. [HMAC-MD5]
頻繁同じくらい可能であることで、AHキーを変えてください。 キーが、無作為に選ばれる必要があるか、または暗号でaを使用することで生成されて、強い擬似ランダムジェネレータに無作為の種子で種を蒔きました。 [HMAC-MD5]
All conforming and compliant implementations MUST support a key length of 128 bits or less. Implementations SHOULD support longer key lengths as well. It is advised that the key length be chosen to be the length of the hash output, which is 128 bits for MD5. For other key lengths the following concerns MUST be considered.
すべて従うのと対応する実装は128ビット以下のキー長をサポートしなければなりません。 実装SHOULDはまた、より長いキー長をサポートします。 キー長がMD5のための128ビットであるハッシュ出力の長さになるように選ばれていると忠告されます。 他のキー長において、以下の関心を考えなければなりません。
A key length of zero is prohibited and implementations MUST prevent key lengths of zero from being used with this transform, since no effective authentication could be provided by a zero-length key. Keys having a length less than 128 bits are strongly discouraged as it would decrease the security strength of the function. Keys longer than 128 bits are acceptable, but the extra length may not significantly increase the function strength. A longer key may be advisable if the randomness of the key is suspect. MD5 operates on 64-byte blocks. Keys longer than 64-bytes are first hashed using MD5. The resulting hash is then used to calculate the authentication data.
ゼロのキー長は禁止されています、そして、実装はゼロのキー長がこの変換と共に使用されるのを防がなければなりません、ゼロ・レングスキーでどんな有効な認証も提供できなかったので。 機能のセキュリティの強さを減少させるだろうというのに従って、128ビット未満の長さを持っているキーが強くがっかりしています。 128ビットより長いキーは許容できますが、付加的な長さは機能の強さをかなり増強しないかもしれません。 キーの偶発性が疑わしいなら、より長いキーは賢明であるかもしれません。 MD5は64バイトのブロックを作動させます。 64バイトより長いキーは、最初に、MD5を使用することで論じ尽くされます。 そして、結果として起こるハッシュは、認証データについて計算するのに使用されます。
1.3 Data Size
1.3 データサイズ
MD5 produces a 128-bit value which is used as the authentication data. It is naturally 64 bit aligned and thus, does not need any padding for machines with native double words.
MD5は認証データとして使用される128ビットの値を生産します。 64ビットが当然、並んで、その結果、固有の二重単語でマシンのための少しの詰め物も必要としないということです。
2. Packet Format
2. パケット・フォーマット
+---------------+---------------+---------------+---------------+ | Next Header | Length | RESERVED | +---------------+---------------+---------------+---------------+ | SPI | +---------------+---------------+---------------+---------------+ | Replay Prevention | | | +---------------+---------------+---------------+---------------+ | | + Authentication Data | | | +---------------+---------------+---------------+---------------+ 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| +---------------+---------------+---------------+---------------+ | 再生防止| | | +---------------+---------------+---------------+---------------+ | | + 認証データ| | | +---------------+---------------+---------------+---------------+ 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
The Next Header, RESERVED, and SPI fields are specified in [RFC- 1826]. The Length field is the length of the Replay Prevention field and the Authentication Data in 32-bit words.
Next Header、RESERVED、およびSPI分野は[RFC1826]で指定されます。 Length分野は、Replay Prevention分野の長さと32ビットの単語でAuthentication Dataです。
Oehler & Glenn Standards Track [Page 3] RFC 2085 HMAC-MD5 February 1997
オーラーとグレン標準化過程[3ページ]RFC2085HMAC-MD5 February 1997
2.1 Replay Prevention
2.1 再生防止
The Replay Prevention field is a 64-bit value used to guarantee that each packet exchanged between two parties is different. Each IPsec Security Association specifies whether Replay Prevention is used for that Security Association. If Replay Prevention is NOT in use, then the Authentication Data field will directly follow the SPI field.
Replay Prevention分野は2回のパーティーの間で交換されたそれぞれのパケットが異なっているのを保証するのに使用される64ビットの値です。 各IPsec Security Associationは、Replay PreventionがそのSecurity Associationに使用されるかどうか指定します。 Replay Preventionが使用中でないなら、Authentication Data分野は直接SPI野原に続くでしょう。
The 64-bit field is an up counter starting at a value of 1.
64ビットの分野は1の値において上の反対の始めであることです。
The secret shared key must not be used for a period of time that allows the counter to wrap, that is, to transmit more than 2^64 packets using a single key.
主要な状態で共有された秘密はしばらく使用されて、それが包装へのカウンタを許容して、単一のキーを使用することで2以上^64パケットを伝えるためにいるということであるはずがありません。
Upon receipt, the replay value is assured to be increasing. The implementation may accept out of order packets. The number of packets to accept out of order is an implementation detail. If an "out of order window" is supported, the implementation shall ensure that any and all packets accepted out of order are guaranteed not to have arrived before. That is, the implementation will accept any packet at most once.
領収書では、再生値は、増加しているように保証されます。 実装は故障しているパケットを受け入れるかもしれません。 故障していると受け入れるパケットの数は実装の詳細です。 「故障している窓」がサポートされるなら、実装は、故障していると受け入れられたありとあらゆるパケットが以前到着したことがないように保証されるのを確実にするものとします。 すなわち、実装は高々一度どんなパケットも受け入れるでしょう。
When the destination address is a multicast address, replay protection is in use, and more than one sender is sharing the same IPsec Security Association to that multicast destination address, then Replay Protection SHOULD NOT be enabled. When replay protection is desired for a multicast session having multiple senders to the same multicast destination address, each sender SHOULD have its own IPsec Security Association.
送付先アドレスがマルチキャストアドレスであるときに、反復操作による保護は、使用中であり、可能にされて、送付者が同じIPsec Security Associationを共有しているマルチキャスト送付先アドレス、当時のReplay Protection SHOULDがないものよりさらに使用中です。 反復操作による保護が同じマルチキャスト送付先アドレスには複数の送付者がいるマルチキャストセッションのために望まれているとき、それぞれの送付者SHOULDでは、それ自身のIPsec Security Associationがあります。
[ESP-DES-MD5] provides example code that implements a 32 packet replay window and a test routine to show how it works.
[超能力-DES-MD5]は目立つように32パケット再生ウィンドウとチェックルーチンを実装する例のコードにどう働いているかを提供します。
2.2 Authentication Data Calculation
2.2 認証データ計算
The authentication data is the output of the authentication algorithm (MD5). This value is calculated over the entire IP datagram. Fields within the datagram that are variant during transit and the authentication data field itself, must contain all zeros prior to the computation [RFC-1826]. The Replay Prevention field if present, is included in the calculation.
認証データは認証アルゴリズム(MD5)の出力です。 この値は全体のIPデータグラムの上に計算されます。 データグラムの中のトランジットの間異形である分野と認証データは、それ自体をさばいて、計算[RFC-1826]の前にすべてのゼロを含まなければなりません。 プレゼントが含まれているなら、Replay Preventionは計算でさばきます。
The definition and reference implementation of MD5 appears in [RFC- 1321]. Let 'text' denote the data to which HMAC-MD5 is to be applied and K be the message authentication secret key shared by the parties. If K is longer than 64-bytes it MUST first be hashed using MD5. In this case, K is the resulting hash.
MD5の定義と参照実装は[RFC1321]に現れます。 'テキスト'に通報認証がパーティーによって共有された秘密鍵であったならどのHMAC-MD5が適用されていることになっていたらよいか、そして、Kに指示させてくださいデータを。 Kが64バイトより長いなら、MD5を使用して、最初に、それを論じ尽くさなければなりません。 この場合、Kは結果として起こるハッシュです。
Oehler & Glenn Standards Track [Page 4] RFC 2085 HMAC-MD5 February 1997
オーラーとグレン標準化過程[4ページ]RFC2085HMAC-MD5 February 1997
We define two fixed and different strings ipad and opad as follows (the 'i' and 'o' are mnemonics for inner and outer):
私たちが異なったストリングの修理された2、ipad、および以下のopadを定義する、(より多くのinの間、'i'と'o'がニーモニックである、外側、)、:
ipad = the byte 0x36 repeated 64 times opad = the byte 0x5C repeated 64 times. To compute HMAC-MD5 over the data `text' we perform MD5(K XOR opad, MD5(K XOR ipad, text)) Namely, (1) append zeros to the end of K to create a 64 byte string (e.g., if K is of length 16 bytes it will be appended with 48 zero bytes 0x00) (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with ipad (3) append the data stream 'text' to the 64 byte string resulting from step (2) (4) apply MD5 to the stream generated in step (3) (5) XOR (bitwise exclusive-OR) the 64 byte string computed in step (1) with opad (6) append the MD5 result from step (4) to the 64 byte string resulting from step (5) (7) apply MD5 to the stream generated in step (6) and output the result
ipadは64回繰り返されたopad=バイト0x5Cの64倍繰り返されたバイト0x36と等しいです。 私たちが実行するデータ'テキスト'MD5の上でHMAC-MD5を計算する、(K XOR opad、MD5、(K XOR ipad、テキスト)、(1) すなわち、作成するKでは、64バイトのストリングがステップ(1)でipad(3)で計算したaの64バイトのストリング(例えば、Kが追加されたそれが16バイトの長さのものであるなら、48で、バイト0x00のゼロを合わせる)(2)XOR(排他的論理和をbitwiseする)がデータ・ストリーム'テキスト'を追加する終わりにゼロを追加してください; 64バイトのストリングに、(4)が適用するステップ(2)から生じると、ストリームへのMD5が64バイトのストリングがステップ(1)で(6)が追加するopadで計算したステップ(3)(5)XOR(排他的論理和をbitwiseする)でステップ(4)からステップ(5)(7)から生じる64バイトのストリングまでMD5結果を生成したMD5がステップ(6)で生成されたストリームに適用されて、結果は出力されます。
This computation is described in more detail, along with example code and performance improvements, in [HMAC-MD5]. Implementers should consult [HMAC-MD5] for more information on this technique for keying a cryptographic hash function.
この計算は例のコードと性能改良と共に[HMAC-MD5]でさらに詳細に説明されます。 Implementersは暗号のハッシュ関数を合わせるためのこのテクニックに関する詳しい情報のために[HMAC-MD5]に相談するはずです。
3. Security Considerations
3. セキュリティ問題
The security provided by this transform is based on the strength of MD5, the correctness of the algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the associated secret key, and upon the correctness of the implementations in all of the participating systems. [HMAC-MD5] contains a detailed discussion on the strengths and weaknesses of MD5.
この変換で提供されたセキュリティがMD5の強さとアルゴリズムの実装の正当性とかぎ管理メカニズムのセキュリティと実装、関連秘密鍵の強さに基づいた参加システムのすべての実装の正当性にあります。[HMAC-MD5]はMD5の長所と短所の詳細な論議を含んでいます。
Acknowledgments
承認
This document is largely based on text written by Hugo Krawczyk. The format used was derived from work by William Simpson and Perry Metzger. The text on replay prevention is derived directly from work by Jim Hughes.
このドキュメントはユーゴーKrawczykによって書かれたテキストに主に基づいています。 使用される形式から、ウィリアム・シンプソンとペリーメッツガーは仕事に由来されていました。 再生防止に関するテキストはジム・ヒューズによって直接仕事から引き出されます。
Oehler & Glenn Standards Track [Page 5] RFC 2085 HMAC-MD5 February 1997
オーラーとグレン標準化過程[5ページ]RFC2085HMAC-MD5 February 1997
References
参照
[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.
[RFC-1825] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1852、海軍研究試験所、1995年7月。 [RFC-1826] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年8月。 [RFC-1828] メッツガー、P.とW.シンプソン、「1995年8月に合わせられたMD5"、RFC1828を使用するIP認証。」 [RFC-1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。 [HMAC-MD5] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。 [超能力-DES-MD5] ヒューズと、J.と、「セキュリティが変える結合したDES-CBC、MD5、および再生防止」は進行中で働いています。
Authors' Addresses
作者のアドレス
Michael J. Oehler National Security Agency Atn: R23, INFOSEC Research and Development 9800 Savage Road Fort Meade, MD 20755
マイケルJ.オーラー国家安全保障局Atn: R23、INFOSEC研究開発9800サヴェージ道路フォートミード、MD 20755
EMail: mjo@tycho.ncsc.mil
メール: mjo@tycho.ncsc.mil
Robert Glenn NIST Building 820, Room 455 Gaithersburg, MD 20899
ロバートグレンNIST Building820、部屋455ゲイザースバーグ(MD)20899
EMail: rob.glenn@nist.gov
メール: rob.glenn@nist.gov
Oehler & Glenn Standards Track [Page 6]
オーラーとグレン標準化過程[6ページ]
一覧
スポンサーリンク