メインコンテンツまでスキップ

1.5 Extending Kerberos without Breaking Interoperability (相互運用性を損なわず Kerberos を拡張する)

概要​

展開されている Kerberos 実装のベースが大きくなるにつれ, Kerberos の拡張はより重要になります。本節は, 将来の実装が相互運用性を維持できるようにするための指針を示します。

拡張機構​

Kerberos はプロトコル拡張性のための一般的な機構を提供します:

  • プロトコルメッセージには型付きの穴 (typed holes) が含まれる
  • サブメッセージには, 解釈を定義する整数とともに octet-string が含まれる
  • 整数型は中央で登録される
  • ベンダー拡張および IETF による標準化に利用できる

定義: 本ドキュメントにおいて "extension (拡張)" とは, 既存の型付き穴に挿入する新しい型を定義することを指し, (明示されていない限り) ASN.1 型に新しいフィールドを追加することではありません。

1.5.1. RFC 1510 との互換性​

制約​

既存の Kerberos メッセージ形式は, ASN.1 型にフィールドを追加することで容易には拡張できません:

  • 追加フィールドを送ると, メッセージ全体が破棄されることが多い
  • エラー表示は提供されない

実装への要件​

未知のメッセージ拡張を受信するすべての新規または変更された実装は:

  • SHOULD (すべきである): 拡張のエンコーディングを保持する
  • SHOULD (すべきである): その存在を無視する
  • MUST NOT (してはならない): 拡張が存在するだけを理由に要求を拒否してはならない

例外: 認可データ (Authorization Data)​

未知の認可データ要素型が, チケット付与サービス以外のサーバーによって次のいずれかで受信された場合:

  • AP-REQ 内, または
  • AP-REQ に含まれるチケット内

そのとき認証は失敗しなければならない (MUST)。

根拠 (Rationale): 認可データはチケットの利用を制限します。サービスが制限が適用されるか判断できない場合, セキュリティ上の弱点になり得ます。

ベストプラクティス (Best Practice): オプションの認可要素は AD-IF-RELEVANT 要素で囲むべきである (SHOULD)。

チケット付与サービス (TGS) の動作​

TGS は:

  • 未知の認可データ型は無視しつつ, 派生チケットへ伝播しなければならない (MUST)
  • 例外: データ型が MANDATORY-FOR-KDC 要素に埋め込まれている場合, 要求は拒否される

1.5.2. 拡張可能なメッセージの送信​

中核原則​

拡張を理解していない古い実装に対しても, 送信するメッセージを理解できるようにするため, 注意が必要です。

規則: 送信者が拡張がサポートされていると分かる場合を除き, 拡張はコアメッセージまたは既に定義された拡張の意味を変えてはなりません。

例​

KDC-REP の暗号化部分を復号するのに必要な鍵情報を含む拡張は, 受信者がその拡張をサポートすることが分かっている場合にのみ使用できます。クライアントは AS-REQ 列の padata 要素でサポートを示せます。KDC は padata 要素がある場合にのみ拡張を使うべきです。

ベストプラクティス (Best Practice): ポリシーが拡張を要求する場合, 受信者がサポートしていない可能性があるときにそれを使うのではなく, 拡張が必要であることを示すエラーを返すべきです。これによりデバッグが容易になります。

参照​

完全な技術的詳細はRFC 4120 セクション1.5を参照してください。

📊 翻訳品質チェック​

  • 段落対応: 原文の節・リストと訳文が1:1対応
  • リンク形式: 参照リンク保持
  • 用語の双語表記: authorization data, TGS 等
  • RFC 2119: MUST, MUST NOT, SHOULD を明示
  • 技術保持: ASN.1, padata, AD-IF-RELEVANT 等保持
  • 句読点規範: 英文句読点使用
  • 言語純度: 日本語
  • ディレクトリ正確: ja ディレクトリ

📍 現在の進捗​

  • RFC 番号: 4120
  • 対象言語: 🇯🇵 日本語
  • 微タスク: 1-5-extending-kerberos (短縮版)
に最終更新