RFC2444 日本語訳

Network Working Group                                          C. Newman
Request for Comments: 2444                                      Innosoft
Updates: 2222                                               October 1998
Category: Standards Track

コメントを求めるワーキンググループC.ニューマン要求をネットワークでつないでください: 2444のInnosoftアップデート: 2222 1998年10月のカテゴリ: 標準化過程

                  The One-Time-Password SASL Mechanism

1つの時間パスワードSASLメカニズム

Status of this Memo

この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)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

Abstract

要約

   OTP [OTP] provides a useful authentication mechanism for situations
   where there is limited client or server trust.  Currently, OTP is
   added to protocols in an ad-hoc fashion with heuristic parsing.  This
   specification defines an OTP SASL [SASL] mechanism so it can be
   easily and formally integrated into many application protocols.

OTP[OTP]は限られたクライアントかサーバ信頼がある状況に役に立つ認証機構を提供します。 現在、OTPは発見的な構文解析がある臨時のファッションでプロトコルに追加されます。 この仕様は、簡単に正式に多くのアプリケーション・プロトコルとそれを統合できるようにOTP SASL[SASL]メカニズムを定義します。

1. How to Read This Document

1. このドキュメントを読む方法

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED" and "MAY" in this document are to be interpreted as
   defined in "Key words for use in RFCs to Indicate Requirement Levels"
   [KEYWORDS].

キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」、このドキュメントの「推薦され」て「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で定義されるように解釈されることになっているべきです。

   This memo assumes the reader is familiar with OTP [OTP], OTP extended
   responses [OTP-EXT] and SASL [SASL].

このメモは、読者がOTP[OTP]に詳しいと仮定して、OTPは応答[OTP-EXT]とSASL[SASL]を広げました。

2. Intended Use

2. 意図している使用

   The OTP SASL mechanism replaces the SKEY SASL mechanism [SASL].  OTP
   is a good choice for usage scenarios where the client is untrusted
   (e.g., a kiosk client), as a one-time password will only give the
   client a single opportunity to act on behalf of the user.  OTP is
   also a good choice for situations where interactive logins are
   permitted to the server, as a compromised OTP authentication database
   is only subject to dictionary attacks, unlike authentication
   databases for other simple mechanisms such as CRAM-MD5 [CRAM-MD5].

OTP SASLメカニズムはSKEY SASLメカニズム[SASL]を置き換えます。 OTPはクライアントが信頼されていない用法シナリオ(例えば、キオスククライアント)のための良い選択です、ワンタイムパスワードがユーザを代表して行動するただ一つの機会をクライアントに与えるだけであるとき。 また、OTPは対話的なログインがサーバに受入れられる状況のための良い選択です、感染しているOTP認証データベースが単に辞書攻撃を受けることがあるとき、CRAM-MD5[CRAM-MD5]などの他の簡単なメカニズムのための認証データベースと異なって。

Newman                      Standards Track                     [Page 1]

RFC 2444                   OTP SASL Mechanism               October 1998

ニューマンStandardsはOTP SASLメカニズム1998年10月にRFC2444を追跡します[1ページ]。

   It is important to note that each use of the OTP mechanism causes the
   authentication database entry for a user to be updated.

OTPメカニズムの各使用がユーザがアップデートされるデータベースエントリーを認証に引き起こすことに注意するのは重要です。

   This SASL mechanism provides a formal way to integrate OTP into
   SASL-enabled protocols including IMAP [IMAP4], ACAP [ACAP], POP3
   [POP-AUTH] and LDAPv3 [LDAPv3].

このSASLメカニズムはIMAP[IMAP4]、ACAP[ACAP]、POP3[POP-AUTH]、およびLDAPv3[LDAPv3]を含むSASLによって可能にされたプロトコルとOTPを統合する正式な方法を提供します。

3. Profiling OTP for SASL

3. SASLのためにOTPの輪郭を描きます。

   OTP [OTP] and OTP extended responses [OTP-EXT] offer a number of
   options.  However, for authentication to succeed, the client and
   server need compatible option sets.  This specification defines a
   single SASL mechanism: OTP.  The following rules apply to this
   mechanism:

