RFC2930 日本語訳
2930 Secret Key Establishment for DNS (TKEY RR). D. Eastlake 3rd. September 2000. (Format: TXT=34894 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Eastlake, 3rd Request for Comments: 2930 Motorola Category: Standards Track September 2000
ワーキンググループのD.イーストレーク、コメントを求める第3要求をネットワークでつないでください: 2930年のモトローラカテゴリ: 標準化過程2000年9月
Secret Key Establishment for DNS (TKEY RR)
DNSのための秘密鍵設立(TKEY RR)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
[RFC 2845] provides a means of authenticating Domain Name System (DNS) queries and responses using shared secret keys via the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server.
[RFC2845]はTransaction Signature(TSIG)リソース記録(RR)で共有秘密キーキーを使用することでドメインネームシステム(DNS)質問と応答を認証する手段を提供します。 しかしながら、それは手動交換以外のそのようなキーをセットアップするのにメカニズムを全く提供しません。 このドキュメントはDNSレゾルバとサーバの間の共有秘密キーキーを証明するのに多くの異なったモードで使用できるTransaction Key(TKEY)RRについて説明します。
Acknowledgments
承認
The comments and ideas of the following persons (listed in alphabetic order) have been incorporated herein and are gratefully acknowledged:
以下の人々(アルファベット順に記載されています)のコメントと考えは、ここに法人組織であり、感謝して承諾されます:
Olafur Gudmundsson (TIS)
Olafurグドムンソン(TIS)
Stuart Kwan (Microsoft)
スチュアート・クワン(マイクロソフト)
Ed Lewis (TIS)
Ed Lewis(TIS)
Erik Nordmark (SUN)
エリックNordmark(太陽)
Brian Wellington (Nominum)
ブライアン・ウェリントン(Nominum)
Eastlake Standards Track [Page 1] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[1ページ]。
Table of Contents
目次
1. Introduction............................................... 2 1.1 Overview of Contents...................................... 3 2. The TKEY Resource Record................................... 4 2.1 The Name Field............................................ 4 2.2 The TTL Field............................................. 5 2.3 The Algorithm Field....................................... 5 2.4 The Inception and Expiration Fields....................... 5 2.5 The Mode Field............................................ 5 2.6 The Error Field........................................... 6 2.7 The Key Size and Data Fields.............................. 6 2.8 The Other Size and Data Fields............................ 6 3. General TKEY Considerations................................ 7 4. Exchange via Resolver Query................................ 8 4.1 Query for Diffie-Hellman Exchanged Keying................. 8 4.2 Query for TKEY Deletion................................... 9 4.3 Query for GSS-API Establishment........................... 10 4.4 Query for Server Assigned Keying.......................... 10 4.5 Query for Resolver Assigned Keying........................ 11 5. Spontaneous Server Inclusion............................... 12 5.1 Spontaneous Server Key Deletion........................... 12 6. Methods of Encryption...................................... 12 7. IANA Considerations........................................ 13 8. Security Considerations.................................... 13 References.................................................... 14 Author's Address.............................................. 15 Full Copyright Statement...................................... 16
1. 序論… 2 コンテンツの1.1概要… 3 2. TKEYリソース記録… 4 2.1 名前欄… 4 2.2 TTL分野… 5 2.3 アルゴリズム分野… 5 2.4 始まりと満了分野… 5 2.5 モード分野… 5 2.6 誤り分野… 6 2.7 主要なサイズとデータ・フィールド… 6 2.8 他のサイズとデータ・フィールド… 6 3. 一般TKEY問題… 7 4. Resolver Queryを通した交換… 8 ディフィー-ヘルマンのための4.1質問は合わせることを交換しました… 8 4.2 TKEYには、削除について質問してください… 9 4.3 GSS-API設立のために、質問します。 10 サーバのための4.4質問は合わせることを割り当てました… 10 レゾルバのための4.5質問は合わせることを割り当てました… 11 5. 自然発生的なサーバ包含… 12 5.1 自然発生的なサーバ主要な削除… 12 6. 暗号化のメソッド… 12 7. IANA問題… 13 8. セキュリティ問題… 13の参照箇所… 14作者のアドレス… 15 完全な著作権宣言文… 16
1. Introduction
1. 序論
The Domain Name System (DNS) is a hierarchical, distributed, highly available database used for bi-directional mapping between domain names and addresses, for email routing, and for other information [RFC 1034, 1035]. It has been extended to provide for public key security and dynamic update [RFC 2535, RFC 2136]. Familiarity with these RFCs is assumed.
ドメインネームシステム(DNS)はドメイン名とアドレスの間の双方向のマッピング、メールルーティング、および他の情報に使用される階層的で、分配されて、非常に利用可能なデータベース[RFC1034、1035]です。 公開鍵セキュリティとダイナミックなアップデート[RFC2535、RFC2136]に備えるためにそれを広げてあります。 これらのRFCsへの親しみは想定されます。
[RFC 2845] provides a means of efficiently authenticating DNS messages using shared secret keys via the TSIG resource record (RR) but provides no mechanism for setting up such keys other than manual exchange. This document specifies a TKEY RR that can be used in a number of different modes to establish and delete such shared secret keys between a DNS resolver and server.
[RFC2845]は、TSIGリソース記録(RR)で共有秘密キーキーを使用することで効率的にDNSメッセージを認証する手段を提供しますが、手動交換以外のそのようなキーをセットアップするのにメカニズムは全く提供しません。 このドキュメントはDNSレゾルバとサーバの間のそのような共有秘密キーキーを設立して、削除するのに多くの異なったモードで使用できるTKEY RRを指定します。
Eastlake Standards Track [Page 2] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[2ページ]。
Note that TKEY established keying material and TSIGs that use it are associated with DNS servers or resolvers. They are not associated with zones. They may be used to authenticate queries and responses but they do not provide zone based DNS data origin or denial authentication [RFC 2535].
材料を合わせながら設立されたTKEYとそれを使用するTSIGsがDNSサーバかレゾルバに関連していることに注意してください。 それらはゾーンに関連づけられません。 質問と応答を認証するのに使用されるかもしれませんが、それらはベースのDNSデータ発生源か否定認証[RFC2535]をゾーンに提供しません。
Certain modes of TKEY perform encryption which may affect their export or import status for some countries. The affected modes specified in this document are the server assigned mode and the resolver assigned mode.
TKEYのあるモードはそれらの輸出か輸入状態に影響するかもしれない暗号化をいくつかの国に実行します。 本書では指定された影響を受けるモードは、モードが割り当てられたサーバとモードが割り当てられたレゾルバです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
In all cases herein, the term "resolver" includes that part of a server which may make full and incremental [RFC 1995] zone transfer queries, forwards recursive queries, etc.
ここに、「レゾルバ」という用語が含む離れている完全で増加[RFC1995]のゾーン転送を質問にするかもしれないサーバ、リカーシブが質問するフォワードなどのすべての場合で
1.1 Overview of Contents
1.1 コンテンツの概要
Section 2 below specifies the TKEY RR and provides a description of and considerations for its constituent fields.
以下のセクション2は、TKEY RRを指定して、構成している分野への記述と問題を提供します。
Section 3 describes general principles of operations with TKEY.
セクション3はTKEYとの操作の綱領について説明します。
Section 4 discusses key agreement and deletion via DNS requests with the Query opcode for RR type TKEY. This method is applicable to all currently defined TKEY modes, although in some cases it is not what would intuitively be called a "query".
セクション4はRRタイプTKEYのためにQuery opcodeとのDNS要求で主要な協定と削除について論じます。 このメソッドはすべての現在定義されたTKEYモードに適切です、それがいくつかの場合直観的に「質問」と呼ばれるものではありませんが。
Section 5 discusses spontaneous inclusion of TKEY RRs in responses by servers which is currently used only for key deletion.
セクション5はサーバによる応答での現在主要な削除にだけ使用されるTKEY RRsの自然発生的な包含について論じます。
Section 6 describes encryption methods for transmitting secret key information. In this document these are used only for the server assigned mode and the resolver assigned mode.
セクション6は秘密鍵情報を伝えるための暗号化メソッドを説明します。 本書ではこれらはモードが割り当てられたサーバとモードが割り当てられたレゾルバにだけ使用されます。
Section 7 covers IANA considerations in assignment of TKEY modes.
セクション7はTKEYモードの課題におけるIANA問題をカバーします。
Finally, Section 8 provides the required security considerations section.
最終的に、セクション8は必要なセキュリティ問題部を提供します。
Eastlake Standards Track [Page 3] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[3ページ]。
2. The TKEY Resource Record
2. TKEYリソース記録
The TKEY resource record (RR) has the structure given below. Its RR type code is 249.
TKEYリソース記録(RR)で、構造を以下に与えます。 RRタイプコードは249です。
Field Type Comment
----- ---- -------
フィールド・タイプコメント----- ---- -------
NAME domain see description below
TTYPE u_int16_t TKEY = 249
CLASS u_int16_t ignored, SHOULD be 255 (ANY)
TTL u_int32_t ignored, SHOULD be zero
RDLEN u_int16_t size of RDATA
RDATA:
Algorithm: domain
Inception: u_int32_t
Expiration: u_int32_t
Mode: u_int16_t
Error: u_int16_t
Key Size: u_int16_t
Key Data: octet-stream
Other Size: u_int16_t
Other Data: octet-stream undefined by this specification
NAMEドメインは、ゼロがRDATA RDATAのRDLEN u_int16_tサイズであったなら249CLASS u_t TKEY=_int16_tが無視したTTYPE u_int16、SHOULDの下の記述が(いずれ)のTTL u_int32_tが無視した255、SHOULDであることがわかります: アルゴリズム: ドメインInception: _u int32_t Expiration: _u int32_t Mode: _u int16_t Error: _u int16_t Key Size: _u int16_t Key Data: 八重奏ストリームOther Size: _u int16_t Other Data: この仕様によって未定義の八重奏ストリーム
2.1 The Name Field
2.1 名前欄
The Name field relates to naming keys. Its meaning differs somewhat with mode and context as explained in subsequent sections.
Name分野は命名キーに関連します。 意味はその後のセクションで説明されるようにモードと文脈といくらか異なっています。
At any DNS server or resolver only one octet string of keying material may be in place for any particular key name. An attempt to establish another set of keying material at a server for an existing name returns a BADNAME error.
合わせることのどんなDNSサーバかレゾルバの1つの八重奏だけのストリングではも、材料はどんな特定の主要な名前のためにも適所にあるかもしれません。 既存の名前のためにサーバにおける材料を合わせるもう1セットを設立する試みはBADNAME誤りを返します。
For a TKEY with a non-root name appearing in a query, the TKEY RR name SHOULD be a domain locally unique at the resolver, less than 128 octets long in wire encoding, and meaningful to the resolver to assist in distinguishing keys and/or key agreement sessions. For TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD be a globally unique server assigned domain.
非根の名が質問、SHOULDというTKEY RR名に現れているTKEYに関しては、レゾルバで局所的にユニークなドメイン、キーを区別する助けるワイヤコード化で長くて、レゾルバに、重要な128未満の八重奏、そして/または、主要な協定セッションになってください。 質問、SHOULDというTKEY RR名への応答に現れるTKEY(s)に関してはグローバルにユニークなサーバ割り当てられたドメインになってください。
A reasonable key naming strategy is as follows:
戦略を命名する妥当なキーは以下の通りです:
If the key is generated as the result of a query with root as its
owner name, then the server SHOULD create a globally unique domain
name, to be the key name, by suffixing a pseudo-random [RFC 1750]
label with a domain name of the server. For example
89n3mDgX072pp.server1.example.com. If generation of a new
キーが質問の結果として所有者名としての根で生成されるなら、サーバSHOULDは、サーバのドメイン名があるsuffixingするのによる擬似ランダム[RFC1750]ラベルという例えばという主要な名前89n3mDgX072pp. server1.example.comになるようにグローバルにユニークなドメイン名を作成します。 a新しいことの世代です。
Eastlake Standards Track [Page 4] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[4ページ]。
pseudo-random name in each case is an excessive computation load
or entropy drain, a serial number prefix can be added to a fixed
pseudo-random name generated an DNS server start time, such as
1001.89n3mDgX072pp.server1.example.com.
擬似ランダム名がその都度過度の計算負荷かエントロピードレインである、DNSサーバ開始時刻であると生成された固定擬似ランダム名に通し番号接頭語を追加できます、1001.89n3mDgX072pp. server1.example.comなどのように。
If the key is generated as the result of a query with a non-root
name, say 789.resolver.example.net, then use the concatenation of
that with a name of the server. For example
789.resolver.example.net.server1.example.com.
キーが質問の結果として非根の名で生成されるなら、789.resolver.example.netを言ってください、そして、次に. 例えば、サーバ789.resolver.example.net.server1.example.comの名前によるその連結を使用してください。
2.2 The TTL Field
2.2 TTL分野
The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to be sure that older DNS implementations do not cache TKEY RRs.
TTL分野はTKEY RRsで無意味です。 それ、SHOULD、 より古いDNS実装がTKEY RRsをキャッシュしないのを確信しているいつもゼロになってください。
2.3 The Algorithm Field
2.3 アルゴリズム分野
The algorithm name is in the form of a domain name with the same meaning as in [RFC 2845]. The algorithm determines how the secret keying material agreed to using the TKEY RR is actually used to derive the algorithm specific key.
アルゴリズム名が、[RFC2845]のように意味しながら、ドメイン名の形に同じくらいをもってあります。 アルゴリズムは、TKEY RRを使用するのに同意する材料を合わせる秘密がアルゴリズムの特定のキーを引き出すのに実際にどのように使用されるかを決定します。
2.4 The Inception and Expiration Fields
2.4 始まりと満了分野
The inception time and expiration times are in number of seconds since the beginning of 1 January 1970 GMT ignoring leap seconds treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages between a DNS resolver and a DNS server where these fields are meaningful, they are either the requested validity interval for the keying material asked for or specify the validity interval of keying material provided.
飛躍秒を無視するとリング演算を使用する法2**32がグリニッジ標準時の1970年1月1日の始まりに扱われたので[RFC1982]、秒数には始まり時間と満了時間があります。 これらの分野が重要であるDNSレゾルバとDNSサーバの間のメッセージでは、それらは、材料が求めた合わせる要求された正当性間隔であるか供給された材料を合わせる正当性間隔を指定します。
To avoid different interpretations of the inception and expiration times in TKEY RRs, resolvers and servers exchanging them must have the same idea of what time it is. One way of doing this is with the NTP protocol [RFC 2030] but that or any other time synchronization used for this purpose MUST be done securely.
それらを交換するTKEY RRsの始まりと満了時間の異なった解釈、レゾルバ、およびサーバを避けるのにおいて、何時かに関する同じ考えがなければなりません。 これをする1つの方法がNTPプロトコル[RFC2030]と共にありますが、しっかりとそれかこのために使用されるいかなる他の時間同期化もしなければなりません。
2.5 The Mode Field
2.5 モード分野
The mode field specifies the general scheme for key agreement or the purpose of the TKEY DNS message. Servers and resolvers supporting this specification MUST implement the Diffie-Hellman key agreement mode and the key deletion mode for queries. All other modes are OPTIONAL. A server supporting TKEY that receives a TKEY request with a mode it does not support returns the BADMODE error. The following values of the Mode octet are defined, available, or reserved:
モード分野は主要な協定の一般的な体系かTKEY DNSメッセージの目的を指定します。 この仕様をサポートするサーバとレゾルバはディフィー-ヘルマンの主要な協定モードと質問のための主要な削除モードを実装しなければなりません。 他のすべてのモードがOPTIONALです。 それがサポートしないモードでTKEY要求を受け取るTKEYをサポートするサーバはBADMODE誤りを返します。 Mode八重奏の以下の値は、定義される、利用可能であるか、または予約されています:
Eastlake Standards Track [Page 5] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[5ページ]。
Value Description
----- -----------
0 - reserved, see section 7
1 server assignment
2 Diffie-Hellman exchange
3 GSS-API negotiation
4 resolver assignment
5 key deletion
6-65534 - available, see section 7
65535 - reserved, see section 7
値の記述----- ----------- 0--予約されていて、セクション7 1サーバ課題2ディフィー-ヘルマンの交換3GSS-API交渉4のレゾルバの課題の5の主要な削除6-65534を見てください--利用可能です、セクション7 65535を見てください--予約されていて、セクション7を見てください。
2.6 The Error Field
2.6 誤り分野
The error code field is an extended RCODE. The following values are defined:
エラーコード分野は拡張RCODEです。 以下の値は定義されます:
Value Description
----- -----------
0 - no error
1-15 a non-extended RCODE
16 BADSIG (TSIG)
17 BADKEY (TSIG)
18 BADTIME (TSIG)
19 BADMODE
20 BADNAME
21 BADALG
値の記述----- ----------- 0--いいえ、誤り1-15a非拡張しているRCODE16BADSIG(TSIG)17BADKEY(TSIG)18BADTIME(TSIG)19BADMODE20BADNAME21BADALG
When the TKEY Error Field is non-zero in a response to a TKEY query, the DNS header RCODE field indicates no error. However, it is possible if a TKEY is spontaneously included in a response the TKEY RR and DNS header error field could have unrelated non-zero error codes.
TKEY Error FieldがTKEY質問への応答で非ゼロであるときに、DNSヘッダーRCODE分野は誤りを全く示しません。 しかしながら、TKEYが応答に自然に含まれているならTKEY RRとDNSヘッダー誤り分野には関係ない非ゼロエラーコードがあるかもしれないのが、可能です。
2.7 The Key Size and Data Fields
2.7 主要なサイズとデータ・フィールド
The key data size field is an unsigned 16 bit integer in network order which specifies the size of the key exchange data field in octets. The meaning of this data depends on the mode.
重要なデータサイズ分野は八重奏における、主要な交換データ・フィールドのサイズを指定するネットワークオーダーで16ビットの未署名の整数です。 このデータの意味はモードに依存します。
2.8 The Other Size and Data Fields
2.8 もう片方のサイズとデータ・フィールド
The Other Size and Other Data fields are not used in this specification but may be used in future extensions. The RDLEN field MUST equal the length of the RDATA section through the end of Other Data or the RR is to be considered malformed and rejected.
Other SizeとOther Data分野は、この仕様で使用されませんが、今後の拡大に使用されるかもしれません。 RDLEN分野がOther Dataの端までRDATA部の長さと等しくなければならないか、RRは奇形であると考えられて、拒絶されることになっています。
Eastlake Standards Track [Page 6] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[6ページ]。
3. General TKEY Considerations
3. 一般TKEY問題
TKEY is a meta-RR that is not stored or cached in the DNS and does not appear in zone files. It supports a variety of modes for the establishment and deletion of shared secret keys information between DNS resolvers and servers. The establishment of such a shared key requires that state be maintained at both ends and the allocation of the resources to maintain such state may require mutual agreement. In the absence of willingness to provide such state, servers MUST return errors such as NOTIMP or REFUSED for an attempt to use TKEY and resolvers are free to ignore any TKEY RRs they receive.
TKEYはDNSで保存もされませんし、キャッシュもされないメタ-RRであり、ゾーンファイルに現れません。 それはDNSレゾルバとサーバの間の設立のためのさまざまなモードと共有秘密キー重要情報の削除をサポートします。 そのような共有されたキーの設立は、状態がリソースの両端と配分のときにそのような州が合意を必要とするかもしれないと主張するために維持されるのを必要とします。 そのような状態を提供する意欲が不在のとき、サーバはTKEYを使用する試みのためにNOTIMPかREFUSEDなどの誤りを返さなければなりません、そして、レゾルバは自由に彼らが受けるどんなTKEY RRsも無視できます。
The shared secret keying material developed by using TKEY is a plain octet sequence. The means by which this shared secret keying material, exchanged via TKEY, is actually used in any particular TSIG algorithm is algorithm dependent and is defined in connection with that algorithm. For example, see [RFC 2104] for how TKEY agreed shared secret keying material is used in the HMAC-MD5 algorithm or other HMAC algorithms.
TKEYを使用することによって発生する材料を合わせる共有秘密キーは明瞭な八重奏系列です。 TKEYを通して交換された材料を合わせるこの共有秘密キーが実際にどんな特定のTSIGアルゴリズムでも使用される手段は、アルゴリズムに依存していて、そのアルゴリズムに関して定義されます。 例えば、TKEYが、材料を合わせる共有秘密キーがHMAC-MD5アルゴリズムか他のHMACアルゴリズムで使用されるのにどう同意したように、[RFC2104]を見てくださいか。
There MUST NOT be more than one TKEY RR in a DNS query or response.
DNS質問か応答には1TKEY RRがあるはずがありません。
Except for GSS-API mode, TKEY responses MUST always have DNS transaction authentication to protect the integrity of any keying data, error codes, etc. This authentication MUST use a previously established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST NOT use any key that the response to be verified is itself providing.
GSS-APIモードを除いて、TKEY応答には、どんな合わせるデータ、エラーコードなどの保全も保護するDNSトランザクション認証がいつもなければなりません。 この認証は、以前に確立した秘密(TSIG)の、または、公共(SIG(0)[RFC2931])のキーを使用しなければならなくて、提供して、それ自体で、確かめられるべき応答がそうであるどんなキーも使用してはいけません。
TKEY queries MUST be authenticated for all modes except GSS-API and, under some circumstances, server assignment mode. In particular, if the query for a server assigned key is for a key to assert some privilege, such as update authority, then the query must be authenticated to avoid spoofing. However, if the key is just to be used for transaction security, then spoofing will lead at worst to denial of service. Query authentication SHOULD use an established secret (TSIG) key authenticator if available. Otherwise, it must use a public (SIG(0)) key signature. It MUST NOT use any key that the query is itself providing.
GSS-API以外のすべてのモードといくつかの状況によるサーバ課題モードのためにTKEY質問を認証しなければなりません。 次に、何らかの特権が更新権限などのように質問であると断言するのを特に、サーバの割り当てられたキーのための質問がキーのためのものであるならだますのを避けるために認証しなければなりません。 しかしながら、まさしくキーがトランザクションセキュリティに使用されるつもりであると、スプーフィングは最悪の場合はサービスの否定につながるでしょう。 利用可能であるなら、質問認証SHOULDは確立した秘密の(TSIG)主要な固有識別文字を使用します。 さもなければ、それは公衆を使用しなければなりません。(SIG(0))調号。 提供して、それはそれ自体で、質問がそうであるどんなキーも使用してはいけません。
In the absence of required TKEY authentication, a NOTAUTH error MUST be returned.
必要なTKEY認証がないとき、NOTAUTH誤りを返さなければなりません。
To avoid replay attacks, it is necessary that a TKEY response or query not be valid if replayed on the order of 2**32 second (about 136 years), or a multiple thereof, later. To accomplish this, the keying material used in any TSIG or SIG(0) RR that authenticates a TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
反射攻撃を避けるのに、オーダーのときに再演されるならTKEY応答か質問が2**32 2番目(およそ136年)、またはそれの倍数で有効でないことが必要です、後で。 これを達成するために、材料がTKEYメッセージを認証するどんなTSIGやSIG(0)RRでも使用した合わせるのは**31--1秒の当時より多くの2の生涯を持ってはいけません。
Eastlake Standards Track [Page 7] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[7ページ]。
(about 68 years). Thus, on attempted replay, the authenticating TSIG or SIG(0) RR will not be verifiable due to key expiration and the replay will fail.
(およそ68年。) したがって、試みられた再生のときに認証TSIGかSIG(0)RRが主要な満了で証明可能にならないでしょう、そして、再生は失敗するでしょう。
4. Exchange via Resolver Query
4. Resolver Queryを通した交換
One method for a resolver and a server to agree about shared secret keying material for use in TSIG is through DNS requests from the resolver which are syntactically DNS queries for type TKEY. Such queries MUST be accompanied by a TKEY RR in the additional information section to indicate the mode in use and accompanied by other information where required.
レゾルバとサーバがTSIGにおける使用のための材料を合わせる共有秘密キーに関して同意する1つのメソッドがレゾルバからのシンタクス上、DNSがタイプのためにTKEYについて質問するということであるDNS要求であります。 そのような質問に使用中のモードを示すために追加情報部のTKEY RRによって伴われて、他の情報で必要であるところに伴わなければなりません。
Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY ignore the recursive header bit in TKEY queries they receive.
TKEY質問SHOULD NOTをタイプしてください。リカーシブとサーバがそれらが受けるTKEY質問で再帰的なヘッダービットを無視するかもしれないので、旗を揚げられてください。
4.1 Query for Diffie-Hellman Exchanged Keying
ディフィー-ヘルマンのための4.1質問は合わせることを交換しました。
Diffie-Hellman (DH) key exchange is a means whereby two parties can derive some shared secret information without requiring any secrecy of the messages they exchange [Schneier]. Provisions have been made for the storage of DH public keys in the DNS [RFC 2539].
ディフィー-ヘルマン(DH)の主要な交換は2回のパーティーがそれらが交換するメッセージ[シュナイアー]の秘密保持を必要としないで何らかの共有秘密キー情報を引き出すことができる手段です。 DNSでのDH公開鍵のストレージに備えました[RFC2539]。
A resolver sends a query for type TKEY accompanied by a TKEY RR in the additional information section specifying the Diffie-Hellman mode and accompanied by a KEY RR also in the additional information section specifying a resolver Diffie-Hellman key. The TKEY RR algorithm field is set to the authentication algorithm the resolver plans to use. The "key data" provided in the TKEY is used as a random [RFC 1750] nonce to avoid always deriving the same keying material for the same pair of DH KEYs.
レゾルバはレゾルバディフィー-ヘルマンキーを指定する追加情報部でもKEY RRによってディフィー-ヘルマンモードを指定する追加情報部のTKEY RRによって同伴されて、同伴されたタイプTKEYのために質問を送ります。 TKEY RRアルゴリズム分野はレゾルバが使用するのを計画している認証アルゴリズムに設定されます。 TKEYに提供された「重要なデータ」は、いつも同じように派生するのを避けるのにDH KEYsの同じ組のために材料を合わせながら、無作為[RFC1750]の一回だけとして使用されます。
The server response contains a TKEY in its answer section with the Diffie-Hellman mode. The "key data" provided in this TKEY is used as an additional nonce to avoid always deriving the same keying material for the same pair of DH KEYs. If the TKEY error field is non-zero, the query failed for the reason given. FORMERR is given if the query included no DH KEY and BADKEY is given if the query included an incompatible DH KEY.
サーバ応答は答え部にディフィー-ヘルマンモードでTKEYを保管しています。 このTKEYに提供された「重要なデータ」は、いつも同じように派生するのを避けるのにDH KEYsの同じ組のために材料を合わせながら、追加一回だけとして使用されます。 TKEY誤り分野が非ゼロであるなら、質問はあげられた理由で失敗しました。 質問がDH KEYを全く含んでいなかったなら、FORMERRを与えます、そして、質問が非互換なDH KEYを含んでいたなら、BADKEYを与えます。
If the TKEY error field is zero, the resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in the additional information section and a server Diffie-Hellman KEY RR will also be present in the answer section of the response. Both parties can then calculate the same shared secret quantity from the pair of Diffie-Hellman (DH) keys used [Schneier] (provided these DH keys use the same generator and modulus) and the data in the TKEY RRs. The TKEY RR data is mixed with the DH result as follows:
TKEY誤り分野がゼロであるなら、レゾルバは反響しているコネが追加情報部であったならディフィー-ヘルマンKEY RR SHOULDを供給しました、そして、また、aサーバディフィー-ヘルマンKEY RRも応答の答え部に存在するでしょう。 そして、双方は、ディフィー-ヘルマン(DH)キーの組からの同じ共有秘密キー量が[シュナイアー](これらのDHキーが同じジェネレータと係数を使用するなら)とTKEY RRsのデータを使用したと見込むことができます。 TKEY RRデータは以下のDH結果に混ぜられます:
Eastlake Standards Track [Page 8] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[8ページ]。
keying material =
XOR ( DH value, MD5 ( query data | DH value ) |
MD5 ( server data | DH value ) )
材料を合わせるのはXORと等しいです。(MD5(質問データ| DH値)| DH値、MD5(サーバデータ| DH値))
Where XOR is an exclusive-OR operation and "|" is byte-stream concatenation. The shorter of the two operands to XOR is byte-wise left justified and padded with zero-valued bytes to match the length of the other operand. "DH value" is the Diffie-Hellman value derived from the KEY RRs. Query data and server data are the values sent in the TKEY RR data fields. These "query data" and "server data" nonces are suffixed by the DH value, digested by MD5, the results concatenated, and then XORed with the DH value.
そして、「XORが排他的論理和操作である、」|「バイト・ストリームは連結です」? 二つのオペランドでは、無評価されたバイトで正当化されて、水増しされた、もう片方のオペランドの長さを合わせたバイト的な左はXORにより不足しています。 「DH値」はKEY RRsから得られたディフィー-ヘルマン値です。 質問データとサーバデータはTKEY RRデータ・フィールドで送られた値です。 これらの「質問データ」と「サーバデータ」一回だけは連結された結果がMD5によって読みこなされたDH値によってsuffixedされて、次に、DH値があるXORedをsuffixedされます。
The inception and expiry times in the query TKEY RR are those requested for the keying material. The inception and expiry times in the response TKEY RR are the maximum period the server will consider the keying material valid. Servers may pre-expire keys so this is not a guarantee.
質問TKEY RRにおける始まりと満期回は合わせることの材料のために要求されたものです。 応答TKEY RRにおける始まりと満期回はサーバが合わせることの材料が有効であると考える最大の期間です。 サーバがキーをあらかじめ吐き出すかもしれないので、これは保証ではありません。
4.2 Query for TKEY Deletion
4.2はTKEYのために削除について質問します。
Keys established via TKEY can be treated as soft state. Since DNS transactions are originated by the resolver, the resolver can simply toss keys, although it may have to go through another key exchange if it later needs one. Similarly, the server can discard keys although that will result in an error on receiving a query with a TSIG using the discarded key.
TKEYを通して設立されたキーは軟性国家として扱うことができます。 DNSトランザクションがレゾルバによって溯源されるので、レゾルバは単にキーを投げることができます、後で1を必要とするなら、別の主要な交換に直面しなければならないかもしれませんが。 同様に、それはTSIGが捨てられたキーを使用している質問を受けるときの誤りをもたらすでしょうが、サーバはキーを捨てることができます。
To avoid attempted reliance in requests on keys no longer in effect, servers MUST implement key deletion whereby the server "discards" a key on receipt from a resolver of an authenticated delete request for a TKEY RR with the key's name. If the server has no record of a key with that name, it returns BADNAME.
もう事実上でないサーバがサーバがレゾルバからの領収書で主要なaを「捨てる」主要な削除を実装しなければならないキーに関する要求における試みられた信用を避ける、認証されて、キーの名前でTKEY RRを求める要求を削除してください。 サーバにキーに関する記録が全くその名前と共にないなら、それはBADNAMEを返します。
Key deletion TKEY queries MUST be authenticated. This authentication MAY be a TSIG RR using the key to be deleted.
主要な削除TKEY質問を認証しなければなりません。 この認証は削除されるのにキーを使用するTSIG RRであるかもしれません。
For querier assigned and Diffie-Hellman keys, the server MUST truly "discard" all active state associated with the key. For server assigned keys, the server MAY simply mark the key as no longer retained by the client and may re-send it in response to a future query for server assigned keying material.
本当に、割り当てられたquerierとディフィー-ヘルマンキーに関しては、サーバはキーに関連しているすべての活動的な状態を「捨てなければなりません」。 サーバの割り当てられたキーに関しては、サーバは、単にもう保有されていないとしてのクライアントによるキーをマークして、今後の質問に対応してそれを再送するかもしれません。
Eastlake Standards Track [Page 9] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[9ページ]。
4.3 Query for GSS-API Establishment
4.3 GSS-API設立のための質問
This mode is described in a separate document under preparation which should be seen for the full description. Basically the resolver and server can exchange queries and responses for type TKEY with a TKEY RR specifying the GSS-API mode in the additional information section and a GSS-API token in the key data portion of the TKEY RR.
このモードは別々のドキュメントで余すところのない解説に関して見られるべきである準備で説明されます。 基本的に、レゾルバとサーバはTKEY RRが追加情報部のGSS-APIモードとTKEY RRの重要なデータ一部のGSS-APIトークンを指定しているタイプTKEYと質問と応答を交換できます。
Any issues of possible encryption of parts the GSS-API token data being transmitted are handled by the GSS-API level. In addition, the GSS-API level provides its own authentication so that this mode of TKEY query and response MAY be, but do not need to be, authenticated with TSIG RR or SIG(0) RR [RFC 2931].
どんな問題、も部品の可能な暗号化では、送られるGSS-APIトークンデータはGSS-APIレベルによって扱われます。 さらに、TSIG RRかSIG(0)RR[RFC2931]と共にあって、認証されて、提供する必要はないのを除いて、GSS-APIレベルは、TKEY質問と応答のこの方法があることができるように、それ自身の認証を提供します。
The inception and expiry times in a GSS-API mode TKEY RR are ignored.
GSS-APIモードTKEY RRによる始まりと満期回は無視されます。
4.4 Query for Server Assigned Keying
サーバのための4.4質問は合わせることを割り当てました。
Optionally, the server can assign keying for the resolver. It is sent to the resolver encrypted under a resolver public key. See section 6 for description of encryption methods.
任意に、サーバはレゾルバのための合わせることを割り当てることができます。レゾルバ公開鍵の下で暗号化されたレゾルバにそれを送ります。 暗号化メソッドの記述に関してセクション6を見てください。
A resolver sends a query for type TKEY accompanied by a TKEY RR specifying the "server assignment" mode and a resolver KEY RR to be used in encrypting the response, both in the additional information section. The TKEY algorithm field is set to the authentication algorithm the resolver plans to use. It is RECOMMENDED that any "key data" provided in the query TKEY RR by the resolver be strongly mixed by the server with server generated randomness [RFC 1750] to derive the keying material to be used. The KEY RR that appears in the query need not be accompanied by a SIG(KEY) RR. If the query is authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR and that authentication is verified, then any SIG(KEY) provided in the query SHOULD be ignored. The KEY RR in such a query SHOULD have a name that corresponds to the resolver but it is only essential that it be a public key for which the resolver has the corresponding private key so it can decrypt the response data.
レゾルバは「サーバ課題」モードを指定するTKEY RRによって同伴されたタイプTKEYとレゾルバKEY RRが応答を暗号化する際に使用されるために質問を送ります、ともに追加情報部で。 TKEYアルゴリズム分野はレゾルバが使用するのを計画している認証アルゴリズムに設定されます。 レゾルバによって質問TKEY RRに提供されたどんな「重要なデータ」もサーバによって強く使用されるために合わせることの材料を誘導するために偶発性[RFC1750]であると生成されるサーバに混ぜられるのは、RECOMMENDEDです。 質問に現れるKEY RRはSIG(KEY)RRによって同伴される必要はありません。 (0) 質問がTSIG RR[RFC2845]かSIGをもっているレゾルバによって認証されるなら、質問SHOULDで無視されるなら、RRとその認証はSIGの確かめられて、当時のいずれも(KEY)です。 そのような質問SHOULDのKEY RRには、レゾルバに文通される名前がありますが、応答データを解読することができて、それがレゾルバが対応する秘密鍵を持っている公開鍵であることは不可欠であるだけです。
The server response contains a TKEY RR in its answer section with the server assigned mode and echoes the KEY RR provided in the query in its additional information section.
サーバ応答は、モードが割り当てられるサーバでの答え部にTKEY RRを保管していて、追加情報部で質問に提供されたKEY RRを反響します。
If the response TKEY error field is zero, the key data portion of the response TKEY RR will be the server assigned keying data encrypted under the public key in the resolver provided KEY RR. In this case, the owner name of the answer TKEY RR will be the server assigned name of the key.
応答TKEY誤り分野がゼロであるなら、応答TKEY RRの重要なデータ一部がレゾルバの提供されたKEY RRで公開鍵の下で暗号化されたデータを合わせながら割り当てられたサーバになるでしょう。 この場合、所有者名(答えTKEY RR)はキーのサーバの割り当てられた名になるでしょう。
Eastlake Standards Track [Page 10] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[10ページ]。
If the error field of the response TKEY is non-zero, the query failed for the reason given. FORMERR is given if the query specified no encryption key.
応答TKEYの誤り分野が非ゼロであるなら、質問はあげられた理由で失敗しました。 質問が暗号化キーを全く指定しなかったなら、FORMERRを与えます。
The inception and expiry times in the query TKEY RR are those requested for the keying material. The inception and expiry times in the response TKEY are the maximum period the server will consider the keying material valid. Servers may pre-expire keys so this is not a guarantee.
質問TKEY RRにおける始まりと満期回は合わせることの材料のために要求されたものです。 応答TKEYにおける始まりと満期回はサーバが合わせることの材料が有効であると考える最大の期間です。 サーバがキーをあらかじめ吐き出すかもしれないので、これは保証ではありません。
The resolver KEY RR MUST be authenticated, through the authentication of this query with a TSIG or SIG(0) or the signing of the resolver KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY for which they know the private key, and thereby the attacker could obtain a valid shared secret key from the server.
レゾルバKEY RR MUST、認証されてください、SIG(KEY)があるレゾルバKEYのTSIGとのこの質問の認証、SIG(0)または署名を通して。 さもなければ、攻撃者は彼らが秘密鍵を知っているレゾルバKEYを鍛造できます、そして、その結果、攻撃者はサーバから主要な有効な共有秘密キーを得ることができました。
4.5 Query for Resolver Assigned Keying
レゾルバのための4.5質問は合わせることを割り当てました。
Optionally, a server can accept resolver assigned keys. The keying material MUST be encrypted under a server key for protection in transmission as described in Section 6.
任意に、サーバはレゾルバの割り当てられたキーを受け入れることができます。 セクション6で説明されるトランスミッションにおける保護に、主要なサーバの下で合わせることの材料を暗号化しなければなりません。
The resolver sends a TKEY query with a TKEY RR that specifies the encrypted keying material and a KEY RR specifying the server public key used to encrypt the data, both in the additional information section. The name of the key and the keying data are completely controlled by the sending resolver so a globally unique key name SHOULD be used. The KEY RR used MUST be one for which the server has the corresponding private key, or it will not be able to decrypt the keying material and will return a FORMERR. It is also important that no untrusted party (preferably no other party than the server) has the private key corresponding to the KEY RR because, if they do, they can capture the messages to the server, learn the shared secret, and spoof valid TSIGs.
レゾルバはデータを暗号化するのに使用されるサーバ公開鍵を指定する材料とKEY RRをTKEY RRとの暗号化された合わせることを指定するTKEY質問に送ります、ともに追加情報部で。 キーの名前と合わせるデータが送付レゾルバによって完全に制御されるので、グローバルにユニークなキーはSHOULDを命名します。使用されます。 使用されるKEY RRがサーバには対応する秘密鍵があるものであるに違いないかそれは、合わせるのが材料であると解読することができないで、FORMERRを返すでしょう。 また、どんな信頼されていないパーティー(サーバいいえ以外の望ましくはパーティー)もそうするなら、彼らがメッセージをサーバとして得て、共有秘密キーを学んで、有効なTSIGsを偽造することができるので秘密鍵をKEY RRに対応するようにしないのも、重要です。
The query TKEY RR inception and expiry give the time period the querier intends to consider the keying material valid. The server can return a lesser time interval to advise that it will not maintain state for that long and can pre-expire keys in any case.
質問TKEY RR始まりと満期はquerierが合わせることの材料が有効であると考えるつもりである期間を与えます。 サーバは、それのための状態を長く維持しないと忠告するために、より少ない時間間隔を返すことができて、どのような場合でも、キーをあらかじめ吐き出すことができます。
This mode of query MUST be authenticated with a TSIG or SIG(0). Otherwise, an attacker can forge a resolver assigned TKEY query, and thereby the attacker could specify a shared secret key that would be accepted, used, and honored by the server.
TSIGかSIG(0)と共に質問のこの方法を認証しなければなりません。 さもなければ、攻撃者はレゾルバの割り当てられたTKEY質問を鍛造できます、そして、その結果、攻撃者はサーバによって受け入れられて、使用されて、光栄に思われる共有された秘密鍵を指定できました。
Eastlake Standards Track [Page 11] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[11ページ]。
5. Spontaneous Server Inclusion
5. 自然発生的なサーバ包含
A DNS server may include a TKEY RR spontaneously as additional information in responses. This SHOULD only be done if the server knows the querier understands TKEY and has this option implemented. This technique can be used to delete a key and may be specified for modes defined in the future. A disadvantage of this technique is that there is no way for the server to get any error or success indication back and, in the case of UDP, no way to even know if the DNS response reached the resolver.
DNSサーバは追加情報として応答に自然にTKEY RRを含むかもしれません。 このSHOULDはサーバが、querierがTKEYを理解しているのを知る場合にだけ終わって、このオプションを実装させます。 このテクニックは、キーを削除するのに使用できて、将来定義されたモードに指定されるかもしれません。 このテクニックの不都合はDNS応答がレゾルバに届いたならどんな誤りや成功指示後部も得ますが、知るのさえUDPの場合におけるどんな方法も得ないようにサーバのための方法が全くないということです。
5.1 Spontaneous Server Key Deletion
5.1 自然発生的なサーバ主要な削除
A server can optionally tell a client that it has deleted a secret key by spontaneously including a TKEY RR in the additional information section of a response with the key's name and specifying the key deletion mode. Such a response SHOULD be authenticated. If authenticated, it "deletes" the key with the given name. The inception and expiry times of the delete TKEY RR are ignored. Failure by a client to receive or properly process such additional information in a response would mean that the client might use a key that the server had discarded and would then get an error indication.
サーバは、応答の追加情報部にキーの名前で自然にTKEY RRを含んで、主要な削除モードを指定することによって秘密鍵を削除したとクライアントに任意に言うことができます。 そのような応答SHOULD、認証されてください。 認証されるなら、それは名でキーを「削除します」。 TKEY RRを削除してください。始まりと満期回、無視されます。 受信するか、または適切に応答におけるそのような追加情報を処理しない場合、クライアントがサーバが捨てて、次に誤り表示を得るキーを使用するかもしれないことを意味するでしょう。
For server assigned and Diffie-Hellman keys, the client MUST "discard" active state associated with the key. For querier assigned keys, the querier MAY simply mark the key as no longer retained by the server and may re-send it in a future query specifying querier assigned keying material.
割り当てられたサーバとディフィー-ヘルマンキーに関しては、クライアントはキーに関連している活動的な状態を「捨てなければなりません」。 キーが割り当てられたquerierに関しては、querierは単にもう保有されていないとしてのサーバによるキーをマークして、材料を合わせながら割り当てられたquerierを指定する今後の質問でそれを再送するかもしれません。
6. Methods of Encryption
6. 暗号化のメソッド
For the server assigned and resolver assigned key agreement modes, the keying material is sent within the key data field of a TKEY RR encrypted under the public key in an accompanying KEY RR [RFC 2535]. This KEY RR MUST be for a public key algorithm where the public and private keys can be used for encryption and the corresponding decryption which recovers the originally encrypted data. The KEY RR SHOULD correspond to a name for the decrypting resolver/server such that the decrypting process has access to the corresponding private key to decrypt the data. The secret keying material being sent will generally be fairly short, usually less than 256 bits, because that is adequate for very strong protection with modern keyed hash or symmetric algorithms.
選任されたサーバと主要な協定モードが割り当てられたレゾルバに関しては、付随のKEY RR[RFC2535]の公開鍵の下で暗号化されたTKEY RRの重要なデータ分野の中で合わせることの材料を送ります。 このKEY RR MUSTは暗号化に公衆と秘密鍵を使用できる公開鍵アルゴリズムのためのそうであり、対応は元々暗号化されたデータを回復する復号化です。 KEY RR SHOULDが解読するレゾルバ/サーバのための名前に対応しているので、解読するプロセスはデータを解読するために対応する秘密鍵に近づく手段を持っています。 一般に、送られる材料を合わせる秘密はかなり短くなるでしょう、通常256ビット未満、非常に強い保護に、それが現代の合わせられたハッシュか左右対称のアルゴリズムで適切であるので。
If the KEY RR specifies the RSA algorithm, then the keying material is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in PKCS#1 [RFC 2437]. (Note, the secret keying material being sent is directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
KEY RRがRSAアルゴリズムを指定するなら、合わせることの材料はPKCS#1[RFC2437]における、RSAES-PKCS1-v1_5暗号化の記述に従って暗号化されます。 (送られる材料を合わせる秘密が直接、RSAがPKCS#で. それが「おおわれない」1つの形式を暗号化したということであることに注意してください。
Eastlake Standards Track [Page 12] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[12ページ]。
some other symmetric algorithm.) In the unlikely event that the keying material will not fit within one RSA modulus of the chosen public key, additional RSA encryption blocks are included. The length of each block is clear from the public RSA key specified and the RSAES-PKCS1-v1_5 padding makes it clear what part of the encrypted data is actually keying material and what part is formatting or the required at least eight bytes of random [RFC 1750] padding.
ある他の左右対称のアルゴリズム。) 合わせることの材料が選ばれた公開鍵の1つのRSA係数の中で合わないありそうもないイベントでは、追加RSA暗号化ブロックは含まれています。 それぞれのブロックの長さは指定された公共のRSAキーから明確です、そして、RSAES-PKCS1-v1_5詰め物は暗号化されたデータのどんな部分が実際に材料を合わせて、部分がフォーマットしていることか必要な少なくとも8バイトの無作為[RFC1750]の詰め物であるかを断言します。
7. IANA Considerations
7. IANA問題
This section is to be interpreted as provided in [RFC 2434].
このセクションは[RFC2434]に提供するように解釈されることになっています。
Mode field values 0x0000 and 0xFFFF are reserved.
モード分野値の0×0000と0xFFFFは予約されています。
Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE can only be assigned by an IETF Standards Action.
モード分野は0x00FFを通して0×0001を評価します、そして、IETF Standards Actionは0XFF00から0XFFFEを割り当てることができるだけです。
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF are allocated by IESG approval or IETF consensus.
IESG承認かIETFコンセンサスは0xFEFFを通した0x0FFFと0xF0000を通したモード分野値0x0100を割り当てます。
Mode field values 0x1000 through 0xEFFF are allocated based on Specification Required as defined in [RFC 2434].
Specification Requiredに基づいて[RFC2434]で定義されるように0xEFFFを通したモード分野値0x1000を割り当てます。
Mode values should not be changed when the status of their use changes. For example, a mode value assigned based just on providing a specification should not be changed later just because that use's status is changed to standards track.
彼らの使用の状態が変化するとき、最頻値を変えるべきではありません。 例えば、ただその使用の状態が標準化過程に変わるので、後でまさしく仕様を提供するのに基づいた状態で割り当てられた最頻値を変えるべきではありません。
The following assignments are documented herein:
以下の課題はここに記録されます:
RR Type 249 for TKEY.
RRはTKEYのために249をタイプします。
TKEY Modes 1 through 5 as listed in section 2.5.
セクション2.5で記載されているTKEY Modes1〜5。
Extended RCODE Error values of 19, 20, and 21 as listed in section
2.6.
セクション2.6で同じくらい記載されていた状態で19、20、および21のRCODE Error値を広げました。
8. Security Considerations
8. セキュリティ問題
The entirety of this specification is concerned with the secure establishment of a shared secret between DNS clients and servers in support of TSIG [RFC 2845].
この仕様の全体がTSIG[RFC2845]を支持してDNSクライアントとサーバの間の共有秘密キーの安全な確立に関係があります。
Protection against denial of service via the use of TKEY is not provided.
TKEYの使用を通したサービスの否定に対する保護は提供されません。
Eastlake Standards Track [Page 13] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[13ページ]。
References
参照
[Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and
Sons
[シュナイアー]ブルース・シュナイアー、「適用された暗号:」 「C」、1996、ジョン・ワイリー、およびソンスのプロトコル、アルゴリズム、およびソースコード
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
Mockapetris、[RFC1034]P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
Mockapetris、[RFC1035]P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC1750] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
September 1996.
[RFC1982] ElzとR.とR.ブッシュ、「通し番号演算」、RFC1982、1996年9月。
[RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC1995] 太田、M.、「DNSの増加のゾーン転送」、RFC1995、1996年8月。
[RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2030] 工場、D.、「IPv4、IPv6、およびOSIのための簡単なネットワーク時間プロトコル(SNTP)バージョン4」、RFC2030、1996年10月。
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC2136] VixieとP.とトムソンとS.、RekhterとY.とJ.バウンド、「ドメインネームシステム(DNSアップデート)におけるダイナミックなアップデート」RFC2136(1997年4月)。
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434] Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.
[RFC2437] Kaliski、B.、およびJ.Staddon、「PKCS#1:」 RSA暗号仕様バージョン2インチ、RFC2437、10月1998日
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC2539] イーストレーク、D.、「ドメインネームシステム(DNS)における、ディフィー-ヘルマンKeysのストレージ」、RFC2539、1999年3月。
Eastlake Standards Track [Page 14] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[14ページ]。
[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2845] Vixie、P.、グドムンソン、O.、イーストレーク、D.、およびB.ウェリントン(「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s )", RFC 2931, September 2000.
[RFC2931] D.、「DNS要求とトランザクション署名(SIG(0)s)」、RFC2931 2000年9月のイーストレーク。
Author's Address
作者のアドレス
Donald E. Eastlake 3rd Motorola 140 Forest Avenue Hudson, MA 01749 USA
ドナルドE.イーストレーク第3モトローラ140の森林Avenue MA01749ハドソン(米国)
Phone: +1 978-562-2827 (h)
+1 508-261-5434 (w)
Fax: +1 508-261-4447 (w)
EMail: Donald.Eastlake@motorola.com
以下に電話をしてください。 +1 978-562-2827(h)+1 508-261-5434(w)Fax: +1 508-261-4447 (w) メールしてください: Donald.Eastlake@motorola.com
Eastlake Standards Track [Page 15] RFC 2930 The DNS TKEY RR September 2000
イーストレークStandardsはDNS TKEY RR2000年9月にRFC2930を追跡します[15ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
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機能のための基金は現在、インターネット協会によって提供されます。
Eastlake Standards Track [Page 16]
イーストレーク標準化過程[16ページ]
一覧
スポンサーリンク
