Network Working Group R. Siemborski
Request for Comments: 5034 Google, Inc.
Obsoletes: 1734 A. Menon-Sen
Updates: 2449 Oryx Mail Systems GmbH
Category: Standards Track July 2007
The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism
ポストオフィスプロトコル（POP3）簡易認証セキュリティー層（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 IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session.
この文書では、ポストオフィスプロトコル（POP3）のための簡易認証セキュリティー層（SASL）のプロファイルを定義します。この拡張は、サーバへの認証メカニズムを示す認証プロトコル交換を実行し、必要に応じて、このセッション中に後続のプロトコル相互作用のためのセキュリティ層を交渉するPOP3クライアントを可能にします。
This document seeks to consolidate the information related to POP3 AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained in Section 6.3 of RFC 2449.
この文書では、1つの文書にPOP3 AUTHに関連した情報を統合することを目指しています。このため、このドキュメントは廃止し、RFC 1734を置き換え、およびRFC 2449のセクション6.3に含まれる情報を更新します。
The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered several problems in its specification. The first is that it was very similar to a SASL framework defined by [RFC4422], but pre-dated the initial SASL specification. It was therefore missing some key components, such as a way to list the available authentication mechanisms.
POP3（[RFC1939]を参照）AUTHコマンド（[RFC1734]を参照）にその仕様にいくつかの問題を被っています。最初は、[RFC4422]で定義されたSASLフレームワークと非常に類似していたが、最初のSASL仕様事前日付ということです。従って、このような利用可能な認証メカニズムを一覧表示する方法として、いくつかの主要なコンポーネントを、行方不明になりました。
Later, [RFC2449] attempted to remedy this situation by adding the CAPA command and allowing an initial client response with the AUTH command, but problems remained in the clarity of the specification of how the initial client response was to be handled.
その後、[RFC2449]はCAPAコマンドを追加し、AUTHコマンドを使用して、初期のクライアント応答を可能にすることにより、この状況を改善しようとしましたが、問題は、最初のクライアント応答が扱われることになっていたかの仕様の明確性に残りました。
Together, this means creating a full POP3 AUTH implementation requires an understanding of material in at least five different documents (and [RFC3206] provides additional response codes that are useful during authentication).
一緒に、これは完全なPOP3のAUTH実装は（認証時に有用である追加の応答コードを提供し、[RFC3206]）少なくとも5つの異なるドキュメント内の材料の理解を必要とする作成手段。
This document attempts to combine the information in [RFC1734] and [RFC2449] to simplify this situation. Additionally, it aims to clarify and update the older specifications where appropriate.
この文書では、この状況を簡素化するために、[RFC1734]と[RFC2449]で情報を結合しようとします。また、それが適切な場合には、古い仕様を明確にし、更新することを目指しています。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
実施例では、「C：」および「S：」はそれぞれクライアントとサーバから送信されたラインを示します。
Formal syntax is defined by [RFC4234].
正式な構文は、[RFC4234]で定義されています。
This section supersedes the definition of the SASL Capability in section 6.3 of [RFC2449].
このセクションでは、[RFC2449]のセクション6.3でSASL能力の定義に取って代わります。
CAPA tag: SASL
CAPAタグ：SASL
Arguments: Supported SASL Mechanisms
引数：サポートされているSASLメカニズム
Added commands: AUTH
追加されましたコマンド：AUTH
Standard commands affected: None
影響を受けた標準コマンド：なし
Announced states / possible differences: both / no
発表された状態/可能性の違い：両方/なし
Commands valid in states: AUTHORIZATION
状態で有効なコマンド：AUTHORIZATIONを
Specification reference: This document and [RFC4422]
仕様参照：このドキュメントと[RFC4422]
Discussion: The SASL capability permits the use of the AUTH command (as defined in Section 4 of this document) to begin a SASL negotiation (as defined in [RFC4422]). The argument to the SASL capability is a space-separated list of SASL mechanisms that are supported.
ディスカッション：SASL能力はSASLネゴシエーションを開始する（このドキュメントのセクション4で定義されるように）AUTHコマンドを使用可能にする（[RFC4422]で定義されるように）。 SASL機能への引数はサポートされているSASLメカニズムのスペース区切りのリストです。
If a server either does not support the CAPA command or does not advertise the SASL capability, clients SHOULD NOT attempt the AUTH command. If a client does attempt the AUTH command in such a situation, it MUST NOT supply the client initial response parameter (for backwards compatibility with [RFC1734]).
サーバがCAPAコマンドをサポートしていないか、SASLの機能をアドバタイズしないか場合は、クライアントがAUTHコマンドを試みるべきではありません。クライアントは、このような状況でAUTHコマンドをしようとしない場合、それは（[RFC1734]との後方互換性のために）クライアント初期応答パラメータを指定してはなりません。
Note that the list of available mechanisms MAY change after a successful STLS command (see [RFC2595]). However, as required by [RFC2449], implementations MUST continue to include the SASL capability even after a successful AUTH command has been completed (even though no further AUTH commands may be issued).
利用可能なメカニズムのリストが成功STLSコマンドの後に変更することがあります（[RFC2595]を参照）。しかしながら、[RFC2449]によって必要とされるよう、実装が成功したAUTHコマンド（さらなるAUTHコマンドが発行されない場合であっても）が完了した後もSASL能力を含めるし続けなければなりません。
Example S: +OK pop.example.com BlurdyBlurp POP3 server ready C: CAPA S: +OK List of capabilities follows S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS S: STLS S: IMPLEMENTATION BlurdyBlurp POP3 server S: .
例S：+ OK pop.example.com BlurdyBlurp POP3サーバ準備C：CAPA S：SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS S：STLSのS：実装BlurdyBlurp POP3サーバS：+能力のOKリストは、Sの後に続きます。
AUTH mechanism [initial-response]
AUTH機構[初期応答]
Arguments:
引数：
mechanism: A string identifying a SASL authentication mechanism.
機構：SASL認証メカニズムを識別する文字列。
initial-response: An optional initial client response, as defined in Section 3 of [RFC4422]. If present, this response MUST be encoded as Base64 (specified in Section 4 of [RFC4648]), or consist only of the single character "=", which represents an empty initial response.
初期の応答：[RFC4422]のセクション3で定義されるようにオプションの初期のクライアント応答、。存在する場合、この応答は、（[RFC4648]のセクション4で指定）Base64でエンコードされたように、または空の初期応答を表す単一文字「=」でのみ構成されなければなりません。
Restrictions:
制限事項：
After an AUTH command has been successfully completed, no more AUTH commands may be issued in the same session. After a successful AUTH command completes, a server MUST reject any further AUTH commands with an -ERR reply.
AUTHコマンドが正常に完了した後、これ以上のAUTHコマンドは、同じセッションで発行することができます。成功したAUTHコマンドが完了すると、サーバは-ERR応答して任意の更なるAUTHコマンドを拒絶しなければなりません。
The AUTH command may only be given during the AUTHORIZATION state.
AUTHコマンドは、AUTHORIZATION状態の間与えられてもよいです。
Discussion:
討論：
The AUTH command initiates a SASL authentication exchange between the client and the server. The client identifies the SASL mechanism to use with the first parameter of the AUTH command. If the server supports the requested authentication mechanism, it performs the SASL exchange to authenticate the user. Optionally, it also negotiates a security layer for subsequent protocol interactions during this session. If the requested authentication mechanism is not supported, the server rejects the AUTH command with an -ERR reply.
AUTHコマンドは、クライアントとサーバ間のSASL認証交換を開始します。クライアントがAUTHコマンドの最初のパラメータで使用するSASLメカニズムを識別します。サーバは要求された認証メカニズムをサポートしている場合、それは、ユーザを認証するためにSASL交換を行います。必要に応じて、それはまた、このセッション中に後続のプロトコル相互作用のためのセキュリティ層を交渉します。要求された認証メカニズムがサポートされていない場合、サーバは-ERR応答でAUTHコマンドを拒否します。
The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the chosen SASL mechanism.
認証プロトコル交換は、選択されたSASLメカニズムに固有のサーバーチャレンジとクライアントの一連の応答で構成されています。
A server challenge is sent as a line consisting of a "+" character, followed by a single space and a string encoded using Base64, as specified in Section 4 of [RFC4648]. This line MUST NOT contain any text other than the BASE64-encoded challenge.
[RFC4648]のセクション4で指定されるように、サーバチャレンジは、単一のスペースに続いて、「+」文字からなるライン、およびBase64でを使用してエンコードされた文字列として送信されます。この行は、BASE64でエンコードされた課題以外の任意のテキストを含めることはできません。
A client response consists of a line containing a string encoded as Base64. If the client wishes to cancel the authentication exchange, it issues a line with a single "*". If the server receives such a response, it MUST reject the AUTH command by sending an -ERR reply.
クライアントの応答は、Base64としてエンコードされた文字列を含む行で構成されています。クライアントが認証交換を中止したい場合は、「*」の単一の行を発行します。サーバがそのような応答を受信した場合、それは-ERR応答を送信することによって、AUTHコマンドを拒絶しなければなりません。
The optional initial-response argument to the AUTH command is used to save a round trip when using authentication mechanisms that support an initial client response. If the initial response argument is omitted and the chosen mechanism requires an initial client response, the server MUST proceed by issuing an empty challenge, as defined in Section 3 of [RFC4422]. In POP3, an empty server challenge is defined as a line with only a "+", followed by a single space. It MUST NOT contain any other data.
AUTHコマンドのオプションの初期応答の引数は、最初のクライアント応答をサポートする認証メカニズムを使用した場合の往復を保存するために使用されます。初期応答引数を省略し、選択されたメカニズムは、初期のクライアント応答を必要としている場合、サーバは[RFC4422]のセクション3で定義されるように、空の挑戦を発行することによって進行しなければなりません。 POP3では、空のサーバのチャレンジは、単一の空白が続くだけ「+」とラインとして定義されます。これは、他のデータを含んではなりません。
For the purposes of the initial client response, the 255-octet limit on the length of a single command, defined in Section 4 of [RFC2449], still applies. If specifying an initial response would cause the AUTH command to exceed this length, the client MUST NOT use the initial-response parameter (and must proceed instead by sending its initial response after an empty challenge from the server, as in Section 3 of [RFC4422]).
初期のクライアント応答、[RFC2449]のセクション4で定義された単一のコマンドの長さに255オクテットの制限の目的のために、依然として適用されます。初期応答を指定すると、AUTHコマンドは、この長さを超過する場合は、クライアントは初期応答パラメータを使用してはならない（と[RFC4422のセクション3のように、サーバからの空の攻撃後にその初期応答を送信することで、代わりに進まなければなりません]）。
If the client needs to send a zero-length initial response, it MUST transmit the response as a single equals sign ("="). This indicates that the response is present, but contains no data.
クライアントは、長さゼロの初期応答を送信する必要がある場合は、単一の等号（「=」）に署名として、それが応答を送信しなければなりません。これは、応答が存在することを示しますが、データは含まれていません。
If the client uses an initial-response argument to the AUTH command with a SASL mechanism that does not support an initial client send, the server MUST reject the AUTH command with an -ERR reply.
クライアントは、最初のクライアントの送信をサポートしていないSASLメカニズムを持つAUTHコマンドへの初期応答の引数を使用している場合、サーバは-ERR応答でAUTHコマンドを拒絶しなければなりません。
If the server cannot Base64 decode a client response, it MUST reject the AUTH command with an -ERR reply. If the client cannot Base64 decode any of the server's challenges, it MUST cancel the authentication using the "*" response. In particular, servers and clients MUST reject (and not ignore) any character not explicitly allowed by the Base64 alphabet, and MUST reject any sequence of Base64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g., "=AAA" and "AAA=BBB" are not allowed).
サーバーがBase64では、クライアントの応答をデコードできない場合は、-ERR応答でAUTHコマンドを拒絶しなければなりません。クライアントは、Base64では、サーバの課題のいずれかをデコードすることができない場合は、「*」レスポンスを使用して認証をキャンセルしなければなりません。具体的には、サーバとクライアントは、（拒否（と無視しない）を明示的にBase64アルファベットで許可されていない任意の文字を、文字列の末尾よりも（「=」）どこか他のパッドの文字が含まれていたBase64任意の文字列を拒絶しなければなりませんしなければなりません例えば、 "= AAA" と "AAA = BBB"）が許可されていません。
Excepting the initial client response, these BASE64 strings may be of arbitrary length, depending on the authentication mechanism in use. Clients and servers MUST be able to handle the largest encoded challenges and responses generated by the authentication mechanisms they support. This requirement is independent of any line-length limitations the client or server may have in other parts of its protocol implementation.
初期のクライアント応答を除いて、これらのBASE64文字列は、使用中の認証メカニズムに応じて、任意の長さのものであってもよいです。クライアントとサーバーは、サポートする認証メカニズムによって生成された最大のエンコードされたチャレンジとレスポンスを扱うことができなければなりません。この要件は、クライアントまたはサーバが、プロトコル実装の他の部分に有していてもよい任意の行の長さの制限とは無関係です。
If the server is unable to authenticate the client, it MUST reject the AUTH command with an -ERR reply. Should the client successfully complete the exchange, the server issues a +OK reply. Additionally, upon success, the POP3 session enters the TRANSACTION state.
サーバがクライアントを認証できない場合は、-ERR応答でAUTHコマンドを拒絶しなければなりません。クライアントが正常に交換を完了する必要があり、サーバーが+ OK応答を発行します。また、成功すると、POP3セッションはTRANSACTION状態に入ります。
The authorization identity generated by the SASL exchange is a simple username, and SHOULD use the SASLprep profile (see [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to prepare these names for matching. If preparation of the authorization identity fails or results in an empty string (unless it was transmitted as the empty string), the server MUST fail the authentication.
SASL交換により生成された承認のアイデンティティは、単純名であり、マッチングのためにこれらの名前を調製するSTRINGPREPアルゴリズムのSASLprepプロファイル（[RFC4013]を参照）（[RFC3454]を参照）を使用すべきです。認可IDの作成が失敗した場合や、空の文字列の結果（それは空の文字列として送信された場合を除く）した場合、サーバーは認証が失敗しなければなりません。
If a security layer is negotiated during the SASL exchange, it takes effect for the client on the octet immediately following the CRLF that concludes the last response generated by the client. For the server, it takes effect immediately following the CRLF of its success reply.
セキュリティ層がSASL交換の間に交渉された場合、それはすぐに、クライアントによって生成された最後の応答を終えるCRLF、次のオクテット上のクライアントのために有効になります。サーバーの場合、それはその成功リプライのCRLFの直後に有効になります。
When a security layer takes effect, the server MUST discard any knowledge previously obtained from the client, which was not obtained from the SASL negotiation itself. Likewise, the client MUST discard any knowledge obtained from the server, such as the list of available POP3 service extensions.
セキュリティ層が有効になると、サーバーは以前SASL交渉自体から得られていないクライアントから得た知識を捨てなければなりません。同様に、クライアントは、利用可能なPOP3サービス拡張のリストとして、サーバから取得したすべての知識を捨てなければなりません。
When both Transport Layer Security (TLS) (see [RFC4346]) and SASL security layers are in effect, the TLS encoding MUST be applied after the SASL encoding when sending data. (According to [RFC2595], STLS can only be issued before AUTH in any case.)
両方のトランスポート層セキュリティ（TLS）が（参照[RFC4346]）とSASLセキュリティ層が有効である場合にデータを送信するとき、TLSエンコーディングはSASL符号化後に適用されなければなりません。 （[RFC2595]によれば、STLSは、いずれの場合においてAUTH前に発行することができます。）
Note that POP3 does not allow for additional data to be sent with a message indicating a successful outcome (see Section 3.6 of [RFC4422]).
POP3は、（[RFC4422]のセクション3.6を参照）成功した結果を示すメッセージで送信する追加のデータを許容しないことに留意されたいです。
The service name specified by this protocol's profile of SASL is "pop".
SASLのこのプロトコルのプロファイルで指定されたサービス名は「ポップ」です。
If an AUTH command fails, the client may try another authentication mechanism or present different credentials by issuing another AUTH command (or by using one of the other POP3 authentication mechanisms). Likewise, the server MUST behave as if the client had not issued the AUTH command.
AUTHコマンドが失敗した場合、クライアントは別の認証機構を試すか、別のAUTHコマンドを発行して（またはその他のPOP3認証メカニズムのいずれかを使用して）別の資格情報を提示することができます。クライアントがAUTHコマンドを発行していなかったかのように同様に、サーバが動作しますしなければなりません。
To ensure interoperability, client and server implementations of this extension MUST implement the PLAIN SASL mechanism [RFC4616] running over TLS [RFC2595].
相互運用性を確保するために、この拡張機能のクライアントとサーバの実装はTLS [RFC2595]上で実行されているPLAIN SASLメカニズム[RFC4616]を実装しなければなりません。
A server implementation MUST implement a configuration in which it does NOT advertise or permit any plaintext password mechanisms, unless the STLS command has been used to negotiate a TLS session (see [RFC2595]). As described by RFC 4616, this configuration SHOULD be the default configuration. Before using a plaintext password mechanism over a TLS session, client implementations MUST verify the TLS server certificate as required by RFC 2595, Section 2.4. Client and server implementations SHOULD implement additional SASL mechanisms that do not send plaintext passwords, such as the GSSAPI [RFC4752] mechanism.
STLSコマンド（[RFC2595]を参照）TLSセッションを交渉するために使用されていない限り、サーバーの実装は、それが任意の平文パスワードメカニズムを宣伝または許可しない構成を実装しなければなりません。 RFC 4616で説明したように、この設定はデフォルトの設定であるべきです。 RFC 2595、セクション2.4で必要とされるTLSセッション上で平文パスワードメカニズムを使用する前に、クライアント実装は、TLSサーバー証明書を検証しなければなりません。クライアントとサーバーの実装は、このようなGSSAPI [RFC4752]メカニズムとして平文パスワードを送信しない追加のSASLメカニズムを実装する必要があります。
The following syntax specification uses the Augmented Backus-Naur Form notation as specified in [RFC4234]. The rules CRLF, ALPHA, and DIGIT are imported from [RFC4234]. The sasl-mech rule is from [RFC4422].
[RFC4234]で指定されるように、次の構文仕様は、拡張バッカス・ナウアフォーム表記を使用します。ルールCRLF、ALPHA、およびDIGITは[RFC4234]からインポートされています。 SASL-メックルールは[RFC4422]です。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper- or lower-case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための大文字または小文字の文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
auth-command = "AUTH" SP sasl-mech [SP initial-response] *(CRLF [base64]) [CRLF cancel-response] CRLF
AUTHコマンド= "AUTH" SPのSASL-メック[SP初期応答] *（CRLF [BASE64]）CRLFキャンセル応答]をCRLF
initial-response = base64 / "="
初期応答= BASE64 / "="
cancel-response = "*"
キャンセル・レスポンス=「*」
base64 = base64-terminal / ( 1*(4base64-CHAR) [base64-terminal] )
BASE64 = BASE64末端/（1 *（4base64-CHAR）BASE64末端]）
base64-char = ALPHA / DIGIT / "+" / "/" ;; Case-sensitive
base64で文字= ALPHA / DIGIT / "+" / "/" ;;大文字と小文字を区別
base64-terminal = (2base64-char "==") / (3base64-char "=")
BASE64末端=（2base64-CHAR "=="）/（3base64-CHAR "="）
continue-req = "+" SP [base64] CRLF
引き続き-REQ = "+" SP [BASE64] CRLF
Additionally, the ABNF specified in [RFC2449] is updated as follows:
次のように加えて、ABNF [RFC2449]で指定が更新されます。
response =/ continue-req
応答= /継続-REQ
Here is an example of a client attempting AUTH PLAIN (see [RFC4616]) under TLS and making use of the initial client response:
ここではTLSの下でAUTH PLAINを（[RFC4616]を参照のこと）しようとすると、最初のクライアント応答を利用したクライアントの例は次のとおりです。
S: +OK pop.example.com BlurdyBlurp POP3 server ready
C: CAPA
S: +OK List of capabilities follows
S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
S: STLS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: STLS
S: +OK Begin TLS negotiation now
(TLS negotiation proceeds, further commands protected by TLS
layer)
C: CAPA
S: +OK List of capabilities follows
S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: +OK Maildrop locked and ready
Here is another client that is attempting AUTH PLAIN under a TLS layer, this time without the initial response. Parts of the negotiation before the TLS layer was established have been omitted:
ここではTLS層の下AUTH PLAINをしようとしている他のクライアント、初期応答のないこの時間があります。 TLS層が確立された前の交渉の一部が省略されています。
(TLS negotiation proceeds, further commands protected by TLS
layer)
C: CAPA
S: +OK List of capabilities follows
S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: AUTH PLAIN
(note that there is a space following the '+' on the
following line)
S: +
C: dGVzdAB0ZXN0AHRlc3Q=
S: +OK Maildrop locked and ready
Here is an example using a mechanism in which the exchange begins with a server challenge (the long lines are broken for editorial clarity only):
ここでは交換はサーバのチャレンジで始まります（長い行のみ編集明確にするため壊れている）するメカニズムを使用した例です。
S: +OK pop.example.com BlurdyBlurp POP3 server ready
C: CAPA
S: +OK List of capabilities follows
S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
S: STLS
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: AUTH DIGEST-MD5
S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
cnNldD11dGYtOA==
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In
BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1
NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA==
S: + cnNwYXV0aD0wYjk3MTQ2MmNlZjVlOGY5MzBkYjlhMzNiMDJmYzlhMA==
C:
S: +OK Maildrop locked and ready
Security issues are discussed throughout this document.
セキュリティ問題はこの文書を通して議論されています。
The IANA has updated its site to refer to this RFC instead of [RFC1734] in http://www.iana.org/assignments/pop3-extension-mechanism (the POP3 extension registry), and also in http://www.iana.org/assignments/gssapi-service-names (the GSSAPI/SASL service name registry).
IANAは、httpでもhttp://www.iana.org/assignments/pop3-extension-mechanismで代わりに[RFC1734]のこのRFC（POP3拡張レジストリ）を参照するために、そのサイトを更新し、そしてました：// WWW。 iana.org/assignments/gssapi-service-names（GSSAPI / SASLサービス名レジストリ）。
The authors would like to acknowledge the contributions of John Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other contributors to RFC 1734 and RFC 2554, on which this document draws heavily.
著者は、この文書は大きく描く上でRFC 1734およびRFC 2554、ジョン・マイヤーズ、ランドールGellens、クリス・ニューマン、ローレンスLundblade、および他の貢献者の貢献を認めたいと思います。
The authors would also like to thank Ken Murchison, Randall Gellens, Alexey Melnikov, Mark Crispin, Arnt Gulbrandsen, Lisa Dusseault, Frank Ellermann, and Philip Guenther for their reviews of this document.
著者らはまた、このドキュメントの彼らのレビューのためにケンマーチソン、ランドールGellens、アレクセイ・メルニコフ、マーク・クリスピン、ARNT Gulbrandsenの、リサDusseault、フランクEllermann、およびフィリップギュンターに感謝したいと思います。
1. Updated references to newer versions of various specifications, particularly RFC 4422.
様々な仕様の新しいバージョン、特にRFC 4422に1.参照を更新。
2. The SASL-based semantics defined in RFC 2449 are now normative for the AUTH extension.
2. RFC 2449で定義されたSASLベースのセマンティクスは今AUTH拡張のための規範です。
3. The proper behaviour and handling of initial client responses is defined, with examples and references to SASL.
3.適切な行動と初期のクライアント応答の取り扱いは、SASLの例や参照で、定義されています。
5. The SASLprep profile SHOULD be used to prepare authorization identities.
5. SASLprepプロファイルは、認証IDを準備するために使用されるべきです。
6. Clarify that the TLS encoding should be applied after any encoding applied by SASL security layers.
6. TLS符号化がSASLセキュリティ層によって適用される任意の符号化の後に適用されるべきであることを明確。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998.
[RFC2449] Gellens、R.、ニューマン、C.、およびL. Lundblade、 "POP3拡張メカニズム"、RFC 2449、1998年11月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595]ニューマン、C.、 "IMAP、POP3およびACAPとTLSを使用する"、RFC 2595、1999年6月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
"構文仕様のための増大しているBNF：ABNF" [RFC4234]クロッカー、D.、エド、およびP. Overell、。、RFC 4234、2005年10月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]メルニコフ、A.編、およびK. Zeilenga、エド。、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RFC4616] Zeilenga、K.、エド。、 "PLAIN簡易認証セキュリティー層（SASL）メカニズム"、RFC 4616、2006年8月。
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[RFC1734]マイヤーズ、J.、 "POP3認証コマンド"、RFC 1734、1994年12月。
[RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC 3206, February 2002.
[RFC3206] Gellens、R.、 "SYSとAUTH POPレスポンスコード"、RFC 3206、2002年2月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4752] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[RFC4752]メルニコフ、A.編、 "ケルベロスV5（" GSSAPI "）簡易認証セキュリティー層（SASL）メカニズム"、RFC 4752、2006年11月。
Authors' Addresses
著者のアドレス
Robert Siemborski Google, Inc. 1600 Ampitheatre Parkway Mountain View, CA 94043
ロバートSiemborskiグーグル株式会社1600アンフィシアターパークウェイマウンテンビュー、CA 94043
Phone: +1 650 623 6925 EMail: robsiemb@google.com
電話：+1 650 623 6925 Eメール：robsiemb@google.com
Abhijit Menon-Sen Oryx Mail Systems GmbH
Abhijitメノンセンオリックスメールシステム社
EMail: ams@oryx.com
メールアドレス：ams@oryx.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。