RFC 2841 - IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2841
タイトル : RFC 2841 - インターリーブパディング（IP-MAC）を備えたキー付きSHA1を使用したIP認証
翻訳編集 : 自動生成

[要約] RFC 2841は、IP-MACと呼ばれるキー付きSHA1を使用したIP認証の仕様を定義しています。この仕様の目的は、IPパケットの送信元の認証と改ざんの検出を実現することです。

Network Working Group                                         P. Metzger
Request for Comments: 2841                                      Piermont
Category: Historic                                            W. Simpson
Obsoletes: 1852                                               DayDreamer
                                                           November 2000

IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)

インターリーブパディング（IP-MAC）を備えたキー付きSHA1を使用したIP認証

Status of this Memo

本文書の位置付け

This memo defines a Historic Document for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティ向けの歴史的な文書を定義しています。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document describes the use of keyed SHA1 with the IP Authentication Header.

このドキュメントでは、IP認証ヘッダーでキー付きSHA1の使用について説明します。

Table of Contents

   1.   Introduction ............................................. 2
   1.1. Keys ..................................................... 2
   1.2. Data Size ................................................ 2
   1.3. Performance .............................................. 3
   2.   Calculation .............................................. 3
   A.   Changes .................................................. 5
   Security Considerations ....................................... 6
   Acknowledgements .............................................. 6
   References .................................................... 7
   Contacts ...................................................... 8
   Editor's Note ................................................. 8
   Full Copyright Statement ...................................... 9

1. Introduction

1. はじめに

The Authentication Header (AH) [RFC-1826] provides integrity and authentication for IP datagrams. This specification describes the AH use of keys with the Secure Hash Algorithm (SHA1) [FIPS-180-1]. This SHA1-IP-MAC algorithm uses a leading and trailing key (a variant of the "envelope method"), with alignment padding between both keys and data.

認証ヘッダー（AH）[RFC-1826]は、IPデータグラムに整合性と認証を提供します。この仕様では、安全なハッシュアルゴリズム（SHA1）[FIPS-180-1]を使用したキーのAH使用について説明します。このSHA1-IP-MACアルゴリズムは、キーとデータの両方の間にアラインメントパディングを使用して、リーディングおよびトレーリングキー（「エンベロープメソッド」のバリアント）を使用します。

It should be noted that this document specifies a newer version of SHA than that described in [FIPS-180], which was flawed. The older version is not interoperable with the newer version.

このドキュメントは、欠陥がある[FIPS-180]に記載されているものよりもSHAの新しいバージョンを指定していることに注意する必要があります。古いバージョンは、新しいバージョンと相互運用できません。

This document assumes that the reader is familiar with the related document "Security Architecture for the Internet Protocol" [RFC-1825], that defines the overall security plan for IP, and provides important background for this specification.

このドキュメントは、読者がIPの全体的なセキュリティ計画を定義し、この仕様の重要な背景を提供する関連ドキュメント「インターネットプロトコルのセキュリティアーキテクチャ」[RFC-1825]に精通していることを前提としています。

1.1. Keys

1.1. キー

The secret authentication key shared between the communicating parties SHOULD be a cryptographically strong random number, not a guessable string of any sort.

通信当事者間で共有される秘密認証キーは、暗号化可能な乱数であり、いかなる種類の推測可能な文字列ではありません。

The shared key is not constrained by this transform to any particular size. Lengths of 160-bits (20 octets) MUST be supported by the implementation, although any particular key may be shorter. Longer keys are encouraged.

共有キーは、特定のサイズへのこの変換によって制約されません。特定のキーが短くなる場合は、160ビット（20オクテット）の長さ（20オクテット）をサポートする必要があります。より長いキーがお勧めします。

1.2. Data Size

1.2. データサイズ

SHA1's 160-bit output is naturally 32-bit aligned. However, many implementations require 64-bit alignment of the following headers.

SHA1の160ビット出力は、当然32ビットアライメントされています。ただし、多くの実装では、次のヘッダーの64ビットアライメントが必要です。

Therefore, several options are available for data alignment (most preferred to least preferred):

したがって、データの調整にはいくつかのオプションが利用可能です（最も好まれるよりも最も好ましいものよりも優先されます）：

1) only the most significant 128-bits (16 octets) of output are used.

1) 最も重要な128ビット（16オクテット）の出力のみが使用されます。

