要約

  • 480 は、現在の接続状態ではコマンドを利用できないという拒否であり、認証後の自動実行予約ではなかった。
  • AUTHINFOに成功すると身元と利用可能な機能は変わり得るが、元の操作はクライアントが改めて送らなければならなかった。
  • 認証は包括的な認可ではない。再送した要求も、サイト固有の方針によって 502 で拒否され得た。

281のあとに残った沈黙

クライアントが GROUP local.research を送り、サーバーが 480 Permission denied と返す。次にクライアントは利用できる認証方式を確認し、AUTHINFOを完了して 281 Authentication accepted を得る。しかし、その時点では何も選択されていない。

必要なのは二度目の GROUP local.research である。一度目の要求は応答を受けて終了しており、サーバー内で凍結されたまま資格情報を待っていたわけではない。見かけ上同じ文字列でも、二度目は新しい身元状態のもとで発生する別の行為だ。

人向けのソフトウェアは、この手順を「保護された場所を選び、ログインして続く」という一つの画面遷移に見せられる。けれども通信記録には、拒否、身元の確立、意図の再提示という三つの境界が残る。

普及した実装が先に再送を定めた

RFC 2980 は、既存のNNTP実装で使われていた拡張を記録した。初期の AUTHINFO USER と AUTHINFO PASS では、480 の後に利用者名を送り、必要なら 381 に応じてパスワードを送り、受理されれば 281 を受け取る。その次にクライアントがすべきことは、480 を受けた元のコマンドを再試行することだった。サーバーは再送されたコマンドを通常どおり評価する。

この順序は、資格情報に余分な意味を持たせない。資格情報は接続の主体を示すが、先ほどの要求が今も必要かどうかまでは語らない。認証の途中で利用者が操作をやめることも、クライアントが別の機能構成を発見することもある。再送は、その時点の意思を新しい証拠として残す。

一方、古いUSER/PASS方式は重大な弱点を抱えていた。RFC 2980は認証情報がすべて平文で送られると明記した。操作を正しく分けても、秘密は守られない。保護された通信路は別に必要だった。

AUTHINFOは認証と認可を統合しなかった

RFC 4643 はAUTHINFOを正式化し、互換性のためUSER/PASSを残しながらSIMPLEとGENERICを廃止し、SASLの利用方法を定義した。同RFCは最初に権限の境界を置く。AUTHINFOが扱うのは利用者の認証であり、認可は各サイトの方針である。

したがって 480 は、コマンドまたは資源を利用するために認証や認可が必要だと伝えるにすぎない。認証後に利用できる可能性はあるが、保証ではない。身元が正しくても、そのニュースグループの権利がなければ 502 を返せる。

281 が証明する範囲も狭い。それはこのセッションの認証交換が受理されたことを示す。すべてのグループの閲覧権、投稿権、ピア転送権、記事の著者性を証明しない。コンテンツ署名にも、別サーバーへの通行証にもならない。

CAPABILITIESは時点付きの観測だった

AUTHINFOを使うクライアントは、まず CAPABILITIES で利用可能な方式を調べる。返答はサーバー製品の恒久的な機能表ではなく、その接続の現在状態を示す。TLSの前後、認証の前後、運用モードの違いによって内容は変わり得る。

認証が成功すると、サーバーは AUTHINFO の広告をやめ、同じセッションでの再認証を 502 で拒否しなければならない。他の機能は増減してよい。認証済み利用者だけに見せる機能が現れる場合もあるため、クライアントは再送前に能力を読み直す必要がある。

ただしSASL機構の一覧は、認証後も同じ内容で提示される。これは能動的なダウングレードを検出する比較材料であり、再認証への招待ではない。AUTHINFO自体は消えている。プロトコルは、交渉の証跡を残すことと、身元を変更する権限を分けた。

古い要求をサーバーが自動再生すれば、クライアントがまだ観測していない新しい能力環境で過去の意図が動く。明示的な再送は、その不透明さを避ける。

認証交換にも終了条件があった

クライアントは 480 のあとにAUTHINFOを始めてもよく、能力が広告されていれば先回りして始めてもよい。ただし最初の段階より先へ進めるのは、サーバーが 38x の応答で継続を歓迎した場合だけである。それ以外の応答を受けて追加の秘密を送ってはならない。

サーバーはAUTHINFOそのものに 480 を返してはならない。認証要求を満たす命令が再び認証を要求すれば、抜け出せない循環になるからだ。歴史的な 381 は、同じコマンドのデータ継続ではなく、別の AUTHINFO PASS を送れという特別な意味を持つ。

一度成功したあと、同じ接続で別のAUTHINFOを行うことも禁止された。主体を変えるなら接続を作り直す。これにより、ある身元の未完了操作が別の身元へ紛れ込む余地を小さくした。

TLSは別の不足を解消した

NNTPの 483 は、適切なプライバシー保護が足りない場合を示す。RFC 4642 のSTARTTLSを通過すると、以前のアプリケーション状態を捨て、能力を再発見する必要がある。保護後に初めてUSER/PASSが現れたり、SASLの選択肢が変わったりする。

ここには四つの別々の判断がある。TLSは一つのリンクを保護する。AUTHINFOはセッションの身元を確立する。ローカル方針が資源への権利を決める。そして再送コマンドが現在の行動を示す。どの段階も次の段階を自動的には含まない。

TLSはニュース記事そのものを署名せず、後続するすべての中継を保護しない。AUTHINFOで認証されたアカウントと記事の著者も同一とは限らない。

拒否を保留命令ではなく証拠として残す

RFC 3977 は、保護されたグループを要求して 480 を受け、認証を行い、再びグループを要求する例を示す。この反復が、最初の要求は終了していたことを最も明確に表す。

運用ログでは、最初のコマンド、480、認証前の能力、TLS状態、選択した方式、認証結果、認証後の能力、明示的な再送、最終判断を別イベントとして保存すべきだ。同じ接続IDで結び付けても、「ログイン成功」一行に潰してはならない。

そうすれば、資格情報の失敗、権限不足、クライアントが再送しなかった場合、サーバーが誤って古い要求を動かした場合を区別できる。二度目は成功だけでなく、502、別の一時障害、あるいは送信中止という結末も持ち得る。

登録されたのは語彙であって権利ではない

IANAのNNTP Parameters は AUTHINFO、SASL、STARTTLS を別々の能力として登録し、それぞれのRFCを示す。共通名は相互運用を助けるが、特定サーバーの提供状況やアカウントの権限を保証しない。

現在の接続が返した能力、認証交換の結果、そして新たに送ったコマンドへの応答だけが、その場の根拠になる。

NNTPが残した設計原則は明快だ。身元不足で一度拒否した行為は、身元が強くなっても勝手に蘇らせない。システムは話者を知ることができる。それでも、今何をしたいのかはもう一度話者に尋ねる。

出典