RFC 8437 - IMAP UNAUTHENTICATE Extension for Connection Reuse 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8437
タイトル : RFC 8437 - 接続再利用のためのIMAP AUTHENTICATE拡張
翻訳編集 : 自動生成

[要約] RFC 8437は、IMAPのUNAUTHENTICATE拡張機能に関する仕様です。この拡張機能の目的は、接続の再利用を可能にすることです。

Internet Engineering Task Force (IETF)                         C. Newman
Request for Comments: 8437                                        Oracle
Updates: 3501                                                August 2018
Category: Standards Track
ISSN: 2070-1721

IMAP UNAUTHENTICATE Extension for Connection Reuse

接続再利用のためのIMAP AUTHENTICATE拡張

Abstract

概要

This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities.

この仕様はインターネットメッセージアクセスプロトコル（IMAP）を拡張して、管理クライアントが複数のIMAPユーザーIDの代わりに同じIMAP接続を再利用できるようにします。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8437.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8437で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   2
   3.  UNAUTHENTICATE Command  . . . . . . . . . . . . . . . . . . .   3
   4.  Interactions  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Stateful Extensions . . . . . . . . . . . . . . . . . . .   4
     4.2.  Client Certificates, SASL EXTERNAL, and imaps . . . . . .   5
   5.  Revised State Machine . . . . . . . . . . . . . . . . . . . .   6
   6.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Appendix A.  Design Considerations  . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

Modern IMAP [RFC3501] server deployments often have peer systems with administrative privilege that perform actions on behalf of IMAP end users. For example, a voicemail gateway can use IMAP to store a user's voicemail and mark that voicemail as \Seen when the user listens to it via the phone interface. These systems can issue the IMAP AUTHENTICATE command with administrative credentials to act on behalf of other users. However, with the IMAP base specification, these specialized IMAP clients must close the connection and create a new connection for each user. For efficiency reasons, it is desirable for these clients to reuse the same connection, particularly if SSL has been negotiated. This specification proposes the UNAUTHENTICATE command to achieve this goal.

最近のIMAP [RFC3501]サーバーの展開には、IMAPエンドユーザーに代わってアクションを実行する管理者特権を持つピアシステムがよくあります。たとえば、ボイスメールゲートウェイはIMAPを使用してユーザーのボイスメールを保存し、ユーザーが電話インターフェースを介して聞いたときに、そのボイスメールを\ Seenとしてマークできます。これらのシステムは、他のユーザーに代わって動作する管理資格情報を使用してIMAP AUTHENTICATEコマンドを発行できます。ただし、IMAP基本仕様では、これらの特殊なIMAPクライアントは接続を閉じ、ユーザーごとに新しい接続を作成する必要があります。効率上の理由から、特にSSLがネゴシエートされている場合は、これらのクライアントが同じ接続を再利用することが望ましいです。この仕様では、この目標を達成するためにUNAUTHENTICATEコマンドを提案しています。

The IMAP state machine described in Section 3 of RFC 3501 does not have a transition from authenticated or selected state to not authenticated state. The UNAUTHENTICATE command adds this transition.

RFC 3501のセクション3で説明されているIMAPステートマシンは、認証済みまたは選択済みの状態から非認証状態への移行がありません。 UNAUTHENTICATEコマンドは、この遷移を追加します。

2. Conventions Used in This Document

2. このドキュメントで使用される規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. UNAUTHENTICATE Command

3. UNAUTHENTICATEDコマンド

Arguments: None

引数：なし

Responses: No specific response for this command

応答：このコマンドに対する特定の応答はありません

Result: OK - Completed, now in not authenticated state BAD - Command unknown or arguments invalid

結果：OK-完了、現在は認証されていない状態BAD-コマンドが不明または引数が無効

This command directs the server to reset all connection state except for the state of the TLS [RFC8446] layer. Upon completion, the server connection is placed in not authenticated state. This represents Transition 7 in the State Machine Diagram (Section 5).

このコマンドは、TLS [RFC8446]レイヤーの状態を除くすべての接続状態をリセットするようサーバーに指示します。完了すると、サーバー接続は認証されていない状態になります。これは、状態マシン図（セクション5）の遷移7を表しています。

