要約

  • RFC 3652は配達・再構成用の固定20オクテットのMessage Envelopeを、固定24オクテットのHeaderと操作固有のBodyから分離した。Message Credential内のデジタル署名はEnvelopeを対象にせず、HeaderとBodyを保護する。
  • Credentialには発信者のデジタル署名、または事前確立したセッション鍵に基づくメッセージ認証コード（MAC）が含まれ得る。この境界が示すのはプロトコル上の完全性保護範囲であり、記録された攻撃、実装不具合、あるいは下位層での保護不能を意味しない。

一つのメッセージに異なる信頼領域

2003年、Handle Systemのプロトコル仕様が定める対象は単なる検索ではなかった。クライアントは担当Handleサーバーを見つけ、解決や管理を依頼し、応答を解釈する必要があった。また、異なるトランスポートでもメッセージを運べる必要がある。RFC 3652 v2.1はそれらを隣接する四つの部分、Envelope、Header、Body、Credentialに分けた。RFC 3652

Envelopeは必ず存在し、ちょうど20オクテットだった。RFCはこれをアプリケーション情報ではなく、メッセージを届けるための包みと説明する。フィールドにはプロトコル版、メッセージフラグ、セッションID、リクエストID、シーケンス番号、メッセージ長が含まれる。必須のHeaderは24オクテットで、操作コードや応答コードなど共通フィールドを持つ。Bodyには操作固有のデータが入り、空の場合もある。RFC 3652

信頼境界はパケット境界とは一致しなかった。RFC 3652は、Message Credentialのデジタル署名がEnvelopeの内容を保護しない一方、HeaderとBodyは保護すると明記する。空でないCredentialは発信者のデジタル署名、または確立済みのセッション鍵に基づく一方向MACを含み得る。RFCはこれをメッセージの認証と転送後のデータ完全性確認に使える仕組みとしている。MACは共有秘密を前提とし、デジタル署名とは鍵のモデルが異なる。RFC 3652 RFC 2104

この分離はEnvelopeの役割に沿っていた。HandleクライアントはUDPデータグラムでもTCPバイトストリームでもメッセージを送れた。RFC 3652はUDPで運ぶメッセージを、IPとUDPのヘッダーを除いて512オクテットまでに制限する。より長いメッセージは断片化され、各断片が再構成用のシーケンス番号をEnvelopeに載せた。TCPはバイトストリームを提供するが、Handleメッセージの境界までは定めない。大きなメッセージはHandle層でも分割・再構成され得る。RFC 3652 RFC 768 RFC 793

それに対しHeaderとBodyは、クライアントとサーバーが何をしているかを記述した。操作コードがHandle操作の種類を指定し、応答コードは成功、値なし、サービス紹介、認可拒否、認証要求などの結果を示した。プロトコルは別途定義された名前空間とデータモデルに従い、RFC 3650はサービス全体の構成を説明する。つまり、保護対象となる意味内容は配達用の包みの後から始まる。断片を組み立てることと、その中の操作を許可することは別である。RFC 3652 RFC 3650 RFC 3651

認証と認可は別の判定

RFC 3652はクライアントの証明とサーバーの許可判断も分けた。管理操作ではサーバーがチャレンジを送り、クライアントは対応する秘密鍵または共有秘密を持つことを応答で証明できる。しかし証明が検証された後も、サーバーは要求された操作に十分な権限があるかを確認しなければならない。チャレンジ応答に成功してもHandle変更が承認されたわけではない。セッションでは複数操作が状態や鍵を共有することもある。RFC 3652

RFC 3552ではデータ完全性、相手の認証、機密性、システム安全性は異なる目標であり、署名やMACだけで全部が自動的に得られるわけではない。RFC 3652のセキュリティ節はサーバー署名やクライアント認証を扱うが、形式定義はより限定的だ。Credentialが保護するのはHeaderとBodyであり、配達用Envelopeではない。この記述だけから、実運用システムでメッセージ改ざんがあったとは言えない。下位層の通信路が別の保護を与える可能性もある。RFCは仕様であって事故報告ではない。RFC 3552 RFC 3652

Handle CredentialをX.509署名プロファイルと混同してもいけない。RFC 3279はそのPKIにおける証明書と失効リストのアルゴリズム識別子や符号化を定めるもので、RFC 3652が署名する範囲を拡張せず、Envelopeを認証済みの内容にもしない。暗号用語を並べるだけでは不十分で、何というオブジェクトを認証するのかを特定する必要がある。RFC 3279 RFC 3652

RFC 3652はInformationalで、IESG注記はHandle SystemやIETF識別子アーキテクチャとの関係についてIETFの合意に至っていないとする。これは提案されたプロトコルの記述で、普遍的な採用の証明ではない。教訓はもっと限定的だ。メッセージの枠付け、再構成、認証は別々の規則で動き得るため、完全性を主張するときはCredentialが実際にどのバイトを対象にするか示さなければならない。RFC 3652

出典