Network Working Group C. Newman
Request for Comments: 2595 Innosoft
Category: Standards Track June 1999
Using TLS with IMAP, POP3 and ACAP
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 Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
The TLS protocol (formerly known as SSL) provides a way to secure an application protocol from tampering and eavesdropping. The option of using such security is desirable for IMAP, POP and ACAP due to common connection eavesdropping and hijacking attacks [AUTH]. Although advanced SASL authentication mechanisms can provide a lightweight version of this service, TLS is complimentary to simple authentication-only SASL mechanisms or deployed clear-text password login commands.
（以前のSSLとして知られている）TLSプロトコルが改ざんや盗聴からアプリケーションプロトコルを確保する方法を提供します。このようなセキュリティを使用するオプションが原因共通接続盗聴と乗っ取り攻撃[AUTH]にIMAP、POPおよびACAPのために望ましいです。高度なSASL認証メカニズムは、このサービスの軽量バージョンを提供することができるが、TLSは簡単な認証のみのSASLメカニズムや展開クリアテキストパスワードログインコマンドに無料です。
Many sites have a high investment in authentication infrastructure (e.g., a large database of a one-way-function applied to user passwords), so a privacy layer which is not tightly bound to user authentication can protect against network eavesdropping attacks without requiring a new authentication infrastructure and/or forcing all users to change their password. Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. (Note there is a separate RFC for the STARTTLS command in SMTP [SMTPTLS].)
多くのサイトでは、認証インフラストラクチャでの高い投資を持っている（例えば、ユーザパスワードに適用される一方向関数の大規模データベース）しっかりと新しいを必要とせず、ネットワーク盗聴攻撃を防ぐことができ、ユーザ認証にバインドされていないので、プライバシー層、認証インフラストラクチャおよび/またはそのパスワードを変更するすべてのユーザーを強制的に。このようなサイトは、TLS暗号化と組み合わせて簡易パスワード認証を希望することを認識し、この仕様は、このようなACAPやSMTPなどの単純なパスワード認証コマンドが不足しているプロトコルで使用するためにPLAIN SASLメカニズムを定義します。 （SMTP [SMTPTLS]でSTARTTLSコマンドの別々のRFCがあることに注意してください。）
There is a strong desire in the IETF to eliminate the transmission of clear-text passwords over unencrypted channels. While SASL can be used for this purpose, TLS provides an additional tool with different deployability characteristics. A server supporting both TLS with simple passwords and a challenge/response SASL mechanism is likely to interoperate with a wide variety of clients without resorting to unencrypted clear-text passwords.
暗号化されていないチャネルを介してクリアテキストのパスワードの送信を排除するためにIETFでの強い要望があります。 SASLは、この目的のために使用することができるが、TLSは、異なる展開性特性を有する追加のツールを提供します。簡単なパスワードやチャレンジ/レスポンスでSASLメカニズムを両方TLSをサポートするサーバは、暗号化されていないクリアテキストのパスワードに頼ることなく、クライアントの多種多様と相互運用する可能性があります。
The STARTTLS command rectifies a number of the problems with using a separate port for a "secure" protocol variant. Some of these are mentioned in section 7.
STARTTLSコマンドは、「安全な」プロトコルバリアントに対して別々のポートを使用すると多くの問題を整流します。これらのいくつかは、セクション7に記載されています。
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
キーワード「REQUIRED」、「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」RFCsにおける使用のためのキーワード」で説明したように、このドキュメントの「MAY」、および「OPTIONAL」は解釈されるべきです要件レベル」[KEYWORDS]を示すために。
Terms related to authentication are defined in "On Internet Authentication" [AUTH].
認証に関連する用語は、「オンインターネット認証」[AUTH]で定義されています。
Formal syntax is defined using ABNF [ABNF].
正式な構文はABNF [ABNF]を使用して定義されます。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
実施例では、「C：」および「S：」はそれぞれクライアントとサーバから送信されたラインを示します。
The following requirements apply to all implementations of the STARTTLS extension for IMAP, POP3 and ACAP.
次の要件は、IMAP、POP3およびACAPのためのSTARTTLS拡張のすべての実装に適用されます。
Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite is REQUIRED. This is important as it assures that any two compliant implementations can be configured to interoperate.
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS]暗号スイートの実装が必要となります。それは任意の二つの準拠する実装は、相互運用するように構成することができることを保証するので、これは重要です。
All other cipher suites are OPTIONAL.
他のすべての暗号スイートはオプションです。
Both clients and servers SHOULD have a privacy operational mode which refuses authentication unless successful activation of an encryption layer (such as that provided by TLS) occurs prior to or at the time of authentication and which will terminate the connection if that encryption layer is deactivated. Implementations are encouraged to have flexability with respect to the minimal encryption strength or cipher suites permitted. A minimalist approach to this recommendation would be an operational mode where the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to permitting authentication.
クライアントとサーバの両方が（例えばTLSによって提供されるような）暗号化層の成功活性化が前または認証とどのよう暗号化層が非アクティブ化されている場合、接続を終了します時には発生しない限り、認証を拒否し、プライバシー動作モードを持っているべきです。実装は許可され、最小限の暗号化の強度や暗号スイートに関してフレキサビリティを持つことが奨励されています。この勧告にミニマリストアプローチはTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA暗号スイートは、事前認証を可能に必須である動作モードであろう。
Clients MAY have an operational mode which uses encryption only when it is advertised by the server, but authentication continues regardless. For backwards compatibility, servers SHOULD have an operational mode where only the authentication mechanisms required by the relevant base protocol specification are needed to successfully authenticate.
クライアントはそれがサーバによってアドバタイズされた場合にのみ、暗号化を使用して動作モードを持っているかもしれませんが、認証にかかわらず続けています。後方互換性のために、サーバは、関連する基本プロトコル仕様で必要とされる唯一の認証メカニズムが正常に認証するために必要な動作モードを持っているべきです。
Clients and servers which implement STARTTLS MUST be configurable to refuse all clear-text login commands or mechanisms (including both standards-track and nonstandard mechanisms) unless an encryption layer of adequate strength is active. Servers which allow unencrypted clear-text logins SHOULD be configurable to refuse clear-text logins both for the entire server, and on a per-user basis.
STARTTLSを実装するクライアントとサーバーは、十分な強度の暗号化層がアクティブでない限り、すべてクリアテキストログインコマンドまたは（スタンダードトラックおよび標準外のメカニズムの両方を含む）のメカニズムを拒否するために構成可能でなければなりません。暗号化されていないクリアテキストログインはサーバ全体のために、そしてユーザーごとに両方クリアテキストログインを拒否するように設定すべきである（SHOULD）許可サーバー。
During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules:
man-in-the-middle攻撃を防ぐために、サーバ証明書メッセージに提示されるTLSネゴシエーション中に、クライアントはサーバーのIDに対するサーバーのホスト名のその理解をチェックしなければなりません。マッチングは、これらの規則に従って実行されます。
- The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
- クライアントはサーバ証明書で表したように、サーバー名と比較する値として接続を開くために使用されるサーバーのホスト名を使用しなければなりません。クライアントは、安全でないリモートソース（例えば、安全でないDNSルックアップ）に由来するサーバのホスト名のいずれかの形式を使用してはなりません。 CNAMEの正規化が行われていません。
- If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
- 型のdNSNameのsubjectAltName拡張が証明書に存在している場合、それはサーバのアイデンティティの源として使用する必要があります。
- Matching is case-insensitive.
- マッチングは大文字と小文字を区別しません。
- A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.
- A「*」ワイルドカード文字は、証明書内の一番左の名前の成分として使用することができます。たとえば、* .example.comとはa.example.com、foo.example.comなどと一致しますが、example.comが一致しません。
- If the certificate contains multiple names (e.g. more than one dNSName field), then a match with any one of the fields is considered acceptable.
- 証明書が複数の名前（例えば、複数のdNSNameフィールド）が含まれている場合、その後のフィールドのいずれかとの一致が許容されると考えられます。
If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate the server's identity is suspect.
マッチが失敗した場合、クライアントは、明示的なユーザの確認を求める、または接続を終了し、サーバのアイデンティティが疑わしいであることを示すべきです。
Both the client and server MUST check the result of the STARTTLS command and subsequent TLS negotiation to see whether acceptable authentication or privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document.
クライアントとサーバの両方が許容可能な認証やプライバシーが達成されたかどうかを確認するためにSTARTTLSコマンドとそれに続くTLS交渉の結果をチェックしなければなりません。完全にこのステップを無視すると、セキュリティのためにTLSを使用して無効化します。許容可能な認証やプライバシーが達成されたかどうかについての決定がローカルに作られ、実装依存であり、この文書の範囲を超えています。
When the TLS extension is present in IMAP, "STARTTLS" is listed as a capability in response to the CAPABILITY command. This extension adds a single command, "STARTTLS" to the IMAP protocol which is used to begin a TLS negotiation.
TLS拡張子がIMAPに存在する場合、「STARTTLSは」CAPABILITYコマンドに応答して機能としてリストされています。この拡張は、TLSネゴシエーションを開始するために使用されているIMAPプロトコルに単一のコマンド、「STARTTLS」を追加します。
Arguments: none
引数：なし
Responses: no specific responses for this command
回答：このコマンドのための特定の応答がありません
Result: OK - begin TLS negotiation BAD - command unknown or arguments invalid
結果：OK - TLSネゴシエーションBADを開始 - コマンド不明または無効な引数
A TLS negotiation begins immediately after the CRLF at the end of the tagged OK response from the server. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete.
TLSネゴシエーションは、サーバからのタグ付きOK応答の最後のCRLFの直後に開始されます。クライアントがSTARTTLSコマンドを発行すると、サーバーの応答が見られるまでには、さらにコマンドを発行してはならないとTLSネゴシエーションが完了しています。
The STARTTLS command is only valid in non-authenticated state. The server remains in non-authenticated state, even if client credentials are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STARTTLS command are not required to support the EXTERNAL mechanism.
STARTTLSコマンドは非認証状態でのみ有効です。サーバーは、クライアントの資格情報は、TLSネゴシエーション中に供給されていても、非認証状態のまま。 SASL [SASL]外部機構は、TLSクライアントの資格情報が正常に交換された後の認証に使用することができるが、STARTTLSコマンドをサポートするサーバは、外部機構をサポートする必要はありません。
Once TLS has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS.
TLSが開始された後、クライアントは、サーバの機能について、キャッシュされた情報を捨てなければなりませんし、CAPABILITYコマンドを再発行する必要があります。これはSTARTTLSに先立って機能のリストを変更man-in-the-middle攻撃から保護するために必要です。サーバがSTARTTLSの後に別の機能を通知してもよい（MAY）。
The formal syntax for IMAP is amended as follows:
次のようにIMAPのための正式な構文が改正されています。
command_any =/ "STARTTLS"
command_any = / "STARTTLS"
Example: C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED S: a001 OK CAPABILITY completed C: a002 STARTTLS S: a002 OK Begin TLS negotiation now <TLS negotiation, further commands are under TLS layer> C: a003 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL S: a003 OK CAPABILITY completed C: a004 LOGIN joe password S: a004 OK LOGIN completed
例：C：A001 CAPABILITYのS：* CAPABILITY IMAP4rev1のSTARTTLS LOGINDISABLED S：A001 OK CAPABILITY完了C：STARTTLSのS A002：A003 CAPABILITYのS：* CAPABILITY A002 OKになりましたTLSネゴシエーションを開始しますC <TLSネゴシエーションを、さらにコマンドはTLS層の下にあります> IMAP4rev1 AUTH = EXTERNAL S：A004 LOGINのジョー・パスワードS：完成A004 OK LOGIN Cを完成A003 OK CAPABILITY
The current IMAP protocol specification (RFC 2060) requires the implementation of the LOGIN command which uses clear-text passwords. Many sites may choose to disable this command unless encryption is active for security reasons. An IMAP server MAY advertise that the LOGIN command is disabled by including the LOGINDISABLED capability in the capability response. Such a server will respond with a tagged "NO" response to any attempt to use the LOGIN command.
現在のIMAPプロトコル仕様（RFC 2060）クリアテキストのパスワードを使用するLOGINコマンドの実装を必要とします。多くのサイトでは、暗号化はセキュリティ上の理由から、アクティブでない限り、このコマンドを無効にすることができます。 IMAPサーバは、LOGINコマンドは、能力応答でLOGINDISABLED機能を含むことによって無効になっていることを宣伝してもよい（MAY）。このようなサーバは、LOGINコマンドを使用しようとするとタグ付けされた「NO」応答で応答します。
An IMAP server which implements STARTTLS MUST implement support for the LOGINDISABLED capability on unencrypted connections.
STARTTLSを実装IMAPサーバは、暗号化されていない接続上のLOGINDISABLED機能のサポートを実装しなければなりません。
An IMAP client which complies with this specification MUST NOT issue the LOGIN command if this capability is present.
この機能が存在している場合は、この仕様に準拠IMAPクライアントは、LOGINコマンドを発行してはいけません。
This capability is useful to prevent clients compliant with this specification from sending an unencrypted password in an environment subject to passive attacks. It has no impact on an environment subject to active attacks as a man-in-the-middle attacker can remove this capability. Therefore this does not relieve clients of the need to follow the privacy mode recommendation in section 2.2.
この機能は、受動的攻撃への環境下では暗号化されていないパスワードを送信からこの仕様に準拠したクライアントを防ぐのに便利です。これは、この機能を削除することができなman-in-the-middle攻撃などのアクティブな攻撃を受け、環境に与える影響はありません。したがって、これはセクション2.2でプライバシーモードの勧告に従う必要のクライアントを緩和しません。
Servers advertising this capability will fail to interoperate with many existing compliant IMAP clients and will be unable to prevent those clients from disclosing the user's password.
この機能を広告するサーバーは、多くの既存の対応のIMAPクライアントと相互運用に失敗し、ユーザーのパスワードの開示から、それらのクライアントを防ぐことができません。
The POP3 STARTTLS extension adds the STLS command to POP3 servers. If this is implemented, the POP3 extension mechanism [POP3EXT] MUST also be implemented to avoid the need for client probing of multiple commands. The capability name "STLS" indicates this command is present and permitted in the current state.
POP3 STARTTLS拡張は、POP3サーバにSTLSコマンドが追加されます。これが実装されている場合、POP3拡張メカニズムは、[POP3EXT]また、複数のコマンドのプロービングクライアントの必要性を回避するために実装しなければなりません。機能名「STLSは、」このコマンドが存在し、現在の状態で許可されていることを示します。
STLS
STLS
Arguments: none
引数：なし
Restrictions: Only permitted in AUTHORIZATION state.
制限事項：のみ許可ステートで許可。
Discussion: A TLS negotiation begins immediately after the CRLF at the end of the +OK response from the server. A -ERR response MAY result if a security layer is already active. Once a client issues a STLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete.
考察：TLSネゴシエーションがサーバーからの+ OK応答の最後のCRLFの直後に開始されます。セキュリティ層が既にアクティブな場合-ERR応答が生じる可能性があります。クライアントはSTLSコマンドを発行すると、サーバーの応答が見られるまでには、さらにコマンドを発行してはならないとTLSネゴシエーションが完了しています。
The STLS command is only permitted in AUTHORIZATION state
and the server remains in AUTHORIZATION state, even if
client credentials are supplied during the TLS negotiation.
The AUTH command [POP-AUTH] with the EXTERNAL mechanism
[SASL] MAY be used to authenticate once TLS client
credentials are successfully exchanged, but servers
supporting the STLS command are not required to support the
EXTERNAL mechanism.
Once TLS has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPA command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STLS. The server MAY advertise different capabilities after STLS.
TLSが開始された後、クライアントは、サーバ機能に関するキャッシュされた情報を捨てなければなりませんし、CAPAコマンドを再発行すべきです。これは、従来STLSへの機能のリストを変更man-in-the-middle攻撃から保護するために必要です。サーバはSTLSの後に別の機能を通知してもよい（MAY）。
Possible Responses: +OK -ERR
可能な応答：+ OK -ERR
Examples: C: STLS S: +OK Begin TLS negotiation <TLS negotiation, further commands are under TLS layer> ... C: STLS S: -ERR Command not permitted when TLS active
例：C：STLSのS：+ OK TLS交渉開始<TLSネゴシエーションを、さらにコマンドはTLS層の下にある> ... C：STLSのS：TLSアクティブ-ERRコマンドは許されません
When the TLS extension is present in ACAP, "STARTTLS" is listed as a capability in the ACAP greeting. No arguments to this capability are defined at this time. This extension adds a single command, "STARTTLS" to the ACAP protocol which is used to begin a TLS negotiation.
TLS拡張子がACAP中に存在する場合、「STARTTLS」がACAP挨拶の機能として表示されています。この機能には引数は現時点で定義されていません。この拡張は、TLSネゴシエーションを開始するために使用されるACAPプロトコルに単一のコマンド、「STARTTLS」を追加します。
Arguments: none
引数：なし
Responses: no specific responses for this command
回答：このコマンドのための特定の応答がありません
Result: OK - begin TLS negotiation BAD - command unknown or arguments invalid
結果：OK - TLSネゴシエーションBADを開始 - コマンド不明または無効な引数
A TLS negotiation begins immediately after the CRLF at the end of the tagged OK response from the server. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete.
TLSネゴシエーションは、サーバからのタグ付きOK応答の最後のCRLFの直後に開始されます。クライアントがSTARTTLSコマンドを発行すると、サーバーの応答が見られるまでには、さらにコマンドを発行してはならないとTLSネゴシエーションが完了しています。
The STARTTLS command is only valid in non-authenticated state. The server remains in non-authenticated state, even if client credentials are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STARTTLS command are not required to support the EXTERNAL mechanism.
STARTTLSコマンドは非認証状態でのみ有効です。サーバーは、クライアントの資格情報は、TLSネゴシエーション中に供給されていても、非認証状態のまま。 SASL [SASL]外部機構は、TLSクライアントの資格情報が正常に交換された後の認証に使用することができるが、STARTTLSコマンドをサポートするサーバは、外部機構をサポートする必要はありません。
After the TLS layer is established, the server MUST re-issue an untagged ACAP greeting. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The client MUST discard cached capability information and replace it with the information from the new ACAP greeting. The server MAY advertise different capabilities after STARTTLS.
TLS層が確立された後、サーバはタグなしACAP挨拶を再発行しなければなりません。これはSTARTTLSに先立って機能のリストを変更man-in-the-middle攻撃から保護するために必要です。クライアントは、キャッシュされた能力情報を破棄して新しいACAP挨拶からの情報とそれを交換する必要があります。サーバがSTARTTLSの後に別の機能を通知してもよい（MAY）。
The formal syntax for ACAP is amended as follows:
次のようにACAPのための正式な構文が改正されています。
command_any =/ "STARTTLS"
command_any = / "STARTTLS"
Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a002 STARTTLS S: a002 OK "Begin TLS negotiation now" <TLS negotiation, further commands are under TLS layer> S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
例：S：* ACAP（SASL "CRAM-MD5"）（STARTTLS）C：A002 STARTTLSのS：* ACAP（SASL「CRAM：A002 OK "今TLS交渉開始" S <TLSネゴシエーションを、さらにコマンドはTLS層の下にあります> -MD5" "PLAIN" "外部"）
Clear-text passwords are simple, interoperate with almost all existing operating system authentication databases, and are useful for a smooth transition to a more secure password-based authentication mechanism. The drawback is that they are unacceptable for use over an unencrypted network connection.
クリアテキストのパスワードは、ほぼすべての既存のオペレーティングシステムの認証データベースとの相互運用性、シンプルであり、より安全なパスワードベースの認証メカニズムへの円滑な移行のために便利です。欠点は、暗号化されていないネットワーク接続を介して使用するために受け入れられないということです。
This defines the "PLAIN" SASL mechanism for use with ACAP and other protocols with no clear-text login command. The PLAIN SASL mechanism MUST NOT be advertised or used unless a strong encryption layer (such as the provided by TLS) is active or backwards compatibility dictates otherwise.
これは明確なテキストloginコマンドでACAPと他のプロトコルで使用するために「PLAIN」SASLメカニズムを定義します。 PLAIN SASL機構は、アドバタイズまたは強力な暗号化層ない限り（例えば、TLSによって提供されるように）使用される活性であるか、または下位互換性が別に指示してはいけません。
The mechanism consists of a single message from the client to the server. The client sends the authorization identity (identity to login as), followed by a US-ASCII NUL character, followed by the authentication identity (identity whose password will be used), followed by a US-ASCII NUL character, followed by the clear-text password. The client may leave the authorization identity empty to indicate that it is the same as the authentication identity.
メカニズムは、クライアントからサーバへの単一のメッセージで構成されています。クライアントはclear-続くUS-ASCII NUL文字が続く認証アイデンティティ（パスワードが使用されるアイデンティティ）、続くUS-ASCII NUL文字、続く、認可ID（としてログインするアイデンティティ）を送信しますテキストのパスワード。クライアントは、認証アイデンティティと同じであることを示すために、空の認証アイデンティティを残すことができます。
The server will verify the authentication identity and password with the system authentication database and verify that the authentication credentials permit the client to login as the authorization identity. If both steps succeed, the user is logged in.
サーバーは、システムの認証データベースで認証IDとパスワードを確認し、認証資格が認可IDとしてログインするクライアントを許可していることを確認します。両方のステップが成功した場合、ユーザーがログインしています。
The server MAY also use the password to initialize any new authentication database, such as one suitable for CRAM-MD5 [CRAM-MD5].
サーバはまた、CRAM-MD5 [CRAM-MD5]に適したものとして、新しい認証データベースを初期化するためにパスワードを使用するかもしれません。
Non-US-ASCII characters are permitted as long as they are represented in UTF-8 [UTF-8]. Use of non-visible characters or characters which a user may be unable to enter on some keyboards is discouraged.
それらはUTF-8 [UTF-8]で表されているように、非US-ASCII文字は限り許可されています。ユーザーは一部のキーボードで入力することができない可能性が不可視文字または文字の使用は推奨されません。
The formal grammar for the client message using Augmented BNF [ABNF] follows.
増補BNFを使用して、クライアントメッセージの形式文法[ABNF]は、以下。
message = [authorize-id] NUL authenticate-id NUL password authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets password = 1*UTF8-SAFE ; MUST accept up to 255 octets NUL = %x00 UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 UTF8-1 = %x80-BF UTF8-2 = %xC0-DF UTF8-1 UTF8-3 = %xE0-EF 2UTF8-1
メッセージ= [承認-ID]をNULの認証-ID NULパスワード認証-ID = 1 * UTF8-SAFEと、オクテットは、認可-ID = 1 *のUTF8-SAFEを255まで受け入れなければなりません。 255オクテットのパスワード= 1 *のUTF8-SAFEまで受け入れなければなりません。 255オクテットまで受け入れなければならないNUL =％のX00 UTF8-SAFE =％x01-09 /％X0B-0C /％のx0E-7F / UTF8-2 / UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 UTF8- 1 =％X80-BF UTF8-2 =％XC0-DF UTF8-1 UTF8-3 =％xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1 UTF8-5 = %xF8-FB 4UTF8-1 UTF8-6 = %xFC-FD 5UTF8-1
UTF8-4 =％XF0-F7 3UTF8-1 UTF8-5 =％XF8-FB 4UTF8-1 UTF8-6 =％XFC-FD 5UTF8-1
Here is an example of how this might be used to initialize a CRAM-MD5 authentication database for ACAP:
ここでは、これはACAPのためにCRAM-MD5認証データベースを初期化するために使用されるかもしれない方法の例です：
Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) C: a001 AUTHENTICATE "CRAM-MD5" S: + "<1896.697170952@postoffice.reston.mci.net>" C: "tim b913a602c7eda7a495b4e6e7334d3890" S: a001 NO (TRANSITION-NEEDED) "Please change your password, or use TLS to login" C: a002 STARTTLS S: a002 OK "Begin TLS negotiation now" <TLS negotiation, further commands are under TLS layer> S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") C: a003 AUTHENTICATE "PLAIN" {21+} C: <NUL>tim<NUL>tanstaaftanstaaf S: a003 OK CRAM-MD5 password initialized
例：S：* ACAP（SASL "CRAM-MD5"）（STARTTLS）C：A001 AUTHENTICATE "CRAM-MD5" S：+ "<1896.697170952@postoffice.reston.mci.net>" C： "ティムb913a602c7eda7a495b4e6e7334d3890" S： A001 NO（TRANSITION-必要です） "パスワードを変更、またはログインするためにTLSを使用してください" C：A002 STARTTLSのSを：* ACAP（SASL：A002 OKは "今、TLSネゴシエーションを開始します" S <TLS折衝、さらにコマンドはTLS層の下にあります> "CRAM-MD5" "普通" "外部"）C：A003 AUTHENTICATE "プレーン" {21+} C <NUL>ティム<NUL> tanstaaftanstaaf S：初期化A003 OK CRAM-MD5パスワード
Note: In this example, <NUL> represents a single ASCII NUL octet.
注：この例では、<NUL>は、単一のASCII NULオクテットを表します。
Separate "imaps" and "pop3s" ports were registered for use with SSL. Use of these ports is discouraged in favor of the STARTTLS or STLS commands.
独立した「IMAPS」と「POP3S」のポートは、SSLで使用するために登録されました。これらのポートの使用はSTARTTLSまたはSTLSコマンドの賛成で推奨されていません。
A number of problems have been observed with separate ports for "secure" variants of protocols. This is an attempt to enumerate some of those problems.
多くの問題は、プロトコルの「安全な」変種のための別々のポートで観察されています。これは、これらの問題のいくつかを列挙しようとする試みです。
- Separate ports lead to a separate URL scheme which intrudes into the user interface in inappropriate ways. For example, many web pages use language like "click here if your browser supports SSL." This is a decision the browser is often more capable of making than the user.
- 個別のポートが不適切な方法でユーザインタフェースに侵入別個URLスキームにつながります。例えば、多くのウェブページは次のように言語を使用する「ブラウザがSSLをサポートしている場合はこちらをクリックしてください。」これは、ブラウザは、多くの場合、ユーザーよりも、作るより有能である決定です。
- Separate ports imply a model of either "secure" or "not secure." This can be misleading in a number of ways. First, the "secure" port may not in fact be acceptably secure as an export-crippled cipher suite might be in use. This can mislead users into a false sense of security. Second, the normal port might in fact be secured by using a SASL mechanism which includes a security layer. Thus the separate port distinction makes the complex topic of security policy even more confusing. One common result of this confusion is that firewall administrators are often misled into permitting the "secure" port and blocking the standard port. This could be a poor choice given the common use of SSL with a 40-bit key encryption layer and plain-text password authentication is less secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.
- 別々のポートは、「安全な」またはいずれかのモデルを意味するもので、「安全ではないの。」これは、いくつかの方法で誤解を招くことができます。輸出不自由暗号スイートが使用中であるかもしれないように、まず、「安全な」ポートは、実際には許容できる安全ではないかもしれません。これは、誤った安心感にユーザーを欺くことができます。第二に、通常のポートは、実際には、セキュリティの層を含むSASLメカニズムを使用して保護されることがあります。したがって、別のポートの区別がさらに混乱セキュリティポリシーの複雑なトピックになります。この混乱の一つの一般的な結果は、ファイアウォール管理者は、多くの場合、「セキュア」ポートを許可すると、標準のポートをブロックするに誤解されていることです。これは40ビットの鍵暗号化層とプレーンテキストのパスワード認証とSSLの一般的な使用方法与えられたお粗末な選択可能性があり、このようなケルベロス5とGSSAPIのような強いSASLメカニズムよりも安全です。
- Use of separate ports for SSL has caused clients to implement only two security policies: use SSL or don't use SSL. The desirable security policy "use TLS when available" would be cumbersome with the separate port model, but is simple with STARTTLS.
SSLを使用するか、またはSSLを使用しないでください： - SSL用に別のポートを使用すると、唯一の2つのセキュリティ・ポリシーを実装するようにクライアントをもたらしています。望ましいセキュリティポリシーは、「利用可能な場合TLSを使用し、」別のポートモデルと面倒なことが、STARTTLSとシンプルであるだろう。
- Port numbers are a limited resource. While they are not yet in short supply, it is unwise to set a precedent that could double (or worse) the speed of their consumption.
- ポート番号は限られたリソースです。彼らが不足していないが、彼らの消費の速度を倍増（またはより悪い）可能性が先例を設定することは賢明ではありません。
This constitutes registration of the "STARTTLS" and "LOGINDISABLED" IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP].
RFC 2060 [IMAP]のセクション7.2.1によって必要とされるので、これは、「STARTTLS」および「LOGINDISABLED」IMAP機能の登録を構成しています。
The registration for the POP3 "STLS" capability follows:
POP3「STLS」能力のための登録は、次のとおりです。
CAPA tag: STLS Arguments: none Added commands: STLS Standard commands affected: May enable USER/PASS as a side-effect. CAPA command SHOULD be re-issued after successful completion. Announced states/Valid states: AUTHORIZATION state only. Specification reference: this memo
CAPAタグ：STLS引数：なし追加されましたコマンド：STLS標準のコマンドが影響を受ける：副作用としてUSER / PASSを可能にします。 CAPAコマンドが正常に完了した後に再発行する必要があります。発表された状態/有効な状態：のみ許可ステート。仕様参照：このメモ
The registration for the ACAP "STARTTLS" capability follows:
ACAP「STARTTLS」機能のための登録は、次のとおりです。
Capability name: STARTTLS Capability keyword: STARTTLS Capability arguments: none Published Specification(s): this memo Person and email address for further information: see author's address section below
能力名：STARTTLS能力キーワード：STARTTLS能力の引数：なし公開明細書（S）：詳細については、このメモPersonとEメールアドレス：下記の著者のアドレスセクションを参照してください
The registration for the PLAIN SASL mechanism follows:
PLAIN SASLメカニズムのための登録は、次のとおりです。
SASL mechanism name: PLAIN Security Considerations: See section 9 of this memo Published specification: this memo Person & email address to contact for further information: see author's address section below Intended usage: COMMON Author/Change controller: see author's address section below
SASLメカニズム名：PLAINセキュリティの考慮事項：詳細のために連絡するためにこのメモ人とEメールアドレス：このメモ公開された仕様書のセクション9を参照してくださいCOMMON著者/変更コントローラ：下記参照著者のアドレス部意図している用法以下作者のアドレス部を参照してください
TLS only provides protection for data sent over a network connection. Messages transferred over IMAP or POP3 are still available to server administrators and usually subject to eavesdropping, tampering and forgery when transmitted through SMTP or NNTP. TLS is no substitute for an end-to-end message security mechanism using MIME security multiparts [MIME-SEC].
TLSは、ネットワーク接続を介して送信されるデータの保護を提供します。 IMAPやPOP3を介して転送されるメッセージは、SMTPまたはNNTPを透過する際の改ざんや偽造、まだ盗聴の対象サーバー管理者と通常にご利用いただけます。 TLSはMIMEセキュリティマルチパート[MIME-SEC]を使用して、エンドツーエンドのメッセージセキュリティメカニズムに代わるものではありません。
A man-in-the-middle attacker can remove STARTTLS from the capability list or generate a failure response to the STARTTLS command. In order to detect such an attack, clients SHOULD warn the user when session privacy is not active and/or be configurable to refuse to proceed without an acceptable level of security.
man-in-the-middle攻撃者は、能力リストからSTARTTLSを削除するか、STARTTLSコマンドへの失敗応答を生成することができます。そのような攻撃を検出するために、クライアントは、セッションプライバシーがアクティブでない場合、ユーザに警告および/またはセキュリティの許容レベルなしで進行することを拒否するように構成可能であるべきです。
A man-in-the-middle attacker can always cause a down-negotiation to the weakest authentication mechanism or cipher suite available. For this reason, implementations SHOULD be configurable to refuse weak mechanisms or cipher suites.
man-in-the-middle攻撃者は、常に利用可能で、最も弱い認証機構や暗号スイートにダウン交渉を引き起こす可能性があります。このため、実装は弱いメカニズムや暗号スイートを拒否するように設定すべきである（SHOULD）。
Any protocol interactions prior to the TLS handshake are performed in the clear and can be modified by a man-in-the-middle attacker. For this reason, clients MUST discard cached information about server capabilities advertised prior to the start of the TLS handshake.
TLSハンドシェイクの前に任意のプロトコル相互作用は明確で行われるとのman-in-the-middle攻撃者によって修正することができます。このため、クライアントは前TLSハンドシェイクの開始にアドバタイズサーバ機能についてのキャッシュされた情報を捨てなければなりません。
Clients are encouraged to clearly indicate when the level of encryption active is known to be vulnerable to attack using modern hardware (such as encryption keys with 56 bits of entropy or less).
クライアントは、アクティブ暗号化のレベルを（例えば、56エントロピーのビット以下と暗号鍵のような）最新のハードウェアを使用して、攻撃に対して脆弱であることが知られている場合、明らかに示すために奨励されています。
The LOGINDISABLED IMAP capability (discussed in section 3.2) only reduces the potential for passive attacks, it provides no protection against active attacks. The responsibility remains with the client to avoid sending a password over a vulnerable channel.
（セクション3.2で説明する）LOGINDISABLED IMAP能力は、それがアクティブな攻撃に対する保護を提供しない、受動的な攻撃の可能性を低減します。責任は、脆弱なチャネルを介してパスワードを送信することを避けるために、クライアントに残ります。
The PLAIN mechanism relies on the TLS encryption layer for security. When used without TLS, it is vulnerable to a common network eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used unless a suitable TLS encryption layer is active or backwards compatibility dictates otherwise.
PLAINメカニズムは、セキュリティのためのTLS暗号化層に依存しています。 TLSなしで使用する場合、それは一般的なネットワーク盗聴攻撃に対して脆弱です。したがってPLAINがアドバタイズまたは適切なTLS暗号化レイヤがアクティブであるか、下位互換性が別途指示しない限り、使用してはいけません。
When the PLAIN mechanism is used, the server gains the ability to impersonate the user to all services with the same password regardless of any encryption provided by TLS or other network privacy mechanisms. While many other authentication mechanisms have similar weaknesses, stronger SASL mechanisms such as Kerberos address this issue. Clients are encouraged to have an operational mode where all mechanisms which are likely to reveal the user's password to the server are disabled.
PLAINメカニズムを使用すると、サーバーは関係なく、TLSまたは他のネットワークのプライバシーメカニズムによって提供される任意の暗号化の同じパスワードですべてのサービスにユーザーを偽装する能力を獲得します。他の多くの認証機構が同様の弱点を持っているが、Kerberosなどのより強力なSASLメカニズムは、この問題に対処します。クライアントはサーバーにユーザーのパスワードを明らかにする可能性があるすべてのメカニズムが無効になっている動作モードを持つことが奨励されています。
The security considerations for TLS apply to STARTTLS and the security considerations for SASL apply to the PLAIN mechanism. Additional security requirements are discussed in section 2.
SASLはPLAIN機構に適用するためにTLSのセキュリティの考慮事項は、STARTTLSとセキュリティに関する考慮事項に適用されます。追加のセキュリティ要件は、セクション2で説明されています。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
"インターネット認証について" [AUTH]ハラー、N.とR.アトキンソン、RFC 1704、1994年10月。
[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[CRAM-MD5] Klensin、J.、Catoe、R.及びP. Krumviede、 "単純なチャレンジ/レスポンスのためのIMAP / POP許可拡張子"、RFC 2195、1997年9月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 2060、1996年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[MIME-SEC]ガルビン、J.、マーフィー、S.、クロッカー、S.およびN.フリード、 "MIMEマルチパートのセキュリティ：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月には。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998.
[POP3EXT] Gellens、R.、ニューマン、C.とL. Lundblade、 "POP3拡張メカニズム"、RFC 2449、1998年11月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[POP-AUTH]マイヤーズ、J.、 "POP3認証コマンド"、RFC 1734、1994年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999.
[SMTPTLS]ホフマン、P.、 "TLSの上にセキュアなSMTPのためのSMTPサービス拡張子"、RFC 2487、1999年1月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
クリス・ニューマンInnosoftの国際、Inc.の1050湖ドライブウェストコヴィナ、CA 91790 USA
EMail: chris.newman@innosoft.com
メールアドレス：chris.newman@innosoft.com
A. Appendix -- Compliance Checklist
A.付録 - コンプライアンスのチェックリスト
An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant".
それが実装されたプロトコルのためのMUST要件の一つ以上を満たすために失敗した場合、実装は準拠していません。すべてのMUSTとそのプロトコルのためのすべてのSHOULD要件を満たす実装は「無条件に準拠した」と言われて。すべてのMUST要件ではなく、そのプロトコルのためのすべてのSHOULD要件を満たすものは、「条件付き準拠した」と言われています。
Rules Section
----- -------
Mandatory-to-implement Cipher Suite 2.1
SHOULD have mode where encryption required 2.2
server SHOULD have mode where TLS not required 2.2
MUST be configurable to refuse all clear-text login
commands or mechanisms 2.3
server SHOULD be configurable to refuse clear-text
login commands on entire server and on per-user basis 2.3
client MUST check server identity 2.4
client MUST use hostname used to open connection 2.4
client MUST NOT use hostname from insecure remote lookup 2.4
client SHOULD support subjectAltName of dNSName type 2.4
client SHOULD ask for confirmation or terminate on fail 2.4
MUST check result of STARTTLS for acceptable privacy 2.5
client MUST NOT issue commands after STARTTLS
until server response and negotiation done 3.1,4,5.1
client MUST discard cached information 3.1,4,5.1,9
client SHOULD re-issue CAPABILITY/CAPA command 3.1,4
IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2
IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2
POP server MUST implement POP3 extensions 4
ACAP server MUST re-issue ACAP greeting 5.1 client SHOULD warn when session privacy not active and/or
refuse to proceed without acceptable security level 9
SHOULD be configurable to refuse weak mechanisms or
cipher suites 9
The PLAIN mechanism is an optional part of this specification. However if it is implemented the following rules apply:
PLAIN機構は、本明細書の任意の部分です。それが実装されている場合は、次の規則が適用されます。
Rules Section
----- -------
MUST NOT use PLAIN unless strong encryption active
or backwards compatibility dictates otherwise 6,9
MUST use UTF-8 encoding for characters in PLAIN 6
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。