If a mailbox was selected, the mailbox ceases to be selected, but no expunge event is generated. If a Simple Authentication and Security Layer (SASL) [RFC4422] was active, the server terminates its outgoing security layer immediately after sending the CRLF following the OK response. The client's outgoing security layer terminates immediately after the CRLF following the UNAUTHENTICATE command. Note that a BAD response only occurs if UNAUTHENTICATE is issued in an invalid state, is not advertised by the server, or does not follow the command syntax in the specification. A NO response is not permitted. As a result, specification-compliant implementations will interoperate across security layer termination.

メールボックスが選択された場合、メールボックスは選択されなくなりますが、消去イベントは生成されません。 Simple Authentication and Security Layer（SASL）[RFC4422]がアクティブだった場合、サーバーはOK応答に続いてCRLFを送信した直後に送信セキュリティレイヤーを終了します。クライアントの発信セキュリティ層は、UNAUTHENTICATEコマンドに続くCRLFの直後に終了します。不正な応答が発生するのは、UNAUTHENTICATEが無効な状態で発行された場合、サーバーによって通知されなかった場合、または仕様のコマンド構文に従っていない場合のみです。 NO応答は許可されていません。その結果、仕様に準拠した実装は、セキュリティ層の終端全体で相互運用します。

After sending this command, the client is free to issue a new AUTHENTICATE or LOGIN command as permitted based on the server's capabilities. If no SASL security layer was active, the client is permitted to pipeline the UNAUTHENTICATE command with a subsequent AUTHENTICATE command. If the IMAP server also advertises SASL-IR [RFC4959], this permits an administrative client to re-authenticate in one round trip. Because of this pipelining optimization, a server advertising UNAUTHENTICATE is not permitted to respond to the UNAUTHENTICATE command with a NO response if it is unable to reset the state associated with the connection. Servers MAY close the connection with an untagged BYE response if this preferably rare situation occurs.

このコマンドを送信した後、クライアントはサーバーの機能に基づいて許可された新しいAUTHENTICATEまたはLOGINコマンドを自由に発行できます。 SASLセキュリティ層がアクティブでなかった場合、クライアントはUNAUTHENTICATEコマンドをパイプライン処理して、後続のAUTHENTICATEコマンドを実行できます。 IMAPサーバーがSASL-IR [RFC4959]もアドバタイズする場合、これにより、管理クライアントは1回の往復で再認証できます。このパイプライン最適化のため、UNAUTHENTICATEをアドバタイズするサーバーは、接続に関連付けられた状態をリセットできない場合、NOAUTHENTICATEコマンドにNO応答で応答できません。このまれな状況が発生した場合、サーバーはタグなしのBYE応答で接続を閉じることができます（MAY）。

Servers MAY choose to advertise the UNAUTHENTICATE capability only after authentication has completed. As a result, clients may need to issue an IMAP CAPABILITY command after authentication in order to determine the availability of UNAUTHENTICATE.

サーバーは、認証が完了した後にのみUNAUTHENTICATE機能を通知することを選択できます。その結果、UNAUTHENTICATEが利用可能かどうかを判断するために、クライアントは認証後にIMAP CAPABILITYコマンドを発行する必要がある場合があります。

The IMAP ID [RFC2971] command provides properties about the client primarily for use in server log or audit files. Because IMAP ID is not related to application authentication or user identity in any way, and caching it for the duration of the client connection can be useful, the interaction between IMAP ID and the UNAUTHENTICATE command is defined by the implementation.

IMAP ID [RFC2971]コマンドは、主にサーバーログまたは監査ファイルで使用するためのクライアントに関するプロパティを提供します。 IMAP IDはアプリケーション認証やユーザーIDとは一切関係がなく、クライアント接続の間キャッシュすることは有用な場合があるため、IMAP IDとUNAUTHENTICATEコマンド間の相互作用は実装によって定義されます。

4. Interactions

4. 相互作用

This section describes interactions between this extension and other IMAP extensions or usage models.

このセクションでは、この拡張機能と他のIMAP拡張機能または使用モデルとの相互作用について説明します。

4.1. Stateful Extensions

4.1. ステートフル拡張

The connection state for the following list of IMAP extensions MUST be reset if both a) the specified extension is advertised and b) the UNAUTHENTICATE command is advertised and used. This list may not be complete; the requirement to reset the connection state applies to all current and future extensions except STARTTLS and ID. Additional requirements apply to specific stateful extensions as follows:

次のIMAP拡張のリストの接続状態は、a）指定された拡張がアドバタイズされ、b）UNAUTHENTICATEコマンドがアドバタイズされて使用された場合にリセットする必要があります。このリストは完全ではない可能性があります。接続状態をリセットする要件は、STARTTLSとIDを除く現在および将来のすべての拡張機能に適用されます。追加の要件は、次のように特定のステートフル拡張に適用されます。

o Cached identity information, such as group memberships, that are used to evaluate access control lists [RFC4314] MUST be reset.

o アクセス制御リストの評価に使用されるグループメンバーシップなどのキャッシュされたID情報[RFC4314]はリセットする必要があります。

o After an UNAUTHENTICATE command is issued, CONDSTORE servers [RFC7162] MUST behave as if no CONDSTORE-enabling command was issued.

o UNAUTHENTICATEコマンドが発行された後、CONDSTOREサーバー[RFC7162]は、CONDSTORE対応のコマンドが発行されなかったかのように動作する必要があります。

o If IMAP COMPRESS [RFC4978] is active, the server terminates its outgoing compression layer after it sends the CRLF following the OK response. The client terminates its outgoing compression layer after the CRLF following the UNAUTHENTICATE command. When it matters, the compression layer terminates before a SASL layer terminates.

o IMAP COMPRESS [RFC4978]がアクティブな場合、サーバーは、OK応答に続いてCRLFを送信した後、発信圧縮層を終了します。クライアントは、UNAUTHENTICATEコマンドに続くCRLFの後に発信圧縮層を終了します。必要に応じて、SASL層が終了する前に圧縮層が終了します。

o Any extensions enabled by the IMAP ENABLE [RFC5161] command cease to be enabled when the UNAUTHENTICATE command is issued. This includes, but is not limited to, CONDSTORE [RFC7162], QRESYNC [RFC7162], METADATA [RFC5464], METADATA-SERVER [RFC5464], and UTF8=ACCEPT [RFC6855].

o IMAP ENABLE [RFC5161]コマンドによって有効化された拡張機能は、UNAUTHENTICATEコマンドが発行されると有効化されなくなります。これには、CONDSTORE [RFC7162]、QRESYNC [RFC7162]、METADATA [RFC5464]、METADATA-SERVER [RFC5464]、UTF8 = ACCEPT [RFC6855]が含まれますが、これらに限定されません。

o A server advertising SEARCHRES [RFC5182] discards any saved search results so that '$' subsequently represents the empty set.

o SEARCHRES [RFC5182]をアドバタイズするサーバーは、保存された検索結果をすべて破棄するため、「$」はその後空のセットを表します。

o A server advertising LANGUAGE [RFC5255] will revert to the "i-default" language.

o LANGUAGE [RFC5255]をアドバタイズするサーバーは、「i-default」言語に戻ります。

o When a server advertises CONTEXT=SEARCH or CONTEXT=SORT [RFC5267], the UNAUTHENTICATE command includes an implicit CANCELUPDATE for all server contexts.

o サーバーがCONTEXT = SEARCHまたはCONTEXT = SORT [RFC5267]を通知する場合、UNAUTHENTICATEコマンドには、すべてのサーバーコンテキストの暗黙的なCANCELUPDATEが含まれます。

o When a server advertises NOTIFY [RFC5465], the UNAUTHENTICATE command cancels the server state related to the NOTIFY command and reverts to default IMAP base-specification behavior for notifications.

o サーバーがNOTIFY [RFC 5465]をアドバタイズすると、UNAUTHENTICATEDコマンドはNOTIFYコマンドに関連するサーバーの状態をキャンセルし、通知のデフォルトのIMAPベース仕様の動作に戻します。

4.2. Client Certificates, SASL EXTERNAL, and imaps

4.2. クライアント証明書、SASL EXTERNAL、imaps

When a TLS [RFC8446] security layer is negotiated using either the STARTTLS command or the imaps port [RFC8314], IMAP servers may be configured to request a client certificate, and IMAP clients may provide one. Client credentials at the TLS layer do not normally impact the application layer; however, they do have an impact when the SASL EXTERNAL mechanism [RFC4422] in an IMAP AUTHENTICATE command is used to direct the server to use the provided client certificate to authenticate as the specified IMAP user. The UNAUTHENTICATE command breaks any application-level binding of the TLS client credentials but does not discard the client credentials. As a result, an administrative client may use a client certificate with administrative privilege to act on behalf of multiple IMAP users in the same connection via the EXTERNAL mechanism and the UNAUTHENTICATE command.

