要約

  • RFC 9820 では、EAP メソッドの成功と MSK の出力だけで保護セッションは完成しない。認証器からの OSCORE 保護 Step 7 と、peer から戻る OSCORE 保護 Step 8 2.04 Changed の両方を検証して初めて、同じ派生コンテキストを保持したという相互証拠になる。
  • 共有コンテキストは、すべてのアプリケーション資源への許可ではない。ブートストラップ認可、資源別ポリシー、寿命、再認証、世代切替、強制削除には、それぞれ別の決定主体と完了条件がある。
  • 監査可能な最小単位は、CoAP リソース世代、EAP 結果、秘密を含まない鍵系譜、暗号交渉、Recipient ID、Step 7/8 の検証、実効ポリシー、削除応答、観測トラフィックを結ぶ。MSK 自体をログに残してはならない。

古い宛先は、古い判断を運んでくる

仮想的な事故では、パケットそのものは改ざんされていない。古い Step の要求がネットワーク遅延後に再到着し、セッション表の粗い照合がそれを現行交換へ結びつけた。運用側は EAP が一度成功していたため、順序の違いを単なる輸送上の再送とみなした。

RFC 9820 は、制約のある IoT 機器で EAP を CoAP 上に運ぶ認証サービスを定義する。機器は EAP peer である一方、CoAP server としてリソースを提供する。Controller は EAP authenticator でありながら、CoAP client として要求を送る。pass-through 構成では backend AAA server が方法や認可属性に関与する。

この役割配置では「クライアントが認証された」という一文さえ曖昧になる。クライアントとは CoAP の送信者か、EAP の peer か、製品所有者か。証拠はプロトコル役割、実体、政策を持つ組織、最終動作を決めるアプリケーションを区別しなければならない。

RFC Editor の情報ページと IETF Datatracker は、RFC 9820 を ACE Working Group で策定され、2025 年 9 月に公開された IETF Standards Track 文書として記録する。これは仕様の地位を示す。特定製品の実装、相互接続、認証、入域、アクセス結果を証明するものではない。

リソースの生成と破棄が会話の順序になる

CoAP-EAP は、永続 URL の裏で見えないカウンターだけを進める方式ではない。peer は各要求を処理すると次の Step 用リソースを生成し、前のリソースを削除する。応答の Location-Path または Location-Query が、次に受け付ける場所を指す。

したがって宛先の世代は transcript の一部である。削除された場所への要求は、内容が以前に正しかったという理由だけで現行にならない。認証中の重複 Step 0 は黙って破棄されるべきであり、セッション終了後の古い trigger は、authenticator 側では新しい開始に見えても peer 側の期待資源と一致しない場合がある。

RFC 7252 は CoAP の要求、応答、信頼性を定義する。RFC 4137 は EAP peer と authenticator の状態機械を示す。RFC 9820 は二つを組み合わせるが、どちらかを単一のセッション行へ消去しない。

必要な記録は、現在資源と削除資源、要求・応答 ID、EAP 状態遷移、CoAP 結果、到着時刻、peer/authenticator の役割である。再試行が別世代へ到達したなら、拒否、破棄、新規認証のどれとして扱われたかも残す。

Step 7 は成功通知ではなく、片側の主張に対する試験である

EAP メソッドが成功すると、authenticator は出力された MSK、EAP Success、Session-Lifetime などの認可情報を得る。RFC 5247 は EAP Key Management Framework を定義する。RFC 9820 は少なくとも 64 octets の MSK と EMSK を出力する方法を要求する。

しかし authenticator に MSK があることは、peer と同じアプリケーション保護状態を導出した証明ではない。RFC 9820 は MSK、暗号 suite 交渉 transcript、定義済み context string から OSCORE Master Secret と Master Salt を導出する。先に交換した Recipient ID が送受信方向を定める。RFC 5869 は HKDF を、RFC 8613 は OSCORE を定義する。

authenticator は EAP Success を OSCORE 保護 POST で送る。peer は自分の EAP 状態機械から MSK を得て、同じ入力でコンテキストを導出し、その POST を検証する。Step 7 は、既に決着した成功を暗号化して飾るものではない。片側の結論を、もう片側が互換状態によって受理できるか試す境界である。

監査のために MSK を保存する必要はない。保存すべきは、交渉 transcript の fingerprint、方法と suite の識別子、Recipient ID、導出世代、実行 version、検証結果である。秘密を証拠庫へ複製すれば、証拠機構そのものが新しい侵害面になる。

Step 8 は、開始者へ戻る独立した証言である

peer は EAP 成功と Step 7 検証の後、OSCORE で保護した 2.04 Changed を返す。authenticator がこれを検証すると、peer も同じ Master Secret に基づくコンテキストを使えたという戻りの証拠を得る。

少なくとも五つの事実がある。メソッドが成功した。MSK が出力された。各側で候補コンテキストを導出した。peer が Step 7 を検証した。authenticator が Step 8 を検証した。最後の応答が失われても最初の四つは消えないが、「相互確認済み」とは言えない。

暗号 suite の交渉内容は導出に入るため、transcript が異なればコンテキストも異なり、保護 Step の検証に失敗する。IANA CoRE Parameters と IANA EAP Parameters は codepoint を登録するが、稼働 endpoint が何を提示し、選び、実行したかは証明しない。

この二つの証人を個別に残せば、輸送損失、導出不一致、片側だけの進行を区別できる。一つの緑色表示では、調査時にその違いを復元できない。

OSCORE を共有しても、資源所有者にはならない

Step 8 の後、最後の CoAP-EAP リソースとの通信は OSCORE で保護される。同じコンテキストを他の資源に使えるのは、アプリケーションポリシーが認めた場合だけである。

