要約

  • RFC 9647のtestアクションは、呼出者が渡した試験文字列について、設定済みの鍵とアルゴリズムでMACを計算し、候補MACとの一致を真偽値で返す。鍵値も、内部で計算したMACも返さない。
  • 鍵値のvalueリーフにあるnacm:default-deny-allだけでは、別のtestアクションの実行可否は決まらない。呼出先を特定するすべての祖先データノードの読取権限と、アクションの実行権限が必要になる。
  • 実行判定には、セッション、グループ、規則の適用範囲と順序が関わる。一致する実行規則で決まらない場合に適用されるexec-defaultの標準値はpermitだが、誰でも呼べるという意味ではない。
  • 正当な権限によるローカル照合は、鍵の投入確認に役立つ。しかし、実際のパケット認証や対向装置の受信、経路状態、切替準備、ネットワークの健全性は証明しない。新旧鍵の併用中は、通信が旧鍵に支えられている可能性も残る。

鍵を取り出さず、鍵に計算をさせる

診断担当者の手元にあるのは、試したいバイナリ文字列と、それに対応すると考える候補MACだけだとする。担当者は、対象の鍵項目を指定して管理アクションを呼ぶ。装置は、その項目に設定された鍵とアルゴリズムを使って内部で計算し、渡されたMACと比較する。正常に処理された場合、返るのは一致か不一致かという真偽値である。これはRFC 9647が定義する機能を説明する仮定であり、特定の設備で実施された試験ではない。RFC 9647第2.3節

入力の名前はtest-stringとmacで、どちらもバイナリ型である。出力はブール型のindication。一致すればtrue、一致しなければfalseとなる。このアクションは、装置が計算したMACを呼出者へ返さない。候補を先に提出し、装置の内部計算と一致するかを確かめる。この入出力の制約が、テストに委ねられた権限の範囲を決めている。RFC 9647第2.3節

鍵値を外へ返さないことには意味がある。診断のたびに担当者へ秘密を配布せず、設定された組合せが期待した結果を生むかを確認できるからだ。同時に、呼出者は自分が選んだ入力について、秘密に依存する計算を起動できる。出力が二通りに限られていても、秘密を使わせる権限そのものは存在する。

この用途は、情報モデルにも位置付けられている。RFC 9046第3.8節は、鍵値の読取りを認めず、鍵とアルゴリズムが期待した結果を出すか確かめるテスト操作を記述する。RFC 9647は、その管理機能をYANGのアクションとして表現している。読めない秘密について診断を可能にする設計には、診断を委任する価値と、委任先を決める責任が伴う。RFC 9046第3.8節、RFC 9647第2.3節

鍵の名前と、鍵を使わせる資格

RFC 9647の鍵項目には、name、use-send、use-verify、value、algorithmが置かれる。nameは、読めない値の代わりに管理対象を識別する手掛かりとなる。use-sendは送信するBabelパケットに含めるMACの計算にその鍵を使うか、use-verifyは受信パケットの検証に使うかを表す。algorithmは、その鍵で用いるMACアルゴリズムを指定する。RFC 9647第2.3節

ここには、異なる種類の情報が並んでいる。名前が示すのは対象であり、送受信のフラグが示すのはパケット処理での用途である。それらを見たことから、担当者が鍵の所有者である、鍵値を読める、テストを実行できる、といった資格は導けない。use-verifyが有効でも、それが管理担当者へのテスト実行許可になるわけではない。

鍵値を格納するvalueリーフには、nacm:default-deny-allが付く。一方、testは同じ鍵項目の下に置かれた別のアクションであり、valueの子ではない。鍵値を保護する指定があるという事実から、この隣接するアクションの許可や拒否をそのまま読み取ることはできない。RFC 9647第2.3節

また、default-deny-allはNACMの既定のアクセス判定に関わる指定である。鍵を読取り可能にしないというモデルの要求と、誰がどの管理操作を要求できるかという評価は、区別して扱う必要がある。指定の名称に含まれる「すべて」を、鍵に関係するあらゆる計算の全面禁止と解釈すると、テストの実行権限という論点が見えなくなる。RFC 9647第4節、RFC 8341第3.4.5節

