[要約] RFC 3645は、DNSのための秘密鍵トランザクション認証のための汎用セキュリティサービスアルゴリズム（GSS-TSIG）に関するものです。このRFCの目的は、DNSトランザクションの認証とセキュリティを向上させるための標準化を提供することです。
Network Working Group S. Kwan
Request for Comments: 3645 P. Garg
Updates: 2845 J. Gilroy
Category: Standards Track L. Esibov
J. Westhead
Microsoft Corp.
R. Hall
Lucent Technologies
October 2003
Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)
DNSの秘密キートランザクション認証のための一般的なセキュリティサービスアルゴリズム（GSS-TSIG）
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). This document updates RFC 2845.
DNS（TSIG）プロトコルのSecret Keyトランザクション認証は、DNSのトランザクションレベル認証を提供します。TSIGは、新しいアルゴリズムの定義を通じて拡張可能です。このドキュメントは、ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）（RFC2743）に基づくアルゴリズムを指定します。このドキュメントは、RFC 2845を更新します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . . 3
2.1. GSS Details. . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Modifications to the TSIG protocol (RFC 2845). . . . . . 4
3. Client Protocol Details. . . . . . . . . . . . . . . . . . . . 5
3.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 5
3.1.1. Call GSS_Init_sec_context. . . . . . . . . . . . . 6
3.1.2. Send TKEY Query to Server. . . . . . . . . . . . . 8
3.1.3. Receive TKEY Query-Response from Server. . . . . . 8
3.2. Context Established. . . . . . . . . . . . . . . . . . . 11
3.2.1. Terminating a Context. . . . . . . . . . . . . . . 11
4. Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12
4.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 12
4.1.1. Receive TKEY Query from Client . . . . . . . . . . 12
4.1.2. Call GSS_Accept_sec_context. . . . . . . . . . . . 12
4.1.3. Send TKEY Query-Response to Client . . . . . . . . 13
4.2. Context Established. . . . . . . . . . . . . . . . . . . 15
4.2.1. Terminating a Context. . . . . . . . . . . . . . . 15
5. Sending and Verifying Signed Messages. . . . . . . . . . . . . 15
5.1. Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15
5.2. Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16
6. Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
9. Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References. . . . . . . . . . . . . . . . . . 24
12.2. Informative References. . . . . . . . . . . . . . . . . 24
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845] protocol was developed to provide a lightweight authentication and integrity of messages between two DNS entities, such as client and server or server and server. TSIG can be used to protect dynamic update messages, authenticate regular message or to off-load complicated DNSSEC [RFC2535] processing from a client to a server and still allow the client to be assured of the integrity of the answers.
DNS（TSIG）[RFC2845]プロトコルのSecret Key Transaction認証は、クライアントとサーバー、サーバー、サーバーなどの2つのDNSエンティティ間のメッセージの軽量認証と整合性を提供するために開発されました。TSIGは、動的な更新メッセージを保護し、通常のメッセージを認証するか、クライアントからサーバーへの複雑なDNSSEC [RFC2535]処理をオフロードし、クライアントが回答の整合性を保証できるようにするために使用できます。
The TSIG protocol [RFC2845] is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) [RFC2743]. GSS-API is a framework that provides an abstraction of security to the application protocol developer. The security services offered can include authentication, integrity, and confidentiality.
TSIGプロトコル[RFC2845]は、新しいアルゴリズムの定義を通じて拡張可能です。このドキュメントは、一般的なセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）[RFC2743]に基づくアルゴリズムを指定します。GSS-APIは、アプリケーションプロトコル開発者にセキュリティの抽象化を提供するフレームワークです。提供されるセキュリティサービスには、認証、整合性、機密性が含まれます。
The GSS-API framework has several benefits:
GSS-APIフレームワークにはいくつかの利点があります。
* Mechanism and protocol independence. The underlying mechanisms that realize the security services can be negotiated on the fly and varied over time. For example, a client and server MAY use Kerberos [RFC1964] for one transaction, whereas that same server MAY use SPKM [RFC2025] with a different client.
* メカニズムとプロトコルの独立性。セキュリティサービスを実現する根本的なメカニズムは、その場で交渉し、時間とともに変化する可能性があります。たとえば、クライアントとサーバーは1つのトランザクションにKerberos [RFC1964]を使用する場合がありますが、同じサーバーは別のクライアントでSPKM [RFC2025]を使用する場合があります。
* The protocol developer is removed from the responsibility of creating and managing a security infrastructure. For example, the developer does not need to create new key distribution or key management systems. Instead the developer relies on the security service mechanism to manage this on its behalf.
* プロトコル開発者は、セキュリティインフラストラクチャの作成と管理の責任から削除されます。たとえば、開発者は新しいキーディストリビューションまたはキー管理システムを作成する必要はありません。代わりに、開発者はセキュリティサービスメカニズムに依存して、これを代表して管理します。
The scope of this document is limited to the description of an authentication mechanism only. It does not discuss and/or propose an authorization mechanism. Readers that are unfamiliar with GSS-API concepts are encouraged to read the characteristics and concepts section of [RFC2743] before examining this protocol in detail. It is also assumed that the reader is familiar with [RFC2845], [RFC2930], [RFC1034] and [RFC1035].
このドキュメントの範囲は、認証メカニズムのみの説明に限定されます。承認メカニズムについて議論および/または提案していません。GSS-APIの概念に不慣れな読者は、このプロトコルを詳細に調べる前に、[RFC2743]の特性と概念セクションを読むことをお勧めします。また、読者は[RFC2845]、[RFC2930]、[RFC1034]、[RFC1035]に精通していると想定されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
このドキュメントの「必須」、「必須」、「必須」、「必須」、「必要」、「推奨」、「推奨」、および「5月」は、BCP 14、RFC 2119 [RFC2119 [RFC2119]に記載されているように解釈されるべきです。]。
In GSS, client and server interact to create a "security context". The security context can be used to create and verify transaction signatures on messages between the two parties. A unique security context is required for each unique connection between client and server.
GSSでは、クライアントとサーバーが対話して「セキュリティコンテキスト」を作成します。セキュリティコンテキストを使用して、2つの当事者間のメッセージのトランザクション署名を作成および検証できます。クライアントとサーバーの間の一意の接続ごとに、一意のセキュリティコンテキストが必要です。
Creating a security context involves a negotiation between client and server. Once a context has been established, it has a finite lifetime for which it can be used to secure messages. Thus there are three states of a context associated with a connection:
セキュリティコンテキストの作成には、クライアントとサーバーの間の交渉が含まれます。コンテキストが確立されると、メッセージを保護するために使用できる有限寿命があります。したがって、接続に関連付けられたコンテキストの3つの状態があります。
+----------+
| |
V |
+---------------+ |
| Uninitialized | |
| | |
+---------------+ |
| |
V |
+---------------+ |
| Negotiating | |
| Context | |
+---------------+ |
| |
V |
+---------------+ |
| Context | |
| Established | |
+---------------+ |
| |
+----------+
Every connection begins in the uninitialized state.
すべての接続は、初期化された状態で始まります。
Client and server MUST be locally authenticated and have acquired default credentials before using this protocol as specified in Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
クライアントとサーバーは、RFC 2743 [RFC2743]のセクション1.1.1「資格情報」で指定されているように、このプロトコルを使用する前に、ローカルで認証され、デフォルトの資格情報を取得している必要があります。
The GSS-TSIG algorithm consists of two stages:
GSS-TSIGアルゴリズムは、2つの段階で構成されています。
I. Establish security context. The Client and Server use the GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate the tokens that they pass to each other using [RFC2930] as a transport mechanism.
I.セキュリティコンテキストを確立します。クライアントとサーバーは、gss_init_sec_contextとgss_accept_sec_context apisを使用して、[RFC2930]を輸送メカニズムとして使用して互いに渡るトークンを生成します。
II. Once the security context is established it is used to generate and verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. These signatures are exchanged by the Client and Server as a part of the TSIG records exchanged in DNS messages sent between the Client and Server, as described in [RFC2845].
ii。セキュリティコンテキストが確立されると、GSS_GETMICおよびGSS_VERIFYMIC APIを使用して署名を生成および検証するために使用されます。これらの署名は、[RFC2845]で説明されているように、クライアントとサーバー間で送信されたDNSメッセージで交換されるTSIGレコードの一部として、クライアントとサーバーによって交換されます。
Modification to RFC 2845 allows use of TSIG through signing server's response in an explicitly specified place in multi message exchange between two DNS entities even if client's request wasn't signed.
RFC 2845への変更により、クライアントの要求が署名されていなくても、2つのDNSエンティティ間のマルチメッセージ交換で明示的に指定された場所でサーバーの応答に署名することにより、TSIGを使用できます。
Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
具体的には、RFC 2845のセクション4.2は次のように変更する必要があります。
Replace: "The server MUST not generate a signed response to an unsigned request."
交換：「サーバーは、署名されていないリクエストに対する署名された応答を生成してはなりません。」
With: "The server MUST not generate a signed response to an unsigned request, except in case of response to client's unsigned TKEY query if secret key is established on server side after server processed client's query. Signing responses to unsigned TKEY queries MUST be explicitly specified in the description of an individual secret key establishment algorithm."
with：「サーバーは、サーバーの処理されたクライアントのクエリの後にサーバー側にシークレットキーが確立された場合、クライアントの未署名のTKEYクエリへの応答の場合を除き、署名されていないリクエストに対する署名された応答を生成してはなりません。個々の秘密の鍵設立アルゴリズムの説明で。」
A unique context is required for each server to which the client sends secure messages. A context is identified by a context handle. A client maintains a mapping of servers to handles:
クライアントが安全なメッセージを送信するサーバーごとに一意のコンテキストが必要です。コンテキストは、コンテキストハンドルによって識別されます。クライアントは、ハンドルへのサーバーのマッピングを維持しています。
(target_name, key_name, context_handle)
（Target_name、key_name、context_handle）
The value key_name also identifies a context handle. The key_name is the owner name of the TKEY and TSIG records sent between a client and a server to indicate to each other which context MUST be used to process the current request.
値key_nameは、コンテキストハンドルも識別します。key_nameは、クライアントとサーバーの間で送信されたtkeyおよびtsigレコードの所有者名であり、現在のリクエストを処理するためにどのコンテキストを使用する必要があるかを互いに示します。
DNS client and server MAY use various underlying security mechanisms to establish security context as described in sections 3 and 4. At the same time, in order to guarantee interoperability between DNS clients and servers that support GSS-TSIG it is REQUIRED that security mechanism used by client enables use of Kerberos v5 (see Section 9 for more information).
DNSクライアントとサーバーは、さまざまな基礎となるセキュリティメカニズムを使用して、セクション3と4で説明されているようにセキュリティコンテキストを確立することができます。同時に、GSS-TSIGをサポートするサーバー間の相互運用性を保証するためにクライアントは、Kerberos V5の使用を可能にします（詳細については、セクション9を参照）。
In GSS, establishing a security context involves the passing of opaque tokens between the client and the server. The client generates the initial token and sends it to the server. The server processes the token and if necessary, returns a subsequent token to the client. The client processes this token, and so on, until the negotiation is complete. The number of times the client and server exchange tokens depends on the underlying security mechanism. A completed negotiation results in a context handle.
GSSでは、セキュリティコンテキストを確立するには、クライアントとサーバーの間で不透明なトークンが渡されることが含まれます。クライアントは最初のトークンを生成し、サーバーに送信します。サーバーはトークンを処理し、必要に応じて後続のトークンをクライアントに返します。クライアントは、交渉が完了するまでこのトークンなどを処理します。クライアントとサーバーの交換トークンの回数は、基礎となるセキュリティメカニズムに依存します。完成した交渉により、コンテキストハンドルが得られます。
The TKEY resource record [RFC2930] is used as the vehicle to transfer tokens between client and server. The TKEY record is a general mechanism for establishing secret keys for use with TSIG. For more information, see [RFC2930].
TKEYリソースレコード[RFC2930]は、クライアントとサーバーの間にトークンを転送するための車両として使用されます。TKEYレコードは、TSIGで使用する秘密の鍵を確立するための一般的なメカニズムです。詳細については、[RFC2930]を参照してください。
To obtain the first token to be sent to a server, a client MUST call GSS_Init_sec_context API.
サーバーに送信される最初のトークンを取得するには、クライアントはGSS_INIT_SEC_CONTEXT APIを呼び出す必要があります。
The following input parameters MUST be used. The outcome of the call is indicated with the output values below. Consult Sections 2.2.1, "GSS_Init_sec_context call", of [RFC2743] for syntax definitions.
次の入力パラメーターを使用する必要があります。コールの結果は、以下の出力値で示されています。構文定義については、[RFC2743]の[RFC2743]のセクション2.2.1「GSS_INIT_SEC_CONTEXT CALL」を参照してください。
INPUTS CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use default"). Client MAY instead specify some other valid handle to its credentials. CONTEXT HANDLE input_context_handle = 0 INTERNAL NAME targ_name = "DNS@<target_server_name>" OBJECT IDENTIFIER mech_type = Underlying security mechanism chosen by implementers. To guarantee interoperability of the implementations of the GSS-TSIG mechanism client MUST specify a valid underlying security mechanism that enables use of Kerberos v5 (see Section 9 for more information). OCTET STRING input_token = NULL BOOLEAN replay_det_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE BOOLEAN deleg_req_flag = TRUE BOOLEAN sequence_req_flag = TRUE BOOLEAN anon_req_flag = FALSE BOOLEAN integ_req_flag = TRUE INTEGER lifetime_req = 0 (0 requests a default value). Client MAY instead specify another upper bound for the lifetime of the context to be established in seconds. OCTET STRING chan_bindings = Any valid channel bindings as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
入力資格情報ハンドルlachant_cred_handle = null（nullは「デフォルトの使用」を指定します）。代わりに、クライアントは資格情報に他の有効なハンドルを指定することができます。コンテキストハンドルinput_context_handle = 0内部名targ_name = "dns@<target_server_name>"オブジェクト識別子mech_type =実装者によって選択された基礎となるセキュリティメカニズム。GSS-TSIGメカニズムの実装の相互運用性を保証するには、クライアントがKerberos V5の使用を可能にする有効な基礎となるセキュリティメカニズムを指定する必要があります（詳細についてはセクション9を参照）。Octet String input_token = null boolean repray_det_req_flag = true boolean mutual_req_flag = true boolean deleg_req_flag = true boolean sequence_req_flag = True boolean anon_req_flag = false boolean integ_req_flag = true integime_req = 0（defauts a defauts）。代わりに、クライアントは、数秒で確立されるコンテキストの寿命の別の上限を指定することができます。Octet String chan_bindings = [RFC2743]のセクション1.1.6「チャネルバインディング」で指定されている有効なチャネルバインディング
OUTPUTS INTEGER major_status CONTEXT HANDLE output_context_handle OCTET STRING output_token BOOLEAN replay_det_state BOOLEAN mutual_state INTEGER minor_status OBJECT IDENTIFIER mech_type BOOLEAN deleg_state BOOLEAN sequence_state BOOLEAN anon_state BOOLEAN trans_state BOOLEAN prot_ready_state BOOLEAN conf_avail BOOLEAN integ_avail INTEGER lifetime_rec
outputs integer major_statusコンテキストハンドルoutput_context_handle string string output_token boolean repray_det_state boolean mutual_state integer minor_status識別子mech_type boolean deleg_state boolean sequence_state boolean anon_state boolean confean ger lifetime_rec
If returned major_status is set to one of the following errors:
返された場合、Major_Statusは次のエラーのいずれかに設定されています。
GSS_S_DEFECTIVE_TOKEN GSS_S_DEFECTIVE_CREDENTIAL GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_NO_CRED GSS_S_CREDENTIALS_EXPIRED GSS_S_BAD_BINDINGS GSS_S_OLD_TOKEN GSS_S_DUPLICATE_TOKEN GSS_S_NO_CONTEXT GSS_S_BAD_NAMETYPE GSS_S_BAD_NAME GSS_S_BAD_MECH GSS_S_FAILURE
gss_s_defective_token gss_s_defective_credential gss_s_bad_sig（gss_s_bad_mic）gss_s_s_s_s_s_s_s_s_s_s_s_s_expired gss_s_s_bad_bindings S_S_BAD_NAMETYPE GSS_S_BAD_NAME GSS_S_BAD_MECH GSS_S_FAILURE
then the client MUST abandon the algorithm and MUST NOT use the GSS-TSIG algorithm to establish this security context. This document does not prescribe which other mechanism could be used to establish a security context. Next time when this client needs to establish security context, the client MAY use GSS-TSIG algorithm.
その後、クライアントはアルゴリズムを放棄する必要があり、このセキュリティコンテキストを確立するためにGSS-TSIGアルゴリズムを使用してはなりません。このドキュメントでは、セキュリティコンテキストを確立するために他のメカニズムを使用できるかは規定されていません。次回、このクライアントがセキュリティコンテキストを確立する必要があるとき、クライアントはGSS-TSIGアルゴリズムを使用できます。
Success values of major_status are GSS_S_CONTINUE_NEEDED and GSS_S_COMPLETE. The exact success code is important during later processing.
Major_Statusの成功値はGSS_S_CONTINUE_NEEDEDおよびGSS_S_COMPLETEです。正確な成功コードは、後の処理中に重要です。
The values of replay_det_state and mutual_state indicate if the security package provides replay detection and mutual authentication, respectively. If returned major_status is GSS_S_COMPLETE AND one or both of these values are FALSE, the client MUST abandon this algorithm.
Replay_Det_Stateと相互_STATEの値は、セキュリティパッケージがそれぞれリプレイの検出と相互認証を提供するかどうかを示します。Major_StatusがGSS_S_Completeであり、これらの値の1つまたは両方がfalseである場合、クライアントはこのアルゴリズムを放棄する必要があります。
Client's behavior MAY depend on other OUTPUT parameters according to the policy local to the client.
クライアントの動作は、クライアントにローカルなポリシーに従って、他の出力パラメーターに依存する場合があります。
The handle output_context_handle is unique to this negotiation and is stored in the client's mapping table as the context_handle that maps to target_name.
ハンドルoutput_context_handleはこのネゴシエーションに固有のものであり、ターゲット_nameにマップするコンテキスト_handleとしてクライアントのマッピングテーブルに保存されます。
An opaque output_token returned by GSS_Init_sec_context is transmitted to the server in a query request with QTYPE=TKEY. The token itself will be placed in a Key Data field of the RDATA field in the TKEY resource record in the additional records section of the query. The owner name of the TKEY resource record set queried for and the owner name of the supplied TKEY resource record in the additional records section MUST be the same. This name uniquely identifies the security context to both the client and server, and thus the client SHOULD use a value which is globally unique as described in [RFC2930]. To achieve global uniqueness, the name MAY contain a UUID/GUID [ISO11578].
gss_init_sec_contextによって返される不透明なoutput_tokenは、qtype = tkeyを使用してクエリ要求でサーバーに送信されます。トークン自体は、クエリの追加レコードセクションのTKEYリソースレコードのRDATAフィールドのキーデータフィールドに配置されます。Tkey Resource Recordセットの所有者名はクエリされており、追加のレコードセクションで提供されたTKEYリソースレコードの所有者名は同じでなければなりません。この名前は、クライアントとサーバーの両方に対してセキュリティコンテキストを一意に識別するため、クライアントは[RFC2930]で説明されているようにグローバルに一意の値を使用する必要があります。グローバルな一意性を達成するために、名前にはUUID/GUID [ISO11578]が含まれている場合があります。
TKEY Record NAME = client-generated globally unique domain name string (as described in [RFC2930]) RDATA Algorithm Name = gss-tsig Mode = 3 (GSS-API negotiation - per [RFC2930]) Key Size = size of output_token in octets Key Data = output_token
TKEYレコード名=クライアントで生成されたグローバルに一意のドメイン名文字列（[RFC2930]で説明されている）RDATAアルゴリズム名= GSS-TSIGモード= 3（GSS-APIネゴシエーション-RFC2930]）data = output_token
The remaining fields in the TKEY RDATA, i.e., Inception, Expiration, Error, Other Size and Data Fields, MUST be set according to [RFC2930].
TKEY RDATAの残りのフィールド、つまり、開始、有効期限、エラー、その他のサイズ、およびデータフィールドは、[RFC2930]に従って設定する必要があります。
The query is transmitted to the server.
クエリはサーバーに送信されます。
Note: if the original client call to GSS_Init_sec_context returned any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then the client MUST NOT send TKEY query. Client's behavior in this case is described above in Section 3.1.1.
注：GSS_INIT_SEC_CONTEXTへの元のクライアント呼び出しがGSS_S_S_CONTINUE_NEEDEDまたはGSS_S_COMPLETE以外のMajoy_Statusを返した場合、クライアントはTKEYクエリを送信してはなりません。この場合のクライアントの動作は、上記のセクション3.1.1で説明します。
Upon the reception of the TKEY query the DNS server MUST respond according to the description in Section 4. This section specifies the behavior of the client after it receives the matching response to its query.
TKEYクエリを受信すると、DNSサーバーはセクション4の説明に従って応答する必要があります。このセクションでは、クライアントに対するクライアントの一致した応答を受信した後のクライアントの動作を指定します。
The next processing step depends on the value of major_status from the most recent call that client performed to GSS_Init_sec_context: either GSS_S_COMPLETE or GSS_S_CONTINUE.
次の処理ステップは、クライアントがGSS_INIT_SEC_CONTEXT：GSS_S_CompleteまたはGSS_S_CONTINUEのいずれかに実行した最新のコールからのMajor_Statusの値に依存します。
If the last call to GSS_Init_sec_context yielded a major_status value of GSS_S_COMPLETE and a non-NULL output_token was sent to the server, then the client side component of the negotiation is complete and the client is awaiting confirmation from the server.
GSS_INIT_SEC_CONTEXTへの最後の呼び出しがGSS_S_COMPLETEのMajor_Status値を生成し、非Null Output_Tokenがサーバーに送信された場合、交渉のクライアント側コンポーネントが完了し、クライアントはサーバーからの確認を待っています。
Confirmation is in the form of a query response with RCODE=NOERROR and with the last client supplied TKEY record in the answer section of the query. The response MUST be signed with a TSIG record. Note that the server is allowed to sign a response to unsigned client's query due to modification to the RFC 2845 specified in Section 2.2 above. The signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages. If the response is not signed, OR if the response is signed but the signature is invalid, then an attacker has tampered with the message in transit or has attempted to send the client a false response. In this case, the client MAY continue waiting for a response to its last TKEY query until the time period since the client sent last TKEY query expires. Such a time period is specified by the policy local to the client. This is a new option that allows the DNS client to accept multiple answers for one query ID and select one (not necessarily the first one) based on some criteria.
確認は、rcode = noerrorでクエリ応答の形式であり、最後のクライアントはクエリの回答セクションでtkeレコードを提供しました。応答は、TSIGレコードで署名する必要があります。上記のセクション2.2で指定されたRFC 2845の変更により、サーバーは署名されていないクライアントのクエリへの応答に署名することが許可されていることに注意してください。TSIGレコードの署名は、セクション5で詳述された手順を使用して、署名されたメッセージを送信および確認する必要があります。応答が署名されていない場合、または応答が署名されていないが署名が無効である場合、攻撃者は輸送中のメッセージを改ざんするか、クライアントに誤った応答を送信しようとしました。この場合、クライアントが最後のtkeyクエリを送信してからの期間まで、クライアントは最後のtkeyクエリへの応答を待ち続けることができます。このような期間は、クライアントにローカルなポリシーによって指定されます。これは、DNSクライアントが1つのクエリIDの複数の回答を受け入れ、いくつかの基準に基づいて1つ（必ずしも最初の回答ではない）を選択できる新しいオプションです。
If the signature is verified, the context state is advanced to Context Established. Proceed to section 3.2 for usage of the security context.
署名が検証されている場合、コンテキスト状態はコンテキストの確立まで進められます。セキュリティコンテキストの使用については、セクション3.2に進みます。
If the last call to GSS_Init_sec_context yielded a major_status value of GSS_S_CONTINUE_NEEDED, then the negotiation is not yet complete. The server will return to the client a query response with a TKEY record in the Answer section. If the DNS message error is not NO_ERROR or error field in the TKEY record is not 0 (i.e., no error), then the client MUST abandon this negotiation sequence. The client MUST delete an active context by calling GSS_Delete_sec_context providing the associated context_handle. The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1. To prevent infinite looping the number of attempts to establish a security context MUST be limited to ten or less.
GSS_INIT_SEC_CONTEXTの最後の呼び出しがGSS_S_S_CONTINUE_NEEDEDのMajor_Status値を生成した場合、交渉はまだ完了していません。サーバーは、回答セクションにTKEYレコードを使用してクライアントにクエリ応答を返します。DNSメッセージエラーがTKEYレコードのNO_ERRORまたはエラーフィールドが0ではない場合（つまり、エラーなし）、クライアントはこのネゴシエーションシーケンスを放棄する必要があります。クライアントは、関連するContext_handleを提供するGSS_DELETE_SEC_CONTEXTを呼び出すことにより、アクティブなコンテキストを削除する必要があります。クライアントは、セクション3.1で説明されているように、非初期化状態から始まる交渉シーケンスを繰り返すことができます。無限のループを防ぐには、セキュリティコンテキストを確立しようとする試みの数を10以下に制限する必要があります。
If the DNS message error is NO_ERROR and the error field in the TKEY record is 0 (i.e., no error), then the client MUST pass a token specified in the Key Data field in the TKEY resource record to GSS_Init_sec_context using the same parameters values as in previous call except values for CONTEXT HANDLE input_context_handle and OCTET STRING input_token as described below:
DNSメッセージエラーがNO_ERRORであり、TKEYレコードのエラーフィールドが0の場合（つまり、エラーなし）、クライアントはTKEYリソースレコードのキーデータフィールドで指定されたトークンに渡す必要があります。以下のinput_context_handleおよびoctet string input_tokenのコンテキストの値を除く前の呼び出しで：以下に説明します。
INPUTS CONTEXT HANDLE input_context_handle = context_handle (this is the context_handle corresponding to the key_name which is the owner name of the TKEY record in the answer section in the TKEY query response)
入力コンテキストハンドルinput_context_handle = context_handle（これは、tkey query応答の回答セクションのtkeyレコードの所有者名であるkey_nameに対応するコンテキスト_handleです）
OCTET STRING input_token = token from Key field of TKEY record
octet string input_token = tkeyレコードのキーフィールドからのトークン
Depending on the following OUTPUT values of GSS_Init_sec_context
gss_init_sec_contextの次の出力値に応じて
INTEGER major_status OCTET STRING output_token
integer major_status octet string output_token
the client MUST take one of the following actions:
クライアントは、次のアクションのいずれかを取得する必要があります。
If OUTPUT major_status is set to one of the following values:
出力Major_Statusが次の値のいずれかに設定されている場合：
GSS_S_DEFECTIVE_TOKEN GSS_S_DEFECTIVE_CREDENTIAL GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_NO_CRED GSS_S_CREDENTIALS_EXPIRED GSS_S_BAD_BINDINGS GSS_S_OLD_TOKEN GSS_S_DUPLICATE_TOKEN GSS_S_NO_CONTEXT GSS_S_BAD_NAMETYPE GSS_S_BAD_NAME GSS_S_BAD_MECH GSS_S_FAILURE
gss_s_defective_token gss_s_defective_credential gss_s_bad_sig（gss_s_bad_mic）gss_s_s_s_s_s_s_s_s_s_s_s_s_expired gss_s_s_bad_bindings S_S_BAD_NAMETYPE GSS_S_BAD_NAME GSS_S_BAD_MECH GSS_S_FAILURE
the client MUST abandon this negotiation sequence. This means that the client MUST delete an active context by calling GSS_Delete_sec_context providing the associated context_handle. The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1. To prevent infinite looping the number of attempts to establish a security context MUST be limited to ten or less.
クライアントは、この交渉シーケンスを放棄する必要があります。これは、Clientがgss_delete_sec_contextを呼び出して、関連するContext_handleを提供することにより、アクティブなコンテキストを削除する必要があることを意味します。クライアントは、セクション3.1で説明されているように、非初期化状態から始まる交渉シーケンスを繰り返すことができます。無限のループを防ぐには、セキュリティコンテキストを確立しようとする試みの数を10以下に制限する必要があります。
If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then client MUST act as described below.
出力major_statusがgss_s_continue_neededまたはgss_completeである場合、クライアントは以下に説明するように行動する必要があります。
If the response from the server was signed, and the OUTPUT major_status is GSS_S_COMPLETE,then the signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages. If the signature is invalid, then the client MUST abandon this negotiation sequence. This means that the client MUST delete an active context by calling GSS_Delete_sec_context providing the associated context_handle. The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1. To prevent infinite looping the number of attempts to establish a security context MUST be limited to ten or less.
サーバーからの応答が署名され、出力Major_StatusがGSS_S_Completeである場合、TSIGレコードの署名は、セクション5で詳述された手順を使用して検証し、署名メッセージを送信および検証する必要があります。署名が無効な場合、クライアントはこの交渉シーケンスを放棄する必要があります。これは、Clientがgss_delete_sec_contextを呼び出して、関連するContext_handleを提供することにより、アクティブなコンテキストを削除する必要があることを意味します。クライアントは、セクション3.1で説明されているように、非初期化状態から始まる交渉シーケンスを繰り返すことができます。無限のループを防ぐには、セキュリティコンテキストを確立しようとする試みの数を10以下に制限する必要があります。
If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet finished. The token output_token MUST be passed to the server in a TKEY record by repeating the negotiation sequence beginning with section 3.1.2. The client MUST place a limit on the number of continuations in a context negotiation to prevent endless looping. Such limit SHOULD NOT exceed value of 10.
Major_StatusがGSS_S_CONTINUE_NEEDEDの場合、交渉はまだ終了していません。トークンoutput_tokenは、セクション3.1.2で始まるネゴシエーションシーケンスを繰り返すことにより、TKEYレコードのサーバーに渡す必要があります。クライアントは、無限のループを防ぐために、コンテキストネゴシエーションに継続数に制限を設けなければなりません。そのような制限は10の値を超えてはなりません。
If major_status is GSS_S_COMPLETE and output_token is non-NULL, the client-side component of the negotiation is complete but the token output_token MUST be passed to the server by repeating the negotiation sequence beginning with section 3.1.2.
Major_StatusがGSS_S_COMPLETEおよびoutput_Tokenが非ヌルである場合、ネゴシエーションのクライアント側コンポーネントは完了しますが、セクション3.1.2で始まるネゴシエーションシーケンスを繰り返して、トークンoutput_tokenをサーバーに渡す必要があります。
If major_status is GSS_S_COMPLETE and output_token is NULL, context negotiation is complete. The context state is advanced to Context Established. Proceed to section 3.2 for usage of the security context.
Major_StatusがGSS_S_COMPLETEであり、output_Tokenがnullである場合、コンテキストネゴシエーションが完了します。コンテキスト状態は、コンテキストが確立されるまで進められます。セキュリティコンテキストの使用については、セクション3.2に進みます。
When context negotiation is complete, the handle context_handle MUST be used for the generation and verification of transaction signatures.
コンテキストネゴシエーションが完了した場合、ハンドルコンテキスト_handleを使用して、トランザクション署名の生成と検証に使用する必要があります。
The procedures for sending and receiving signed messages are described in section 5, Sending and Verifying Signed Messages.
署名されたメッセージを送信および受信するための手順は、署名されたメッセージを送信および検証するセクション5で説明されています。
When the client is not intended to continue using the established security context, the client SHOULD delete an active context by calling GSS_Delete_sec_context providing the associated context_handle, AND client SHOULD delete the established context on the DNS server by using TKEY RR with the Mode field set to 5, i.e., "key deletion" [RFC2930].
クライアントが確立されたセキュリティコンテキストを使用し続けることを意図していない場合、クライアントはGSS_DELETE_SEC_CONTEXTを呼び出して、関連するContext_Handleを提供するアクティブコンテキストを削除する必要があり、クライアントはモードフィールドを使用してTKEY RRを使用してDNSサーバーの確立されたコンテキストを削除する必要があります。5、つまり、「キー欠失」[RFC2930]。
As on the client-side, the result of a successful context negotiation is a context handle used in future generation and verification of the transaction signatures.
クライアント側と同様に、コンテキストネゴシエーションが成功した結果は、将来の生成とトランザクション署名の検証で使用されるコンテキストハンドルです。
A server MAY be managing several contexts with several clients. Clients identify their contexts by providing a key name in their request. The server maintains a mapping of key names to handles:
サーバーは、複数のクライアントといくつかのコンテキストを管理している場合があります。クライアントは、リクエストにキー名を提供することにより、コンテキストを特定します。サーバーは、キー名のハンドルへのマッピングを維持しています。
(key_name, context_handle)
（key_name、context_handle）
A server MUST recognize TKEY queries as security context negotiation messages.
サーバーは、TKEYクエリをセキュリティコンテキストネゴシエーションメッセージとして認識する必要があります。
Upon receiving a query with QTYPE = TKEY, the server MUST examine whether the Mode and Algorithm Name fields of the TKEY record in the additional records section of the message contain values of 3 and gss-tsig, respectively. If they do, then the (key_name, context_handle) mapping table is searched for the key_name matching the owner name of the TKEY record in the additional records section of the query. If the name is found in the table and the security context for this name is established and not expired, then the server MUST respond to the query with BADNAME error in the TKEY error field. If the name is found in the table and the security context is not established, the corresponding context_handle is used in subsequent GSS operations. If the name is found but the security context is expired, then the server deletes this security context, as described in Section 4.2.1, and interprets this query as a start of new security context negotiation and performs operations described in Section 4.1.2 and 4.1.3. If the name is not found, then the server interprets this query as a start of new security context negotiation and performs operations described in Section 4.1.2 and 4.1.3.
QTYPE = TKEYでクエリを受信すると、サーバーは、メッセージの追加レコードセクションにあるTKEYレコードのモードとアルゴリズム名のフィールドに、それぞれ3とGSS-TSIGの値を含むかどうかを調べる必要があります。もしそうなら、（key_name、context_handle）マッピングテーブルは、クエリの追加レコードセクションのtkeレコードの所有者名と一致するkey_nameを検索します。名前がテーブルにある場合、この名前のセキュリティコンテキストが確立され、有効期限が切れていない場合、サーバーはTKEYエラーフィールドのbadnameエラーでクエリに応答する必要があります。名前がテーブルにある場合、セキュリティコンテキストが確立されていない場合、対応するContext_handleは後続のGSS操作で使用されます。名前が見つかったがセキュリティコンテキストの有効期限が切れている場合、セクション4.2.1で説明されているように、サーバーはこのセキュリティコンテキストを削除し、このクエリを新しいセキュリティコンテキストネゴシエーションの開始として解釈し、セクション4.1.2および説明操作を実行します。4.1.3。名前が見つからない場合、サーバーはこのクエリを新しいセキュリティコンテキストネゴシエーションの開始として解釈し、セクション4.1.2および4.1.3で説明した操作を実行します。
The server performs its side of a context negotiation by calling GSS_Accept_sec_context. The following input parameters MUST be used. The outcome of the call is indicated with the output values below. Consult Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743 [RFC2743] for syntax definitions.
サーバーは、gss_accept_sec_contextを呼び出すことにより、コンテキストネゴシエーションの側面を実行します。次の入力パラメーターを使用する必要があります。コールの結果は、以下の出力値で示されています。構文定義については、RFC 2743 [RFC2743]のセクション2.2.2 "GSS_ACCEPT_SEC_CONTEXT呼び出し"を参照してください。
INPUTS CONTEXT HANDLE input_context_handle = 0 if new negotiation, context_handle matching key_name if ongoing negotiation OCTET STRING input_token = token specified in the Key field from TKEY RR (from Additional records Section of the client's query)
入力コンテキストハンドルinput_context_handle = 0新しいネゴシエーションの場合、context_handle key_name key_nameが進行中のネゴシエーションの場合、octet string input_token = tkey RRのキーフィールドで指定されています（クライアントのクエリの追加レコードセクションから）
CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use default"). Server MAY instead specify some other valid handle to its credentials. OCTET STRING chan_bindings = Any valid channel bindings as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
資格情報ハンドルAcceptor_cred_handle = null（nullは「デフォルトを使用する」を指定します）。代わりに、サーバーは資格情報に他の有効なハンドルを指定することができます。Octet String chan_bindings = [RFC2743]のセクション1.1.6「チャネルバインディング」で指定されている有効なチャネルバインディング
OUTPUTS INTEGER major_status CONTEXT_HANDLE output_context_handle OCTET STRING output_token INTEGER minor_status INTERNAL NAME src_name OBJECT IDENTIFIER mech_type BOOLEAN deleg_state BOOLEAN mutual_state BOOLEAN replay_det_state BOOLEAN sequence_state BOOLEAN anon_state BOOLEAN trans_state BOOLEAN prot_ready_state BOOLEAN conf_avail BOOLEAN integ_avail INTEGER lifetime_rec CONTEXT_HANDLE delegated_cred_handle
outputs integer major_status context_handle output_context_handle octet string output_token integer minor_status internal name src_name deleg_state boolean mech_tape boolean boolean repray_det_state boolean trans_state boolean boolean integ_avail integer lifetime_rec context_handle delegated_cred_handle
If this is the first call to GSS_Accept_sec_context in a new negotiation, then output_context_handle is stored in the server's key-mapping table as the context_handle that maps to the name of the TKEY record.
これが新しいネゴシエーションでGSS_ACCEPT_SEC_CONTEXTの最初の呼び出しである場合、output_context_handleは、tkeレコードの名前にマップするContext_handleとしてサーバーのキーマッピングテーブルに保存されます。
The server MUST respond to the client with a TKEY query response with RCODE = NOERROR, that contains a TKEY record in the answer section.
サーバーは、rcode = noerrorを使用したtkey query応答でクライアントに応答する必要があります。
If OUTPUT major_status is one of the following errors the error field in the TKEY record set to BADKEY.
Output Major_statusが次のエラーの1つである場合、Tkey RecordのエラーフィールドはBadkeyに設定されています。
GSS_S_DEFECTIVE_TOKEN GSS_S_DEFECTIVE_CREDENTIAL GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_DUPLICATE_TOKEN GSS_S_OLD_TOKEN GSS_S_NO_CRED GSS_S_CREDENTIALS_EXPIRED GSS_S_BAD_BINDINGS GSS_S_NO_CONTEXT GSS_S_BAD_MECH GSS_S_FAILURE
gss_s_defective_token gss_s_defective_credential gss_s_bad_sig（gss_s_bad_mic）gss_s_s_s_s_s_s_s_s_s_s_s_token gss_s_no_cred gss_s_credentions_nedentions_nexedsedentys_nexexpedpedpedpedpeads_noedsedentic S_S_BAD_MECH GSS_S_FAILURE
If OUTPUT major_status is set to GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED then server MUST act as described below.
出力Major_StatusがGSS_S_COMPLETEまたはGSS_S_CONTINUE_NEEDEDに設定されている場合、サーバーは以下に説明するように動作する必要があります。
If major_status is GSS_S_COMPLETE the server component of the negotiation is finished. If output_token is non-NULL, then it MUST be returned to the client in a Key Data field of the RDATA in TKEY. The error field in the TKEY record is set to NOERROR. The message MUST be signed with a TSIG record as described in section 5, Sending and Verifying Signed Messages. Note that server is allowed to sign a response to unsigned client's query due to modification to the RFC 2845 specified in Section 2.2 above. The context state is advanced to Context Established. Section 4.2 discusses the usage of the security context.
Major_StatusがGSS_S_Completeの場合、ネゴシエーションのサーバーコンポーネントが終了します。output_tokenが非ヌルの場合、tkeyのrdataのキーデータフィールドでクライアントに返す必要があります。TKEYレコードのエラーフィールドは、NoErrorに設定されています。メッセージは、セクション5で説明されているように、署名されたメッセージを送信および検証するTSIGレコードで署名する必要があります。上記のセクション2.2で指定されたRFC 2845の変更により、サーバーは署名されていないクライアントのクエリへの応答に署名することが許可されていることに注意してください。コンテキスト状態は、コンテキストが確立されるまで進められます。セクション4.2では、セキュリティコンテキストの使用について説明します。
If major_status is GSS_S_COMPLETE and output_token is NULL, then the TKEY record received from the client MUST be returned in the Answer section of the response. The message MUST be signed with a TSIG record as described in section 5, Sending and Verifying Signed Messages. Note that server is allowed to sign a response to unsigned client's query due to modification to the RFC 2845 specified in section 2.2 above. The context state is advanced to Context Established. Section 4.2 discusses the usage of the security context.
Major_StatusがGSS_S_Completeおよびoutput_Tokenがnullである場合、クライアントから受け取ったTkeレコードは、応答の回答セクションで返される必要があります。メッセージは、セクション5で説明されているように、署名されたメッセージを送信および検証するTSIGレコードで署名する必要があります。上記のセクション2.2で指定されたRFC 2845の変更により、サーバーは署名されていないクライアントのクエリへの応答に署名することが許可されていることに注意してください。コンテキスト状態は、コンテキストが確立されるまで進められます。セクション4.2では、セキュリティコンテキストの使用について説明します。
If major_status is GSS_S_CONTINUE_NEEDED, the server component of the negotiation is not yet finished. The server responds to the TKEY query with a standard query response, placing in the answer section a TKEY record containing output_token in the Key Data RDATA field. The error field in the TKEY record is set to NOERROR. The server MUST limit the number of times that a given context is allowed to repeat, to prevent endless looping. Such limit SHOULD NOT exceed value of 10.
Major_StatusがGSS_S_CONTINUE_NEEDEDである場合、ネゴシエーションのサーバーコンポーネントはまだ終了していません。サーバーは、標準のクエリ応答を使用してTKEYクエリに応答し、Key Data RDATAフィールドにoutput_Tokenを含むTKEYレコードを回答セクションに配置します。TKEYレコードのエラーフィールドは、NoErrorに設定されています。サーバーは、無限のループを防ぐために、特定のコンテキストが繰り返されることが許可されている回数を制限する必要があります。そのような制限は10の値を超えてはなりません。
In all cases, except if major_status is GSS_S_COMPLETE and output_token is NULL, other TKEY record fields MUST contain the following values:
すべての場合において、Major_StatusがGSS_S_COMPLETEおよびoutput_Tokenがnullである場合を除き、他のtkeyレコードフィールドには次の値を含める必要があります。
NAME = key_name RDATA Algorithm Name = gss-tsig Mode = 3 (GSS-API negotiation - per [RFC2930]) Key Size = size of output_token in octets
name = key_name rdata algorithm name = gss-tsig mode = 3（gss-apiネゴシエーション - [rfc2930]）キーサイズ=オクテットのoutput_tokenのサイズ
The remaining fields in the TKEY RDATA, i.e., Inception, Expiration, Error, Other Size and Data Fields, MUST be set according to [RFC2930].
TKEY RDATAの残りのフィールド、つまり、開始、有効期限、エラー、その他のサイズ、およびデータフィールドは、[RFC2930]に従って設定する必要があります。
When context negotiation is complete, the handle context_handle is used for the generation and verification of transaction signatures. The handle is valid for a finite amount of time determined by the underlying security mechanism. A server MAY unilaterally terminate a context at any time (see section 4.2.1).
コンテキストネゴシエーションが完了すると、ハンドルコンテキスト_handleがトランザクション署名の生成と検証に使用されます。ハンドルは、基礎となるセキュリティメカニズムによって決定される有限の時間に対して有効です。サーバーは、いつでもコンテキストを一方的に終了する場合があります（セクション4.2.1を参照）。
Server SHOULD limit the amount of memory used to cache established contexts.
サーバーは、確立されたコンテキストをキャッシュするために使用されるメモリの量を制限する必要があります。
The procedures for sending and receiving signed messages are given in section 5, Sending and Verifying Signed Messages.
署名されたメッセージを送信および受信するための手順は、署名されたメッセージを送信および検証するセクション5に記載されています。
A server can terminate any established context at any time. The server MAY hint to the client that the context is being deleted by including a TKEY RR in a response with the Mode field set to 5, i.e., "key deletion" [RFC2930]. An active context is deleted by calling GSS_Delete_sec_context providing the associated context_handle.
サーバーは、いつでも確立されたコンテキストを終了できます。サーバーは、5に設定されたモードフィールドでTKEY RRを含めることにより、コンテキストが削除されていることをクライアントに示唆する場合があります。つまり、「キー欠失」[RFC2930]。Active Context_Handleを提供するGSS_DELETE_SEC_CONTEXTを呼び出すことにより、アクティブなコンテキストが削除されます。
The procedure for sending a signature-protected message is specified in [RFC2845]. The data to be passed to the signature routine includes the whole DNS message with specific TSIG variables appended. For the exact format, see [RFC2845]. For this protocol, use the following TSIG variable values:
署名保護されたメッセージを送信する手順は、[RFC2845]で指定されています。署名ルーチンに渡されるデータには、特定のTSIG変数が追加されたDNSメッセージ全体が含まれます。正確な形式については、[RFC2845]を参照してください。このプロトコルでは、次のTSIG変数値を使用します。
TSIG Record NAME = key_name that identifies this context RDATA Algorithm Name = gss-tsig
tsigレコード名=このコンテキストを識別するkey_name rdata algorithm name = gss-tsig
Assign the remaining fields in the TSIG RDATA appropriate values as described in [RFC2845].
[RFC2845]で説明されているように、TSIG RDATA適切な値に残りのフィールドを割り当てます。
The signature is generated by calling GSS_GetMIC. The following input parameters MUST be used. The outcome of the call is indicated with the output values specified below. Consult Sections 2.3.1 "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions.
署名は、gss_getmicを呼び出すことによって生成されます。次の入力パラメーターを使用する必要があります。コールの結果は、以下に指定された出力値で示されています。構文定義については、RFC 2743 [RFC2743]のセクション2.3.1「GSS_GETMICコール」を参照してください。
INPUTS CONTEXT HANDLE context_handle = context_handle for key_name OCTET STRING message = outgoing message plus TSIG variables (per [RFC2845]) INTEGER qop_req = 0 (0 requests a default value). Caller MAY instead specify other valid value (for details see Section 1.2.4 in [RFC2743])
入力コンテキストハンドルContext_handle = context_handle for key_name octet string message = inovering message plus tsig変数（[rfc2845]）integer qop_req = 0（0はデフォルト値を要求します）。代わりに発信者は他の有効な値を指定することができます（詳細については、[RFC2743]のセクション1.2.4を参照）
OUTPUTS INTEGER major_status INTEGER minor_status OCTET STRING per_msg_token
integer major_status integer minor_status octet string per_msg_token
If major_status is GSS_S_COMPLETE, then signature generation succeeded. The signature in per_msg_token is inserted into the Signature field of the TSIG RR and the message is transmitted.
Major_StatusがGSS_S_Completeの場合、署名生成が成功しました。per_msg_tokenの署名はTSIG RRの署名フィールドに挿入され、メッセージが送信されます。
If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED or GSS_S_FAILURE the caller MUST delete the security context, return to the uninitialized state and SHOULD negotiate a new security context, as described above in Section 3.1
Major_statusがGSS_S_CONTEXT_EXPIRED、GSS_S_CREDENTIALS_EXPIREDまたはGSS_S_FAILUREである場合、発信者はセキュリティコンテキストを削除し、初心者化された状態に戻り、セクション3.1で説明するように新しいセキュリティコンテキストを交渉する必要があります。
If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry for key_name from the (target_ name, key_name, context_handle) mapping table, return to the uninitialized state and SHOULD negotiate a new security context, as described above in Section 3.1
major_statusがGSS_S_S_NO_CONTEXTの場合、発信者は（ターゲット_ name、key_name、context_handle）マッピングテーブルからkey_nameのエントリを削除する必要があります。
If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the GSS_GetMIC call with allowed QOP value. The number of such repetitions MUST be limited to prevent infinite loops.
Major_StatusがGSS_S_BAD_QOPの場合、発信者は許可されたQOP値でGSS_GETMIC呼び出しを繰り返す必要があります。そのような繰り返しの数は、無限のループを防ぐために制限する必要があります。
The procedure for verifying a signature-protected message is specified in [RFC2845].
署名保護されたメッセージを確認する手順は、[RFC2845]で指定されています。
The NAME of the TSIG record determines which context_handle maps to the context that MUST be used to verify the signature. If the NAME does not map to an established context, the server MUST send a standard TSIG error response to the client indicating BADKEY in the TSIG error field (as described in [RFC2845]).
TSIGレコードの名前は、署名を検証するために使用する必要があるコンテキストにどのContext_handleマップをマップしますか。名前が確立されたコンテキストにマッピングされない場合、サーバーは、TSIGエラーフィールドでバッドキーを示すクライアントに標準のTSIGエラー応答を送信する必要があります（[RFC2845]で説明されています）。
For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
GSSアルゴリズムの場合、signatureはgss_verifymicを使用して検証されます。
INPUTS CONTEXT HANDLE context_handle = context_handle for key_name OCTET STRING message = incoming message plus TSIG variables (per [RFC2845]) OCTET STRING per_msg_token = Signature field from TSIG RR
入力コンテキストハンドルContext_handle = context_handle for key_name octet string message = incoming message plus tsig変数（[rfc2845]）octet string per_msg_token = tsig rrの署名フィールド
OUTPUTS INTEGER major_status INTEGER minor_status INTEGER qop_state
integer major_status integer minor_status integer qop_state
If major_status is GSS_S_COMPLETE, the signature is authentic and the message was delivered intact. Per [RFC2845], the timer values of the TSIG record MUST also be valid before considering the message to be authentic. The caller MUST not act on the request or response in the message until these checks are verified.
Major_statusがGSS_S_Completeの場合、署名は本物であり、メッセージはそのまま配信されます。[RFC2845]に従って、TSIGレコードのタイマー値も、メッセージを本物であると考える前に有効でなければなりません。発信者は、これらのチェックが検証されるまで、メッセージ内のリクエストまたは応答に基づいて行動してはなりません。
When a server is processing a client request, the server MUST send a standard TSIG error response to the client indicating BADKEY in the TSIG error field as described in [RFC2845], if major_status is set to one of the following values
サーバーがクライアント要求を処理している場合、サーバーは[RFC2845]で説明されているように、TSIGエラーフィールドでバッドキーを示すクライアントに標準のTSIGエラー応答を送信する必要があります。
GSS_S_DEFECTIVE_TOKEN GSS_S_BAD_SIG (GSS_S_BAD_MIC) GSS_S_DUPLICATE_TOKEN GSS_S_OLD_TOKEN GSS_S_UNSEQ_TOKEN GSS_S_GAP_TOKEN GSS_S_CONTEXT_EXPIRED GSS_S_NO_CONTEXT GSS_S_FAILURE
gss_s_defective_token gss_s_bad_sig（gss_s_bad_mic）gss_s_duplicate_token gss_s_old_token gss_s_unseq_token gss_s_s_gap_token gss_s_context_context_expeared gs_s_s_contex
If the timer values of the TSIG record are invalid, the message MUST NOT be considered authentic. If this error checking fails when a server is processing a client request, the appropriate error response MUST be sent to the client according to [RFC2845].
TSIGレコードのタイマー値が無効である場合、メッセージは本物と見なされてはなりません。サーバーがクライアント要求を処理しているときにこのエラーチェックが失敗した場合、[RFC2845]に従って適切なエラー応答をクライアントに送信する必要があります。
This Section describes an example where a Client, client.example.com, and a Server, server.example.com, establish a security context according to the algorithm described above.
このセクションでは、クライアント、client.example.com、およびserver、server.example.comが、上記のアルゴリズムに従ってセキュリティコンテキストを確立する例について説明します。
I. Client initializes security context negotiation
I.クライアントは、セキュリティコンテキストのネゴシエーションを初期化します
To establish a security context with a server, server.example.com, the Client calls GSS_Init_sec_context with the following parameters. (Note that some INPUT and OUTPUT parameters not critical for this algorithm are not described in this example.)
サーバーServer.example.comでセキュリティコンテキストを確立するには、クライアントは次のパラメーターを使用してGSS_INIT_SEC_CONTEXTを呼び出します。（このアルゴリズムにとって重要ではない入出力パラメーターと出力パラメーターは、この例では説明されていないことに注意してください。）
CONTEXT HANDLE input_context_handle = 0 INTERNAL NAME targ_name = "DNS@server.example.com" OCTET STRING input_token = NULL BOOLEAN replay_det_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE
コンテキストハンドルinput_context_handle = 0 internal name targ_name = "dns@server.example.com" input_token = null boolean replay_det_req_flag = true boolean mutual_req_flag = true
The OUTPUTS parameters returned by GSS_Init_sec_context include INTEGER major_status = GSS_S_CONTINUE_NEEDED CONTEXT HANDLE output_context_handle context_handle OCTET STRING output_token output_token BOOLEAN replay_det_state = TRUE BOOLEAN mutual_state = TRUE
gss_init_sec_contextによって返される出力パラメーターにはinteger major_status = gss_continue_needed contextハンドルinteger major_status = gss_continue_needed handle output_context_handle context_handle octet string output_token output_token boolean repreay_det_state =真のboolean
Client verifies that replay_det_state and mutual_state values are TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a success OUTPUT major_status value, client stores context_handle that maps to "DNS@server.example.com" and proceeds to the next step.
クライアントは、replay_det_stateとuntulal_state値が真であることを確認します。Major_statusはGSS_S_S_CONTINUE_NEEDED（これが成功したMajor_Status値であるため、クライアントが「dns@server.example.com」にマップするContext_handleを保存し、次のステップに進みます。
II. Client sends a query with QTYPE = TKEY to server
ii。クライアントはqtype = tkeyでクエリをサーバーに送信します
Client sends a query with QTYPE = TKEY for a client-generated globally unique domain name string, 789.client.example.com.server.example.com. Query contains a TKEY record in its Additional records section with the following fields. (Note that some fields not specific to this algorithm are not specified.)
クライアントは、クライアントで生成されたグローバルに一意のドメイン名文字列、789.client.example.com.server.example.comのqtype = tkeyでクエリを送信します。クエリには、次のフィールドを含む追加のレコードセクションにTKEYレコードが含まれています。（このアルゴリズムに固有のない一部のフィールドは指定されていないことに注意してください。）
NAME = 789.client.example.com.server.example.com. RDATA Algorithm Name = gss-tsig Mode = 3 (GSS-API negotiation - per [RFC2930]) Key Size = size of output_token in octets Key Data = output_token
name = 789.client.example.com.server.example.com。RDATAアルゴリズム名= GSS-TSIGモード= 3（GSS-APIネゴシエーション - [RFC2930]）キーサイズ=オクテットのoutput_tokenキーデータ= output_token
After the key_name 789.client.example.com.server.example.com. is generated it is stored in the client's (target_name, key_name, context_handle) mapping table.
key_name 789.client.example.com.server.example.comの後。生成されますそれはクライアントの（target_name、key_name、context_handle）マッピングテーブルに保存されます。
III. Server receives a query with QTYPE = TKEY
iii。サーバーはQTYPE = TKEYでクエリを受信します
When server receives a query with QTYPE = TKEY, the server verifies that Mode and Algorithm fields in the TKEY record in the Additional records section of the query are set to 3 and "gss-tsig" respectively. It finds that the key_name 789.client.example.com.server.example.com. is not listed in its (key_name, context_handle) mapping table.
サーバーがQTYPE = TKEYでクエリを受信すると、サーバーは、クエリの追加レコードセクションのTKEYレコードのモードとアルゴリズムフィールドをそれぞれ3と「GSS-TSIG」に設定します。key_name 789.client.example.com.server.example.comであることがわかります。（key_name、context_handle）マッピングテーブルにリストされていません。
IV. Server calls GSS_Accept_sec_context
IV。サーバーはgss_accept_sec_contextを呼び出します
To continue security context negotiation server calls GSS_Accept_sec_context with the following parameters. (Note that some INPUT and OUTPUT parameters not critical for this algorithm are not described in this example.)
セキュリティコンテキストネゴシエーションサーバーを継続するには、次のパラメーターを使用してGSS_ACCEPT_SEC_CONTEXTを呼び出します。（このアルゴリズムにとって重要ではない入出力パラメーターと出力パラメーターは、この例では説明されていないことに注意してください。）
INPUTS CONTEXT HANDLE input_context_handle = 0 OCTET STRING input_token = token specified in the Key field from TKEY RR (from Additional records section of the client's query)
入力コンテキストハンドルinput_context_handle = 0 octet string input_token = tkey rrのキーフィールドで指定されたトークン（クライアントのクエリの追加レコードセクションから）
The OUTPUTS parameters returned by GSS_Accept_sec_context include INTEGER major_status = GSS_S_CONTINUE_NEEDED CONTEXT_HANDLE output_context_handle context_handle OCTET STRING output_token output_token
gss_accept_sec_contextによって返される出力パラメーターにはinteger major_status = gss_s_continue_needed context_handle output_context_handle context_handle octet string_token output_token
Server stores the mapping of the 789.client.example.com.server.example.com. to OUTPUT context_handle in its (key_name, context_handle) mapping table.
サーバーは、789.client.example.com.server.example.comのマッピングを保存します。（key_name、context_handle）マッピングテーブルにcontext_handleを出力します。
V. Server responds to the TKEY query
V.サーバーはTKEYクエリに応答します
Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's call to GSS_Accept_sec_context, the server responds to the TKEY query placing in the answer section a TKEY record containing output_token in the Key Data RDATA field. The error field in the TKEY record is set to 0. The RCODE in the query response is set to NOERROR.
Major_status = gss_s_continue_needed gss_accept_sec_contextへの最後のサーバーの呼び出しでは、サーバーは、Key Data rdataフィールドにoutput_tokenを含むtkeyレコードに配置されたtkeyクエリに応答します。TKEYレコードのエラーフィールドは0に設定されています。クエリ応答のrcodeはnoerrorに設定されています。
VI. Client processes token returned by server
vi。クライアントプロセスサーバーによって返されたクライアントプロセストークン
When the client receives the TKEY query response from the server, the client calls GSS_Init_sec_context with the following parameters. (Note that some INPUT and OUTPUT parameters not critical for this algorithm are not described in this example.)
クライアントがサーバーからTKEYクエリ応答を受信すると、クライアントは次のパラメーターを使用してGSS_INIT_SEC_CONTEXTを呼び出します。（このアルゴリズムにとって重要ではない入出力パラメーターと出力パラメーターは、この例では説明されていないことに注意してください。）
CONTEXT HANDLE input_context_handle = the context_handle stored in the client's mapping table entry (DNS@server.example.com., 789.client.example.com.server.example.com., context_handle) INTERNAL NAME targ_name = "DNS@server.example.com" OCTET STRING input_token = token from Key field of TKEY record from the Answer section of the server's response BOOLEAN replay_det_req_flag = TRUE BOOLEAN mutual_req_flag = TRUE
コンテキストハンドルinput_context_handle =クライアントのマッピングテーブルエントリ（dns@server.example.com。、789.client.example.com.server.example.com。、context_handle）内部名targ_name = "dns@server.example.com "Octet string input_token = tkeyレコードのキーフィールドからのトークンサーバーの応答の回答セクションBoolean Replay_det_req_flag = true boolean mutual_req_flag = true
The OUTPUTS parameters returned by GSS_Init_sec_context include INTEGER major_status = GSS_S_COMPLETE CONTEXT HANDLE output_context_handle = context_handle OCTET STRING output_token = output_token BOOLEAN replay_det_state = TRUE BOOLEAN mutual_state = TRUE
gss_init_sec_contextによって返される出力パラメーターにはinteger major_status = gss_completeコンテキストハンドルinteger major_status = gss_context_handle = context_handle octet string output_token = output_token boolean replay_det_state = troo
Since the major_status is set to GSS_S_COMPLETE the client side security context is established, but since the output_token is not NULL client MUST send a TKEY query to the server as described below.
Major_StatusはGSS_S_Completeに設定されているため、クライアント側のセキュリティコンテキストが確立されますが、output_tokenはnullクライアントではないため、以下に説明するようにサーバーにtkeyクエリを送信する必要があります。
VII. Client sends a query with QTYPE = TKEY to server
vii。クライアントはqtype = tkeyでクエリをサーバーに送信します
Client sends to the server a TKEY query for the 789.client.example.com.server.example.com. name. Query contains a TKEY record in its Additional records section with the following fields. (Note that some INPUT and OUTPUT parameters not critical to this algorithm are not described in this example.)
クライアントは、789.client.example.com.server.example.comのtkeyクエリをサーバーに送信します。名前。クエリには、次のフィールドを含む追加のレコードセクションにTKEYレコードが含まれています。（このアルゴリズムにとって重要ではないいくつかの入力パラメーターと出力パラメーターは、この例では説明されていないことに注意してください。）
NAME = 789.client.example.com.server.example.com. RDATA Algorithm Name = gss-tsig Mode = 3 (GSS-API negotiation - per [RFC2930]) Key Size = size of output_token in octets Key Data = output_token
name = 789.client.example.com.server.example.com。RDATAアルゴリズム名= GSS-TSIGモード= 3（GSS-APIネゴシエーション - [RFC2930]）キーサイズ=オクテットのoutput_tokenキーデータ= output_token
VIII. Server receives a TKEY query
viii。サーバーはtkeyクエリを受信します
When the server receives a TKEY query, the server verifies that Mode and Algorithm fields in the TKEY record in the Additional records section of the query are set to 3 and gss-tsig, respectively. It finds that the key_name 789.client.example.com.server.example.com. is listed in its (key_name, context_handle) mapping table.
サーバーがTKEYクエリを受信すると、サーバーは、クエリの追加レコードセクションのTKEYレコードのモードとアルゴリズムフィールドをそれぞれ3およびGSS-TSIGに設定します。key_name 789.client.example.com.server.example.comであることがわかります。（key_name、context_handle）マッピングテーブルにリストされています。
IX. Server calls GSS_Accept_sec_context
ix。サーバーはgss_accept_sec_contextを呼び出します
To continue security context negotiation server calls GSS_Accept_sec_context with the following parameters (Note that some INPUT and OUTPUT parameters not critical for this algorithm are not described in this example)
セキュリティコンテキストネゴシエーションサーバーを継続するには、次のパラメーターを使用してGSS_ACCEPT_SEC_CONTEXTを呼び出します（このアルゴリズムにとって重要ではない入力パラメーターと出力パラメーターは、この例で説明されていないことに注意してください）
INPUTS CONTEXT HANDLE input_context_handle = context_handle from the (789.client.example.com.server.example.com., context_handle) entry in the server's mapping table OCTET STRING input_token = token specified in the Key field of TKEY RR (from Additional records Section of the client's query)
入力コンテキストハンドルinput_context_handle = context_handle from the（789.client.example.com。、context_handle）エントリサーバーのマッピングテーブルのエントリOctet string input_token = tkey rrのキーフィールドで指定クライアントのクエリの）
The OUTPUTS parameters returned by GSS_Accept_sec_context include INTEGER major_status = GSS_S_COMPLETE CONTEXT_HANDLE output_context_handle = context_handle OCTET STRING output_token = NULL
gss_accept_sec_contextによって返される出力パラメーターには、integer major_status = gss_s_complete context_handle output_context_handle = context_handleオクター文字列output_token = null
Since major_status = GSS_S_COMPLETE, the security context on the server side is established, but the server still needs to respond to the client's TKEY query, as described below. The security context state is advanced to Context Established.
Major_status = gss_s_completeであるため、サーバー側のセキュリティコンテキストが確立されますが、以下に説明するように、サーバーはクライアントのtkeクエリに応答する必要があります。セキュリティコンテキスト状態は、確立されたコンテキストに進められます。
X. Server responds to the TKEY query
X.サーバーはTKEYクエリに応答します
Since the major_status = GSS_S_COMPLETE in the last server's call to GSS_Accept_sec_context and the output_token is NULL, the server responds to the TKEY query placing in the answer section a TKEY record that was sent by the client in the Additional records section of the client's latest TKEY query. In addition, this server places a TSIG record in additional records section of its response. Server calls GSS_GetMIC to generate a signature to include it in the TSIG record. The server specifies the following GSS_GetMIC INPUT parameters:
gss_accept_sec_contextへの最後のサーバーの呼び出しでmajor_status = gss_s_completeはnullであるため、サーバーは、クライアントの最新のtke queryの追加記録セクションでクライアントが送信したtkeyレコードを回答セクションに配置するtkeクエリに応答します。。さらに、このサーバーは、TSIGレコードをその応答の追加レコードセクションに配置します。サーバーはgss_getmicを呼び出して署名を生成してtsigレコードに含める。サーバーは、次のgss_getmic入力パラメーターを指定します。
CONTEXT HANDLE context_handle = context_handle from the (789.client.example.com.server.example.com., context_handle) entry in the server's mapping table OCTET STRING message = outgoing message plus TSIG variables (as described in [RFC2845])
コンテキストハンドルContext_handle = context_handle from（789.client.example.com.server.example.com。、context_handle）サーバーのマッピングテーブルでのエントリOctet String message = outoving Message Plus TSIG変数（[RFC2845]で説明）
The OUTPUTS parameters returned by GSS_GetMIC include INTEGER major_status = GSS_S_COMPLETE OCTET STRING per_msg_token
gss_getmicによって返される出力パラメーターにはinteger major_status = gss_complete occet string per_msg_tokenが含まれます
Signature field in the TSIG record is set to per_msg_token.
TSIGレコードの署名フィールドは、per_msg_tokenに設定されています。
XI. Client processes token returned by server
xi。クライアントプロセスサーバーによって返されたクライアントプロセストークン
Client receives the TKEY query response from the server. Since the major_status was GSS_S_COMPLETE in the last client's call to GSS_Init_sec_context, the client verifies that the server's response is signed. To validate the signature, the client calls GSS_VerifyMIC with the following parameters:
クライアントは、サーバーからTKEYクエリ応答を受信します。Major_Statusは、GSS_INIT_SEC_CONTEXTへの最後のクライアントの呼び出しでGSS_S_Completeであったため、クライアントはサーバーの応答が署名されていることを確認します。署名を検証するために、クライアントは次のパラメーターを使用してGSS_VERIFYMICを呼び出します。
INPUTS CONTEXT HANDLE context_handle = context_handle for 789.client.example.com.server.example.com. key_name OCTET STRING message = incoming message plus TSIG variables (as described in [RFC2845]) OCTET STRING per_msg_token = Signature field from TSIG RR included in the server's query response
入力コンテキストハンドルContext_handle = context_handle for 789.client.example.com.server.example.com。key_name octet string message =受信メッセージとtsig変数（[rfc2845]に記載されている）Octet string per_msg_token =サーバーのクエリ応答に含まれるtsig rrからの署名フィールド
Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the signature is validated, security negotiation is complete and the security context state is advanced to Context Established. These client and server will use the established security context to sign and validate the signatures when they exchange packets with each other until the context expires.
出力パラメーターmajor_status = gss_s_completeであるため、署名が検証され、セキュリティネゴシエーションが完了し、セキュリティコンテキスト状態がコンテキストの確立まで進められます。これらのクライアントとサーバーは、確立されたセキュリティコンテキストを使用して、コンテキストが期限切れになるまでパケットを互いに交換するときに署名と検証に署名および検証します。
This document describes a protocol for DNS security using GSS-API. The security provided by this protocol is only as effective as the security provided by the underlying GSS mechanisms.
このドキュメントでは、GSS-APIを使用したDNSセキュリティのプロトコルについて説明します。このプロトコルによって提供されるセキュリティは、基礎となるGSSメカニズムによって提供されるセキュリティと同じくらい効果的です。
All the security considerations from RFC 2845, RFC 2930 and RFC 2743 apply to the protocol described in this document.
RFC 2845、RFC 2930、およびRFC 2743からのすべてのセキュリティ上の考慮事項は、このドキュメントで説明されているプロトコルに適用されます。
The IANA has reserved the TSIG Algorithm name gss-tsig for the use in the Algorithm fields of TKEY and TSIG resource records. This Algorithm name refers to the algorithm described in this document. The requirement to have this name registered with IANA is specified in RFC 2845.
IANAは、TKEYおよびTSIGリソースレコードのアルゴリズムフィールドで使用するために、TSIGアルゴリズム名GSS-TSIGを予約しています。このアルゴリズム名は、このドキュメントで説明されているアルゴリズムを指します。この名前をIANAに登録するための要件は、RFC 2845で指定されています。
The GSS API using SPNEGO [RFC2478] provides maximum flexibility to choose the underlying security mechanisms that enables security context negotiation. GSS API using SPNEGO [RFC2478] enables client and server to negotiate and choose such underlying security mechanisms on the fly. To support such flexibility, DNS clients and servers SHOULD specify SPNEGO mech_type in their GSS API calls. At the same time, in order to guarantee interoperability between DNS clients and servers that support GSS-TSIG it is required that
SPNEGO [RFC2478]を使用したGSS APIは、セキュリティコンテキストの交渉を可能にする基礎となるセキュリティメカニズムを選択するための最大の柔軟性を提供します。SPNEGOを使用したGSS API [RFC2478]を使用すると、クライアントとサーバーがそのような基礎となるセキュリティメカニズムをその場で選択して選択できます。このような柔軟性をサポートするために、DNSクライアントとサーバーは、GSS API呼び出しでSPNEGO Mech_Typeを指定する必要があります。同時に、GSS-TSIGをサポートするDNSクライアントとサーバー間の相互運用性を保証するために、
- DNS servers specify SPNEGO mech_type - GSS APIs called by DNS client support Kerberos v5 - GSS APIs called by DNS server support SPNEGO [RFC2478] and Kerberos v5.
- DNSサーバーは、DNSクライアントサポートKerberos v5 -GSS API -dns Server Support Spnego [RFC2478]およびKerberos V5によって呼び出されるKerberos v5 -GSS APIによって呼び出されたSPNEGO Mech_Type -GSS APIを指定します。
In addition to these, GSS APIs used by DNS client and server MAY also support other underlying security mechanisms.
これらに加えて、DNSクライアントとサーバーが使用するGSS APIは、他の基礎となるセキュリティメカニズムもサポートする場合があります。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実践するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待します。情報をIETFエグゼクティブディレクターに宛ててください。
The authors of this document would like to thank the following people for their contribution to this specification: Chuck Chan, Mike Swift, Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake, 3rd and Erik Nordmark.
この文書の著者は、この仕様への貢献について次の人々に感謝したいと思います：チャック・チャン、マイク・スウィフト、ラム・ヴィスワナサン、オラファー・グドムンソン、ドナルド・E・イーストレイク、3番目、エリック・ノードマーク。
[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月。
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, December 1998.
[RFC2478] Baize、E。およびD. Pinkas、「シンプルで保護されたGSS-API交渉メカニズム」、RFC 2478、1998年12月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface, Version 2 , Update 1", RFC 2743, January 2000.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interface、バージョン2、Update 1」、RFC 2743、2000年1月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake 3rd、D。and B. Wellington、「DNS（TSIG）のシークレットキートランザクション認証」、RFC 2845、2000年5月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930] EastLake 3rd、D。、「DNSの秘密の鍵設立（TKEY RR）」、RFC 2930、2000年9月。
[ISO11578] "Information technology", "Open Systems Interconnection", "Remote Procedure Call", ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html.
[ISO11578]「情報技術」、「オープンシステムの相互接続」、「リモートプロシージャコール」、ISO/IEC 11578：1996、http：//www.iso.ch/cate/d2229.html。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1034、1987年11月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964] Linn、J。、「Kerberosバージョン5 GSS-APIメカニズム」、RFC 1964、1996年6月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025] Adams、C。、「シンプルなパブリックキーGSS-APIメカニズム（SPKM）」、RFC 2025、1996年10月。
[RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC2137] EastLake 3rd、D。、「セキュアドメイン名システムダイナミックアップデート」、RFC 2137、1997年4月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] EastLake 3rd、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
Stuart Kwan Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: skwan@microsoft.com
Stuart Kwan Microsoft Corporation One Microsoft Way Redmond、WA 98052 USAメール：skwan@microsoft.com
Praerit Garg Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: praeritg@microsoft.com
Praerit Garg Microsoft Corporation One Microsoft Way Redmond、WA 98052 USAメール：praeritg@microsoft.com
James Gilroy Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: jamesg@microsoft.com
James Gilroy Microsoft Corporation One Microsoft Way Redmond、WA 98052 USAメール：Jamesg@microsoft.com
Levon Esibov Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: levone@microsoft.com
Levon Esibov Microsoft Corporation One Microsoft Way Redmond、WA 98052 USAメール：levone@microsoft.com
Randy Hall Lucent Technologies 400 Lapp Road Malvern PA 19355 USA EMail: randyhall@lucent.com
Randy Hall Lucent Technologies 400 Lapp Road Malvern PA 19355 USAメール：randyhall@lucent.com
Jeff Westhead Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: jwesth@microsoft.com
Jeff Westhead Microsoft Corporation One Microsoft Way Redmond、WA 98052 USAメール：jwesth@microsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。