要約

  • 公開鍵で署名した認証メッセージは、送信者を示せても再送を自動では防がない。DASSは時刻印と受信済みメッセージの記録で、この問題に対処しようとした。
  • この選択は往復回数を抑える一方、時計のずれ、時刻の巻き戻し、サーバー再起動後の状態保持を認証経路に持ち込んだ。
  • RFC 1507はDASSをExperimentalとして記述する。設計の説明から、実運用の規模や採用状況を推定することはできない。

署名が正しくても、同じ要求は何度でも届く

RFC 1507が扱うのは、暗号の正しさとネットワーク上の一度限りの利用が別問題だという点だ。受信側が署名を検証できても、盗聴者が同じ署名付きメッセージを別のサーバーに送ったり、同じ相手に何度も送り直したりすれば、認証要求が再利用されるおそれがある。署名は鍵の所持を示せるが、「この宛先への、この時点での一回の要求」という条件までは自動で与えない。

DASSが比較するのはチャレンジ・レスポンスと時刻印だ。前者はサーバーが新しい値を出し、クライアントがその値を含めて署名する。使い捨ての値を確認できる反面、追加の通信が必要になる。時刻印方式なら、クライアントは現在時刻を署名対象に含める。サーバーは許容範囲より古いものを拒否し、窓の中ですでに見たメッセージを記憶する。DASSは、接続確立のメッセージに認証を重ねやすく、交換回数を抑えられるという理由から後者を採った。

この選択は、単に時計を読むだけでは完了しない。サーバーは受け入れた認証メッセージを一定期間保持しなければならない。再起動後にその履歴が失われ、攻撃者が同じ窓内で再送できれば、検出の前提が崩れる。RFCは、この状態を安定した記憶域に残す必要があると説明している。

数分の誤差が暗号の外で結果を変える

DASSの時刻要件は、証明書の有効期限を確かめる場合と、再送を検出する場合とで異なる。証明書やチケットの日付確認は数時間程度の精度で動くとされた。一方、再送検出にはネットワーク内で数分以内にそろう単調増加の時刻が必要だ。時計のずれが大きければ、正しい要求も拒否される。サーバーの時計を過去へ戻し、その後に期限切れメッセージを送ると、受け入れられる可能性もあるとRFCは指摘する。

つまり、暗号鍵が正しく管理されていても、時刻サービス、クロックの単調性、サーバーの保持状態が崩れれば認証の結果が変わる。これは暗号の検証を無意味にするという話ではない。署名検証が証明する範囲と、要求の新しさを確かめる制御が証明する範囲を分ける必要がある。

その時刻印を持つのは誰の資格情報か

時間窓の中で要求を再送できないようにするには、メッセージが誰のものかだけでなく、どの主体がどの機械から送ったのかも分かる必要がある。DASSは人とコンピューターをともに principal と見なす。ユーザー資格情報とノード資格情報を別々に持たせ、両者が同じ要求に署名できるようにした。受信側は「ユーザーは本人か」と「その要求を運んだノードは何か」を別々に確認できる。

この二つはローカルアカウントの問題とも結び付く。ある利用者が十台の機械にアカウントを持てば、従来のリモート資源は十個の名前を管理しなければならない。DASSはユーザーにグローバルな名前を与え、どのノードから来ても同じ主体として認識することを目指した。とはいえ、受信ホストは依然としてその主体を自分のアカウントへ対応付ける。.rhostsに似た既存の仕組みを拡張し、複数の中継機を一つずつ列挙しない形が橋渡しとして想定された。

ユーザーのログイン後、資格情報はプロセスに関連付けられ、必要なら遠隔サービスへ委任される。サービスがさらに別のサービスを呼び出す場面では、ユーザーが毎回パスワードを入力しなくてもよい。ただし、RFC 1507の委任制限は時間が中心で、目的ごとの最小権限ではなかった。短い期限を設けても、そのサービスが有効時間内に何を実行できるかまでは限定されない。

公開鍵の名前はX.500の木をたどった

資格情報を送るだけでは、受信側は公開鍵と名前の対応を信じられない。DASSでは認証局（CA）が名前と公開鍵を結び付ける証明書を署名する。CA同士の証明書はX.500の命名階層と連動し、親、子、交差証明書をたどって遠いディレクトリの principal に至る。各サーバーがネットワーク上の全員の鍵を個別に登録する必要を減らす設計だった。

階層はCAの権限を制限しようともする。下位のCAが侵害された場合、影響はおおむねそのディレクトリ分岐と関連する信頼経路に収まるとRFCは説明する。だが、そのCAが担当範囲内の名前を誤って認証できることに変わりはない。階層が制限するのは到達範囲であり、誤発行や運用ミスが起きないという保証ではない。

そのため、証明書の取り消しも名前サービスと切り離せなかった。DASSは二つの方法を提示する。一つは証明書を期限付きにし、定期的に更新する方法だ。通常の期限は約一年、運用負荷を抑える更新間隔は数カ月単位になり得る。鍵の漏えいに即応するには遅い。もう一つは、名前サービスに有効な証明書だけを載せ、存在しない証明書を受け入れない方法だった。こちらは迅速にできる一方、複製とキャッシュの遅延が残り、認証の可用性と撤回の安全性がそのサービスに依存する。DASSは当時、X.509の失効リストをサポートしていなかった。

仕様の隣にある文書が示す範囲

RFC 1507はDASSをExperimentalと明記し、Internet Standardではないとする。付録にはGeneric Security Service APIへの対応例がある。RFC 1508は仕組みに依存しないAPIを別途定義し、RFC 1509はC言語のバインディングを規定した。これらはアプリケーションから利用できる形を設計していた証拠にはなるが、どの程度使われたかは示さない。

同時期にはRFC 1510のKerberos V5もあり、RFC 1704は複数の認証方式を後に概観した。これらを並べても、勝者や導入数、DASSがその後どうなったかは分からない。標準の分類と実装の採用は別の証拠である。

DASSの記録は、認証が一つの署名検証で終わらない理由を具体化する。ユーザー名、ノード名、証明書経路、委任期間、時計、再送履歴、取り消し状態が個別に働く。どれか一つの成功を、残りの成功やアクセス許可の証拠に置き換えてはならない。

出典