RFC4616 日本語訳

Network Working Group                                   K. Zeilenga, Ed.
Request for Comments: 4616                           OpenLDAP Foundation
Updates: 2595                                                August 2006
Category: Standards Track

ワーキンググループK.Zeilenga、エドをネットワークでつないでください。コメントのために以下を要求してください。 4616のOpenLDAP財団アップデート: 2595 2006年8月のカテゴリ: 標準化過程

  The PLAIN Simple Authentication and Security Layer (SASL) Mechanism

明瞭な簡易認証とセキュリティ層(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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(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メカニズムと呼ばれる簡単なクリアテキストユーザ/パスワードSimple AuthenticationとSecurity Layer(SASL)メカニズムを定義します。 PLAINメカニズムが使用されることを意図します、下層によって提供されたデータの機密性サービスと組み合わせて、簡単なパスワード認証コマンドを欠いているプロトコルで。

Zeilenga                    Standards Track                     [Page 1]

RFC 4616                The PLAIN SASL Mechanism             August 2006

Zeilenga規格は明瞭なSASLメカニズム2006年8月にRFC4616を追跡します[1ページ]。

1.  Introduction

1. 序論

   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.

このドキュメントはプロトコルにおける使用のためにクリアテキストログインコマンド(例えば、[ACAP]か[SMTP-AUTH])なしでPLAIN Simple AuthenticationとSecurity Layer([SASL])メカニズムを定義します。 セクション6に取って代わって、このドキュメントはRFC2595をアップデートします。 RFC2595以来の変化はAppendix Aで詳細です。

   The name associated with this mechanism is "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メカニズムを使用するべきではありません。 応用層プロトコルで提供するデータ機密保護保護と共にメカニズムが使用されることを意図します、一般にTransport Layer Security([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.

デフォルトで、適切なデータ機密保護サービスが適所にあるときだけ、実装SHOULDは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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?

2.  PLAIN SASL Mechanism

2. 明瞭なSASLメカニズム

   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.

メカニズムはただ一つのメッセージから成ります、[UTF-8]コード化された[ユニコード]キャラクタのストリング、クライアントからサーバまで。クライアントが承認のアイデンティティを提示する、(行動するアイデンティティ、)、認証のアイデンティティ(パスワードが使用されるアイデンティティ)があとに続いたキャラクタがNUL(U+0000)キャラクタを続けたNUL(U+0000)によって続かれて、クリアテキストパスワードで続きました。 資格証明書からアイデンティティを得て、承認のアイデンティティとしてそれを使用するためにサーバを願っているとき、他のSASLメカニズムのように、クライアントは承認のアイデンティティを提供しません。

Zeilenga                    Standards Track                     [Page 2]

RFC 4616                The PLAIN SASL Mechanism             August 2006

Zeilenga規格は明瞭なSASLメカニズム2006年8月にRFC4616を追跡します[2ページ]。

   The formal grammar for the client message using Augmented BNF [ABNF]
   follows.

Augmented 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

安全な=UTF1/UTF2/UTF3/UTF4。 NULを除いて、どんなUTF-8もユニコード文字をコード化しました。

   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/%xE1EC2(UTF0)/%xED%x80-9F UTF0/%xEE-EF2(UTF0)UTF4=%xF0%x90-BF2(UTF0)/%xF1-F3 3(UTF0)/%xF4%x80-8F2(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.

承認のアイデンティティ(authzid)、認証のアイデンティティ(authcid)、パスワード(passwd)、およびNULキャラクタdeliminators SHALL、[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.

サーバは255の八重奏を含めてauthzid、authcid、およびpasswd創作を受け入れることができなければなりません。 ユニコード文字の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)について確かめるでしょう、そして、それは認証資格証明書が、クライアントが(提示されるか、または引き出されます)承認のアイデンティティ(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

提示された認証のアイデンティティ、パスワードストリング、データベース認証のアイデンティティ、およびパスワードストリングは検証プロセスで使用される前に準備されていることです。 [StringPrep]アルゴリズムの[SASLPrep]プロフィールはRECOMMENDED準備アルゴリズムです。 SASLprep準備アルゴリズムはそうです。

Zeilenga                    Standards Track                     [Page 3]

RFC 4616                The PLAIN SASL Mechanism             August 2006

Zeilenga規格は明瞭なSASLメカニズム2006年8月にRFC4616を追跡します[3ページ]。

   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.

比較が予想された態度で振る舞うという見込みを改良することが勧められます。 適切であるときに、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.

予想されたストリングの非invertible機能(例えば、ハッシュ)の出力が保存されるなら使用される準備アルゴリズムにかかわらず、その機能に入力される前にストリングを準備しなければなりません。

   Regardless of the preparation algorithm used, if preparation fails or
   results in an empty string, verification SHALL fail.

準備が空のストリングを失敗するか、またはもたらすなら使用される準備アルゴリズムにかかわらず、検証SHALLは失敗します。

   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.

承認のアイデンティティを全く提供しないとき、サーバが承認のアイデンティティに提供された認証アイデンティティストリングの準備された表現に由来しています。 これは、認証のアイデンティティの異なった表現の派生が同じ承認のアイデンティティを生産するのを確実にします。

   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]に適当な1つなどのどんな新しい認証データベースも初期化するのに資格証明書を使用するかもしれません。

3.  Pseudo-Code

3. 中間コード

   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
     }

論理演算子Verify(authzidを結んでください、ストリングauthcid、ストリングpasswd)、ストリングpAuthcidはSASLprep(本当にauthcid)と等しいです; #authcidストリングpPasswd=SASLprep(本当にpasswd)を用意してください; #(NULL| | pAuthcid=pPasswd=NULL)が準備が失敗した偽;#、を返すならpasswdを用意してください、(pAuthcid=、「「| | pPasswd=、「「)」{虚偽で戻ってください; #空の準備されたストリング}

Zeilenga                    Standards Track                     [Page 4]

RFC 4616                The PLAIN SASL Mechanism             August 2006

Zeilenga規格は明瞭なSASLメカニズム2006年8月にRFC4616を追跡します[4ページ]。

     storedHash = FetchPasswordHash(pAuthcid);
     if (storedHash == NULL || storedHash == "") {
       return false;     # error or unknown authcid
     }

storedHashはFetchPasswordHash(pAuthcid)と等しいです。 (ヌル| | storedHash=storedHash=、「「)」{虚偽で戻ってください; #誤りか未知のauthcid}

     if (!Compare(storedHash, Hash(pPasswd))) {
       return false;     # incorrect password
     }

((storedHash、ハッシュ(pPasswd))を比較してください。{虚偽で戻ってください; #間違ったパスワード}

     if (authzid == NULL ) {
       authzid = DeriveAuthzid(pAuthcid);
       if (authzid == NULL || authzid == "") {
           return false; # could not derive authzid
       }
     }

(authzid=ヌル)authzidはDeriveAuthzid(pAuthcid)と等しいです;、(NULL| | authzid=authzid=、「「)、虚偽で戻ってください; #、がauthzidを引き出すことができなかった、」

     if (!Authorize(pAuthcid, authzid)) {
       return false;     # not authorized
     }

(Authorize(pAuthcid、authzid))です。{虚偽で戻ってください; 認可されなかった#}

     return 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番目のパラメタは、割り当てられなかったコード・ポイントが入力に許容されているのを示します。 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.

Authorize機能に提供された2番目のパラメタはこのコードによって準備されません。 アプリケーションレベル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とAuthorize機能(これらが機能する方法で設計されているか否かに関係なく、1つの機能か2つの機能として実装するか、またはほかの場所でメカニズム実装を再利用できることにかかわらず)がメカニズムとアプリケーションレベルプロトコル仕様、そして/または、実装する実装の詳細の知識と理解を必要とすることに注意してください。

   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.

Authorize機能結果が明確にローカルの承認モデルと方針の詳細に依存していることに注意してください。 両方の機能はまた、他の要素に依存しているかもしれません。

Zeilenga                    Standards Track                     [Page 5]

RFC 4616                The PLAIN SASL Mechanism             August 2006

Zeilenga規格は明瞭なSASLメカニズム2006年8月にRFC4616を追跡します[5ページ]。

4.  Examples

4. 例

   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)キャラクタの代理をします。 Application Configuration Accessプロトコル([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、「一夜漬け-MD5") (STARTTLS)C:、」 a001 STARTTLS S: TLS層の>Sの下にa001OK「現在のTLS交渉を始めてください」<TLS交渉、より遠いコマンドがあります: * ACAP、(SASL、「一夜漬け-MD5"「平野」) C:、」 a002 AUTHENTICATE「平野」S: +、「「C:」 21C: <NUL>tim<NUL>tanstaaftanstaaf S: OKが「認証した」a002

   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.

2番目の例は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、「一夜漬け-MD5") (STARTTLS)C:、」 a001 STARTTLS S: TLS層の>Sの下にa001OK「現在のTLS交渉を始めてください」<TLS交渉、より遠いコマンドがあります: * ACAP、(SASL、「一夜漬け-MD5"「平野」) C:、」 a002 AUTHENTICATE「平野」20+、C: Ursel<NUL>カート<NUL>xipj3plmq S: 「要求された承認のアイデンティティに認可されなかった」a002

5.  Security Considerations

5. セキュリティ問題

   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などのサービスは多くの応用層プロトコルで前提としました。 デフォルトで、実装SHOULD NOTは広告を出します、そして、適切なデータ機密保護サービスが適所にない場合、SHOULD NOTはPLAINメカニズムを利用します。

Zeilenga                    Standards Track                     [Page 6]

RFC 4616                The PLAIN SASL Mechanism             August 2006

Zeilenga規格は明瞭なSASLメカニズム2006年8月にRFC4616を追跡します[6ページ]。

   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]セキュリティ問題は適用されます。

6.  IANA Considerations

6. IANA問題

   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 Mechanism登録[IANA-SASL]エントリーは、このドキュメントが現在技術仕様書を提供するのを反映するためにIANAによってアップデートされました。

   To: iana@iana.org
   Subject: Updated Registration of SASL mechanism PLAIN

To: iana@iana.org Subject: SASLメカニズムPLAINのアップデートされたRegistration

   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 Security問題: RFC4616を見てください。 広められた仕様(任意の、そして、お勧めの): 詳細のために連絡するRFC4616PersonとEメールアドレス: カート Zeilenga <kurt@openldap.org 、gt;、IETF SASL WG <ietf-sasl@imc.org 、gt;、意図している用法: COMMON Author/変化コントローラ: IESG <iesg@ietf.org 、gt;、注意: PLAINのために既存のエントリーをアップデートします。

7.  Acknowledgements

7. 承認

   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.

このドキュメントはクリス・ニューマンによるRFC2595の改正です。 セクション2で定義された文法の部分はフランソアYergeauによって[UTF-8]から借りられました。

   This document is a product of the IETF Simple Authentication and
   Security Layer (SASL) Working Group.

このドキュメントはIETF Simple AuthenticationとSecurity Layer(SASL)作業部会の製品です。

Zeilenga                    Standards Track                     [Page 7]

RFC 4616                The PLAIN SASL Mechanism             August 2006

Zeilenga規格は明瞭なSASLメカニズム2006年8月にRFC4616を追跡します[7ページ]。

8.  Normative References

8. 引用規格

   [ABNF]        Crocker, D., Ed. and P. Overell, "Augmented BNF for
                 Syntax Specifications: ABNF", RFC 4234, October 2005.

エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

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

「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」という[キーワード]ブラドナー、S.、BCP14、RFC2119、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)を層にする」RFC4422、6月2006日

   [SASLPrep]    Zeilenga, K., "SASLprep: Stringprep Profile for User
                 Names and Passwords", RFC 4013, February 2005.

[SASLPrep]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。

   [StringPrep]  Hoffman, P. and M. Blanchet, "Preparation of
                 Internationalized Strings ("stringprep")", RFC 3454,
                 December 2002.

[StringPrep] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、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/).

[ユニコード] ユニコードConsortium、「ユニコード規格、バージョン、3.2、0インチ、定義される、「ユニコード規格、修正されるバージョン3インチ(読書、MA、アディソン-ウエスリー、2000ISBN0-201- 61633-5)、「ユニコード規格別館#27:」 「ユニコード規格別館#28:」 ユニコード3.2インチ( http://www.unicode.org/reports/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、ISO10646の変換形式」STD63、RFC3629、11月2003日

   [TLS]         Dierks, T. and E. Rescorla, "The Transport Layer
                 Security (TLS) Protocol Version 1.1", RFC 4346, April
                 2006.

[TLS] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

9.  Informative 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]    Nerenberg, L., Ed., "The CRAM-MD5 SASL Mechanism", Work
                 in Progress, June 2006.

[一夜漬け-MD5] ネーレンバーグ、L.、エド、「一夜漬け-MD5 SASLメカニズム」、処理中の作業、6月2006

   [DIGEST-MD5]  Melnikov, A., Ed., "Using Digest Authentication as a
                 SASL Mechanism", Work in Progress, June 2006.

[ダイジェスト-MD5] エドメリニコフ、A.、処理中の作業、「SASLメカニズムとしてダイジェスト認証を使用すること」での2006年6月。

Zeilenga                    Standards Track                     [Page 8]

RFC 4616                The PLAIN SASL Mechanism             August 2006

Zeilenga規格は明瞭なSASLメカニズム2006年8月にRFC4616を追跡します[8ページ]。

   [IANA-SASL]   IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL)
                 MECHANISMS",
                 <http://www.iana.org/assignments/sasl-mechanisms>.

