要約

  • RFC 9668 は forward flow に限り、EDHOC message_3 と最初の OSCORE request を同じ CoAP message で送り、鍵確立と一取引を最小二往復にできる。
  • message が一つでも、session lookup、message_3 検証、context 確立、replay 判定、application delivery、実行、protected response は別々の receipt である。

無線区間を通った datagram は一つだった。しかし gateway 内では、その datagram が二本の処理経路に分かれた。上側では EDHOC message_3 が session に結び付けられ、認証交換の最後の検証を受ける。下側では新しい OSCORE context を使う application request が replay と integrity の検査を待つ。その先に初めて制御対象がある。

運用画面が packet count だけを見れば、全体は一イベントに見える。RFC 9668 の処理順序を見れば、複数の成否が同居していることが分かる。

従来の順番では、EDHOC を完了してから OSCORE transaction を始める。だが Initiator は message_2 を正しく処理した時点で Security Context を導出できる。そこで message_3 を作るのと並行して最初の CoAP request を OSCORE で保護し、両方をまとめて送る。無線時間と待ち時間を減らす、実用的で狭い最適化である。

結合されるのは transport であって意味ではない

payload は EDHOC_MSG_3 と OSCORE_PAYLOAD の連結である。C_R は payload に置かず、client の OSCORE Sender ID として kid に入る。番号 21 の空の EDHOC option が、server に combined format を知らせる。

この option は Critical、Safe-to-Forward、Cache-Key の一部であり、一回だけ現れ、値を持たない。値が送られても無視される。つまり option 自体に承認情報はない。その役割は「先頭を EDHOC として処理してから残りを OSCORE として扱え」と parser に指示することだ。

OSCORE ciphertext は message_3 を対象に計算されない。message_3 は EDHOC の保護を持ち、request は OSCORE の保護を持つ。datagram が共通でも、証明する対象は別である。

packet が少ないほど内部の順序を見えるようにする

server はまず OSCORE option と combined payload の形式を確認する。次に message_3 を取り出し、kid を C_R として正しい EDHOC session を検索する。その session の application profile が message_4 を必須にしていれば、最適化された path は失敗である。

その後に message_3 を検証し、成功した場合だけ OSCORE context を確立する。続いて ciphertext を抽出し、EDHOC option を除いた protected request を再構成し、decrypt、integrity、replay の検査を行う。application へ渡すのは最後である。

message_3 が失敗すれば session は abort され、新しい context を作ってはならない。message_3 成功後に OSCORE が失敗する場合は、別の error handling になる。この違いは復旧判断に直結する。再認証すべきなのか、replay state を調べるべきなのか、application policy を見るべきなのかが変わるからだ。

観測記録には秘密を入れず、session generation、transcript hash、profile version、kid、Partial IV、replay verdict、OSCORE verdict、application transaction ID をつなぐ。単一の「secure」boolean は、障害解析に必要な分岐を消してしまう。

response は cryptographic loop を閉じる

EDHOC と OSCORE の両方に成功すると、server は OSCORE-protected response を返す。client が新しい鍵でその response を検証できれば、Responder が期待した key material を計算したという key confirmation を得られる。response は request にも結び付けられる。

それでも physical loop が閉じたとは限らない。application は job を queue に入れただけかもしれない。制御器は actuator に指令を送ったが、位置 sensor の確認を待っているかもしれない。protected response は内容の真正性を守るが、内容以上の事実を作らない。

application receipt は、delivered、authorized、accepted、durably committed、physically observed、compensated を区別すべきである。仕様上の応答 code を、業務や機械の完了へ無断で拡張してはならない。

retry は session と業務の二つの時間軸を横切る

不安定な link では response loss が起きる。client が同じ session と C_R に対する combined request を複数同時に持つことは原則避ける。EDHOC は同じ message_3 の多重処理を防ぎ、OSCORE は request replay を検査する。

しかし、業務 action の duplicate は別問題である。最初の request が application に届き、response だけが失われた場合、新しい transaction ID で再送すると二回目の action が成立し得る。first request こそ stable idempotency key と照会可能な outcome を持たせる必要がある。

timeout は failure category ではない。最後に確認できた gate と、まだ不明な範囲を示すべきだ。これにより operator は、鍵交換をやり直すか、同じ operation を照会するか、安全な補償を行うかを選べる。

MTU は最適化の権限を制限する

message_3 に certificate chain や External Authorization Data が含まれると大きくなる。最初の application request が Block-wise を必要とし、COMB_PAYLOAD が MAX_UNFRAGMENTED_SIZE を超える場合、client はその block transfer を中止し、sequential flow に戻れる。message_3 を先に送り、EDHOC 完了後に OSCORE request を送る。

したがって「二往復」は固定の製品特性ではない。credential、MTU、block size、application payload に左右される policy result である。component size、想定 MTU、block number、threshold、fallback reason を残せば、どの population が何を選ばれたか説明できる。

共通仕様が定めるべきなのは interoperable な最小境界である。最適化を使うかどうか、どの command まで許すかは local operator の将来判断として残る。

情報源