メインコンテンツまでスキップ

6.2 クライアントコマンド - 未認証状態 (Client Commands - Not Authenticated State)

未認証状態では、AUTHENTICATE または LOGIN コマンドが認証を確立し、認証済み状態に入ります。AUTHENTICATE コマンドは、さまざまな認証技術、プライバシー保護、完全性チェックのための汎用メカニズムを提供しますが、LOGIN コマンドは従来のユーザー名と平文パスワードのペアを使用し、プライバシー保護や完全性チェックを確立する手段がありません。

STARTTLS コマンドは、セッションのプライバシー保護と完全性チェックを確立する代替形式ですが、それ自体では認証を確立したり、認証済み状態に入ったりしません。

サーバー実装は、認証を確立せずに特定のメールボックスへのアクセスを許可してもよい (してもよい)。これは、[ANONYMOUS] で説明されている ANONYMOUS [SASL] 認証子を使用して行うことができます。古い慣例では、ユーザー ID "anonymous" を使用する LOGIN コマンドがあります。この場合、サーバーは任意のパスワードを受け入れることを選択できますが、パスワードが必要です。匿名ユーザーに課される制限は実装依存です。

一度認証されると (匿名を含む)、未認証状態に再入することはできません。

ユニバーサルコマンド (CAPABILITY、NOOP、および LOGOUT) に加えて、次のコマンドは未認証状態で有効です：STARTTLS、AUTHENTICATE、および LOGIN。これらのコマンドに関する重要な情報については、セキュリティに関する考慮事項 (セクション 11) を参照してください。

6.2.1 STARTTLS コマンド​

引数 (Arguments): なし

応答 (Responses): このコマンドには特定の応答がありません

結果 (Result):

  • OK - starttls 完了、TLS ネゴシエーションを開始
  • NO - サーバー構成エラーのため、TLS ネゴシエーションを開始できません
  • BAD - 成功した TLS ネゴシエーション後に STARTTLS を受信したか、引数が無効

STARTTLS コマンドは平文ポートでのみ使用できることに注意してください。暗黙的 TLS ポートで STARTTLS コマンドを受信した場合、サーバーは常にタグ付き BAD 応答で応答しなければなりません (しなければなりません)。

TLS [TLS-1.3] ネゴシエーションは、サーバーからのタグ付き OK 応答の終わりの CRLF の直後に開始されます。クライアントが STARTTLS コマンドを発行したら、サーバーの応答が確認され、TLS ネゴシエーションが完了するまで、さらにコマンドを発行してはなりません (してはなりません)。一部の過去のサーバー実装は STARTTLS 処理を誤って実装しており、STARTTLS 平文コマンドインジェクション脆弱性 [CERT-555316] を含むことが知られています。この脆弱性を回避するために、STARTTLS コマンドを開始する CRLF の後に同じ TCP バッファでデータが受信された場合、サーバー実装は次のいずれかを行わなければなりません (しなければなりません)：

  1. TCP バッファからの余分なデータは、TLS ハンドシェイクの開始として解釈されます。(データが平文の場合、これにより TLS ハンドシェイクが失敗します。)

  2. TCP バッファからの余分なデータは破棄されます。

最初のオプションは、STARTTLS コマンドの開始を TLS ハンドシェイクデータとパイプライン化するクライアントにとってより親切であることに注意してください。

TLS ネゴシエーションが成功した後、TLS ネゴシエーション中にクライアント認証情報が提供された場合でも、サーバーは未認証状態のままです。これは、EXTERNAL ([SASL] で定義) などの認証メカニズムが TLS ネゴシエーションによって決定されたクライアント ID を使用することを妨げるものではありません。

TLS が開始されると、クライアントはサーバー機能に関するキャッシュされた情報を破棄しなければならず (しなければならず)、CAPABILITY コマンドを再発行すべきです (すべきです)。これは、STARTTLS 前に機能リストを変更するアクティブな攻撃から保護するために必要です。サーバーは異なる機能を通知してもよく (してもよく)、特に、成功した STARTTLS コマンドの後に STARTTLS 機能を通知すべきではありません (すべきではありません)。

例:

C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS ネゴシエーション、以降のコマンドは TLS レイヤー下>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: a004 OK Success (tls protection)

6.2.2 AUTHENTICATE コマンド​

