要約

  • RFC 10020は、CoAPグループ、アプリケーショングループ、セキュリティグループを別々に定義する。相互関係は多対多、一対多、多対一、一対一のいずれでもよく、どのように対応させるかは配備側の設定で決まる。
  • Group OSCOREは、保護された要求を送った具体的なセキュリティグループメンバーを認証できる。しかし同RFCは、その所属をアプリケーション資源のアクセス制御に流用すべきではないと明記している。

退役処理を終えたはずの端末が、一斉制御の要求を受け取った。マルチキャストアドレスの購読は残っていた。対象と同じURIパスも残っていた。鍵の更新前だったため、Group OSCOREの材料もまだ有効だった。要求の署名に問題はなく、送信者も特定できた。

「安全に受信した」という判定は正しい。それでも「いま動作してよい」という判定にはならない。

この差は、2026年7月のIETF Standards Track文書であるRFC 10020の設計そのものにある。同文書はCoAPのグループ通信を定め、RFC 7390を廃止し、RFC 7252とRFC 7641を更新する。UDP/IPマルチキャストをグループ要求の既定トランスポートとしながら、「グループ」という言葉に一つの権限モデルを背負わせてはいない。

到達先、機能、暗号参加者

CoAPグループとは、特定のIPマルチキャストアドレスとUDPポート宛てのグループメッセージを受信するよう設定されたCoAP端点の集合である。これはネットワーク上の到達性を表す。グループURIにはマルチキャストアドレスまたはグループ用ホスト名を置き、必要なら既定のUDPポート5683以外も指定できる。

アプリケーショングループは、CoAP資源を通じて同じアプリケーション機能を提供するサーバー端点の集合である。こちらが表すのは、要求のメソッドとパスをどのサーバーがどの機能として処理するかだ。名前はURIパスに明示することも、要求内容や配備文脈から受信側が導くこともある。

セキュリティグループは、メッセージの保護と検証に必要なセキュリティ材料を共有する端点の集合である。これは暗号上の参加資格を表す。一台の端点が複数のセキュリティグループに所属してもよい。

三つの集合は自動的には一致しない。RFC 10020は多対多、一対多、多対一、一対一の全てを認める。保存量や更新負担を減らすため、複数のアプリケーショングループが一つのセキュリティグループを使える。クライアントの対応アルゴリズムが異なる場合、一つのアプリケーショングループが複数のセキュリティグループを使うこともできる。対応関係を作るのは配備の設定主体である。

送信者も受信者名簿からは決まらない。対象はAny-Source Multicastであり、送信元は宛先IPマルチキャストグループのメンバーでも、そうでなくてもよい。送信元の数にも、このモデルから来る制限はない。「聴いている端点」を「送ってよい主体」と読み替えることは、プロトコルが与えていない権限を足すことになる。

署名の検証結果に認可を足さない

保護された通信には、RFC 10021のGroup OSCOREを使う。Group OSCOREはRFC 8613のOSCOREを拡張し、RFC 9052などのCOSE構造を用いてCoAPメッセージをアプリケーション層で保護する。グループモードでは送信端点の秘密鍵による署名を、pairwiseモードでは一対一通信用に導出した鍵を使う。

受信側が得る保証は明確である。OSCOREグループに属する、特定可能な端点がメッセージを生成したことを検証できる。共通の対称鍵材料だけならグループ単位の認証にとどまるが、Group OSCOREは送信元認証を加える。ただし、パケットの送信元IPアドレスやUDPポートそのものを認証するものではない。

さらに、これは資源に対する包括的な利用権ではない。RFC 10020は、同じアプリケーショングループ内のアクセス方針を、異なるセキュリティグループの所属で表すことを推奨していない。セキュリティグループ所属が与えるのは、保護されたメッセージを交換し、メンバーを認証する能力である。資源を利用する認可は別のセキュリティ領域に属し、資源の属性または専用のアクセス制御資格で判断すべきだとしている。

したがって、検証成功は「この鍵epochで誰が送ったか」を答える。認可判断は「その主体が、いま、このURIパスへ、このメソッドを、この業務範囲で実行してよいか」を答える。前者を後者の代わりに使えば、鍵配布が意図せず権限管理になる。

RFC 9200のACE枠組みは、端点がGroup Managerを通じてセキュリティグループへ参加するときの認証・認可に利用できる。それでも、グループ材料を受け取る許可と、その材料で保護された全資源を使う許可は同じではない。参加、真正性、資源操作の三段階は、それぞれ記録する必要がある。

名簿は異なる時点、異なる手で作られる

RFC 10020は、グループを作る主体を広く「設定主体」と呼ぶ。アプリケーション、利用者、開発者、クラウドサービス、コミッショニングツールなどが該当し得る。設定の時点も、ソフトウェア作成時、工場、販売店、初期導入、現地での再設定と幅広い。

同文書は、それらを異なる主体がほとんど、あるいは全く調整せずに実施する可能性を指摘する。工場でセキュリティ資格を入れ、導入業者がマルチキャストを設定し、クラウド側がアプリケーション資源の対象を決め、その後の保守で一つだけ変更する。各工程が正しくても、三つの現在値は一致しないことがある。