2) an additional 32-bits (4 octets) of padding is added before the SHA1 output.

2) SHA1出力の前に、追加の32ビット（4オクテット）のパディングが追加されます。

3) an additional 32-bits (4 octets) of padding is added after the SHA1 output.

3) SHA1出力後に追加の32ビット（4オクテット）のパディングが追加されます。

4) the SHA1 output is variably bit-positioned within 192-bits (24 octets).

4) SHA1出力は、192ビット（24オクテット）以内にさまざまなビットポジションになります。

The size and position of the output are negotiated as part of the key management. Padding bits are filled with unspecified implementation dependent (random) values, which are ignored on receipt.

出力のサイズと位置は、主要な管理の一部として交渉されます。パディングビットには、領収書で無視される不特定の実装依存（ランダム）値が満たされています。

Discussion:

議論：

Although truncation of the output for alignment purposes may appear to reduce the effectiveness of the algorithm, some analysts of attack verification suggest that this may instead improve the overall robustness [PO95a].

アライメント目的での出力の切り捨ては、アルゴリズムの有効性を低下させるように見えるかもしれませんが、攻撃検証のアナリストの中には、これが代わりに全体的な堅牢性を改善する可能性があることを示唆しています[PO95A]。

1.3. Performance

1.3. パフォーマンス

Preliminary results indicate that SHA1 is 62% as fast as MD5, and 80% as fast as DES hashing. That is:

予備的な結果は、SHA1がMD5と同じくらい速く62％、80％がDes Hashingと同じくらい速いことを示しています。あれは：

SHA1 < DES < MD5

Sha1 <des <md5

This appears to be a reasonable performance tradeoff, as SHA1 internal chaining is significantly longer than either DES or MD5:

SHA1内部チェーンはDESまたはMD5よりも大幅に長いため、これは合理的なパフォーマンストレードオフのように見えます。

DES < MD5 < SHA1

des <md5 <sha1

Nota Bene: Suggestions are sought on alternative authentication algorithms that have significantly faster throughput, are not patent-encumbered, and still retain adequate cryptographic strength.

NOTA BENE：スループットが大幅に高速であり、特許が刻まれておらず、適切な暗号強度を保持する代替認証アルゴリズムについて提案が求められています。

2. Calculation

2. 計算

The 160-bit digest is calculated as described in [FIPS-180-1]. A portable C language implementation of SHA1 is available via FTP from ftp://rand.org/pub/jim/sha.tar.gz.

160ビットダイジェストは、[FIPS-180-1]で説明されているように計算されます。sha1のポータブルC言語実装は、ftp：//rand.org/pub/jim/sha.tar.gzからFTPから入手できます。

The form of the authenticated message is:

認証されたメッセージの形式は次のとおりです。

SHA1( key, keyfill, datagram, datafill, key, sha1fill )

Sha1（key、keyfill、datagram、datafill、key、sha1fill）

First, the variable length secret authentication key is filled to the next 512-bit boundary, using the same pad-with-length technique defined for SHA1. The padding technique includes a length that protects arbitrary length keys.

まず、SHA1用に定義された同じ長さの手法を使用して、可変長さの秘密認証キーが次の512ビット境界に記入されます。パディング技術には、任意の長さキーを保護する長さが含まれています。

Next, the filled key is concatenated with (immediately followed by) the invariant fields of the entire IP datagram (variant fields are zeroed). This is also filled to the next 512-bit boundary, using the same pad-with-length technique defined for SHA1. The length includes the leading key and data.

次に、塗りつぶされたキーには、IPデータグラム全体の不変フィールド（バリアントフィールドがゼロになっている）が連結されます（その後に続いて）。これは、SHA1用に定義された同じパッド付き長さの手法を使用して、次の512ビット境界にも埋められます。長さには、主要なキーとデータが含まれます。

Then, the filled data is concatenated with (immediately followed by) the original variable length key again. A trailing pad-with-length to the next 512-bit boundary for the entire message is added by SHA1 itself.

次に、塗りつぶされたデータには、元の変数長キーが再び（すぐに続く）（すぐに続く）。メッセージ全体の次の512ビット境界までの長さの後続のパッドがSHA1自体によって追加されます。

Finally, the 160-bit SHA1 digest is calculated, and the result is inserted into the Authentication Data field.