引数 (Arguments):

  • SASL 認証メカニズム名
  • オプションの初期応答

応答 (Responses): 継続データを要求できます

結果 (Result):

  • OK - 認証完了、現在は認証済み状態
  • NO - 認証失敗：サポートされていない認証メカニズム、認証情報が拒否されました
  • BAD - コマンド不明または引数が無効、認証交換がキャンセルされました

AUTHENTICATE コマンドは、[SASL] 認証メカニズムをサーバーに示します。サーバーが要求された認証メカニズムをサポートしている場合、クライアントを認証して識別するために認証プロトコル交換を実行します。後続のプロトコル相互作用のためにオプションのセキュリティレイヤーをネゴシエートしてもよい (してもよい)。要求された認証メカニズムがサポートされていない場合、サーバーはタグ付き NO 応答を送信して AUTHENTICATE コマンドを拒否すべきです (すべきです)。

AUTHENTICATE コマンドは、[SASL] のセクション 4 で定義されているオプションの「初期応答」機能をサポートしています。クライアントはそれを使用する必要はありません。SASL メカニズムが「初期応答」をサポートしているが、クライアントによって指定されていない場合、サーバーは [SASL] のセクション 3 で指定されているように処理します。

このプロトコルの [SASL] プロファイルで指定されたサービス名は「imap」です。

認証プロトコル交換は、認証メカニズムに固有の一連のサーバーチャレンジとクライアント応答で構成されます。サーバーチャレンジは、「+」トークンとそれに続く base64 エンコード ([RFC4648] のセクション 4 を参照) された文字列を含むコマンド継続要求応答で構成されます。クライアント応答は、base64 エンコードされた文字列で構成される単一行です。クライアントが認証交換をキャンセルしたい場合、単一の「*」で構成される行を発行します。サーバーがそのような応答を受信した場合、または無効な base64 文字列 (たとえば、base64 アルファベット外の文字または非終端の「=」) を受信した場合、タグ付き BAD 応答を送信して AUTHENTICATE コマンドを拒否しなければなりません (しなければなりません)。

他のクライアント応答と同様に、初期応答は base64 としてエンコードされなければなりません (しなければなりません)。また、引用文字列またはリテラルの外部で送信されなければなりません (しなければなりません)。長さゼロの初期応答を送信するには、クライアントは単一のパディング文字 (「=」) を送信しなければなりません (しなければなりません)。これは、応答が存在するが、長さゼロの文字列であることを示します。

初期応答の base64 データをデコードする場合、デコードエラーは、通常の SASL クライアント応答と同様に、つまりタグ付き BAD 応答で処理されなければなりません (しなければなりません)。特に、サーバーは、base64 アルファベットで明示的に許可されていない文字、および文字列の末尾以外のどこかにパディング文字 ('=') を含む base64 文字のシーケンスをチェックする必要があります (たとえば、「=AAA」および「AAA=BBB」は許可されていません)。

クライアントが初期応答をサポートしていない SASL メカニズムで初期応答を使用する場合、サーバーはタグ付き BAD 応答でコマンドを拒否しなければなりません (しなければなりません)。

[SASL] 認証交換を通じてセキュリティレイヤーがネゴシエートされた場合、クライアントの場合は認証交換を終了する CRLF の直後に、サーバーの場合はタグ付き OK 応答の CRLF の直後に有効になります。

クライアントおよびサーバー実装は AUTHENTICATE コマンド自体を実装しなければなりませんが (しなければなりませんが)、[PLAIN] で説明されている PLAIN メカニズム以外の認証メカニズムを実装する必要はありません。また、認証メカニズムは任意のセキュリティレイヤーをサポートする必要はありません。

注意: サーバー実装は、STARTTLS コマンドがネゴシエートされたか、暗黙的 TLS ポートで TLS がネゴシエートされたか、またはセッションをパスワードスヌーピングから保護する他のメカニズムが提供されていない限り、平文パスワードメカニズムを許可しない構成を実装しなければなりません (しなければなりません)。サーバーサイトは、パスワードスヌーピングに対するそのような保護メカニズムなしに平文パスワードメカニズムを許可する構成を使用すべきではありません (すべきではありません)。クライアントおよびサーバー実装は、[RFC4752] で説明されている GSSAPI メカニズム、SCRAM-SHA-256/SCRAM-SHA-256-PLUS [SCRAM-SHA-256] メカニズム、および/または相互 TLS 認証用の EXTERNAL [SASL] メカニズムなど、平文パスワードを使用しない追加の [SASL] メカニズムを実装すべきです (すべきです)。