実行を決める、祖先ノードと規則の順序

通常のNACM適用下でYANGアクションを呼ぶには、二つの条件を満たさなければならない。第一に、呼出先を特定するデータノード階層のすべてのインスタンスを読めること。第二に、そのアクションを実行する権限があることだ。RFC 8341第3.1.3節は、いずれかを満たさなければaccess-deniedとして要求を拒否すると定める。RFC 8341第3.1.3節

Babelのテストなら、ルーティングの上位ノードから対象の鍵セット、鍵項目に至る、アクションを特定する祖先階層全体が対象になる。対象の鍵項目だけを読めれば十分、という条件ではない。隣接するvalueリーフはこの祖先に含まれないため、その読取禁止が直ちにテストの拒否へつながることもない。RFC 9647第2.3節、RFC 8341第3.1.3節

実行権限は、役職名やアカウントの呼び方からは分からない。RFC 8341第3.4.5節では、セッションに対応するグループを求め、そのグループに適用される規則リストと規則を順番に評価する。モジュール、対象パス、要求するアクセス操作などが一致する最初の規則が、許可または拒否を決める。外部グループを利用する設定なら、その情報も評価に加わる。RFC 8341第3.4.5節

したがって、規則のどこかに拒否が書かれているだけでは足りない。その要求に先に一致する許可規則があれば、後の拒否は判断に使われない。反対に、一致する規則で拒否が決まった要求を、既定値が許可へ戻すこともない。対象アクションを名指しした記述だけでなく、上位パスやモジュールを対象とする広い規則にも注意が必要になる。RFC 8341第3.4.5節

一致する実行規則で判断が決まらない場合に、実行の既定値であるexec-defaultが適用される。第5.1節が示す標準値はpermitである。ただし、実際の設定値は確認を要し、祖先ノードの読取条件も残る。鍵値を読めないアカウントにも実行権限が成立し得ることと、すべてのアカウントに成立することの間には、この評価手続がある。RFC 8341第3.4.5節・第5.1節

呼出先を特定する祖先ノードの読取り 対象アクションの実行判定 通常のNACM適用下での帰結
すべて許可 最初に一致する実行規則が許可 呼出しに必要な権限条件を満たす
すべて許可 最初に一致する実行規則が拒否 呼出しは拒否される
一つでも拒否 実行側では許可 祖先の読取条件を満たさず、呼出しは拒否される
すべて許可 一致する実行規則がなく、実際のexec-defaultがpermit 呼出しに必要な権限条件を満たす
すべて許可 一致する実行規則がなく、実際のexec-defaultがdeny 呼出しは拒否される

この表はアクセス権の判定を整理したものであり、特定の製品やセッションを検査した結果ではない。対象機能の実装、要求の妥当性、処理の完了まで保証するものでもない。NACMが有効か、通常のセッションかといった前提も含め、実効権限は具体的な状況に即して評価する必要がある。RFC 8341第3.1.3節・第3.4.5節

許可の主体は、鍵を預かる担当者だけではない

RFCが用意する機構を、個々の人や自動処理へ割り当てるのは、運用組織の方針と設定である。業務上の責任者は、誰にどの鍵を試させる必要があるかを決める。アクセス制御の管理者は、それを対象範囲と操作権限へ落とし込む。認証やグループの管理者による所属変更も、どの規則が適用されるかを変え得る。サーバーは、セッションの識別情報と設定に基づいて要求を判定する。RFC 8341第3.4.2節・第3.4.5節

ここから先は組織設計の問題である。「鍵の管理担当者」という一つの肩書に責任を集約しても、別の担当者がグループを変更でき、別の自動処理が実行要求を送るなら、権限の配分は複数の判断に依存する。鍵値を変更しないまま、秘密を使わせられる主体の集合が変わることもある。

