[要約] RFC 5868は、Kerberosのクロスレルム操作に関する問題を説明しています。このRFCの目的は、異なるレルム間でのKerberosの運用に関連する問題を特定し、解決策を提案することです。
Internet Engineering Task Force (IETF) S. Sakane
Request for Comments: 5868 K. Kamada
Category: Informational S. Zrelli
ISSN: 2070-1721 Yokogawa Electric Corp.
M. Ishiyama
Toshiba Corp.
May 2010
Problem Statement on the Cross-Realm Operation of Kerberos
Kerberosのクロスリアム操作に関する問題声明
Abstract
概要
This document provides background information regarding large-scale Kerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC 4120.
このドキュメントは、RFC 4120で定義されている現在のKerberos Cross-Realm認証モデルの問題を特定することを目的として、産業部門での大規模なKerberosの展開に関する背景情報を提供します。
This document describes some examples of actual large-scale industrial systems, and lists requirements and restrictions regarding authentication operations in such environments. It also identifies a number of requirements derived from the industrial automation field. Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem of Kerberos cross-realm operations.
このドキュメントでは、実際の大規模な産業システムの例について説明し、そのような環境での認証操作に関する要件と制限をリストします。また、産業用自動化分野から派生した多くの要件を特定しています。それらは産業自動化の分野で見られますが、これらの要件は十分に一般的であり、Kerberos Cross-Realm運用の問題に適用できます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5868.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5868で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
2. Kerberos System .................................................4
2.1. Kerberos Basic Operation ...................................4
2.2. Cross-Realm Operation ......................................4
3. Applying Cross-Realm Kerberos in Complex Environments ...........5
4. Requirements ....................................................7
5. Issues ..........................................................8
5.1. Unreliability of Authentication Chain ......................8
5.2. Possibility of MITM in the Indirect Trust Model ............8
5.3. Scalability of the Direct Trust Model ......................9
5.4. Exposure to DoS Attacks ....................................9
5.5. Client's Performance ......................................10
5.6. Kerberos Pre-Authentication Problem in Roaming Scenarios ..10
6. Implementation Considerations ..................................11
7. Security Considerations ........................................11
8. Acknowledgements ...............................................11
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................11
Kerberos Version 5 is a widely deployed mechanism that enables a server to authenticate a client before granting it access to a certain service. Each client belongs to a managed domain called a realm. Kerberos supports authentication when a client and a server belong to different realms. This is called cross-realm authentication.
Kerberosバージョン5は、特定のサービスへのアクセスを許可する前に、サーバーがクライアントを認証することを可能にする広く展開されているメカニズムです。各クライアントは、領域と呼ばれる管理されたドメインに属します。Kerberosは、クライアントとサーバーが異なる領域に属している場合、認証をサポートします。これは、Cross-RealM認証と呼ばれます。
There exist several ways for using Kerberos in large-scale distributed systems. Such infrastructures are typically split into several managed domains for geographical reasons, and to implement different management policies. In order to ensure smooth network operations in such systems, a common authentication mechanism for the different managed domains is required. When using the Kerberos cross-realm operation in large-scale distributed systems, some issues arise.
大規模な分散システムでKerberosを使用するには、いくつかの方法があります。このようなインフラストラクチャは、通常、地理的な理由でいくつかの管理されたドメインに分割され、さまざまな管理ポリシーを実装します。このようなシステムでのスムーズなネットワーク操作を確保するために、さまざまな管理ドメインの共通認証メカニズムが必要です。大規模な分散システムでKerberos Cross-RealM操作を使用すると、いくつかの問題が発生します。
As industrial automation is moving towards wider adoption of Internet standards, the Kerberos authentication protocol represents one of the best alternatives for ensuring the confidentiality and the integrity of communications in control networks while meeting performance and security requirements. However, the use of Kerberos cross-realm operations in large-scale industrial systems may introduce issues that could cause performance and reliability problems.
産業自動化がインターネット標準のより広範な採用に向かっているため、Kerberos認証プロトコルは、パフォーマンスとセキュリティ要件を満たしながら、制御ネットワークでのコミュニケーションの整合性を確保するための最良の代替手段の1つです。ただし、大規模な産業システムでKerberosクロスリアム運用を使用すると、パフォーマンスと信頼性の問題を引き起こす可能性のある問題が発生する可能性があります。
This document briefly describes the Kerberos Version 5 system and its cross-realm operation mode. Then it describes two case-study systems that Kerberos could be applied to, and describes seven requirements in those systems (in terms of both management and operations) that outline various constraints that Kerberos operations might be subjected to. Finally, it lists six issues related to Kerberos cross-realm operations when applied to those systems.
このドキュメントでは、Kerberosバージョン5システムとそのクロスリアム操作モードについて簡単に説明します。次に、Kerberosを適用できる2つのケーススタディシステムを説明し、Kerberosの操作にさらされる可能性のあるさまざまな制約を概説するシステム（管理と運用の両方の観点から）の7つの要件を説明します。最後に、これらのシステムに適用された場合、Kerberos Cross-Realm操作に関連する6つの問題がリストされています。
Note that this document might not describe all issues related to Kerberos cross-realm operations. New issues might be found in the future. It also does not propose any solution to the issues described in this document. Furthermore, publication of this document does not mean that each of the issues has to be solved by the IETF members. Detailed analysis of the issues, problem definitions, and exploration of possible solutions may be carried out as separate work items.
このドキュメントは、Kerberos Cross-RealM操作に関連するすべての問題を説明していない可能性があることに注意してください。将来、新しい問題が見つかるかもしれません。また、このドキュメントに記載されている問題に対する解決策も提案していません。さらに、この文書の公開は、各問題をIETFメンバーが解決する必要があることを意味しません。可能な解決策の問題、問題の定義、および調査の詳細な分析は、個別の作業項目として実行される場合があります。
This document assumes that the readers are familiar with the terms and concepts described in "The Kerberos Network Authentication Service (V5)" ([RFC4120]).
このドキュメントは、読者が「The Kerberos Network Authentication Service（V5）」（[RFC4120]）に記載されている用語と概念に精通していることを前提としています。
Kerberos [RFC4120] is a widely deployed authentication system. The authentication process in Kerberos involves principals and a Key Distribution Center (KDC). The principals can be users or services. Each KDC maintains a database of principals and shares a secret key with each registered principal.
Kerberos [RFC4120]は、広く展開されている認証システムです。Kerberosの認証プロセスには、プリンシパルとキー配布センター（KDC）が含まれます。校長はユーザーまたはサービスにすることができます。各KDCはプリンシパルのデータベースを維持し、登録された各プリンシパルとシークレットキーを共有します。
The authentication process allows a user to acquire the needed credentials from the KDC. These credentials allow services to authenticate the users before granting them access to the resources. An important part of the credentials is called "tickets". There are two kinds of tickets: the Ticket-Granting Ticket (TGT) and the service ticket. The TGT is obtained periodically from the KDC and has a limited lifetime, after which it expires and the user must renew it. The TGT is used to obtain the other kind of tickets -- service tickets. The user obtains a TGT from the Authentication Service (AS), a logical component of the KDC. The process of obtaining a TGT is referred to as "AS exchange". When a request for a TGT is issued by the user, the AS responds by sending a reply packet containing the credentials, which consist of the TGT along with a random key called the "TGS session key". The TGT contains information encrypted using a secret key associated with a special service, referred to as the "TGS" (Ticket-Granting Service). The TGS session key is encrypted using the user's key so that the user can obtain the TGS session key only if she knows the secret key she shares with the KDC. The TGT is then used to obtain a service ticket from the TGS -- the second component of the KDC. The process of obtaining service tickets is referred to as "TGS exchange". The request for a service ticket consists of a packet containing a TGT and an "Authenticator". The Authenticator is encrypted using the TGS session key and contains the identity of the user as well as time stamps (for protection against replay attacks). After decrypting the TGT received from the user, the TGS extracts the TGS session key. Using that session key, it decrypts the Authenticator and authenticates the user. Then, the TGS issues the credentials requested by the user. These credentials consist of a service ticket and a session key that will be used to authenticate the user to the desired application service.
認証プロセスにより、ユーザーはKDCから必要な資格情報を取得できます。これらの資格情報により、サービスはリソースへのアクセスを許可する前に、ユーザーを認証することができます。資格情報の重要な部分は「チケット」と呼ばれます。チケットには、チケット栽培チケット（TGT）とサービスチケットの2種類があります。TGTは定期的にKDCから取得され、寿命が限られており、その後有効期限が切れ、ユーザーはそれを更新する必要があります。TGTは、他の種類のチケット（サービスチケット）を入手するために使用されます。ユーザーは、KDCの論理コンポーネントである認証サービス（AS）からTGTを取得します。TGTを取得するプロセスは、「交換」と呼ばれます。TGTのリクエストがユーザーによって発行されると、ASは、「TGSセッションキー」と呼ばれるランダムキーで構成される資格情報を含む応答パケットを送信することで応答します。TGTには、「TGS」（チケット栽培サービス）と呼ばれる特別なサービスに関連付けられたシークレットキーを使用して暗号化された情報が含まれています。TGSセッションキーは、ユーザーのキーを使用して暗号化され、ユーザーがKDCと共有する秘密キーを知っている場合にのみ、TGSセッションキーを取得できるようにします。TGTは、KDCの2番目のコンポーネントであるTGSからサービスチケットを取得するために使用されます。サービスチケットを取得するプロセスは、「TGS Exchange」と呼ばれます。サービスチケットのリクエストは、TGTと「Authenticator」を含むパケットで構成されています。Authenticatorは、TGSセッションキーを使用して暗号化され、ユーザーのIDとタイムスタンプ（リプレイ攻撃に対する保護のため）が含まれています。ユーザーから受信したTGTを復号化した後、TGSはTGSセッションキーを抽出します。そのセッションキーを使用して、認証機を復号化し、ユーザーを認証します。次に、TGSはユーザーが要求した資格情報を発行します。これらの資格情報は、サービスチケットと、ユーザーを目的のアプリケーションサービスに認証するために使用されるセッションキーで構成されています。
The Kerberos protocol provides cross-realm authentication capabilities. This allows users to obtain service tickets to access services in foreign realms. In order to access such services, the users first contact their home KDC asking for a TGT that will be used with the TGS of the foreign realm. If there is a direct trust relationship between the home realm and the foreign realm (practically materialized in shared inter-realm keys), the home KDC delivers the requested TGT.
Kerberosプロトコルは、Cross-RealM認証機能を提供します。これにより、ユーザーは外国の領域でサービスにアクセスするためのサービスチケットを取得できます。そのようなサービスにアクセスするために、ユーザーは最初に外国の領域のTGSで使用されるTGTを求めて自宅KDCに連絡します。ホームレルムと外国の領域（共有間のリアルム間キーで実質的に具体化された）の間に直接的な信頼関係がある場合、ホームKDCは要求されたTGTを提供します。
However, if the home realm does not share inter-realm keys with the foreign realm, we are in a so-called indirect trust model situation. In this situation, the home KDC will provide a TGT that can be used with an intermediary foreign realm that is likely to be sharing inter-realm keys with the target realm. The client can use this "intermediary TGT" to communicate with the intermediary KDC, which will iterate the actions taken by the home KDC. If the intermediary KDC does not share inter-realm keys with the target foreign realm, it will point the user to another intermediary KDC (just as in the first exchange between the user and her home KDC). However, in the other case (when it shares inter-realm keys with the target realm), the intermediary KDC will issue a TGT that can be used with the KDC of the target realm. After obtaining a TGT for the desired foreign realm, the client uses it to obtain service tickets from the TGS of the foreign realm. Finally, the user accesses the service using the service ticket.
ただし、ホームレルムが外国のキーを外国の領域と共有していない場合、私たちはいわゆる間接的な信頼モデルの状況にあります。この状況では、Home KDCは、ターゲットの領域とRealm間キーを共有する可能性が高い中間外国の領域で使用できるTGTを提供します。クライアントは、この「中間TGT」を使用して、中間KDCと通信することができます。中間KDCがターゲット外国の領域とRealm間キーを共有しない場合、ユーザーは別の仲介KDCを指します（ユーザーと自宅KDCの最初の交換のように）。ただし、他のケースでは（ターゲットレルムとREALM間キーを共有する場合）、中間KDCは、ターゲットレルムのKDCで使用できるTGTを発行します。目的の外国領域のTGTを取得した後、クライアントはそれを使用して外国のTGSからサービスチケットを取得します。最後に、ユーザーはサービスチケットを使用してサービスにアクセスします。
When the realms belong to the same institution, a chain of trust can be automatically determined by the client or the KDC by following the DNS domain hierarchy and assuming that a parent domain shares keys with all of its child sub-domains. However, since this assumption is not always true, in many situations, the trust path might have to be specified manually. Since the Kerberos cross-realm operations with the indirect inter-realm trust model rely on intermediary realms, the success of the cross-realm operation completely depends on the realms that are part of the authentication path.
レルムが同じ機関に属している場合、DNSドメイン階層に従い、親ドメインがすべての子サブドメインとキーを共有すると仮定することにより、クライアントまたはKDCによって自動的に信頼を決定できます。ただし、この仮定は常に真実ではないため、多くの状況では、信頼パスを手動で指定する必要がある場合があります。間接間の間接間トラストモデルを使用したKerberos Cross-RealMの運用は、中間領域に依存しているため、クロスリアム操作の成功は、認証パスの一部である領域に完全に依存します。
In order to help the reader understand requirements and restrictions for cross-realm authentication operations, this section describes the scale and operations of two actual systems that could be supported by cross-realm Kerberos. The two systems would be most naturally implemented using different trust models, which will imply different requirements for cross-realm Kerberos.
読者がクロスリアム認証操作の要件と制限を理解するのを支援するために、このセクションでは、クロスリアムケルベロスによってサポートできる2つの実際のシステムの規模と操作について説明します。2つのシステムは、異なる信頼モデルを使用して最も自然に実装されます。これは、Cross-Realm Kerberosのさまざまな要件を暗示します。
Hereafter, we will consider an actual petrochemical company [SHELLCHEM], and overview two examples among its plants. Petrochemical companies produce bulk petrochemicals and deliver them to large industrial customers. The company under consideration possesses 43 plants all over the world managed by operation sites in 35 countries. This section shows two examples of these plants.
以下、実際の石油化学会社[Shellchem]を検討し、その植物の2つの例を概要します。石油化学企業は、大量の石油化学物質を生産し、大規模な産業顧客に届けます。検討中の会社は、35か国の運用サイトが管理する世界中に43の植物を所有しています。このセクションは、これらの植物の2つの例を示しています。
The first example is a plant deploying a centralized system [CSPC]. CSPC, also referred to as China National Offshore Oil Corporation (CNOOC) and Shell Petrochemicals Company, is operated by a joint enterprise of these two companies. This system is one of the largest of its type in the world. It is located in an area of 3.4 square kilometers in the north coast of Daya Bay, Guangdong, in southeast China. 3,000 network segments are deployed in the system, and 16,000 control devices are connected to local area networks. These devices belong to 9 different subsystems. A control device can have many control and monitoring points. In the plant considered in this example, there are 200,000 control points in all. They are controlled by 3 different control centers.
最初の例は、集中システム[CSPC]を展開するプラントです。CSPCは、中国国立オフショアオイルコーポレーション（CNOOC）およびShell Petrochemicals Companyとも呼ばれ、これら2社の共同企業によって運営されています。このシステムは、世界最大のタイプの1つです。中国南東部の広東省のダヤ湾の北海岸にある3.4平方キロメートルの地域にあります。3,000個のネットワークセグメントがシステムに展開され、16,000個の制御デバイスがローカルエリアネットワークに接続されています。これらのデバイスは9つの異なるサブシステムに属します。制御デバイスは、多くの制御ポイントと監視ポイントを持つことができます。この例で考慮されているプラントでは、全部で200,000の制御ポイントがあります。それらは3つの異なるコントロールセンターによって制御されます。
Another example is a distributed system [NAM]. The Nederlandse Aardolie Maatschappij (NAM) is operated by a partnership company of two enterprises that represent the oil company. This system is composed of some plants that are geographically distributed within the range of 863 square kilometers in the northern part of the Netherlands. 26 plants, each one called a "cluster", are scattered in the area. They are connected to each other by a private ATM WAN. Each cluster has approximately 500-1,000 control devices. These devices are managed by a local control center in each cluster. In the entire system of the NAM, there are one million control points.
別の例は、分散システムです[NAM]。Nederlandse Aardolie Maatschappij（NAM）は、石油会社を代表する2つの企業のパートナーシップ会社によって運営されています。このシステムは、オランダ北部の863平方キロメートルの範囲内に地理的に分布しているいくつかの植物で構成されています。それぞれが「クラスター」と呼ばれる26の植物がこの地域に散らばっています。それらはプライベートなATMワンによって互いに接続されています。各クラスターには、約500〜1,000の制御デバイスがあります。これらのデバイスは、各クラスターのローカルコントロールセンターによって管理されています。NAMのシステム全体に、100万の制御ポイントがあります。
In both examples, the end devices are basically connected to a local network by a twisted-pair cable, with a low bandwidth of 32 kbps. End devices use a low clock CPU -- for example, the H8 [RNSS-H8] and M16C [RNSS-M16C]. Furthermore, to reduce power consumption, the clock on the CPU may be lowered. This adjustment restricts the amount of total energy in the device, thereby reducing the risk of explosions.
どちらの例でも、エンドデバイスは基本的に、32 kbpsの帯域幅が低いツイストペアケーブルによってローカルネットワークに接続されています。ENDデバイスは、低クロックCPU、たとえばH8 [RNSS-H8]およびM16C [RNSS-M16C]を使用します。さらに、消費電力を削減するために、CPUのクロックが低下する場合があります。この調整は、デバイス内の総エネルギーの量を制限し、それにより爆発のリスクを減らします。
A device on the network collects data from other devices monitoring the condition of the system. These data are then used to make decisions on how to control other devices via instructions transmitted over the network. If it takes time for data to travel through the network, normal operations cannot be ensured. The travel time of data from a device to another device in both examples must be within 1 second. Other control system applications may have shorter or longer timescales.
ネットワーク上のデバイスは、システムの状態を監視する他のデバイスからデータを収集します。これらのデータは、ネットワークを介して送信される命令を介して他のデバイスを制御する方法を決定するために使用されます。データがネットワークを通過するのに時間がかかる場合、通常の操作を確保することはできません。両方の例で、デバイスから別のデバイスへのデータの移動時間は1秒以内でなければなりません。他の制御システムアプリケーションは、時間スケールが短くなったり長い場合があります。
Some parts of the operations, such as control, maintenance, and environmental monitoring, can be consigned to an external organization. Also, agents may be consigned to walk around the plant and collect information about plant operations, or to watch the plant from a remote site.
制御、メンテナンス、環境監視などの運用の一部は、外部組織に委託することができます。また、エージェントは、植物の周りを歩き、植物の運用に関する情報を収集したり、遠隔地から植物を視聴するために委託される場合があります。
This section provides a list of requirements derived from the industrial automation use-case. The requirements are written in a generic fashion, and are addressed towards frameworks and architectures that underlie Kerberos cross-realm operations. The aim of these requirements is to provide some foundational guidelines to future developments of cross-realm framework or architecture for Kerberos.
このセクションでは、産業用自動化の使用ケースから派生した要件のリストを提供します。要件は一般的な方法で記述されており、Kerberos Cross-RealMの操作の根底にあるフレームワークとアーキテクチャに向けて対処されています。これらの要件の目的は、Kerberosのクロスリアムフレームワークまたはアーキテクチャの将来の開発に基本的なガイドラインを提供することです。
Requirements R-1, R-2, R-3, and R-4 are related to the management of the divided system. Requirements R-5, R-6, and R-7 are related to restrictions in such large-scale industrial networks as those discussed in Section 3.
要件R-1、R-2、R-3、およびR-4は、分割されたシステムの管理に関連しています。要件R-5、R-6、およびR-7は、セクション3で説明したような大規模な産業ネットワークの制限に関連しています。
R-1 For organizational reasons and scalability needs, a management domain typically must be partitioned into two or more sub-domains of management. Therefore, any architecture and implementation solution to the Kerberos cross-realm problem must (i) support the case of cross-realm operations across multiple management domains and (ii) support delegation of management authority from one management domain to another management domain. This must be performed without any decrease in the security level or quality of those cross-realm operations and must not expose Kerberos entities to new types of attacks.
R-1組織の理由とスケーラビリティのニーズについては、管理ドメインは通常、2つ以上のサブドメインの管理ドメインを分割する必要があります。したがって、Kerberos Cross-RealM問題に対するアーキテクチャと実装ソリューションは、（i）複数の管理ドメインにわたるクロスリアム操作の場合をサポートする必要があります。これは、これらのクロスリアム運用のセキュリティレベルまたは品質を減らすことなく実行する必要があり、Kerberosエンティティを新しいタイプの攻撃にさらしてはなりません。
R-2 Any architecture and implementation solution to the Kerberos cross-realm problem must support the co-existence of multiple independent management domains on the same network. Furthermore, it must allow organizations (corresponding to different management domains) to delegate the management of a part of, or the totality of, their system at any one time.
R-2 Kerberos Cross-RealMの問題に対するアーキテクチャと実装ソリューションは、同じネットワーク上の複数の独立した管理ドメインの共存をサポートする必要があります。さらに、組織（異なる管理ドメインに対応）が、一度にシステムの一部または全体の管理を委任できるようにする必要があります。
R-3 Any architecture and implementation solution to the Kerberos cross-realm problem must allow the use-case in which one device operationally controls another device, but each belongs to different management domains, respectively.
R-3 Kerberos Cross-RealMの問題に対するアーキテクチャと実装ソリューションは、あるデバイスが別のデバイスを動作的に制御するユースケースを許可する必要がありますが、それぞれがそれぞれ異なる管理ドメインに属します。
R-4 Any architecture and implementation solution to the Kerberos cross-realm problem must address the fundamental deployment use-case in which the management domain traverses geographic boundaries and network topological boundaries. In particular, it must address the case where devices are geographically (or topologically) remote, even though they belong to the same management domain.
R-4 Kerberos Cross-RealM問題に対するアーキテクチャと実装ソリューションは、管理ドメインが地理的境界とネットワークトポロジー境界を通過する基本的な展開ユースケースに対処する必要があります。特に、同じ管理ドメインに属していても、デバイスが地理的に（またはトポロジカル）リモートである場合に対処する必要があります。
R-5 Any architecture and implementation solution to the Kerberos cross-realm problem must be aimed at reducing operational and management costs as much as possible.
R-5 Kerberos Cross-RealMの問題に対するアーキテクチャと実装ソリューションは、可能な限り運用コストと管理コストを削減することを目的としている必要があります。
R-6 Any architecture and implementation solution to the Kerberos cross-realm problem must address the (limited) processing capabilities of devices, and implementations of solutions must be considered to aim at limiting or suppressing power consumption of such devices.
R-6 Kerberos Cross-RealMの問題に対するアーキテクチャと実装ソリューションは、デバイスの（限られた）処理機能に対処する必要があり、ソリューションの実装は、そのようなデバイスの電力消費を制限または抑制することを目的とする必要があります。
R-7 Any architecture and implementation solution to the Kerberos cross-realm problem must address the possibility of limited availability of communications bandwidth between devices within one domain, and also across domains.
R-7 Kerberos Cross-RealMの問題に対するアーキテクチャと実装ソリューションは、1つのドメイン内およびドメイン全体のデバイス間の通信帯域幅の限られた可用性の可能性に対処する必要があります。
This section lists issues in Kerberos cross-realm operations when used in large-scale systems such as the ones described in Section 3, and taking into consideration the requirements described in Section 4.
このセクションでは、セクション3で説明されているような大規模システムで使用され、セクション4で説明されている要件を考慮した場合、Kerberos Cross-Realm操作の問題をリストします。
When the trust relationship between realms follows a chain or hierarchical model, the cross-realm authentication operations are not dependable, since they strongly depend on intermediary realms that might not be under the same authority. If any of the realms in the authentication path is not available, then the principals of the end realms cannot perform cross-realm operations.
レルム間の信頼関係がチェーンモデルまたは階層モデルに従う場合、クロスリアム認証操作は信頼できません。なぜなら、それらは同じ権限の下にない可能性のある中間領域に強く依存するためです。認証パスの領域のいずれかが利用できない場合、最終領域のプリンシパルはクロスリアム操作を実行できません。
The end-point realms do not have full control of and responsibility for the success of the cross-realm operations, even if their own respective KDCs are fully functional. Dependability of a system decreases if the system relies on uncontrolled components. End-point realms have no way of knowing the authentication result occurring within intermediary realms.
エンドポイントの領域は、それぞれのKDCが完全に機能していても、クロスリアムオペレーションの成功を完全に制御し、責任を負いません。システムが制御されていないコンポーネントに依存している場合、システムの信頼性は低下します。エンドポイントレルムは、中間領域内で発生する認証結果を知る方法がありません。
Satisfying requirements R-1 and R-2 will eliminate (or considerably diminish) this issue of the unreliability of the authentication chain.
満足のいく要件R-1とR-2は、認証チェーンの信頼性の低いこの問題を排除（または大幅に減少させます）。
Every KDC in the authentication path knows the shared secret between the client and the remaining KDCs in the authentication path. This allows a malicious KDC to perform man-in-the-middle (MITM) attacks on communications between the client and any KDC in the remaining authentication chain. A malicious KDC also may learn the service session key that is used to protect the communication between the client and the actual application service. It can then use this key to perform a MITM attack.
認証パス内のすべてのKDCは、クライアントと認証パス内の残りのKDCの間の共有秘密を知っています。これにより、悪意のあるKDCは、クライアントと残りの認証チェーンのKDC間の通信に対する中間（MITM）攻撃を実行できます。悪意のあるKDCは、クライアントと実際のアプリケーションサービスとの間の通信を保護するために使用されるサービスセッションキーも学習する場合があります。その後、このキーを使用してMITM攻撃を実行できます。
In [SPECCROSS], the authors have analyzed the cross-realm operations in Kerberos and provided formal proof of the issue discussed in this section.
[Speccross]では、著者はKerberosでのクロスリアム操作を分析し、このセクションで説明した問題の正式な証拠を提供しました。
Satisfying requirements R-1 and R-2 will eliminate (or considerably diminish) this issue of MITM attacks by intermediate KDCs in the indirect trust model.
R-1とR-2の満足する要件は、間接トラストモデルの中間KDCによるMITM攻撃のこの問題を排除（またはかなり減少させる）ことを排除（または大幅に減少させます）。
In the direct trust relationship model, the realms involved in the cross-realm operations share keys, and their respective TGS's principals are registered in each other's KDC. Each realm must maintain keys with all foreign realms that it interacts with. This can become a cumbersome task and may increase maintenance costs when the number of realms increases.
直接的な信頼関係モデルでは、クロスリアムオペレーションに関与する領域がキーを共有し、それぞれのTGSのプリンシパルが互いのKDCに登録されています。各領域は、相互作用するすべての外国の領域で鍵を維持する必要があります。これは面倒な作業になる可能性があり、領域の数が増えるとメンテナンスコストを増加させる可能性があります。
Satisfying requirements R-1, R-2, and R-5 will eliminate (or considerably diminish) this issue of scalability of the direct trust model.
満足のいく要件R-1、R-2、およびR-5は、直接的な信頼モデルのスケーラビリティのこの問題を排除（またはかなり減少させます）。
One of the assumptions made when allowing the cross-realm operation in Kerberos is that users can communicate with KDCs located in remote realms. This practice introduces security threats, because KDCs are open to the public network. Administrators may think of restricting the access to the KDC to the trusted realms only. However, this approach is not scalable and does not really protect the KDC. Indeed, when the remote realms have several IP prefixes (e.g., control centers or outsourcing companies, located worldwide), then the administrator of the local KDC must collect the list of prefixes that belong to these organizations. The filtering rules must then explicitly allow the incoming traffic from any host that belongs to one of these prefixes. This makes the administrator's tasks more complicated and prone to human errors. Also, the maintenance cost increases. On the other hand, when a range of external IP addresses are allowed to communicate with the KDC, then the risk of becoming targets of attacks from remote malicious users increases.
Kerberosでのクロスリアム操作を許可するときに行われた仮定の1つは、ユーザーがリモートレルムにあるKDCと通信できることです。KDCはパブリックネットワークに開放されているため、このプラクティスはセキュリティの脅威をもたらします。管理者は、KDCへのアクセスを信頼できる領域にのみ制限することを考える場合があります。ただし、このアプローチはスケーラブルではなく、KDCを実際に保護しません。実際、リモートレルムにいくつかのIPプレフィックス（世界中にあるコントロールセンターやアウトソーシング会社など）がある場合、ローカルKDCの管理者は、これらの組織に属するプレフィックスのリストを収集する必要があります。フィルタリングルールは、これらのプレフィックスのいずれかに属するホストからの着信トラフィックを明示的に許可する必要があります。これにより、管理者のタスクがより複雑になり、人的エラーが発生しやすくなります。また、メンテナンスコストが増加します。一方、外部IPアドレスの範囲がKDCと通信できると、リモートの悪意のあるユーザーからの攻撃のターゲットになるリスクが高まります。
Satisfying requirements R-1, R-3, R-4, and R-5 will eliminate (or considerably diminish) this issue of exposure to denial-of-service (DoS) attacks.
満足のいく要件R-1、R-3、R-4、およびR-5は、サービス拒否（DOS）攻撃への暴露の問題を排除（またはかなり減少させます）。
In Kerberos cross-realm operations, clients have to perform TGS exchanges with all of the KDCs in the trust path, including the home KDC and the target KDC. A TGS exchange requires cryptographic operations and may consume a large amount of processing time, especially when the client has limited computational capabilities. As a result, the overhead of Kerberos cross-realm exchanges may cause unacceptable delays in processing.
Kerberos Cross-RealMオペレーションでは、クライアントは、Home KDCやターゲットKDCを含む、Trust PathのすべてのKDCとTGS交換を実行する必要があります。TGS交換には暗号化操作が必要であり、特にクライアントの計算機能が限られている場合、大量の処理時間を消費する場合があります。その結果、Kerberos Cross-RealM交換のオーバーヘッドは、処理に受け入れられない遅延を引き起こす可能性があります。
We ported the MIT Kerberos library (version 1.2.4), implemented a Kerberos client on our original board with H8 (16-bit, 20 MHz), and measured the process time of each Kerberos message [KRBIMPL]. It takes 195 milliseconds to perform a TGS exchange with the on-board H/W crypto engine. Indeed, this result seems reasonable, given the requirement of the response time for the control network. However, we did not modify the clock speed of the H8 during our measurement. The processing time must be slower in an actual environment, because H8 is used with a lowered clock speed in such a system. With such devices, the delays can become unacceptable when the number of intermediary realms increases.
MIT Kerberos Library（バージョン1.2.4）を移植し、H8（16ビット、20 MHz）で元のボードにKerberosクライアントを実装し、各Kerberosメッセージのプロセス時間を測定しました[krbimpl]。オンボードH/W CryptoエンジンとのTGS交換を実行するには、195ミリ秒かかります。実際、制御ネットワークの応答時間の要件を考えると、この結果は妥当と思われます。ただし、測定中はH8のクロック速度を変更しませんでした。H8は、このようなシステムのクロック速度が低くなって使用されるため、実際の環境では処理時間が遅くなる必要があります。このようなデバイスでは、中間領域の数が増加すると、遅延が受け入れられないようになります。
Satisfying requirements R-1, R-2, R-6, and R-7 will eliminate (or considerably diminish) this issue relating to the client's performance.
満足のいく要件R-1、R-2、R-6、およびR-7は、クライアントのパフォーマンスに関連するこの問題を排除（または大幅に減少させます）。
In roaming scenarios, the client needs to contact her home KDC to obtain a cross-realm TGT for the local (or visited) realm. However, the policy of the network access providers or the gateway in the local network usually does not allow clients to communicate with hosts in the Internet unless they provide valid authentication credentials. In this manner, the client encounters a chicken-and-egg problem where two resources are interdependent; the Internet connection is needed to contact the home KDC and for obtaining credentials, and on the other hand, the Internet connection is only granted for clients who have valid credentials. As a result, the Kerberos protocol cannot be used as it is for authenticating roaming clients requesting network access. Typically, a VPN approach is applied to solve this problem. However, we cannot always establish VPNs between different sites.
ローミングシナリオでは、クライアントは自宅KDCに連絡して、ローカル（または訪問した）領域のクロスリアルムTGTを取得する必要があります。ただし、ネットワークアクセスプロバイダーまたはローカルネットワークのゲートウェイのポリシーは、通常、有効な認証資格情報を提供しない限り、クライアントがインターネット内のホストと通信することを許可しません。このようにして、クライアントは、2つのリソースが相互依存している鶏と卵の問題に遭遇します。ホームKDCに連絡し、資格情報を取得するには、インターネット接続が必要であり、一方で、インターネット接続は有効な資格情報を持っているクライアントにのみ付与されます。その結果、ネットワークアクセスを要求するローミングクライアントを認証するためのKerberosプロトコルは使用できません。通常、この問題を解決するためにVPNアプローチが適用されます。ただし、さまざまなサイト間で常にVPNを確立することはできません。
Satisfying requirements R-3, R-4, and R-5 will eliminate (or considerably diminish) this roaming-related issue pertaining to Kerberos pre-authentication.
満足のいく要件R-3、R-4、およびR-5は、Kerberosの事前認証に関連するこのローミング関連の問題を排除（またはかなり減少させます）。
This document describes issues of Kerberos cross-realm operations. There are important matters to be considered when designing and implementing solutions for these issues. Such solutions must not introduce new problems. Any solution should use existing components or protocols as much as possible, and it should avoid introducing definitions of new components. It should not require new changes to existing deployed clients and as much as possible should not influence the client code-base. Because a KDC is a significant server in an information system based on Kerberos, any new burden placed on the KDC should be minimal. Solutions must take these tradeoffs and requirements into consideration. On the other hand, solutions are not required to solve all of the issues listed in this document at once.
このドキュメントでは、Kerberos Cross-Realm操作の問題について説明しています。これらの問題のソリューションを設計および実装する際には、考慮すべき重要な問題があります。このようなソリューションは、新しい問題を導入してはなりません。ソリューションは、既存のコンポーネントまたはプロトコルを可能な限り使用する必要があり、新しいコンポーネントの定義の導入を避ける必要があります。既存の展開されたクライアントに新しい変更を必要としないはずであり、可能な限りクライアントのコードベースに影響を与えてはなりません。KDCはKerberosに基づいた情報システムの重要なサーバーであるため、KDCに置かれた新しい負担は最小限である必要があります。ソリューションは、これらのトレードオフと要件を考慮する必要があります。一方、このドキュメントにリストされているすべての問題を一度に解決するためのソリューションは必要ありません。
This document clarifies the issues of the cross-realm operation of the Kerberos V system, which include security issues to be considered. See Sections 5.1, 5.2, 5.3, and 5.4 for further details.
この文書は、考慮すべきセキュリティの問題を含むKerberos Vシステムのクロスリアム操作の問題を明確にしています。詳細については、セクション5.1、5.2、5.3、および5.4を参照してください。
The authors are grateful to Nobuo Okabe, Kazunori Miyazawa, and Atsushi Inoue. They gave us lots of comments and suggestions for this document from its earliest stages. Nicolas Williams, Chaskiel Grundman, and Love Hornquist Astrand gave valuable suggestions and corrections. Thomas Hardjono devoted much work and helped to improve this document. Finally, the authors thank Jeffrey Hutzelman. He gave us a lot of suggestions for completion of this document.
著者は、岡田星、宮崎川、および井上島に感謝しています。彼らは、このドキュメントについて、その初期の段階から多くのコメントと提案をしてくれました。ニコラス・ウィリアムズ、シャスキエル・グルンドマン、そして愛のホーンキスト・アストランドは貴重な提案と修正を与えました。Thomas Hardjonoは多くの仕事を捧げ、この文書の改善に役立ちました。最後に、著者はJeffrey Hutzelmanに感謝します。彼はこの文書を完成させるために私たちに多くの提案をしてくれました。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。
[CSPC] "CSPC Nanhai - Shell Global Solutions", <http://www.shell.com/home/content/global_solutions/ aboutshell/key_projects/nanhai/>.
[cspc] "cspc nanhai -shell global solutions"、<http://www.shell.com/home/content/global_solutions/ aboutshell/key_projects/nanhai/>。
[KRBIMPL] "A Prototype of a Secure Autonomous Bootstrap Mechanism for Control Networks", Nobuo Okabe, Shoichi Sakane, Masahiro Ishiyama, Atsushi Inoue and Hiroshi Esaki, SAINT, pp. 56-62, IEEE Computer Society, 2006.
[Krbimpl]「制御ネットワークの安全な自動運転ブートストラップメカニズムのプロトタイプ」、岡部、sakane、shahiyama、sushi inoue、sushi saki、Saint、pp。56-62、IEEe Computer Society、2006。
[NAM] Nederlandse Aardolie Maatschappij BV, <http://www.nam.nl/>.
[nam] nederlandse aardolie maatschappij bv、<http://www.nam.nl/>。
[RNSS-H8] "H8 Family | Renesas Electronics", <http://www.renesas.com/products/mpumcu/h8/ h8_landing.jsp>.
[RNSS-H8] "H8ファミリー| Renesas Electronics"、<http://www.renesas.com/products/mpumcu/h8/ h8_landing.jsp>。
[RNSS-M16C] "M16C Family (R32C/M32C/M16C) | Renesas Electronics", <http://www.renesas.com/products/mpumcu/m16c/ m16c_landing.jsp>.
[RNSS-M16C] "M16Cファミリー（R32C/M32C/M16C）| Renesas Electronics"、<http://www.renesas.com/products/mpumcu/m16c/ m16c_landing.jsp>。
[SHELLCHEM] "Shell Chemicals", <http://www.shell.com/home/content/chemicals>.
[シェルチェム]「シェルケミカル」、<http://www.shell.com/home/content/chemicals>。
[SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C. Walstad, "Specifying Kerberos 5 Cross-Realm Authentication", Fifth Workshop on Issues in the Theory of Security, January 2005.
[Speccross] I. CervesatoathとA. JaggardおよびA. Scedrov and C. Walstad、「Kerberos 5 Cross-Realm認証の指定」、2005年1月、セキュリティ理論の問題に関する第5回ワークショップ。
Authors' Addresses
著者のアドレス
Shoichi Sakane Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi Tokyo 180-8750 Japan EMail: Shouichi.Sakane@jp.yokogawa.com
Shoichi Sakane Yokogawa Electric Corporation 2-9-32 Nakacho、Musashino-Shi Tokyo 180-8750日本メール：shouichi.sakane@jp.yokogawa.com
Ken'ichi Kamada Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi Tokyo 180-8750 Japan EMail: Ken-ichi.Kamada@jp.yokogawa.com
Ken'ichi kamadi Yokogawa Electric Corporation 2-9-32 Nakacho、Musashino-Shi Tokyo 180-8750日本メール：ken-ichi.kamada@jp.yokogawa.com
Saber Zrelli Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi Tokyo 180-8750 Japan EMail: Saber.Zrelli@jp.yokogawa.com
Saber Zrelli Yokogawa Electric Corporation 2-9-32 Nakacho、Musashino-Shi Tokyo 180-8750日本メール：saber.zrelli@jp.yokogawa.com
Masahiro Ishiyama Toshiba Corporation 1, Komukai Toshiba-cho, Saiwai-ku Kawasaki 212-8582 Japan EMail: masahiro@isl.rdc.toshiba.co.jp
石島石田田会社1、小谷小谷王子、聖川川崎212-8582日本メール：masahiro@isl.rdc.toshiba.co.c.jp