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)
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.
著作権（C）インターネット協会（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）プロトコルは、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]プロトコル、クライアントとサーバーまたはサーバーやサーバーなどの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.
*メカニズムやプロトコルに依存しません。セキュリティサービスを実現する基礎となるメカニズムは、その場で交渉し、時間の経過とともに変化させることができます。同じサーバが別のクライアントでSPKM [RFC2025]を使用する場合があるたとえば、クライアントとサーバは、1つのトランザクションのためのKerberos [RFC1964]を使用するかもしれません。
* 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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、 "推奨"、 "SHOULD NOT"、および本書でBCP 14に記載されるように解釈されるべきである、 "MAY"、RFC 2119 [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では、クライアントとサーバは、「セキュリティコンテキスト」を作成するために相互作用します。セキュリティコンテキストを作成し、二者間のメッセージのトランザクション署名を検証するために使用することができます。独自のセキュリティコンテキストは、クライアントとサーバ間の各一意の接続に必要です。
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.は、セキュリティコンテキストを確立します。クライアントとサーバは、それらが搬送機構として[RFC2930]を使用して、お互いに渡すトークンを生成するために、もしGSS_Init_sec_context及び場合gss_accept_sec_context APIを使用します。
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."
：「秘密鍵をサーバに処理、クライアントのクエリの後に、サーバー側で確立された場合、符号なし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はまた、コンテキスト・ハンドルを識別します。たキー名は、現在の要求を処理するために使用されなければならない状況お互いに示すために、クライアントとサーバの間で送信される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).
セキュリティメカニズムがで使用されることが必要とされるGSS-TSIGをサポートするDNSクライアントとサーバ間の相互運用性を保証するために、同時に、セクション3と4で説明したようにDNSクライアントとサーバは、セキュリティコンテキストを確立するために、様々な基本的なセキュリティ・メカニズムを使用するかもしれクライアントは、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]は、クライアントとサーバとの間のトークンを転送するための媒体として使用されます。処理鍵レコードは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]のセクション2.2.1、 "もしGSS_Init_sec_contextの呼び出し" を、参照してください。
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]
入力CREDENTIALハンドルclaimant_cred_handle = NULL（NULLが "デフォルトを使用" を指定します）。クライアントは、代わりにその資格情報にいくつかの他の有効なハンドルを指定するかもしれません。実装者が選択したコンテキスト・ハンドルinput_context_handle = 0内部の名前targ_name = "DNS @ <target_server_name>" オブジェクト識別子たmech_type =基本セキュリティメカニズム。ケルベロスV5の使用を可能に有効な基本的なセキュリティ・メカニズムを指定しなければならないGSS-TSIG機構クライアントの実装の相互運用性を保証するために（詳細については、セクション9を参照してください）。 OCTET STRINGの入力トークン= 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要求デフォルト値）。クライアントではなく、数秒で確立されるコンテキストの寿命のために別の上限を指定するかもしれません。 [RFC2743]で「チャネルバインディング」のセクション1.1.6に指定されているオクテット文字列chan_bindings =任意の有効なチャネルバインディング
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
OUTPUTS INTEGERはBOOLEAN replay_det_stateのBOOLEAN mutual_state整数minor_statusオブジェクト識別子メカニズム種別のブールdeleg_stateたoutput_tokenコンテキストハンドルoutput_context_handleオクテット文字列をmajor_status
BOOLEAN sequence_state BOOLEAN anon_state BOOLEAN trans_state BOOLEAN prot_ready_state BOOLEAN conf_avail BOOLEAN integ_avail INTEGER lifetime_rec
INTEGERのlifetime_rec integ_avail BOOLEAN sequence_stateのBOOLEAN anon_stateのBOOLEAN trans_stateのBOOLEANのprot_ready_stateのBOOLEANのconf_availのBOOLEAN
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_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
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とmutual_stateの値は、それぞれ、示します。返さmajor_statusがGSS_S_COMPLETE、これらの値の一方または両方が偽である場合、クライアントはこのアルゴリズムを放棄しなければなりません。
Client's behavior MAY depend on other OUTPUT parameters according to the policy local to the client.
クライアントの動作は、クライアントのローカルポリシーに応じて他のOUTPUTパラメータに依存してもよいです。
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はこの交渉に固有であり、TARGET_NAMEにマップcontext_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でクエリ要求でサーバーに送信されます。トークン自体は、クエリの追加レコードセクションの処理鍵資源レコードのRDATAフィールドの主要データフィールドに配置されます。追加レコードセクションのために照会TKEYリソースレコードセットと供給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録音NAME =クライアントが生成したグローバルにユニークなドメイン名の文字列RDATAアルゴリズム名= GSS-TSIGモード= 3（[RFC2930]で説明したように） - オクテットキーでのoutput_tokenの（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].
キーデータ、i.n.、インセプション、有効期限、エラー、その他のサイズとデータフィールドの残りのフィールドは、[RFC 2930]に応じて設定されなければなりません。
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_CONTINUE_NEEDEDかGSS_S_COMPLETE以外のmajor_statusを返した場合、クライアントは処理鍵の問合せを送ってはいけません。この場合、クライアントの動作は、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.
処理鍵の問合せを受信すると、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_S_COMPLETEまたはGSS_S_CONTINUEのいずれか：次の処理ステップは、クライアントがもしGSS_Init_sec_contextに実行した最新の呼び出しから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と非NULLのoutput_tokenのmajor_status値が得られた場合は、交渉のクライアント側コンポーネントが完了し、クライアントがサーバーからの確認を待っています。
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と、クエリの回答セクションの最後のクライアント供給処理鍵レコードを持つクエリ応答の形です。応答がTSIGレコードで署名されなければなりません。サーバが原因上記の2.2節で指定されたRFC 2845に変更に符号なしのクライアントのクエリに対する応答に署名することを許可されていることに注意してください。 TSIGレコードの署名は、送信および署名されたメッセージの確認、セクション5に詳述した手順を使用して検証されなければなりません。応答が署名されていない場合、応答が署名したが、署名が無効である場合、または、その後、攻撃者は、輸送中にメッセージを改ざんしているか、クライアントに偽の応答を送信しようとしています。この場合、クライアントは、クライアント送信された最後の処理鍵の問合せの有効期限が切れてからの時間期間までその最後の処理鍵のクエリへの応答を待ち続けるかもしれません。このような期間は、クライアントにローカルポリシーで指定されています。これは、いくつかの基準に基づいて1つのクエリIDについて複数回答を受け入れ、1つを選択するDNSクライアントを可能にする新しいオプション（必ずしも最初の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_CONTINUE_NEEDEDのmajor_status値が得られた場合、交渉はまだ完了していません。サーバーは、クライアントへの回答セクションの処理鍵レコードを持つクエリ応答を返します。 DNSメッセージのエラーが処理鍵レコード内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
DNSメッセージエラーが処理鍵レコードのNO_ERRORとエラーフィールドが0（すなわち、エラーなし）であるれていない場合、クライアントはにTKEYリソースレコード内のキーデータフィールドに指定されたトークンを渡す必要があります
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:
後述のように入力トークンCONTEXTハンドルinput_context_handleとオクテット文字列の値を除いて、前の呼び出しと同じパラメータ値を使用して、もしGSS_Init_sec_context。
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)
INPUTS CONTEXTハンドルinput_context_handle = context_handle（これは処理鍵問合せ応答の答え部で処理鍵レコードの所有者名たキー名に対応するcontext_handleです）
OCTET STRING input_token = token from Key field of TKEY record
処理鍵レコードのキーフィールドから=トークン入力トークンオクテットSTRING
Depending on the following OUTPUT values of GSS_Init_sec_context
もしGSS_Init_sec_contextの次の出力値に応じて、
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:
OUTPUTの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
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.
クライアントは、この交渉のシーケンスを放棄しなければなりません。これは、クライアントが関連付けられているcontext_handleを提供GSS_Delete_sec_contextを呼び出すことにより、アクティブなコンテキストを削除しなければならないことを意味します。クライアントは、セクション3.1で説明したように初期化されていない状態で始まる交渉シーケンスを繰り返してもよいです。セキュリティコンテキストを確立するための試行回数をループ無限防ぐために、10以下に制限されなければなりません。
If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then client MUST act as described below.
OUTPUTのmajor_statusがGSS_S_CONTINUE_NEEDED OR GSS_S_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に詳述した手順を使用して検証されなければなりません。署名が無効である場合、クライアントは、この交渉のシーケンスを放棄しなければなりません。これは、クライアントが関連付けられているcontext_handleを提供GSS_Delete_sec_contextを呼び出すことにより、アクティブなコンテキストを削除しなければならないことを意味します。クライアントは、セクション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で始まる交渉シーケンスを繰り返すことにより、処理鍵レコードでサーバに渡さなければなりません。クライアントは、無限ループを防ぐために、コンテキスト交渉に継続回数に制限を置かなければなりません。そのような限界は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がNULLでない場合、交渉のクライアント側コンポーネントは完了ですが、トークンのoutput_tokenは3.1.2で始まる交渉シーケンスを繰り返すことで、サーバに通過しなければなりません。
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.
コンテキストのネゴシエーションが完了すると、ハンドルcontext_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].
クライアントが確立されたセキュリティコンテキストを使用し続けることが意図されていない場合は、クライアントは、関連するcontext_handleを提供GSS_Delete_sec_contextを呼び出すことにより、アクティブなコンテキストを削除する必要があり、クライアントがに設定Modeフィールドで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)
（たキー名、context_handle）
A server MUST recognize TKEY queries as security context negotiation messages.
サーバは、セキュリティコンテキストのネゴシエーションメッセージとして処理鍵のクエリを認識しなければなりません。
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でクエリを受信すると、サーバは、メッセージの追加レコードセクションの処理鍵レコードのモードとアルゴリズム名フィールドは、それぞれ、3の値とGSS-TSIGを含むかどうかを検討しなければなりません。彼らが行う場合には、（key_nameは、context_handle）マッピングテーブルは、クエリの追加レコードセクションの処理鍵レコードの所有者名を照合たキー名が検索されます。名前はこの名前のテーブルとセキュリティコンテキストで発見された場合に確立し、有効期限が切れていない場合、サーバが処理鍵エラーフィールドで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)
INPUTSコンテキストハンドルのinput_context_handle = 0新しい交渉、context_handle照合たキー名かの継続的な交渉のオクテット文字列を入力トークン=（クライアントのクエリの追加レコードのセクションから）処理鍵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が "デフォルトを使用" を指定します）。サーバーではなく、その資格情報にいくつかの他の有効なハンドルを指定するかもしれません。 [RFC2743]で「チャネルバインディング」のセクション1.1.6に指定されているオクテット文字列chan_bindings =任意の有効なチャネルバインディング
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
INTEGER lifetime_rec CONTEXT_HANDLEのdelegated_cred_handle integ_avail INTEGER minor_status内部名src_nameオブジェクト識別子メカニズム種別の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たoutput_token OUTPUTS INTEGER major_status CONTEXT_HANDLE output_context_handleオクテットSTRING
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は処理鍵レコードの名前にマップ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と処理鍵クエリ応答でクライアントに反応しなければなりません。
If OUTPUT major_status is one of the following errors the error field in the TKEY record set to BADKEY.
OUTPUTのmajor_statusは、次のいずれかのエラー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
If OUTPUT major_status is set to GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED then server MUST act as described below.
OUTPUTの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がNULLでない場合、それはTKEYでRDATAの主要データフィールドにクライアントに返さなければなりません。処理鍵レコードのエラーフィールドは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の場合、レコードは、クライアントから受信したTKEYは、応答の回答セクションで返さなければなりません。セクション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であるならば、交渉のサーバーコンポーネントは、まだ完成ではありません。サーバが応答セクションにキーデータRDATAフィールドでのoutput_token含む処理鍵レコードを配置し、標準クエリ応答で処理鍵の問合せに応答します。処理鍵レコードのエラーフィールドは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である場合を除いて、他の処理鍵レコードのフィールドは、次の値を含まなければなりません：
NAME = key_name
RDATA
Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [RFC2930])
Key Size = size of output_token in octets
The remaining fields in the TKEY RDATA, i.e., Inception, Expiration, Error, Other Size and Data Fields, MUST be set according to [RFC2930].
キーデータ、i.n.、インセプション、有効期限、エラー、その他のサイズとデータフィールドの残りのフィールドは、[RFC 2930]に応じて設定されなければなりません。
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).
コンテキストのネゴシエーションが完了すると、ハンドルcontext_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に設定されたモード・フィールド、すなわち「キー削除」[RFC2930]と応答したTKEY RRを含めることによって削除されているクライアントへのヒントもしれ。アクティブなコンテキストは、関連する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レコードNAME =この文脈RDATAアルゴリズム名= 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])
たキー名のOCTET STRINGのメッセージ=送信メッセージプラスTSIG変数（[RFC2845]あたりの）整数qop_req = 0（0要求デフォルト値）の入力コンテキストハンドルcontext_handle = context_handle。 （詳細は[RFC2743]でセクション1.2.4を参照）発信者ではなく、他の有効な値を指定することもできます
OUTPUTS INTEGER major_status INTEGER minor_status OCTET STRING per_msg_token
OUTPUTS INTEGER major_status INTEGER minor_statusオクテット文字列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_NO_CONTEXTである場合、発信者は、セクション3.1で上述したように、初期化されていない状態に戻り、新たなセキュリティコンテキストをネゴシエートする、（ターゲット：名前、key_nameは、context_handle）マッピングテーブルからたキー名のエントリを削除する必要があります
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マップを決定します。 NAMEは、確立されたコンテキストにマッピングされていない場合、サーバはTSIGエラーフィールドにBADKEYを示すクライアントに標準TSIGエラー応答を送らなければなりません（[RFC2845]に記載されているように）。
For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
GSSのアルゴリズムのために、署名は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
TSIG RRからの入力（[RFC2845]あたり）key_nameはOCTET STRINGのメッセージ=着信メッセージプラスTSIG変数のコンテキストハンドルcontext_handle = context_handleをオクテットストリングper_msg_token =署名フィールド
OUTPUTS INTEGER major_status INTEGER minor_status INTEGER qop_state
OUTPUTS 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
サーバは、クライアント要求を処理しているときmajor_statusは、以下のいずれかの値に設定されている場合、サーバは、[RFC2845]に記載されているようにTSIGエラーフィールドにBADKEYを示すクライアントに標準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
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.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
CONTEXTハンドルinput_context_handle = 0内部名targ_name = "DNS@server.example.com" OCTET STRINGの入力トークン= 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によって返される出力パラメータは、BOOLEANたoutput_token replay_det_state = TRUE TRUE BOOLEANのmutual_state =たoutput_token context_handleオクテットSTRING output_context_handle INTEGER major_status = GSS_S_CONTINUE_NEEDED・コンテキスト・ハンドルを含みます
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とmutual_state値がTRUEであることを確認します。 major_statusは成功出力major_status値であるGSS_S_CONTINUE_NEEDED、であるので、クライアント店がcontext_handle次のステップにマップを「DNS@server.example.com」と進めています。
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でクエリを送信します。クエリは、次のフィールドとの追加レコードセクションの処理鍵レコードが含まれています。 （このアルゴリズムに固有のものではない一部のフィールドが指定されていないことに注意してください。）
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
= 789.client.example.com.server.example.comに名前を付けます。 RDATAアルゴリズム名= GSS-TSIGモード= 3 - オクテットキーデータ=のoutput_token中のoutput_tokenの（GSS-API交渉あたり[RFC2930]）キーサイズ=サイズ
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でクエリを受信すると、サーバはクエリの追加レコードセクションの処理鍵レコード内のモードとアルゴリズムフィールドは、それぞれ3に設定し、「GSS-TSIG」されていることを確認します。これは、key_nameはの789.client.example.com.server.example.comことを発見します。その（たキー名、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)
INPUTSコンテキストハンドルのinput_context_handle = 0オクテット文字列入力トークン=（クライアントのクエリの追加レコードセクションから）処理鍵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によって返される出力パラメータは、たoutput_tokenたoutput_token INTEGER major_status = GSS_S_CONTINUE_NEEDED CONTEXT_HANDLE output_context_handle context_handle OCTET文字列を含みます
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のマッピングを格納します。その（たキー名、context_handle）マッピングテーブル内の出力context_handleします。
V. Server responds to the TKEY query
V. Serverが処理鍵の問合せに応答します
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.
場合gss_accept_sec_contextへの最後のサーバーの呼び出しでmajor_status = GSS_S_CONTINUE_NEEDEDので、サーバが応答セクションにキーデータRDATAフィールドでのoutput_token含む処理鍵レコードを置く処理鍵の問合せに応答します。処理鍵レコードのエラーフィールドが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.)
クライアントがサーバから処理鍵問合せ応答を受信すると、クライアントは次のパラメータでもし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 = context_handleがクライアントのマッピングテーブルエントリに保存されている（DNS@server.example.com。、789.client.example.com.server.example.com。、context_handle）内部の名前targ_name =「DNS@server.exampleサーバーの応答BOOLEANのreplay_det_req_flagの回答セクションから処理鍵レコードのキーフィールド= TRUE BOOLEANのmutual_req_flagから入力トークン=トークン.COM」オクテットSTRING = 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によって返される出力パラメータは= TRUE INTEGER major_status = GSS_S_COMPLETEコンテキストハンドルoutput_context_handle = context_handleオクテットSTRINGたoutput_token =たoutput_token BOOLEANのreplay_det_state = TRUE BOOLEANのmutual_stateを含みます
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ではないので、以下に説明するように、クライアントがサーバに処理鍵の問合せを送らなければなりません。
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ための処理鍵クエリーを送信します。名前。クエリは、次のフィールドとの追加レコードセクションの処理鍵レコードが含まれています。 （このアルゴリズムにとって重要ではなく、いくつかの入力および出力パラメータは、この例で説明されていないことに注意してください。）
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
= 789.client.example.com.server.example.comに名前を付けます。 RDATAアルゴリズム名= GSS-TSIGモード= 3 - オクテットキーデータ=のoutput_token中のoutput_tokenの（GSS-API交渉あたり[RFC2930]）キーサイズ=サイズ
VIII. Server receives a TKEY query
VIII。サーバーは処理鍵の問合せを受けます
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.
サーバが処理鍵の問合せを受信すると、サーバはクエリの追加レコードセクションの処理鍵レコード内のモードとアルゴリズムフィールドは、それぞれ、3に設定し、GSS-TSIGされていることを確認します。これは、key_nameはの789.client.example.com.server.example.comことを発見します。その（たキー名、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を呼び出し続けるには（このアルゴリズムのために重要ではなく、いくつかのINPUTとOUTPUTパラメータは、この例で説明されていないことに注意してください）
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)
追加レコードのセクションからサーバーのマッピングテーブルオクテットSTRING中（789.client.example.com.server.example.com。、context_handle）エントリーからの入力コンテキストハンドルinput_context_handle = context_handle入力トークン= 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 OCTET STRINGた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ので、サーバー側のセキュリティコンテキストが確立されているが、サーバーは、まだ以下に説明するように、クライアントの処理鍵の問合せに応答する必要があります。セキュリティコンテキストの状態が確立されたコンテキストに進んでいます。
X. Server responds to the TKEY query
X. Serverが処理鍵の問合せに応答します
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の呼び出しとのoutput_tokenでmajor_status = GSS_S_COMPLETEがNULLであるので、サーバが応答セクションで、クライアントの最新TKEYクエリの追加レコードのセクションで、クライアントによって送信された処理鍵レコードを置く処理鍵の問合せに応答します。また、このサーバは、その応答の追加レコードセクションにTSIGレコードを配置します。サーバーはTSIGレコードに含める署名を生成するためにGSS_GetMICを呼び出します。サーバーは、次の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 = context_handle（789.client.example.com.server.example.com。、context_handle）サーバのマッピングテーブルOCTET STRINGメッセージ=送信メッセージプラス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_S_COMPLETE OCTET 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:
クライアントは、サーバから処理鍵問合せ応答を受け取ります。 major_statusがGSS_S_COMPLETEがもしGSS_Init_sec_contextへの最後のクライアントの呼び出しであったため、クライアントは、サーバーの応答が署名されていることを確認します。署名を検証するために、クライアントは次のパラメータで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
789.client.example.com.server.example.comの入力コンテキストハンドルのcontext_handle = context_handle。 （[RFC2845]に記載されているように）たキー名のOCTET STRINGのメッセージは=着信メッセージプラスTSIG変数OCTET列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 [RFC2478]を使用してGSS APIは、クライアントとサーバーが交渉し、その場で、このような基本的なセキュリティメカニズムを選択することができます。このような柔軟性をサポートするために、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サーバは、SPNEGOのメカニズム種別を指定 - DNSクライアントのサポートのKerberos V5によって呼び出さGSS APIを - DNSサーバのサポートSPNEGO [RFC2478]およびKerberos V5によって呼び出さ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.
チャック・チャン、マイク・スウィフト、ラムViswanathanの、オラフルグドムンソン、ドナルドE.イーストレイク、3番目とエリックNordmarkと：この文書の著者は、この仕様書への貢献のために、以下の人々に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ベーズ、E.およびD.ピンカス、 "単純で保護されたGSS-API交渉メカニズム"、RFC 2478、1998年12月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface, Version 2 , Update 1", RFC 2743, January 2000.
[RFC2743]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェース、バージョン2、アップデート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.、グドムンソン、O.、イーストレイク3日、D.とB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]イーストレーク第3、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]リン、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]アダムス、C.、 "単純な公開鍵GSS-APIメカニズム（SPKM）"、RFC 2025、1996年10月。
[RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[RFC2137]イーストレーク第3、D.は、RFC 2137、1997年4月、 "ドメインネームシステム動的な更新を固定します"。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレーク第3、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
Stuart Kwan Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: skwan@microsoft.com
スチュアート・クワンマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052 USA電子メール：skwan@microsoft.com
Praerit Garg Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: praeritg@microsoft.com
マイクロソフト社1つのマイクロソフト道、レドモンドはガーグ、WA 98052 USAメールをpraerit：praeritg@microsoft.com
James Gilroy Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: jamesg@microsoft.com
ジェームズ・ギルロイマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052 USA電子メール：jamesg@microsoft.com
Levon Esibov Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: levone@microsoft.com
レヴォンEsibovマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052 USA電子メール：levone@microsoft.com
Randy Hall Lucent Technologies 400 Lapp Road Malvern PA 19355 USA EMail: randyhall@lucent.com
ランディ・ホールルーセント・テクノロジーズ400のLapp道路マルバーンPA 19355 USA Eメール：randyhall@lucent.com
Jeff Westhead Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: jwesth@microsoft.com
ジェフWestheadマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052 USA電子メール：jwesth@microsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。