要約

  • UNAUTHENTICATE は、管理用クライアントが IMAP 接続を未認証状態へ戻し、別の利用者のために再利用する仕組みだ。TLS は残るが、前の利用者のアプリケーション上の権限や状態をそのまま引き継いではならない。
  • これは一切の情報を消す操作ではない。選択中のメールボックスからメッセージを消去せず、TLS 証明書も失効させない。IMAP ID との関係には実装に委ねられる部分がある。
  • 最初の認証だけを調べ、その後は通信を素通しするプロキシでは、次の認証に同じ制限が及ばない場合がある。接続の再利用を認めるには、最初のログインの成功とは別の証拠が必要になる。

接続を切る処理にも役割があった

一つの接続が一人の利用者に対応している間は、接続の終わりが仕事の終わりを示す。次の利用者は別の入口から入る。この対応関係を前提にしていれば、認証を確認する場所、利用者ごとの情報を保持する期間、後段へ通信を渡すタイミングも比較的説明しやすい。

複数の利用者に代わって処理する管理用システムにとって、その分かりやすさには費用がかかる。毎回接続を開き、保護された通信路を確立する作業が繰り返されるからだ。RFC 8437 の UNAUTHENTICATE は、この通信路を残しながら、アプリケーション上の利用者をいったん退場させる方法を定めている。

ここで短くなるのは接続を準備する手順であって、次の利用者を認めるための判断ではない。接続の寿命と利用者の権限の寿命が一致しなくなれば、それまで同じ境界に乗っていた処理を分けて説明しなければならない。何を残し、何を捨て、誰が次の要求を認めるのか。効率化の条件はこの三つに分かれる。

本稿は、プロトコルに書かれた条件と、その運用上の意味を検討するものだ。実際のメールアカウントを切り替えた試験、プロキシの制限を回避する実験、特定製品の性能測定は行っていない。文書にある懸念を、確認済みの事故や脆弱性に読み替えることはできない。

「未認証に戻る」は「接続を閉じる」ではない

UNAUTHENTICATE によって追加されるのは、認証済み状態またはメールボックス選択状態から、未認証状態への遷移である。メールボックスが選択されていれば選択を解除するが、その際にメッセージの expunge は行わない。TLS の状態も維持される。LOGOUT の別名でも、メールボックスを空にする命令でもない。

命令には引数がなく、成功時には OK が返る。BAD が対応するのは、使用できない状態、能力が通知されていない場合、構文の誤りなどだ。NO という応答は認められない。サーバーが状態を初期化できなければ、タグなしの BYE を送って接続を閉じることができる。

この応答規則は、効率化の優先順位を示している。状態の切り替えを保証できないときまで接続を守る必要はない。クライアントが未認証に戻ったと思っているのに、サーバー側では前の利用者として動き続ける、といった曖昧な継続を正当化する規則ではない。

その後の AUTHENTICATE や LOGIN は、利用可能な能力に従って実行する。なお、UNAUTHENTICATE の能力は認証後にだけ通知される場合がある。最初の能力一覧だけで対応の有無を決めず、認証後に CAPABILITY を再確認する必要が生じ得る。観測した時点の違いを、実装の不一致と早合点すべきではない。

往復回数にも条件が付く。有効な SASL セキュリティ層がない場合には、後続の AUTHENTICATE をパイプライン化できる。SASL-IR と組み合わせれば、管理用の再認証を一往復で行える場合がある。ただし、すべての接続や認証方式で同じ短縮が得られるという約束ではない。文書上の可能性と、対象環境で測定した効果は分けて扱う必要がある。

消すべきものは、利用者名だけではない

認証済みの利用者名を変更しただけでは、接続が新しい利用者のために使えるとは限らない。サーバーはその名前に基づいて、権限の判断、検索の状態、通知の設定などを保持しているかもしれない。RFC が求めているのは、表示上の名前の交換ではなく、こうしたアプリケーション状態の切り替えだ。

UNAUTHENTICATE を通知して使用する場合、拡張機能の状態を初期化する必要がある。例外として扱われる STARTTLS と ID を除き、将来追加される拡張機能もこの問題から自由ではない。導入時に存在した機能だけを確認して、その後の拡張には同じ検討を行わない、という運用では責任が抜け落ちる。