OTP[OTP]とOTPは[OTP-EXT]が多くのオプションを提供する応答を広げました。 しかしながら、認証が成功するように、クライアントとサーバはコンパチブルオプションセットを必要とします。 この仕様はただ一つのSASLメカニズムを定義します: OTP。 以下の規則はこのメカニズムに適用されます:

   o   The extended response syntax MUST be used.

o 拡張応答構文を使用しなければなりません。

   o   Servers MUST support the following four OTP extended responses:
       "hex", "word", "init-hex" and "init-word".  Servers MUST support
       the "word" and "init-word" responses for the standard dictionary
       and SHOULD support alternate dictionaries.  Servers MUST NOT
       require use of any additional OTP extensions or options.

o サーバは以下の4OTPに拡張応答をサポートしなければなりません: 「十六進法」、「単語」、「イニット十六進法」、および「イニット単語。」 サーバは標準的な辞典とSHOULDサポートのための「単語」と「イニット単語」応答に代替の辞書をサポートしなければなりません。 サーバはどんな追加OTP拡張子やオプションの使用も必要としてはいけません。

   o   Clients SHOULD support display of the OTP challenge to the user
       and entry of an OTP in multi-word format.  Clients MAY also
       support direct entry of the pass phrase and compute the "hex" or
       "word" response.

o クライアントSHOULDはユーザへのOTP挑戦のディスプレイと句動詞形式における、OTPのエントリーをサポートします。 クライアントは、また、パス句のダイレクトエントリーをサポートして、応答という「十六進法」か「単語」を計算するかもしれません。

   o   Clients MUST indicate when authentication fails due to the
       sequence number getting too low and SHOULD offer the user the
       option to reset the sequence using the "init-hex" or "init-word"
       response.

o クライアントは、認証がいつ低くなり過ぎる一連番号のため失敗するかを示さなければなりません、そして、SHOULDは「イニット十六進法」か「イニット単語」応答を使用することで系列をリセットするためにオプションをユーザに申し出ます。

   Support for the MD5 algorithm is REQUIRED, and support for the SHA1
   algorithm is RECOMMENDED.

MD5アルゴリズムのサポートはREQUIREDです、そして、SHA1アルゴリズムのサポートはRECOMMENDEDです。

4. OTP Authentication Mechanism

4. OTP認証機構

   The mechanism does not provide any security layer.

メカニズムはどんなセキュリティ層も提供しません。

   The client begins by sending a message to the server containing the
   following two pieces of information.

クライアントは、2つの情報を含むサーバにメッセージを送ることによって、始めます。

   (1) An authorization identity.  When the empty string is used, this
   defaults to the authentication identity.  This is used by system
   administrators or proxy servers to login with a different user
   identity.  This field may be up to 255 octets and is terminated by a
   NUL (0) octet.  US-ASCII printable characters are preferred, although

(1) 承認のアイデンティティ。 空のストリングが使用されているとき、これは認証のアイデンティティをデフォルトとします。 これはシステム管理者かプロキシサーバによって使用されて、異なったユーザアイデンティティでログインします。 この分野は、最大255の八重奏であるかもしれなく、NUL(0)八重奏で終えられます。 米国-ASCIIの印刷可能なキャラクタは好まれます。

Newman                      Standards Track                     [Page 2]

RFC 2444                   OTP SASL Mechanism               October 1998

ニューマンStandardsはOTP SASLメカニズム1998年10月にRFC2444を追跡します[2ページ]。

   UTF-8 [UTF-8] printable characters are permitted to support
   international names.  Use of character sets other than US-ASCII and
   UTF-8 is forbidden.

UTF-8[UTF-8]の印刷可能なキャラクタが国際的な名前をサポートすることが許可されています。 米国-ASCIIとUTF-8以外の文字集合の使用は禁じられます。

   (2) An authentication identity.  The identity whose pass phrase will
   be used.  This field may be up to 255 octets.  US-ASCII printable
   characters are preferred, although UTF-8 [UTF-8] printable characters
   are permitted to support international names.  Use of character sets
   other than US-ASCII and UTF-8 is forbidden.