最後に、160ビットSHA1ダイジェストが計算され、結果が認証データフィールドに挿入されます。

Discussion:

議論：

The leading copy of the key is padded in order to facilitate copying of the key at machine boundaries without requiring re-alignment of the following datagram. Filling to the SHA1 block size also allows the key to be prehashed to avoid the physical copy in some implementations.

キーの主要なコピーは、次のデータグラムの再編成を必要とせずに、マシンの境界でキーのコピーを容易にするためにパッドで埋められています。SHA1ブロックサイズに入力することで、キーを事前にチャッシュして、いくつかの実装で物理的なコピーを避けることができます。

The trailing copy of the key is not necessary to protect against appending attacks, as the IP datagram already includes a total length field. It reintroduces mixing of the entire key, providing protection for very long and very short datagrams, and robustness against possible attacks on the IP length field itself.

IPデータグラムには総長さフィールドが既に含まれているため、キーの後続コピーは、追加の攻撃から保護するために必要はありません。キー全体の混合を再導入し、非常に長くて非常に短いデータグラムの保護を提供し、IPの長さフィールド自体に対する攻撃の可能性に対する堅牢性を提供します。

When the implementation adds the keys and padding in place before and after the IP datagram, care must be taken that the keys and/or padding are not sent over the link by the link driver.

実装がIPデータグラムの前後にキーとパディングを所定の位置に追加する場合、リンクドライバーがリンクにキーやパディングを送信しないように注意する必要があります。

A. Changes

A.変更

Changes from RFC 1852:

RFC 1852からの変更：

Use of SHA1 term (as always intended).

SHA1用語の使用（常に意図したとおり）。

Added shortened 128-bit output, and clarify output text.

短縮された128ビット出力を追加し、出力テキストを明確にしました。

Added tradeoff text.

トレードオフテキストを追加しました。

Changed padding technique to comply with Crypto '95 recommendations.

Crypto '95の推奨事項に準拠するために、パディングテクニックを変更しました。

Updated references.

更新された参照。

Updated contacts.

更新された連絡先。

Minor editorial changes.

マイナーな編集の変更。

Security Considerations

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

Users need to understand that the quality of the security provided by this specification depends completely on the strength of the SHA1 hash function, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key, and upon the correctness of the implementations in all of the participating nodes.

ユーザーは、この仕様によって提供されるセキュリティの品質は、SHA1ハッシュ関数の強度、そのアルゴリズムの実装の正確性、キー管理メカニズムのセキュリティ、およびその実装、キーの強度、およびキーの強度に完全に依存することを理解する必要があります。参加しているすべてのノードの実装の正しさについて。

The SHA algorithm was originally derived from the MD4 algorithm [RFC-1320]. A flaw was apparently found in the original specification of SHA [FIPS-180], and this document specifies the use of a corrected version [FIPS-180-1].

SHAアルゴリズムは、もともとMD4アルゴリズム[RFC-1320]に由来していました。Sha [FIPS-180]の元の仕様で明らかに欠陥が見つかったようで、この文書は修正されたバージョン[FIPS-180-1]の使用を指定しています。

At the time of writing of this document, there are no known flaws in the SHA1 algorithm. That is, there are no known attacks on SHA1 or any of its components that are better than brute force, and the 160- bit hash size of SHA1 is substantially more resistant to brute force attacks than the 128-bit hash size of MD4 and MD5.

このドキュメントの執筆時点では、SHA1アルゴリズムに既知の欠陥はありません。つまり、SHA1またはブルートフォースよりも優れたコンポーネントに対する既知の攻撃はありません。SHA1の160ビットハッシュサイズは、MD4およびMD5の128ビットハッシュサイズよりもブルートフォース攻撃に対して実質的に耐性があります。。

However, as the flaw in the original SHA1 algorithm shows, cryptographers are fallible, and there may be substantial deficiencies yet to be discovered in the algorithm.

ただし、元のSHA1アルゴリズムの欠陥が示すように、暗号化者は誤りやすく、アルゴリズムではまだかなりの欠陥がある可能性があります。

Acknowledgements

謝辞

Some of the text of this specification was derived from work by Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.

この仕様のテキストの一部は、SIP、SIPP、およびIPv6ワーキンググループのランドールアトキンソンによる作業から派生しました。

Preliminary performance analysis was provided by Joe Touch.

