RFC2085 日本語訳

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ページ]