Network Working Group                                      B. Wellington
Request for Comments: 3008                                       Nominum
Updates: 2535                                              November 2000
Category: Standards Track
        
         Domain Name System Security (DNSSEC) Signing Authority
        

Status of this Memo

このメモの位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2000). All Rights Reserved.

著作権(C)インターネット協会(2000)。全著作権所有。

Abstract

抽象

This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records.

この文書では、ドメインネームシステムセキュリティ(DNSSEC)の署名機関の改訂モデルを提案しています。改訂されたモデルは、以前の文書を明確にし、安全な解決プロセスを簡素化するために追加の制限を加えるように設計されています。具体的には、これは、レコードのセットに署名する鍵の承認に影響を与えます。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

1 - Introduction

1 - はじめに

This document defines additional restrictions on DNSSEC signatures (SIG) records relating to their authority to sign associated data. The intent is to establish a standard policy followed by a secure resolver; this policy can be augmented by local rules. This builds upon [RFC2535], updating section 2.3.6 of that document.

このドキュメントでは、関連するデータに署名するために彼らの権限に関連するDNSSEC署名(SIG)レコードの追加の制限を定義します。その意図は、セキュアリゾルバが続く標準ポリシーを確立することです。このポリシーは、ローカルルールによって増強することができます。これは、その文書のセクション2.3.6を更新し、[RFC2535]の上に構築します。

The most significant change is that in a secure zone, zone data is required to be signed by the zone key.

最も重要な変更は、セキュアゾーンで、ゾーンデータはゾーン鍵によって署名される必要があるということです。

Familiarity with the DNS system [RFC1034, RFC1035] and the DNS security extensions [RFC2535] is assumed.

DNSシステム[RFC1034、RFC1035]とDNSセキュリティ拡張[RFC2535]に精通が仮定されます。

2 - The SIG Record

2 - SIGのレコード

A SIG record is normally associated with an RRset, and "covers" (that is, demonstrates the authenticity and integrity of) the RRset. This is referred to as a "data SIG". Note that there can be multiple SIG records covering an RRset, and the same validation process should be repeated for each of them. Some data SIGs are considered "material", that is, relevant to a DNSSEC capable resolver, and some are "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC validation. Immaterial SIGs may have application defined roles. SIG records may exist which are not bound to any RRset; these are also considered immaterial. The validation process determines which SIGs are material; once a SIG is shown to be immaterial, no other validation is necessary.

SIGレコードは通常、RRセット(つまりは、真正性との整合性を実証している)RRセット、および「カバー」に関連しています。これは、「データSIG」と呼ばれています。資源レコード集合をカバーする複数のSIGレコードが存在し得ることに留意されたい、と同じ検証プロセスは、それらの各々に対して繰り返さなければなりません。一部のデータのSIGはそれは、DNSSEC対応リゾルバに関連している、と彼らはDNSSEC検証に関連していないとして、いくつかは、「重要でない」または「エクストラDNSSEC」されている、「材料」とみなされます。軽微のSIGは、アプリケーション定義された役割を有することができます。 SIGレコードは、任意のRRセットにバインドされていない存在してもよいです。これらも軽微と考えられています。検証プロセスは、材料であるのSIGを判定する。 SIGが重要であることが示された後、他の検証は必要ではありません。

SIGs may also be used for transaction security. In this case, a SIG record with a type covered field of 0 is attached to a message, and is used to protect message integrity. This is referred to as a SIG(0) [RFC2535, RFC2931].

SIGは、トランザクションのセキュリティのために使用することができます。この場合、0の種類対象とする分野でのSIGレコードがメッセージに添付され、メッセージの完全性を保護するために使用されます。これは、SIG(0)[RFC2535、RFC2931]と呼ぶことにします。

The following sections define requirements for all of the fields of a SIG record. These requirements MUST be met in order for a DNSSEC capable resolver to process this signature. If any of these requirements are not met, the SIG cannot be further processed. Additionally, once a KEY has been identified as having generated this SIG, there are requirements that it MUST meet.

次のセクションでは、SIGレコードのフィールドのすべての要件を定義します。これらの要件は、この署名を処理するためにDNSSECできるリゾルバために満たさなければなりません。これらの要件のいずれかが満たされていない場合は、SIGは、さらに処理することはできません。 KEYは、このSIGを生成したと識別された後さらに、それが満たさなければならない要件があります。

