要約

  • RADEXTのRadSec作業部会草案第18版では、Response Authenticatorの検証に失敗した応答をクライアントが破棄しても、(D)TLS接続は開いたままにしなければならない。対応する保留中の要求がない応答にも同じ扱いを義務付ける。IESGで審議中の草案であり、承認済みRFCではない。
  • 要求のタイムアウト後に1オクテットのIdentifierを再利用すると、前の要求への応答が新しい要求の文脈で検証され、失敗する競合があり得る。応答を通してよいという意味ではなく、真のMessage-Authenticator失敗まで接続維持の例外にするものでもない。

問題の中心にあるのは、暗号化された経路そのものではなく、遅れて届いた一つの応答である。クライアントが要求Aを諦め、そのIdentifierを要求Bに割り当てる。そこへサーバーがAへの応答を送ってくる。クライアントの現在の表にはBがあり、応答のResponse AuthenticatorをBの要求情報で確かめれば一致しない。応答を採用する余地はない。しかし接続まで切る必要があるのか、という別の問いが残る。

9月30日付のdraft-ietf-radext-radiusdtls-bis-18は、ここで処分の単位を狭める。第3.12節は検証に失敗した応答について、破棄すると同時に接続を維持するようクライアントに求める。保留中の要求に対応しない応答も同様だ。第17版ではResponse Authenticatorの失敗が接続を閉じる側の一覧にあり、対応要求のない応答は閉じるかどうかを実装が選べた。新しい付録A.1は、タイムアウトと識別子の再割り当てで誤った照合が生じる順序を具体化している。これは失敗した認証を無視する変更ではなく、失敗の影響範囲を見直す変更だ。

比較対象のRFC 6613は、RADIUS/TCPでResponse Authenticatorが失敗した場合にTCP接続を閉じる規則を持つ。要求と結び付かない応答については接続維持も切断も許した。Identifierは1オクテットなので、一つの接続で表せる値は256個に限られる。負荷が高ければ、期限切れになった要求の番号がすぐに再利用され得る。古い応答が新しい要求より遅く、しかしサーバーが新しい要求を処理するより早く到着する、という窓ができる。中継点を挟む場合はタイムアウト設定の差も、応答が宛先を失う原因となる。草案は可能な機序を説明しており、特定の事業者で障害が起きたとは述べていない。

例外の外側を見落としてはならない。不一致の応答はあくまで捨てる。Response Authenticatorで既に落としたパケットについて、続けてMessage-Authenticatorを検査する意味はないというのが草案の整理だ。逆に、要求との対応が妥当でMessage-Authenticatorだけが失敗した場合、接続を閉じる境界は維持される。サーバーがクライアントを受け入れられないと判断すれば、(D)TLSを直ちに終了し、RADIUS/TLSではTCPも閉じる。すべてを同じ「認証エラー」にまとめると、今回の改訂が守ろうとする境界が消える。

実装の確認には、エラー数だけでは足りない。応答に対応する要求がまだあったか、どの検証で止まったか、その応答が本当に破棄されたか、接続で後続の正しい交換が続いたかを区別して記録する必要がある。草案はパケットのコード、ID、違反規則などをログに残し、接続を保つ場合は無視したパケットのログを流量制限するよう勧める。この検証項目の組み立ては編集上の運用提案であって、IETFが新しい監視データ形式を制定したという意味ではない。

Datatracker上の状態は、RADEXT作業部会の活発なInternet-Draft、IESG Evaluation::AD Followupで、目指す位置付けはProposed Standardだ。RFC 6614とRFC 7360を置き換えるとの表記には「承認されれば」という条件が付く。今回の教訓は、応答への不合格判定を、そのまま接続全体への不信任票にしてはならない場合がある、という限定されたものだ。

出典