(2) 認証のアイデンティティ。 パス句が使用されるアイデンティティ。 この分野は最大255の八重奏であるかもしれません。 UTF-8[UTF-8]の印刷可能なキャラクタが国際的な名前をサポートすることが許可されていますが、米国-ASCIIの印刷可能なキャラクタは好まれます。 米国-ASCIIとUTF-8以外の文字集合の使用は禁じられます。

   The server responds by sending a message containing the OTP challenge
   as described in OTP [OTP] and OTP extended responses [OTP-EXT].

サーバは、OTP[OTP]で説明されるようにOTP挑戦を含むメッセージとOTPに拡張応答[OTP-EXT]を送ることによって、反応します。

   If a client sees an unknown hash algorithm name it will not be able
   to process a pass phrase input by the user.  In this situation the
   client MAY prompt for the six-word format, issue the cancel sequence
   as specified by the SASL profile for the protocol in use and try a
   different SASL mechanism, or close the connection and refuse to
   authenticate.  As a result of this behavior, a server is restricted
   to one OTP hash algorithm per user.

クライアントが未知のハッシュアルゴリズム名を見ると、ユーザでパス句の入力を処理できないでしょう。 クライアントが6語形式のためにうながすかもしれないこの状況で、指定されるとしての使用中のプロトコルのためのSASLプロフィールによるキャンセル系列を発行してください、そして、異なったSASLメカニズムを試みるか、または認証する接続と廃物を終えてください。 この振舞いの結果、サーバは1ユーザあたり1つのOTPハッシュアルゴリズムに制限されます。

   On success, the client generates an extended response in the "hex",
   "word", "init-hex" or "init-word" format.  The client is not required
   to terminate the response with a space or a newline and SHOULD NOT
   include unnecessary whitespace.

成功では、クライアントは「十六進法」における拡張応答、「単語」、「イニット十六進法」または「イニット単語」形式を生成します。 クライアントはスペースかニューラインで応答を終える必要はありません、そして、SHOULD NOTは不要な空白を含んでいます。

   Servers MUST tolerate input of arbitrary length, but MAY fail the
   authentication if the length of client input exceeds reasonable size.

サーバは、任意の長さの入力を許容しなければなりませんが、クライアント入力の長さが妥当なサイズを超えているなら、認証に失敗するかもしれません。

5. Examples

5. 例

   In these example, "C:" represents lines sent from the client to the
   server and "S:" represents lines sent from the server to the client.
   The user name is "tim" and no authorization identity is provided.
   The "<NUL>" below represents an ASCII NUL octet.

これらの例で「C:」 そして、クライアントからサーバに送られた台詞を表す、「S:」 サーバからクライアントに送られた台詞を表します。 存在というユーザ名の"tim"を提供しますが、どんな承認のアイデンティティも提供しません。 以下の「<NUL>」はASCII NUL八重奏を表します。

   The following is an example of the OTP mechanism using the ACAP
   [ACAP] profile of SASL.  The pass phrase used in this example is:
             This is a test.

↓これはSASLのACAP[ACAP]プロフィールを使用するOTPメカニズムに関する例です。 この例で使用されるパス句は以下の通りです。 これはテストです。

          C: a001 AUTHENTICATE "OTP" {4}
          C: <NUL>tim
          S: + "otp-md5 499 ke1234 ext"
          C: "hex:5bf075d9959d036f"
          S: a001 OK "AUTHENTICATE completed"

C: a001 AUTHENTICATE"OTP"4C: <NUL>tim S: + 「otp-md5 499ke1234 ext」C: 「十六進法: 5bf075d9959d036f」S: a001のOKの「完成したAUTHENTICATE」

Newman                      Standards Track                     [Page 3]

RFC 2444                   OTP SASL Mechanism               October 1998

ニューマンStandardsはOTP SASLメカニズム1998年10月にRFC2444を追跡します[3ページ]。

        Here is the same example using the six-words response:

ここに、同じ例が6単語の応答を使用することであります:

          C: a001 AUTHENTICATE "OTP" {4}
          C: <NUL>tim
          S: + "otp-md5 499 ke1234 ext"
          C: "word:BOND FOGY DRAB NE RISE MART"
          S: a001 OK "AUTHENTICATE completed"

