Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 6394 BBN Technologies
Category: Informational October 2011
ISSN: 2070-1721
Use Cases and Requirements for DNS-Based Authentication
of Named Entities (DANE)
Abstract
抽象
Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name. Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNS Security Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names.
現在の多くのアプリケーションは、クライアントが接続されているサーバが適切に希望するドメイン名を表していることを確認できるようにするためにトランスポート層セキュリティ（TLS）に証明書ベースの認証機能を使用しています。典型的には、この認証は、よく知られた認証局（CA）に根ざしPKIX証明書チェーンに基づいているが、追加情報は、DNS自体を介して提供することができます。この文書では、DNSおよびDNSセキュリティ拡張機能（DNSSEC）はTLS認証プロセスをサポートするアサーションを作るために使用することができているユースケースのセットを記述します。このドキュメントの主な焦点は、TLSサーバー認証であるが、それはまた、TLSクライアントがドメイン名で識別されたアプリケーションのためのTLSクライアント認証をカバーしています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6394.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6394で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions .....................................................4
3. Use Cases .......................................................4
3.1. CA Constraints .............................................5
3.2. Service Certificate Constraints ............................6
3.3. Trust Anchor Assertion and Domain-Issued Certificates ......7
3.4. Delegated Services .........................................9
4. Other Requirements .............................................10
5. Acknowledgements ...............................................11
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
Transport Layer Security (TLS) is used as the basis for security features in many modern Internet application service protocols to provide secure client-server connections [RFC5246]. It underlies secure HTTP and secure email [RFC2818] [RFC2595] [RFC3207], and provides hop-by-hop security in real-time multimedia and instant-messaging protocols [RFC3261] [RFC6120].
トランスポート層セキュリティ（TLS）は、セキュアなクライアント - サーバ接続[RFC5246]を提供するために、多くの近代的なインターネットアプリケーションサービスプロトコルのセキュリティ機能のための基礎として使用されます。これは、セキュアHTTPおよびセキュアな電子メール[RFC2818] [RFC2595] [RFC3207]を根底に、かつリアルタイムマルチメディアおよびインスタント・メッセージング・プロトコル[RFC3261] [RFC6120]でホップバイホップのセキュリティを提供します。
Application service clients typically establish TLS connections to application servers identified by DNS domain names. The process of obtaining this "source" domain is application specific [RFC6125]. The name could be entered by a user or found through an automated discovery process such as an SRV or NAPTR record. After obtaining the address of the server via an A or AAAA DNS record, the client conducts a TLS handshake with the server, during which the server presents a PKIX certificate [RFC5280]. The TLS layer performs PKIX
アプリケーションサービスのクライアントは、通常、DNSドメイン名で識別されるアプリケーションサーバへのTLS接続を確立します。この「ソース」ドメインを取得するプロセスは、特定用途向け[RFC6125]です。名前は、SRVやNAPTRレコードとして自動検出プロセスを介してユーザーが入力したか、見つけることができます。 AまたはAAAA DNSレコードを介してサーバのアドレスを取得した後、クライアントは、サーバがPKIX証明書[RFC5280]を提示する時にサーバとTLSハンドシェイクを行います。 TLS層はPKIXを行います
validation of the certificate, including verification that the certificate chains to one of the client's trust anchors. If this validation is successful, then the application layer determines whether the DNS name for the application service presented in the certificate matches the source domain name [RFC6125]. Typically, if the name matches, then the client proceeds with the TLS connection.
そのクライアントのトラストアンカーのいずれかに証明書チェーンの検証など、証明書の検証、。この検証が成功した場合、アプリケーション層は、証明書に提示したアプリケーションサービスのDNS名は元のドメイン名[RFC6125]を一致するかどうかを判断します。名前が一致した場合、通常、クライアントはTLS接続で進行します。
The certificate authorities (CAs) that issue PKIX certificates are asserting bindings between domain names and the public keys they certify. Application service clients are verifying these bindings and making authorization decisions -- whether to proceed with connections -- based on them.
認証局（CA）が発行PKIX証明書は、ドメイン名と、彼らは証明公開鍵の間のバインディングを主張しています。アプリケーションサービスクライアントは、これらのバインディングを検証し、許可決定を作っている - の接続を続行するかどうか - それに基づきます。
Clients thus rely on CAs to correctly assert bindings between public keys and domain names, in the sense that the holder of the corresponding private key should be the domain holder. Today, an attacker can successfully authenticate as a given application service domain if he can obtain a "mis-issued" certificate from one of the widely used CAs -- a certificate containing the victim application service's domain name and a public key whose corresponding private key is held by the attacker. If the attacker can additionally insert himself as a "man in the middle" between a client and server (e.g., through DNS cache poisoning of an A or AAAA record), then the attacker can convince the client that a server of the attacker's choice legitimately represents the victim's application service.
クライアントは、このように正確に対応する秘密鍵の所有者は、ドメインの所有者であるべきという意味で、公開鍵とドメイン名の間のバインディングを主張するのCAに依存しています。被害者のアプリケーションサービスのドメイン名とその秘密鍵に対応する公開鍵を含む証明書 - 彼は広く使われているCAのいずれかから「誤発行の」証明書を取得することができれば今日、攻撃者が指定したアプリケーション・サービス・ドメインとして認証することができます攻撃者によって保持されています。攻撃者は、さらに、（AまたはAAAAレコードのDNSキャッシュポイズニングを通じて例えば、）は、クライアントとサーバの間の「中間者」としての地位を挿入することができた場合、攻撃者がクライアントを納得させることができる合法的に攻撃者が選択したサーバー被害者のアプリケーションサービスを表します。
With the advent of DNSSEC [RFC4033], it is now possible for DNS name resolution to provide its information securely, in the sense that clients can verify that DNS information was provided by the domain operator and not tampered with in transit. The goal of technologies for DNS-based Authentication of Named Entities (DANE) is to use the DNS and DNSSEC to provide additional information about the cryptographic credentials associated with a domain, so that clients can use this information to increase the level of assurance they receive from the TLS handshake process. This document describes a set of use cases that capture specific goals for using the DNS in this way, and a set of requirements that the ultimate DANE mechanism should satisfy.
DNSの名前解決は、クライアントがDNS情報は、ドメイン事業者によって提供され、中に改ざんされていないことを確認することができるという意味で、安全にその情報を提供するためにDNSSEC [RFC4033]の出現により、それが可能になりました。名前付きエンティティ（DANE）のDNSベースの認証のための技術の目標は、クライアントは、彼らが受け取る保証レベルを高めるために、この情報を使用できるように、ドメインに関連付けられた暗号の資格情報についての追加情報を提供するために、DNSとDNSSECを使用することですTLSハンドシェイクプロセスから。この文書では、ユースケースこのようにDNSを使用するためのものキャプチャ具体的な目標のセット、および究極DANEメカニズムが満たすべき要件のセットを記述する。
Finally, it should be noted that although this document will frequently use HTTPS as an example application service, DANE is intended to apply equally to all applications that make use of TLS to connect to application services identified by domain names.
最後に、この文書は頻繁に例のアプリケーションサービスとしてHTTPSを使用しますが、DANEは、ドメイン名で識別されるアプリケーションサービスに接続するためにTLSを使用するすべてのアプリケーションにも同様に適用することを意図していることに留意すべきです。
This document also makes use of standard PKIX, DNSSEC, and TLS terminology. See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and RFC 5246 [RFC5246], respectively, for these terms. In addition, terms related to TLS-protected application services and DNS names are taken from RFC 6125 [RFC6125].
この資料はまた標準PKIX、DNSSEC、およびTLSの用語を使用します。これらの用語のために、それぞれRFC 5280 [RFC5280]、RFC 4033 [RFC4033]、およびRFC 5246 [RFC5246]を参照してください。また、TLSで保護されたアプリケーションサービスとDNS名に関連する用語は、RFC 6125 [RFC6125]から取られます。
Note in particular that the term "server" in this document refers to the server role in TLS, rather than to a host. Multiple servers of this type may be co-located on a single physical host, often using different ports, and each of these can use different certificates.
このドキュメントの「サーバー」という用語は、TLSでのサーバーの役割にはなく、ホストを指していることに特に注意してください。このタイプの複数のサーバーは、多くの場合、別のポートを使用して、単一の物理ホスト上に共存することができる、これらの各々は異なる証明書を使用することができます。
This document refers several times to the notion of a "domain holder". This term is understood to mean the entity that is authorized to control the contents of a particular zone. For example, the registrants of 2nd- or 3rd-level domains are the holders of those domains. The holder of a particular domain is not necessarily the entity that operates the zone.
この文書では、「ドメインの所有者」の概念に数回言及します。この用語は、特定のゾーンの内容を制御するために認可されたエンティティを意味すると理解されます。例えば、2nd-の登録又は第3レベルドメインは、それらのドメインの所有者です。特定のドメインの所有者は必ずしもゾーンを操作するエンティティではありません。
It should be noted that the presence of a valid DNSSEC signature in a DNS reply does not necessarily imply that the records protected by that signature were authorized by the domain holder. The distinction between the holder of a domain and the operator of the corresponding zone has several security implications, which are discussed in the individual use cases below.
DNS応答の有効なDNSSEC署名の存在は、必ずしもその署名によって保護されたレコードは、ドメインの所有者によって承認されたことを意味するものではないことに留意すべきです。ドメインのホルダと対応するゾーンのオペレータとの間の区別は、以下の個々のユースケースに記載されているいくつかのセキュリティ上の影響を有しています。
In this section, we describe the major use cases that the DANE mechanism should support. This list is not intended to represent all possible ways that the DNS can be used to support TLS authentication. Rather, it represents the specific cases that comprise the initial goals for DANE.
このセクションでは、DANEメカニズムがサポートしている必要があり、主要なユースケースを記述する。このリストは、DNSがTLS認証をサポートするために使用することができるすべての可能な方法を表すものではありません。むしろ、それはDANEの初期の目標を構成する具体的な例を表しています。
In the use cases below, we will refer to the following dramatis personae:
以下のユースケースでは、我々は以下の登場人物を指します。
Alice: The operator of a TLS-protected application service on the host alice.example.com, and administrator of the corresponding DNS zone.
アリス：TLSで保護されたアプリケーションのホストalice.example.com上のサービス、および対応するDNSゾーンの管理者のオペレータ。
Bob: A client connecting to alice.example.com.
ボブ：alice.example.comに接続しているクライアント。
Charlie: A well-known CA that issues certificates with domain names as identifiers.
チャーリー：識別子としてドメイン名を持つ証明書を発行し、よく知られたCA。
Oscar: An outsourcing provider that operates TLS-protected application services on behalf of customers.
オスカー：顧客に代わってTLSで保護されたアプリケーションサービスを運営アウトソーシング・プロバイダー。
Trent: A CA that issues certificates with domain names as identifiers, but is not generally well-known.
トレント：識別子としてドメイン名を持つ証明書を発行するが、一般的によく知られていないCA。
These use cases are framed in terms of adding verification steps to TLS server identity checking on the part of application service clients. In application services where the clients are also identified by domain names (e.g., Extensible Messaging and Presence Protocol (XMPP) server-to-server connections), the same considerations and use cases are applicable to the application server's checking of identities in TLS client certificates.
これらのユースケースは、アプリケーション・サービス・クライアントの一部にチェックTLSサーバIDに検証ステップを追加するという点で囲まれています。クライアントは、ドメイン名（例えば、拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）サーバー間接続）、同じ考慮事項とユースケースによって識別されたアプリケーションサービスではTLSクライアント証明書におけるアイデンティティのアプリケーションサーバのチェックに適用されます。
Alice runs a website on alice.example.com and has obtained a certificate from the well-known CA Charlie. She is concerned that other well-known CAs might issue certificates for alice.example.com without her authorization, which clients would accept. Alice would like to provide a mechanism for visitors to her site to know that they should expect alice.example.com to use a certificate issued under the CA that she uses (Charlie) and not another CA. That is, Alice is recommending that the client verify that there is a valid certificate chain from the server certificate to Charlie before accepting the server certificate. (For example, in the TLS handshake, the server might include Charlie's certificate in the server Certificate message's certificate_list structure [RFC5246]).
アリスはalice.example.com上でウェブサイトを運営し、よく知られたCAチャーリーから証明書を取得しています。彼女は他のよく知られたCAは、クライアントが受け入れるだろう彼女の許可なしalice.example.comの証明書を発行する可能性があることを懸念しています。アリスは、彼らは彼女が（チャーリー）を使用してCAの下で発行された証明書ではなく、別のCAを使用するようにalice.example.comを期待するべきであることを知っている彼女のサイトへの訪問者のためのメカニズムを提供したいと思いますつまり、アリスは、クライアントがサーバ証明書を受け入れる前に、チャーリーへのサーバ証明書から有効な証明書チェーンがあることを確認することを推奨しています。 （例えば、TLSハンドシェイクで、サーバは、サーバ証明書メッセージのcertificate_list構造[RFC5246]にチャーリーの証明書が含まれる場合があります）。
When Bob connects to alice.example.com, he uses this mechanism to verify that the certificate presented by the server was issued under the proper CA, Charlie. Bob also performs the normal PKIX validation procedure for this certificate, in particular verifying that the certificate chains to a trust anchor (possibly Charlie's CA, if Bob accepts Charlie's CA as a trust anchor).
ボブはalice.example.comに接続すると、彼は、サーバーによって提示された証明書が正しいCA、チャーリーの下で発行されたことを確認するために、このメカニズムを使用しています。ボブはまた、特定のベリファイでは、この証明書のためにそのトラストアンカーへの証明書チェーン（多分チャーリーのCA、ボブはトラストアンカーとしてチャーリーのCAを受け入れる場合）を通常のPKIX検証手順を実行します。
Alice may wish to provide similar information to an external CA operator, Charlie. Prior to issuing a certificate for alice.example.com to someone claiming to be Alice, Charlie needs to verify that Alice is actually requesting a certificate. Alice could indicate her preferred CA using DANE to CAs as well as relying parties. Charlie could then check to see whether Alice said that her certificates should be issued by Charlie or another CA. Note that this check does not guarantee that the precise entity requesting a certification from Charlie actually represents Alice -- only that Alice has authorized Charlie to issue certificates for her domain to properly authorized individuals.
アリスは、外部CAのオペレータ、チャーリーに同様の情報を提供することを望むかもしれません。アリスであると主張する誰かにalice.example.comのための証明書を発行する前に、チャーリーは、アリスが実際に証明書を要求していることを確認する必要があります。アリスはCASにだけでなく、依拠当事者DANEを使用して、彼女の優先CAを示している可能性があり。チャーリーは、アリスは彼女の証明書がチャーリーまたは別のCAによって発行されるべきであると言ったかどうかをチェックできますアリスは彼女のドメイン適切に承認する個人のための証明書を発行するためにチャーリーを承認した唯一のこと - このチェックは、チャーリーからの認証を要求して、正確なエンティティが実際にアリスを表していることを保証するものではないことに注意してください。
In principle, DANE information expressing CA constraints can be presented with or without DNSSEC protection. Presenting DANE information without DNSSEC protection does not introduce any new vulnerabilities, but neither does it add much assurance. Deletion of records removes the protection provided by this constraint, but the client is still protected by CA practices (as now). Injected or modified false records are not useful unless the attacker can also obtain a certificate for the target domain. Thus, in the worst case, tampering with these constraints increases the risk of false authentication to the level that is now standard.
原則的には、CAの制約を表現DANE情報は、DNSSECの保護の有無にかかわらず提示することができます。 DNSSEC保護なしDANE情報を提示しても、新しい脆弱性を導入していませんが、どちらもそれははるかに保証を追加していないん。レコードの削除は、この制約による保護を削除しますが、クライアントはまだ（今のように）CAの実践により保護されています。攻撃者は、ターゲットドメインの証明書を取得することができない限り、注入されたまたは変更された偽のレコードは有用ではありません。このように、最悪の場合には、これらの制約を改ざんすることは今や標準であるレベルに誤った認証のリスクを増大させます。
Using DANE information for CA constraints without DNSSEC provides a very small incremental security feature. Many common attacks against TLS connections already require the attacker to inject false A or AAAA records in order to steer the victim client to the attacker's server. An attacker that can already inject false DNS records can also provide fake DANE information (without DNSSEC) by simply spoofing the additional records required to carry the DANE information.
DNSSECなしCAの制約のためにDANE情報を使用すると、非常に小さな増分セキュリティ機能を提供します。 TLS接続に対して、多くの一般的な攻撃は、すでに攻撃者のサーバに被害者のクライアントを操縦するために、偽のAまたはAAAAレコードを注入するために、攻撃者が必要です。すでに偽のDNSレコードを挿入することができ、攻撃者は、単にDANE情報を運ぶために必要な追加のレコードを偽装することによって（DNSSECなし）フェイクDANE情報を提供することができます。
Injected or modified false DANE information of this type can be used for denial of service, even if the attacker does not have a certificate for the target domain. If an attacker can modify DNS responses that a target host receives, however, there are already much simpler ways of denying service, such as providing a false A or AAAA record. In this case, DNSSEC is not helpful, since an attacker could still cause a denial of service by blocking all DNS responses for the target domain.
このタイプの注入されたまたは変更された虚偽のDANE情報は、攻撃者がターゲットドメインの証明書を持っていない場合でも、サービス拒否のために使用することができます。攻撃者はターゲットホストが受信するDNS応答を変更することができた場合は、しかし、そのような虚偽のAまたはAAAAレコードを提供するなどのサービスを拒否するはるかに単純な方法は、既に存在しています。攻撃者は、まだターゲットドメインのすべてのDNS応答をブロックすることにより、サービス拒否を引き起こす可能性がありますので、この場合には、DNSSECは、有用ではありません。
Continuing to require PKIX validation also limits the degree to which DNS operators (as distinct from the holders of domains) can interfere with TLS authentication through this mechanism. As above, even if a DNS operator falsifies DANE records, it cannot masquerade as the target server unless it can also obtain a certificate for the target domain.
PKIX検証を必要とし続けることも、（ドメインの所有者とは異なるような）DNSオペレータはこのメカニズムを介してTLS認証を妨害し得る程度を制限します。それはまた、ターゲットドメインの証明書を取得することができない限り、上記のように、DNSのオペレータはDANEレコードを改ざんしたとしても、それは、ターゲットサーバーになりすますことができません。
Alice runs a website on alice.example.com and has obtained a certificate from the well-known CA Charlie. She is concerned about additional, unauthorized certificates being issued by Charlie as well as by other CAs. She would like to provide a way for visitors to her site to know that they should expect alice.example.com to present a specific certificate. In TLS terms, Alice is letting Bob know that this specific certificate must be the first certificate in the server Certificate message's certificate_list structure [RFC5246].
アリスはalice.example.com上でウェブサイトを運営し、よく知られたCAチャーリーから証明書を取得しています。彼女はチャーリーによってだけでなく、他のCAによって発行され、追加、不正な証明書を懸念しています。彼女は、彼らがalice.example.comは、特定の証明書を提示することを期待すべきであることを知っている彼女のサイトへの訪問者のための方法を提供したいと思います。 TLSの用語では、アリスはボブが、この特定の証明書は、サーバ証明書メッセージのcertificate_list構造[RFC5246]内の最初の証明書でなければならないことを知らせるれます。
When Bob connects to alice.example.com, he uses this mechanism to verify that the certificate presented by the server is the correct certificate. Bob also performs the normal PKIX validation procedure for this certificate, in particular verifying that the certificate chains to a trust anchor.
ボブはalice.example.comに接続すると、彼は、サーバーによって提示された証明書が正しい証明書であることを確認するために、このメカニズムを使用しています。ボブはまた、特定のベリファイでは、この証明書の通常のPKIX検証手順を実行することトラストアンカーへの証明書チェーン。
The security implications for this case are the same as for the "CA Constraints" case above.
この場合のセキュリティ上の影響は、上記の「CAの制約」の場合と同じです。
Alice would like to be able to generate and use certificates for her website on alice.example.com without involving an external CA at all. Alice can generate her own certificates today, making self-signed certificates and possibly certificates subordinate to those certificates. When Bob receives such a certificate in a TLS handshake, however, he doesn't automatically have a way to verify that the issuer of the certificate is actually Alice, because he doesn't necessarily possess Alice's corresponding trust anchor. This concerns him because an attacker could present a different certificate and perform a man-in-the-middle attack. Bob would like to protect against this.
アリスは、すべての外部CAを介さずalice.example.com上の彼女のウェブサイトのための証明書を生成し、使用できるようにしたいと思います。アリスは、自己署名証明書と、おそらくそれらの証明書に下位証明書を作り、今日の彼女の自身の証明書を生成することができます。ボブは、TLSハンドシェイクで、このような証明書を受信したとき、彼は必ずしもアリスの対応トラストアンカーを持たないので、しかし、彼は自動的に、証明書の発行者が実際にアリスであることを確認する方法はありません。攻撃者が別の証明書を提示し、man-in-the-middle攻撃を行う可能性があるため、これは彼に関するものです。ボブはこのから保護したいと思います。
Alice would thus like to publish information so that visitors to her site can know that the certificates presented by her application services are legitimately hers. When Bob connects to alice.example.com, he uses this information to verify that the certificate presented by the server has been issued by Alice. Since Bob can bind certificates to Alice in this way, he can use Alice's CA as a trust anchor for purposes of validating certificates for alice.example.com. Alice can additionally recommend that clients accept only her certificates using the CA constraints described above.
アリスは、このように自分のサイトへの訪問者が彼女のアプリケーションサービスが提示した証明書は、彼女が合法的であることを知ることができるように情報を公開したいと思います。ボブはalice.example.comに接続すると、彼は、サーバーによって提示された証明書は、アリスによって発行されたことを確認するために、この情報を使用しています。ボブは、このようにアリスに証明書をバインドすることができますので、彼はalice.example.comの証明書を検証する目的で、トラストアンカーとしてアリスのCAを使用することができます。アリスは、さらに、クライアントは、上記のCAの制約を使用してのみ、彼女の証明書を受け入れることをお勧めすることができます。
As in Section 3.1 above, Alice may wish to represent this information to potential third-party CAs (Charlie) as well as to relying parties (Bob). Since publishing a certificate in a DANE record of this form authorizes the holder of the corresponding private key to represent alice.example.com, a CA that has received a request to issue a certificate from alice.example.com could use the DANE information to verify the requestor's authorization to receive a certificate for that domain. For example, a CA might choose to issue a certificate for a given domain name and public key only when the holder of the domain name has provisioned DANE information with a certificate containing the public key.
上記セクション3.1のように、アリスは、依存者（ボブ）へ、ならびに潜在的なサードパーティCA（チャーリー）にこの情報を表現することを望むかもしれません。このフォームのDANEレコードに証明書を公開することはalice.example.comを表現するために対応する秘密鍵の所有者を許可するので、alice.example.comから証明書を発行する要求を受信したCAは、にDANE情報を使用することができますそのドメインの証明書を受け取るために、要求者の許可を確認します。例えば、CAは、特定のドメイン名とドメイン名の所有者が公開鍵を含む証明書を使用してDANE情報をプロビジョニングしている唯一の公開鍵の証明書を発行することを選択するかもしれません。
Note that this use case is functionally equivalent to the case where Alice doesn't issue her own certificates, but uses Trent's CA, which is not well-known. In this case, Alice would be advising Bob that he should treat Trent as a trust anchor for purposes of validating Alice's certificates, rather than a CA operated by Alice herself. Bob would thus need a way to securely obtain Trent's trust anchor information, namely through DANE information.
このユースケースは、アリスが彼女自身の証明書を発行しない場合と機能的に同等であるが、よく知られていないトレントのCAを、使用することに注意してください。この場合、アリスは彼がアリスの証明書を検証する目的で、トラストアンカーではなく、アリス自身が運営するCAとしてトレントを扱う必要があることをボブに助言されるだろう。ボブは、このように、すなわちDANE情報を通じて、安全トレントの信頼点情報を取得する方法が必要になります。
Alice's advertising of trust anchor material in this way does not guarantee that Bob will accept the advertised trust anchor. For example, Bob might have out-of-band information (such as a pre-existing local policy) that indicates that the CA advertised by Alice (Trent's CA) is not trustworthy, which would lead him to decide not to accept Trent as a trust anchor, and thus to reject Alice's certificate if it is issued under Trent's CA.
このようにトラストアンカー材料のアリスの広告は、ボブは、アドバタイズトラストアンカーを受け入れることを保証するものではありません。例えば、ボブはとしてトレントを受け入れるしないことを決定するために彼を導くことになる、アリス（トレントのCA）によってアドバタイズCAが信頼できないことを示している（例えば、既存のローカルポリシーなど）アウトオブバンド情報を持っているかもしれませんそれはトレントのCA.の下で発行された場合、アリスの証明書を拒否することがアンカーを信頼し、
Providing trust anchor material in this way clearly requires DNSSEC, since corrupted or injected records could be used by an attacker to cause clients to trust an attacker's certificate (assuming that the attacker's certificate is not rejected by some other local policy). Deleted records will only result in connection failure and denial of service, although this could result in clients re-connecting without TLS (a downgrade attack), depending on the application. Therefore, in order for this use case to be safe, applications must forbid clients from falling back to unsecured channels when records appear to have been deleted (e.g., when a missing record has no NSEC or NSEC3 record).
破損または注入されたレコードは（攻撃者の証明書は他のいくつかのローカルポリシーによって拒否されていないと仮定して）攻撃者の証明書を信頼するようにクライアントを引き起こすために、攻撃者によって使用される可能性があるので、このようにトラストアンカー材料を提供することは明らかに、DNSSECが必要です。これは、アプリケーションに応じて、再接続TLS（ダウングレード攻撃）せずにクライアントにつながる可能性が削除されたレコードは、接続に失敗し、サービス拒否が発生します。レコードが削除されたように見えるときしたがって、このユースケースの注文は安全であるとして、アプリケーションがセキュリティ保護されていないチャンネルにフォールバックからクライアントを禁止しなければならない（例えば、欠落しているレコードは何のNSECまたはNSEC3レコードを持っていない場合）。
By the same token, this use case puts the most power in the hands of DNS operators. Since the operator of the appropriate DNS zone has de facto control over the content and signing of the zone, he can create false DANE records that bind a malicious party's certificate to a domain. This risk is especially important to keep in mind in cases where the operator of a DNS zone is a different entity than the holder of the domain, as in DNS hosting/outsourcing arrangements, since in these cases the DNS operator might be able to make changes to a domain that are not authorized by the holder of the domain.
同様に、このユースケースは、DNSオペレータの手に最も力を入れます。適切なDNSゾーンのオペレータは、ゾーンの内容と署名の上に事実上のコントロールを持っているので、彼はドメインに悪質なパーティの証明書をバインド偽DANEレコードを作成することができます。このリスクは、これらの場合にDNSのオペレータが変更を加えることができるかもしれないので、DNSゾーンのオペレータは、DNSホスティング/アウトソーシング契約のように、ドメインの所有者とは異なる実体である場合には心に留めておくことが特に重要ですドメインの所有者によって許可されていないドメインに。
It should be noted that DNS operators already have the ability to obtain certificates for domains under their control, under certain CA policies. In the current system, CAs need to verify that an entity requesting a certificate for a domain is actually the legitimate holder of that domain. Typically, this is done using information published about that domain, such as WHOIS email addresses or special records inserted into a domain. By manipulating these values, it is possible for DNS operators to obtain certificates from some well-known certificate authorities today without authorization from the true domain holder.
DNSの事業者はすでに特定のCAの方針の下で、自分の管理下にドメインの証明書を取得する能力を持っていることに留意すべきです。現在のシステムでは、CAは、ドメインの証明書を要求しているエンティティが実際にそのドメインの正当な所有者であることを確認する必要があります。通常、このようなWHOIS電子メールアドレスまたはドメインに挿入された特別な記録として、そのドメインについての公開された情報を使用して行われます。 DNS事業者が真のドメイン所有者からの許可なしに、今日いくつかのよく知られた認証局から証明書を取得するためにこれらの値を操作することによって、それが可能です。
In addition to guarding against CA mis-issue, CA constraints and certificate constraints can also be used to constrain the set of certificates that can be used by an outsourcing provider. Suppose that Oscar operates alice.example.com on behalf of Alice. In particular, Oscar then has de facto control over what certificates to present in TLS handshakes for alice.example.com. In such cases, there are a few ways that DNS-based information about TLS certificates could be configured; for example:
CAの誤発行し、CAの制約と証明書の制約に対する保護に加えて、アウトソーシング・プロバイダーで使用できる証明書のセットを制約するために使用することができます。オスカーは、アリスに代わってalice.example.com動作することとします。具体的には、オスカーは、alice.example.comのためにTLSハンドシェイク中に提示する証明書をオーバー事実上のコントロールを持っています。このような場合には、TLS証明書についてDNSベースの情報を設定することができ、いくつかの方法があります。例えば：
1. Alice has the A/AAAA records in her DNS and can sign them along with the DANE record, but Oscar and Alice now need to have tight coordination if the addresses and/or the certificates change.
1.アリスは彼女のDNSにA / AAAAレコードを持っており、DANEレコードと一緒にそれらを署名することができますが、オスカーとアリスは今のアドレスおよび/または証明書が変更された場合タイトな連携を持っている必要があります。
2. Alice refers to Oscar's DNS by delegating a sub-domain name to Oscar, and has no control over the A/AAAA, DANE, or any other pieces under Oscar's control.
2.アリスは、オスカーにサブドメイン名を委任することによってオスカーのDNSを参照して、A / AAAA、DANE、又はオスカーの制御下で、他のピースを制御できません。
3. Alice can put DANE records into her DNS server but delegate the address records to Oscar's DNS server. This means that Alice can control the usage of certificates, but Oscar is free to move the servers around as needed. The only coordination needed is when the certificates change, and then it would depend on how the DANE record is set up (i.e., a CA or an end-entity certificate pointer).
3.アリスはDNSサーバにDANEレコードを置くが、オスカーのDNSサーバーにアドレスレコードを委任することができます。これはアリスが証明書の使用を制御することができることを意味しますが、オスカーは、必要に応じてサーバを周りに自由に動くことができます。証明書が変更されたときに必要なだけの調整であり、それはDANEレコードが設定されているかに依存するであろう（すなわち、CAまたはエンドエンティティ証明書のポインタ）。
Which of these deployment patterns is used in a given deployment will determine what sort of constraints can be expressed by which actors. In cases where Alice controls DANE records (1 and 3), she can use CA and certificate constraints to control what certificates Oscar presents for Alice's application services. For instance, Alice might require Oscar to use certificates under a given set of CAs. This control, however, requires that Alice update DANE records when Oscar needs to change certificates. Cases where Oscar controls DANE records allow Oscar to maintain more autonomy from Alice, but by the same token, Alice cannot enforce any requirements on the certificates that Oscar presents in TLS handshakes.
これらの展開パターンのどの与え展開で使用されている俳優で表すことができる制約の種類を決定します。アリスはDANEレコード（1および3）を制御する場合には、彼女はオスカーがアリスのアプリケーション・サービスのために提示するものの証明書を制御するためにCA証明書および制約を使用することができます。例えば、アリスは、CAの特定のセットの下で証明書を使用するようにオスカーが必要な場合があります。このコントロールは、しかし、オスカーは、証明書を変更する必要があるときにアリスはDANEレコードを更新する必要があります。オスカーはDANEレコードを制御ケースは、オスカーがアリスからのより多くの自主性を維持することができますが、同じトークンによって、アリスはオスカーがTLSハンドシェイク中に提示した証明書のいずれかの要件を強制することはできません。
In addition to supporting the above use cases, the DANE mechanism must satisfy several lower-level operational and protocol requirements and goals.
上記のユースケースをサポートすることに加えて、デーン機構は、いくつかの低レベル動作およびプロトコル要件と目標を満たさなければなりません。
Multiple Ports: DANE should be able to support multiple application services with different credentials on the same named host, distinguished by port number.
複数のポート：DANEは、ポート番号で区別同じ名前のホスト、上の別の資格情報を使用して複数のアプリケーション・サービスをサポートすることができるはずです。
No Downgrade: An attacker who can tamper with DNS responses must not be able to make a DANE-compliant client treat a site that has deployed DANE and DNSSEC like a site that has deployed neither.
いいえダウングレードん：DNSレスポンスを改ざんすることができ、攻撃者はDANE-準拠のクライアントはどちらも展開されていないサイトのようDANEとDNSSECを導入したサイトを処理させることができない必要があります。
Encapsulation: If there is DANE information for the name alice.example.com, it must only affect application services hosted at alice.example.com.
カプセル化：名前alice.example.comためDANE情報がある場合は、それが唯一のalice.example.comでホストされているアプリケーションサービスに影響を与える必要があります。
Predictability: Client behavior in response to DANE information must be defined in the DANE specification as precisely as possible, especially for cases where DANE information might conflict with PKIX information.
予測可能性：クライアントの行動DANE情報に応じて、特にDANE情報は、PKIX情報と競合する可能性のある場合のために、可能な限り正確にDANE仕様で定義されている必要があります。
Opportunistic Security: The DANE mechanism must allow a client to determine whether DANE information is available for a site, so that a client can provide the highest level of security possible for a given application service. Clients that do not support DANE should continue to work as specified, regardless of whether DANE information is present or not.
日和見セキュリティ：クライアントが指定したアプリケーション・サービスのための可能な最高レベルのセキュリティを提供できるようにDANEメカニズムは、クライアントがDANE情報をサイトで利用可能であるかどうかを判断できるようにする必要があります。 DANEをサポートしていないクライアントは、指定されたとおりにかかわらずDANE情報が存在するかどうかの、作業を継続する必要があります。
Combination: The DANE mechanism must allow multiple DANE statements of the above forms to be combined. For example, a domain holder should be able to specify that clients should accept a particular certificate (Section 3.2) as well as any certificate issued by its own CA (Section 3.3). The precise types of combination allowed will be defined by the DANE protocol.
組み合わせ：DANE機構は、上記形態の複数DANEステートメントを組み合わせることを可能にする必要があります。例えば、ドメインの所有者は、クライアントが特定の証明書（セクション3.2）、ならびに独自のCA（3.3節）によって発行された証明書を受け入れるように指定することができなければなりません。許容組合せの正確な種類はDANEプロトコルによって定義されます。
Roll-over: The DANE mechanism must allow a site to transition from using one DANE mechanism to another. For example, a domain holder should be able to migrate from using DANE to assert a domain-issued certificate (Section 3.3) to using DANE to require an external CA (Section 3.1), or vice versa. The DANE mechanism must also allow roll-over between records of the same type, e.g., when changing CAs.
ロールオーバー：DANEメカニズムは、サイトが別のDANEメカニズムを使用してから移行できるようにする必要があります。例えば、ドメイン・ホルダーは、その逆の外部CA（3.1節）を必要とするDANEを用いて、以上にドメイン発行された証明書（セクション3.3）をアサートするDANEを使用してから移動することができなければなりません。 CAを変更するときDANE機構はまた、例えば、同じタイプのレコード間のロールオーバーを可能にしなければなりません。
Simple Key Management: DANE should have a mode in which the domain holder only needs to maintain a single long-lived public/private key pair.
シンプルなキー管理：DANEは、ドメイン所有者は、単一の長命の公開鍵/秘密鍵のペアを維持するために必要なモードを持っている必要があります。
Minimal Dependencies: It should be possible for a site to deploy DANE without also deploying anything else, except DNSSEC.
最小限の依存関係：サイトがDNSSECを除いて、また何かを導入せずにDANEを展開することが可能でなければなりません。
Minimal Options: Ideally, DANE should have only one operating mode. Practically, DANE should have as few operating modes as possible.
最小限のオプションは：理想的には、DANEは、唯一の動作モードを持っている必要があります。実際には、DANEはできるだけ少ない動作モードとして持つべきです。
Wildcards: The mechanism for distributing DANE information should allow the use of DNS wildcard labels (*) for setting DANE information for all names within a wildcard expansion.
ワイルドカード：DANE情報を配信するためのメカニズムは、ワイルドカードの展開内のすべての名前のためにDANE情報を設定するためのDNSのワイルドカードのラベル（*）の使用を可能にしなければなりません。
Redirection: The mechanism for distributing DANE information should work when the application service name is the result of following a DNS redirection chain (e.g., via CNAME or DNAME).
リダイレクション：アプリケーション・サービス名は、（CNAMEまたはDNAMEを介して、例えば）DNSリダイレクション鎖を、以下の結果であるときに動作するはずDANE情報を配信するためのメカニズム。
Thanks to Eric Rescorla for the initial formulation of the use cases, Zack Weinberg and Phillip Hallam-Baker for contributing other requirements, and the whole DANE working group for helpful comments on the mailing list.
その他の要件を貢献するためのユースケース、ザックワインバーグとフィリップハラム - ベイカーの初期製剤、およびメーリングリストの有益なコメントのための全体DANEワーキンググループのエリックレスコラに感謝します。
The primary focus of this document is the enhancement of TLS authentication procedures using the DNS. The general effect of such mechanisms is to increase the role of DNS operators in authentication processes, either in place of or in addition to traditional third-party actors such as commercial certificate authorities. The specific security implications of the respective use cases are discussed in their respective sections above.
この文書の主な焦点は、DNSを使用して、TLS認証手順の拡張です。そのようなメカニズムの一般的な効果は、の代わりに、または、そのような商用の認証機関としての伝統的なサードパーティ製の俳優に加えてのいずれかで、認証プロセスにおけるDNS事業者の役割を高めることです。各ユースケースの具体的なセキュリティ上の影響は、上記のそれぞれのセクションに記載されています。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]サンアンドレ、P.およびJ.ホッジス、「表現およびTransport Layer Security（TLS）の文脈でインターネット公開鍵インフラストラクチャの使用X.509内のドメインベースのアプリケーションサービスのアイデンティティの検証（PKIX）証明書」、 RFC 6125、2011年3月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595]ニューマン、C.、 "IMAP、POP3およびACAPとTLSを使用する"、RFC 2595、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]ホフマン、P.、 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"、RFC 3207、2002年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"、RFC 6120、2011年3月。
Author's Address
著者のアドレス
Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US
リチャード・バーンズBBNテクノロジーズ9861ブロークン・ランドパークウェイ、コロンビア、MD 21046米国
Phone: +1 410 290 6169 EMail: rbarnes@bbn.com
電話：+1 410 290 6169 Eメール：rbarnes@bbn.com