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
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の展開に関する背景情報を提供します。
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クロスレルムオペレーションの問題にも適用可能です。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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認証をサポートしています。これは、クロスレルム認証と呼ばれています。
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クロスレルムオペレーションを使用する場合、いくつかの問題が生じます。
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レルムの事業に関連する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レルムの事業に関連するすべての問題を記述しない場合がありますので注意してください。新しい問題は、将来的に発見される可能性があります。また、この文書で説明する問題への解決策を提案していません。さらに、本書の出版は、問題のそれぞれは、IETFメンバーによって解決されなければならないことを意味するものではありません。詳細な問題の分析、問題の定義、および可能な解決策の探求は、別々の作業項目として実施することができます。
This document assumes that the readers are familiar with the terms and concepts described in "The Kerberos Network Authentication Service (V5)" ([RFC4120]).
この文書は、読者が「ケルベロスネットワーク認証サービス（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.
ケルベロス[RFC4120]は広く配備認証システムです。ケルベロスにおける認証プロセスは、プリンシパルとキー配布センター（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はチケットの他の種類を取得するために使用されます。ユーザは、認証サービス（AS）、KDCの論理コンポーネントからTGTを取得します。 TGTを取得するプロセスは、「為替AS」と呼ばれています。 TGTの要求がユーザーによって発行されると、ASは「TGSセッションキー」と呼ばれるランダムなキーと一緒にTGTで構成された資格情報を含む応答パケットを送信して応答します。 TGTは、「TGS」（チケット認可サービス）と呼ばれる特別なサービス、関連付けられた秘密鍵を使って暗号化された情報が含まれています。 TGSセッションキーは、彼女は彼女がKDCと共有する秘密鍵を知っている場合にのみ、ユーザーはTGSセッションキーを取得することができるように、ユーザーのキーを使用して暗号化されています。 KDCの第二の成分 - TGTは、次にTGSからサービスチケットを取得するために使用されます。サービスチケットを取得するプロセスは、「TGS交換」と呼ばれています。サービスチケットの要求はTGTと「認証」を含むパケットで構成されています。オーセンティケータは、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プロトコルは、クロスレルム認証機能を提供します。これにより、ユーザーは、外国のレルム内のサービスにアクセスするためのサービスチケットを入手することができます。このようなサービスにアクセスするためには、ユーザーが最初の外国領域の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.
ホーム領域は、外国レルムにレルム間のキーを共有しない場合は、我々は、いわゆる間接的な信頼モデルの状況にあります。このような状況では、自宅のKDCは、ターゲット・レルムにレルム間のキーを共有する可能性がある仲介外国レルムで使用可能なTGTを提供します。クライアントは、ホームKDCが実行したアクションを繰り返すだろう仲介KDCと通信するために、この「仲介TGT」を使用することができます。仲介KDCは、ターゲット外国レルムにレルム間のキーを共有しない場合は、それが（ちょうどユーザーと彼女の家KDCとの最初の交換のように）別の仲介KDCにユーザーを指します。しかし、他のケース（それが目的のレルムにレルム間キーを共有する場合）には、仲介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レルムの操作が仲介王国に依存しているので、クロスレルムオペレーションの成功は、完全に認証パスの一部である王国に依存します。
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つのシステムは、最も自然レルムの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]を展開する植物です。また、中国海洋石油総公司（CNOOC）とシェル石油化学会社と呼ばCSPCは、これら2社の共同事業によって運営されています。このシステムは、世界でそのタイプの最大の一つです。これは、中国南東部で、大亜湾、広東省の北海岸で3.4平方キロメートルのエリアに位置しています。 3,000ネットワークセグメントは、システムに配備され、16,000の制御装置は、ローカルエリアネットワークに接続されています。これらのデバイスは、9種類のサブシステムに属しています。制御装置は、多くの制御と監視ポイントを有することができます。この例において考慮プラントにおいて、全20万個の制御点があります。彼らは、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 WANによって相互に接続されています。各クラスタは約500〜1,000の制御デバイスを持っています。これらのデバイスは、各クラスタ内のローカルコントロールセンターで管理されています。 NAMのシステム全体では、百万制御点があります。
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の低帯域幅で、ツイストペアケーブルによってローカルネットワークに接続されています。例えば、H8 [RNSS-H8]とM16C [RNSS-M16C] - エンドデバイスは、低クロックCPUを使用します。また、消費電力を低減するために、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クロスレルムオペレーションの基礎となるフレームワークとアーキテクチャに向けて対処しています。これらの要件の目的は、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つ以上のサブドメインに分割されなければなりません。したがって、ケルベロスレルムの問題へのアーキテクチャおよび実装溶液は、（i）は、別の管理ドメインに一つの管理ドメインの管理権限の複数の管理ドメイン間のクロスレルムオペレーションの場合と（ii）のサポートの委任をサポートしなければなりません。これは、これらのクロスレルムオペレーションのセキュリティレベルや品質の低下なしに行われなければならないと攻撃の新しいタイプに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の任意のアーキテクチャおよび実装ソリューションは、同じネットワーク上の複数の独立した管理ドメインの共存をサポートしなければなりません。さらに、（異なる管理ドメインに対応する）組織が任意の時点での一部、または全体、それらのシステムの管理を委任することができなければなりません。
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の任意のアーキテクチャおよび実装ソリューションは、1つのデバイスが動作上の別のデバイスを制御する際に使用するケースを許可する必要があり、それぞれが、それぞれ、異なる管理ドメインに属しています。
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ケルベロスレルム問題に対するいかなるアーキテクチャおよび実装ソリューションは、管理ドメインは、地理的な境界とネットワークトポロジーの境界を横断した基本的な展開ユースケースに対処しなければなりません。特に、それらが同じ管理ドメインに属していても、デバイスがリモート地理的に（または位相幾何学）の場合に対処する必要があります。
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レルムの問題への任意のアーキテクチャと実装ソリューションは、可能な限り運用・管理コストの削減を目的としなければなりません。
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ケルベロスレルム問題に対するいかなるアーキテクチャ及び実装溶液（限定）処理装置の機能、ソリューションの実装に対処する必要があり、そのようなデバイスの電力消費を制限または抑制することを目指して検討しなければなりません。
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の任意のアーキテクチャおよび実装溶液を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に記載されるもののような大規模システムで使用される場合のKerberosクロスレルムオペレーションに問題の一覧を示し、そして考慮セクション4で説明した要件をとります。
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はのman-in-the-middle（MITM）クライアントと残りの認証チェーン内のKDCとの間の通信への攻撃を行うことができます。悪質な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.
ケルベロスにクロスレルムオペレーションを可能にする場合の仮定の一つは、ユーザーが遠隔レルムに位置の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のクロスレルムオペレーションでは、クライアントは、ホームKDCとターゲットKDCなどの信頼パスでのKDCのすべてとTGS交換を実行する必要があります。 TGS交換は、クライアントが計算能力が制限されている場合は特に、暗号化操作を必要とし、処理時間を大量に消費する可能性があります。結果として、ケルベロスレルム交換のオーバーヘッドは、処理中に許容できない遅延を引き起こす可能性があります。
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ライブラリ（バージョン1.2.4）を移植H8（16ビット、20メガヘルツ）と独自ボード上のKerberosクライアントを実装し、各ケルベロスメッセージ[KRBIMPL]の処理時間を測定しました。これは、オンボードH / W暗号化エンジンとの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.
シナリオをローミングでは、クライアントは、ローカル（または訪問）レルムのレルムTGTを取得するために彼女の家KDCに連絡する必要があります。しかし、ネットワーク・アクセス・プロバイダのポリシーまたはローカルネットワーク内のゲートウェイは通常、彼らが有効な認証資格情報を提供しない限り、クライアントはインターネットでのホストと通信することはできません。このように、クライアントは、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クロスレルムオペレーションの問題について説明します。設計およびこれらの問題のためのソリューションを実装する際に考慮すべき重要な事項があります。このようなソリューションは、新たな問題を導入してはなりません。すべてのソリューションは、可能な限り既存のコンポーネントやプロトコルを使用する必要があり、それは新しいコンポーネントの定義を導入することは避けてください。これは、クライアントのコードベースに影響を与えるべきではない、新たな既存の展開クライアントに変更し、可能な限り必要はありません。 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.
この文書では、考慮すべきセキュリティ上の問題を含んでケルベロス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.
著者は信夫岡部、和則宮澤篤井上に感謝しています。彼らは私たちにその初期段階からこの文書に関するコメントや提案の多くを与えました。ニコラス・ウィリアムズ、Chaskiel Grundman、そして愛Hornquist Astrandは貴重な提案や修正を行いました。トーマスHardjonoは、多くの仕事を捧げ、この文書を改善するのに役立ちました。最後に、著者はジェフリーHutzelmanに感謝します。彼は私たちに、この文書の完成のための提案の多くを与えました。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]ノイマン、C.、ゆう、T.、ハルトマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（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南海 - シェルグローバルソリューションズ"、<http://www.shell.com/home/content/global_solutions/ aboutshell / key_projects /南海/>。
[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]、信夫岡部、正一坂根正弘石山、井上淳と江崎浩、SAINT、PP。56-62、IEEEコンピュータ学会、2006年「制御ネットワークのためのセキュアな自律ブートストラップ機構のプロトタイプ」。
[NAM] Nederlandse Aardolie Maatschappij BV, <http://www.nam.nl/>.
[NAM]オランダの石油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ファミリ|ルネサスエレクトロニクス"、<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）|ルネサスエレクトロニクス"、<http://www.renesas.com/products/mpumcu/m16c/ m16c_landing.jsp>。
[SHELLCHEM] "Shell Chemicals", <http://www.shell.com/home/content/chemicals>.
【SHELLCHEM "シェルケミカルズ"、<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. CervesatoとA. JaggardとA. ScedrovとC. Walstad、「指定のKerberos 5レルム間認証」、セキュリティ、2005年1月の理論における問題に関する第五ワークショップ。
Authors' Addresses
著者のアドレス
Shoichi Sakane Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi Tokyo 180-8750 Japan EMail: 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
けんいち かまだ よこがわ えぇｃｔりｃ こｒぽらちおん ２ー９ー３２ なかちょ、 むさしのーし ときょ １８０ー８７５０ じゃぱん えまいｌ： けんーいち。かまだ＠ｊｐ。よこがわ。こｍ
Saber Zrelli Yokogawa Electric Corporation 2-9-32 Nakacho, Musashino-shi Tokyo 180-8750 Japan EMail: 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
まさひろ いしやま としば こｒぽらちおん １、 こむかい としばーちょ、 さいわいーく かわさき ２１２ー８５８２ じゃぱん えまいｌ： まさひろ＠いｓｌ。ｒｄｃ。としば。こ。ｊｐ