要点

  • IETFのLAKEワーキンググループは2026年9月8日、draft-ietf-lake-authz-08のWorking Group Last Callを開始した。締め切りは9月22日で、文書はまだRFCでもIESG承認済み標準でもない。
  • ELAの通常フローでは、端末UがEDHOC message 3でID_CRED_IをVへ渡し、Vが登録サーバーWへ転送する。WがVを認めたバウチャーはmessage 4でUへ戻る。
  • 草案自身が、Uは認証済みのVに自らのIDを明かした時点では、ELAの認可が成功するかをまだ知らないと述べている。加入専用IDの利用は一つの緩和策である。
  • Daniel Kadeは、認証、第三者認可、拒否、ID切り替えを別々に残す限定的な加入レシートを提案する。これはIETF案の規定ではない。

Last Callの告知は、賛成だけでなく、反対理由と解決案も9月22日までに示すよう求めた。Datatrackerの履歴は9月8日、状態がWG DocumentからIn WG Last Callへ変わったことを記録する。これは審査の開始であって結論ではない。現行文書ページも、rev 08をProposed Standardを目指すInternet-Draftとして表示している。

ELAはLightweight Authorization using EDHOCの略称だ。端末U、ドメイン認証装置V、登録サーバーWという三者を置き、制約の厳しいU–V間ではEDHOCの短い交換を使う。V–W間の処理を制約の少ないネットワーク側へ寄せ、認証と加入認可を並行させることで通信量を抑える。

rev 08が前提にする信頼関係は非対称だ。UにはWの公開鍵と場所があらかじめ入っている。VとWはWeb PKIなどを通じて関係を持つ。一方、UとVに事前関係は不要である。ELAは、既存の二本の関係を使って最後の一本を成立させる仕組みだ。

message 3で何が先に渡るのか

Uはmessage 2でVの認証資格情報を検証する。続くmessage 3で、Uは自らの資格情報を指すID_CRED_Iを送る。同じメッセージのExternal Authorization DataにはWの場所と、将来のバウチャーを独立に保護するための新しいDH公開鍵またはKEM暗号文も入る。

Vはこれらを材料にWへVoucher Requestを出す。要求には選択済み暗号スイート、最初の二メッセージを結ぶH_12、一時鍵材料、ID_CRED_I、Uの資格情報を取得するかどうかのフラグが含まれる。WはH_12と端末IDを関連付け、Uに適用する加入ポリシーを探して実行する。ポリシーの中身は仕様の範囲外であり、許可する端末、時間帯、Vを限定し得る。

Wが生成するバウチャーは、WからUへ「このVを認可した」と伝える表明である。現在のハンドシェイク、Uの識別子、Vの資格情報に暗号学的に結び付く。任意のスコープ情報はUとWには読めるが、運搬役のVには不透明だ。Vはmessage 4でそれをUへ返す。

RFC 9528の通常のEDHOCではmessage 4は任意だが、ELAの通常フローでは必須になる。Uが待っている第三者認可の証拠がそこにあるからだ。草案がUとVの双方を相互作用可能な認可済み状態とするのも、message 4の処理後である。

したがって途中状態は無視できない。VはUに対して鍵の保持を証明済みだが、WがそのVを認めた証拠はまだUに届いていない。それでもUの識別子はVへ届き、Wへの要求にも入っている。Vを認証したという事実は、WがVを加入先として認可したという事実を先取りしない。

ID保護には相手がいる

これはEDHOCのID保護が破れたという話ではない。外部の盗聴者や未認証の相手にIDを公開する設計ではなく、通信は機密性と完全性で保護される。ELAのSecurity Considerationsは、より限定した事実を明記する。Uは認証済みVへIDを明かすが、その時点ではELA認可フローが成功するかを知らない。

同じ節は、Uが加入専用IDを使い、安全なチャネル成立後の運用通信では別IDに替えてよいとする。拒否された試行や誤ったVへの接続が、日常利用の恒久IDと直結しないための現実的な選択肢だ。ただし、VとWの保存期間、二つのIDの対応、切り替え完了をどう証明するかまでは決めない。

バウチャーという語にも境界がある。RFC 8366は、製造者が署名し、pledgeを所有者へ割り当ててドメイン証明書を固定するVoucher Artifactを定義する。ELAは役割が似ていてより小さいバウチャーを用いるが、同じ形式ではない。RFC 8995はBRSKIのpledge、registrar、MASAを分け、監査ログとプライバシーを明示的に扱う。RFC 9031は制約ネットワークへの別の参加手順を示す。いずれも背景であり、ELAの順序そのものではない。

403は単なる通信失敗ではない

WはID_CRED_Iを知っていても、ポリシーによって加入を拒める。その場合、HTTP 403またはCoAP 4.03を返す。Wは別のVを試すよう促す情報などをU向けに暗号化し、VがEDHOCのAccess deniedとして中継することもできる。

この結果を「接続失敗」の一語にまとめると、重要な区別が消える。ポリシー拒否、Uの資格情報取得失敗、バウチャー検証失敗、Wのタイムアウト、誤ったVへの接続は、対処も情報流通の段階も違う。とりわけポリシー拒否では、WがIDを認識して判断した後に加入が止まっている。

IETF 126のLAKE議事録には、EDHOC用とELA用の一時鍵を分ける方針を維持したこと、Last Callへの賛意が少数示されたこと、議長が開始を表明したことが残る。LAKEワーキンググループは共通仕様を審査する。しかし、失敗後に何を忘れるかは導入組織の責任である。

追跡表にしない加入レシート

有用なレシートに生のID_CRED_Iは要らない。試行ごとの一方向ハンドル、V資格情報のフィンガープリント、Wの信頼アンカーとエンドポイント版、H_12、ポリシー版、Uが加入用か運用用のどちらのID種別を使ったか、そしてバウチャー受理、ポリシー拒否、転送、資格情報失敗、期限切れという限定的結果で足りる。

加入IDから運用IDへ替えたときは、切り替え済みであることだけを残し、持ち運べる対応表を作らない。保存期限と削除結果もレシートに含める。完全な証明書、バウチャー平文、ドメインを越えて照合できる端末IDは通常ログから外すべきだ。

このレシート案はDaniel Kadeの分析で、rev 08の要求ではない。ELAは認可ポリシーを仕様外に置く。だからこそ実装側は、認証、WによるVの認可、Uへのポリシー判断、IDの廃棄を一つの「成功」に畳み込んではならない。

出典