この文書はRFC3645の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
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.
ＤＮＳのための秘密鍵取引認証（ＴＳＩＧ）プロトコルはＤＮＳに処理レベ
ルの認証を提供します。ＴＳＩＧは新しいアルゴリズムの定義を通して拡張
可能です。この文書は一般的なセキュリティサービスアプリケーションプロ
グラムインタフェース（ＧＳＳ−ＡＰＩ）（ＲＦＣ２７４３）に基づいたア
ルゴリズムを指定します。この文書はＲＦＣ２８４５を更新します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Algorithm Overview
2. アルゴリズム概要
2.1. GSS Details
2.1. ＧＳＳ詳細
2.2. Modifications to the TSIG protocol (RFC 2845)
2.2. 処理署名プロトコル（ＲＦＣ２８４５）への修正
3. Client Protocol Details
3. クライアントプロトコル詳細
3.1. Negotiating Context
3.1. コンテキスト交渉
3.1.1. Call GSS_Init_sec_context
3.1.1. GSS_Init_sec_context呼出し
3.1.2. Send TKEY Query to Server
3.1.2. TKEY問合せをサーバへ送る
3.1.3. Receive TKEY Query-Response from Server
3.1.3. サーバから処理鍵質問−応答の受信
3.2. Context Established
3.2. 確立したコンテキスト
3.2.1. Terminating a Context
3.2.1. コンテキスト終了
4. Server Protocol Details
4. サーバープロトコル詳細
4.1. Negotiating Context
4.1. コンテキスト交渉
4.1.1. Receive TKEY Query from Client
4.1.1. クライアントからの処理鍵質問の受信
4.1.2. Call GSS_Accept_sec_context
4.1.2. GSS_Accept_sec_context呼出
4.1.3. Send TKEY Query-Response to Client
4.1.3. クライアントに処理鍵応答の送信
4.2. Context Established
4.2. 確立したコンテキスト
4.2.1. Terminating a Context
4.2.1. コンテキスト終了
5. Sending and Verifying Signed Messages
5. 署名メッセージの送信と検証
5.1. Sending a Signed Message - Call GSS_GetMIC
5.1. 署名メッセージ送信−GSS_GetMIC呼出
5.2. Verifying a Signed Message - Call GSS_VerifyMIC
5.2. 署名メッセージの検証−GSS_VerifyMIC呼出
6. Example usage of GSS-TSIG algorithm
6. ＧＳＳ−ＴＳＩＧアルゴリズムの使用例
7. Security Considerations
7. セキュリティの考察
8. IANA Considerations
8. ＩＡＮＡの考慮
9. Conformance
9. 適合性
10. Intellectual Property Statement
10. 知的所有権宣言
11. Acknowledgements
11. 謝辞
12. References
12. 参考文献
12.1. Normative References
12.1. 参照する参考文献
12.2. Informative References
12.2. 有益な参考文献
13. Authors' Addresses
13. 著者のアドレス
14. Full Copyright Statement
14. 著作権表示全文
1. Introduction
1. はじめに
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.
ＤＮＳのための秘密鍵取引認証（ＴＳＩＧ）[RFC2845]プロトコルは、クライ
アントとサーバあるいはサーバとサーバのような、２つのＤＮＳエンティ
ティ間でメッセージの軽量の認証と完全性を供給するために発展しました。
処理署名は動的な更新メッセージを守ったり、通常メッセージを認証するか
クライアントからサーバへの複雑なＤＮＳＳＥＣ[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.
処理署名プロトコル[RFC2845]は新しいアルゴリズムの定義を通して拡張可
能です。この文書は一般的なセキュリティサービスアプリケーションプログ
ラムインタフェース（ＧＳＳ−ＡＰＩ）[RFC2743]に基くアルゴリズムを指
定します。ＧＳＳ−ＡＰＩはアプリケーションプロトコルデベロッパにセ
キュリティの抽象概念を供給するフレームワークです。提供されたセキュ
リティサービスは認証と完全性と機密性を含むことができます。
The GSS-API framework has several benefits:
ＧＳＳ−ＡＰＩフレームワークはいくつかの利点を持っています：
* 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.
* メカニズムとプロトコルが独立。セキュリティサービスを実現する基礎メ
カニズムはその場その場で交渉され、そして長期的に変更ができます。例
えば、あるクライアントとサーバが取引にＫｅｒｂｅｒｏｓ[RFC1964]を
使ってもよい(MAY)のに対し、同じサーバが異なるクライアントにＳＰＫ
Ｍ[RFC2025]を使ってもよいです(MAY)。
* 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].
この文書の範囲は認証メカニズムのみの記述に制限されます。これは認可メ
カニズムを論じたり提案したりしません。ＧＳＳ−ＡＰＩの概念に通じてい
ない読者はこのプロトコルの詳細を調べる前に[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", "RECOMMENDED", "MAY", and "OPTIONAL"はＢＣＰ１４、ＲＦ
Ｃ２１１９[RFC 2119]で記述されるように解釈されるはずです。
2. Algorithm Overview
2. アルゴリズム概要
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.
ＧＳＳで、クライアントとサーバが「セキュリティコンテキスト」を作るた
めに相互作用します。セキュリティコンテキストは２者間にメッセージ処理
署名を作り、そして実証するために使うことができます。クライアントとサー
バ間のそれぞれのユニークな接続のためにユニークなセキュリティコンテキ
ストが必要とされます。
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:
セキュリティコンテキストを作ることはクライアントとサーバの間の交渉を
伴います。コンテキストが確立されると、これは安全なメッセージに使える
有限の寿命を持ちます。それで接続と関連したコンテキストの３つの状態が
あります：
+----------+
| |
V |
+---------------+ |
| Uninitialized | |
| 未初期化 | |
+---------------+ |
| |
V |
+---------------+ |
| Negotiating | |
| Context | |
| コンテキスト | |
| 交渉 | |
+---------------+ |
| |
V |
+---------------+ |
| Context | |
| Established | |
| コンテキスト | |
| 確立 | |
+---------------+ |
| |
+----------+
Every connection begins in the uninitialized state.
すべての接続が未初期化状態で始まります。
2.1. GSS Details
2.1. ＧＳＳ詳細
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].
クライアントとサーバがローカルに認証されなくてはならなくて、そしてＲ
ＦＣ２７４３[RFC2743]のセクション１.１.１「資格」で指定されるように、
このプロトコルを使う前にデフォルト資格証明を獲得しなければなりません
(MUST)。
The GSS-TSIG algorithm consists of two stages:
ＧＳＳ−ＴＳＩＧアルゴリズムは２つの段階から成り立ちます：
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ＡＰＩを使い
ます。
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 ＡＰＩを使って署名の生成と実証するために使われます。
これらの署名は、[RFC2845]で記述されるように、クライアントとサーバ
の間で送ったＤＮＳメッセージの処理署名レコードの一部として、クラ
イアントとサーバによって交換されます。
2.2. Modifications to the TSIG protocol (RFC 2845)
2.2. 処理署名プロトコル（ＲＦＣ２８４５）への修正
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.
Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
ＲＦＣ２８４５への修正は、たとえクライアントの要求が署名されなかっ
たとしても、２つのＤＮＳエンティティ間の多数のメッセージ交換での
明示的に指定された位置でサーバの応答に署名することを通じて処理署
名の使用を許します。特に、ＲＦＣ２８４５の４.２章が次のように修正
されなくてはなりません(MUST)：
Replace:
変更前：
"The server MUST not generate a signed response to an unsigned
request."
「サーバは署名なしの要求に対する署名された応答を生成してはなりませ
ん(MUST)。」
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."
「サーバは署名なしの要求に対する署名された反応を生成してはなりませ
ん(MUST)、例外はもしサーバがクライアントの要求の処理の後でサーバ側
で秘密鍵が確立した場合の、クライアントからの署名なしＴＥＫＹ質問の
応答です。署名なしＴＫＥＹ質問に対する応答に署名することは、個別の
秘密鍵設立アルゴリズムの記述で明示的に指定されなくてはなりません
(MUST)。」
3. Client Protocol Details
3. クライアントプロトコル詳細
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)
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は、お互いにど
のコンテキストが現在の要求を処理するために使われなくてはならない(MUST)
かを認識するための、クライアントとサーバ間で送られる処理鍵と処理署名レ
コードの所有者名です。
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).
ＤＮＳクライアントとサーバが、３章と４章で記述されるように、セキュリ
ティコンテキストを確立するために種々なインフラのセキュリティ機構を
使ってもよいです(MAY)。同時に、ＧＳＳ−ＴＳＩＧをサポートするＤＮＳク
ライアントとサーバ間の互換性を保証するために、クライアントが使用する
セキュリティメカニズムはＫｅｒｂｅｒｏｓ ｖ５を使用可能にする事を要求
します(REQUIRED)（より多くの情報は９章を参照）。
3.1. Negotiating Context
3.1. コンテキスト交渉
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.
ＧＳＳで、セキュリティコンテキストを確立することはクライアントとサー
バの間で不透明なトークンを渡す事を伴います。クライアントは最初のトー
クンを生成し、サーバに送ります。サーバはトークンを処理し、もし必要な
ら、クライアントに次のトークンを返します。クライアントは交渉が完了す
るまで、このトークンを処理します。クライアントとサーバがトークンを交
換する数は基礎となるセキュリティメカニズムによります。交渉が終わると
コンテキストハンドルが得られます。
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].
"GSS_Init_sec_context call", of [RFC2743] for syntax definitions.
処理鍵資源レコード[RFC2930]はクライアントとサーバ間でトークンを運ぶ媒
体として用いられます。処理鍵レコードは処理署名で使用する秘密鍵を確立
する一般的なメカニズムです。より多くの情報は[RFC2930]を見てください。
3.1.1. Call GSS_Init_sec_context
3.1.1. GSS_Init_sec_context呼出し
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を呼ばなくてはなりません(MUST)。
The following input parameters MUST be used. The outcome of the call
is indicated with the output values below. Consult Sections 2.2.1,
次の入力パラメータが使われなくてはなりません(MUST)。呼出し結果は下記
の出力値で示されます。構文定義は[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.
（NULLは「デフォルトの使用」の明示です）。クライアントが代わりに
その証明書の何か他の正当なハンドルを指定してもよいです(MAY)。
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).
実装者によって選択された基礎セキュリティメカニズム。ＧＳＳ−Ｔ
ＳＩＧメカニズムの実装互換性を保証するために、クライアントがケ
ルベロスｖ５の使用を可能にする基礎セキュリティメカニズムを指定
しなければなりません(MUST)（より多くの情報は９章を見てください）。
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.
（０がデフォルト価値を要求します）。クライアントが確立するコン
テキストの代わりの寿命を秒単位で指定してもよいです(MAY)。
OCTET STRING chan_bindings = Any valid channel bindings
as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
[RFC2743]で１.１.６章「チャンネル結合」で指定される任意の有効
なチャンネル結合。
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
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
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.
クライアントはアルゴリズムを断念しなければならず(MUST)、そしてこのセ
キュリティコンテキストを確立するためにＧＳＳ−ＴＳＩＧアルゴリズムを
使ってはなりません(MSUT NOT)。この文書はセキュリティコンテキストを確
立するためにどの他のメカニズムが使えるか規定しません。このクライアン
トが次にセキュリティコンテキストを確立する必要がある時は、クライアン
トはＧＳＳ−ＴＳＩＧアルゴリズムを使ってもよいです(MAY)。
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であり、そしてこれらの値の１つあるいは両
方ともが偽であるなら、クライアントはこのアルゴリズムを断念しなくては
なりません(MUST)。
Client's behavior MAY depend on other OUTPUT parameters according to
the policy local to the client.
クライアントの行動はクライアントのローカルポリシに従って他の出力パラ
メータに依存するかもしれません(MAY)。
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ハンドルはこの交渉に固有で、context_handleを
target_nameに対応付けるクライアントのマッピングテーブルに保管されます。
3.1.2. Send TKEY Query to Server
3.1.2. TKEY問合せをサーバへ送る
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でよって返された不透明な出力トークンはQTYPE=TKEY
の質問要求でサーバに送られます。トークン自身は問合せの追加レコードセ
クションの処理鍵資源レコードの資源データフィールドの鍵データフィール
ドに置かれるでしょう。質問した処理鍵資源レコード集合の所有者名と追加
レコード章で供給された処理鍵資源レコードの所有者名は同じであるに違い
ありません(MUST)。この名前はクライアントとサーバの両方で一意にセキュ
リティコンテキストを識別し、そしてクライアントは[RFC2930]で記述され
るようにグローバルに一意な値を使うべきです(SHOULD)。グローバルな一意
性を成し遂げるために、名前はUUID/GUID[ISO11578]を含んでいるかもしれ
ません(MAY)。
TKEY Record
NAME = client-generated globally unique domain name string
(as described in [RFC2930])
クライアントの生成したグローバルに一意なドメイン名文字列
（[RFC2930]で記述されるように）。
RDATA
Algorithm Name = gss-tsig
Mode = 3 (GSS-API negotiation - per [RFC2930])
（[RFC2930]によるＧＳＳ−ＡＰＩ交渉）
Key Size = size of output_token in octets
output_tokenのオクテット単位のサイズ
Key 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].
処理鍵資源データの残りのフィールド、すなわち、開始と、起源と、エラー
と、他サイズと、データフィールドは、[RFC2930]に従って設定されなくては
なりません(MUST)。
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以外の主状態を返したなら、クライ
アントは処理鍵の質問を送ってはなりません(MUST NOT)。クライアントの行
動はこの場合３.１.１章で記述されます。
3.1.3. Receive TKEY Query-Response from Server
3.1.3. サーバから処理鍵質問−応答の受信
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.
処理鍵問合せの受信時に、ＤＮＳサーバは４章の記述に従って返答しなくて
はなりません(MUST)。この章は、質問に対する応答を受け取った後の、クラ
イアントの行動を指定します。
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呼
出のmajor_status値に依存します：GSS_S_COMPLETEかGSS_S_CONTINUE 。
3.1.3.1. Value of major_status == GSS_S_COMPLETE
3.1.3.1. 主状態値＝GSS_S_COMPLETE
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で、
非ゼロ出力トークンがサーバに送られたなら、クライアント側の交渉要素は
完全で、クライアントはサーバから確認を待ち受けます。
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とクライアントが最後に供給した質問
の回答部の処理鍵レコードのかたちです。応答は処理署名レコードで署名さ
れなければなりません(MUST)。上記２.２章で指定されたＲＦＣ２８４５の修
正で、サーバ署名されていないクライアントの問合せに署名する事が許され
るのに注意してください。処理鍵レコードでの署名は５章の署名メッセージ
の送信と検証で詳述された手順で検証ししなければなりません(MUST)。もし
応答が署名されないなら、あるいはもし応答が署名されるが署名が無効であ
るなら、それから攻撃者が転送メッセージを不法に変更したか、あるいはク
ライアントに虚偽の応答を送ろうと試みました。この場合、クライアントが
送った最後の処理鍵の質問が期限が切れるまで、クライアントは最後の処理
鍵の質問に対する応答を待ち続けてもよいです(MAY)。このような期間はク
ライアントのローカルポリシで指定されます。これはＤＮＳクライアントが
１つの問合せＩＤの多数の応答を受け入れて、そしてある基準に基づいて１
つ（必ずしも最初のではない）を選ぶことを許す新しい選択肢です。
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.1.3.2. Value of major_status == GSS_S_CONTINUE_NEEDED
3.1.3.1. 主状態値＝GSS_S_CONTINUE_NEEDED
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なら、交渉はまだ完全ではありません。サーバは回答
部の処理鍵レコードでクライアントに質問応答を返すでしょう。もしＤＮＳ
メッセージエラがNO_ERRORではないか、あるいは処理鍵レコードのエラー
フィールドが０（すなわち、エラー）ではないなら、クライアントはこの交
渉を断念しなくてはなりません(MUST)。クライアントは
GSS_Delete_sec_contextに関連したcontext_handleを渡して呼出し活性化し
たコンテキストをを削除しなくてはなりません(MUST)。クライアントは３.１
章で記述されるように初期化されていない状態で開始した交渉を繰り返して
もよいです(MAY)。無限ループを避けるために、セキュリティコンテキスト
を確立する試みの数は１０以下に制限されなくてはなりません(MUST)。
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:
もしＤＮＳメッセージエラーが NO_ERRORであり、処理鍵レコードのエラーフィー
ルドが０（すなわち、エラー）ではないなら、クライアントは、下記の
CONTEXT HANDLE input_context_handleとOCTET STRING input_tokenを除き、
前の呼出しと同じパラメータで、GSS_Init_sec_contextに処理鍵資源レコー
ドで鍵データフィールドで指定されたトークンを設定し、渡さなければなり
ません(MUST)：
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)
context_handle（これは処理鍵質問の応答の回答部の処理鍵レコード
の所有者名であるkey_nameに対応するcontext_handleです）。
OCTET STRING input_token = token from Key field of
TKEY record
処理鍵レコードの鍵フィールド
からのトークン。
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:
クライアントは次の行動の１つをとらなくてはなりません(MUST)：
If OUTPUT major_status is set to one of the following values:
もし出力主状態が次の値の１つに設定されるなら：
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.
クライアントはこの交渉の連続を断念しなくてはなりません(MUST)。これは
クライアントは関連したcontext_handleを供給するGSS_Delete_sec_context
を呼ぶ事でアクティブなコンテキストを削除しなければならない(MUST)こと
を意味します。クライアントは３.１章で記述されるように初期化されてい
ない状態から開始して交渉を繰り返してもよいです(MAY)。無限ループを妨
げるために、セキュリティコンテキストを確立する試みの数は１０以下に制
限されなくてはなりません(MUST)。
If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE
then client MUST act as described below.
もし出力主状態がGSS_S_CONTINUE_NEEDEDあるいはGSS_S_COMPLETEであるなら、
クライアントが下に記述されるように、行動をしなくてはなりません(MUST)。
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.
もしサーバからの応答が署名され、そして出力主状態がGSS_S_COMPLETEであ
るなら、処理署名レコードの署名は５章の署名メッセージの送信と検証で詳
述された手順を使って検証されなければなりません(MUST)。もし署名が無効
であるなら、クライアントはこの交渉を断念しなくてはなりません(MUST)。
これはクライアントがcontext_handleで供給されるアクティブなコンテキス
トをGSS_Delete_sec_contextを呼ぶことで削除しなければならないことを意
味します(MUST)。クライアントは３.１章で記述されるように初期化されてい
ない状態の交渉を繰り返してもよいです(MAY)。無限ループを避けるために、
セキュリティコンテキストを確立する試みは１０回以下に制限されなくては
なりません(MUST)。
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.
もし主状態がGSS_S_CONTINUE_NEEDEDであるなら、交渉はまだ終了していませ
ん。トークンoutput_tokenは３.１.２章で開始した交渉を繰り返すことで処
理鍵レコードでサーバに渡されなくてはなりません(MUST)。クライアントは
無限ループを避けるため、コンテキスト交渉の継続回数に上限を置かなくて
はなりません(MUST)。このような上限は１０を超えるべきではありません
(SHOULD NOT)。
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.
もし主状態がGSS_S_COMPLETEで、output_tokenがヌルでないなら、交渉のク
ライアント側の要素は完全です、しかしトークンoutput_tokenは３.１.２章
で始まる交渉を繰り返すことでサーバに渡されなくてはなりません(MUST)。
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.
もし主状態がGSS_S_COMPLETEで、output_tokenがヌルであるなら、文脈交渉
は完了です。コンテキスト状態は確立したコンテキストに進みます。セキュ
リティコンテキストの使用のために３.２章に進んでください。
3.2. Context Established
3.2. 確立したコンテキスト
When context negotiation is complete, the handle context_handle MUST
be used for the generation and verification of transaction
signatures.
コンテキスト交渉が完了した時、ハンドルcontext_handleは取引署名の生成
と検証に使われなくてはなりません(MUST)。
The procedures for sending and receiving signed messages are
described in section 5, Sending and Verifying Signed Messages.
署名メッセージをの送信と受信の手順は、５章の署名メッセージの送信と検
証で記述されます。
3.2.1. Terminating a Context
3.2.1. コンテキスト終了
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を呼出す事
でアクティブなコンテキストを削除するべきで(SHOULD)、そしてクライアン
トはモードフィールドを５、つまり「鍵削除」[RFC2930]、に設定した処理鍵
資源レコードを使うことによってＤＮＳサーバ上に確定したコンテキストを
削除するべきです(SHOULD)。
4. Server Protocol Details
4. サーバープロトコル詳細
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:
サーバがいくつかのクライアントのいくつかのコンテキストを管理している
かもしれません(MAY)。クライアントが要求で鍵名を供給することでコンテキ
ストを識別します。サーバはハンドルと鍵名の対応を維持します：
(key_name, context_handle)
4.1. Negotiating Context
4.1. コンテキスト交渉
A server MUST recognize TKEY queries as security context negotiation
messages.
サーバが処理鍵の質問をセキュリティコンテキスト交渉メッセージとして認
知しなくてはなりません(MUST)。
4.1.1. Receive TKEY Query from Client
4.1.1. クライアントからの処理鍵質問の受信
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で問合せを受取ると、サーバはメッセージの追加レコード部の中
の処理鍵レコードのモードとアルゴリズム名フィールドがそれぞれ３の値と
gss-tsigを含んでいるかどうか吟味しなくてはなりません(MUST)。もしそう
なら、(key_name, context_handle)対応表から質問の追加レコード章の処理
鍵レコードの所有者名に合っているkey_nameを捜索します。もし名前が表か
ら見つかり、この名前のためのセキュリティコンテキストが確立されていて、
そして期限が切れてなければ、サーバは処理鍵エラーフィールドにBADNAME
エラーを設定し問合せに返答しなくてはなりません(MUST)。もし名前が表に
見つかるが、セキュリティコンテキストが確立されなていない、対応する
context_handleは次のGSSオペレーションで使われます。名前が見つかったら
セキュリティコンテキストが期限が切れなら、サーバは４.２.１章で記述さ
れるように、このセキュリティコンテキストを削除して、そして新しいセキュ
リティコンテキスト交渉の開始とこの問合せを解釈して、そして４.１.２章
と４.１.３章で記述されたオペレーションを行います。もし名前が見つから
なければ、サーバはこの問合せを新しいセキュリティコンテキスト交渉の開
始と解釈し、４.１.２章と４.１.３章で記述されたオペレーションを行います。
4.1.2. Call GSS_Accept_sec_context
4.1.2. GSS_Accept_sec_context呼出
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を呼出す事でサーバ側のコンテキスト交渉
を行います。次の入力パラメータが使われなくてはなりません(MUST)。呼出
結果は下の出力値で示されます。構文定義はＲＦＣ２７４３[RFC2743]の
２.２.２章の「GSS_Accept_sec_context呼出」を調べてください。
INPUTS
CONTEXT HANDLE input_context_handle = 0 if new negotiation,
context_handle matching
key_name if ongoing negotiation
もし新しい交渉なら０、
もし継続中の交渉なら、
key_nameに一致するcontext_handle。
OCTET STRING input_token = token specified in the Key
field from TKEY RR (from Additional records Section of
the client's query)
（クライアントの質問の追加のレコード章の）処理鍵資源レコードの
鍵フィールドで指定されたトークン。
CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
default"). Server MAY instead specify some other valid
handle to its credentials.
（ヌルが「デフォルトの使用」の明示です）。サーバ代わりに他の証
明書の正当なハンドルを指定してもよいです(MAY)。
OCTET STRING chan_bindings = Any valid channel bindings
as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
[RFC2743]の１.１.６章の「チャンネル結合」で指定される有効なチャ
ンネル結合。
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
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と
してサーバ鍵対応表に保存されます。
4.1.3. Send TKEY Query-Response to Client
4.1.3. クライアントに処理鍵応答の送信
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で処理鍵質問の回答をクライアントに返さなければ
なりません(MUST)、これは解答部に処理鍵レコードを含んでいます。
If OUTPUT major_status is one of the following errors the error field
in the TKEY record set to BADKEY.
もし出力主状態が次のエラーの１つであるなら、処理鍵レコードのエラー
フィールドは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.
もし出力主状態がGSS_S_COMPLETEかGSS_S_CONTINUE_NEEDEDであるなら、サー
バが、下に記述されるように、行動しなくてはなりません(MUST)。
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.
もし主状態がGSS_S_COMPLETEであるなら、交渉のサーバ要素は終わります。
もしoutput_tokenがヌルでないなら、それは処理鍵の資源データの鍵データ
フィールドでクライアントに返されなくてはなりません(MUST)。処理鍵レコー
ドのエラーフィールドはNOERRORに設定されます。メッセージは５章の署名
メッセージの送信と検証で記述されたように、処理署名レコードで署名され
なくてはなりません(MUST)。そのサーバが上記の２.２章で指定されたＲＦＣ
２８４５の修正によって、署名なしのクライアント問合せに対する反応に署
名することを許されることに注意してください。コンテキスト状態は確立さ
れたコンテキストに進められます。４.２章がセキュリティコンテキストの
使用法を論じます。
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.
もし主状態がGSS_S_COMPLETEで、output_tokenがヌルであるなら、クライア
ントから受信した処理鍵レコードは応答の解答部で返されなくてはなりませ
ん。メッセージは５章の署名メッセージの送信と検証で記述されたように、
処理署名レコードで署名されなくてはなりません(MUST)。そのサーバが上記
の２.２章で指定されたＲＦＣ２８４５の修正によって、署名なしのクライ
アント問合せに対する反応に署名することを許されることに注意してくださ
い。コンテキスト状態は確立されたコンテキストに進められます。４.２章
がセキュリティコンテキストの使用法を論じます。
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.
もし主状態がGSS_S_CONTINUE_NEEDEDであるなら、交渉のサーバ要素はまだ
終了していません。サーバは、output_tokenを鍵データ資源データフィール
ドに含む処理鍵レコードを解答部に設定した、標準的な問合せ応答で、処理
鍵の問合せに応答します。処理鍵レコードのエラーフィールドはNOERRORに
設定されます。サーバは無限ループが発生するのを妨げるため、コンテキス
トで繰返しが許される回数を制限しなくてはなりません(MUST)。このような
限界値は１０を超えるないべきです(SHOULD NOT)。
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:
主状態がGSS_S_COMPLETEで、output_tokenがヌルである場合を除き、全ての
場合で他の処理鍵レコードフィールドが次の値を含んでいなくてはなりませ
ん(MUST)：
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].
処理鍵資源データの残りのフィールド、すなわち、開始と起源とエラーと他
のサイズとデータフィールドは[RFC2930]に従って設定しなければなりません。
4.2. Context Established
4.2. 確立したコンテキスト
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は署名の生成と検
証に使われます。ハンドルはセキュリティメカニズムの決定した有限量の時
間の間、有効です。サーバはいつでも一方的にコンテキストを終了できます
(MAY)（４.２.１章参照）。
Server SHOULD limit the amount of memory used to cache established
contexts.
サーバが確立したコンテキストをキャッシュするために使うメモリの量を制
限するべきです(SHOULD)。
The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages.
署名メッセージの送受信手順は５章の署名メッセージの送信と検証で与えら
れます。
4.2.1. Terminating a Context
4.2.1. コンテキスト終了
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.
サーバがいつでも確立したコンテキストを終了できます。サーバはモードフィー
ルドを５、すなわち「鍵削除」[RFC2930]に設定した処理鍵資源レコードを応
答に含めることでクライアントにコンテキストが削除されていることを暗示
してもよいです(MAY)。アクティブなコンテキストはcontext_handleを示して
GSS_Delete_sec_contextを呼ぶことで削除されます。
5. Sending and Verifying Signed Messages
5. 署名メッセージの送信と検証
5.1. Sending a Signed Message - Call GSS_GetMIC
5.1. 署名メッセージ送信−GSS_GetMIC呼出
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]で指定されま
す。署名ルーチンに渡されるデータは、特定の処理署名変数を持つＤＮＳメッ
セージ全体です。厳密なフォーマットは[RFC2845]を見てください。このプロ
トコルで次の処理署名変数値を使います：
TSIG Record
NAME = key_name that identifies this context
RDATA
Algorithm Name = gss-tsig
Assign the remaining fields in the TSIG RDATA appropriate values as
described in [RFC2845].
[RFC2845]で記述されるように、処理署名資源データの適切な値を残りのフィー
ルドを割り当てます。
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呼出によって生成されます。次の入力パラメータが使われ
なくてはなりません(MUST)。呼出の結果は下に指定された出力値で示されま
す。構文論定義はＲＦＣ２７４３[RFC2743]の２.３.１章「GSS_GetMIC呼出」
を調べてください。
INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name
key_nameのためのcontext_handle。
OCTET STRING message = outgoing message plus TSIG
variables (per [RFC2845])
外向きメッセージ足す処理署名変数
（[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])
（０がデフォルト値を要求します）。呼出し者が代わりに他の有効
な値を指定してもよいです(MAY)（詳細は[RFC2743]の１.２.４章参照）。
OUTPUTS
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.
もし主状態がGSS_S_COMPLETEであるなら、署名生成が成功しました。
per_msg_tokenの署名は処理署名資源レコードの署名フィールドに挿入され、
そしてメッセージは伝達されます。
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
もし主状態がGSS_S_CONTEXT_EXPIREDかGSS_S_CREDENTIALS_EXPIREDか
GSS_S_FAILURE であるなら、呼出し者はセキュリティコンテキストを削除し
(MUST)、初期化されていない状態に戻り、そして上記３.１章で記述される
ように、新しいセキュリティコンテキストを交渉するべきです(SHOULD)。
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
もし主状態がGSS_S_NO_CONTEXTであるなら、呼出し者はkey_nameの項目を
(target_ name, key_name, context_handle)対応表から 削除し(MUST)、初
期化されていない状態に戻り、そして上記３.１章で記述されるように、新
しいセキュリティコンテキストを交渉するべきです(SHOULD)。
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.
もし主状態がGSS_S_BAD_QOPであるなら、呼出し者は許されたＱＯＰ値で
GSS_GetMIC呼出を繰り返すべきです(SHOULD)。このような反復の数は無限ルー
プを妨げるために限定されなければなりません(MUST)。
5.2. Verifying a Signed Message - Call GSS_VerifyMIC
5.2. 署名メッセージの検証−GSS_VerifyMIC呼出
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]).
処理署名レコードの名前はどのコンテキストに対応するcontext_handleを署
名を検証するために使う(MUST)か決定します。もし名前が確立したコンテキ
ストに対応しないなら、サーバは（[RFC2845]で記述されるように）処理署
名エラーフィールドでBADKEYを示してクライアントに標準処理署名エラー応
答を送らなくてはなりません(MUST)。
For the GSS algorithm, a signature is verified by using
GSS_VerifyMIC:
ＧＳＳアルゴリズムで、署名がGSS_VerifyMICを使うことで検証されます：。
INPUTS
CONTEXT HANDLE context_handle = context_handle for key_name
key_nameのためのcontext_handle。
OCTET STRING message = incoming message plus TSIG
variables (per [RFC2845])
内向きメッセージ足す処理署名変数
（[RFC2845]による）。
OCTET STRING per_msg_token = Signature field from TSIG RR
処理署名資源レコードからの署名
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.
もし主状態がGSS_S_COMPLETEであるなら、署名は正く、メッセージはそこな
われずに届けられました。[RFC2845]によって、処理署名レコードのタイマ
値はメッセージが正しいと考える前に有効であるに違いありません(MUST)。
呼出し者は、これらの検査が実証されるまで、メッセージの要求や応答に対
して行動してはなりません(MUST not)。
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]で記述される処理署名エラーフィー
ルドにBADKEYを示してクライアントに標準処理署名エラー応答を送らなけれ
ばなりません(MUST)。
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].
もし処理署名レコードのタイマ値が無効であるなら、メッセージは正しいと
思われてはなりません(MUST NOT)。もしサーバがクライアント要求を処理し
ている時、このエラー検査に失敗するなら、適切なエラー応答が[RFC2845]
に従ってクライアントに送られなくてはなりません(MUST)。
6. Example usage of GSS-TSIG algorithm
6. ＧＳＳ−ＴＳＩＧアルゴリズムの使用例
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
The OUTPUTS parameters returned by GSS_Init_sec_context include
GSS_Init_sec_contextの出力パラメータは以下を含みます
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
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値が真であることを確かめ
ます。主状態がGSS_S_CONTINUE_NEEDEDで、これは成功出力主状態値なので、
クライアントは「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 の問合せを送
ります。問合せは次のフィールドの処理鍵レコード追加レコード章に含みます。
（このアルゴリズムで重要でないフィールドは指定されないことに注意してく
ださい。）
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
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.
鍵名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で問合せを受け取る時、サーバは問合せの追加レコー
ド部の処理鍵レコードのモードとアルゴリズムフィールドがそれぞれ３と
"gss-tsig"に設定されている事を確認します。そして(key_name,
context_handle)対応表に鍵名789.client.example.com.server.example.com.
がないことに気付きます。
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)
The OUTPUTS parameters returned by GSS_Accept_sec_context include
GSS_Accept_sec_contextの出力パラメターは以下を含みます。
INTEGER major_status = GSS_S_CONTINUE_NEEDED
CONTEXT_HANDLE output_context_handle context_handle
OCTET STRING output_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と出力コンテキストハ
ンドルの対応をits (key_name, context_handle対応表の保存します。
V. Server responds to the TKEY query
V. サーバの処理鍵問合せ返答
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への呼出の主状態＝
GSS_S_CONTINUE_NEEDEDなので、サーバは鍵データ資源データフィールドに
出力トークンを含む処理鍵レコードを解答部に置いて処理鍵の問合せに応答
します。処理鍵レコードのエラーフィールドは０に設定されます。質問回答
での応答コードは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
The OUTPUTS parameters returned by GSS_Init_sec_context include
GSS_Init_sec_contextの出力パラメターは以下を含みます。
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
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.
主状態がGSS_S_COMPLETEなので、クライアント側のセキュリティコンテキスト
は確立されます、しかし出力トークンがヌルでないので、クライアントが下記
のように、サーバに処理鍵問合せを送らなくてはなりません。
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のためにサー
バに処理鍵問合せを送ります。問合せは以下のフィールを持つ処理鍵レコード
を追加レコード章に含みます。（このアルゴリズムで重要でない入出力パラメー
タがこの例で記述されないことに注意してください）。
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
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.
サーバが処理鍵問合せを受信する時、サーバは問合せの追加レコード部の処理
鍵レコードのモードとアルゴリズムフィールドがそれぞれ３とgss-tsigに設定
されていることを確かめます。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)
The OUTPUTS parameters returned by GSS_Accept_sec_context include
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.
主状態＝GSS_S_COMPLETEなので、サーバ側のセキュリティコンテキストは確立
されますが、サーバはまだ下記のように、クライアントの処理鍵問合せに応答
する必要があります。セキュリティコンテキスト状態は確立されたコンテキス
トに進みます。
X. Server responds to the TKEY query
X. サーバの処理鍵問合せ応答
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呼出の主状態＝GSS_S_COMPLETEで、出
力トークンがヌルなので、サーバは、クライアントからの最後の処理鍵問合せ
で解答部に設定されていた、処理鍵レコードを処理鍵応答の解答部に設定し返
答します。加えて、このサーバは処理鍵レコードをその解答の追加レコード部
に置きます。サーバが処理署名レコードを含めた署名を生成するために、
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])
The OUTPUTS parameters returned by GSS_GetMIC include
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.
処理署名の署名フィールドが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:
クライアントがサーバから処理鍵問合せ応答を受け取ります。最後の
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
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.
出力パラメータ主状態＝GSS_S_COMPLETEから、署名は有効です、セキュリティ
交渉は完全で、そしてセキュリティコンテキスト状態は確立されたコンテキス
トに進められます。これらのクライアントとサーバは、コンテキストの期限が
切れるまで、パケットをお互いに交換する時、署名と署名検証に確立されたセ
キュリティコンテキストを使うでしょう。
7. Security Considerations
7. セキュリティの考察
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.
この文章はＧＳＳ−ＡＰＩを使うＤＮＳセキュリティのためのプロトコルを
記述します。このプロトコルによって供給されたセキュリティ管理は基礎Ｇ
ＳＳメカニズムの供給したセキュリティと同じぐらいの効果だけです。
All the security considerations from RFC 2845, RFC 2930 and RFC 2743
apply to the protocol described in this document.
ＲＦＣ２８４５とＲＦＣ２９３０とＲＦＣ２７４３のすべてのセキュリティ
の考察はこの文書で記述されたプロトコルに当てはまります。
8. IANA Considerations
8. ＩＡＮＡの考慮
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.
ＩＡＮＡは処理鍵と処理署名資源レコードのアルゴリズムフィールドで使用
する、処理署名アルゴリズム名gss-tsig を確保しました。このアルゴリズム
名はこの文書で記述されたアルゴリズムに関係します。この名前がＩＡＮＡ
に登録される必要条件はＲＦＣ２８４５で指定されます。
9. Conformance
9. 適合性
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
ＳＰＮＥＧＯ[RFC2478]を使用するＧＳＳ ＡＰＩはセキュリティコンテキス
ト交渉を可能にする基礎セキュリティメカニズムを選択する最大の柔軟性を
供給します。ＳＰＮＥＧＯ[RFC2478]を使用するＧＳＳ ＡＰＩはクライアン
トとサーバが交渉して、その場その場でこのような基礎セキュリティメカニ
ズムを選択することができるようにします。このような柔軟性をサポートす
るために、ＤＮＳクライアントとサーバはＧＳＳ ＡＰＩ呼出しでＳＰＮＥ
ＧＯメカニズム種別を指定するべきです(SHOULD)。同時に、ＧＳＳ−ＴＳＩ
ＧをサポートするＤＮＳクライアントとサーバ間で互換性を保証するために、
以下を要求します。
- 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.
- ＤＮＳサーバに呼び出されるＧＳＳ ＡＰＩがＳＰＮＥＧＯ[RFC2478]と
ケルベロスｖ５をサポートします。
In addition to these, GSS APIs used by DNS client and server MAY also
support other underlying security mechanisms.
ＤＮＳクライアントとサーバが使用するＧＳＳ ＡＰＩはこれらのほかに基
礎セキュリティメカニズムをサポートするかもしれません(MAY)。
10. Intellectual Property Statement
10. 知的所有権宣言
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.
この文書に記述された実装や技術に関して主張される知的財産や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する調査をしたとは述べません。ＩＥＴＦ標準手続きと標準関連文書で
の権利に関しての手順の情報はＢＣＰ１１を見てください。出版に利用する
権利の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書
の実装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの
結果はＩＥＴＦ事務局で得られます。
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.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかＩＥＴＦ専務に情報を伝えてください。
11. Acknowledgements
11. 謝辞
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.
この文書の著者はこの仕様書の貢献に対して次の人々に感謝します：Chuck
ChanとMike SwiftとRam ViswanathanとOlafur Gudmundssonと
Donald E. Eastlake, 3rdとErik Nordmark.
12. References
12. 参考文献
12.1. Normative References
12.1. 参照する参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface, Version 2 , Update 1", RFC 2743, January 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
12.2. Informative References
12.2. 有益な参考文献
[ISO11578] "Information technology", "Open Systems Interconnection",
"Remote Procedure Call", 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.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1034, November 1987.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
1964, June 1996.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996.
[RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic
Update", RFC 2137, April 1997.
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
13. Authors' Addresses
13. 著者のアドレス
Stuart Kwan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: skwan@microsoft.com
Praerit Garg
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: praeritg@microsoft.com
James Gilroy
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: jamesg@microsoft.com
Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: levone@microsoft.com
Randy Hall
Lucent Technologies
400 Lapp Road
Malvern PA 19355
USA
EMail: randyhall@lucent.com
Jeff Westhead
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: jwesth@microsoft.com
14. Full Copyright Statement
14. 著作権表示全文
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。