認証は方法が peer について何を結論したかを扱う。鍵確認は二つの endpoint が互換保護を持つかを扱う。認可は、この peer が今、この資源にこの操作を行えるかを決める。結果は、アプリケーションが実際に何を行ったかである。同じセッション ID は、これらの管轄を統合しない。

AAA を用いる場合、peer に責任を持つ組織から RADIUS や Diameter 経由でブートストラップ認可情報が届くことがある。standalone では authenticator に置かれる。ブートストラップ後に追加認可を要求でき、RFC 9200 は ACE 向け OAuth 利用を定義する。それでも、規格への適合表明だけでは個々の資源判断を証明できない。

MSK を持つ Controller が組織の政策を所有するわけではない。属性を返した AAA は、その属性が実施された証拠ではない。正しい OSCORE message も、対象資源が許可集合に入っていたことを保証しない。

認証中に必要な IP 接続は許容されるが、保護されない通信は CoAP-EAP 交換に限定される。EAP Success を見て subnet 全体を開放すれば、方法結果をネットワーク権限へ膨張させることになる。

再認証の開始時点には、二つの現在がある

Session-Lifetime が届かない場合、RFC 9820 は RFC 5247 の推奨に従い八時間を default とする。これは protocol default であり、全環境に妥当な security objective ではない。

再認証中は、現在の CoAP-EAP 状態と新候補が同時に存在する。新しい認証が完全に成功した時点で古い状態が置換される。新しい試行が失敗すれば、古い状態は expiry または後の更新まで利用できる。

したがって管理面は、更新開始時に世代を上書きしてはならない。旧世代、新候補、メソッド結果、Step 7/8、activation、旧 context の最終利用、retirement、expiry を別イベントとして保持する。

二世代を同時に受け付けるなら、意図した overlap か、どの irreversible operation を許したかを記録する。設定が「置換済み」と言っても、実行中 resource server が旧 context を検証していれば、その code path がその場の現実である。

DELETE の timeout は遠隔削除の証明ではない

強制削除では、authenticator が最後の状態資源へ OSCORE 保護 DELETE を送り、peer が保護 2.02 Deleted を返す。応答が EXCHANGE_LIFETIME 内に届かなければ、authenticator はローカル状態を削除する。

ローカル cleanup は必要だが、peer が DELETE を受信し、context を消去し、通信を停止したことまでは示さない。partition 中には、authenticator が「退出」と表示し、peer が状態を保持し、resource cache が権限を残すことができる。

証拠列は、削除決定者、理由、対象世代、送信、peer 受信、peer 側削除、保護応答、authenticator 検証、timeout、ローカル cleanup、downstream invalidation、後続拒否、独立観測による traffic cessation である。途中が不明なら、「削除済み」という語を actor と layer で限定する。

発見された endpoint は、指定された権威とは限らない

authenticator や intermediary の discovery は RFC 9820 の範囲外である。サービスを見つけた事実だけでは、意図した組織の endpoint と証明できない。RFC 6677 の EAP channel binding は lower-layer identifier の不一致を方法と AAA 経路内で示す助けになるが、実セッションでの設定と結果を保存する必要がある。

peer が MSK を持つ authenticator を信頼できるのは、自分の AAA server がその authenticator を信頼したという鍵管理上の限定的委任による。「trusted controller」という固定ラベルでは、誰が誰へ何を委任したか消える。

偽造 Step 0 は、異なる peer を装って authenticator の state を消費できる。RFC は rate limit と EAP-Response/Identity 前の state 最小化を勧告する。rate-limit counter は負荷制御を示すが、送信元の正当性を示さない。

試験では、あえて状態機械を食い違わせる

最低構成は peer、authenticator、pass-through AAA、異なる policy を持つ二つの application resource、独立 packet observer である。正常系に加え、suite transcript 改変、Step 7 loss、Step 8 loss、旧 resource generation replay、Step 0 duplication、新規再認証 failure、old/new overlap、第二資源 denial、応答あり・なしの forced deletion を行う。

各ケースで EAP state、CoAP generation、OSCORE verification、application decision、observed effect を比較する。最終 success 一語だけを返す試験は、層間差異を捨てている。

特に、古い宛先を replay しながら新候補の Step 8 を失わせる。どの層がその要求を拒否し、どの層がまだ許可と考えるかを確認すれば、セッション名では見えない権限境界が現れる。

これらの資料が証明しないもの

RFC 9820 は、製品、operator、実導入を特定しない。電池寿命、latency、loss rate、admission 数、攻撃、相互運用試験の実測値も報告しない。例は protocol 説明であって deployment telemetry ではない。

Datatracker history、RFC 9820 を参照する文書、RFC 9820 の参照文書 は文書関係を示す。RFC Editor errata search は編集状態であり security score ではない。

RFC 3748 は広い EAP framework を定義する。標準の存在から個別機器の identity、authority、state、outcome を推論してはならない。

参考資料

  1. IETF Datatracker：RFC 9820
  2. RFC 9820 の履歴
  3. RFC 9820 を参照する文書
  4. RFC 9820 の参照文書
  5. Heng Lu：最小初期仕様
  6. Heng Lu：現実の層
  7. Heng Lu：実行コード優先
  8. IANA CoRE Parameters
  9. IANA EAP Parameters
  10. RFC 9820 errata
  11. RFC Editor 情報ページ
  12. RFC 3748
  13. RFC 4137
  14. RFC 5247
  15. RFC 5869
  16. RFC 6677
  17. RFC 7252
  18. RFC 8613
  19. RFC 9200
  20. RFC 9820