RFC2841 日本語訳
2841 IP Authentication using Keyed SHA1 with Interleaved Padding(IP-MAC). P. Metzger, W. Simpson. November 2000. (Format: TXT=14139 bytes) (Obsoletes RFC1852) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Metzger
Request for Comments: 2841 Piermont
Category: Historic W. Simpson
Obsoletes: 1852 DayDreamer
November 2000
コメントを求めるワーキンググループP.メッツガー要求をネットワークでつないでください: 2841年のピアモントカテゴリ: 歴史的なW.シンプソンは以下を時代遅れにします。 1852 空想家2000年11月
IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)
はさみ込まれた詰め物がある合わせられたSHA1を使用するIP認証(IP-Mac)
Status of this Memo
この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.
このメモはインターネットコミュニティのためにHistoric Documentを定義します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes the use of keyed SHA1 with the IP Authentication Header.
このドキュメントはIP Authentication Headerとの合わせられた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. 序論… 2 1.1. キー… 2 1.2. データサイズ… 2 1.3. パフォーマンス… 3 2. 計算… 3 A.は変化します… 5 セキュリティ問題… 6つの承認… 6つの参照箇所… 7 連絡します。 8編集者注… 8 完全な著作権宣言文… 9
Metzger & Simpson Historic [Page 1] RFC 2841 AH SHA1 IP-MAC November 2000
メッツガーとシンプソンHistoric、[ああ、SHA1IP-MAC2000年11月に1]RFC2841を呼び出してください。
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.
Authentication Header(AH)[RFC-1826]はIPデータグラムのための保全と認証を提供します。この仕様はSecure Hash Algorithm(SHA1)[FIPS-180-1]とのキーのAH使用について説明します。 このSHA1IP 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.
このドキュメントがSHAの失敗した[FIPS-180]で説明されたそれより新しいバージョンを指定することに注意されるべきです。 旧式のバージョンは、より新しいバージョンで共同利用できません。
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.
このドキュメントが、読者が「インターネットプロトコルのためのセキュリティー体系」[RFC1825]という関連するドキュメントに詳しいと仮定して、それは、IPのために総合的な警備計画を定義して、重要なバックグラウンドをこの仕様に提供します。
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.
秘密の認証キーが交信パーティーSHOULDを平等に割り当てた、暗号で、強い乱数、どんな種類の推測可能ストリングでない。
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の八重奏)の長さをサポートしなければなりません。 より長いキーは奨励されます。
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) 詰め物の追加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の八重奏)以内で変化しやすく置かれます。
Metzger & Simpson Historic [Page 2] RFC 2841 AH SHA1 IP-MAC November 2000
メッツガーとシンプソンHistoric、[ああ、SHA1IP-MAC2000年11月に2]RFC2841を呼び出してください。
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がDESの論じ尽くすのとMD5と62%同じくらい速い、および80%同じくらい速いのを示します。 それは以下の通りです。
SHA1 < DES < MD5
SHA1<デス<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
デス<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.
背板嘆願: 提案は、かなり速いスループットを持っている代替の認証アルゴリズムで探されて、妨げられなかった、どんな特許でありも、まだ適切な暗号の強さを保有しています。
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(キー、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.
まず最初に、可変長の秘密の認証キーは次の512ビットの境界にいっぱいにされます、SHA1のために定義された同じ長さがあるパッドのテクニックを使用して。 詰め物のテクニックは任意の長さのキーを保護する長さを含んでいます。
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ビットの境界にいっぱいにされます。 長さは主なキーとデータを含んでいます。
Metzger & Simpson Historic [Page 3] RFC 2841 AH SHA1 IP-MAC November 2000
メッツガーとシンプソンHistoric、[ああ、SHA1IP-MAC2000年11月に3]RFC2841を呼び出してください。
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ダイジェストは計算されます、そして、結果はAuthentication Data分野に挿入されます。
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データグラム、注意を払わなければならなかった後に、キー、そして/または、詰め物が適所にあるキーと詰め物ですが、実装がいつ加えるかがリンクドライバーでリンクを移動しました。
Metzger & Simpson Historic [Page 4] RFC 2841 AH SHA1 IP-MAC November 2000
メッツガーとシンプソンHistoric、[ああ、SHA1IP-MAC2000年11月に4]RFC2841を呼び出してください。
A. Changes
A。 変化
Changes from RFC 1852:
RFC1852からの変化:
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.
Crypto95年の推薦に従うために詰め物のテクニックを変えました。
Updated references.
参照をアップデートしました。
Updated contacts.
接触をアップデートしました。
Minor editorial changes.
小さい方の社説は変化します。
Metzger & Simpson Historic [Page 5] RFC 2841 AH SHA1 IP-MAC November 2000
メッツガーとシンプソンHistoric、[ああ、SHA1IP-MAC2000年11月に5]RFC2841を呼び出してください。
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].
元々、MD4アルゴリズム[RFC-1320]からSHAアルゴリズムを得ました。 欠点は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 Groupsのために仕事に由来されていました。
Preliminary performance analysis was provided by Joe Touch.
予備の機能解析はジョー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]によって示されました。
Metzger & Simpson Historic [Page 6] RFC 2841 AH SHA1 IP-MAC November 2000
メッツガーとシンプソンHistoric、[ああ、SHA1IP-MAC2000年11月に6]RFC2841を呼び出してください。
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がそうするかもしれません。
Also known as: 58 Fed Reg 27712 (1993).
また、知られています: 58はレッジ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はレッジ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 Technicalニュースレター)、vol.1 no.1、Spring1995との通報認証。」
[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.、バンOorshot、P.、「MDx-MAC、ハッシュ関数からの速いMACsを造る」(95年Proceedings、Cryptoサンタバーバラ(カリフォルニア)1995年Cryptology--8月のAdvances)。
[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、Crypto95年、サンタバーバラ(カリフォルニア)(1995年8月)のRump Sessionの「2つのMACアルゴリズムのセキュリティ」のP.Presented。
[RFC 1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC
1320, April 1992.
[RFC1320] Rivest、R.、「MD4メッセージダイジェストアルゴリズム」、RFC1320、1992年4月。
[RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994.
[RFC1700] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[RFC 1825] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 1825, July 1995.
[RFC1825] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、1995年7月。
[RFC 1826] Atkinson, R., "IP Authentication Header", RFC 1826, July
1995.
[RFC1826] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年7月。
Metzger & Simpson Historic [Page 7] RFC 2841 AH SHA1 IP-MAC November 2000
メッツガーとシンプソンHistoric、[ああ、SHA1IP-MAC2000年11月に7]RFC2841を呼び出してください。
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:
このドキュメントはIP Securityインターネット・エンジニアリング・タスク・フォース作業部会(IETF)への服従です。 現在のいすを通してワーキンググループに連絡できます:
Questions about this document can also be directed to:
また、このドキュメントに関する質問による以下のことよう指示できます。
Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033
ニューヨーク、スイート#2ニューヨーク ペリーメッツガーピアモント情報システム株式会社160カブリーニBlvd.、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)
メール: wsimpson@UMich.edu wsimpson@GreenDragon.com(都合のよい)です。
Editor's Note
編集者注
This paper was originally submitted May 1, 1996.
1996年5月1日に元々、この論文を提出しました。
Metzger & Simpson Historic [Page 8] RFC 2841 AH SHA1 IP-MAC November 2000
メッツガーとシンプソンHistoric、[ああ、SHA1IP-MAC2000年11月に8]RFC2841を呼び出してください。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Metzger & Simpson Historic [Page 9]
メッツガーとシンプソンHistoricです。[9ページ]
一覧
スポンサーリンク
