原文:ftp://ftp.rfc-editor.org/in-notes/rfc5034.txt
原文との対訳として読みたい方へ:このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。


サイト内関連リンク:RFC 1939 POP3RFC 4422 SASL



Network Working Group
Request for Comments: 5034
Obsoletes: 1734
Updates: 2449
Category: Standards Track
R. Siemborski
Google, Inc.
A. Menon-Sen
Oryx Mail Systems GmbH
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. この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況については "Internet Official Protocol Standards" (STD 1)を参照してほしい。この文書の配布に制限はない。

Copyright Notice 著作権情報

Copyright (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 の概要を定義する。この拡張により PO3 クライアントは、サーバーに認証メカニズムを提示し、認証プロトコル交換を実行し、オプションでそのセッション中の後続のプロトコル対話のためのセキュリティレイヤを交渉することが可能となる。

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 に含まれる情報を更新する。

1. Introduction 1. 導入

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 実装を作成するには、少なくとも 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] の情報を統合することを試みる。さらに、必要に応じて過去の仕様を明確化することも目標とする。

2. Conventions Used in This Document 2. この文書で使用される慣例

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", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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] で定義される。

3. The SASL Capability 3. SASL 能力

This section supersedes the definition of the SASL Capability in section 6.3 of [RFC2449]. このセクションは、[RFC2449] のセクション 6.3 における SASL 能力の定義を置き換えるものである。

CAPA tag: CAPA タグ:
SASL
Arguments: 引数:
Supported SASL Mechanisms サポートされる SASL メカニズム
Added commands: 追加されるコマンド:
AUTH
Standard commands affected: 影響を受ける標準コマンド:
None なし
Announced states / possible differences: 告知される状態 / 起こり得る差異:
both / 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 機能により、SASL 交渉([RFC4422] で定義されている)を開始するための AUTH コマンド(セクション 4 で定義されている)の使用が可能になる。この 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 コマンドを試みるべきではない(SHOULD NOT)。そのような状況でクライアントが AUTH コマンドを試みた場合、クライアントは初期レスポンスパラメータを提供してはならない(MST NOT)([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] 参照)の成功後に変化してもよい(MAY)。ただし [RFC2449] で要求されている通り、AUTH コマンドが完了した後でも実装は引き続き SASL 能力を含まなければならない(MUST)(それ以上 AUTH コマンドが発行されない可能性があるとしてもである)。
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: .
    

4. The AUTH Command 4. AUTH コマンド