C: a001 AUTHENTICATE"OTP"4C: <NUL>tim S: + 「otp-md5 499ke1234 ext」C: 「単語: 時代遅れの人の冴えないNe上昇市場を接着してください」というS: a001のOKの「完成したAUTHENTICATE」

        Here is the same example using the OTP-SHA1 mechanism:

ここに、同じ例がOTP-SHA1メカニズムを使用することであります:

          C: a001 AUTHENTICATE "OTP" {4}
          C: <NUL>tim
          S: + "otp-sha1 499 ke1234 ext"
          C: "hex:c90fc02cc488df5e"
          S: a001 OK "AUTHENTICATE completed"

C: a001 AUTHENTICATE"OTP"4C: <NUL>tim S: + 「otp-sha1 499ke1234 ext」C: 「十六進法: c90fc02cc488df5e」S: a001のOKの「完成したAUTHENTICATE」

        Here is the same example with the init-hex extended response

ここに、イニット十六進法の拡張応答がある同じ例があります。

          C: a001 AUTHENTICATE "OTP" {4}
          C: <NUL>tim
          S: + "otp-md5 499 ke1234 ext"
          C: "init-hex:5bf075d9959d036f:md5 499 ke1235:3712dcb4aa5316c1"
          S: a001 OK "OTP sequence reset, authentication complete"

C: a001 AUTHENTICATE"OTP"4C: <NUL>tim S: + 「otp-md5 499ke1234 ext」C: 「: 5bf075d9959d036f: md5 499ke1235: 3712dcb4aa5316c1"Sにイニットで魔法をかけてください」 「認証完全な状態でリセットされたOTP系列」というa001OK

     The following is an example of the OTP mechanism using the IMAP
     [IMAP4] profile of SASL.  The pass phrase used in this example is:
          this is a test

↓これはSASLのIMAP[IMAP4]プロフィールを使用するOTPメカニズムに関する例です。 この例で使用されるパス句は以下の通りです。 これはテストです。

       C: a001 AUTHENTICATE OTP
       S: +
       C: AHRpbQ==
       S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA==
       C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE=
       S: a001 OK AUTHENTICATE completed

C: a001 AUTHENTICATE OTP S: + C: AHRpbQ== S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA=C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE= S: OK AUTHENTICATEが完成したa001

   Note that the lack of an initial client response and the base64
   encoding are characteristics of the IMAP profile of SASL.  The server
   challenge is "otp-md5 123 ke1234 ext" and the client response is
   "hex:11d4c147e227c1f1".

初期のクライアント応答の不足とbase64コード化がSASLのIMAPプロフィールの特性であることに注意してください。 サーバ挑戦は「otp-md5 123ke1234 ext」です、そして、クライアント応答は「: 11d4c147e227c1f1"に魔法をかける」ことです。

6. Security Considerations

6. セキュリティ問題

   This specification introduces no security considerations beyond those
   those described in SASL [SASL], OTP [OTP] and OTP extended responses
   [OTP-EXT].  A brief summary of these considerations follows:

この仕様はものがSASL[SASL]、OTP[OTP]で説明したものを超えてセキュリティ問題を全く紹介しません、そして、OTPは応答[OTP-EXT]を広げました。 これらの問題の簡潔な概要は従います:

   This mechanism does not provide session privacy, server
   authentication or protection from active attacks.

このメカニズムは活発な攻撃からセッションプライバシー、サーバ証明または保護を提供しません。

Newman                      Standards Track                     [Page 4]

RFC 2444                   OTP SASL Mechanism               October 1998

ニューマンStandardsはOTP SASLメカニズム1998年10月にRFC2444を追跡します[4ページ]。

   This mechanism is subject to passive dictionary attacks.  The
   severity of this attack can be reduced by choosing pass phrases well.

このメカニズムは受け身の辞書攻撃を受けることがあります。 この攻撃の厳しさは、パス句をよく選ぶことによって、減少できます。

   The server authentication database necessary for use with OTP need
   not be plaintext-equivalent.

OTPとの使用に必要なサーバ証明データベースは平文同等である必要はありません。

   Server implementations MUST protect against the race attack [OTP].

サーバ実装はレース攻撃[OTP]から守らなければなりません。

7. Multinational Considerations

