RFC3562 日本語訳
3562 Key Management Considerations for the TCP MD5 Signature Option.M. Leech. July 2003. (Format: TXT=14965 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Leech Request for Comments: 3562 Nortel Networks Category:Informational July 2003
コメントを求めるワーキンググループM.ヒルの要求をネットワークでつないでください: 3562 ノーテルはカテゴリ: 情報の2003年7月をネットワークでつなぎます。
Key Management Considerations for the TCP MD5 Signature Option
TCP MD5署名オプションのためのKey Management問題
Status of this Memo
このMemoの状態
This memo provides information 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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material.
BGPによって支配的に使用されたTCP MD5 Signature Option(RFC2385)はインターネット基盤の重要な領域で重要な展開を見ました。 このオプションのセキュリティは大いに材料がMD5署名を計算するのに使用した合わせることの品質を当てにします。 このドキュメントは、材料を合わせながら、セキュリティがその要件であると扱います。
1. Introduction
1. 序論
The security of various cryptographic functions lies both in the strength of the functions themselves against various forms of attack, and also, perhaps more importantly, in the keying material that is used with them. While theoretical attacks against the simple MAC construction used in RFC 2385 are possible [MDXMAC], the number of text-MAC pairs required to mount a forgery make it vastly more probable that key-guessing is the main threat against RFC 2385.
様々な形式の攻撃に対して様々な暗号の機能のセキュリティが機能自体の強さに両方の、あります、そして、合わせることの材料の中では、また、恐らくより重要に、それはそれらと共に使用されます。 RFC2385で使用される簡単なMAC工事に対する理論上の攻撃が可能である間[MDXMAC]、組が偽造を仕掛けるのを必要としたテキスト-MACの数で、キー推測がRFC2385に対する主な脅威であることは広大にありえそうになります。
We show a quantitative approach to determining the security requirements of keys used with [RFC2385], which tends to suggest the following:
私たちは以下を示す傾向がある[RFC2385]と共に使用されるキーのセキュリティ要件を決定することへの量的なアプローチを示しています:
o Key lengths SHOULD be between 12 and 24 bytes, with larger keys having effectively zero additional computational costs when compared to shorter keys.
o キー長SHOULDは12の間のそうであり、24はバイトです、より短いキーと比べる場合事実上どんな追加コンピュータのコストも持っていないより大きいキーで。
Leech Informational [Page 1] RFC 3562 Considerations for the TCP MD5 Signature Option July 2003
署名オプション2003年7月にTCP MD5のための情報[1ページ]のRFC3562問題を取ってください。
o Key sharing SHOULD be limited so that keys aren't shared among multiple BGP peering arrangements.
o キーが複数のBGPじっと見るアレンジメントの中で共有されないように制限されていて、SHOULDを共有するキー。
o Keys SHOULD be changed at least every 90 days.
o キーSHOULD、少なくともあらゆる90日間単位で変えてください。
1.1. Requirements Keywords
1.1. 要件キーワード
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」 現れる「5月」は中[RFC2119]で説明されるように本書では解釈されることになっているべきです。
2. Performance assumptions
2. パフォーマンス仮定
The most recent performance study of MD5 that this author was able to find was undertaken by J. Touch at ISI. The results of this study were documented in [RFC1810]. The assumption is that Moores Law applies to the data in the study, which at the time showed a best-possible *software* performance for MD5 of 87Mbits/second. Projecting this number forward to the ca 2002 timeframe of this document, would suggest a number near 2.1Gbits/second.
この作者が見つけることができたMD5の最新の性能研究はISIでJ.Touchによって引き受けられました。 この研究の結果は[RFC1810]に記録されました。 仮定はムーア法が当時、87Mbits/秒のMD5に、最も良い可能な*ソフトウェア*性能を示した研究におけるデータに適用されるということです。 2002年のこのドキュメントのca時間枠にこの数のフォワードを映し出して、2.1Gbits/秒の近くに数を示すでしょう。
For purposes of simplification, we will assume that our key-guessing attacker will attack short packets only. A likely minimal packet is an ACK, with no data. This leads to having to compute the MD5 over about 40 bytes of data, along with some reasonable maximum number of key bytes. MD5 effectively pads its input to 512-bit boundaries (64 bytes) (it's actually more complicated than that, but this simplifying assumption will suffice for this analysis). That means that a minimum MD5 "block" is 64 bytes, so for a ca 2002-scaled software performance of 2.1Gbits/second, we get a single-CPU software MD5 performance near 4.1e6 single-block MD5 operations per second.
簡素化の目的のために、私たちは、私たちのキーを推測する攻撃者が脆いパケットだけを攻撃すると思うつもりです。 ありそうな最小量のパケットはデータがなければACKです。 これは、およそ40バイトのデータに関してMD5を計算しなければならないのに通じます、何らかの妥当な最大数の主要なバイトと共に。 事実上、MD5は512ビットの境界(64バイト)に入力を水増しします(それが実際にそれより複雑ですが、この簡素化仮定はこの分析に十分でしょう)。 それが、最小のMD5「ブロック」が64バイトであることを意味するので、2.1Gbits/秒のcaに2002でスケーリングされたソフトウェア・パフォーマンスのために、私たちはほぼ1秒あたりの4.1e6単滑車MD5操作で単一のCPUソフトウェアMD5性能を得ます。
These numbers are, of course, assuming that any key-guessing attacker is resource-constrained to a single CPU. In reality, distributed cryptographic key-guessing attacks have been remarkably successful in the recent past.
これらの数は、もちろんどんなキーを推測する攻撃者もリソースで強制的であると単一のCPUに仮定しています。 ほんとうは、分配された暗号のキーを推測する攻撃は最近において著しくうまくいっています。
It may be instructive to look at recent Internet worm infections, to determine what the probable maximum number of hosts that could be surreptitiously marshalled for a key-guessing attack against MD5. CAIDA [CAIDA2001] has reported that the Code Red worm infected over 350,000 Internet hosts in the first 14 hours of operation. It seems reasonable to assume that a worm whose "payload" is a mechanism for quietly performing a key-guessing attack (perhaps using idle CPU cycles of the infected host) could be at least as effective as Code Red was. If one assumes that such a worm were engineered to be maximally stealthy, then steady-state infection could conceivably reach 1 million hosts or more. That changes our single-CPU
最近のインターネットワーム感染力を調べるのは、ありえそうな最大が付番するキーを推測する攻撃のためにこっそりとMD5に対して整列できたホストのことを決定するためにためになっているかもしれません。 CAIDA[CAIDA2001]は、コード・レッド・ワームが最初の14時間の操作で35万人以上のインターネット・ホストを感染させたと報告しました。 「ペイロード」が静かにキーを推測する攻撃(恐らく、感染宿主の暇なCPUサイクルを費やす)を実行するためのメカニズムであるワームがCode Redと少なくとも同じくらい有効であるかもしれないと仮定するのは妥当に思えます。 人は、そのようなワームが最高にこっそりなるように設計されて、次に、定常状態感染が多分100万人のホストに届くかもしれないと仮定するか、そして、以上。 それは私たちの単一のCPUを変えます。
Leech Informational [Page 2] RFC 3562 Considerations for the TCP MD5 Signature Option July 2003
署名オプション2003年7月にTCP MD5のための情報[2ページ]のRFC3562問題を取ってください。
performance from 4.1e6 operations per second, to somewhere between 1.0e11 and 1.0e13 MD5 operations per second.
1秒あたりの4.1e6操作から1秒あたりの1.0e11と1.0e13 MD5操作の間のどこかまでの性能。
In 1997, John Gilmore, and the Electronic Frontier Foundation [EFF98] developed a special-purpose machine, for an investment of approximately USD$250,000. This machine was able to mount a key-guessing attack against DES, and compute a key in under 1 week. Given Moores Law, the same investment today would yield a machine that could do the same work approximately 8 times faster. It seems reasonable to assume that a similar hardware approach could be brought to bear on key-guessing attacks against MD5, for similar key lengths to DES, with somewhat-reduced performance (MD5 performance in hardware may be as much as 2-3 times slower than DES).
1997年に、ジョン・ギルモア、および電子フロンティア財団[EFF98]はおよそU.S.ドルの投資のための専用マシンを25万ドル開発しました。 このマシンは、DESに対してキーを推測する攻撃を仕掛けて、1週間未満でキーを計算できました。 ムーア法を考えて、今日の同じ投資は、より速くおよそ8回同じ仕事ができたマシンをもたらすでしょう。 キーを推測する攻撃のときにMD5に対して同様のハードウェアアプローチを生かすことができたと仮定するのは妥当に思えます、DESへの同様のキー長のために、いくらか減少している性能で(ハードウェアにおけるMD5性能はDESより何倍も遅い2-3であるかもしれません)。
3. Key Lifetimes
3. 主要な生涯
Operational experience with RFC 2385 would suggest that keys used with this option may have lifetimes on the order of months. It would seem prudent, then, to choose a minimum key length that guarantees that key-guessing runtimes are some small multiple of the key-change interval under best-case (for the attacker) practical attack performance assumptions.
RFC2385の運用経験は、このオプションと共に使用されるキーが何カ月もの注文に生涯を持っているかもしれないのを示すでしょう。 そして、キーを推測するランタイムが最も良いケース(攻撃者のための)の実用的な攻撃性能仮定の下のキーチェンジ間隔の何らかのわずかな倍数であることを保証する最小のキー長を選ぶのは慎重に思えるでしょう。
The keys used with RFC 2385 are intended only to provide authentication, and not confidentiality. Consequently, the ability of an attacker to determine the key used for old traffic (traffic emitted before a key-change event) is not considered a threat.
RFC2385と共に使用されるキーが単に秘密性ではなく、認証を提供することを意図します。 その結果、攻撃者が古いトラフィック(キーチェンジイベントの前に放たれたトラフィック)に使用されるキーを決定する能力は脅威であると考えられません。
3. Key Entropy
3. 主要なエントロピー
If we make an assumption that key-change intervals are 90 days, and that the reasonable upper-bound for software-based attack performance is 1.0e13 MD5 operations per second, then the minimum required key entropy is approximately 68 bits. It is reasonable to round this number up to at least 80 bits, or 10 bytes. If one assumes that hardware-based attacks are likely, using an EFF-like development process, but with small-country-sized budgets, then the minimum key size steps up considerably to around 83 bits, or 11 bytes. Since 11 is such an ugly number, rounding up to 12 bytes is reasonable.
私たちがキーチェンジ間隔が90日間であり、ソフトウェアベースの攻撃性能のための妥当な上限が1秒あたり1.0e13 MD5操作であるという仮定をするなら、最小の必要な主要なエントロピーはおよそ68ビットです。 この数を少なくとも80ビット、または10バイトまで一周させるのは妥当です。 人が、それがハードウェアベースであると仮定するなら、EFFのような開発過程を使用して、攻撃はありそうですが、小さい国のサイズの予算で、そして、最小の主要なサイズはおよそ83ビット、または11バイトにかなり上げられます。 11が非常に醜い数であるので、12バイトへの一斉逮捕は合理的です。
In order to achieve this much entropy with an English-language key, one needs to remember that English has an entropy of approximately 1.3 bits per character. Other human languages are similar. This means that a key derived from a human language would need to be approximately 61 bytes long to produce 80 bits of entropy, and 73 bytes to produce 96 bits of entropy.
英語キーでこれだけのエントロピーを達成するために、人は、英語には1キャラクタあたりおよそ1.3ビットのエントロピーがあるのを覚えている必要があります。 他の人間の言語は同様です。 これは、人間の言語から得られたキーが、エントロピーの80ビット、および96ビット作り出すエントロピーの73バイトを作り出すのにおよそ61バイト長である必要を意味します。
Leech Informational [Page 3] RFC 3562 Considerations for the TCP MD5 Signature Option July 2003
署名オプション2003年7月にTCP MD5のための情報[3ページ]のRFC3562問題を取ってください。
A more reasonable approach would be to use the techniques described in [RFC1750] to produce a high quality random key of 96 bits or more.
より合理的なアプローチは96ビット以上の高品質のランダムキーを生産するために[RFC1750]で説明されたテクニックを使用するだろうことです。
It has previously been noted that an attacker will tend to choose short packets to mount an attack on, since that increases the key-guessing performance for the attacker. It has also been noted that MD5 operations are effectively computed in blocks of 64 bytes. Given that the shortest packet an attacker could reasonably use would consist of 40 bytes of IP+TCP header data, with no payload, the remaining 24 bytes of the MD5 block can reasonably be used for keying material without added CPU cost for routers, but substantially increase the burden on the attacker. While this practice will tend to increase the CPU burden for ordinary short BGP packets, since it will tend to cause the MD5 calculations to overflow into a second MD5 block, it isn't currently seen to be a significant extra burden to BGP routing machinery.
以前に攻撃者が、攻撃を開始する脆いパケットを選ぶ傾向があることに注意されました、それが攻撃者のためのキーを推測する性能を増強するので。 また、事実上、MD5操作が64バイトのブロックで計算されることに注意されました。 攻撃者が合理的に使用できた中で最も脆いパケットが40バイトのIP+TCPヘッダー・データから成るなら、ペイロードがなければ、ルータのために加えられたCPU費用なしで材料を合わせるのにMD5ブロックの残っている24バイトを合理的に使用できますが、攻撃者でかなり負担を増強してください。 それが、MD5計算が第2MD5ブロックにあふれることを引き起こす傾向があるのでこの習慣が、普通の脆いBGPパケットのためにCPU負担を増強する傾向がある間、それは現在、BGPルーティング機械への重要な付加的な負担であると考えられません。
The most reasonable practice, then, would be to choose the largest possible key length smaller than 25 bytes that is operationally reasonable, but at least 12 bytes.
そして、最も妥当な習慣はそれが25バイトに操作上妥当であるよりわずかな可能な限り大きいキー長、しかし、少なくとも12バイトを選ぶことになっているでしょう。
Some implementations restrict the key to a string of ASCII characters, much like simple passwords, usually of 8 bytes or less. The very real risk is that such keys are quite vulnerable to key-guessing attacks, as outlined above. The worst-case scenario would occur when the ASCII key/password is a human-language word, or pseudo-word. Such keys/passwords contain, at most, 12 bits of entropy. In such cases, dictionary driven attacks can yield results in a fraction of the time that a brute-force approach would take. Such implementations SHOULD permit users to enter a direct binary key using the command line interface. One possible implementation would be to establish a convention that an ASCII key beginning with the prefix "0x" be interpreted as a string of bytes represented in hexadecimal. Ideally, such byte strings will have been derived from a random source, as outlined in [RFC1750]. Implementations SHOULD NOT limit the length of the key unnecessarily, and SHOULD allow keys of at least 16 bytes, to allow for the inevitable threat from Moores Law.
いくつかの実装が一連のASCII文字のキーを制限します、通常、8バイト以下の簡単なパスワードのように。 非常に本当のリスクはそのようなキーが上に概説されているようにキーを推測する攻撃に全く被害を受け易いということです。 ASCIIキー/パスワードが人間の言語単語、または疑似単語であるときに、最悪の事態のシナリオは起こるでしょう。 そのようなキー/パスワードは大部分にエントロピーの12ビットを含んでいます。 そのような場合、駆動攻撃がもたらすことができる辞書はブルートフォースアプローチが取るだろう現代の部分で結果として生じます。 そのような実装SHOULDは、ユーザがダイレクト2進のキーを入れるのをコマンドラインインタフェースを使用することで可能にします。 1つの可能な実装は接頭語"0x"が一連のバイトとして解釈されているASCIIの主要な始めが16進で代表したコンベンションを設立するだろうことです。 理想的に、[RFC1750]に概説されているように無作為のソースからそのようなバイトストリングを得てしまうでしょう。 実装SHOULD NOTは不必要にキーの長さを制限します、そして、SHOULDはムーア法から必然の脅威を考慮するために少なくとも16バイトのキーを許容します。
4. Key management practices
4. かぎ管理練習
In current operational use, TCP MD5 Signature keys [RFC2385] may be shared among significant numbers of systems. Conventional wisdom in cryptography and security is that such sharing increases the probability of accidental or deliberate exposure of keys. The more frequently such keying material is handled, the more likely it is to be accidentally exposed to unauthorized parties.
現在の操作上の使用で、TCP MD5 Signatureキー[RFC2385]は重要な数のシステムの中で共有されるかもしれません。暗号とセキュリティにおける一般通念はそのような共有がキーの偶然の、または、慎重な展示の確率を増強するということです。 材料をそのような合わせるのであるのが、より頻繁に扱われれば扱うほど、それは偶然権限のないパーティーにより暴露されそうです。
Leech Informational [Page 4] RFC 3562 Considerations for the TCP MD5 Signature Option July 2003
署名オプション2003年7月にTCP MD5のための情報[4ページ]のRFC3562問題を取ってください。
Since it is possible for anyone in possession of a key to forge packets as if they originated with any of the other keyholders, the most reasonable security practice would be to limit keys to use between exactly two parties. Current implementations may make this difficult, but it is the most secure approach when key lifetimes are long. Reducing key lifetimes can partially mitigate widescale key-sharing, by limiting the window of opportunity for a "rogue" keyholder.
まるで他のkeyholdersのどれかを発するかのようにキーの所持のだれでもパケットを鍛造するのが、可能であるので、最も妥当なセキュリティ実践はキーをちょうど2回のパーティーの間の使用に制限するだろうことです。 現在の実装でこれは難しくなるかもしれませんが、主要な寿命が長いときに、それは最も安全なアプローチです。 主要な生涯を短縮すると、「凶暴な」keyholderの機会の窓を制限することによって、widescaleキー共有を部分的に緩和できます。
Keying material is extremely sensitive data, and as such, should be handled with reasonable caution. When keys are transported electronically, including when configuring network elements like routers, secure handling techniques MUST be used. Use of protocols such as S/MIME [RFC2633], TLS [RFC2246], Secure Shell (SSH) SHOULD be used where appropriate, to protect the transport of the key.
材料を合わせるのは、非常に機密のデータです、そして、そういうものとして、妥当な警告で扱われるべきです。 ネットワーク要素がルータが好きであることを構成して、いつ安全な取り扱いのテクニックを使用しなければならないかを含んでいて、キーが電子的に輸送されるとき。 S/MIME[RFC2633]、TLS[RFC2246]、Secureシェル(SSH)SHOULDのようなプロトコルの使用、キーの輸送を保護するのに適切であるところで使用されます。
5. Security Considerations
5. セキュリティ問題
This document is entirely about security requirements for keying material used with RFC 2385.
このドキュメントはRFC2385と共に使用される材料を合わせるための完全なセキュリティ要件に関するものです。
No new security exposures are created by this document.
どんな新しいセキュリティ暴露もこのドキュメントによって作成されません。
6. Acknowledgements
6. 承認
Steve Bellovin, Ran Atkinson, and Randy Bush provided valuable commentary in the development of this document.
スティーブBellovin、Ranアトキンソン、およびランディ・ブッシュはこのドキュメントの開発における貴重な論評を提供しました。
7. References
7. 参照
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
1995年の[RFC1771]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
接触、J.が「MD5パフォーマンスに関して報告する」[RFC1810]、RFC1810、1995年6月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[MDXMAC] Van Oorschot, P. and B. Preneel, "MDx-MAC and Building Fast MACs from Hash Functions". Proceedings Crypto '95, Springer-Verlag LNCS, August 1995.
[MDXMAC]はOorschot、P.、B.Preneel、「MDx-MAC、ハッシュ関数から速いMACsを造ること」をバンに積みます。 議事暗号95年、追出石-Verlag LNCS、1995年8月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
Leech Informational [Page 5] RFC 3562 Considerations for the TCP MD5 Signature Option July 2003
署名オプション2003年7月にTCP MD5のための情報[5ページ]のRFC3562問題を取ってください。
[EFF98] "Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design". Electronic Frontier Foundation, 1998.
[EFF98]、「分解DES:」 「暗号化のシークレットは、研究して、政治を盗聴して、デザインを欠きます。」 電子フロンティア財団、1998。
[RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633] Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[CAIDA2001] "CAIDA Analysis of Code Red" http://www.caida.org/analysis/security/code-red/
[CAIDA2001]「コード赤のCAIDA分析」 http://www.caida.org/analysis/security/code-red/
8. Author's Address
8. 作者のアドレス
Marcus D. Leech Nortel Networks P.O. Box 3511, Station C Ottawa, ON Canada, K1Y 4H7
マーカスD.Leechノーテルは私書箱3511、駅のCオタワをカナダ、K1Y 4H7にネットワークでつなぎます。
Phone: +1 613-763-9145 EMail: mleech@nortelnetworks.com
以下に電話をしてください。 +1 613-763-9145 メールしてください: mleech@nortelnetworks.com
Leech Informational [Page 6] RFC 3562 Considerations for the TCP MD5 Signature Option July 2003
署名オプション2003年7月にTCP MD5のための情報[6ページ]のRFC3562問題を取ってください。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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 assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
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機能のための基金は現在、インターネット協会によって提供されます。
Leech Informational [Page 7]
ヒルの情報です。[7ページ]
一覧
スポンサーリンク