[IANA-SASL]IANA、「簡易認証とセキュリティ層(SASL)のメカニズム」、<sasl http://www.iana.org/課題/メカニズム>。

   [SMTP-AUTH]   Myers, J., "SMTP Service Extension for Authentication",
                 RFC 2554, March 1999.

[SMTP-AUTH] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。

Zeilenga                    Standards Track                     [Page 9]

RFC 4616                The PLAIN SASL Mechanism             August 2006

Zeilenga規格は明瞭なSASLメカニズム2006年8月にRFC4616を追跡します[9ページ]。

Appendix A.  Changes since RFC 2595

RFC2595以来の付録A.変化

   This appendix is non-normative.

この付録は非規範的です。

   This document replaces Section 6 of RFC 2595.

このドキュメントはRFC2595のセクション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文法をアップデートしました。 特に、文法は現在、authzid、authcid、passwd創作にLINE FEED(U+000A)とCARRIAGE RETURN(U+000D)キャラクタを許容します。 しかしながら、これらの制御文字が使用されるかもしれないかどうかが生産に適切なストリング準備規則によります。 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

Zeilenga                    Standards Track                    [Page 10]

RFC 4616                The PLAIN SASL Mechanism             August 2006

Zeilenga規格は明瞭なSASLメカニズム2006年8月にRFC4616を追跡します[10ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Zeilenga                    Standards Track                    [Page 11]

Zeilenga標準化過程[11ページ]