2.1 - Type Covered
2.1 - タイプカバー

For a data SIG, the type covered MUST be the same as the type of data in the associated RRset. For a SIG(0), the type covered MUST be 0.

データSIGのために、被覆されたタイプは、関連するRRセット内のデータのタイプと同じでなければなりません。 SIG(0)のために、被覆されたタイプは0でなければなりません。

2.2 - Algorithm Number
2.2 - アルゴリズム数

The algorithm specified in a SIG MUST be recognized by the client, and it MUST be an algorithm that has a defined SIG rdata format.

SIGで指定されたアルゴリズムは、クライアントによって認識されなければならない、それが定義されたSIGのRDATAフォーマットを有するアルゴリズムでなければなりません。

2.3 - Labels
2.3 - ラベル

The labels count MUST be less than or equal to the number of labels in the SIG owner name, as specified in [RFC2535, section 4.1.3].

[RFC2535、セクション4.1.3]で指定されたラベルは、以下SIGの所有者名のラベルの数に等しくなければならない数えます。

2.4 - Original TTL
2.4 - オリジナルTTL

The original TTL MUST be greater than or equal to the TTL of the SIG record itself, since the TTL cannot be increased by intermediate servers. This field can be ignored for SIG(0) records.

TTLは、中間サーバによって増加させることができないので、元のTTLは、以上SIGレコード自体のTTLに等しくなければなりません。このフィールドには、SIG(0)レコードを無視することができます。

2.5 - Signature Expiration and Inception
2.5 - 署名の有効期限とインセプション

The current time at the time of validation MUST lie within the validity period bounded by the inception and expiration times.

検証時の現時刻が開始と有効期限に囲まれた有効期間内になければなりません。

2.6 - Key Tag
2.6 - 鍵タグ

There are no restrictions on the Key Tag field, although it is possible that future algorithms will impose constraints.

将来のアルゴリズムが制約を課すことは可能であるが、鍵タグフィールドには制限がありません。

2.7 - Signer's Name
2.7 - 署名者の名前

The signer's name field of a data SIG MUST contain the name of the zone to which the data and signature belong. The combination of signer's name, key tag, and algorithm MUST identify a zone key if the SIG is to be considered material. The only exception that the signer's name field in a SIG KEY at a zone apex SHOULD contain the parent zone's name, unless the KEY set is self-signed. This document defines a standard policy for DNSSEC validation; local policy may override the standard policy.

データSIGの署名者の名前フィールドは、データと署名が属するゾーンの名前を含まなければなりません。 SIGは、材料と見なされるのであれば、署名者の名前、キー、タグ、およびアルゴリズムの組み合わせは、ゾーン鍵を特定しなければなりません。 KEYセットが自己署名されない限り、ゾーンの頂点にSIGキーに署名者の名前フィールドは、親ゾーンの名前が含まれているべきであることを唯一の例外。この文書はDNSSEC検証のための標準的なポリシーを定義します。ローカルポリシーは、標準ポリシーを無効にすることができます。

There are no restrictions on the signer field of a SIG(0) record. The combination of signer's name, key tag, and algorithm MUST identify a key if this SIG(0) is to be processed.

SIG(0)レコードの署名者フィールドに制限はありません。このSIG(0)を処理する場合は、署名者の名前、キー、タグ、およびアルゴリズムの組み合わせは、キーを特定しなければなりません。

2.8 - Signature
2.8 - 署名

There are no restrictions on the signature field. The signature will be verified at some point, but does not need to be examined prior to verification unless a future algorithm imposes constraints.

署名フィールドに制限はありません。署名は、いくつかの点で検証されますが、将来のアルゴリズムは、制約を課していない限り前の検証に検討する必要はありません。

3 - The Signing KEY Record

3 - 署名鍵レコード

Once a signature has been examined and its fields validated (but before the signature has been verified), the resolver attempts to locate a KEY that matches the signer name, key tag, and algorithm fields in the SIG. If one is not found, the SIG cannot be verified and is considered immaterial. If KEYs are found, several fields of the KEY record MUST have specific values if the SIG is to be considered material and authorized. If there are multiple KEYs, the following checks are performed on all of them, as there is no way to determine which one generated the signature until the verification is performed.

署名が検査され、そのフィールドが有効(ただし、署名が検証された前)と、レゾルバは、SIGに署名者名、キータグ、およびアルゴリズム・フィールドと一致するキーを検索することを試みます。 1が見つからない場合は、SIGを検証することができず、軽微と考えられています。鍵が発見された場合SIGは、材料を考慮し、許可する場合は、KEYレコードのいくつかのフィールドは、特定の値を持たなければなりません。複数のキーがある場合は、検証が実行されるまで署名を生成したかを判断する方法がないように、次のチェックは、それらの全てに対して実行されます。

3.1 - Type Flags
3.1 - タイプフラグ

The signing KEY record MUST have a flags value of 00 or 01 (authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. A DNSSEC resolver MUST only trust signatures generated by keys that are permitted to authenticate data.

署名鍵レコード00または01(認証許可され、任意の機密性)[RFC2535、3.1.2]のフラグ値を有しなければなりません。 DNSSECリゾルバのみデータを認証するために許可されているキーによって生成された署名を信頼しなければなりません。

3.2 - Name Flags
3.2 - 名前の国旗

The interpretation of this field is considerably different for data SIGs and SIG(0) records.

このフィールドの解釈は、データのSIGとSIG(0)レコードのかなり異なっています。

3.2.1 - Data SIG
3.2.1 - データSIG

If the SIG record covers an RRset, the name type of the associated KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, section 2.3.6. The DNSSEC validation process performed by a resolver MUST ignore all keys that are not zone keys unless local policy dictates otherwise.

SIGレコードが資源レコード集合をカバーする場合、関連付けられたキーの名前タイプが01(ゾーン)[RFC2535、3.1.2]でなければなりません。これはRFC 2535、セクション2.3.6に更新します。リゾルバによって行わDNSSEC検証プロセスは、ローカルポリシーが指示しない限りキーゾーンされていないすべてのキーを無視しなければなりません。

The primary reason that RFC 2535 allows host and user keys to generate material DNSSEC signatures is to allow dynamic update without online zone keys; that is, avoid storing private keys in an online server. The desire to avoid online signing keys cannot be achieved, though, because they are necessary to sign NXT and SOA sets [RFC3007]. These online zone keys can sign any incoming data. Removing the goal of having no online keys removes the reason to allow host and user keys to generate material signatures.

RFC 2535は、ホストとユーザ鍵材料のDNSSEC署名を生成することを可能にすることを主な理由は、オンラインゾーン鍵なしの動的更新を可能にすることです。つまり、オンラインサーバーに秘密鍵を保管することは避けてください。彼らはNXTとSOAセット[RFC3007]を署名する必要があるため、オンライン署名鍵を避けたいという願望は、しかし、実現することはできません。これらのオンラインゾーン鍵は、すべての着信データに署名することができます。オンラインキーを備えていないという目標を削除すると、ホストとユーザのキーは材料の署名を生成することができるようにする理由を削除します。

Limiting material signatures to zone keys simplifies the validation process. The length of the verification chain is bounded by the name's label depth. The authority of a key is clearly defined; a resolver does not need to make a potentially complicated decision to determine whether a key has the proper authority to sign data.

ゾーンキーに材料署名を制限することは、検証プロセスを簡素化します。検証チェーンの長さは、名前のラベルの深さによって制限されます。キーの権限が明確に定義されています。リゾルバは鍵がデータに署名するための適切な権限を持っているかどうかを判断するために潜在的に複雑な意思決定を行う必要はありません。

Finally, there is no additional flexibility granted by allowing host/user key generated material signatures. As long as users and hosts have the ability to authenticate update requests to the primary zone server, signatures by zone keys are sufficient to protect the integrity of the data to the world at large.

最後に、ホスト/ユーザ鍵生成材料の署名を可能にすることによって付与された追加の柔軟性がありません。限り、ユーザーとホストがプライマリゾーンサーバへの更新要求を認証する能力を持っているとして、ゾーン鍵によって署名が広く世界にデータの整合性を保護するのに十分です。

3.2.2 - SIG(0)
3.2.2 - SIG(0)

If the SIG record is a SIG(0) protecting a message, the name type of the associated KEY SHOULD be 00 (user) or 10 (host/entity). Transactions are initiated by a host or user, not a zone, so zone keys SHOULD not generate SIG(0) records.

SIGレコードがSIG(0)メッセージを保護している場合、関連付けられたキーの名前タイプが00(ユーザ)または10(ホスト/エンティティ)であるべきです。取引は、ホストまたはユーザーではなく、ゾーンによって開始され、そのゾーンのキーは、SIG(0)レコードを生成してはなりません。

A client is either explicitly executed by a user or on behalf of a host, therefore the name type of a SIG(0) generated by a client SHOULD be either user or host. A nameserver is associated with a host, and its use of SIG(0) is not associated with a particular zone, so the name type of a SIG(0) generated by a nameserver SHOULD be host.

クライアントは、明示的にユーザまたはホストのいずれかでなければならないクライアントによって生成されたSIG(0)のゆえ名前タイプ、ユーザまたはホストに代わって実行されます。ネームサーバは、ホストに関連付けられ、そしてSIGの名前のタイプ(0)ホストであるべきであるネームサーバによって生成されるように、SIGのその使用は、(0)、特定のゾーンに関連付けられていません。

3.3 - Signatory Flags
3.3 - 署名者の国旗

This document does not assign any values to the signatory field, nor require any values to be present.

この文書は、署名フィールドに任意の値を割り当て、また存在することが任意の値を必要としません。

3.4 - Protocol
3.4 - プロトコル

The signing KEY record MUST have a protocol value of 3 (DNSSEC) or 255 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC resolver MUST NOT trust any signature that it generates.

署名鍵レコードは3(DNSSEC)または255(ALL)のプロトコル値を有しなければなりません。キーはDNSSECで使用するように指定されていない場合は、DNSSECリゾルバは、それが生成する任意の署名を信用してはいけません。

3.5 - Algorithm Number
3.5 - アルゴリズム数

The algorithm field MUST be identical to that of the generated SIG record, and MUST meet all requirements for an algorithm value in a SIG record.

アルゴリズムフィールドは、生成されたSIGレコードのものと同一でなければならない、とSIGレコード内のアルゴリズム値のためのすべての要件を満たす必要があります。

4 - Security Considerations

4 - セキュリティの考慮事項

This document defines a standard baseline for a DNSSEC capable resolver. This is necessary for a thorough security analysis of DNSSEC, if one is to be done.

この文書はDNSSEC可能なレゾルバのための標準的なベースラインを定義します。 1が実行される場合、これは、DNSSECの徹底的なセキュリティ分析のために必要です。

Specifically, this document places additional restrictions on SIG records that a resolver must validate before the signature can be considered worthy of DNSSEC trust. This simplifies the protocol, making it more robust and able to withstand scrutiny by the security community.

具体的には、この文書は、署名がDNSSECの信頼に値すると考えることができる前に、リゾルバが検証する必要がありSIGレコードの追加の制限を課します。これは、より堅牢でセキュリティコミュニティによって精査に耐えることができる作り、プロトコルを簡素化します。

5 - Acknowledgements

5 - 謝辞

The author would like to thank the following people for review and informative comments (in alphabetical order):

著者は、レビューと(アルファベット順)有益なコメントを以下の人々に感謝したいと思います:

Olafur Gudmundsson Ed Lewis

オラフルグドムンソンエド・ルイス

6 - References

6 - 参考文献

[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.

[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.

[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System", RFC 2136, April 1997.

[RFC2136]いるVixie(編)、結合したP.、トムソン、S.、Rekhter、Y.、およびJ.、 "ドメインネームシステムにおける動的更新"、RFC 2136、1997年4月。

[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.

[RFC2535]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。

[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000.

[RFC2931]イーストレイク、D.、 "DNS要求とトランザクション署名(SIG(0)S)"、RFC 2931、2000年9月。

[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.

[RFC3007]ウェリントン、B.、 "シンプル・セキュアドメインネームシステム(DNS)動的更新"、RFC 3007、2000年11月。

7 - Author's Address

7 - 著者のアドレス

Brian Wellington Nominum, Inc. 950 Charter Street Redwood City, CA 94063

ブライアンウェリントンノミナム社950憲章通りカリフォルニア州レッドウッドシティー94063

Phone: +1 650 381 6022 EMail: Brian.Wellington@nominum.com

電話:+1 650 381 6022 Eメール:Brian.Wellington@nominum.com

8 Full Copyright Statement

8フル著作権声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

著作権(C)インターネット協会(2000)。全著作権所有。

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 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機能のための基金は現在、インターネット協会によって提供されます。