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
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.
本文档提供了有关工业部门大规模Kerberos部署的背景信息，旨在确定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批准的所有文件都适用于任何级别的互联网标准；见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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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身份验证协议是确保控制网络中通信的机密性和完整性，同时满足性能和安全要求的最佳替代方案之一。但是，在大型工业系统中使用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可以应用到的两个案例研究系统，并描述了这些系统中的七个需求（在管理和操作方面），这些需求概述了Kerberos操作可能受到的各种约束。最后，它列出了应用于这些系统时与Kerberos跨领域操作相关的六个问题。
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]).
本文档假设读者熟悉“Kerberos网络身份验证服务（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）和服务票。TGT周期性地从KDC获得，并且有一个有限的生命周期，在该生命周期结束后，它将过期，用户必须续订它。TGT用于获取另一种票据——服务票据。用户从身份验证服务（AS）获得TGT，AS是KDC的逻辑组件。获取TGT的过程称为“交换”。当用户发出对TGT的请求时，AS通过发送包含凭据的应答包进行响应，该应答包由TGT和称为“TGS会话密钥”的随机密钥组成。TGT包含使用与特殊服务（称为“TGS”（票证授予服务）相关联的密钥加密的信息。TGS会话密钥使用用户密钥进行加密，以便用户仅在知道与KDC共享的密钥时才能获得TGS会话密钥。然后使用TGT从TGS（KDC的第二个组件）获取服务票证。获取服务票的过程称为“TGS交换”。服务票证请求由包含TGT和“验证器”的数据包组成。验证器使用TGS会话密钥加密，并包含用户身份和时间戳（用于防止重播攻击）。在对从用户收到的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
Kerberos协议提供跨域身份验证功能。这允许用户获得服务票证以访问国外领域的服务。为了访问这些服务，用户首先联系他们的家庭KDC，请求使用TGT
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.
与国外的TGS合作。如果主域和外部域之间存在直接信任关系（实际上在共享的域间密钥中具体化），则主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，可以与可能与目标领域共享域间密钥的中间外部领域一起使用。客户端可以使用这个“中介TGT”与中介KDC通信，中介KDC将迭代主KDC执行的操作。如果中间KDC不与目标外部领域共享域间密钥，它会将用户指向另一个中间KDC（就像用户与其主KDC之间的第一次交换一样）。然而，在另一种情况下（当它与目标领域共享领域间密钥时），中介KDC将发出一个TGT，该TGT可与目标领域的KDC一起使用。在获得所需外部领域的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.
当领域属于同一机构时，客户机或KDC可以通过遵循DNS域层次结构并假设父域与其所有子域共享密钥来自动确定信任链。但是，由于这种假设并不总是正确的，因此在许多情况下，可能必须手动指定信任路径。由于使用间接域间信任模型的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.
为了帮助读者理解跨领域身份验证操作的要求和限制，本节描述了跨领域Kerberos支持的两个实际系统的规模和操作。这两个系统最自然的实现方式是使用不同的信任模型，这意味着对跨领域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.
此后，我们将考虑一个实际的石化公司[SHIELCHM ]，并概述其植物中的两个例子。石化公司生产大宗石化产品，并将其交付给大型工业客户。考虑中的公司在全球拥有43家工厂，由35个国家的运营点管理。本节展示了这些工厂的两个示例。
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）和壳牌石油化工有限公司，由这两家公司的合资企业运营。该系统是世界上最大的同类系统之一。它位于中国东南部广东大亚湾北岸，面积3.4平方公里。系统中部署了3000个网段，16000个控制设备连接到局域网。这些设备属于9个不同的子系统。一个控制装置可以有许多控制和监控点。在本例中考虑的工厂中，总共有200000个控制点。它们由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]。荷兰Aardolie Maatschapij（NAM）由代表该石油公司的两家企业组成的合伙公司运营。该系统由分布在荷兰北部863平方公里范围内的一些植物组成。该地区分布着26种植物，每一种都被称为“集群”。它们通过专用ATM WAN相互连接。每个集群大约有500-1000个控制设备。这些设备由每个集群中的本地控制中心管理。在不结盟运动的整个系统中，有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的低带宽。终端设备使用低时钟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跨领域操作基础的框架和体系结构进行处理。这些需求的目的是为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由于组织原因和可伸缩性需要，一个管理域通常必须划分为两个或多个管理子域。因此，Kerberos跨领域问题的任何体系结构和实现解决方案都必须（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 Kerberos跨领域问题的任何体系结构和实现解决方案都必须支持在同一网络上同时存在多个独立的管理域。此外，它必须允许组织（对应于不同的管理域）在任何时候委托管理其系统的一部分或全部。
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跨领域问题的任何架构和实现解决方案都必须允许一个设备操作控制另一个设备，但每个设备分别属于不同的管理域。
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跨领域问题的任何体系结构和实现解决方案都必须解决管理域跨越地理边界和网络拓扑边界的基本部署用例。特别是，它必须解决设备在地理（或拓扑）上是远程的情况，即使它们属于同一管理域。
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 Kerberos跨领域问题的任何体系结构和实现解决方案都必须解决设备的（有限的）处理能力，解决方案的实现必须考虑限制或抑制此类设备的功耗。
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跨领域问题的任何体系结构和实现解决方案都必须解决一个域内以及跨域的设备之间通信带宽可用性有限的可能性。
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
身份验证路径中的每个KDC都知道客户端和身份验证路径中其余KDC之间的共享秘密。这使得恶意KDC能够对客户端与剩余KDC之间的通信执行中间人（MITM）攻击
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还可能学习用于保护客户端和实际应用程序服务之间通信的服务会话密钥。然后，它可以使用此密钥执行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中允许跨领域操作时所做的一个假设是，用户可以与位于远程领域中的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交换需要加密操作，并且可能会消耗大量的处理时间，特别是当客户端的计算能力有限时。因此，Kerberos跨域交换的开销可能会导致无法接受的处理延迟。
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 MHz）实现了Kerberos客户端，并测量了每个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.
在漫游场景中，客户端需要联系其家庭KDC以获取本地（或访问的）域的跨域TGT。但是，本地网络中的网络访问提供商或网关的策略通常不允许客户端与Internet中的主机通信，除非它们提供有效的身份验证凭据。在这种情况下，客户会遇到两种资源相互依赖的鸡和蛋问题；需要Internet连接来联系家庭KDC并获取凭据，另一方面，Internet连接仅授予具有有效凭据的客户端。因此，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.
本文档澄清了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.
作者感谢冈部信夫、宫泽和诺里和井上聪。他们从文件的最初阶段就给了我们很多意见和建议。Nicolas Williams、Chaskiel Grundman和Love Hornquist Astrand给出了宝贵的建议和更正。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，“Kerberos网络身份验证服务（V5）”，RFC41202005年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/ 关于壳牌/重点项目/南海/>。
[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]“用于控制网络的安全自主引导机制的原型”，冈部信夫、坂根昭一、石山正彦、井上春树和以崎广史，圣人，第56-62页，IEEE计算机学会，2006年。
[NAM] Nederlandse Aardolie Maatschappij BV, <http://www.nam.nl/>.
[NAM]荷兰Aardolie Maatschapij有限公司<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>.
[壳牌化学]“壳牌化学”<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
昭一坂根横河电气公司2-9-32中町，武藏市东京180-8750日本电子邮件：寿一。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
日本武藏野市中町2-9-32-180-8750日本横川电机株式会社Kamada Ken'ichi Yokogawa Electric Corporation电子邮件：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，武藏县中町市，东京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号，日本川崎市西围区Komukai Toshiba cho 212-8582电子邮件：masahiro@isl.rdc.toshiba.co.jp