[要約] RFC 6784は、DHCPv6におけるKerberosオプションの仕様を定義しています。その目的は、IPv6ネットワークでのセキュアな認証と認可を提供するために、Kerberosプロトコルを使用するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) S. Sakane
Request for Comments: 6784 Cisco Systems
Category: Standards Track M. Ishiyama
ISSN: 2070-1721 Toshiba Corporation
November 2012
Kerberos Options for DHCPv6
DHCPv6のKerberosオプション
Abstract
概要
This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos.
このドキュメントでは、IPv6の動的ホスト構成プロトコル（DHCPv6）の4つの新しいオプションを定義します。これらのオプションは、Kerberosの構成情報を運ぶために使用されます。
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/rfc6784.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6784で入手できます。
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. Kerberos Options ................................................4
3.1. Kerberos Principal Name Option .............................4
3.2. Kerberos Realm Name Option .................................5
3.3. Kerberos Default Realm Name Option .........................6
3.4. Kerberos KDC Option ........................................6
4. Client and Server Operation .....................................7
4.1. KDC Discovery for a Client .................................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................9
7. Acknowledgments .................................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Appendix A. An Example of the Operation of the Client .............11
Kerberos Version 5 [RFC4120] is a trusted third-party authentication system. Each organization wishing to use Kerberos establishes its own "realm", and each client is registered as part of that realm. At least one Key Distribution Center (KDC) is required for the operation of a Kerberos realm.
Kerberosバージョン5 [RFC4120]は、信頼できるサードパーティ認証システムです。 Kerberosの使用を希望する各組織は独自の「レルム」を確立し、各クライアントはそのレルムの一部として登録されます。 Kerberosレルムの操作には、少なくとも1つのキー配布センター（KDC）が必要です。
When a client wishes to communicate with, and be authenticated to, a Kerberos application server (also a client of the KDC), the client identifies itself, and its realm, to the KDC and acquires a credential from the KDC. The client then presents the credential to the Kerberos application server, which can use the credential to authenticate the client. The client needs to know at least one IP address for a KDC in order to initiate this process.
クライアントがKerberosアプリケーションサーバー（KDCのクライアントでもある）と通信して認証を受けることを望む場合、クライアントは自身とその領域をKDCに対して識別し、KDCから資格を取得します。次に、クライアントは資格情報をKerberosアプリケーションサーバーに提示します。Kerberosアプリケーションサーバーは、資格情報を使用してクライアントを認証できます。このプロセスを開始するには、クライアントがKDCのIPアドレスを少なくとも1つ知っている必要があります。
One example of the application of this protocol is as follows. A student might want to use a shared, public workstation, one that is not configured for Kerberos. If there is a mechanism for the workstation to obtain a realm name and IP address for a KDC, then a student need only input a user-id and pass phrase to be able to use Kerberos.
このプロトコルの適用例の1つは次のとおりです。学生は、Kerberos用に構成されていない共有のパブリックワークステーションを使用する場合があります。ワークステーションがKDCのレルム名とIPアドレスを取得するメカニズムがある場合、学生はKerberosを使用できるようにするためにユーザーIDとパスフレーズを入力するだけで済みます。
The Kerberos V5 specification [RFC4120] defines the use of DNS SRV records [RFC2782] for KDC discovery. Some systems, such as industrial systems, do not use DNS. Such systems already have their own name spaces and their own name resolution systems, including preconfigured mapping tables for devices, and do not use Fully Qualified Domain Names. However, many of these systems do use DHCP.
Kerberos V5仕様[RFC4120]は、KDCディスカバリ用のDNS SRVレコード[RFC2782]の使用を定義しています。産業用システムなど、一部のシステムはDNSを使用しません。そのようなシステムには、独自の名前空間と独自の名前解決システム（デバイス用に事前構成されたマッピングテーブルを含む）がすでにあり、完全修飾ドメイン名を使用していません。ただし、これらのシステムの多くはDHCPを使用します。
Adding a DNS server to such systems may decrease the reliability of the system and increase the management cost. In such an environment, another mechanism is needed to provide an IP address for the KDC. For the PacketCable Architecture [PCARCH], RFC 3634 [RFC3634] defines the KDC Server Address sub-option for the DHCPv4 CableLabs Client Configuration option. However, a mechanism is still needed to provide a realm name and an IPv6 address -- one that does not depend on any external architecture.
このようなシステムにDNSサーバーを追加すると、システムの信頼性が低下し、管理コストが増加する可能性があります。このような環境では、KDCにIPアドレスを提供する別のメカニズムが必要です。 PacketCableアーキテクチャ[PCARCH]の場合、RFC 3634 [RFC3634]は、DHCPv4 CableLabsクライアント構成オプションのKDCサーバーアドレスサブオプションを定義します。ただし、レルム名とIPv6アドレス（外部アーキテクチャに依存しないもの）を提供するメカニズムが依然として必要です。
This document defines a Kerberos option for DHCPv6 that provides a realm name and/or a list of KDC IP addresses. This option does not replace or modify any of the existing methods for obtaining this information.
このドキュメントでは、レルム名やKDC IPアドレスのリストを提供するDHCPv6のKerberosオプションを定義しています。このオプションは、この情報を取得するための既存の方法を置き換えたり変更したりしません。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
It is assumed that the readers are familiar with the terms and concepts described in DHCPv6 [RFC3315], Kerberos V5 [RFC4120], and DNS SRV [RFC2782].
読者はDHCPv6 [RFC3315]、Kerberos V5 [RFC4120]、およびDNS SRV [RFC2782]で説明されている用語と概念に精通していることを前提としています。
This document defines four DHCPv6 configuration parameters for Kerberos.
このドキュメントでは、Kerberosの4つのDHCPv6構成パラメータを定義しています。
Kerberos Principal Name Option
Kerberosプリンシパル名オプション
Kerberos Realm Name Option
Kerberosレルム名オプション
Kerberos Default Realm Name Option
Kerberosのデフォルトのレルム名オプション
Kerberos KDC Option
Kerberos KDCオプション
This section describes the format of each option and the usage of each field in that option.
このセクションでは、各オプションの形式と、そのオプションの各フィールドの使用法について説明します。
These options, except for the Kerberos KDC Option, MUST NOT appear more than once in a DHCPv6 message.
これらのオプションは、Kerberos KDCオプションを除いて、DHCPv6メッセージで複数回表示されてはなりません（MUST NOT）。
The Kerberos Principal Name Option carries the name of a Kerberos principal. This is sent by the client to the DHCPv6 server, which MAY use it to select a specific set of configuration parameters, either for a client or for a Kerberos application server.
Kerberosプリンシパル名オプションには、Kerberosプリンシパルの名前が含まれています。これはクライアントからDHCPv6サーバーに送信されます。DHCPv6サーバーはこれを使用して、クライアントまたはKerberosアプリケーションサーバーの特定の構成パラメーターセットを選択できます（MAY）。
The format of the Kerberos Principal Name Option is:
Kerberosプリンシパル名オプションの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_PRINCIPAL_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: principal-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16 bits): OPTION_KRB_PRINCIPAL_NAME (75)
o オプションコード（16ビット）：OPTION_KRB_PRINCIPAL_NAME（75）
o option-len (16 bits): length of the principal-name field.
o option-len（16ビット）：プリンシパル名フィールドの長さ。
o principal-name (variable): a client principal name. The encoding of the principal-name field MUST conform to the definition of "PrincipalName" in Section 5.2.2 of RFC 4120 [RFC4120].
o プリンシパル名（変数）：クライアントプリンシパル名。 principal-nameフィールドのエンコーディングは、RFC 4120 [RFC4120]のセクション5.2.2の「PrincipalName」の定義に準拠している必要があります。
The Kerberos Realm Name Option carries a Kerberos realm name. A DHCPv6 client uses this option to specify to a DHCPv6 server which realm the client wants to access.
Kerberosレルム名オプションには、Kerberosレルム名が含まれています。 DHCPv6クライアントはこのオプションを使用して、クライアントがアクセスするレルムをDHCPv6サーバーに指定します。
The format of the Kerberos Realm Name Option is:
Kerberosレルム名オプションの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_REALM_NAME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: realm-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16 bits): OPTION_KRB_REALM_NAME (76)
o オプションコード（16ビット）：OPTION_KRB_REALM_NAME（76）
o option-len (16 bits): the length of the realm-name field in octets.
o option-len（16ビット）：オクテット単位の領域名フィールドの長さ。
o realm-name (variable): a realm-name. The encoding of the realm-name field MUST conform to the definition of "Realm" in Section 5.2.2 of RFC 4120 [RFC4120].
o レルム名（変数）：レルム名。レルム名フィールドのエンコーディングは、RFC 4120 [RFC4120]のセクション5.2.2の「レルム」の定義に準拠する必要があります。
The Kerberos Default Realm Name Option is used to specify a default realm name for the Kerberos system. A DHCPv6 server uses this option to specify the default realm name to both clients and Kerberos application servers.
Kerberosのデフォルトのレルム名オプションは、Kerberosシステムのデフォルトのレルム名を指定するために使用されます。 DHCPv6サーバーはこのオプションを使用して、クライアントとKerberosアプリケーションサーバーの両方にデフォルトのレルム名を指定します。
The option-code of this option is OPTION_KRB_DEFAULT_REALM_NAME (77). The format and usage of the option-len and realm-name fields are identical to those for the Kerberos Realm Name Option.
このオプションのオプションコードはOPTION_KRB_DEFAULT_REALM_NAME（77）です。 option-lenおよびrealm-nameフィールドの形式と使用法は、Kerberos Realm Name Optionのものと同じです。
The Kerberos KDC Option is used to provide configuration information about a KDC.
Kerberos KDCオプションは、KDCに関する構成情報を提供するために使用されます。
The format of the Kerberos KDC Option is:
Kerberos KDCオプションの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_KRB_KDC | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Type| Port Number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| KDC IPv6 address +---------------+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
: :
: realm-name :
: (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code (16 bits): OPTION_KRB_KDC (78)
o オプションコード（16ビット）：OPTION_KRB_KDC（78）
o option-len (16 bits): 23 + the length of the realm-name field in octets.
o option-len（16ビット）：23 +オクテット単位の領域名フィールドの長さ。
o Priority (16 bits): see the description of the Weight field.
o 優先度（16ビット）：重みフィールドの説明を参照してください。
o Weight (16 bits): the Priority and Weight fields provide a hint to the client as to which KDC to select. The usage of the Priority and Weight values MUST follow the specification for DNS SRV [RFC2782].
o 重み（16ビット）：優先度および重みフィールドは、選択するKDCに関するヒントをクライアントに提供します。優先度と重みの値の使用は、DNS SRV [RFC2782]の仕様に従う必要があります。
o Transport Type (8 bits): The Transport Type specifies the transport protocol used for Kerberos. Kerberos [RFC4120] defines UDP and TCP transports. Exchanges over TCP are further described in [RFC5021], while the transport of Kerberos over Transport Layer Security (TLS) is described in [RFC6251].
o トランスポートタイプ（8ビット）：トランスポートタイプは、Kerberosに使用されるトランスポートプロトコルを指定します。 Kerberos [RFC4120]はUDPおよびTCPトランスポートを定義します。 TCPを介した交換については[RFC5021]でさらに説明されており、トランスポート層セキュリティ（TLS）を介したKerberosのトランスポートについては[RFC6251]で説明されています。
The transport type is defined below.
トランスポートタイプは以下で定義されます。
Value Transport Type
---- --------------
0 Reserved
1 UDP
2 TCP
3 TLS
4-254 Unassigned
255 Reserved
o Port Number (16 bits): the port number on which the KDC listens.
o ポート番号（16ビット）：KDCが待機するポート番号。
o KDC IPv6 address (128 bits): the IPv6 address of the KDC.
o KDC IPv6アドレス（128ビット）：KDCのIPv6アドレス。
o realm-name (variable): the name of the realm for which the specified KDC provides service. The encoding of the realm-name field MUST conform to the definition of "Realm" in Section 5.2.2 of RFC 4120 [RFC4120].
o レルム名（変数）：指定されたKDCがサービスを提供するレルムの名前。レルム名フィールドのエンコーディングは、RFC 4120 [RFC4120]のセクション5.2.2の「レルム」の定義に準拠する必要があります。
This section describes the operations of the client and server. It assumes that the client has been configured with a principal name.
このセクションでは、クライアントとサーバーの操作について説明します。クライアントがプリンシパル名で構成されていることを前提としています。
If a client requires a realm name, the client sends a DHCPv6 Option Request Option (ORO) specifying the Kerberos Default Realm Name Option. The DHCPv6 server responds with a Reply message containing a Kerberos Default Realm Name Option.
クライアントがレルム名を必要とする場合、クライアントはKerberosデフォルトレルム名オプションを指定してDHCPv6オプション要求オプション（ORO）を送信します。 DHCPv6サーバーは、Kerberosのデフォルトのレルム名オプションを含む応答メッセージで応答します。
If a client requires configuration parameters for a KDC, the client sends a DHCPv6 ORO specifying the Kerberos KDC Option. The client MAY include a Kerberos Principal Name Option. The client MAY include a Kerberos Realm Name Option.
クライアントがKDCの構成パラメーターを必要とする場合、クライアントはKerberos KDCオプションを指定してDHCPv6 OROを送信します。クライアントには、Kerberosプリンシパル名オプションが含まれる場合があります。クライアントには、Kerberosレルム名オプションが含まれる場合があります。
The DHCPv6 server replies with one or more sets of configuration parameters for a Kerberos KDC. If the client has specified either a Kerberos Principal Name Option or a Kerberos Realm Name Option, then the DHCPv6 server MAY use those parameters to select specific sets of configuration parameters.
DHCPv6サーバーは、Kerberos KDCの構成パラメーターの1つ以上のセットで応答します。クライアントがKerberosプリンシパル名オプションまたはKerberosレルム名オプションのいずれかを指定している場合、DHCPv6サーバーはこれらのパラメーターを使用して、特定の構成パラメーターセットを選択できます（MAY）。
Where the server replies with more than one set of configuration parameters, the usage of the Priority and Weight fields by the client MUST follow the specification for DNS SRV [RFC2782].
サーバーが複数の構成パラメーターのセットで応答する場合、クライアントによるPriorityおよびWeightフィールドの使用は、DNS SRV [RFC2782]の仕様に従う必要があります。
The client MAY include other options with data values as hints to the DHCPv6 server about parameter values the client would like to have returned; this is specified in Section 18.1.5 of RFC 3315 [RFC3315].
クライアントは、クライアントが返したいパラメータ値に関するDHCPv6サーバーへのヒントとして、データ値を持つ他のオプションを含めることができます（MAY）。これはRFC 3315 [RFC3315]のセクション18.1.5で指定されています。
When a client implements both the DNS method defined by Section 7.2.3.2 of [RFC4120] and the DHCP method defined by this document, the choice of method is determined by local policy. The administrator of the realm usually defines the method as part of the configuration of the client before the client is installed.
[RFC4120]のセクション7.2.3.2で定義されているDNSメソッドと、このドキュメントで定義されているDHCPメソッドの両方をクライアントが実装する場合、メソッドの選択はローカルポリシーによって決定されます。レルムの管理者は通常、クライアントをインストールする前に、クライアントの構成の一部としてメソッドを定義します。
When no criteria have been specified and the client could get the Kerberos information from either the DNS server or the DHCPv6 server, then the information from DNS SHOULD be preferred.
基準が指定されておらず、クライアントがDNSサーバーまたはDHCPv6サーバーのいずれかからKerberos情報を取得できる場合、DNSからの情報を優先する必要があります（SHOULD）。
IANA has assigned four option codes from the DHCPv6 Option Codes registry for the following:
IANAは、DHCPv6オプションコードレジストリから次の4つのオプションコードを割り当てました。
75 OPTION_KRB_PRINCIPAL_NAME
75 OPTION_KRB_PRINCIPAL_NAME
76 OPTION_KRB_REALM_NAME
76 OPTION_KRB_REALM_NAME
77 OPTION_KRB_DEFAULT_REALM_NAME
77 OPTION_KRB_DEFAULT_REALM_NAME
78 OPTION_KRB_KDC
78 OPTION_KRB_KDC
IANA has created the Kerberos Message Transport Types sub-registry, under the Kerberos Parameters registry. The initial entries are described in Section 3.4.
IANAは、Kerberosパラメータレジストリの下にKerberosメッセージ転送タイプサブレジストリを作成しました。最初のエントリはセクション3.4で説明されています。
The assignment of future entries is by "IETF Review" policy as described in BCP 26 [RFC5226]. Per that policy, a document specifies the symbolic name of such entries, which are assigned numeric codes by IANA once publication is approved.
今後のエントリの割り当ては、BCP 26 [RFC5226]で説明されている「IETFレビュー」ポリシーによるものです。そのポリシーに従って、ドキュメントはそのようなエントリのシンボル名を指定し、発行が承認されると、IANAによって数値コードが割り当てられます。
The security considerations in RFC 3315 [RFC3315] apply.
RFC 3315 [RFC3315]のセキュリティに関する考慮事項が適用されます。
DHCPv6 messages can be modified in transit. If an adversary modifies the response from a DHCPv6 server or injects its own response, a client may be led into contacting a malicious KDC. Both cases are categorized as a Denial-of-Service (DoS) attack. However, a malicious KDC does not know the shared key and so is unable to proceed any further with the exchange. If a client receives a response from such a KDC, the client can use the shared key to detect that the message originates from a malicious KDC.
DHCPv6メッセージは送信中に変更できます。攻撃者がDHCPv6サーバーからの応答を変更したり、自身の応答を挿入したりすると、クライアントが悪意のあるKDCに接続するよう誘導される可能性があります。どちらの場合も、サービス拒否（DoS）攻撃として分類されます。ただし、悪意のあるKDCは共有キーを認識していないため、交換をこれ以上進めることはできません。クライアントがそのようなKDCから応答を受信した場合、クライアントは共有キーを使用して、メッセージが悪意のあるKDCから発信されたことを検出できます。
A shared, unconfigured workstation may obtain its KDC information, and default realm, via DHCPv6. Such a workstation may not have a host or other service key, and thus it may be unable to validate the Ticket-Granting Ticket issued by the KDC. A modified DHCPv6 response would then result in the workstation talking to a malicious KDC, and the workstation would not be able to detect that this has happened. This in turn could allow access by unauthorized users.
共有された未構成のワークステーションは、DHCPv6を介してKDC情報とデフォルトのレルムを取得できます。このようなワークステーションにはホストまたはその他のサービスキーがない可能性があり、したがって、KDCによって発行されたチケット許可チケットを検証できない場合があります。 DHCPv6応答が変更されると、ワークステーションは悪意のあるKDCと通信し、ワークステーションはこれが発生したことを検出できなくなります。これにより、権限のないユーザーがアクセスできる可能性があります。
To minimize potential vulnerabilities, a client SHOULD use DHCPv6 authentication as defined in Section 21 of RFC 3315 [RFC3315].
潜在的な脆弱性を最小限に抑えるために、クライアントはRFC 3315 [RFC3315]のセクション21で定義されているDHCPv6認証を使用する必要があります（SHOULD）。
Kerberos information may be manually configured on the client before requesting information from DHCPv6. Manual configuration of the device SHOULD be preferred to configuration via the DHCPv6 server.
DHCPv6から情報を要求する前に、Kerberos情報をクライアントで手動で構成できます。デバイスの手動構成は、DHCPv6サーバーを介した構成よりも優先する必要があります（SHOULD）。
The authors are very grateful to Nobuo Okabe and Shigeya Suzuki. They contributed the explanation as to why DNS is inappropriate for some industry networks. Ted Lemon made many suggestions to improve DHCP aspects of this specification. Ken'ichi Kamada and Yukiyo Akisada contributed to the initial work on this document. Tom Petch helped to improve the readability of this document. The authors also thank Jeffrey Hutzelman, Kazunori Miyazawa, Kensuke Hosoya, Nicolas Williams, Nobumichi Ozoe, Sam Hartman, and Stephen Farrell. They made valuable comments and suggestions.
岡部信夫氏、鈴木重也氏に感謝します。彼らは、なぜDNSが一部の業界ネットワークに不適切であるかについての説明に貢献しました。 Ted Lemonは、この仕様のDHCPの側面を改善するために多くの提案をしました。このドキュメントの最初の作業には、鎌田健一氏と秋田幸代氏が貢献しました。 Tom Petchは、このドキュメントの読みやすさの向上に貢献しました。また、Jeffrey Hutzelman、宮沢和典、細谷健介、Nicolas Williams、Ozoe Nobumichi、Sam Hartman、Stephen Farrellにも感謝します。彼らは貴重なコメントや提案をしました。
[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月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[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月。
[RFC5021] Josefsson, S., "Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP", RFC 5021, August 2007.
[RFC5021] Josefsson、S。、「TCPを介した拡張Kerberosバージョン5キー配布センター（KDC）交換」、RFC 5021、2007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[PCARCH] CableLabs, "PacketCable 1.0(TM) Architecture Framework Technical Report", December 1999, <http://www.packetcable.com/downloads/specs/ pkt-tr-arch-v01-991201.pdf>.
[PCARCH] CableLabs、「PacketCable 1.0（TM）Architecture Framework Technical Report」、1999年12月、<http://www.packetcable.com/downloads/specs/pkt-tr-arch-v01-991201.pdf>。
[RFC3634] Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust, "Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option", RFC 3634, December 2003.
[RFC3634] Luehrs、K.、Woundy、R.、Bevilacqua、J.、and N. Davoust、 "Key Distribution Center（KDC）Server Address Sub-option for the Dynamic Host Configuration Protocol（DHCP）CableLabs Client Configuration（CCC）オプション」、RFC 3634、2003年12月。
[RFC6251] Josefsson, S., "Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol", RFC 6251, May 2011.
[RFC6251] Josefsson、S。、「トランスポート層セキュリティ（TLS）プロトコルを介したKerberosバージョン5の使用」、RFC 6251、2011年5月。
When no criteria have been specified and the client could get the Kerberos information from either the DNS server or the DHCPv6 server, then the information from DNS SHOULD be preferred. The following is an informational guide for the client in such an environment.
基準が指定されておらず、クライアントがDNSサーバーまたはDHCPv6サーバーのいずれかからKerberos情報を取得できる場合、DNSからの情報を優先する必要があります（SHOULD）。以下は、このような環境でのクライアント向けの情報ガイドです。
No Resp. or
+------------+ DNS Info. +-----------+ No Resp.
Start --> | Ask DHCP(1)| ---------> | Ask DNS(3)| ------>
+------------+ +-----------+ Terminate(4)
/ \ \
Only KRB / \ DNS and \ KRB Info.
Info. / \ KRB Info. \
/ \ \
| | |
| V |
V No Ans. +-----------+ KRB Info. V
Use Info. <-------- | Ask DNS(6)| ---------> Use Info.
from DHCP +-----------+ from DNS
(2), (7) (5), (8)
Abbreviations: Resp.: Response Info.: Information KRB : Kerberos
省略形：応答：応答情報：情報KRB：Kerberos
1) Initially, the client requests both DNS and Kerberos information from the DHCPv6 server.
1）最初に、クライアントはDHCPv6サーバーにDNSとKerberosの両方の情報を要求します。
2) If the DHCPv6 server replies with Kerberos information and not with DNS information, then the client uses that information.
2）DHCPv6サーバーがDNS情報ではなくKerberos情報で応答する場合、クライアントはその情報を使用します。
3) If the DHCPv6 server does not reply or replies with only DNS information, then the client requests Kerberos information from the DNS server.
3）DHCPv6サーバーが応答しないか、DNS情報のみで応答する場合、クライアントはDNSサーバーにKerberos情報を要求します。
4) If the client gets no response or no Kerberos information from the DNS server, then the client terminates the process.
4）クライアントがDNSサーバーから応答またはKerberos情報を取得しない場合、クライアントはプロセスを終了します。
5) If the client gets Kerberos information from the DNS server, then the client uses that information.
5）クライアントがDNSサーバーからKerberos情報を取得した場合、クライアントはその情報を使用します。
6) If, as the result of (1), the DHCPv6 server replies with both DNS and Kerberos information, then the client requests Kerberos information from the DNS server.
6）（1）の結果として、DHCPv6サーバーがDNS情報とKerberos情報の両方で応答した場合、クライアントはDNSサーバーにKerberos情報を要求します。
7) If the client gets no response from the DNS server, then the client uses the Kerberos information from the DHCPv6 server.
7）クライアントがDNSサーバーから応答を受信しない場合、クライアントはDHCPv6サーバーからのKerberos情報を使用します。
8) If, as the result of (6), the DNS server replies with Kerberos information, then the client uses the information from the DNS server and not that from the DHCPv6 server.
8）（6）の結果として、DNSサーバーがKerberos情報で応答する場合、クライアントはDHCPv6サーバーからの情報ではなく、DNSサーバーからの情報を使用します。
Authors' Addresses
著者のアドレス
Shoichi Sakane Cisco Systems 9-7-1 Akasaka Minato-ku, Tokyo 107-6227 Japan
しょいち さかね しｓこ Ｓｙｓてｍｓ ９ー７ー１ あかさか みなとーく、 ときょ １０７ー６２２７ じゃぱん
EMail: ssakane@cisco.com
Masahiro Ishiyama Toshiba Corporation 1, Komukai-toshiba-cho, Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
まさひろ いしやま としば こｒぽらちおん １、 こむかいーとしばーちょ、 さいわいーく、 かわさき、 かながわ ２１２ー８５８２ じゃぱん
EMail: masahiro.ishiyama@toshiba.co.jp