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

1.3 Choosing a Principal with Which to Communicate (通信する Principal の選択)

概要​

Kerberos プロトコルは, 通信する相手が, 主張された識別情報 (principal 名) を用いて KDC に登録されたのと同じエンティティであることを検証する手段を提供します。ただし, その識別情報が, 通信しようとするエンティティに対応するかどうかを判断することは依然として必要です。

判断方法​

構文的な判断​

適切なデータが事前に交換されている場合, アプリケーションは次に基づいて構文的に判断を行えます:

  • アプリケーションプロトコル仕様
  • ユーザーが提供した情報
  • 設定ファイル

例: telnet サーバーのサーバー principal 名は, 次から導出される場合があります:

  • telnet コマンドラインからのユーザー指定ホスト名
  • アプリケーションプロトコル仕様による "host/" プレフィックス
  • ホスト名のドメイン部分から導出される Kerberos レルムへのマッピング

信頼できる第三者​

判断には信頼できる第三者に依存できますが, 次の場合に限ります:

  • 第三者から得たデータが, 適切に完全性保護されている
  • 第三者サーバー上に存在している間もデータが保護されている
  • 伝送中もデータが保護されている

セキュリティ要件​

DNS とホスト名の正規化​

してはならない (MUST NOT):

  • 実装は, サービス principal 名のホスト名部分を正規化するために, 安全でない DNS クエリを使用してはならない
  • ある名前を別名にマッピングするために, 安全でない DNS クエリを使用してはならない

してもよい (MAY):

  • セキュアなネームサービスがない環境では, アプリケーションは, 修飾されていないホスト名に静的に設定されたドメイン名を付加してもよい
  • それ以上は行わないべきである

セキュアなネームサービス:

  • 利用可能であれば, セキュアなネームサービス機能をホスト名正規化に信頼してもよい
  • そのようなクライアントによる正規化を KDC 実装が要求すべきではない (SHOULD NOT)

実装上の注意​

多くの現行実装は, 提供されたサービス名をある程度正規化しており, しばしば DNS を使用します。これはセキュリティ上の問題を生みます。ただし, 実装間で次について一貫性はありません:

  • サービス名を小文字に折りたたむかどうか
  • 逆引き (reverse resolution) を用いるかどうか

ベストプラクティス (Best Practice): 相互運用性とセキュリティを最大にするために, アプリケーションは, ユーザーが入力した名前を小文字に折りたたんだ結果の名前をセキュリティ機構に渡し, それ以外の変更や正規化は行わないべきである (SHOULD)。

参照​

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

📊 翻訳品質チェック​

  • 段落対応: 原文の節・リスト構造と訳文が1:1対応
  • リンク形式: 参照リンク保持
  • 用語の双語表記: principal, DNS 等に双語・説明を適用
  • RFC 2119: MUST NOT, MAY, SHOULD NOT, SHOULD を明示
  • MDX 安全: 特殊記号に注意
  • 技術保持: フィールド名, プロトコル用語保持
  • 句読点規範: 英文句読点使用
  • 言語純度: 日本語
  • ディレクトリ正確: ja ディレクトリ

📍 現在の進捗​

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