実装を提供する側には、定義された入出力とアクセス制御を正しく扱う役割がある。一方、どの職務にテストを委任するか、結果をどの変更判断へ結び付けるかは、仕様だけでは決まらない。鍵を保管する責任、診断を依頼する責任、実行を許可する責任、結果で先へ進む責任を説明できることが、この機能の利用条件になる。

正当な投入確認には、期待値の出所が要る

正当な利用を考えると、権限を分ける利点が具体的になる。例えば、鍵の投入を担当する管理工程が、承認された試験文字列と期待MACの組を用意し、診断担当者にはその組だけを渡す運用が考えられる。担当者は設定後の対象項目を選んでテストし、期待した計算結果になるかを確かめる。鍵値の読取りを許さずに、確認作業を委任できる。RFC 9647第4節

ただし、返されたtrueの意味は、期待値の出所に左右される。信頼できる投入記録から用意された組なら、対象の鍵とアルゴリズムが、その試験について想定どおり振る舞うという材料になる。どこから来たか分からない組が一致しても、業務上意図した鍵の確認になったとは限らない。投入と期待値作成に同じ取り違えが入り込むという仮定なら、一致だけでその取り違えを見つけることもできない。

こうした利用手順や期待値の管理方法は、本稿の運用上の分析であり、RFCが義務付ける工程ではない。狭く定義した判定としては、「指定した項目が、この試験組に対して期待した結果を返したので、投入確認の次段階へ進む」と整理できる。鍵のバイト列を取り出して同一性を直接確認したことにも、担当者が秘密を所有していることにもならない。

不一致にも限界がある。falseだけでは、候補MAC、試験文字列、対象項目、想定するアルゴリズムのどこに食い違いがあるかは特定できない。さらに、アクセス拒否や処理未完了は不一致の結果とは別である。権限不足で比較に到達していない要求を「鍵が間違っている」と扱えば、実行権限の問題を鍵の問題へ転嫁してしまう。

ローカルの一致から、鍵の切替へは飛べない

RFC 8967が定める実際のBabel認証には、パケットを対象としたMAC計算と受信処理がある。受信側ではMACの照合に加え、カウンターやインデックス、必要に応じたチャレンジに関わる処理も行われる。管理アクションへ渡した任意の文字列が一致したという事実は、これらのパケット処理が実行された証拠を含まない。RFC 8967第4節〜第6節

装置内の比較が成功しても、その鍵によるMACを持つパケットが送信されたとは分からない。送信を確認しても、対向装置が受信し、必要な認証条件を満たして受理したかは別の観測を要する。さらに、経路状態やネットワーク全体の健全性には、それぞれの対象を観測した証拠が必要になる。テストの返り値には、この隔たりを埋める情報がない。

鍵の更新時には、この限界が判断に直結する。RFC 8967第5節では、新鍵を追加し、新旧の鍵を併用する段階を経て旧鍵を取り除く。パケットに載るのは、それぞれの鍵で計算したMACであり、鍵のバイト列ではない。併用中は、他の受信条件を満たす前提で、新旧いずれかの鍵による認証が受理を支え得る。RFC 8967第4.2節・第5節・第6.1節

したがって、新鍵のローカルテストが成功し、通信も続いているという二つの観測を合わせても、旧鍵への依存が解消したとは言えない。通信が旧鍵によって成立している可能性が残るからだ。新鍵だけで必要な認証が成立するという判断には、その判断に対応する独立した証拠が要る。どの方法で取得するかは実装と運用条件に依存し、管理テストの真偽値が代行することはできない。

管理上の識別名にも同じ注意が必要になる。RFC 8967第6.1節のMAC TLVには、管理モデルの鍵名をそのまま示すフィールドはない。パケット内にMACがあることだけで、どの管理項目の鍵が受理を支えたかまで自動的に分かるとは限らない。ローカルの鍵名、実際のパケット、受信側の判断を結び付ける証拠の有無が、切替判断の確かさを左右する。RFC 8967第6.1節

