Network Working Group K. Zeilenga
Request for Comments: 3112 OpenLDAP Foundation
Category: Informational May 2001
LDAP Authentication Password Schema
Status of this 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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This attribute type holds values derived from the user's password(s) (commonly using cryptographic strength one-way hash). authPassword is intended to used instead of userPassword.
この文書では、authPasswordと属性タイプを含むLDAP（ライトウェイトディレクトリアクセスプロトコル）ディレクトリ内のユーザー/パスワード認証のサポートにスキーマを記述する。この属性のタイプは、（一般的に、暗号強度一方向ハッシュを使用して）ユーザのパスワード（複数可）から得られた値を保持しています。 authPasswordとは、userPassword属性の代わりに使用することを意図しています。
The userPassword attribute type [RFC2256] is intended to be used to support the LDAP [RFC2251] "simple" bind operation. However, values of userPassword must be clear text passwords. It is often desirable to store values derived from the user's password(s) instead of actual passwords.
userPassword属性は、[RFC2256]を入力し、属性LDAP [RFC2251]「シンプル」バインド操作をサポートするために使用されることを意図しています。しかし、userPassword属性の値は、クリアテキストのパスワードでなければなりません。代わりに、実際のパスワードのユーザのパスワード（複数可）に由来する値を格納することが望ましい場合が多いです。
The authPassword attribute type is intended to be used to store information used to implement simple password based authentication. The attribute type may be used by LDAP servers to implement the LDAP Bind operation's "simple" authentication method.
authPasswordと属性タイプは、単純なパスワードベースの認証を実装するために使用される情報を格納するために使用されることを意図しています。属性タイプは、LDAPバインド操作の認証方法に「simple」を実装するためにLDAPサーバーで使用することができます。
The attribute type supports multiple storage schemes. A matching rule is provided for use with extensible search filters to allow clients to assert that a clear text password "matches" one of the attribute's values.
属性タイプは、複数のストレージ・スキームをサポートしています。マッチングルールは、クライアントがクリアテキストのパスワード「マッチ」属性の値のいずれかということを主張できるようにするために拡張可能な検索フィルタを使用するために提供されています。
Storage schemes often use cryptographic strength one-way hashing. Though the use of one-way hashing reduces the potential that exposed values will allow unauthorized access to the Directory (unless the hash algorithm/implementation is flawed), the hashing of passwords is intended to be as an additional layer of protection. It is RECOMMENDED that hashed values be protected as if they were clear text passwords.
ストレージスキームは、多くの場合、暗号強度一方向ハッシュを使用します。一方向ハッシュの使用は（ハッシュアルゴリズム/実装は欠陥がある場合を除く）の値は、ディレクトリへの不正アクセスを許可する暴露の可能性を低減しますが、パスワードのハッシュは、追加の保護層としてあることを意図しています。彼らはクリアテキストのパスワードであるかのようにハッシュ値を保護することをお勧めします。
This attribute may be used in conjunction with server side password generation mechanisms (such as the LDAP Password Modify [RFC3062] extended operation).
この属性は、（例えば、LDAPパスワード変更[RFC3062]の拡張操作など）をサーバ側のパスワード生成機構と組み合わせて使用することができます。
Access to this attribute may governed by administrative controls such as those which implement password change policies.
この属性にアクセスするには、このようなパスワード変更ポリシーを実装するものとして管理統制によって管理可能。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、および本文書にように解釈されるべきであり、 "MAY" RFC 2119 [RFC2119]で説明。
The following schema definitions are described in terms of LDAPv3 Attribute Syntax Definitions [RFC2252] with specific syntax detailed using Augmented BNF [RFC2234].
以下のスキーマ定義は、拡張BNF [RFC2234]を用いて詳述する特定の構文でのLDAPv3属性の構文定義[RFC2252]の観点から説明されています。
( 1.3.6.1.4.1.4203.1.1.2
DESC 'authentication password syntax' )
Values of this syntax are encoded according to:
この構文の値は、に従って符号化されています。
authPasswordValue = w scheme s authInfo s authValue w scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F ; 0-9, A-Z, "-", ".", "/", or "_" authInfo = schemeSpecificValue authValue = schemeSpecificValue schemeSpecificValue = *( %x21-23 / %x25-7E ) ; printable ASCII less "$" and " " s = w SEP w w = *SP SEP = %x24 ; "$" SP = %x20 ; " " (space)
authPasswordValue =スキーム=％x30-39 /％x41-5A /％x2D-2F /％のx5F WスキームS AUTHINFO S authValue W。 0-9、-Z、 " - "、 "/"、または "_" AUTHINFO = schemeSpecificValue authValue = schemeSpecificValue schemeSpecificValue = *（％x21-23 /％x25-7E） "";印刷可能なASCII以下 "$" や "" S = 9月のw * SP 9月=％のX24 = wで。 "$" SP =％X20; " " （スペース）
where scheme describes the mechanism and authInfo and authValue are a scheme specific. The authInfo field is often a base64 encoded salt. The authValue field is often a base64 encoded value derived from a user's password(s). Values of this attribute are case sensitive.
どこスキームは、メカニズムを説明し、AUTHINFOとauthValueは、特定の方式です。 AUTHINFOフィールドは、多くの場合、base64でエンコードされた塩です。 authValueフィールドには、多くの場合、ユーザのパスワード（複数可）に由来するbase64でエンコードされた値です。この属性の値は、大文字と小文字が区別されます。
Transfer of values of this syntax is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the values to unauthorized parties.
基礎となるトランスポートサービスは、機密性を保証することはできませんし、権限のない者への値の開示につながることができる場合は、この構文の値の転送は強くお勧めします。
This document describes a number of schemes, as well as requirements for the scheme naming, in section 3.
この文書は、セクション3で、スキームの命名のためのスキームの数、および要件について説明します。
( 1.3.6.1.4.1.4203.1.2.2
NAME 'authPasswordExactMatch'
DESC 'authentication password exact matching rule'
SYNTAX 1.3.6.1.4.1.4203.1.1.2 )
This matching rule allows a client to assert that an asserted authPasswordSyntax value matches authPasswordSyntax values. It is meant to be used as the EQUALITY matching rule of attributes whose SYNTAX is authPasswordSyntax.
このマッチングルールは、クライアントがアサートauthPasswordSyntax値がauthPasswordSyntax値と一致していることを主張することができます。 SYNTAX authPasswordSyntaxある属性が等しいマッチングルールとして使用されることを意味します。
The assertion is "TRUE" if there is an attribute value which has the same scheme, authInfo, and authValue components as the asserted value; "FALSE" if no attribute value has the same components as the asserted value; and "Undefined" otherwise.
アサートされた値と同じ方式で、AUTHINFO、及びauthValue成分を有する属性値がある場合に、アサーションは、「TRUE」です。無属性値がアサート値と同じ構成要素を持っていない場合は、「FALSE」。そうでない場合と「未定義」。
( 1.3.6.1.4.1.4203.1.2.3
NAME 'authPasswordMatch'
DESC 'authentication password matching rule'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
This matching rule allows a client to assert that a password matches values of authPasswordSyntax using an extensibleMatch filter component. Each value is matched per its scheme. The assertion is "TRUE" if one or more attribute values matches the asserted value, "FALSE" if all values do not matches, and "Undefined" otherwise.
このマッチングルールは、クライアントがパスワードがextensibleMatchフィルタ部品を使用してauthPasswordSyntaxの値と一致していることを主張することができます。各値は、そのスキームごとに一致しています。アサーションは、1つ以上の属性値がアサートされた値と一致した場合、すべての値がないマッチを行う場合は、「FALSE」「TRUE」であり、そうでない場合は「未定義」。
Servers which support use of this matching rule SHOULD publish appropriate matchingRuleUse values per [RFC2252], 4.4.
このマッチング規則の使用をサポートするサーバーは4.4、[RFC2252]あたりの適切なれるmatchingRuleUse値を公開するべきです。
Transfer of authPasswordMatch assertion values is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the values to unauthorized parties.
基礎となるトランスポートサービスは、機密性を保証することはできませんし、権限のない者への値の開示をもたらすことができる場所authPasswordMatchアサーション値の転送を強くお勧めします。
( 1.3.6.1.4.1.4203.1.3.3
NAME 'supportedAuthPasswordSchemes'
DESC 'supported password storage schemes'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
USAGE dSAOperation )
The values of this attribute are names of supported authentication password schemes which the server supports. The syntax of a scheme name is described in section 2.1. This attribute may only be present in the root DSE. If the server does not support any password schemes, this attribute will not be present.
この属性の値は、サーバーがサポート認証パスワードスキームの名前です。スキーム名の構文は、セクション2.1に記載されています。この属性は、ルートDSE中に存在することができます。サーバーは、任意のパスワードスキームをサポートしていない場合、この属性は存在しません。
( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword'
DESC 'password authentication information'
EQUALITY 1.3.6.1.4.1.4203.1.2.2
SYNTAX 1.3.6.1.4.1.4203.1.1.2 )
The values of this attribute are representative of the user's password(s) and conform to the authPasswordSyntax described in 2.1. The values of this attribute may be used for authentication purposes.
この属性の値は、ユーザのパスワード（複数可）の代表であり、2.1で説明したauthPasswordSyntaxに準拠しています。この属性の値は、認証目的のために使用することができます。
Transfer of authPassword values is strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the values to unauthorized parties.
基礎となるトランスポートサービスは、機密性を保証することはできませんし、権限のない者への値の開示をもたらすことができる場所をauthPassword値の転送を強くお勧めします。
( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject'
DESC 'authentication password mix in class'
MAY 'authPassword'
AUXILIARY )
Entries of this object class may contain authPassword attribute types.
このオブジェクトクラスのエントリはをauthPassword属性の種類が含まれていてもよいです。
This section describes the "MD5" and "SHA1" schemes. Other schemes may be defined by other documents. Schemes which are not described in an RFC SHOULD be named with a leading "X-" to indicate they are a private or implementation specific scheme, or may be named using the dotted-decimal representation [RFC2252] of an OID assigned to the scheme.
このセクションでは、「MD5」と「SHA1」のスキームを説明します。他の方式は、他の文書によって定義することができます。 RFCに記載されていないスキームは、それらがプライベートまたは実装固有の方式であることを示すために先頭の「X-」と命名されるべきであり、又はスキームに割り当てられたOIDのドット付き10進表現[RFC2252]を使用して名前を付けることができます。
The MD5 [RFC1321] scheme name is "MD5".
MD5 [RFC1321]スキーム名は "MD5" です。
The authValue is the base64 encoding of an MD5 digest of the concatenation the user password and salt. The base64 encoding of the salt is provided in the authInfo field. The salt MUST be at least 64 bits long. Implementations of this scheme MUST support salts up to 128 bits in length.
authValueは連結ユーザパスワード及び塩のMD5ダイジェストのbase64エンコーディングです。塩のBase64エンコードは、AUTHINFOフィールドに設けられています。塩は、少なくとも64ビットの長さでなければなりません。このスキームの実装では、長さが128ビットまでの塩をサポートしなければなりません。
Example: Given a user "joe" who's password is "mary" and a salt of "salt", the authInfo field would be the base64 encoding of "salt" and the authValue field would be the base64 encoding of the MD5 digest of "marysalt".
例：パスワードのユーザー「ジョー」が「メアリー」と「塩」の塩で考えると、AUTHINFOフィールドは「塩」のbase64エンコードとauthValueフィールドがmarysalt」のMD5ダイジェストのbase64エンコードになりますでしょう」。
A match against an asserted password and an attribute value of this scheme SHALL be true if and only if the MD5 digest of concatenation of the asserted value and the salt is equal to the MD5 digest contained in AuthValue. The match SHALL be undefined if the server is unable to complete the equality test for any reason. Otherwise the match SHALL be false.
アサートされた値の連結のMD5ダイジェストと塩AuthValueに含まれるMD5ダイジェストに等しい場合にのみ場合にアサートされたパスワードとこの方式の属性値に対する一致が真でなければなりません。サーバが何らかの理由で平等のテストを完了することができない場合、一致は未定義されなければなりません。そうでなければマッチは偽されなければなりません。
Values of this scheme SHOULD only be used to implement simple user/password authentication.
この方式の値は、単純なユーザー/パスワード認証を実装するために使用されるべきです。
The SHA1 [SHA1] scheme name is "SHA1".
SHA1 [SHA1]スキーム名は "SHA1" です。
The authValue is the base64 encoding of a SHA1 digest of the concatenation the user password and the salt. The base64 encoding of the salt is provided in the authInfo field. The salt MUST be at least 64 bits long. Implementations of this scheme MUST support salts up to 128 bits in length.
authValueは連結ユーザパスワード及び塩のSHA1ダイジェストのbase64エンコーディングです。塩のBase64エンコードは、AUTHINFOフィールドに設けられています。塩は、少なくとも64ビットの長さでなければなりません。このスキームの実装では、長さが128ビットまでの塩をサポートしなければなりません。
Example: Given a user "joe" who's password is "mary" and a salt of "salt", the authInfo field would be the base64 encoding of "salt" and the authValue field would be the base64 encoding of the SHA1 digest of "marysalt".
例：パスワードのユーザー「ジョー」が「メアリー」と「塩」の塩で考えると、AUTHINFOフィールドは「塩」のbase64エンコードとauthValueフィールドがmarysalt」のSHA1ダイジェストのbase64エンコードになりますでしょう」。
A match against an asserted password and an attribute value of this scheme SHALL be true if and only if the SHA1 digest of concatenation of the asserted value and the salt is equal to the SHA1 digest contained in AuthValue. The match SHALL be undefined if the server is unable to complete the equality test for any reason. Otherwise the match SHALL be false.
アサートされた値の連結のSHA1ダイジェストと塩AuthValueに含まSHA1ダイジェストに等しい場合にのみ場合にアサートされたパスワードとこの方式の属性値に対する一致が真でなければなりません。サーバが何らかの理由で平等のテストを完了することができない場合、一致は未定義されなければなりません。そうでなければマッチは偽されなければなりません。
Values of this scheme SHOULD only be used to implement simple user/password authentication.
この方式の値は、単純なユーザー/パスワード認証を実装するために使用されるべきです。
For all implementations of this specification:
この仕様のすべての実装のために：
Servers MAY restrict which schemes are used in conjunction with a particular authentication process but SHOULD use all values of selected schemes. If the asserted password matches any of the stored values, the asserted password SHOULD be considered valid. Servers MAY use other authentication storage mechanisms, such as userPassword or an external password store, in conjunction with authPassword to support the authentication process.
サーバは、特定の認証プロセスに関連して使用されるが、選択されたスキームのすべての値を使用すべきスキームを制限することができます。アサートパスワードが格納された値のいずれかと一致する場合、アサートパスワードが有効と見なされるべきです。サーバーは認証プロセスをサポートするためにをauthPasswordと併せて、このようなのuserPasswordまたは外部パスワード・ストアのような他の認証用記憶メカニズムを使用することができます。
Servers that support simple bind MUST support the SHA1 scheme and SHOULD support the MD5 scheme.
単純なバインドをサポートするサーバーは、SHA1のスキームをサポートしなければならないし、MD5スキームをサポートする必要があります。
Servers SHOULD NOT publish values of authPassword nor allow operations which expose authPassword values or AuthPasswordMatch assertions to unless confidentiality protection is in place.
サーバーはauthPasswordとの値を公開したり機密保護が整備されている場合を除きまでをauthPassword値またはAuthPasswordMatchアサーションを公開する操作を許してはなりません。
Clients SHOULD NOT initiate operations which provide or request values of authPassword or make authPasswordMatch assertions unless confidentiality protection is in place.
クライアントが提供操作またはをauthPasswordの要求値を開始したり、機密保護が整備されている場合を除きauthPasswordMatchアサーションを行うべきではありません。
Clients SHOULD NOT assume that a successful AuthPasswordMatch, whether by compare or search, is sufficient to gain directory access. The bind operation MUST be used to authenticate to the directory.
クライアントは、比較または検索によってか、その成功AuthPasswordMatchを仮定するべきではありません、ディレクトリのアクセス権を取得するのに十分です。バインド操作は、ディレクトリへの認証に使用しなければなりません。
This document describes how authentication information may be stored in a directory. Authentication information MUST be adequately protected as unintended disclosure will allow attackers to gain immediate access to the directory as described by [RFC2829].
この文書では、認証情報がディレクトリに格納することができる方法を説明します。認証情報が適切に[RFC2829]で説明したように、攻撃者がディレクトリへの即時アクセスを得ることを可能にする、意図しない開示として保護されなければなりません。
As flaws may be discovered in the hashing algorithm or with a particular implementation of the algorithm or values could be subject to various attacks if exposed, values of AuthPassword SHOULD be protected as if they were clear text passwords. When values are transferred, privacy protections, such as IPSEC or TLS, SHOULD be in place.
欠陥がハッシュアルゴリズムにまたは露出した場合、アルゴリズムまたは値の特定の実装は様々な攻撃を受ける可能性がで発見されるように、彼らはクリアテキストのパスワードであるかのように、authPasswordとの値が保護されなければなりません。値が転送されると、このようIPSECやTLSなどのプライバシー保護は、場所にする必要があります。
Clients SHOULD use strong authentication mechanisms [RFC2829].
クライアントは、強力な認証メカニズム[RFC2829]を使用すべきです。
AuthPasswordMatch matching rule allows applications to test the validity of a user password and, hence, may be used to mount an attack. Servers SHOULD take appropriate measures to protect the directory from such attacks.
AuthPasswordMatchマッチングルールは、アプリケーションは、ユーザパスワードの有効性をテストすることを可能にし、したがって、攻撃をするために使用することができます。サーバーは、このような攻撃からディレクトリを保護するために適切な措置をとるべきです。
Some password schemes may require CPU intensive operations. Servers SHOULD take appropriate measures to protect against Denial of Service attacks.
いくつかのパスワード方式は、CPU集中型の操作が必要な場合があります。サーバーは、サービス拒否攻撃から保護するための適切な措置をとるべきです。
AuthPassword does not restrict an authentication identity to a single password. An attacker who gains write access to this attribute may store additional values without disabling the user's true password(s). Use of policy aware clients and servers is RECOMMENDED.
authPasswordとは、単一のパスワードに認証IDを制限するものではありません。この属性への書き込みアクセスを攻撃者は、ユーザーの本当のパスワード（複数可）を無効にせずに追加の値を格納することができます。政策対応クライアントとサーバの使用を推奨します。
The level of protection offered against various attacks differ from scheme to scheme. It is RECOMMENDED that servers support scheme selection as a configuration item. This allows for a scheme to be easily disabled if a significant security flaw is discovered.
様々な攻撃から提供される保護のレベルは、スキームのスキームとは異なります。サーバーが構成アイテムとしてスキームの選択をサポートすることが推奨されます。これは重大なセキュリティ上の欠陥が発見された場合に簡単に無効にするためのスキームが可能になります。
This document borrows from a number of IETF documents and is based upon input from the IETF LDAPext working group.
この文書は、IETFドキュメントの数から借用し、IETF LDAPEXTワーキンググループからの入力に基づいています。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月
[RFC2219] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2219]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2234] Crocker, D., Editor, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、D.、エディタ、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[RFC2252]ワール、M.、Coulbeck、A.、ハウズ、T.、およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）：属性の構文定義"、RFC 2252、1997年12月。
[RFC2256] Wahl, A., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
[RFC2256]ワール、A.、RFC 2256、1997年12月 "のLDAPv3で使用するためのX.500（96）ユーザスキーマの概要"。
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998.
[RFC2307]ハワード、L.、1998年3月、RFC 2307 "ネットワーク情報サービスとしてLDAPを使用するためのアプローチ"。
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, June 2000.
[RFC2829]ワール、M.、Alvestrand、H.、ホッジス、J.とR.モルガン、 "LDAPのための認証方法"、RFC 2829、2000年6月。
[RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", RFC 3062, February 2001.
[RFC3062] Zeilenga、K.、RFC 3062、2001年2月 "LDAPパスワード変更拡張操作を"。
[SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[SHA1] NIST、FIPS PUB 180-1の：セキュアハッシュ標準、1995年4月。
Kurt D. Zeilenga OpenLDAP Foundation
クルトD. ZeilengaのOpenLDAP財団
EMail: Kurt@OpenLDAP.org
メールアドレス：Kurt@OpenLDAP.org
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。