TLS [RFC8446]セキュリティレイヤーがSTARTTLSコマンドまたはimapsポート[RFC8314]のいずれかを使用してネゴシエートされると、IMAPサーバーはクライアント証明書を要求するように構成され、IMAPクライアントはそれを提供します。 TLS層のクライアント資格情報は、通常、アプリケーション層に影響を与えません。ただし、IMAP AUTHENTICATEコマンドのSASL EXTERNALメカニズム[RFC4422]を使用して、指定されたIMAPユーザーとして認証するために、提供されたクライアント証明書を使用するようサーバーに指示する場合に、影響があります。 UNAUTHENTICATEコマンドは、TLSクライアント資格情報のアプリケーションレベルのバインドを解除しますが、クライアント資格情報は破棄しません。その結果、管理クライアントは、管理特権を持つクライアント証明書を使用して、EXTERNALメカニズムとUNAUTHENTICATEコマンドを介して、同じ接続で複数のIMAPユーザーの代わりに機能することができます。

Some server implementations using the imaps port will request and use a TLS client certificate to authenticate immediately as the default IMAP identity associated with that certificate. These implementations indicate this behavior by using the PREAUTH greeting, as indicated by Transition 2 in the State Machine Diagram (Section 5). As a result, TLS client certificates cannot be used for administrative proxy authentication with the imaps port unless the UNAUTHENTICATE command is also advertised. In that case, an administrative client can respond to the PREAUTH greeting with an UNAUTHENTICATE command and then issue an AUTHENTICATE EXTERNAL command.

imapsポートを使用する一部のサーバー実装は、TLSクライアント証明書を要求して使用し、その証明書に関連付けられているデフォルトのIMAP IDとしてすぐに認証します。これらの実装は、状態マシン図（セクション5）の遷移2で示されているように、PREAUTHグリーティングを使用してこの動作を示します。その結果、UNAUTHENTICATEコマンドも通知されない限り、TLSクライアント証明書をimapsポートでの管理プロキシ認証に使用できません。その場合、管理クライアントは、PREAUTHグリーティングにUNAUTHENTICATEコマンドで応答してから、AUTHENTICATE EXTERNALコマンドを発行できます。

5. Revised State Machine

5. 改訂された状態機械

                      +----------------------+
                      |connection established|
                      +----------------------+
                                 ||
                                 \/
               +--------------------------------------+
               |          server greeting             |
               +--------------------------------------+
                         || (1)       || (2)        || (3)
                         \/           ||            ||
               +-----------------+    ||            ||
               |Not Authenticated|<===||=========++ ||
               +-----------------+    ||     (7) || ||
                || (8)   || (4)       ||         || ||
                ||       \/           \/         || ||
                ||     +----------------+        || ||
                ||     |                |========++ ||
                ||     | Authenticated  |<=++    || ||
                ||     +----------------+  ||    || ||
                ||       || (8)   || (5)   ||(6) || ||
                ||       ||       \/       ||    || ||
                ||       ||    +--------+  ||    || ||
                ||       ||    |Selected|==++    || ||
                ||       ||    |        |========++ ||
                ||       ||    +--------+           ||
                ||       ||       || (8)            ||
                \/       \/       \/                \/
               +--------------------------------------+
               |               Logout                 |
               +--------------------------------------+
                                 ||
                                 \/
                   +-------------------------------+
                   |both sides close the connection|
                   +-------------------------------+

Revised IMAP state machine transitions:

IMAPステートマシンの遷移の改訂：

1. Connection without pre-authentication (OK greeting)

1. 事前認証なしの接続（OKグリーティング）

2. Pre-authenticated connection (PREAUTH greeting)

2. 事前認証された接続（PREAUTHグリーティング）

3. Rejected connection (BYE greeting)

3. 拒否された接続（BYEグリーティング）

4. Successful LOGIN or AUTHENTICATE command 5. Successful SELECT or EXAMINE command

4. LOGINまたはAUTHENTICATEコマンドの成功5. SELECTまたはEXAMINEコマンドの成功

6. CLOSE, UNSELECT [RFC3691], or failed SELECT or EXAMINE command

6. CLOSE、UNSELECT [RFC3691]、または失敗したSELECTまたはEXAMINEコマンド

7. UNAUTHENTICATE command

7. UNAUTHENTICATEDコマンド