具体例の一つは、ACL のために保持している認証主体やグループ所属のキャッシュである。これを消すのは、前の利用者の判断材料を次の利用者に持ち越さないためだ。永続的なアクセス制御規則そのものを削除する話ではない。この二つを混同すると、安全のための初期化をデータ破壊のように説明してしまう。

CONDSTORE は未有効化として扱い、ENABLE によって有効になった機能はすべて無効にする。SEARCHRES の保存済み検索結果は空に戻す。LANGUAGE は i-default に戻す。サーバー上のすべての検索コンテキストには暗黙の CANCELUPDATE が作用し、NOTIFY は基本の動作へ戻る。それぞれ保持する対象が違うため、一項目の成功でほかも正しく処理されたとはいえない。

例えば新しい利用者が自分のメールボックスを開けたとしても、それは古い検索コンテキストがなくなった証拠ではない。権限キャッシュが消えたとしても、通知設定の初期化までは証明しない。これは不具合の存在を断定する説明ではなく、確認すべき対象を分ける説明である。

機能が増えるほど、この責任の所在が重要になる。認証モジュールを変更していなくても、新しい拡張が利用者ごとの情報を保持するなら、接続再利用の前提が変わる。初期化を認証担当者だけの仕事にしておくと、別の担当者が追加した機能が検討から漏れる可能性がある。

継続する TLS と、終了する SASL

通信の保護を一語で「暗号化」と呼ぶと、切り替えの境目が見えなくなる。UNAUTHENTICATE は TLS を維持する一方で、SASL セキュリティ層の終了位置を別に定めている。

クライアントから送る方向では、UNAUTHENTICATE 命令を終える CRLF の直後に SASL セキュリティ層が終了する。サーバーから送る方向では、成功応答 OK を終える CRLF の直後だ。両方向で同じ瞬間に何もかも消える、という規則ではない。

COMPRESS にも、それぞれの送信方向で対応する終了位置がある。該当する場合には、SASL より先に圧縮を終了する。これらは次のバイト列をどう解釈するかを決める規則であり、単なる実装上の好みではない。終端について両側の認識が違えば、「接続は生きている」という確認だけでは不足する。

RFC 4422 は SASL の枠組みを説明するが、別の再認証に関する一般的な扱いを、そのまま UNAUTHENTICATE に当てはめてはならない。本稿で問題にしている切り替えでは、RFC 8437 の具体的な終了規則が判断の基準になる。

運用側が求めるべきなのは、保護されたままか否かという一つの答えではない。TLS が続く証拠と、古い SASL 層や圧縮が指定の位置で終わる証拠は異なる。本稿は実際の通信を採取していないため、その動作が特定の環境で正しいとは結論できない。規則を読むことと、動作を確かめることの境界はここにもある。

証明書の継続と、利用者への委任を分ける

同じ管理用クライアントが何人もの利用者に代わって働くには、認証と認可の区別が欠かせない。RFC 4422 は、資格情報によって認証される主体と、その主体が要求する認可上の主体を分けている。サーバーは資格情報を検証するだけでなく、要求された主体として行動する権利も確認しなければならない。

EXTERNAL は、SASL の外部ですでに確立された資格情報を利用する方式で、必要に応じて認可上の識別子を運ぶ。EXTERNAL 自体はセキュリティ層を提供しない。事前の合意なしに、外部資格情報の由来が必ず TLS だとクライアントが決めつけることもできない。十分な外部の保護が必要である。

RFC 8437 では、TLS クライアント資格情報を残しながら、アプリケーション上の結び付きを解除する。管理用証明書によって複数の利用者のために動けることがあっても、その範囲は認可に従う。証明書を持っていれば任意のメールアカウントになれる、という意味ではない。

文書には、imaps 接続が既定の利用者として PREAUTH を受けた場合の条件付きの説明もある。その結び付きを外してから EXTERNAL による代理認証を行うには、UNAUTHENTICATE の能力が通知されている必要がある。これはすべての TLS 接続がそのように始まるという説明ではなく、特定の初期状態からどう移るかという説明だ。

