[要約] RFC 2595は、IMAP、POP3、ACAPとTLSを使用するためのガイドラインを提供しています。その目的は、これらのプロトコルをセキュアに通信するための手法とベストプラクティスを示すことです。
Network Working Group C. Newman
Request for Comments: 2595 Innosoft
Category: Standards Track June 1999
Using TLS with IMAP, POP3 and ACAP
IMAP、POP3、ACAPでTLSを使用します
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.
Copyright（c）The Internet Society（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.
TLSプロトコル（以前はSSLとして知られていました）は、改ざんと盗聴からアプリケーションプロトコルを保護する方法を提供します。このようなセキュリティを使用するオプションは、一般的な接続盗聴およびハイジャック攻撃のために、IMAP、POP、およびACAPに望ましい[auth]。高度な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などの単純なパスワード認証コマンドを欠くプロトコルで使用するプレーン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
IETFには、暗号化されていないチャネルを介したクリアテキストパスワードの送信を排除するという強い欲求があります。SASLはこの目的に使用できますが、TLSは異なる展開特性を備えた追加のツールを提供します。両方のTLSをサポートするサーバー
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.
簡単なパスワードとチャレンジ/応答SASLメカニズムは、暗号化されていないクリアテキストパスワードに頼ることなく、さまざまなクライアントと相互運用する可能性があります。
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].
「必須」、「必須」、「必要はない」、「そうは思わない」、「そうではない」、「5月」、および「オプション」は、「RFCで使用するためのキーワードで説明されていると解釈されます。要件レベルを示すために」[キーワード]。
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]暗号スイートが必要です。これは、2つの準拠の実装を相互運用するように構成できることを保証するため、重要です。
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 CIPHESスイートが認証を許可する前に必須です。
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.
StartTLを実装するクライアントとサーバーは、適切な強度の暗号化層がアクティブでない限り、すべてのクリアテキストログインコマンドまたはメカニズム（標準トラックと非標準のメカニズムの両方を含む）を拒否するように構成可能でなければなりません。暗号化されていないクリアテキストログインを許可するサーバーは、サーバー全体およびユーザーごとにクリアテキストログインを拒否するように構成可能である必要があります。
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:
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 Canonicalizationは行われていません。
- 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のsubmestaltname拡張機能が証明書に存在する場合、サーバーのIDのソースとして使用する必要があります。
- 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.
- 「*」ワイルドカード文字は、証明書の左端の名前コンポーネントとして使用できます。たとえば、 *.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.
一致が失敗した場合、クライアントは明示的なユーザーの確認を要求するか、接続を終了し、サーバーのIDが疑わしいことを示す必要があります。
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」は機能コマンドに応じて機能としてリストされます。この拡張機能は、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交渉を開始する悪い - コマンド不明または引数が無効です
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が開始されると、クライアントはサーバー機能に関するキャッシュされた情報を破棄し、機能コマンドを再発行する必要があります。これは、StartTLSの前に機能リストを変更する中間の攻撃から保護するために必要です。サーバーは、startTLS後にさまざまな機能を宣伝する場合があります。
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
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）には、クリアテキストパスワードを使用するログインコマンドの実装が必要です。多くのサイトは、セキュリティ上の理由で暗号化がアクティブでない限り、このコマンドを無効にすることを選択する場合があります。IMAPサーバーは、logindisabled機能を機能応答に含めることにより、ログインコマンドが無効になっていることを宣伝する場合があります。このようなサーバーは、ログインコマンドを使用しようとする試みに対するタグ付けされた「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クライアントは、この機能が存在する場合、ログインコマンドを発行してはなりません。
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.
この機能は、この仕様に準拠したクライアントが、パッシブ攻撃の対象となる環境で暗号化されていないパスワードを送信できないようにするのに役立ちます。中間の攻撃者がこの機能を削除できるため、積極的な攻撃の対象となる環境には影響しません。したがって、これは、セクション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拡張機能は、STLSコマンドをPOP3サーバーに追加します。これが実装されている場合、複数のコマンドのクライアントプローブの必要性を回避するために、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の直後に始まります。セキュリティレイヤーがすでにアクティブである場合、A -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.
STLSコマンドは、クライアントの資格情報がTLS交渉中に提供されたとしても、認証状態でのみ許可され、サーバーは認証状態のままです。外部メカニズム[SASL]を使用したauthコマンド[pop-auth]は、TLSクライアント資格情報が正常に交換されると認証するために使用できますが、STLSコマンドをサポートするサーバーは、外部メカニズムをサポートするために必要ありません。
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の前に機能リストを変更する中間の攻撃から保護するために必要です。サーバーは、STLS後に異なる機能を宣伝する場合があります。
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
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交渉を開始する悪い - コマンド不明または引数が無効です
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の前に機能リストを変更する中間の攻撃から保護するために必要です。クライアントは、キャッシュされた機能情報を破棄し、新しいACAPの挨拶からの情報に置き換える必要があります。サーバーは、startTLS後にさまざまな機能を宣伝する場合があります。
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")
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.
これは、ACAPおよびその他のプロトコルで使用する「プレーン」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.
メカニズムは、クライアントからサーバーへの単一のメッセージで構成されています。クライアントは、認証ID（アイデンティティAS）を送信し、次にUS-ASCII NUL文字が続き、次に認証ID（パスワードが使用されるID）が続き、その後に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
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
Note: In this example, <NUL> represents a single ASCII NUL octet.
注：この例では、<nul>は単一のascii nul octetを表します。
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.
SSLで使用するために、個別の「IMAPS」と「POP3S」ポートが登録されました。これらのポートの使用は、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スキームにつながります。たとえば、多くのWebページでは、「ブラウザが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
- 別々のポートは、「セキュア」または「セキュアではない」のモデルを意味します。これは、さまざまな方法で誤解を招く可能性があります。第一に、「セキュア」ポートは、実際には、輸出がクリップされた暗号スイートが使用されているため、実際には許容できない場合があります。これは、ユーザーを誤解させる可能性があります。第二に、通常のポートは、セキュリティ層を含むSASLメカニズムを使用して保護される場合があります。したがって、個別のポートの区別により、セキュリティポリシーの複雑なトピックがさらに混乱します。この混乱の一般的な結果の1つは、ファイアウォール管理者がしばしば誤解されていることです
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.
「セキュア」ポートを許可し、標準ポートをブロックします。これは、40ビットのキー暗号化層とプレーンテキストパスワード認証を備えたSSLの一般的な使用を考えると、Kerberos 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に個別のポートを使用すると、クライアントは2つのセキュリティポリシーのみを実装しました。SSLの使用またはSSLを使用しないでください。望ましいセキュリティポリシー「利用可能な場合は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.
- ポート番号は限られたリソースです。彼らはまだ不足していませんが、消費の速度を2倍（またはそれ以上）倍増させる可能性のある先例を設定することは賢明ではありません。
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標準コマンドに影響を受ける：ユーザー/パスを副作用として有効にすることができます。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機能引数：なし公開された仕様：このメモ担当者と電子メールアドレス詳細について：著者のアドレスセクションを参照してください
The registration for the PLAIN SASL mechanism follows:
プレーン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メカニズム名：プレーンセキュリティの考慮事項：このメモ公開された仕様のセクション9を参照してください。
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.
中間の攻撃者は、常に最も弱い認証メカニズムや暗号スイートを利用可能にするために、常に無交渉を引き起こす可能性があります。このため、実装は、弱いメカニズムまたは暗号スイートを拒否するように構成できる必要があります。
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の握手前のプロトコルの相互作用は、明確なもので実行され、中間の攻撃者によって変更される可能性があります。このため、クライアントは、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.
Logindisabled IMAP機能（セクション3.2で説明）は、パッシブ攻撃の可能性を減らすだけで、アクティブな攻撃に対する保護を提供しません。責任は、脆弱なチャネルを介してパスワードの送信を避けるためにクライアントに残ります。
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.
プレーンメカニズムは、セキュリティのためのTLS暗号化レイヤーに依存しています。TLSなしで使用すると、一般的なネットワーク盗聴攻撃に対して脆弱です。したがって、適切な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.
プレーンメカニズムを使用すると、サーバーは、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.
TLSのセキュリティ上の考慮事項はStartTLSに適用され、SASLのセキュリティに関する考慮事項は、プレーンメカニズムに適用されます。追加のセキュリティ要件については、セクション2で説明します。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、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] Newman、C。and J. Myers、「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] Crispin、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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Galvin、J.、Murphy、S.、Crocker、S。、およびN. Freed、「Mimeのセキュリティマルチパート：MultiPart/Signed and MultiPart/暗号化」、RFC 1847、1995年10月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3] Myers、J。and M. Rose、「郵便局プロトコル - バージョン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.、Newman、C。and L. Lundblade、「Pop3拡張メカニズム」、RFC 2449、1998年11月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[Pop-auth] Myers、J。、「Pop3 Authenticationコマンド」、RFC 1734、1994年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999.
[SMTPTLS] Hoffman、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] Dierks、T。およびC. Allen、「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
クリスニューマンイノソフトインターナショナル、インク1050レイクスドライブウェストコヴィナ、カリフォルニア州91790 USA
EMail: 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".
実装するプロトコルの要件の1つ以上を満たすことができない場合、実装は準拠していません。すべてのマストを満たす実装とそのプロトコルのすべての要件は、「無条件に準拠している」と言われています。すべての必須要件を満たすが、そのプロトコルのすべての要件が「条件付きに準拠している」と言われるものではない。
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
クライアントは、セッションのプライバシーがアクティブではない場合、および/または許容可能なセキュリティレベル9が弱いメカニズムまたは暗号スイートを拒否するために構成可能である必要がある場合に警告する必要があります9
The PLAIN mechanism is an optional part of this specification. However if it is implemented the following rules apply:
プレーンメカニズムは、この仕様のオプションの部分です。ただし、それが実装されている場合、次のルールが適用されます。
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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。