8. LOGOUT command, server shutdown, or connection closed

8. LOGOUTコマンド、サーバーのシャットダウン、または接続のクローズ

6. Formal Syntax

6. 正式な構文

The following syntax specification uses the Augmented Backus-Naur Form (ABNF), as described in [RFC5234]. Amended terms are defined in [RFC3501].

次の構文仕様では、[RFC5234]で説明されているように、拡張バッカスナウアフォーム（ABNF）を使用しています。修正された用語は[RFC3501]で定義されています。

capability =/ "UNAUTHENTICATE"

機能= / "認証"

command-auth =/ "UNAUTHENTICATE"

command-auth = / "AUTHENTICATE"

command-select =/ "UNAUTHENTICATE"

command-select = / "AUTHENTICATE"

7. IANA Considerations

7. IANAに関する考慮事項

IANA has added the UNAUTHENTICATE capability to the "IMAP Capabilities" registry.

IANAは、「IMAP機能」レジストリにUNAUTHENTICATE機能を追加しました。

8. Security Considerations

8. セキュリティに関する考慮事項

The original IMAP state machine was designed to allow a server-implementation approach in which each IMAP authentication identity matches an operating system identity and the server revokes all administrative privilege once authentication completes. This extension is not compatible with that implementation approach. However, that approach has significant performance costs on Unix systems, and this extension is designed for environments where efficiency is a relatively high-priority deployment goal. This extension is therefore appropriate for some deployments but may not be appropriate for the most security-sensitive environments.

元のIMAP状態マシンは、各IMAP認証IDがオペレーティングシステムIDと一致し、認証が完了するとサーバーがすべての管理特権を取り消すサーバー実装アプローチを可能にするように設計されました。この拡張機能は、その実装アプローチと互換性がありません。ただし、このアプローチはUnixシステムでかなりのパフォーマンスコストがかかります。この拡張機能は、効率が比較的優先度の高い展開目標である環境向けに設計されています。したがって、この拡張機能は一部の展開に適していますが、最もセキュリティが重要な環境には適さない場合があります。

IMAP server implementations are complicated and can retain a lot of state related to an authenticated user. Server implementers need to take care to reset all server state such that authentication as a subsequent user does not inherit any data or privileges from the previous user. State data associated with a user can include cached identity information such as group membership used to evaluate access control lists [RFC4314], active notifications [RFC5465], access to per-user data such as flags, etc.

IMAPサーバーの実装は複雑で、認証済みユーザーに関連する多くの状態を保持できます。サーバーの実装者は、後続のユーザーとしての認証が前のユーザーからデータまたは特権を継承しないように、すべてのサーバーの状態をリセットするように注意する必要があります。ユーザーに関連付けられた状態データには、アクセス制御リスト[RFC4314]、アクティブ通知[RFC5465]を評価するために使用されるグループメンバーシップなどのキャッシュされたID情報、フラグなどのユーザーごとのデータへのアクセスを含めることができます。

IMAP server systems are often deployed in a two-tier model where a server-side IMAP proxy routes to an IMAP backend that handles all connections for a subset of possible users. Some IMAP proxies enter a pass-through mode after authentication. If enabled, the UNAUTHENTICATE command would allow a client, on a subsequent authentication, to bypass any security restrictions present in the proxy layer but not in the backend server layer. As a result, IMAP server implementations of this extension MUST provide a way to disable it when it is not needed. Use of an IMAP proxy that processes the UNAUTHENTICATE command at the proxy layer eliminates this concern. Another option to mitigate this concern is for servers to only enable the UNAUTHENTICATE extension if the supplied authentication credentials are associated with an administrative identity.

IMAPサーバーシステムは、多くの場合、サーバー側のIMAPプロキシが、可能なユーザーのサブセットのすべての接続を処理するIMAPバックエンドにルーティングする2層モデルで展開されます。一部のIMAPプロキシは、認証後にパススルーモードに入ります。 UNAUTHENTICATEコマンドを有効にすると、クライアントは後続の認証で、プロキシレイヤーに存在するがバックエンドサーバーレイヤーには存在しないセキュリティ制限をバイパスできます。その結果、この拡張機能のIMAPサーバー実装は、不要な場合に無効にする方法を提供する必要があります。プロキシレイヤーでUNAUTHENTICATEコマンドを処理するIMAPプロキシを使用すると、この問題を回避できます。この懸念を軽減する別のオプションは、サーバーがUNAUTHENTICATE拡張を有効にできるのは、提供された認証資格情報が管理IDに関連付けられている場合のみです。