したがって、監査で問うべきことも分かれる。証明書が継続しているか。前の利用者とのアプリケーション上の結び付きは外れたか。次の利用者として行動する権利は認められたか。最初の答えだけで、残る二つを代用してはいけない。

残る情報があること自体を隠さない

IMAP ID はさらに別の性格を持つ。RFC 2971 が扱うのはソフトウェアなどの実装情報であり、メールボックス利用者を認証する資格情報ではない。RFC 8437 は、ID と UNAUTHENTICATE の相互作用を実装に委ねている。

このため、「一切の過去情報が消える」と説明するのは正確でない。どの ID 情報が残るのか、どのように記録されるのかを別途確かめる必要がある。一方で RFC 2971 は、ID 情報に基づいて動作を変更したり、最適化したり、利用を拒否したりすることを認めていない。情報の開示を減らすことや NIL を返すことはできるが、虚偽の情報を返してよいわけではない。

同文書が指摘する一意の識別子や記録によるプライバシーへの影響も、会話状態の初期化とは別の検討対象だ。メール処理の状態が適切に戻ったことと、追跡につながる情報が最小限であることは、同じ試験結果では示せない。

RFC 8437 は、データセンター間で接続を再利用すると、一部のトラフィック分析を難しくする可能性にも触れている。ただし、匿名性の保証ではない。本稿で測定した効果でもない。残る情報を明記したうえで、どの観測が難しくなり得るのかという限定付きの議論として扱うべきだ。

最初の関門を二度通るとは限らない

接続の再利用が認可の配置を変えることは、プロキシを考えると分かりやすい。最初の認証を調べた後に接続先を決め、以後の通信を素通しするプロキシがあるとする。そこで利用者が切り替われば、次の認証は後段のサーバーだけで処理されるかもしれない。

RFC 8437 は、この構成ではプロキシに存在し、後段に存在しない制限を回避できる場合があると警告する。あらゆるプロキシに欠陥があるという主張ではない。最初の認証後に何を調べなくなるか、どの制限がどこにだけ存在するかという条件に依存する。

仕様は UNAUTHENTICATE を無効にする仕組みを必須とする。プロキシが命令を処理すれば、この指摘された懸念は解消すると説明し、管理用の認証主体だけに機能を限定する案も挙げる。ただし、「管理用だから安全」という言葉で委任の範囲を省略してよいわけではない。使える主体を絞ることと、その主体の権限を明確にすることは両方必要だ。

もう一つ、明示された非互換性がある。認証した主体に応じて OS 上の実行主体を切り替え、ログイン時に管理権限をすべて放棄する実装は、この再利用モデルと両立しない。権限を失う設計は、安全境界として選ばれている可能性がある。再利用できないことだけをもって劣った設計と評価したり、特定の OS 全般を危険と見なしたりする根拠にはならない。

同 RFC が述べる効率と安全性への配慮の違いは、実測された優劣ではなく、適合する設計の違いとして読むのが妥当だ。未認証に戻す命令を独立させた理由についても、認証処理の入口を単純に保つことや機能を無効にしやすくすることが挙げられている。これは文書の設計理由であり、開発者の動機を外から推測したものではない。

仕様から言えることを越えない

調査時点で RFC 8437 の errata、RFC 4422 の errata、RFC 2971 の errata は、該当する記録を返さなかった。これは参照した仕様の状況であり、実装の無欠陥を証明するものではない。

Lu Heng の意思決定とその帰結の負担を論じた文章に照らせば、問いは「誰が節約を承認し、その後の分離を誰が保証するのか」となる。効率を求める意図を疑うための問いではない。利益が一つの指標にまとまり、責任が複数の部署に散らばる構造を見落とさないための問いだ。

同じく、現実の説明を主張の宣伝より優先するという姿勢は、本稿の結論にも制限を課す。確認できたのは、何を残し、何を初期化し、どの構成で警戒すべきかという仕様である。特定の導入先がすでに安全であるとも、問題を起こしているともいえない。

接続を残す価値はある。その価値を認めるために、前の利用者まで残す必要はない。次の利用者が認められた証拠と、前の利用者が退場した証拠を別々に要求することが、再利用を合理的な運用判断にする。