要約

  • RFC 4422は、資格情報に結び付く認証アイデンティティーと、クライアントがその名で行動したい認可アイデンティティーを別々に検証させる。
  • SASL交換の成功はセッション状態やセキュリティー層を確立できるが、アプリケーション内の各操作を許可する万能な証明書ではない。

成功表示から主語が落ちるとき

利用者にとって緑のチェックは便利だ。しかし「認証成功」という短い表示は、何に成功したのかを省略している。パスワードや証明書が受理されたのか、別の主体として振る舞うことも許されたのか、あるサービスに入場できるのか、そこで一件の操作を実行できるのか。実装がこれらを一つの状態へ畳み込むほど、成功の意味は曖昧になる。

SASLは、接続型のアプリケーションプロトコルと交換可能な認証メカニズムの間に置かれる枠組みだ。メカニズムは資格情報をどう確かめるかを定め、各プロトコルのプロファイルは交換をどう運び、その結果を自らの状態へどう反映するかを定める。

この分業により、古いプロトコルも新しいメカニズムを利用できる。一方、メカニズムはメールボックスや管理コマンドの意味を知らない。成功時にセキュリティー層が始まる場合でさえ、すべての資源が開いたとは言えない。次の要求を拒むことは、先の成功を否定するのではなく、別の判断を実行している。

同じに見える二つのアイデンティティー

RFC 4422は、認証アイデンティティーと認可アイデンティティーを概念上分ける。前者は資格情報が示す主体で、後者はクライアントがその名で行動することを求める主体だ。

通常のログインでは両者が同じため、区別は表に出ない。認可アイデンティティーの文字列が空なら、クライアントはサーバーが資格情報に結び付けた主体として行動したいと求める。しかし代理処理では、Aが自分の資格情報を提示しながら、Bとしての行動を申請できる。

サーバーはまずAの資格情報を確かめ、次にAがBを名乗ってよいかを確かめる。片方でも失敗すれば交換は失敗する。有効な資格情報を持つことと、別の主体を代理することの間に自動的な橋はない。

さらに、受理された認可アイデンティティーも全権限の集合ではない。それは当該プロトコルの認可状態に使う身元である。Bがどの資源を読み、どの操作を行えるかは、その後のアクセス制御が決める。

プロファイルが残りの意味を引き受ける

共通枠組みは、すべてのアプリケーションに同じ身元体系を押し付けない。SASLを採用するプロトコルは、メカニズムの提示と選択、チャレンジと応答の運搬、認可アイデンティティーの形式、セキュリティー層の開始位置、複数回認証の影響などを記述しなければならない。

これは文書作成上の形式ではなく、意味の所有者を定める取り決めだ。ネットワーク上の文字列は、ローカルな正規化を経て内部アカウントに対応し、グループや属性を介して資源ポリシーへ届くことがある。きれいなSASL記録は、その対応表が新しく、曖昧でなく、過大でもないことまでは保証しない。

交換可能性には、境界を説明する責任が伴う。認証担当が「アプリ側で判断する」と考え、アプリ担当が「認証基盤が許可済みだ」と考えれば、実際には誰も操作を評価しない空白が生まれる。

SMTPの235が伝える範囲

SMTP AUTHでは成功の対象が明瞭だ。RFC 4954の235 2.7.0 Authentication SucceededはAUTHコマンドへの応答であり、認可アイデンティティーをSMTPセッションに関連付ける。その後のメール取引についての受領書ではない。

AUTHでセキュリティー層を確立した場合、SMTP状態はいったん初期化される。以前に得た機能情報を捨て、クライアントはEHLOを改めて送ることが望まれる。認証成功がアプリケーション対話を終えるどころか、整然と再開させる場合がある。

中継方針、宛先検査、コンテンツ制御、キュー、配送は別の段階にある。ここでの要点は配送論ではなく、明確な数値コードにも「どのコマンドへの答えか」という射程があることだ。

誰も特定しないSASL成功

RFC 4505のANONYMOUSは、利用者が身元を確立も開示もせず、通常は制限付きでサービスへ入るためのメカニズムだ。任意の追跡情報には認証がなく、偽ることもできる。

したがって、ログにSASLの成功があるだけでは「本人確認済み」と分類できない。まず、そのメカニズムが何を主張するものかを読まなければならない。匿名アクセスを検証済み人物として保存すれば、標準が意図して残した違いを監視側が消してしまう。

強い暗号は権限表を更新しない

RFC 7677はSCRAM-SHA-256とSCRAM-SHA-256-PLUSを登録した。SHA-256の採用やチャネルバインディングへの対応は、資格情報交換の強度を高める。だが、そのメカニズムには個々のメールボックスやコマンドの所有関係は見えない。

弱いメカニズムを置き換えても、広すぎるグループ、失効し忘れた代理規則、誤った資源ポリシーは残る。暗号の確からしさは認可判断の材料にはなるが、判断そのものを代行しない。

「誰」を一つの欄に押し込まない

事故調査に必要なのは、選択されたメカニズム、チャネル保護、資格情報から得た認証アイデンティティー、要求された認可アイデンティティー、受理された結果、代理を許した規則、そして後続操作の認可結果だ。

これらを単一の「ユーザー」欄へ縮めると、資格情報の盗用、代理範囲の誤り、ディレクトリー対応の古さ、アプリケーション権限の過大付与を区別できない。プロトコルを先へ進める一ビットの成功と、責任を再構成する証拠は別物である。

画面上の言葉も同様だ。「この身元でサインイン中」はセッションを表す。「この項目を変更できます」は具体的な認可を表す。この差を示せば、ログイン直後の拒否を不可解な故障ではなく、サービス固有の制御として説明できる。

情報源