9. Privacy Considerations

9. プライバシーに関する考慮事項

For the most part, this extension will have no impact on the privacy considerations already present in an IMAP implementation. However, if this extension were used between data centers, it could improve end-user privacy by increasing the difficultly of traffic analysis due to connection reuse.

ほとんどの場合、この拡張機能は、IMAP実装にすでに存在するプライバシーの考慮事項に影響を与えません。ただし、この拡張機能がデータセンター間で使用された場合、接続の再利用により困難なトラフィック分析が増加するため、エンドユーザーのプライバシーが向上する可能性があります。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.

[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、DOI 10.17487 / RFC3501、2003年3月、<https://www.rfc-editor.org/info/rfc3501>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

10.2. Informative References

10.2. 参考引用

[RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, DOI 10.17487/RFC2971, October 2000, <https://www.rfc-editor.org/info/rfc2971>.

[RFC2971] Showalter、T。、「IMAP4 ID拡張」、RFC 2971、DOI 10.17487 / RFC2971、2000年10月、<https://www.rfc-editor.org/info/rfc2971>。

[RFC3691] Melnikov, A., "Internet Message Access Protocol (IMAP) UNSELECT command", RFC 3691, DOI 10.17487/RFC3691, February 2004, <https://www.rfc-editor.org/info/rfc3691>.

[RFC3691] Melnikov、A。、「インターネットメッセージアクセスプロトコル（IMAP）UNSELECTコマンド」、RFC 3691、DOI 10.17487 / RFC3691、2004年2月、<https://www.rfc-editor.org/info/rfc3691>。

[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, DOI 10.17487/RFC4314, December 2005, <https://www.rfc-editor.org/info/rfc4314>.

[RFC4314] Melnikov、A。、「IMAP4 Access Control List（ACL）Extension」、RFC 4314、DOI 10.17487 / RFC4314、2005年12月、<https://www.rfc-editor.org/info/rfc4314>。

[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <https://www.rfc-editor.org/info/rfc4422>.

[RFC4422]メルニコフ、A。、エド。 K. Zeilenga編、「Simple Authentication and Security Layer（SASL）」、RFC 4422、DOI 10.17487 / RFC4422、2006年6月、<https://www.rfc-editor.org/info/rfc4422>。

[RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response", RFC 4959, DOI 10.17487/RFC4959, September 2007, <https://www.rfc-editor.org/info/rfc4959>.

[RFC4959] Siemborski、R。およびA. Gulbrandsen、「Simple Authentication and Security Layer（SASL）Initial Client ResponseのIMAP拡張機能」、RFC 4959、DOI 10.17487 / RFC4959、2007年9月、<https：//www.rfc-editor .org / info / rfc4959>。

[RFC4978] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, DOI 10.17487/RFC4978, August 2007, <https://www.rfc-editor.org/info/rfc4978>.

[RFC4978] Gulbrandsen、A。、「The IMAP COMPRESS Extension」、RFC 4978、DOI 10.17487 / RFC4978、2007年8月、<https://www.rfc-editor.org/info/rfc4978>。

[RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March 2008, <https://www.rfc-editor.org/info/rfc5161>.

[RFC5161] Gulbrandsen、A.、Ed。 A. Melnikov編、「The IMAP ENABLE Extension」、RFC 5161、DOI 10.17487 / RFC5161、2008年3月、<https://www.rfc-editor.org/info/rfc5161>。

[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March 2008, <https://www.rfc-editor.org/info/rfc5182>.

[RFC5182] Melnikov、A。、「最後の検索結果を参照するためのIMAP拡張機能」、RFC 5182、DOI 10.17487 / RFC5182、2008年3月、<https://www.rfc-editor.org/info/rfc5182>。

[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, DOI 10.17487/RFC5255, June 2008, <https://www.rfc-editor.org/info/rfc5255>.

[RFC5255]ニューマン、C.、Gulbrandsen、A。、およびA. Melnikov、「インターネットメッセージアクセスプロトコルの国際化」、RFC 5255、DOI 10.17487 / RFC5255、2008年6月、<https://www.rfc-editor.org/ info / rfc5255>。

[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, DOI 10.17487/RFC5267, July 2008, <https://www.rfc-editor.org/info/rfc5267>.

[RFC5267] Cridland、D。およびC. King、「Contexts for IMAP4」、RFC 5267、DOI 10.17487 / RFC5267、2008年7月、<https://www.rfc-editor.org/info/rfc5267>。

[RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464, DOI 10.17487/RFC5464, February 2009, <https://www.rfc-editor.org/info/rfc5464>.

[RFC5464] Daboo、C。、「The IMAP METADATA Extension」、RFC 5464、DOI 10.17487 / RFC5464、2009年2月、<https://www.rfc-editor.org/info/rfc5464>。

[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465, February 2009, <https://www.rfc-editor.org/info/rfc5465>.

[RFC5465] Gulbrandsen、A.、King、C。、およびA. Melnikov、「IMAP NOTIFY Extension」、RFC 5465、DOI 10.17487 / RFC5465、2009年2月、<https://www.rfc-editor.org/info / rfc5465>。

[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March 2013, <https://www.rfc-editor.org/info/rfc6855>.

[RFC6855] Resnick、P。、編、Newman、C。、編、S。Shen、編、「IMAP Support for UTF-8」、RFC 6855、DOI 10.17487 / RFC6855、2013年3月、<https： //www.rfc-editor.org/info/rfc6855>。

[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)", RFC 7162, DOI 10.17487/RFC7162, May 2014, <https://www.rfc-editor.org/info/rfc7162>.

[RFC7162] Melnikov、A。およびD. Cridland、「IMAP Extensions：Quick Flag Changes Resynchronization（CONDSTORE）and Quick Mailbox Resynchronization（QRESYNC）」、RFC 7162、DOI 10.17487 / RFC7162、2014年5月、<https：// www。 rfc-editor.org/info/rfc7162>。

[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, <https://www.rfc-editor.org/info/rfc8314>.

[RFC8314]ムーアK.およびC.ニューマン、「廃止予定のクリアテキスト：電子メールの送信とアクセスのためのトランスポート層セキュリティ（TLS）の使用」、RFC 8314、DOI 10.17487 / RFC8314、2018年1月、<https：// www。 rfc-editor.org/info/rfc8314>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。

Appendix A. Design Considerations

付録A.設計上の考慮事項

The author deliberately chose to add a separate UNAUTHENTICATE command instead of allowing the LOGIN or AUTHENTICATE commands to be issued when the connection is in a state other than unauthenticated. The primary reason for this choice is that the code that transitions from not authenticated state to authenticated state in a server is often the most security-sensitive code, because it needs to assume and handle unconditionally hostile attackers. That sensitive code is simpler if it only handles a single server state (unauthenticated) and the state transition is as simple as possible. Smaller and simpler code is easier to audit and write in a secure way.

作成者は、接続が非認証以外の状態にあるときにLOGINまたはAUTHENTICATEコマンドを発行する代わりに、別のUNAUTHENTICATEコマンドを意図的に追加することを選択しました。この選択の主な理由は、サーバーで認証されていない状態から認証された状態に遷移するコードは、無条件に悪意のある攻撃者を想定して処理する必要があるため、多くの場合、最もセキュリティに敏感なコードであることです。その機密コードは、単一のサーバー状態（非認証）のみを処理し、状態遷移が可能な限り単純である場合は、より単純になります。小さくてシンプルなコードは、監査と安全な方法での記述が簡単です。

A secondary reason to have a separate command is that it is simpler to enable or disable the feature with that design. See the discussion in the Security Considerations section recommending that implementations provide a way to disable this extension.

別のコマンドを使用する2つ目の理由は、そのデザインで機能を有効または無効にする方が簡単だからです。「セキュリティの考慮事項」セクションの説明を参照して、実装がこの拡張機能を無効にする方法を提供することを推奨します。

Acknowledgements

謝辞

Thanks to Fred Batty for implementing UNAUTHENTICATE and to Cyrus Daboo for constructive suggestions to improve this document.

UNAUTHENTICATEを実装してくれたFred Battyと、このドキュメントを改善するための建設的な提案をしてくれたCyrus Dabooに感謝します。

Author's Address

著者のアドレス

Chris Newman Oracle 440 E. Huntington Dr., Suite 400 Arcadia, CA 91006 United States of America

クリスニューマンオラクル440 E. Huntington Dr.、Suite 400 Arcadia、CA 91006アメリカ合衆国

   Email: chris.newman@oracle.com