ジョー・タッチによって予備的なパフォーマンス分析が提供されました。

Padding the leading copy of the key to a hash block boundary for increased performance was originally suggested by William Allen Simpson.

パフォーマンスを向上させるために、キーの主要なコピーをハッシュブロック境界にパディングすることは、もともとウィリアムアレンシンプソンによって提案されました。

Padding the leading copy of the key to a hash block boundary for increased security was suggested by [KR95]. Including the key length for increased security was suggested by David Wagner.

セキュリティを増やすために、キーの主要なコピーをハッシュブロック境界にパディングすることは、[KR95]によって提案されました。セキュリティを増やすためのキー長を含めることは、David Wagnerによって提案されました。

Padding the datagram to a hash block boundary to avoid (an impractical) key recovery attack was suggested by [PO95b].

データグラムをハッシュブロック境界にパディングして、[PO95B]によって（非現実的な）キーリカバリ攻撃を回避しました。

References

参考文献

[FIPS-180] "Secure Hash Standard", Computer Systems Laboratory, National Institute of Standards and Technology, U.S. Department Of Commerce, May 1993.

[FIPS-180]「Secure Hash Standard」、Computer Systems Laboratory、国立標準技術研究所、米国商務省、1993年5月。

Also known as: 58 Fed Reg 27712 (1993).

また、58 Fed Reg 27712（1993）としても知られています。

[FIPS-180-1] "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department Of Commerce, April 1995.

[FIPS-180-1]「Secure Hash Standard」、国立標準技術研究所、米国商務省、1995年4月。

Also known as: 59 Fed Reg 35317 (1994).

また、59 Fed Reg 35317（1994）としても知られています。

[KR95] Kaliski, B., and Robshaw, M., "Message authentication with MD5", CryptoBytes (RSA Labs Technical Newsletter), vol.1 no.1, Spring 1995.

[KR95] Kaliski、B。、およびRobshaw、M。、「MD5によるメッセージ認証」、Cryptobytes（RSA Labsテクニカルニュースレター）、Vol.1 No.1、1995年春。

[PO95a] Preneel, B., and van Oorshot, P., "MDx-MAC and Building Fast MACs from Hash Functions", Advances in Cryptology -- Crypto '95 Proceedings, Santa Barbara, California, August 1995.

[PO95A] Preneel、B。、およびVan Oorshot、P。、「MDX-MACおよびハッシュ機能からの高速MACの構築」、Cryptogy-Crypto '95 Proceedings、Santa Barbara、California、1995年8月。

[PO95b] Preneel, B., and van Oorshot, P., "On the Security of Two MAC Algorithms", Presented at the Rump Session of Crypto '95, Santa Barbara, California, August 1995.

[PO95B] Preneel、B。、およびVan Oorshot、P。、「2つのMACアルゴリズムのセキュリティについて」、1995年8月、カリフォルニア州サンタバーバラのCrypto '95のRumpセッションで発表されました。

[RFC 1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April 1992.

[RFC 1320] Rivest、R。、「MD4 Message-Digest Algorithm」、RFC 1320、1992年4月。

[RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.

[RFC 1700] Reynolds、J。およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。

[RFC 1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, July 1995.

[RFC 1825]アトキンソン、R。、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 1825、1995年7月。

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

[RFC 1826]アトキンソン、R。、「IP認証ヘッダー」、RFC 1826、1995年7月。

Contacts

連絡先

Comments about this document should be discussed on the photuris@adk.gr mailing list.

このドキュメントに関するコメントについては、Photuris@adk.grメーリングリストで説明する必要があります。

This document is a submission to the IP Security Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the current chairs:

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）のIPセキュリティワーキンググループへの提出です。ワーキンググループは、現在の椅子から連絡できます。

Questions about this document can also be directed to:

このドキュメントに関する質問は、次のように向けます。

Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033

Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd.、Suite＃2 New York、NY 10033

   EMail: perry@piermont.com

William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071

ウィリアム・アレン・シンプソン・デイドレーマー・コンピューター・システムコンサルティングサービス1384フォンテーヌ・マディソン・ハイツ、ミシガン州48071

   EMail: wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)

Editor's Note

編集者のメモ

This paper was originally submitted May 1, 1996.

この論文はもともと1996年5月1日に提出されました。

Full Copyright Statement

完全な著作権声明

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.

この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。