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)
インターリーブパディング付きキー付きSHA1を使用してIP認証（IP-MAC）
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.
このメモはインターネットコミュニティのための歴史的な文書を定義します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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
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）とキーのAHの使用を記載している[FIPS-180-1]。この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]、「インターネットプロトコルのためのセキュリティー体系」に精通していることを前提としており、この仕様のための重要な背景を提供します。
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オクテット）の長さは、実装によってサポートされなければなりません。より長いキーが奨励されています。
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）パディングの追加の32ビット（4つのオクテット）SHA1出力の前に添加されます。
3) an additional 32-bits (4 octets) of padding is added after the SHA1 output.
3）パディングの追加の32ビット（4オクテット）はSHA1出力後に添加されます。
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]を向上させることが示唆されました。
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ハッシュほど高速であることを示しています。あれは：
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.
注意ベーネ：提案を大幅に高速スループットを持つ代替認証アルゴリズムに求められている、特許邪魔されず、まだ十分な暗号強度を保持。
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.
[FIPS-180-1]に記載されているように160ビットのダイジェストを計算します。 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（キー、keyfill、データグラム、datafill、キー、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ブロックサイズに充填することも、キーがいくつかの実装では物理的なコピーを避けるためにprehashedすることができます。
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.
暗号'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 Working GroupにおけるRandall Atkinsonの成果から得られました。
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]によって提案されました。セキュリティを強化するための鍵の長さを含めて、デビッド・ワグナーによって示唆されました。
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]、コンピュータシステム研究所、国立標準技術研究所、米国商務省が、1993年5月「ハッシュ標準セキュア」。
Also known as: 58 Fed Reg 27712 (1993).
58連銀の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]、国立標準技術研究所、米国商務省が、1995年4月「ハッシュ標準セキュア」。
Also known as: 59 Fed Reg 35317 (1994).
59連銀の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研究所テクニカルレター）、第1巻第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.、およびバンOorschot、PDX-MACや建物のハッシュ関数から速いMACは」、暗号理論の進歩 - 暗号'95の議事録、サンタバーバラ、カリフォルニア州、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.、およびバンOorshot、P.、暗号'95のランプセッションで発表され、サンタバーバラ、カリフォルニア州、1995年8月「二MACアルゴリズムのセキュリティについて」。
[RFC 1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April 1992.
[RFC 1320]のRivest、R.、 "MD4メッセージダイジェストアルゴリズム"、RFC 1320、1992年4月。
[RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC 1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、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
ペリーメッツガーピアモント情報システム株式会社160 Cabriniブルバード、スイート＃2ニューヨーク、NY 10033
EMail: perry@piermont.com
メールアドレス：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)
Eメール：wsimpson@UMich.edu wsimpson@GreenDragon.com（優先）
Editor's Note
編集者のメモ
This paper was originally submitted May 1, 1996.
この論文は、もともと1996年5月1日に提出されました。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。