7. 多国籍の問題

   As remote access is a crucial service, users are encouraged to
   restrict user names and pass phrases to the US-ASCII character set.
   However, if characters outside the US-ASCII chracter set are used in
   user names and pass phrases, then they are interpreted according to
   UTF-8 [UTF-8].

遠隔アクセスが重要なサービスであるので、ユーザは、米国-ASCII文字の組にユーザ名を制限して、句を通過するよう奨励されます。 しかしながら、米国-ASCII chracterセットの外におけるキャラクタがユーザ名に使用されて、句を通過するなら、UTF-8[UTF-8]によると、それらは解釈されます。

   Server support for alternate dictionaries is strongly RECOMMENDED to
   permit use of the six-word format with non-English words.

代替の辞書のサーバサポートは強くそうです。非英単語との6語形式の使用を可能にするRECOMMENDED。

8. IANA Considerations

8. IANA問題

   Here is the registration template for the OTP SASL mechanism:

ここに、OTP SASLメカニズムのための登録テンプレートがあります:

   SASL mechanism name: OTP
   Security Considerations: See section 6 of this memo
   Published specification: this memo
   Person & email address to contact for futher information:
     see author's address section below
   Intended usage: COMMON
   Author/Change controller: see author's address section below

SASLメカニズム名: OTPセキュリティ問題: このメモPublished仕様のセクション6を見てください: futher情報のために連絡するこのメモPersonとEメールアドレス: Intended用法の下で作者のアドレス部を見てください: COMMON Author/変化コントローラ: 下の作者のアドレス部を見てください。

   This memo also amends the SKEY SASL mechanism registration [SASL] by
   changing its intended usage to OBSOLETE.

また、このメモは、意図している用法をOBSOLETEに変えることによって、SKEY SASLメカニズム登録[SASL]を修正します。

9. References

9. 参照

   [ACAP]     Newman, C. and J. Myers, "ACAP -- Application
              Configuration Access Protocol", RFC 2244, November 1997.

[ACAP] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日

   [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
              AUTHorize Extension for Simple Challenge/Response", RFC
              2195, September 1997.

[一夜漬け-MD5] KlensinとJ.とCatoeとR.とP.Krumviede、「/が飛び出させるIMAPは簡単な挑戦/応答のための拡大を認可する」RFC2195、1997年9月。

   [IMAP4]    Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 2060, December 1996.

[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Newman                      Standards Track                     [Page 5]

RFC 2444                   OTP SASL Mechanism               October 1998

ニューマンStandardsはOTP SASLメカニズム1998年10月にRFC2444を追跡します[5ページ]。

   [LDAPv3]   Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
              Access Protocol (v3)", RFC 2251, December 1997.

[LDAPv3]ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。

   [MD5]      Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
              April 1992.

[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。

   [OTP]      Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
              Password System", RFC 2289, February 1998.

[OTP] ハラーとN.とメスとC.とNesserとP.とM.わら、「A One-時間パスワードシステム」、RFC2289、1998年2月。

   [OTP-EXT]  Metz, C., "OTP Extended Responses", RFC 2243, November
              1997.

[OTP-EXT] メス、C.、「OTPは応答を広げた」RFC2243、1997年11月。

   [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
              December 1994.

[POP-AUTH] マイアーズ、J.、「POP3 AUTHenticationコマンド」、RFC1734、1994年12月。

   [SASL]     Myers, J., "Simple Authentication and Security Layer
              (SASL)", RFC 2222, October 1997.

[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。

   [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.

[UTF-8]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。

10. Author's Address

10. 作者のアドレス

   Chris Newman
   Innosoft International, Inc.
   1050 Lakes Drive
   West Covina, CA 91790 USA

クリスニューマンInnosoftの国際Inc.1050Lakesはウエストコビナ、カリフォルニア91790米国を運転します。

   EMail: chris.newman@innosoft.com

メール: chris.newman@innosoft.com

Newman                      Standards Track                     [Page 6]

RFC 2444                   OTP SASL Mechanism               October 1998

ニューマンStandardsはOTP SASLメカニズム1998年10月にRFC2444を追跡します[6ページ]。

11.  Full Copyright Statement

11. 完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Newman                      Standards Track                     [Page 7]

ニューマン標準化過程[7ページ]