[要約] RFC 6806は、Kerberosプリンシパル名の正規化とクロスレルムのリファラルに関する仕様です。目的は、Kerberos認証システムのセキュリティと相互運用性を向上させることです。
Internet Engineering Task Force (IETF) S. Hartman, Ed.
Request for Comments: 6806 Painless Security
Updates: 4120 K. Raeburn
Category: Standards Track MIT
ISSN: 2070-1721 L. Zhu
Microsoft Corporation
November 2012
Kerberos Principal Name Canonicalization and Cross-Realm Referrals
Kerberosプリンシパル名の正規化とレルム間の紹介
Abstract
概要
This memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm Ticket-Granting Ticket (TGT) to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120.
このメモは、クライアントがユーザーまたはサービスのレルムに関する詳細な構成情報を持っていない場合に、Kerberos鍵配布センター（KDC）がKerberosチケットのクライアント要求に応答する方法を説明しています。 KDCは、紹介エラーまたはクロスレルムチケット許可チケット（TGT）を紹介パス上の別のレルムに返すことにより、他のレルムのプリンシパルの要求を処理します。クライアントはこの紹介情報を使用して、ターゲットプリンシパルのレルムに到達し、チケットを受け取ります。このメモは、要求が転送中に改ざんされていないことを確認するためのメカニズムも提供します。このメモはRFC 4120を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6806.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6806で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4
4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5
4.1. Trust Assumptions . . . . . . . . . . . . . . . . . . . . 5
5. Enterprise Principal Name Type . . . . . . . . . . . . . . . . 6
6. Name Canonicalization . . . . . . . . . . . . . . . . . . . . 7
7. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 9
8. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 10
9. Cross-Realm Routing . . . . . . . . . . . . . . . . . . . . . 11
10. Caching Information . . . . . . . . . . . . . . . . . . . . . 11
11. Negotiation of FAST and Detecting Modified Requests . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13.1. Shared-Password Case . . . . . . . . . . . . . . . . . . . 16
13.2. Pre-Authentication Data . . . . . . . . . . . . . . . . . 16
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
15.1. Normative References . . . . . . . . . . . . . . . . . . . 17
15.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Compatibility with Earlier Implementations of
Name Canonicalization . . . . . . . . . . . . . . . . 18
Current implementations of the Kerberos Authentication Service (AS) and Ticket-Granting Service (TGS) protocols, as defined in [RFC4120], use principal names constructed from a known user or service name and realm. A service name is typically constructed from a name of the service and the DNS host name of the computer that is providing the service. Many existing deployments of Kerberos use a single Kerberos realm where all users and services would be using the same realm. However, in an environment where there are multiple Kerberos realms, the client needs to be able to determine what realm a particular user or service is in before making an AS or TGS request. Traditionally, this requires client configuration to make this possible.
Kerberos認証サービス（AS）およびチケット許可サービス（TGS）プロトコルの現在の実装は、[RFC4120]で定義されているように、既知のユーザーまたはサービス名とレルムから構築されたプリンシパル名を使用します。サービス名は通常、サービスの名前と、サービスを提供しているコンピューターのDNSホスト名から構成されます。既存のKerberosの多くのデプロイメントでは、すべてのユーザーとサービスが同じレルムを使用する単一のKerberosレルムを使用しています。ただし、複数のKerberosレルムがある環境では、クライアントは、ASまたはTGS要求を行う前に、特定のユーザーまたはサービスがどのレルムにあるかを判別できる必要があります。従来、これを可能にするには、クライアント構成が必要です。
When having to deal with multiple realms, users are forced to know what realm they are in before they can obtain a Ticket-Granting Ticket (TGT) with an AS request. However, in many cases, the user would like to use a more familiar name that is not directly related to the realm of their Kerberos principal name. A good example of this is an email name in the style described in [RFC5322]. This document describes a mechanism that would allow a user to specify a user principal name that is an alias for the user's Kerberos principal name. In practice, this would be the name that the user specifies to obtain a TGT from a Kerberos KDC. The user principal name no longer has a direct relationship with the Kerberos principal or realm. Thus, the administrator is able to move the user's principal to other realms without the user having to know that it happened.
複数のレルムを処理する必要がある場合、ユーザーはAS要求でチケット許可チケット（TGT）を取得する前に、自分がどのレルムにいるかを知る必要があります。ただし、多くの場合、ユーザーは自分のKerberosプリンシパル名の領域に直接関連しない、より馴染みのある名前を使用したいと考えています。この良い例は、[RFC5322]で説明されているスタイルの電子メール名です。このドキュメントでは、ユーザーがユーザーのKerberosプリンシパル名のエイリアスであるユーザープリンシパル名を指定できるようにするメカニズムについて説明します。実際には、これは、Kerberos KDCからTGTを取得するためにユーザーが指定する名前になります。ユーザープリンシパル名は、Kerberosプリンシパルまたはレルムと直接の関係がなくなりました。したがって、管理者は、ユーザーがそのことを知らなくても、ユーザーのプリンシパルを他のレルムに移動できます。
Once a TGT has been obtained, the user would like to be able to access services in any Kerberos realm for which there is an authentication path from the realm of their principal. To do this requires that the client be able to determine what realm the target service principal is in before making the TGS request. Current implementations of Kerberos typically have a table that maps DNS host names to corresponding Kerberos realms. The user-supplied host name or its domain component is looked up in this table (often using the result of some form of host name lookup performed with insecure DNS queries, in violation of [RFC4120]). The corresponding realm is then used to complete the target service principal name. Even if insecure DNS queries were not used, managing this table is problematic.
TGTが取得されると、ユーザーは、プリンシパルのレルムからの認証パスが存在するKerberosレルムのサービスにアクセスできるようになります。これを行うには、TGS要求を行う前に、クライアントがターゲットサービスプリンシパルがどのレルムにあるかを判別できる必要があります。 Kerberosの現在の実装には、通常、DNSホスト名を対応するKerberosレルムにマップするテーブルがあります。ユーザーが指定したホスト名またはそのドメインコンポーネントがこのテーブルで検索されます（多くの場合、[RFC4120]に違反して、安全でないDNSクエリで実行されたホスト名検索の結果を使用します）。次に、対応するレルムを使用して、ターゲットサービスプリンシパル名を完成させます。安全でないDNSクエリが使用されなかった場合でも、このテーブルの管理には問題があります。
This traditional mechanism requires that each client have very detailed configuration information about the hosts that are providing services and their corresponding realms. Having client-side configuration information can be very costly from an administration point of view -- especially if there are many realms and computers in the environment.
この従来のメカニズムでは、各クライアントが、サービスを提供しているホストとそれに対応するレルムに関する非常に詳細な構成情報を持っている必要があります。クライアント側の構成情報があると、管理の観点から非常にコストがかかる可能性があります（特に、環境に多くのレルムとコンピューターがある場合）。
This memo proposes a solution for these problems and simplifies administration by minimizing the configuration information needed on each computer using Kerberos. Specifically, it describes a mechanism to allow the KDC to handle canonicalization of names, provide for principal aliases for users and services, and allow the KDC to determine the trusted realm authentication path by being able to generate referrals to other realms in order to locate principals.
このメモは、これらの問題の解決策を提案し、Kerberosを使用して各コンピューターで必要な構成情報を最小限に抑えることで管理を簡素化します。具体的には、KDCが名前の正規化を処理し、ユーザーとサービスにプリンシパルエイリアスを提供し、プリンシパルを見つけるために他のレルムへの参照を生成できるようにすることで、KDCが信頼されたレルム認証パスを決定できるようにするメカニズムについて説明します。
Two kinds of KDC referrals are introduced in this memo:
このメモでは、2種類のKDC紹介が紹介されています。
1. Client referrals, in which the client doesn't know which realm contains a user account.
1. クライアントの紹介。クライアントは、どのレルムにユーザーアカウントが含まれているかを認識していません。
2. Server referrals, in which the client doesn't know which realm contains a server account.
2. サーバー紹介。クライアントは、どのレルムにサーバーアカウントが含まれているかを認識していません。
These two types of referrals introduce new opportunities for an attacker. In order to avoid these attacks, a mechanism is provided to protect the integrity of the request between the client and KDC. This mechanism complements the Flexible Authentication Secure Tunnels (FAST) facility provided in [RFC6113]. A mechanism is provided to negotiate the availability of FAST. Among other benefits, this can be used to protect errors generated by the referral process.
これらの2種類の参照は、攻撃者に新しい機会をもたらします。これらの攻撃を回避するために、クライアントとKDC間の要求の整合性を保護するメカニズムが提供されています。このメカニズムは、[RFC6113]で提供されるフレキシブル認証セキュアトンネル（FAST）機能を補完します。 FASTの可用性を交渉するメカニズムが提供されます。他の利点の中でも、これは紹介プロセスによって生成されたエラーを保護するために使用できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In order to request referrals as defined in later sections, the Kerberos client MUST explicitly request the "canonicalize" KDC option (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to the KDC that the client is prepared to receive a reply that contains a principal name other than the one requested.
後のセクションで定義されているように紹介を要求するために、KerberosクライアントはAS-REQまたはTGS-REQの「正規化」KDCオプション（ビット15）[RFC4120]を明示的に要求する必要があります。このフラグは、クライアントが要求されたプリンシパル名以外のプリンシパル名を含む応答を受信する準備ができていることをKDCに示します。
KDCOptions ::= KerberosFlags
-- canonicalize (15)
-- other KDCOptions values omitted
When sending names with the "canonicalize" KDC option, the client should expect that names in the KDC's reply MAY be different than the name in the request. A referral TGT is a cross-realm TGT that is returned with the server name of the ticket being different from the server name in the request [RFC4120].
「canonicalize」KDCオプションを使用して名前を送信する場合、クライアントは、KDCの応答内の名前が要求内の名前と異なる場合があることを期待する必要があります。紹介TGTは、要求のサーバー名とは異なるチケットのサーバー名が返されるクロスレルムTGTです[RFC4120]。
This memo assumes that the world of principals is arranged on multiple levels: the realm, the enterprise, and the world. A KDC may issue tickets for any principal in its realm or cross-realm tickets for realms with which it has a direct cross-realm relationship. The KDC also has access to a trusted name service that can resolve any name from within its enterprise into a realm closer along the authentication path to the service. This trusted name service removes the need to use an untrusted DNS lookup for name resolution.
このメモは、プリンシパルの世界が複数のレベル（レルム、企業、世界）に配置されていることを前提としています。 KDCは、レルム内の任意のプリンシパルのチケット、またはレルム間の直接のレルム間関係を持つレルムのクロスレルムチケットを発行できます。 KDCは、企業内からサービスへの認証パスに近いレルムに任意の名前を解決できる信頼できるネームサービスにもアクセスできます。この信頼できるネームサービスにより、名前解決に信頼できないDNSルックアップを使用する必要がなくなります。
For example, consider the following configuration, where lines indicate cross-realm relationships:
たとえば、線がレルム間の関係を示す次の構成を考えます。
EXAMPLE.COM
/ \
/ \
ADMIN.EXAMPLE.COM DEV.EXAMPLE.COM
In this configuration, all users in the EXAMPLE.COM enterprise could have principal names, such as alice@EXAMPLE.COM, with the same realm portion. In addition, servers at EXAMPLE.COM should be able to have DNS host names from any DNS domain independent of what Kerberos realm their principals reside in.
この構成では、EXAMPLE.COMエンタープライズのすべてのユーザーが、同じレルム部分を持つalice@EXAMPLE.COMなどのプリンシパル名を持つことができます。さらに、EXAMPLE.COMのサーバーは、プリンシパルが存在するKerberosレルムに関係なく、任意のDNSドメインからのDNSホスト名を持つことができる必要があります。
Two realms participate in any cross-realm relationship: an issuing realm issues a cross-realm ticket, and a consuming realm uses this ticket. There is a degree of trust of the issuing realm by the consuming realm implied by this relationship. Whenever a service in the consuming realm permits an authentication path containing the issuing realm, that service trusts the issuing realm to accurately represent the identity of the authenticated principal and any information about the transited path. If the consuming realm's KDC sets the transited policy checked flag, the KDC is making the same trust assumption that a service would.
2つのレルムがレルム間の関係に参加します。発行レルムがレルム間チケットを発行し、消費レルムがこのチケットを使用します。この関係によって暗示される消費レルムによる発行レルムのある程度の信頼があります。消費側レルムのサービスが発行元レルムを含む認証パスを許可すると、そのサービスは発行元レルムを信頼して、認証されたプリンシパルのIDと通過パスに関する情報を正確に表します。消費側レルムのKDCが通過ポリシーチェック済みフラグを設定する場合、KDCはサービスと同じ信頼性を想定しています。
This trust is transitive across a multi-hop authentication path. The service's realm trusts each hop along the authentication path closer to the client to accurately represent the authenticated identity and to accurately represent transited information. Any KDC along this path could impersonate the client.
この信頼は、マルチホップ認証パス全体で推移的です。サービスのレルムは、クライアントに近い認証パスに沿った各ホップを信頼して、認証されたIDを正確に表し、転送された情報を正確に表します。このパスに沿ったすべてのKDCがクライアントを偽装する可能性があります。
KDC-signed or -issued authorization data often implies additional trust. The implications of such trust from a security and operational standpoint is an ongoing topic of discussion during the development of this specification. As such, such discussion is out of scope for this memo.
KDCが署名または発行した承認データは、追加の信頼を意味します。セキュリティと運用の観点からのこのような信頼の影響は、この仕様の開発中に継続的に議論されるトピックです。したがって、そのような議論はこのメモの範囲外です。
Administrators have several tools to limit trust caused by cross-realm relationships. A service or KDC can control what authentication paths are acceptable. For example, if a given realm is not permitted on the authentication path for a particular client, then that realm cannot affect trust placed in that client principal. Consuming realms can exercise significant control by deciding what principals to place on an access-control list. If no client using a given issuing realm in authentication paths is permitted to access a resource, then that issuing realm is not trusted in access decisions regarding that resource.
管理者には、レルム間の関係によって引き起こされる信頼を制限するためのいくつかのツールがあります。サービスまたはKDCは、許容される認証パスを制御できます。たとえば、特定のレルムが特定のクライアントの認証パスで許可されていない場合、そのレルムはそのクライアントプリンシパルに設定された信頼に影響を与えることができません。レルムを使用すると、アクセス制御リストに配置するプリンシパルを決定することにより、重要な制御を行うことができます。認証パスで特定の発行レルムを使用しているクライアントがリソースへのアクセスを許可されていない場合、その発行レルムはそのリソースに関するアクセス決定では信頼されません。
Creating a cross-realm relationship implies relatively little inherent trust in the issuing realm. Significant trust only applies as principals dependent on that issuing realm are given access to resources. However, two deployment characteristics may increase the trust implied by the initial cross-realm relationship. First, a number of realms provide access to any principal to some resources. Access decisions involving these resources involve a degree of trust in all issuing realms in the transited graph. Secondly, many realms do not constrain the set of principals to which users of that realm may grant access. In these realms, creating a cross-realm relationship delegates the decision to trust that realm to users of the consuming realm. In this situation, creating the cross-realm relationship is the primary trust decision point under the administrator's control.
レルム間の関係を作成することは、発行元のレルムに対する固有の信頼が比較的少ないことを意味します。重要な信頼は、発行元のレルムに依存するプリンシパルにリソースへのアクセス権が与えられるときにのみ適用されます。ただし、2つの展開特性により、最初の領域間の関係が意味する信頼が高まる場合があります。まず、いくつかのレルムは、いくつかのリソースへのプリンシパルへのアクセスを提供します。これらのリソースに関連するアクセス決定には、遷移グラフ内のすべての発行元レルムに対するある程度の信頼が含まれます。次に、多くのレルムは、そのレルムのユーザーがアクセスを許可するプリンシパルのセットを制約しません。これらのレルムでは、レルム間の関係を作成すると、消費するレルムのユーザーにそのレルムを信頼するという決定が委任されます。この状況では、レルム間の関係を作成することが、管理者の制御下にある主要な信頼決定ポイントです。
The NT-ENTERPRISE type principal name contains one component, a string of realm-defined content, which is intended to be used as an alias for another principal name in some realm in the enterprise. It is used for conveying the alias name, not for the real principal names within the realms, and thus is only useful when name canonicalization is requested.
NT-ENTERPRISEタイプのプリンシパル名には、1つのコンポーネント、レルム定義コンテンツの文字列が含まれています。これは、企業内のいくつかのレルムで別のプリンシパル名のエイリアスとして使用することを目的としています。これは、レルム内の実際のプリンシパル名ではなく、エイリアス名の伝達に使用されるため、名前の正規化が要求された場合にのみ役立ちます。
The intent is to allow unification of email and security principal names. For example, all users at EXAMPLE.COM may have a client principal name of the form "joe@EXAMPLE.COM", even though the principals are contained in multiple realms. This global name is again an alias for the true client principal name, which indicates what realm contains the principal. Thus, accounts "alice" in the realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM".
その目的は、電子メールとセキュリティプリンシパル名の統合を可能にすることです。たとえば、プリンシパルが複数のレルムに含まれている場合でも、EXAMPLE.COMのすべてのユーザーが "joe@EXAMPLE.COM"という形式のクライアントプリンシパル名を持っている可能性があります。このグローバル名は、本当のクライアントプリンシパル名のエイリアスでもあります。これは、プリンシパルが含まれているレルムを示します。したがって、レルムDEV.EXAMPLE.COMのアカウント「alice」およびADMIN.EXAMPLE.COMの「bob」は、「alice@EXAMPLE.COM」および「bob@EXAMPLE.COM」としてログオンする場合があります。
This utilizes a new principal name type, as the KDC-REQ message only contains a single client realm (crealm) field, and the realm portion of this name corresponds to the Kerberos realm with which the request is made. Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a single component in the client name field of the AS-REQ message, with a name type of NT-ENTERPRISE [RFC4120] (and the local realm name). The KDC will recognize this name type and then transform the requested name into the true principal name if the client account resides in the local realm. The true principal name can have a name type different from the requested name type. Typically, the true principal name will be an NT-PRINCIPAL [RFC4120].
これは新しいプリンシパル名タイプを利用します。これは、KDC-REQメッセージに含まれるクライアントレルム（crealm）フィールドが1つだけであり、この名前のレルム部分が、要求が行われたKerberosレルムに対応しているためです。したがって、名前全体「alice@EXAMPLE.COM」は、名前タイプNT-ENTERPRISE [RFC4120]（およびローカルレルム名）を使用して、AS-REQメッセージのクライアント名フィールドの単一コンポーネントとして送信されます。 KDCはこの名前タイプを認識し、クライアントアカウントがローカルレルムにある場合、要求された名前を実際のプリンシパル名に変換します。真のプリンシパル名は、要求された名前タイプとは異なる名前タイプを持つことができます。通常、真のプリンシパル名はNT-PRINCIPAL [RFC4120]です。
A service or account may have multiple principal names. For example, if a host is known by multiple names, host-based services on it may be known by multiple names in order to prevent the client from needing a secure directory service to determine the correct host name to use. In order to avoid the need to update the host whenever a new alias is created, the KDC may provide the mapping information to the client in the credential acquisition process.
サービスまたはアカウントには、複数のプリンシパル名がある場合があります。たとえば、ホストが複数の名前で認識されている場合、クライアントが安全なディレクトリサービスを使用して正しいホスト名を決定する必要がないように、ホスト上のホストベースのサービスが複数の名前で認識される場合があります。新しいエイリアスが作成されるたびにホストを更新する必要を回避するために、KDCは資格情報取得プロセスでクライアントにマッピング情報を提供する場合があります。
If the "canonicalize" KDC option is set, then the KDC MAY change the client and server principal names and types in the AS response and ticket returned from those in the request. Names MUST NOT be changed in the response to a TGS request, although it is common for KDCs to maintain a set of aliases for service principals. Regardless of which alias a client requests, the same service key is used. However, in the TGS request, the client receives a ticket for the alias requested. Services MUST NOT make distinctions based on which alias is in the issued ticket, because the service name in a ticket is not cryptographically protected and can be changed by parties other than the KDC.
「canonicalize」KDCオプションが設定されている場合、KDCは、AS応答のクライアントとサーバーのプリンシパル名とタイプ、およびリクエストのそれらから返されたチケットを変更できます（MAY）。 KDCがサービスプリンシパルのエイリアスのセットを維持することは一般的ですが、TGS要求への応答で名前を変更してはなりません（MUST NOT）。クライアントが要求するエイリアスに関係なく、同じサービスキーが使用されます。ただし、TGS要求では、クライアントは要求されたエイリアスのチケットを受け取ります。チケット内のサービス名は暗号で保護されておらず、KDC以外の当事者によって変更される可能性があるため、サービスは、発行されたチケットに含まれるエイリアスに基づいて区別してはなりません。
For example, the AS request may specify a client name of "bob@ EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC option set, and the KDC will return with a client name of "104567" as an NT-UID [RFC4120].
たとえば、ASリクエストでは、「canbicalize」KDCオプションが設定されたNT-ENTERPRISE名として「bob@EXAMPLE.COM」のクライアント名を指定でき、KDCはNTとして「104567」のクライアント名を返します。 -UID [RFC4120]。
(It is assumed that the client discovers whether the KDC supports the NT-ENTERPRISE name type via out-of-band mechanisms.)
（クライアントは、KDCが帯域外メカニズムを介してNT-ENTERPRISE名タイプをサポートしているかどうかを検出すると想定されています。）
See Section 11 for a mechanism to detect modification of the request between the client and KDC. However, for the best protection, Flexible Authentication Secure Tunneling (FAST) [RFC6113] or another mechanism that protects the entire KDC exchange SHOULD be used. Clients MAY reject responses from a KDC where the client or server name is changed if the KDC does not support such a mechanism.
クライアントとKDC間の要求の変更を検出するメカニズムについては、セクション11を参照してください。ただし、最高の保護のために、フレキシブル認証セキュアトンネリング（FAST）[RFC6113]またはKDC交換全体を保護する別のメカニズムを使用する必要があります（SHOULD）。 KDCがこのようなメカニズムをサポートしていない場合、クライアントは、クライアントまたはサーバーの名前が変更されたKDCからの応答を拒否できます（MAY）。
Clients SHOULD reject an AS response that changes the server name unless the response is protected by such a mechanism or the new server name is one explicitly expected by the client. For example, many clients permit the realm name to be changed in an AS response, even if the response is not protected. See Section 13 for a discussion of the tradeoffs in allowing unprotected responses.
クライアントは、応答がそのようなメカニズムによって保護されていないか、新しいサーバー名がクライアントによって明示的に予期されているものでない限り、サーバー名を変更するAS応答を拒否する必要があります。たとえば、多くのクライアントは、応答が保護されていない場合でも、AS応答でレルム名を変更することを許可します。保護されていない応答を許可する際のトレードオフについては、セクション13を参照してください。
In order to permit authorization decisions to be made based on aliases as well as the canonicalized form of a principal name, the KDC MAY include the following authorization data element, wrapped in AD-KDC-ISSUED, in the initial credentials and copy it from a ticket-granting ticket into additional credentials:
エイリアスおよび正規化された形式のプリンシパル名に基づいて許可決定を行うことを許可するために、KDCは、AD-KDC-ISSUEDでラップされた次の許可データ要素を初期認証情報に含めて、それを追加の資格情報へのチケット許可チケット：
AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number 80 --
login-aliases [0] SEQUENCE (SIZE (1..MAX)) OF PrincipalName,
...
}
The login-aliases field lists one or more of the aliases the principal is known by.
login-aliasesフィールドには、プリンシパルが認識している1つ以上のエイリアスが一覧表示されます。
In addition to permitting authorization based on aliases, this permits user-to-user exchanges where the party receiving the authenticator knows the other party only by an alias. The recipient of such an authenticator SHOULD check the AD-LOGIN-ALIAS names, if present, in addition to the normal client name field, against the identity of the party with which it wishes to authenticate; either should be allowed to match. (Note that this is not backwards compatible with [RFC4120]; if the server side of the user-to-user exchange does not support this extension and does not know the true principal name, authentication may fail if the alias is sought in the client name field.)
これにより、エイリアスに基づく認証が許可されるだけでなく、認証者を受け取る当事者がエイリアスによってのみ他の当事者を知る場合のユーザー間の交換が可能になります。そのようなオーセンティケータの受信者は、通常のクライアント名フィールドに加えて、AD-LOGIN-ALIAS名が存在する場合、それを認証したい当事者のアイデンティティと照合する必要があります（SHOULD）。どちらも一致させる必要があります。 （これは[RFC4120]との下位互換性がないことに注意してください。ユーザー間交換のサーバー側がこの拡張をサポートせず、真のプリンシパル名を知らない場合、クライアントでエイリアスが求められると認証が失敗する可能性があります名前フィールド。）
The use of AD-KDC-ISSUED authorization data elements in cross-realm cases has not been well explored at this writing; hence, we will only specify the inclusion of this data in the one-realm case. The AD-LOGIN-ALIAS information SHOULD be dropped in the general cross-realm case. However, a realm MAY implement a policy of accepting and re-signing (wrapping in a new AD-KDC-ISSUED element) alias information provided by certain trusted realms in the cross-realm ticket-granting service.
レルム間でのAD-KDC-ISSUED認証データ要素の使用は、この執筆では十分に検討されていません。したがって、このデータを含めることを指定するのは、1レルムの場合のみです。 AD-LOGIN-ALIAS情報は、一般的なクロスレルムの場合は削除する必要があります。ただし、レルムは、レルム間のチケット認可サービスの特定の信頼されたレルムによって提供されるエイリアス情報を受け入れて再署名するポリシー（新しいAD-KDC-ISSUED要素でラップする）を実装してもよい（MAY）。
The canonical principal name for an alias MUST NOT be in the form of a ticket-granting service name, as (in a case of server name canonicalization) that would be construed as a case of cross-realm referral, described below.
エイリアスの正規のプリンシパル名は、（サーバー名の正規化の場合）以下に説明するレルム間の紹介の場合と解釈されるため、チケット許可サービス名の形式であってはなりません（MUST NOT）。
The simplest form of ticket referral is for a user requesting a ticket using an AS-REQ. In this case, the client machine will send the AS-REQ to a convenient realm trusted to map principals, for example, the realm of the client machine. In the case of the name alice@EXAMPLE.COM, the client MAY optimistically choose to send the request to EXAMPLE.COM. The realm in the AS-REQ is always the name of the realm that the request is for, as specified in [RFC4120].
チケット紹介の最も単純な形式は、AS-REQを使用してチケットをリクエストするユーザー用です。この場合、クライアントマシンはAS-REQを、プリンシパルをマップすることが信頼されている便利なレルム、たとえばクライアントマシンのレルムに送信します。 alice@EXAMPLE.COMという名前の場合、クライアントは、EXAMPLE.COMにリクエストを送信することを楽観的に選択できます。 AS-REQのレルムは常に、[RFC4120]で指定されているように、要求の対象となるレルムの名前です。
The KDC will try to lookup the name in its local account database. If the account is present in the realm of the request, it SHOULD return a KDC reply with the appropriate ticket.
KDCはローカルアカウントデータベースで名前を検索しようとします。アカウントがリクエストの領域に存在する場合、適切なチケットを含むKDC応答を返す必要があります。
If the account is not present in the realm specified in the request and the "canonicalize" KDC option is set, the KDC may look up the client principal name using some kind of name service or directory service. If this lookup is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]. If the lookup is successful, it MUST return an error KDC_ERR_WRONG_REALM [RFC4120]; in the error message, the crealm field will contain either the true realm of the client or another realm that MAY have better information about the client's true realm. The client MUST NOT use the cname returned in this error message.
リクエストで指定されたレルムにアカウントが存在せず、「canonicalize」KDCオプションが設定されている場合、KDCはなんらかのネームサービスまたはディレクトリサービスを使用してクライアントプリンシパル名を検索する場合があります。この検索が失敗した場合は、エラーKDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]を返す必要があります。検索が成功した場合は、エラーKDC_ERR_WRONG_REALM [RFC4120]を返す必要があります。エラーメッセージのcrealmフィールドには、クライアントの真のレルム、またはクライアントの真のレルムに関するより良い情報を持つ可能性のある別のレルムが含まれます。クライアントは、このエラーメッセージで返されたcnameを使用してはなりません（MUST NOT）。
If the client receives a KDC_ERR_WRONG_REALM error, it will issue a new AS request with the same client principal name used to generate the first AS request to the realm specified by the realm field of the Kerberos error message corresponding to the first request. (The client realm name will be updated in the new request to refer to this new realm.) The client SHOULD repeat these steps until it finds the true realm of the client. To avoid infinite referral loops, an implementation should limit the number of referrals. A suggested limit is 5 referrals before giving up.
クライアントがKDC_ERR_WRONG_REALMエラーを受信した場合、クライアントは、最初の要求に対応するKerberosエラーメッセージの領域フィールドで指定された領域への最初のAS要求の生成に使用されたものと同じクライアントプリンシパル名で新しいAS要求を発行します。 （クライアントのレルム名は、この新しいレルムを参照するように新しいリクエストで更新されます。）クライアントは、クライアントの真のレルムが見つかるまで、これらの手順を繰り返す必要があります。無限の参照ループを回避するには、実装で参照の数を制限する必要があります。提案された制限は、あきらめる前に5つの紹介です。
Since the same client name is sent to the referring and referred-to realms, both realms must recognize the same client names. In particular, the referring realm cannot (usefully) define principal name aliases that the referred-to realm will not know.
同じクライアント名が参照領域と参照先領域に送信されるため、両方の領域が同じクライアント名を認識する必要があります。特に、参照元のレルムは、（有効に）参照先のレルムが知らないプリンシパル名のエイリアスを定義できません。
The true principal name of the client, returned in AS-REP, can be validated in a subsequent TGS message exchange where its value is communicated back to the KDC via the authenticator in the PA-TGS-REQ padata [RFC4120]. However, this requires trusting the referred-to realm's KDCs. Clients should limit the referral mappings they will accept to realms trusted via some local policy. Some possible factors that might be taken into consideration for such a policy might include: o Any realm indicated by the local KDC if the returned KRB-ERROR message is protected by some additional means, for example, FAST
AS-REPで返されるクライアントの真のプリンシパル名は、後続のTGSメッセージ交換で検証できます。その値は、PA-TGS-REQ padata [RFC4120]のオーセンティケーターを介してKDCに返されます。ただし、これには、参照先のレルムのKDCを信頼する必要があります。クライアントは、ローカルポリシーを介して信頼されるレルムに受け入れる紹介マッピングを制限する必要があります。このようなポリシーで考慮される可能性のあるいくつかの要因には、以下が含まれる可能性があります。
o A list of realms configured by an administrator
o 管理者によって構成されたレルムのリスト
o Any realm accepted by the user when explicitly prompted
o 明示的に要求されたときにユーザーが受け入れるすべてのレルム
One common approach for limiting the realms from which referrals are accepted is to limit referrals to realms that can construct an authentication path back to the service principal of the local machine. This tends to work well when realms are generally within an organization and all realms that can form an authentication path back to the local machine have some reasonable level of mapping trust. Deployments involving more complex trust, for example, high probability of malicious realms, are likely to need more complex policy and MAY need to prompt the user before accepting some referrals.
紹介を受け入れるレルムを制限するための一般的なアプローチの1つは、ローカルマシンのサービスプリンシパルに戻る認証パスを構築できるレルムに紹介を制限することです。これは、レルムが一般的に組織内にあり、ローカルマシンへの認証パスを形成できるすべてのレルムに、ある程度のマッピング信頼のレベルがある場合にうまく機能する傾向があります。悪意のあるレルムの可能性が高いなど、より複雑な信頼を伴う展開では、より複雑なポリシーが必要になる可能性が高く、一部の紹介を受け入れる前にユーザーにプロンプトを表示する必要があります。
There is currently no provision for changing the client name in a client referral response.
現在、クライアント紹介応答でクライアント名を変更するための規定はありません。
The primary difference in server referrals is that the KDC returns a referral TGT rather than an error message as is done in the client referrals.
サーバー紹介の主な違いは、KDCがクライアント紹介で行われるエラーメッセージではなく、紹介TGTを返すことです。
If the "canonicalize" flag in the KDC options is set and the KDC doesn't find the principal locally, either as a regular principal or as an alias for another local principal, the KDC MAY return a cross-realm ticket-granting ticket to the next hop on the trust path towards a realm that may be able to resolve the principal name.
KDCオプションの「canonicalize」フラグが設定されていて、KDCがプリンシパルをローカルで、通常のプリンシパルとして、または別のローカルプリンシパルのエイリアスとして見つけられない場合、KDCはレルム間チケット認可チケットをプリンシパル名を解決できる可能性があるレルムへの信頼パス上の次のホップ。
The client will use this referral information to request a chain of cross-realm ticket-granting tickets until it reaches the realm of the server, and can then expect to receive a valid service ticket.
クライアントはこの紹介情報を使用して、サーバーのレルムに到達するまで、レルム間のチケット認可チケットのチェーンを要求し、有効なサービスチケットを受け取ることを期待できます。
However, an implementation should limit the number of referrals that it processes to avoid infinite referral loops. A suggested limit is 5 referrals before giving up.
ただし、実装では、無限参照ループを回避するために、処理する参照の数を制限する必要があります。提案された制限は、あきらめる前に5つの紹介です。
The client may cache the mapping of the requested name to the name of the next realm to use and the principal name to ask for (see Section 10).
クライアントは、要求された名前の、次に使用するレルムの名前と要求するプリンシパル名へのマッピングをキャッシュできます（セクション10を参照）。
Here is an example of a client requesting a service ticket for a service in realm DEV.EXAMPLE.COM where the client is in ADMIN.EXAMPLE.COM.
以下は、クライアントがADMIN.EXAMPLE.COMにあるレルムDEV.EXAMPLE.COMのサービスのサービスチケットを要求するクライアントの例です。
+NC = Canonicalize KDCOption set
C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM
S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM
C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM
S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM
C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM
S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM
Note that any referral or alias processing of the server name in user-to-user authentication should use the same data as client name canonicalization or referral. Otherwise, the name used by one user to log in may not be useable by another for user-to-user authentication to the first.
ユーザー間認証におけるサーバー名の参照またはエイリアス処理では、クライアント名の正規化または参照と同じデータを使用する必要があることに注意してください。そうしないと、あるユーザーがログインに使用した名前が、別のユーザーが最初のユーザー間の認証に使用できない場合があります。
RFC 4120 permits a KDC to return a closer referral ticket when a cross-realm TGT is requested. This specification extends this behavior when the canonicalize flag is set. When this flag is set, a KDC MAY return a TGT for a realm closer to the service for any service as discussed in the previous section. When a client follows such a referral, it includes the realm of the referred-to realm in the generated request.
RFC 4120では、レルム間のTGTが要求されたときに、KDCがより近い紹介チケットを返すことが許可されています。この仕様は、正規化フラグが設定されている場合にこの動作を拡張します。このフラグが設定されている場合、KDCは、前のセクションで説明したように、任意のサービスのサービスに近いレルムのTGTを返す場合があります。クライアントがそのような紹介に従うと、生成されたリクエストに参照先レルムのレルムが含まれます。
When the canonicalize flag is not set, the rules defined in RFC 4120 apply.
canonicalizeフラグが設定されていない場合、RFC 4120で定義されたルールが適用されます。
It is possible that the client may wish to get additional credentials for the same service principal, perhaps with different authorization-data restrictions or other changed attributes. The return of a server referral from a KDC can be taken as an indication that the requested principal does not currently exist in the local realm. Clearly, it would reduce network traffic if the clients could cache that information and use it when acquiring the second set of credentials for a service, rather than always having to recheck with the local KDC to see if the name has been created locally.
クライアントが、おそらく異なる承認データ制限または他の変更された属性を使用して、同じサービスプリンシパルの追加の資格情報を取得したい場合があります。 KDCからのサーバー参照の返却は、要求されたプリンシパルが現在ローカルレルムに存在しないことを示していると見なすことができます。明らかに、クライアントがその情報をキャッシュし、サービスの2番目の資格情報セットを取得するときにそれを使用できれば、常にローカルKDCに再確認して名前がローカルに作成されているかどうかを確認する必要がなく、ネットワークトラフィックが減少します。
When the TGT expires, the previously returned referral from the local KDC should be considered invalid, and the local KDC must be asked again for information for the desired service principal name. (Note that the client may get back multiple referral TGTs from the local KDC to the same remote realm, with different lifetimes. The lifetime information SHOULD be properly associated with the requested service principal names. Simply having another TGT for the same remote realm does not extend the validity of previously acquired information about one service principal name.)
TGTの有効期限が切れると、以前にローカルKDCから返された紹介は無効と見なされ、ローカルKDCに目的のサービスプリンシパル名の情報を再度要求する必要があります。 （クライアントは、ローカルKDCから同じリモートレルムに複数の紹介TGTを返しますが、ライフタイムは異なります。ライフタイム情報は、要求されたサービスプリンシパル名に適切に関連付ける必要があります。同じリモートレルムに別のTGTを指定するだけでは、 1つのサービスプリンシパル名について以前に取得した情報の有効性を拡張します。）
Accordingly, KDC authors and maintainers should consider what factors (e.g., DNS alias lifetimes) they may or may not wish to incorporate into credential expiration times in cases of referrals.
したがって、KDCの作成者と保守担当者は、紹介の場合にクレデンシャルの有効期限に組み込むことを望む、または望まない可能性がある要因（DNSエイリアスのライフタイムなど）を考慮する必要があります。
Implementations of this specification MUST support the FAST negotiation mechanism described in this section. This mechanism provides detection of KDC requests modified by an attacker when those requests result in a reply instead of an error. In addition, this mechanism provides a secure way to detect if a KDC supports FAST.
この仕様の実装は、このセクションで説明するFASTネゴシエーションメカニズムをサポートする必要があります。このメカニズムは、要求の結果がエラーではなく応答になる場合に、攻撃者が変更したKDC要求を検出します。さらに、このメカニズムは、KDCがFASTをサポートしているかどうかを検出する安全な方法を提供します。
Clients conforming to this specification MUST send new pre-authentication data of type PA-REQ-ENC-PA-REP (149) in all AS requests and MAY send this padata type in TGS requests. The value of this padata item SHOULD be empty and its value MUST be ignored by a receiving KDC. Sending this padata item indicates support for this negotiation mechanism. KDCs conforming to this specification must always set the ticket flag enc-pa-rep (15) in all the issued tickets. This ticket flag indicates KDC support for the mechanism.
この仕様に準拠するクライアントは、すべてのAS要求でタイプPA-REQ-ENC-PA-REP（149）の新しい事前認証データを送信する必要があり、TGS要求でこのpadataタイプを送信できます（MAY）。このpadataアイテムの値は空である必要があり（SHOULD）、その値は受信側KDCによって無視されなければなりません（MUST）。このpadataアイテムを送信することは、この交渉メカニズムがサポートされていることを示します。この仕様に準拠するKDCは、発行されたすべてのチケットに常にチケットフラグenc-pa-rep（15）を設定する必要があります。このチケットフラグは、メカニズムのKDCサポートを示します。
The KDC response [RFC4120] is extended to support an additional field containing encrypted pre-authentication data.
KDC応答[RFC4120]は、暗号化された事前認証データを含む追加フィールドをサポートするように拡張されています。
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL,
encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
}
The encrypted-pa-data element MUST be absent unless either the "canonicalize" KDC option is set or the PA-REQ-ENC-PA-REP padata item is sent.
「canonicalize」KDCオプションが設定されているか、PA-REQ-ENC-PA-REP padataアイテムが送信されない限り、encrypted-pa-data要素は存在しない必要があります。
If the PA-REQ-ENC-PA-REP padata item is sent in the request, then the KDC MUST include a PA-REQ-ENC-PA-REP padata item in the encrypted-pa-data item of any generated KDC reply. The PA-REQ-ENC-PA-REP pa-data value contains the checksum computed over the type AS-REQ or TGS-REQ in the request. The checksum key is the reply key and the checksum type is the required checksum type for the encryption type of the reply key, and the key usage number is KEY_USAGE_AS_REQ (56). If the KDC supports FAST, then the KDC MUST include a padata of type PA-FX-FAST in any encrypted-pa-data sequence it generates. The padata item MUST be empty on sending, and the contents of the padata item MUST be ignored on receiving.
PA-REQ-ENC-PA-REPパデータ項目が要求で送信される場合、KDCは、生成されたKDC応答の暗号化されたパデータ項目にPA-REQ-ENC-PA-REPパデータ項目を含める必要があります。 PA-REQ-ENC-PA-REP pa-data値には、要求のタイプAS-REQまたはTGS-REQで計算されたチェックサムが含まれます。チェックサムキーは応答キーであり、チェックサムタイプは応答キーの暗号化タイプに必要なチェックサムタイプであり、キー使用番号はKEY_USAGE_AS_REQ（56）です。 KDCがFASTをサポートしている場合、KDCは、生成するすべての暗号化されたpa-dataシーケンスにタイプPA-FX-FASTのpadataを含める必要があります。送信時にはpadataアイテムを空にする必要があり、受信時にはpadataアイテムのコンテンツを無視する必要があります。
A client MUST reject a response for which it sent PA-REQ-ENC-PA-REP if the ENC-PA-REP ticket flag is set and the PA-REQ-ENC-PA-REP padata item is absent or the checksum is not successfully verified.
ENC-PA-REPチケットフラグが設定されていて、PA-REQ-ENC-PA-REPパデータ項目が存在しないか、チェックサムが存在しない場合、クライアントはPA-REQ-ENC-PA-REPを送信した応答を拒否する必要があります。正常に確認されました。
PA-REQ-ENC-PA-REP has been registered in the Kerveros "Pre-authentication and Typed Data" registry <http://www.iana.org/assignments/kerberos-parameters>.
PA-REQ-ENC-PA-REPは、Kerverosの「事前認証と型付きデータ」レジストリ<http://www.iana.org/assignments/kerberos-parameters>に登録されています。
For the AS exchange case, it is important that the logon mechanism not trust a name that has not been used to authenticate the user. For example, the name that the user enters as part of a logon exchange may not be the name that the user authenticates as, given that the KDC_ERR_WRONG_REALM error may have been returned. The relevant Kerberos naming information for logon (if any) is the client name and client realm in the service ticket targeted at the workstation obtained using the user's initial TGT. That is, rather than trusting the client name in the AS response, a workstation SHOULD perform an AP-REQ authentication against itself as a service and use the client name in the ticket issued for its service by the KDC.
AS交換の場合、ログオンメカニズムがユーザーの認証に使用されていない名前を信頼しないことが重要です。たとえば、ユーザーがログオン交換の一部として入力した名前は、KDC_ERR_WRONG_REALMエラーが返された場合、ユーザーが認証した名前とは異なる場合があります。ログオンに関連するKerberos命名情報（存在する場合）は、ユーザーの初期TGTを使用して取得されたワークステーションをターゲットとするサービスチケットのクライアント名とクライアント領域です。つまり、ワークステーションは、AS応答でクライアント名を信頼するのではなく、サービスとして自身に対してAP-REQ認証を実行し、KDCがサービスに対して発行したチケットでクライアント名を使用する必要があります（SHOULD）。
How the client name and client realm are mapped into a local account for logon is a local matter, but the client logon mechanism MUST use additional information such as the client realm and/or authorization attributes from the service ticket presented to the workstation by the user when mapping the logon credentials to a local account on the workstation.
クライアント名とクライアントレルムをログオン用のローカルアカウントにマップする方法はローカルな問題ですが、クライアントログオンメカニズムは、ユーザーによってワークステーションに提示されたサービスチケットからのクライアントレルムや認証属性などの追加情報を使用する必要がありますログオン資格情報をワークステーションのローカルアカウントにマッピングするとき。
Not all fields in a KDC reply defined by RFC 4120 are protected. None of the fields defined in RFC 4120 for AS request are protected, and some information in a TGS request may not be protected. The referrals mechanism creates several opportunities for attack because of these unprotected fields. FAST [RFC6113] can be used to completely mitigate these issues by protecting both the KDC request and response. However, FAST requires that a client obtain an armor ticket before authenticating. Not all realms permit all clients to obtain armor tickets. Also, while it is expected to be uncommon, a client might wish to use name canonicalization while obtaining an armor ticket. The mechanism described in Section 11 detects modification of the request between the KDC and client, mitigating some attacks.
RFC 4120で定義されているKDC応答のすべてのフィールドが保護されるわけではありません。 ASリクエスト用にRFC 4120で定義されているフィールドは保護されておらず、TGSリクエストの一部の情報は保護されていない可能性があります。参照メカニズムは、これらの保護されていないフィールドのために、攻撃の機会をいくつか作成します。 FAST [RFC6113]を使用すると、KDC要求と応答の両方を保護することにより、これらの問題を完全に軽減できます。ただし、FASTでは、クライアントが認証前にアーマーチケットを取得する必要があります。すべてのレルムがすべてのクライアントにアーマーチケットの取得を許可するわけではありません。また、一般的ではないことが予想されますが、クライアントはアーマーチケットを取得するときに名前の正規化を使用することを望む場合があります。セクション11で説明するメカニズムは、KDCとクライアント間の要求の変更を検出し、一部の攻撃を軽減します。
There is a widely deployed base of implementations that use name canonicalization or server referrals that use neither the negotiation mechanism nor FAST. So, implementations may be faced with only the limited protection afforded by RFC 4120, by the negotiation mechanism discussed in this document, or by FAST. All three situations are important to consider from a security standpoint.
名前の正規化またはネゴシエーションメカニズムとFASTのどちらも使用しないサーバー参照を使用する、広く展開されている実装ベースがあります。そのため、実装は、RFC 4120、このドキュメントで説明されているネゴシエーションメカニズム、またはFASTによって提供される限られた保護のみに直面する可能性があります。セキュリティの観点から考えると、3つの状況すべてが重要です。
An attacker cannot mount a downgrade attack against a client. The negotiation mechanism described in this document is securely indicated by the presence of a ticket flag. So, a client will detect if the facility was available but not used. It is possible for an attacker to strip the indication that a client supports the negotiation facility. The client will learn from the response that this happened, but the KDC will not learn that the client is attacked. So, for a single round-trip Kerberos exchange, the KDC may believe the exchange was successful when the client detects an attack. Packet loss or client failure can produce a similar result; this is not a significant vulnerability. The negotiation facility described in this document securely indicates the presence of FAST. So, if a client wishes to use FAST when it is available, an attacker cannot force the client to downgrade away from FAST. An attacker MAY be able to prevent a client from obtaining an armor ticket, for example, by responding to a request for anonymous Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) with an error response.
攻撃者は、クライアントに対してダウングレード攻撃を仕掛けることはできません。このドキュメントで説明されているネゴシエーションメカニズムは、チケットフラグの存在によって安全に示されます。そのため、クライアントは、機能が利用可能であったが使用されなかったかどうかを検出します。攻撃者は、クライアントがネゴシエーションファシリティをサポートしているという表示を取り除くことができます。クライアントはこれが発生したことを応答から学習しますが、KDCはクライアントが攻撃されたことを学習しません。したがって、単一の往復Kerberos交換の場合、KDCは、クライアントが攻撃を検出したときに交換が成功したと信じる場合があります。パケット損失またはクライアント障害でも同様の結果が生じる可能性があります。これは重大な脆弱性ではありません。このドキュメントで説明する交渉機能は、FASTの存在を安全に示します。したがって、クライアントが利用可能なときにFASTを使用したい場合、攻撃者はクライアントをFASTからダウングレードするように強制することはできません。攻撃者は、たとえば、Kerberosの初期認証用の匿名公開鍵暗号化（PKINIT）の要求にエラー応答で応答することにより、クライアントがアーマーチケットを取得できないようにする可能性があります（MAY）。
If FAST is used, then the communications between the client and KDC are protected. However, name canonicalization places a new responsibility for mapping principals onto the KDC. This can increase the number of KDCs involved in an authentication, which adds additional trusted third parties to the exchange.
FASTを使用すると、クライアントとKDC間の通信が保護されます。ただし、名前の正規化により、プリンシパルをKDCにマッピングする新しい責任が生じます。これにより、認証に関与するKDCの数が増える可能性があり、信頼できるサードパーティが取引所に追加されます。
If only the negotiation mechanism is used, then the request from the client to the KDC is protected, but not all of the response is protected. In particular, the client name is not protected; the ticket is also not protected. An attacker can potentially modify these fields. Modification of the client name will result in a denial of service. When the client attempts to authenticate to a service (including the TGS), it constructs an AP-REQ message. This message includes a client name that MUST match the client name in the ticket according to RFC 4120. Thus, if the client name is changed, the resulting ticket will fail when used. This is undesirable because the authentication is separated from the later failure, which may confuse problem determination. If the ticket is replaced with another ticket, then later authentication to a service will fail because the client will not know the session key for the other ticket. If the ticket is simply modified, then authentication to a service will fail as with RFC 4120. More significant attacks are possible if a KDC violates the requirements of RFC 4120 and issues two tickets with the same session key, or if a service violates the requirements of RFC 4120 and does not check the client name against that in the ticket.
ネゴシエーションメカニズムのみを使用する場合、クライアントからKDCへの要求は保護されますが、すべての応答が保護されるわけではありません。特に、クライアント名は保護されていません。チケットも保護されていません。攻撃者はこれらのフィールドを変更する可能性があります。クライアント名を変更すると、サービス拒否が発生します。クライアントがサービス（TGSを含む）に対する認証を試みると、AP-REQメッセージが作成されます。このメッセージには、RFC 4120に従ってチケットのクライアント名と一致する必要があるクライアント名が含まれています。したがって、クライアント名が変更された場合、結果のチケットは使用時に失敗します。これは、認証が後の失敗から切り離され、問題判別を混乱させる可能性があるため、望ましくありません。チケットが別のチケットに置き換えられた場合、クライアントは他のチケットのセッションキーを認識できないため、サービスに対する後の認証は失敗します。チケットが単に変更された場合、サービスへの認証はRFC 4120と同様に失敗します。KDCがRFC 4120の要件に違反し、同じセッションキーで2つのチケットを発行する場合、またはサービスが要件に違反する場合、より重大な攻撃が可能ですRFC 4120に準拠しており、チケット内のクライアント名に対してクライアント名をチェックしません。
There is an additional attack possible when FAST is not used against KDC_ERR_WRONG_REALM. Since this is an error response, not an AS response, it is not protected by the negotiation mechanism. Thus, an attacker may be able to convince a client to authenticate to a realm other than the one intended. If an attacker is off-path, this may give the attacker an advantage in attacking the client's credentials. Also, see the discussion of shared passwords below.
KDC_ERR_WRONG_REALMに対してFASTが使用されていない場合、追加の攻撃が可能です。これはAS応答ではなくエラー応答であるため、ネゴシエーションメカニズムによって保護されていません。したがって、攻撃者はクライアントを意図したもの以外の領域で認証するように仕向けることができます。攻撃者がパスから外れている場合、これは攻撃者にクライアントの資格情報を攻撃する利点を与える可能性があります。また、以下の共有パスワードの説明も参照してください。
More serious attacks are possible if no protection beyond RFC 4120 is used. In this case, neither the client name nor the service name is protected between the client and KDC. In the general case, if an attacker changes the client name, then authentication will fail because the client will not have the right credentials (password, certificate, or other) to authenticate as the user selected by the attacker. However, see the discussion of shared passwords below. Changing the server name can be a very significant attack. For example, if a user is authenticating in order to send some confidential information, then the attacker could gain this information by directing the user to a server under the attacker's control. The server name in the response is protected by RFC 4120, but not the one in the request. Fortunately, users are typically authenticating to the "krbtgt" service in an AS exchange. Clients that permit changes to the server name when no protection beyond RFC 4120 is in use SHOULD carefully restrict what service names are acceptable. One critical case to consider is the password-changing service. When a user authenticates to change their password, they use an AS authentication directly to the password-changing service. Clients MUST restrict service name changes sufficiently that the client ends up talking to the correct password-changing service.
RFC 4120を超える保護を使用しない場合、より深刻な攻撃が可能になります。この場合、クライアント名とサービス名のどちらもクライアントとKDCの間で保護されません。一般的なケースでは、攻撃者がクライアント名を変更すると、攻撃者が選択したユーザーとして認証するための適切な資格情報（パスワード、証明書など）がクライアントにないため、認証は失敗します。ただし、以下の共有パスワードの説明を参照してください。サーバー名を変更すると、非常に重大な攻撃になる可能性があります。たとえば、ユーザーが機密情報を送信するために認証を行っている場合、攻撃者は、ユーザーを攻撃者の制御下にあるサーバーに誘導することにより、この情報を入手する可能性があります。応答のサーバー名はRFC 4120で保護されていますが、要求のサーバー名は保護されていません。幸い、ユーザーは通常、AS交換で「krbtgt」サービスに対して認証を行っています。 RFC 4120を超える保護が使用されていないときにサーバー名の変更を許可するクライアントは、許容されるサービス名を慎重に制限する必要があります。考慮すべき重要なケースの1つは、パスワード変更サービスです。ユーザーが自分のパスワードを変更するために認証するとき、パスワード変更サービスに対して直接AS認証を使用します。クライアントは、サービス名の変更を十分に制限して、クライアントが正しいパスワード変更サービスと通信するようにする必要があります。
A special case to examine is when the user is known (or correctly suspected) to use the same password for multiple accounts. A man-in-the-middle attacker can either alter the request on its way to the KDC, changing the client principal name, or reply to the client with a response previously sent by the KDC in response to a request from the attacker. The response received by the client can then be decrypted by the user, though if the default "salt" generated from the principal name is used to produce the user's key, a PA-ETYPE-INFO or PA-ETYPE-INFO2 preauth record may need to be added or altered by the attacker to cause the client software to generate the key needed for the message it will receive. None of this requires the attacker to know the user's password, and without further checking, this could cause the user to unknowingly use the wrong credentials.
調べる特別なケースは、ユーザーが複数のアカウントに同じパスワードを使用することがわかっている（または正しく疑われている）場合です。中間者攻撃者は、KDCに向かう途中で要求を変更したり、クライアントプリンシパル名を変更したり、攻撃者からの要求に応じてKDCが以前に送信した応答でクライアントに応答したりできます。クライアントが受信した応答は、ユーザーが復号化できますが、プリンシパル名から生成されたデフォルトの「塩」を使用してユーザーのキーを生成する場合、PA-ETYPE-INFOまたはPA-ETYPE-INFO2事前認証レコードが必要になる場合があります。攻撃者によって追加または変更され、クライアントソフトウェアが受信するメッセージに必要なキーを生成します。これはいずれも、攻撃者がユーザーのパスワードを知る必要がなく、さらにチェックしないと、ユーザーが無意識のうちに誤った資格情報を使用する可能性があります。
In normal operation as described in [RFC4120], a generated AP-REQ message includes in the Authenticator field a copy of the client's idea of its own principal name. If this differs from the name in the KDC-generated ticket, the application server will reject the message.
[RFC4120]で説明されている通常の動作では、生成されたAP-REQメッセージのAuthenticatorフィールドに、クライアントの独自のプリンシパル名に関するアイデアのコピーが含まれています。これがKDC生成チケットの名前と異なる場合、アプリケーションサーバーはメッセージを拒否します。
With client name canonicalization as described in this document, the client may get its principal name from the response from the KDC. Using the wrong credentials may provide an advantage to an attacker. For example, if a client uses one principal for administrative operations and one for less privileged operation, an attacker may coerce a client into using the wrong privilege to either cause some later operation to succeed or fail.
このドキュメントで説明されているクライアント名の正規化を使用すると、クライアントはKDCからの応答からプリンシパル名を取得できます。間違った資格情報を使用すると、攻撃者に有利になる可能性があります。たとえば、クライアントが管理操作に1つのプリンシパルを使用し、権限の低い操作に1つのプリンシパルを使用する場合、攻撃者はクライアントに間違った特権を使用して、後の操作を成功または失敗させる可能性があります。
In cases of credential renewal, forwarding, or validation, if credentials are sent to the KDC that are not an initial ticket-granting ticket for the client's home realm, the encryption key used to protect the TGS exchange is one known to a third party (namely, the service for which the credential was issued). Consequently, in such an exchange, the protection described earlier may be compromised by the service. This is not generally believed to be a problem. If it is, some form of explicit TGS armor could be added to FAST.
資格情報の更新、転送、または検証の場合、クライアントのホームレルムの最初のチケット許可チケットではない資格情報がKDCに送信されると、TGS交換を保護するために使用される暗号化キーはサードパーティに知られています（つまり、資格情報が発行されたサービス）。したがって、そのような交換では、前述の保護がサービスによって危険にさらされる可能性があります。これは一般に問題とは考えられていません。もしそうなら、何らかの形の明示的なTGSアーマーをFASTに追加できます。
John Brezak, Mike Swift, and Jonathan Trostle wrote the initial version of this document.
John Brezak、Mike Swift、Jonathan Trostleがこのドキュメントの最初のバージョンを書きました。
Karthik Jaganathan contributed to earlier versions.
Karthik Jaganathanが以前のバージョンに貢献しました。
Sam Hartman's work on this document was funded by the MIT Kerberos Consortium.
このドキュメントに関するSam Hartmanの作業は、MIT Kerberosコンソーシアムから資金提供を受けました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for Kerberos Pre-Authentication", RFC 6113, April 2011.
[RFC6113] Hartman、S。およびL. Zhu、「Kerberos事前認証の一般化されたフレームワーク」、RFC 6113、2011年4月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC4556] Zhu、L。、およびB. Tung、「Kerberosでの初期認証のための公開鍵暗号化（PKINIT）」、RFC 4556、2006年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation of Crossrealm Referral Handling in the MIT Kerberos Client", Network and Distributed System Security Symposium, February 2001.
[XPR] Trostle、J.、Kosinovsky、I。、およびM. Swift、「MIT Kerberosクライアントでのクロスレルム参照処理の実装」、ネットワークおよび分散システムセキュリティシンポジウム、2001年2月。
Appendix A. Compatibility with Earlier Implementations of Name Canonicalization
付録A.名前の正規化の以前の実装との互換性
The Microsoft Windows 2000 and Windows 2003 releases included an earlier form of name-canonicalization [XPR]. Here are the differences:
Microsoft Windows 2000およびWindows 2003リリースには、以前の形式の名前正規化[XPR]が含まれていました。違いは次のとおりです。
1) Windows include an additional encrypted padata element. The preauth data type definition in the encrypted preauth data is as follows:
1）Windowsには、暗号化されたpadata要素が追加されています。暗号化された事前認証データの事前認証データタイプ定義は次のとおりです。
PA-SVR-REFERRAL-INFO 20
PA-SVR-REFERRAL-INFO 20
PA-SVR-REFERRAL-DATA ::= SEQUENCE {
referred-name [1] PrincipalName OPTIONAL,
referred-realm [0] Realm
}}
The referred-principal is never sent. The referred-realm is included in TGS replies and includes the realm name of the realm to which the client is referred. This information is redundant with the realm in the second component of the returned TGT.
紹介されたプリンシパルは送信されません。参照されるレルムはTGS応答に含まれ、クライアントが参照されるレルムのレルム名が含まれます。この情報は、返されたTGTの2番目のコンポーネントのレルムと重複しています。
2) When PKINIT [RFC4556] is used, the NT-ENTERPRISE client name is encoded as a Subject Alternative Name (SAN) extension [RFC5280] in the client's X.509 certificate. The type of the otherName field for this SAN extension is AnotherName [RFC5280]. The type-id field of the type AnotherName is id-ms-sc-logon-upn (1.3.6.1.4.1.311.20.2.3), and the value field of the type AnotherName is a KerberosString [RFC4120]. The value of this KerberosString type is the single component in the name-string [RFC4120] sequence for the corresponding NT-ENTERPRISE name type.
2）PKINIT [RFC4556]を使用する場合、NT-ENTERPRISEクライアント名は、クライアントのX.509証明書でサブジェクト代替名（SAN）拡張[RFC5280]としてエンコードされます。このSAN拡張のotherNameフィールドのタイプは、AnotherName [RFC5280]です。タイプAnotherNameのタイプIDフィールドはid-ms-sc-logon-upn（1.3.6.1.4.1.311.20.2.3）であり、タイプAnotherNameの値フィールドはKerberosString [RFC4120]です。このKerberosStringタイプの値は、対応するNT-ENTERPRISE名前タイプの名前文字列[RFC4120]シーケンスの単一のコンポーネントです。
In Microsoft's current implementation through the use of global catalogs, any domain in one forest is reachable from any other domain in the same forest or another trusted forest with 3 or less referrals. A forest is a collection of realms with hierarchical trust relationships: there can be multiple trust trees in a forest; each child and parent realm pair and each root realm pair have bidirectional transitive direct trust between them.
グローバルカタログを使用したMicrosoftの現在の実装では、1つのフォレスト内の任意のドメインは、同じフォレスト内の別のドメインまたは3つ以下の参照を持つ別の信頼されたフォレストから到達可能です。フォレストは、階層的な信頼関係を持つレルムのコレクションです。フォレストには複数の信頼ツリーが存在する場合があります。子と親の各レルムペアと各ルートレルムのペアは、それらの間で双方向の推移的な直接信頼を持っています。
While we might want to permit multiple aliases to exist and even be reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only one NT-ENTERPRISE alias to exist, so this question had not previously arisen.
複数のエイリアスの存在を許可したり、AD-LOGIN-ALIASで報告したりすることもできますが、Microsoftの実装では、NT-ENTERPRISEエイリアスの存在を1つだけ許可しているため、この問題は以前は発生していませんでした。
Authors' Addresses
著者のアドレス
Sam Hartman (editor) Painless Security
サムハートマン（編集者）痛みのないセキュリティ
EMail: hartmans-ietf@mit.edu
Kenneth Raeburn Massachusetts Institute of Technology
ケネスレイバーンマサチューセッツ工科大学
EMail: raeburn@mit.edu
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
ぁっｒｙ ←う みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うＳ
EMail: lzhu@microsoft.com