トップページ - 翻訳ドキュメント - RFC 5034
原文:ftp://ftp.rfc-editor.org/in-notes/rfc5034.txt
原文との対訳として読みたい方へ:このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
サイト内関連リンク:RFC 1939 POP3、RFC 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 からの変更点
-
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 プロファイルが使用されるべきである(SHOULD)。
-
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 と共に追加情報を送信することを許可しないことが明記された。
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 によって提供されている。
トップページ - 翻訳ドキュメント - RFC 5034