要約

  • RFC 2444は、アプリケーションごとの場当たり的なOTP解析を、名前と交換形式を持つSASL機構に置き換えた。
  • OTP機構が行うのは認証交換である。セキュリティ層、セッション秘匿、サーバー認証、能動攻撃への防御は含まれない。

「ログインできた」と「その後の通信も守られている」は同じ事実ではない。1998年のRFC 2444が扱ったのは、まず最初の事実をどう標準化するかだった。当時、OTPはアプリケーションに場当たり的に組み込まれ、実装ごとのヒューリスティックな解析に頼っていた。RFC 2444はSimple Authentication and Security Layer（SASL）にOTPという機構を定め、個々のプロトコルが独自のパスワード解析方法を作らずに済む入口を用意した。

ただし、この統一は通信路全体の保護ではない。RFC 2222のSASLは、ユーザー認証と、その後の通信に適用し得るセキュリティ層を別の性質として扱う。RFC 2444は自分の機構がセキュリティ層を提供しないと明記し、セッションの秘匿、サーバー認証、能動攻撃の防止も約束しない。認証に成功した応答が返っても、次のコマンドが流れる接続については、別の仕組みを確認しなければならない。

具体的な形式は、RFC 2289のOTPシステムとRFC 2243の拡張応答に基づく。サーバーはhex、word、init-hex、init-wordの四形式を扱う必要がある。前二つは応答を送り、init-付きの形式はシーケンスの再初期化も行う。MD5のサポートは必須、SHA-1は推奨だった。シーケンス番号が低すぎる場合、クライアントはその失敗を示し、再設定の選択肢をユーザーに提示することが望ましい。OTPを使うたびに認証データベースの項目は更新される。つまり標準はメッセージの形をそろえる一方、互換性と状態管理を実装・運用側の課題として残した。

RFC 2444は、信頼できないクライアント、たとえばキオスク端末を用途の例に挙げる。盗み見られたOTPが、その端末にユーザーの代理操作を許すのは一回だけ、という考え方だ。しかし、それは認証後のセッションを守るという意味ではない。認証データベースが漏えいした場合には辞書攻撃の対象になり得るとも述べる一方、保存形式を平文同等にする必要はないとしている。さらに、受動的な辞書攻撃と、基礎となるOTP仕様に記された競合攻撃にも言及する。「一度だけ」という呼び名だけで、リスク全体を片付けることはできない。

SASLでは認証IDと認可IDも別だ。前者は資格情報が属する識別子、後者は要求する権限の識別子であり、代理操作では一致しない場合がある。認可IDが空なら、サーバーが資格情報から補うこともできる。OTPが正しかった事実と、その人物に何を許すかは別の判断なのである。機構名、チャレンジの形式、各アプリケーション・プロトコル上の符号化、通信路の保護、サーバーの同一性、認可ルールを一つの「認証済み」表示に押し込めてはならない。

RFC 2444は1997年のSASL文書を更新し、S/Key SASL機構の用途をOBSOLETEへ変更した。その後、RFC 4422がSASLの基本文書を置き換え、RFC 5034はPOP3向けプロファイルを、RFC 5802は別機構であるSCRAMを定義した。これは枠組みの変遷を示すもので、RFC 2444が広く導入された証明ではない。また、1998年に書かれたアルゴリズム要件を現代向けの暗号指針として読む根拠にもならない。RFCが記録するのは規範上の設計であり、実装数ではない。

歴史上の成果は限定的だからこそ明瞭だ。OTPを組み込む共通の呼び出し口を定めたこと。その後は、SASLトークンを運ぶ方法をプロトコル設計者が定め、実装者がシーケンスの更新を整合させ、運用者が認証後の通信路を守り、アプリケーションが認可範囲を決める必要が残る。一度きりなのは応答の再利用可能性であり、セッションの安全性ではない。

参考資料