Network Working Group K. Zeilenga, Ed.
Request for Comments: 4616 OpenLDAP Foundation
Updates: 2595 August 2006
Category: Standards Track
The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
PLAIN簡易認証セキュリティー層（SASL）メカニズム
Status of This 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command.
この文書では、単純なクリアテキストのユーザー/パスワード簡易認証セキュリティー層PLAINメカニズムと呼ばれる（SASL）のメカニズムを定義します。 PLAIN機構は、単純なパスワード認証コマンドが不足しているプロトコルでは、下位層によって提供されたデータの機密性サービスと組み合わせて、使用することを意図しています。
Clear-text, multiple-use passwords are simple, interoperate with almost all existing operating system authentication databases, and are useful for a smooth transition to a more secure password-based authentication mechanism. The drawback is that they are unacceptable for use over network connections where data confidentiality is not ensured.
クリアテキスト、マルチユースのパスワードは、ほぼすべての既存のオペレーティングシステムの認証データベースとの相互運用性、シンプルであり、より安全なパスワードベースの認証メカニズムへの円滑な移行のために便利です。欠点は、データの機密性が確保されていないネットワーク接続を介して使用するために受け入れられないということです。
This document defines the PLAIN Simple Authentication and Security Layer ([SASL]) mechanism for use in protocols with no clear-text login command (e.g., [ACAP] or [SMTP-AUTH]). This document updates RFC 2595, replacing Section 6. Changes since RFC 2595 are detailed in Appendix A.
この文書は、PLAIN簡易認証およびセキュリティ層なしクリアテキストloginコマンドでプロトコルにおける使用のための（[SASL]）メカニズムを定義する（例えば、[ACAP]または[SMTP-AUTH]）。このドキュメントの更新RFC 2595、RFC 2595には、付録Aに詳述されているので、6章の変更点を交換します
The name associated with this mechanism is "PLAIN".
このメカニズムに関連付けられている名前は、「PLAIN」です。
The PLAIN SASL mechanism does not provide a security layer.
PLAIN SASLメカニズムはセキュリティレイヤを提供していません。
The PLAIN mechanism should not be used without adequate data security protection as this mechanism affords no integrity or confidentiality protections itself. The mechanism is intended to be used with data security protections provided by application-layer protocol, generally through its use of Transport Layer Security ([TLS]) services.
このメカニズムは全く整合性や機密性の保護自体を与えないようPLAINメカニズムは、十分なデータのセキュリティ保護なしで使用すべきではありません。機構は、一般に、トランスポート層セキュリティ（[TLS]）サービスの使用を介して、アプリケーション層プロトコルによって提供されるデータのセキュリティ保護と一緒に使用されることが意図されます。
By default, implementations SHOULD advertise and make use of the PLAIN mechanism only when adequate data security services are in place. Specifications for IETF protocols that indicate that this mechanism is an applicable authentication mechanism MUST mandate that implementations support an strong data security service, such as TLS.
デフォルトでは、実装では、十分なデータのセキュリティサービスが所定の位置にあるときにのみ広告を掲載し、PLAINメカニズムを利用するべきです。このメカニズムは、適用認証機構であることを示しているIETFプロトコルの仕様は実装がTLSなどの強力なデータ・セキュリティ・サービスをサポートすることを強制しなければなりません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Keywords].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]で説明されるように解釈されます。
The mechanism consists of a single message, a string of [UTF-8] encoded [Unicode] characters, from the client to the server. The client presents the authorization identity (identity to act as), followed by a NUL (U+0000) character, followed by the authentication identity (identity whose password will be used), followed by a NUL (U+0000) character, followed by the clear-text password. As with other SASL mechanisms, the client does not provide an authorization identity when it wishes the server to derive an identity from the credentials and use that as the authorization identity.
機構は、クライアントからサーバに、[UNICODE]の文字が符号化された単一のメッセージ、[UTF-8]の列で構成されています。クライアントが続くNUL（U + 0000）文字、続い認証アイデンティティ（パスワードが使用されますアイデンティティ）に続いてNUL（U + 0000）文字、続く、認可ID（として行動するアイデンティティ）を提示しますクリアテキストのパスワードによる。それは資格情報から身元を導出し、認可IDとしてそれを使用するようにサーバーを希望する場合、他のSASLメカニズムと同様に、クライアントは、認証IDを提供していません。
The formal grammar for the client message using Augmented BNF [ABNF] follows.
増補BNFを使用して、クライアントメッセージの形式文法[ABNF]は、以下。
message = [authzid] UTF8NUL authcid UTF8NUL passwd authcid = 1*SAFE ; MUST accept up to 255 octets authzid = 1*SAFE ; MUST accept up to 255 octets passwd = 1*SAFE ; MUST accept up to 255 octets UTF8NUL = %x00 ; UTF-8 encoded NUL character
メッセージ= [authzidは】UTF8NUL authcid UTF8NULのpasswd authcid = 1 * SAFE。 255オクテットまで受け入れなければならないauthzidは= 1 * SAFE。 255オクテットのpasswd = 1 *のSAFEまで受け入れなければなりません。 255オクテットUTF8NUL =％X00までを受け入れなければなりません。 UTF-8でエンコードされたNUL文字
SAFE = UTF1 / UTF2 / UTF3 / UTF4 ;; any UTF-8 encoded Unicode character except NUL
SAFE = UTF1 / UTF2 / UTF3 / UTF4 ;; NUL以外の任意のUTF-8でエンコードされたUnicode文字
UTF1 = %x01-7F ;; except NUL UTF2 = %xC2-DF UTF0 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / %xF4 %x80-8F 2(UTF0) UTF0 = %x80-BF
UTF1 =％x01-7F ;; NUL UTF2 =％XC2-DF UTF0 UTF3 =％xE0％XA0-BFのUTF0 /％XE1-EC 2（UTF0）/％XED％x80-9F UTF0 /％XEE-EF 2（UTF0）UTF4 =％XF0％X90以外-BF 2（UTF0）/％XF1-F3 3（UTF0）/％XF4％x80-8F 2（UTF0）UTF0 =％X80-BF
The authorization identity (authzid), authentication identity (authcid), password (passwd), and NUL character deliminators SHALL be transferred as [UTF-8] encoded strings of [Unicode] characters. As the NUL (U+0000) character is used as a deliminator, the NUL (U+0000) character MUST NOT appear in authzid, authcid, or passwd productions.
認可ID（authzidは）、認証アイデンティティ（authcid）、パスワード（passwdファイル）、およびNUL文字deliminatorsは[UNICODE]文字の[UTF-8]エンコードされた文字列として転送するものとします。 NUL（U + 0000）文字をdeliminatorとして使用されるように、NUL（U + 0000）文字はauthzidは、authcid、またはpasswdの制作に現れてはいけません。
The form of the authzid production is specific to the application-level protocol's SASL profile [SASL]. The authcid and passwd productions are form-free. Use of non-visible characters or characters that a user may be unable to enter on some keyboards is discouraged.
authzidは生産の形態では、アプリケーションレベルのプロトコルのSASLプロファイル[SASL]に特異的です。 authcidとpasswd制作は、フォームフリーです。ユーザーは一部のキーボードで入力することができない可能性が不可視文字または文字の使用は推奨されません。
Servers MUST be capable of accepting authzid, authcid, and passwd productions up to and including 255 octets. It is noted that the UTF-8 encoding of a Unicode character may be as long as 4 octets.
サーバーは、最大authzidは、authcid、およびpasswdの制作を受け入れ、255個のオクテットを含むことができなければなりません。 Unicode文字のUTF-8エンコーディングは4つのオクテット限りであってもよいことに留意されます。
Upon receipt of the message, the server will verify the presented (in the message) authentication identity (authcid) and password (passwd) with the system authentication database, and it will verify that the authentication credentials permit the client to act as the (presented or derived) authorization identity (authzid). If both steps succeed, the user is authenticated.
メッセージを受信すると、サーバーはシステムの認証データベースとの提示（メッセージで）認証アイデンティティ（authcid）とパスワード（passwdの）を検証し、それが認証証明書は、クライアントが（提示として動作するように許可していることを確認しますまたは派生）認可ID（authzidは）。両方のステップが成功した場合、ユーザーが認証されます。
The presented authentication identity and password strings, as well as the database authentication identity and password strings, are to be prepared before being used in the verification process. The [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED preparation algorithm. The SASLprep preparation algorithm is recommended to improve the likelihood that comparisons behave in an expected manner. The SASLprep preparation algorithm is not mandatory so as to allow the server to employ other preparation algorithms (including none) when appropriate. For instance, use of a different preparation algorithm may be necessary for the server to interoperate with an external system.
提示した認証IDとパスワードの文字列だけでなく、データベース認証用のIDとパスワードの文字列は、検証プロセスで使用する前に準備することになっています。 【STRINGPREP]アルゴリズムのSASLPrep]プロフィールが推奨準備アルゴリズムです。 SASLprep準備アルゴリズムは、比較が期待されるように動作可能性を改善することをお勧めします。適切な場合、サーバは、（いずれも含まない）他の準備アルゴリズムを使用することを可能にするようにSASLprep準備アルゴリズムは必須ではありません。サーバは、外部のシステムと相互運用するために、例えば、異なる製造アルゴリズムの使用が必要であってもよいです。
When preparing the presented strings using [SASLPrep], the presented strings are to be treated as "query" strings (Section 7 of [StringPrep]) and hence unassigned code points are allowed to appear in their prepared output. When preparing the database strings using [SASLPrep], the database strings are to be treated as "stored" strings (Section 7 of [StringPrep]) and hence unassigned code points are prohibited from appearing in their prepared output.
[SASLPrep]を使用して提示ストリングを調製する場合、提示された文字列は、「クエリ」文字列（[STRINGPREP]のセクション7）として処理すべき、従って割り当てられていないコードポイントは、その準備された出力に表示させています。 [SASLPrep]を使用してデータベースの文字列を準備する際、データベースの文字列は、「保存された」文字列（[STRINGPREP]のセクション7）として処理すべき、従って割り当てられていないコードポイントは、その準備された出力に現れるから禁止されています。
Regardless of the preparation algorithm used, if the output of a non-invertible function (e.g., hash) of the expected string is stored, the string MUST be prepared before input to that function.
かかわらず、使用準備アルゴリズムの期待される文字列の非可逆関数（例えば、ハッシュ）の出力が格納されている場合、文字列はその関数への入力の前に準備しなければなりません。
Regardless of the preparation algorithm used, if preparation fails or results in an empty string, verification SHALL fail.
かかわらず、準備が失敗した場合や、空の文字列での結果ならば、使用準備アルゴリズムの検証が失敗しないものとします。
When no authorization identity is provided, the server derives an authorization identity from the prepared representation of the provided authentication identity string. This ensures that the derivation of different representations of the authentication identity produces the same authorization identity.
何の認可IDが提供されない場合は、サーバが提供する認証アイデンティティ文字列の準備表現から認可IDを導出します。これは、認証アイデンティティの異なる表現の導出は、同じ認可IDを生成することを保証します。
The server MAY use the credentials to initialize any new authentication database, such as one suitable for [CRAM-MD5] or [DIGEST-MD5].
サーバーは、[CRAM-MD5]または[DIGEST-MD5]に適したものとして、新しい認証データベースを初期化するための資格情報を使用するかもしれません。
This section provides pseudo-code illustrating the verification process (using hashed passwords and the SASLprep preparation function) discussed above. This section is not definitive.
このセクションでは、上述の（ハッシュされたパスワードとSASLprep作成機能を使用して）検証処理を説明する擬似コードを提供します。このセクションでは、決定的ではありません。
boolean Verify(string authzid, string authcid, string passwd) { string pAuthcid = SASLprep(authcid, true); # prepare authcid string pPasswd = SASLprep(passwd, true); # prepare passwd if (pAuthcid == NULL || pPasswd == NULL) { return false; # preparation failed } if (pAuthcid == "" || pPasswd == "") { return false; # empty prepared string } storedHash = FetchPasswordHash(pAuthcid); if (storedHash == NULL || storedHash == "") { return false; # error or unknown authcid }
確認ブール（文字列authzidは、文字列authcid、文字列のpasswd）{ストリングpAuthcid = SASLprep（authcid、TRUE）。 ＃authcidストリングpPasswd = SASLprep（passwdを、true）を準備。 {falseを返す（pAuthcid == NULL || pPasswd == NULL）場合＃passwdの調製。 ＃準備}が失敗した場合（pAuthcid == "" || pPasswd == ""）{falseを返します。 ＃空の調製列} storedHash = FetchPasswordHash（pAuthcid）。 IF（storedHash == NULL || storedHash == ""）{falseを返します。 ＃エラーまたは未知のauthcid}
if (!Compare(storedHash, Hash(pPasswd))) { return false; # incorrect password }
もし{falseを返します（（storedHash、ハッシュ（pPasswd））の比較！）。 ＃不正なパスワード}
if (authzid == NULL ) { authzid = DeriveAuthzid(pAuthcid); if (authzid == NULL || authzid == "") { return false; # could not derive authzid } }
IF（authzidは== NULL）{authzidは= DeriveAuthzid（pAuthcid）。 IF（authzidは== NULL || authzidは== ""）{falseを返します。 ＃}}はauthzidはを導き出すことができませんでした
if (!Authorize(pAuthcid, authzid)) { return false; # not authorized }
（！承認（pAuthcid、authzidは））{場合はfalseを返します。 ＃ 許可されていません }
return true; }
trueを返します。 }
The second parameter of the SASLprep function, when true, indicates that unassigned code points are allowed in the input. When the SASLprep function is called to prepare the password prior to computing the stored hash, the second parameter would be false.
SASLprep関数の2番目のパラメータは、trueの場合、割り当てられていないコードポイントが入力で許可されていることを示しています。 SASLprep関数が格納されたハッシュを計算する前にパスワードを調製するために呼び出されたときに、2番目のパラメータは偽であろう。
The second parameter provided to the Authorize function is not prepared by this code. The application-level SASL profile should be consulted to determine what, if any, preparation is necessary.
承認機能に設けられた第二のパラメータは、このコードによって調製されていません。アプリケーションレベルのSASLプロファイルがあれば、準備が必要なもの、を決定するために相談する必要があります。
Note that the DeriveAuthzid and Authorize functions (whether implemented as one function or two, whether designed in a manner in which these functions or whether the mechanism implementation can be reused elsewhere) require knowledge and understanding of mechanism and the application-level protocol specification and/or implementation details to implement.
なお、知識及び機構の理解とアプリケーションレベルのプロトコル仕様とを必要とする（これらの機能又は機構の実装は他の場所で再利用することができるかどうかをするように設計されたかどうか、一つの機能又は二として実装するかどうか）DeriveAuthzidおよび承認機能/または実装の詳細を実装します。
Note that the Authorize function outcome is clearly dependent on details of the local authorization model and policy. Both functions may be dependent on other factors as well.
承認機能の結果は、ローカル認可モデルとポリシーの詳細に明らかに依存していることに注意してください。両方の機能は、他の要因に依存してもよいです。
This section provides examples of PLAIN authentication exchanges. The examples are intended to help the readers understand the above text. The examples are not definitive.
このセクションでは、PLAIN認証交換の例を提供します。例は読者が上記のテキストを理解しやすくすることを意図しています。例は決定的ではありません。
"C:" and "S:" indicate lines sent by the client and server, respectively. "<NUL>" represents a single NUL (U+0000) character. The Application Configuration Access Protocol ([ACAP]) is used in the examples.
「C：」と「S：」はそれぞれ、クライアントとサーバから送られた行を示しています。 "<NUL>は、" 単一NUL（U + 0000）文字を表します。アプリケーション設定アクセスプロトコル（[ACAP]）は実施例で使用されています。
The first example shows how the PLAIN mechanism might be used for user authentication.
最初の例は、PLAINメカニズムは、ユーザ認証に使用する方法を示しています。
S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a001 STARTTLS S: a001 OK "Begin TLS negotiation now" <TLS negotiation, further commands are under TLS layer> S: * ACAP (SASL "CRAM-MD5" "PLAIN") C: a002 AUTHENTICATE "PLAIN" S: + "" C: {21} C: <NUL>tim<NUL>tanstaaftanstaaf S: a002 OK "Authenticated"
S：* ACAP（SASL "CRAM-MD5"）（STARTTLS）C：A001 STARTTLSのS：A001 OK "今TLSネゴシエーションを開始します" <TLS折衝、さらにコマンドはTLS層の下にある> S：* ACAP（SASL「CRAM-MD5 " "PLAIN"）C：A002 AUTHENTICATE "PLAIN" S：+ "" C：{21} C <NUL>ティム<NUL> tanstaaftanstaaf S：A002 OK "認証"
The second example shows how the PLAIN mechanism might be used to attempt to assume the identity of another user. In this example, the server rejects the request. Also, this example makes use of the protocol optional initial response capability to eliminate a round-trip.
第二の例は、PLAINメカニズムは、他のユーザのアイデンティティを仮定しようとするために使用する方法を示しています。この例では、サーバは要求を拒否します。また、この例では、ラウンドトリップを排除するためのプロトコルオプションの初期応答性を利用します。
S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a001 STARTTLS S: a001 OK "Begin TLS negotiation now" <TLS negotiation, further commands are under TLS layer> S: * ACAP (SASL "CRAM-MD5" "PLAIN") C: a002 AUTHENTICATE "PLAIN" {20+} C: Ursel<NUL>Kurt<NUL>xipj3plmq S: a002 NO "Not authorized to requested authorization identity"
S：* ACAP（SASL "CRAM-MD5"）（STARTTLS）C：A001 STARTTLSのS：A001 OK "今TLSネゴシエーションを開始します" <TLS折衝、さらにコマンドはTLS層の下にある> S：* ACAP（SASL「CRAM-MD5 " "PLAIN"）C：A002 AUTHENTICATE "プレーン"{20+} C：ローケレン<NUL>クルト<NUL> xipj3plmq S：A002 NO "が要求された許可識別する権限がありません"
As the PLAIN mechanism itself provided no integrity or confidentiality protections, it should not be used without adequate external data security protection, such as TLS services provided by many application-layer protocols. By default, implementations SHOULD NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless adequate data security services are in place.
PLAINメカニズム自体は何の整合性や機密性の保護を提供しないので、このような多くのアプリケーション層のプロトコルが提供するTLSサービスとして、十分な外部データのセキュリティ保護なしで使用すべきではありません。デフォルトでは、実装は宣伝すべきではなく、十分なデータのセキュリティサービスが整っている場合を除きPLAINメカニズムを使用するべきではありません。
When the PLAIN mechanism is used, the server gains the ability to impersonate the user to all services with the same password regardless of any encryption provided by TLS or other confidentiality protection mechanisms. Whereas many other authentication mechanisms have similar weaknesses, stronger SASL mechanisms address this issue. Clients are encouraged to have an operational mode where all mechanisms that are likely to reveal the user's password to the server are disabled.
PLAINメカニズムを使用すると、サーバーは関係なく、TLSまたは他の機密保護機構が提供する暗号化の同じパスワードですべてのサービスにユーザーを偽装する能力を獲得します。他の多くの認証機構が同様の弱点を持っているのに対し、より強力なSASLメカニズムは、この問題に対処します。クライアントはサーバーにユーザーのパスワードを明らかにする可能性があるすべてのメカニズムが無効になっている動作モードを持つことが奨励されています。
General [SASL] security considerations apply to this mechanism.
一般的な[SASL]セキュリティ上の考慮事項は、この機構に適用されます。
Unicode, [UTF-8], and [StringPrep] security considerations also apply.
ユニコード、[UTF-8]、および[STRINGPREP]セキュリティ上の考慮事項も適用されます。
The SASL Mechanism registry [IANA-SASL] entry for the PLAIN mechanism has been updated by the IANA to reflect that this document now provides its technical specification.
PLAINメカニズムのSASLメカニズムのレジストリ[IANA-SASL]のエントリは、この文書は、現在その技術仕様を提供していることを反映するためにIANAによって更新されました。
To: iana@iana.org Subject: Updated Registration of SASL mechanism PLAIN
To：iana@iana.org件名：SASLメカニズムPLAINの更新登録
SASL mechanism name: PLAIN Security considerations: See RFC 4616. Published specification (optional, recommended): RFC 4616 Person & email address to contact for further information: Kurt Zeilenga <kurt@openldap.org> IETF SASL WG <ietf-sasl@imc.org> Intended usage: COMMON Author/Change controller: IESG <iesg@ietf.org> Note: Updates existing entry for PLAIN
SASLメカニズム名：PLAINセキュリティの考慮事項：参照してくださいRFC 4616.公開仕様（オプション、推奨）：RFC 4616には、人とEメールアドレスは、詳細のために連絡する：クルトZeilenga <kurt@openldap.org> IETF SASL WG <IETF-SASL @ IMC .ORG>意図している用法：COMMON著者/変更コントローラ：IESG <iesg@ietf.org>注：PLAINのエントリを既存のアップデート
This document is a revision of RFC 2595 by Chris Newman. Portions of the grammar defined in Section 2 were borrowed from [UTF-8] by Francois Yergeau.
この文書では、クリス・ニューマンによってRFC 2595の改訂版です。セクション2で定義された文法の部分は、フランソワYergeauにより[UTF-8]から借用しました。
This document is a product of the IETF Simple Authentication and Security Layer (SASL) Working Group.
この文書は、IETF簡易認証セキュリティー層（SASL）ワーキンググループの製品です。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[Keywords] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]メルニコフ、A.編、およびK. Zeilenga、エド。、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[SASLPrep] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLPrep] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
【STRINGPREP]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[UNICODE]ユニコードコンソーシアムは、 "Unicode標準、バージョン3.2.0" は、 "Unicode規格、バージョン3.0"（読書、MA、アディソン・ウェズリー、61633から5 2000. ISBN 0-201-）などによって定義されます改正 "Unicode標準の附属書＃27：ユニコード3.1"（http://www.unicode.org/reports/tr27/）とで "Unicode標準の附属書＃28：Unicodeの3.2"（のhttp：//www.unicode .ORG /レポート/ TR28 /）。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[CRAM-MD5] Nerenberg, L., Ed., "The CRAM-MD5 SASL Mechanism", Work in Progress, June 2006.
[CRAM-MD5] Nerenberg、L.、エド。、 "CRAM-MD5 SASLメカニズム"、進歩、2006年6月に作業。
[DIGEST-MD5] Melnikov, A., Ed., "Using Digest Authentication as a SASL Mechanism", Work in Progress, June 2006.
[DIGEST-MD5]メルニコフ、A.編、進歩、2006年6月に、ワーク "SASLメカニズムとしてダイジェスト認証を使用します"。
[IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS", <http://www.iana.org/assignments/sasl-mechanisms>.
[IANA-SASL] IANA、 "簡易認証セキュリティー層（SASL）メカニズム"、<http://www.iana.org/assignments/sasl-mechanisms>。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTP-AUTH]マイヤーズ、J.、 "認証のためのSMTPサービス拡張子"、RFC 2554、1999年3月。
Appendix A. Changes since
付録A.からの変更点
This appendix is non-normative.
この付録は非規範的です。
This document replaces Section 6 of RFC 2595.
この文書は、RFC 2595のセクション6を置き換えます。
The specification details how the server is to compare client-provided character strings with stored character strings.
仕様では、サーバが格納された文字列をクライアントが提供する文字列を比較する方法を詳しく説明します。
The ABNF grammar was updated. In particular, the grammar now allows LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the authzid, authcid, passwd productions. However, whether these control characters may be used depends on the string preparation rules applicable to the production. For passwd and authcid productions, control characters are prohibited. For authzid, one must consult the application-level SASL profile. This change allows PLAIN to carry all possible authorization identity strings allowed in SASL.
ABNF文法を更新しました。特に、文法は今ラインフィード（U + 000A）とキャリッジリターン（U + 000D）authzidは、authcid、passwdの生産の文字を許容します。しかし、これらの制御文字を使用することができるかどうかは、製造に適用文字列準備のルールに依存します。 passwdとauthcid制作のために、制御文字が禁止されています。 authzidは、一つには、アプリケーションレベルのSASLプロファイルを参照する必要があります。この変更は、PLAINはSASLで許可されているすべての可能な認証アイデンティティ文字列を運ぶことができます。
Pseudo-code was added.
擬似コードが追加されました。
The example section was expanded to illustrate more features of the PLAIN mechanism.
実施例の節は、PLAINメカニズムの多くの機能を説明するために拡大しました。
Editor's Address
編集者の住所
Kurt D. Zeilenga OpenLDAP Foundation
クルトD. ZeilengaのOpenLDAP財団
EMail: Kurt@OpenLDAP.org
メールアドレス：Kurt@OpenLDAP.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。