サーバーとクライアントは複数の認証メカニズムをサポートできます。サーバーは、クライアントがどの認証メカニズムを使用するかを知るために、CAPABILITY コマンドへの応答でサポートされている認証メカニズムをリストすべきです (すべきです)。

サーバーは、機能を自動的に送信するために、成功した AUTHENTICATE コマンドのタグ付き OK 応答に CAPABILITY 応答コードを含めてもよい (してもよい)。クライアントがこれらの自動機能を認識する場合、個別の CAPABILITY コマンドを送信する必要はありません。これは、AUTHENTICATE コマンドによってセキュリティレイヤーがネゴシエートされなかった場合にのみ行うべきです。AUTHENTICATE コマンドの一部としてのタグ付き OK 応答は、暗号化/完全性チェックによって保護されていないためです。[SASL] は、この場合にクライアントが CAPABILITY コマンドを再発行することを要求します。サーバーは、成功した AUTHENTICATE コマンドの後に異なる機能を通知してもよい (してもよい)。

AUTHENTICATE コマンドが NO 応答で失敗した場合、クライアントは別の AUTHENTICATE コマンドを発行して別の認証メカニズムを試してもよい (してもよい)。LOGIN コマンドを使用して認証を試みてもよい (してもよい) (詳細についてはセクション 6.2.3 を参照)。つまり、クライアントは優先順位の降順で認証タイプを要求してもよく (してもよく)、LOGIN コマンドを最後の手段としてもよい (してもよい)。

認証交換中にクライアントからサーバーに渡される認可 ID は、クライアントが権限を要求しているユーザー名としてサーバーによって解釈されます。

例: (初期応答付き)

S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI LOGINDISABLED] Server ready
C: A01 STARTTLS
S: A01 OK STARTTLS completed
<TLS ネゴシエーション、以降のコマンドは TLS レイヤー下>
C: A02 CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
S: A02 OK CAPABILITY completed
C: A03 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: A03 OK Success (tls protection)

6.2.3 LOGIN コマンド​

引数 (Arguments):

  • ユーザー名
  • パスワード

応答 (Responses): このコマンドには特定の応答がありません

結果 (Result):

  • OK - ログイン完了、現在は認証済み状態
  • NO - ログイン失敗：ユーザー名またはパスワードが拒否されました
  • BAD - コマンド不明または引数が無効

LOGIN コマンドは、クライアントをサーバーに識別し、このユーザーを認証する平文パスワードを運びます。LOGIN コマンドは、最後の手段として (AUTHENTICATE コマンドを使用して 1 回以上認証を試みて失敗した後)、使用すべきではなく (すべきではなく)、クライアント実装には LOGIN コマンドの自動使用を無効にする手段があることが推奨されます。

サーバーは、機能を自動的に送信するために、成功した LOGIN コマンドのタグ付き OK 応答に CAPABILITY 応答コードを含めてもよい (してもよい)。クライアントがこれらの自動機能を認識する場合、個別の CAPABILITY コマンドを送信する必要はありません。

例:

C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed

注意: 不安全なネットワーク (インターネットなど) 上で LOGIN コマンドを使用することはセキュリティリスクです。なぜなら、ネットワークトラフィックを監視している人は誰でも平文パスワードを取得できるからです。そのため、クライアントは不安全なネットワーク上で LOGIN を使用してはなりません (してはなりません)。

クライアントが暗黙的 TLS ポート [RFC8314] で IMAP サービスにアクセスしている場合、STARTTLS コマンドがネゴシエートされた場合、またはセッションをパスワードスヌーピングから保護する他のメカニズムが提供されている場合を除き、サーバー実装は、LOGINDISABLED 機能を通知し、LOGIN コマンドを許可しない構成を実装しなければなりません (しなければなりません)。サーバーサイトは、パスワードスヌーピングに対するそのような保護メカニズムなしに LOGIN コマンドを許可する構成を使用すべきではありません (すべきではありません)。LOGINDISABLED 機能が通知されている場合、クライアント実装は LOGIN コマンドを送信してはなりません (してはなりません)。

に最終更新