グループ保守には、メンバー追加・削除だけでなく、セキュリティ材料の変更、IPアドレスやUDPポートの再設定、グループURIの変更、アプリケーショングループの改名、分割、統合が含まれる。「グループから削除した」という作業票では、どの集合を変更し、他の二つを誰が照合したかが分からない。

セキュリティグループには鍵の時間軸もある。OSCOREグループは、失効と更新のためにrekeyを採用しなければならない。メンバーの出入りが多く、rekeyに時間がかかる場合、複数の変更をまとめる判断はあり得る。その代わり、rekeyが済むまで、退会済み端点が既存材料で通信にアクセスできる。方針によっては、新規参加者が参加前の通信を読める期間も生じる。

従って「セキュリティグループのメンバー」という表示には、鍵epoch、退出時刻、rekeyの完了範囲が必要だ。時刻のない所属は、現在の権限ではなく、いつか成立した関係しか示さない。

応答がないことを不実行に変換しない

グループ通信では、結果の観測も一対一通信と異なる。クライアントは要求をマルチキャストし、各サーバーは通常、個別にユニキャストで応答する。応答集中を避けるため、グループ要求はNon-confirmableで送られ、サーバーはランダムなLeisure期間に応答を分散する。NSTARTやPROBING_RATEによる輻輳制御も残る。

サーバーは応答を抑制できる。RFC 10020は、エラー時または有用な応答がないとき、アプリケーション方針がその資源について応答を要求しない限り、抑制することを勧める。No-Responseオプションの影響も、あらかじめ適切と判断した資源に限るべきである。

無応答には、要求の損失、資源不一致、拒否応答の抑制、Leisure中の遅延、応答損失、応答を伴わない実行が含まれる。新しいMessage IDで再送すれば、最初の要求を処理済みのサーバーがもう一度処理する場合もある。返答件数だけでは、実行した端点数も副作用数も確定しない。

Heng Luが述べるrunning codeの優先は、この差を消すためではなく、並べて見せるために役立つ。設定は予定された到達性、機能、暗号参加者を示す。観測は実際の動作を示す。統治に必要なのは、宣言と結果を結ぶ証拠である。

三名簿認可レシート

そこで、三名簿認可レシートを作る。第一欄はCoAPグループで、マルチキャストアドレスまたはホスト名、UDPポート、スコープ、受信端点、発見元、設定epochを記録する。Any-Source Multicastでは送信者が受信グループに属する必要がないため、送信端点は別欄に置く。

第二欄はアプリケーショングループと資源認可である。URIパス、メソッド、ペイロード種別、機能を持つべきサーバー集合、方針版、評価した資格または資源属性、判断、期限を記録する。「署名検証済み」を認可結果として転記してはならない。

第三欄はセキュリティグループで、Group Manager、グループ識別子、アルゴリズム、認証した送信者、OSCORE鍵epoch、参加証拠、退出状態、直近rekeyと完了範囲を持つ。送信元認証とネットワークアドレスの検証は分離する。アドレス到達性の確認が必要なら、RFC 9175のEchoオプションを使い、認証済み要求者が申告アドレスで応答可能かを確かめられる。

結果欄には予定受信者、観測した処理、応答抑制方針、Leisure窓、受信応答、既知の損失、再送、副作用を残す。沈黙は「不明」であり、「未実行」へ自動変換しない。名簿を変更した設定主体と、他の二名簿を照合した記録も紐付ける。

これはDaniel Kadeによる編集上のガバナンス提案であり、RFC 10020の要求ではない。アドレス、資源、鍵が全て有効という三つの事実を、一つの説明不能な緑表示にまとめないための仕組みである。

NoSecでは一要求が攻撃も増幅する

RFC 10020はNoSecによるグループ通信を強く非推奨とし、セキュリティを必要としない、またはまだ得られない狭い初期発見などに例外を限る。NoSecのグループサーバーを公共インターネットから利用可能にしてはならない。一つの偽装送信元付きマルチキャスト要求が、複数サーバーから被害者への応答を発生させるためだ。

Group OSCOREは送信者を認証し、パスやクエリを保護することで危険を狭める。応答制限とEchoも緩和策になる。それでも、経路上の攻撃者、セキュリティグループ内部の攻撃者、許可された応答数とサイズは残る。安全なメッセージは、無制限に安全な効果を意味しない。

Heng Luのポリシーミラーが求めるのは、実際の統制分布を画面に映すことだ。アドレス、資源、鍵、認可、応答抑制、観測の所有者は違う。「グループ正常」という一項目では、どの責任が果たされたか分からない。

BTW Mediaが現実を製品とする理由に沿えば、結論は限定的でよい。アドレスは宛先を、Group OSCOREは安全epoch内の送信者を、認可は資源利用権を、運用証拠は結果を示す。それぞれの証明範囲を守ることが、信頼を弱めるのではなく強くする。

情報源