出力が少なくても、実行の委任は管理対象になる

RFC 9647第4節は、テストへのアクセスを制御する必要性を述べ、応答時間などのサイドチャネルを通じて情報が間接的に示される可能性にも触れる。入力MACと内部で生成したMACの比較には、定数時間比較を使うことをSHOULDとしている。この規範上の強さを、必須の保証へ読み替えることはできない。記述自体も、実際に漏えいが観測されたという報告ではない。RFC 9647第4節

定数時間比較は実装上の推奨事項であり、誰へ実行権限を与えるかを決めてはくれない。また、比較にその方法を使うことから、管理要求全体の応答時間が常に一定であるとも導けない。実装の性質と、呼出者に委ねる権限の範囲を、それぞれ確認する必要がある。

権限を広く与え過ぎれば、業務上の必要を説明できない主体にも、秘密を使う計算を起動させることになる。個々の呼出しが正当に許可されたとしても、どの目的のための委任だったかを追う負担は増え得る。返り値が少ないことを理由に、この権限を単なる情報閲覧と同じ扱いにすると、実行可能な主体の拡大を捉えにくくなる。

逆に、狭くし過ぎれば、正当な投入確認や更新準備が、少数の権限保有者の対応待ちになる可能性がある。その待ち時間を解消するために共通の強いアカウントへ作業が集中すれば、委任の範囲と責任の所在をかえって説明しにくくする。これは想定される運用上の誘因であり、特定の組織で起きた事実を述べているわけではない。

判断の基準は、診断に必要な範囲を明示して委任できるかどうかにある。対象の鍵、担当業務、実行主体、結果を利用する判断が対応していれば、鍵値を配布せずに作業を進める利点を保てる。権限の広狭は、その対応関係と業務上の必要から評価することになる。

真偽値に、誰の行為だったかを結び付ける

自動化された呼出しでは、サービスアカウントの名前と、作業を発生させた主体を分けて考える必要がある。サーバーが識別するアカウントを記録しても、それだけでは、どのジョブが、誰の依頼を受け、何を確認するために実行したかまでは分からない。認証で確定した主体とNACMの権限判定を、業務上の責任へ結び付ける記録が必要になる。RFC 8341第3.4.2節

監査可能性を高める設計としては、実行時刻、認証された主体、対象の装置と鍵項目、試験組の参照と出所、許可判定に用いた方針やグループの状態、比較結果を結び付ける方法が考えられる。自動処理なら、ジョブの識別子や依頼・承認の記録も接続する。これらは本稿が示す統治上の選択肢であり、RFCが定めた監査書式ではない。

特に、実行時の文脈を残す意味は大きい。RFC 8341第3.4節では、メッセージ処理開始時に有効なアクセス制御規則を、そのメッセージの処理中に用いる。後日に取得した現在の方針だけでは、当時なぜ許可されたかを説明できない場合がある。鍵値を記録へ複製することなく、対象の履歴や管理された試験組への参照を保存する設計が検討できる。RFC 8341第3.4節

さらに、結果を受け取った人が何を判断したかも残す価値がある。同じtrueでも、投入確認を終える判断と、旧鍵を廃止する判断では必要な証拠が違う。テストを実行する許可に、送受信フラグを変える許可や、旧鍵を削除する判断まで含めたことにはならない。

四つのRFCから確認できるのは、この機能、アクセス制御の条件、そしてパケット認証との境界である。実在する装置の設定、実際の権限付与、タイミングに関する実装特性、更新作業の成否は分からない。普遍的なアクセス、NACMの回避、導入済み環境の欠陥を認定する根拠にはならない。

鍵を読めない担当者にも、業務に必要な診断を委ねることはできる。その委任を説明するには、誰が対象の秘密を使わせられるのかを実効権限で確かめ、得られた一致が支える判断を限定する必要がある。秘密の非開示を維持しながら、その秘密を使う行為と責任を見えるようにすることが、このテストの管理上の核心である。

出典