要約

  • Datatrackerは2026年9月8日、draft-ietf-lake-edhoc-pskを「WG Consensus: Waiting for Write-Up」へ進め、同日に第09版が提出された。現在もInternet-Draftであり、RFCでもIESG承認済み標準でもない。
  • 第09版では、1つのID_CRED_PSKから1つ以上の候補PSKと関連資格情報を取得し、認証復号が成功するまで応答側が候補を替えて試せる。
  • 受信した識別子だけをログに残しても、実際に相手を認証した資格情報コンテキストを特定できなくなった。
  • 候補集合の版、選択された非秘密の資格情報版、試行結果を残すことをDaniel Kadeは提案する。これはドラフトの要件ではなく編集上の分析である。

候補が複数になっても、ネットワーク上を候補一覧が流れるわけではない。開始側が保護されたEDHOCメッセージ3にID_CRED_PSKを入れ、応答側がその値をローカル検索キーとして使う。COSEのkidほど短い参照の背後で、初めて候補集合が現れる。

第09版は処理順を具体化した。検索はPSKだけでなく、EDHOC処理に必要な関連情報も返す。応答側は最初の候補を選び、K_3とIV_3を導出してCIPHERTEXT_3BのAEAD検証を行う。失敗すれば次の候補へ移り、すべてを使い切って初めて処理上の問題または改ざんとして扱う。成功は、その候補のPSKを相手が保持し、交換に能動的に参加したことを示す。

第08版との違いは実装判断に直結する。旧版は「正しいPSK」を取り出す識別子として説明し、曖昧さや複数鍵の試行を避けるため、一意または確率的に一意な指定を推奨していた。公式差分では、その推奨自体は残る一方、複数候補が明示的な処理経路になったことが分かる。一対一は望ましい高速経路だが、唯一の許容形ではない。

候補は単なる鍵ではない

運用画面で「鍵候補」とだけ表示すると、選択の実体を小さく見せすぎる。ドラフトが検索結果に結び付けるのはPSK、CRED_I、CRED_R、および選択した暗号スイートでEDHOCを処理するための情報である。反射や誤結合を抑えるため開始側と応答側の資格情報は異ならなければならず、ハッシュの文脈も候補と整合する必要がある。検証しているのは秘密のバイト列だけでなく、一式の認証コンテキストだ。

基礎仕様のEDHOC、RFC 9528は、短い資格情報参照と実際の資格情報をすでに区別している。COSE、RFC 9052でもkidはグローバルに一意な名前ではなく、受信者が使う識別の手掛かりである。CWT、RFC 8392は関連する主張を表現する一方式を与える。PSK拡張では同じ参照の後ろに複数のローカル文脈を置けるため、この区別が監査上の中心になる。

複数候補を「パスワード総当たり」と呼ぶのも不正確だ。第09版は外部PSKについて少なくとも128ビットのエントロピーと128ビット以上の長さを求め、パスワードなど低エントロピーの入力から共有秘密を作ることを安全ではないと明記する。ここで試されるのは弱い入力空間ではなく、あらかじめ配備された複数の資格情報コンテキストである。

鍵更新を止めない代わりに、表が方針を持つ

複数候補を何に使うかは規定されていない。新旧鍵が重なる更新期間、配備データベース間の一時的なずれ、区画ごとに再利用される短い識別空間、交換を確認する間だけ旧資格情報を残す復旧策などは、いずれも本文から導ける運用例にすぎない。凍結した証拠には、この機能を本番利用している導入事例はない。

それでも利点は明白だ。制約の強いリンクに大きなIDを載せず、全端末を同時に切り替えなくても可用性を保てる。一方で、候補の所属、並び、廃止時刻、試行上限という方針は応答側の表に移る。開始側はその状態を観測できない。

同じ方針で動くはずの2台の応答装置が、同じIDを受けながら異なる候補順で成功することもあり得る。双方がID_CRED_PSKだけを記録すれば、後日の記録は同一だ。先に期限切れ候補を試したのか、更新版が使われたのか、フォールバックが残っていたのかを区別できない。短い参照を唯一の資格情報名として扱うことが、ドラフト以上の意味をログに持ち込んでしまう。

「書き上げ待ち」はRFC化ではない

作業部会最終呼びかけの記録では、第08版のレビュー期間は7月1日から15日だった。保存された候補選択の議論には、AEAD検証に失敗したら別候補を試す提案があり、第09版の処理へ反映された。

9月8日のDatatracker履歴は、状態がWG Last Callから「WG Consensus: Waiting for Write-Up」へ変わり、Marco Tilocaが文書シェパードに指定され、第09版が投稿されたことを示す。現在の文書ページが示すのは、標準化トラックを意図したLAKE作業部会の活動中ドラフトまでだ。シェパード文書、IESG審査、追加改訂、承認、RFC発行はそれぞれ別の段階である。

秘密を残さず、選択を残す

後から必要になるのはPSKそのものではない。「この検索に対して、この応答側はどの非秘密資格情報コンテキストを受け入れたか」という限定された説明である。

受信したID_CRED_PSKの指紋、候補集合の版またはダイジェスト、候補数、選ばれた非秘密資格情報の版、EDHOCスイートとハッシュ文脈、試行回数、結果、方針版、時刻を組にしておけばよい。全候補失敗時にも同じ形を使い、候補内容は露出させない。遅延や全候補失敗率は候補数の帯域ごとに集計でき、端末別の公開識別記録を作る必要もない。

第2候補での成功が一時的に増えるなら更新の進行を示すかもしれない。しかし廃止期限後も続けば、古い状態が固定化している。揃うべき応答側で集合版が違えば、曖昧な「PSK検証失敗」だけが残る前に配備の分岐を発見できる。

この記録形式はDaniel Kadeによる編集提案であって、ドラフトの合意事項ではない。暗号処理を定める標準と、プライバシーを踏まえた運用記録の設計は別の仕事でよい。ただし、検索が複数形になった後も記録を単数形のままにしてよい理由にはならない。

出典