要約

  • 相互モードでは、クライアントはサーバーのチャレンジと、自ら生成した乱数をまとめて署名する。サーバーの最後の署名は両方を含むが、クライアントが自分の値を選ぶ前にサーバーの最初の値を知っていたため、第三の値も加える。
  • 第三の値はサーバーの応答を新たな乱数入力に結び付ける。しかし機構を安全な通信路に変えるものではない。RFC 3163は完全性も機密性も提供せず、能動攻撃が可能だと明記している。

余分に見える値

RFC 3163の手順は同じ確認を繰り返しているように見える。サーバーが乱数チャレンジを送り、クライアントはそれを含む記録に署名し、今度はサーバーも同じ値を含む記録に署名する。最終応答に第三の値が必要なのはなぜか。

2001年8月のExperimental RFC「ISO/IEC 9798-3 Authentication SASL Mechanism」は、メッセージ数ではなく選択の順序から説明する。重要なのは、各参加者が自分の乱数を選ぶ時点で、相手のチャレンジを知っていたかどうかだ。その順序によって、署名から読み取れる交換上の事実が変わる。

仕様は二つのSASL機構名を定める。9798-U-<algorithm>はクライアントをサーバーに対して認証する。9798-M-<algorithm>では相互認証となり、クライアントがサーバーのチャレンジに署名し、サーバーもクライアントのチャレンジに署名する。いずれも公開鍵署名とX.509証明書を使い、記載された検証手順には証明書パスの処理が含まれる。

署名に入る値とその順序

どちらのモードでも、まずサーバーが乱数 R_B を作る。続いてクライアントが R_A を選び、TokenABを送る。ここにはクライアント証明書の情報とR_A、R_Bへの署名が含まれ、任意でサーバー識別子も入る。サーバーは署名を検証し、受け取ったR_Bが最初のチャレンジと一致すること、識別子があればそれも確認する。

一方向認証では、ここまでが中心的な交換になる。相互モードではサーバーの応答を追加する。TokenBA2にはサーバー証明書と、R_A、R_B、新たな値R_Cへの署名が入る。クライアントは証明書と署名を検証し、先の二つの乱数が前段と一致すること、任意のクライアント識別子が妥当であることを確かめる。

第7節はR_Cの理由を述べる。クライアントの署名データにR_Aを含めれば、機構開始前にサーバーが選んだデータへの署名をクライアントから取得することを防げる。しかし逆向きは対称ではない。クライアントはR_Aを選ぶ前からR_Bを知っている。サーバーの署名にR_Bを含める必要はあるが、その値だけではサーバーに同じ保護を与えない。そこでRFC 3163は、サーバーが署名するTokenBA2にR_Cを追加する。

これはRFCが説明するトランスクリプト設計上の理由であり、あらゆる中継、再送、能動攻撃への一般的な証明ではない。乱数には暗号学的に強い生成器が必要で、予測可能な値は攻撃につながる。第三の値が対処するのは記載された時間的なずれであり、記録の外にある安全性までは補わない。

署名だけではセッションを守れない

境界は明白だ。RFC 3163によれば、この機構が提供するのは認証だけである。後続メッセージの完全性も内容の機密性も提供しない。セキュリティ節は受動的な盗聴に対する保護に限られるとし、セッション乗っ取りを含む能動攻撃が可能だと述べる。IESG注記はさらに、PKIの実装負担を引き受けながら各転送の完全性を捨てていると批判し、TLSなら完全性を備えた同等機能を提供できるとしている。

証明書の情報がこうした層を一つにするわけではない。TokenABのauthIDは、証明書の署名者とは異なるアクセス制御用の識別子を表しうる。証明書パスの受け入れ、機構による認証、識別子の対応付け、アプリケーションの認可は別の判断だ。有効な署名が示すのは、ある鍵が対象データに署名したことまでであり、アプリケーションが何を許可すべきかではない。

RFCにあるIMAPの例も、相互モードを示すものではない。例は一方向の9798-U認証であり、Base64の符号化と応答前の+記号はSASL機構ではなくIMAPプロファイルに由来すると明記されている。これは説明用の記録であって、普及や相互運用性の証拠ではない。

Lu HengのNote 20は、ここでは解釈の補助線としてのみ使う。プロトコルが実際に検証する証拠と、身元や権限に関するより大きな主張を分ける見方である。乱数の一致や検証済み署名は交換記録の証拠であり、通信路保護やアプリケーション権限は別の制御に委ねられる。この視点をRFC 3163の著者に帰属させてはいない。

出典

  1. RFC 3163 — ISO/IEC 9798-3 Authentication SASL Mechanism
  2. RFC 3163のRFC Editor記録
  3. RFC 2222 — Simple Authentication and Security Layer
  4. RFC 4422 — Simple Authentication and Security Layer (SASL)
  5. RFC 2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  6. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  7. RFC 2630 — Cryptographic Message Syntax
  8. RFC 8017 — PKCS #1: RSA Cryptography Specifications
  9. RFC 2060 — Internet Message Access Protocol, Version 4rev1
  10. RFC 2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
  11. IANA SASLメカニズム登録簿
  12. NIST FIPS PUB 196 — Entity Authentication Using Public Key Cryptography
  13. Lu Heng、Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile