[要約] RFC 5034は、POP3のSASL認証メカニズムに関する規格であり、セキュリティと認証のための簡単な方法を提供します。このRFCの目的は、POP3サーバーとクライアント間の安全な通信を確保し、認証プロセスを強化することです。
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）The IETF Trust（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.
このドキュメントは、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]を参照）は、その仕様にいくつかの問題を抱えています。1つ目は、[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コマンドを追加し、認証コマンドで最初のクライアント応答を許可することにより、この状況を改善しようとしましたが、問題は最初のクライアント応答がどのように処理されるかを明確にしています。
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実装を作成するには、少なくとも5つの異なるドキュメントで資料を理解する必要があることを意味します（および[RFC3206]は、認証中に役立つ追加の応答コードを提供します）。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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
発表された州 /可能な違い：両方 / no
Commands valid in states: 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機能により、authコマンド（このドキュメントのセクション4で定義されているように）の使用がSASLネゴシエーション（[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コマンドを試みてはいけません。クライアントがそのような状況で認証コマンドを試みる場合、クライアントの初期応答パラメーターを提供してはなりません（[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]で要求されているように、実装は、成功した認証コマンドが完了した後でも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: .
AUTH mechanism [initial-response]
認証メカニズム[初期応答]
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で定義されているオプションの初期クライアント応答。存在する場合、この応答はbase64（[RFC4648]のセクション4で指定）としてエンコードするか、空の初期応答を表す単一文字 "="でのみ構成されている必要があります。
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コマンドが完了した後、サーバーは-err応答を使用してさらに認証コマンドを拒否する必要があります。
The AUTH command may only be given during the AUTHORIZATION state.
認証コマンドは、承認状態中にのみ指定される場合があります。
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認証交換を開始します。クライアントは、認証コマンドの最初のパラメーターで使用するSASLメカニズムを識別します。サーバーが要求された認証メカニズムをサポートする場合、SASL Exchangeを実行してユーザーを認証します。オプションでは、このセッション中にその後のプロトコル相互作用のセキュリティレイヤーも交渉します。要求された認証メカニズムがサポートされていない場合、サーバーは-ERR応答で認証コマンドを拒否します。
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の応答を送信して、認証コマンドを拒否する必要があります。
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コマンドがこの長さを超えると、クライアントは初期応答パラメーターを使用してはなりません（また、[RFC442222222のセクション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文字のシーケンスを拒否する必要があります（たとえば、「= 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コマンドを拒否する必要があります。クライアントがExchangeを正常に完了した場合、サーバーはOK返信を発行します。さらに、成功すると、POP3セッションはトランザクション状態に入ります。
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 Exchangeによって生成された認証IDは単純なユーザー名であり、StringPrepアルゴリズム（[RFC3454]を参照）のSASLPrepプロファイル（[RFC4013]を参照）を使用して、これらの名前をマッチングのために準備する必要があります。承認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セキュリティ層の両方が有効な場合、データを送信するときにSASLエンコード後にTLSエンコードを適用する必要があります。（[RFC2595]によると、STLはいずれにせよ、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プロファイルによって指定されたサービス名は「POP」です。
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.
認証コマンドが失敗した場合、クライアントは別の認証メカニズムを試したり、別の認証コマンドを発行したりすることにより（または他のPOP3認証メカニズムのいずれかを使用して）異なる資格情報を提示することができます。同様に、サーバーは、クライアントが認証コマンドを発行していないかのように動作する必要があります。
To ensure interoperability, client and server implementations of this extension MUST implement the PLAIN SASL mechanism [RFC4616] running over TLS [RFC2595].
相互運用性を確保するために、この拡張機能のクライアントとサーバーの実装は、TLS [RFC2595]を介して実行されるプレーン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コマンドがTLSセッションのネゴシエートに使用されていない限り、プレーンテキストパスワードメカニズムを宣伝または許可しない構成を実装する必要があります（[RFC2595]を参照）。RFC 4616で説明されているように、この構成はデフォルトの構成である必要があります。TLSセッションでプレーンテキストパスワードメカニズムを使用する前に、クライアントの実装は、RFC 2595、セクション2.4で要求される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、アルファ、および桁は[RFC4234]からインポートされます。SASL-MECHルールは[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-command = "auth" sp sasl-mech [sp initial-response] *（crlf [base64]）[crlf cancel-response] crlf
initial-response = base64 / "="
cancel-response = "*"
cancel-response = "*"
base64 = base64-terminal / ( 1*(4base64-CHAR) [base64-terminal] )
base64 = base64ターミナル /（1*（4base64-char）[base64ターミナル]）
base64-char = ALPHA / DIGIT / "+" / "/"
;; Case-sensitive
base64-terminal = (2base64-char "==") / (3base64-char "=")
continue-req = "+" SP [base64] CRLF
継続req = "" sp [base64] crlf
Additionally, the ABNF specified in [RFC2449] is updated as follows:
さらに、[RFC2449]で指定されたABNFは次のように更新されます。
response =/ continue-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://www.iana.org/assignments/pop3-extension-mechanism（pop3拡張レジストリ）、およびhttp：// wwwの[RFC1734]の代わりにこのRFCを参照するようにサイトを更新しました。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.
著者は、John Myers、Randall Gellens、Chris Newman、Laurence Lundblade、およびRFC 1734およびRFC 2554へのその他の貢献者の貢献を認めたいと考えています。
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.
著者はまた、ケン・マーチソン、ランドール・ゲレンズ、アレクセイ・メルニコフ、マーク・クリスピン、アルント・ガルブランドセン、リサ・デュッセル、フランク・エラーマン、およびフィリップ・グンテルのレビューに感謝したいと思います。
10. Changes From RFC 1734, RFC 2449.
10. RFC 1734、RFC 2449からの変更。
1. Updated references to newer versions of various specifications, particularly RFC 4422.
1. さまざまな仕様の新しいバージョン、特にRFC 4422への参照を更新しました。
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への例と参照を使用して、適切な動作と最初のクライアント応答の処理が定義されています。
4. New minimum requirement of support for TLS+PLAIN.
4. TLS Plainのサポートの新しい最小要件。
5. The SASLprep profile SHOULD be used to prepare authorization identities.
5. SASLPREPプロファイルは、承認のアイデンティティを準備するために使用する必要があります。
6. Clarify that the TLS encoding should be applied after any encoding applied by SASL security layers.
6. SASLセキュリティレイヤーによって適用されたエンコード後にTLSエンコードを適用する必要があることを明確にします。
7. Note that the mechanism list can change after STLS.
7. メカニズムリストはSTLS後に変更できることに注意してください。
8. Explicitly mention that "=" means a zero-length initial response.
8. 「=」はゼロの長さの初期応答を意味することを明示的に言及しています。
9. Note that POP3 doesn't allow additional data to be sent with +OK.
9. POP3では、追加データをOKで送信できないことに注意してください。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939] Myers、J。およびM. Rose、「郵便局プロトコル -バージョン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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998.
[RFC2449] Gellens、R.、Newman、C。、およびL. Lundblade、「Pop3拡張メカニズム」、RFC 2449、1998年11月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595] Newman、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] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、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.
[RFC4234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A.、ed。、およびK. Zeilenga、ed。、「Simple Authentication and Security Layer（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.、ed。、「The Plain Simple Authentication and Security Layer（SASL）メカニズム」、RFC 4616、2006年8月。
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[RFC1734] Myers、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Melnikov、A.、ed。、 "The Kerberos V5（" GSSAPI "）シンプルな認証とセキュリティ層（SASL）メカニズム、RFC 4752、2006年11月。
Authors' Addresses
著者のアドレス
Robert Siemborski Google, Inc. 1600 Ampitheatre Parkway Mountain View, CA 94043
Robert Siemborski Google、Inc。1600 Ampitheatre Parkway Mountain View、CA 94043
Phone: +1 650 623 6925
EMail: robsiemb@google.com
Abhijit Menon-Sen Oryx Mail Systems GmbH
Abhijit Menon-Sen Oryx Mail Systems Gmbh
EMail: ams@oryx.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。