AUTH mechanism [initial-response]
Arguments: 引数:
mechanism: A string identifying a SASL authentication mechanism. 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. initial-response: [RFC4422] のセクション 3 で定義されている通りの、オプションの初期クライアントレスポンス。これが提示される場合、Base64([RFC4648] のセクション 4 で規定されている)でエンコードされるか、空の初期レスポンスを表す単一文字 "=" だけで構成されなければならない(MUST)。
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 コマンドが成功した後の別の AUTH コマンドを、サーバーは -ERR リプライによって拒否しなければならない(MUST)。
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 交換を行う。オプションで、このセッションの後続のプロトコル対話のためのセキュリティレイヤの交渉も行う。要求された認証メカニズムをサポートしないサーバーは、その AUTH コマンドを -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. サーバーチャレンジは "+" で始まり、空白一文字と Base64([RFC4648] のセクション 4 で規定されている)でエンコードされた文字列とが続く 1 行として送信される。この行には BASE64 エンコードされたチャレンジ以外の文字が含まれてはならない(MUST NOT)。
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 エンコードされた 1 行の文字列から構成される。クライアントが認証交換を中止したい場合、単独の "*" から成る 1 行を送信する。そのような応答を受信したサーバーは、-ERR リプライの送信によってその AUTH コマンドを拒否しなければならない(MUST)。
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 コマンドのオプションの引数 initial-response は、初期クライアントレスポンスをサポートする認証メカニズムを使用する場合のやり取りを一往復省略するために使用される。初期レスポンスが省略されており、かつ選択されたメカニズムが初期クライアントレスポンスを必要とする場合、[RFC4422] のセクション 3 で定義されているように、サーバーは空のチャレンジを発行して処理を継続しなければならない(MUST)。POP3 における空のサーバーチャレンジは、"+" とそれに続く空白一文字だけの行として定義される。この行には他のデータが含まれてはならない(MUST NOT)。
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]). 初期クライアントレスポンスのために、単一コマンドの長さに 255 オクテットの制限([RFC2449] のセクション 4 で定義されている)を適用する。初期レスポンスを指定すると AUTH コマンドがこの制限を越える場合、クライアントは initial-response を使用してはならない(MUST)(代わりに [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. クライアントが長さゼロの初期レスポンスを送信する必要がある場合、単一の等号("=") としてレスポンスを送信しなければならない(MUST)。これは、レスポンスを提示するが、データを含まないことを表す。
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 コマンドに対して、クライアントが initial-response を使用した場合、サーバーはその AUTH コマンドを -ERR リプライによって拒否しなければならない(MUST)。
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 デコードできなかった場合、サーバーはその AUTH コマンドを -ERR リプライによって拒否しなければならない(MUST)。クライアントがサーバーチャレンジのいずれかを Base64 デコードできなかった場合、クライアントは "*" のレスポンスを使用してその認証を中止しなければならない(MUST)。特にサーバーとクライアントは、Base64 のアルファベットに明示的に許されていない文字を(無視ではなく)拒否しなければならない(MUST)し、文字列の末尾以外にパディング文字('=')を含む Base64 文字列を拒否しなければならない(MUST)(例えば "=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 文字列は任意の長さであってよい。クライアントとサーバーは、サポートする認証メカニズムによって生成されるエンコードされた最大長のチャレンジとレスポンスとを扱えなければならない(MUST)。この要求事項は、クライアントまたはサーバーがそのプロトコル実装の別の部分で課されるであろう行の長さの制限から独立したものである。
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. サーバーがクライアントを認証できない場合、サーバーはその AUTH コマンドを -ERR リプライによって拒否しなければならない。クライアントが交換に成功すると、サーバーは +OK リプライを返す。また成功すると、POP3 セッションは TRANSCTION 状態に入る。
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 アルゴリズム([RFC3454] 参照)の SASLprep プロファイル([RFC4013] 参照) を使用するべきである(SHOULD)。権限アイデンティティの比較に失敗するか、(空文字列として送信されていないのに)結果として空の文字列になった場合、サーバーはその認証に失敗しなければならない(MUST)。
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 交渉そのものから取得した知識を除く)を破棄しなければならない(MUST)。同じようにクライアントも、サーバーから取得したすべての知識(利用可能な POP3 サービス拡張の一覧など)を破棄しなければならない(MUST)。
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.) Transport Layer Security (TLS) ([RFC4346] 参照) と SASL セキュリティレイヤとを両方採用する場合、データ送信時には、SASL のエンコードの後に TLS のエンコードが適用されなければならない(MUST)。([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 のこのプロトコルのプロファイルが特定するサービス名は、"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. AUTH コマンドが失敗した場合、クライアントは別の認証メカニズムを試みたり、別の AUTH コマンドを発行する(または別の POP3 認証メカニズムのひとつを使用する)ことで異なる証明書を提示したりしてよい。同じくサーバーは、クライアントが AUTH コマンドを発行しなかったかのように振る舞わなければならない(MUST)。
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] を実装しなければならない(MUST)。
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. サーバー実装は、TLS セッションの交渉に STLS コマンドが使用された場合([RFC2595] 参照)を除き、平文パスワードのメカニズムを通知しないか、または許可しない設定を実装しなければならない(MUST)。RFC 4616 で説明されている通り、この設定がデフォルトであるべきである(SHOULD)。TLS セッション上で平文パスワードのメカニズムを使用する前に、クライアント実装は RFC 2595 のセクション 2.4 で要求されている通りに TLS サーバーの証明書を検証しなければならない(MUST)。クライアントおよびサーバーの実装は、平文パスワードを送信しない SASL メカニズム、例えば GSSAPI [RFC4752] メカニズムなどを実装するべきである(SHOULD)。

5. Formal Syntax 5. 公式構文

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-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. 特に注記がない限り、すべてのアルファベットは大文字・小文字を区別されない。トークン文字列を定義するのに使用されている大文字・小文字は編集上の明瞭性のために過ぎない。実装は大文字・小文字を区別せずにこれらの文字列を受け入れなければならない(MUST)。

      auth-command     = "AUTH" SP sasl-mech [SP initial-response]
                         *(CRLF [base64]) [CRLF cancel-response] CRLF

      initial-response = base64 / "="

      cancel-response  = "*"

      base64           = base64-terminal /
                         ( 1*(4base64-CHAR) [base64-terminal] )

      base64-char      = ALPHA / DIGIT / "+" / "/"
                         ;; Case-sensitive

      base64-terminal  = (2base64-char "==") / (3base64-char "=")

      continue-req     = "+" SP [base64] CRLF

   Additionally, the ABNF specified in [RFC2449] is updated as follows:

      response         =/ continue-req
      auth-command     = "AUTH" SP sasl-mech [SP initial-response]
                         *(CRLF [base64]) [CRLF cancel-response] CRLF

      initial-response = base64 / "="

      cancel-response  = "*"

      base64           = base64-terminal /
                         ( 1*(4base64-CHAR) [base64-terminal] )

      base64-char      = ALPHA / DIGIT / "+" / "/"
                         ;; Case-sensitive

      base64-terminal  = (2base64-char "==") / (3base64-char "=")

      continue-req     = "+" SP [base64] CRLF

   加えて、[RFC2449] で定義されていた ABNF は次のように更新された:

      response         =/ continue-req

6. Examples 6. 例

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
        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 交渉が開始され、以降のコマンドは TLS レイヤにより保護さ
            れる)
        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
            (TLS 交渉が開始され、以降のコマンドは TLS レイヤにより保護さ
            れる)
        C: CAPA
        S: +OK List of capabilities follows
        S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
        S: IMPLEMENTATION BlurdyBlurp POP3 server
        S: .
        C: AUTH PLAIN
            (次の行の '+' に続いて空白文字があることに注意してほしい)
        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

7. Security Considerations 7. セキュリティ考察

Security issues are discussed throughout this document. セキュリティ問題はこの文書全体を通して議論されている。

8. IANA Considerations 8. IANA 考察

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.iana.org/assignments/gssapi-service-names (GSSAPI/SASL サービス名レジストリ)の両サイトを、[RFC1734] に代わり本 RFC を参照するように更新した。

9. Acknowledgments 9. 謝辞

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 に対する John Myers、 Randall Gellens、 Chris Newman、 Laurence 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. また著者は、この文書をレビューしてくれた Ken Murchison、 Randall Gellens、 Alexey Melnikov、 Mark Crispin、 Arnt Gulbrandsen、 Lisa Dusseault、 Frank Ellermann、 Philip Guenther に感謝する。

10. Changes From RFC 1734, RFC 2449. 10. RFC 1734・RFC 2449 からの変更点

11. Normative References 11. 引用資料

[RFC1939]
Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2449]
Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998.
[RFC2595]
Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC3454]
Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC4013]
Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4234]
Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4422]
Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4648]
Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4616]
Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.

12. Informative References 12. 参考資料

[RFC1734]
Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[RFC3206]
Gellens, R., "The SYS and AUTH POP Response Codes", RFC 3206, February 2002.
[RFC4346]
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4752]
Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.

Authors' Addresses 著者の連絡先

   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

   EMail: ams@oryx.com

Full Copyright Statement

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

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.

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.

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.

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.

Acknowledgement 謝辞

Funding for the RFC Editor function is currently provided by the Internet Society. RFC 編集者の活動資金は、現在 Internet Society によって提供されている。