Network Working Group Jiankang. Yao Internet-Draft CNNIC Intended status: Standards Track September 10, 2010 Expires: March 14, 2011 Resolver Key Identified DNS Query draft-yao-dnsop-resolverkey-01.txt Abstract DNSSEC hardens the DNS between the root server and the recursive resolver. It does not secure the communications between the stub resolver and the recursive resolver. This document specifies the mechanism which deals with securing the communications between them. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 14, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Yao Expires March 14, 2011 [Page 1] Internet-Draft resolverkey September 2010 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The RKIQ mechanism . . . . . . . . . . . . . . . . . . . . . . 3 4. Using RKIQ as the trust measurement . . . . . . . . . . . . . . 4 4.1. DNS package siganature . . . . . . . . . . . . . . . . . . 4 4.2. Validating the siganature . . . . . . . . . . . . . . . . . 4 4.3. Validating the public key . . . . . . . . . . . . . . . . . 4 5. RKIQ Key Management . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Get the trust from the root anchor . . . . . . . . . . . . 5 5.2. Get the trust from the resolver key server . . . . . . . . 5 5.3. Get the trust from the recursive resolver query . . . . . . 5 6. RKIQ Key Format and storage . . . . . . . . . . . . . . . . . . 5 6.1. Resolver Public key format and storage . . . . . . . . . . 5 6.2. DNS message siganature . . . . . . . . . . . . . . . . . . 6 7. Acquire of the resolver domain name . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6 11.1. draft-yao-dnsop-rkiq: Version 00 . . . . . . . . . . . . . 6 12. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Yao Expires March 14, 2011 [Page 2] Internet-Draft resolverkey September 2010 1. Introduction DNSSEC (Domain Name System Security Extensions) [RFC4033] [RFC4034] [RFC4035] has secured the communication between the root server and the recursive resolver. The stub resolver is the piece of the Domain Name System that resides on nearly every computer and translates an application's request for data into a DNS query, and then sends that query to one or more resolvers or name servers that function as the resolver. It is impractical for these stub resolvers to perform general [RFC4035] authentication and they would naturally depend on their validating resolvers to perform such services for them. To do so securely requires secure communication of queries and responses. [RFC4035] provides public key transaction signatures to support this, but such signatures are very expensive computationally to generate. So the DNSSEC validating function is normally deployed in recursive resolvers insteand of stub resolvers. How to get a security communication between the stub resolver and the validaing resolver (resursive resolver) is a big challange ahead of us. TSIG[RFC2845] proposes to solve this problem with the symmentic key. Although, TSIG is lightweight, and provides both authentication and integrity checking, TSIG requires configuration of a shared secret, so it suffers from a nasty key distribution problem. If your recursive resolvers handles hundreds or thousands of stub resolvers, you'd need to configure a shared secret with each of them. This document specifies the new mechanism which deals with securing the communications between the stub resolver and the recursive resolver. 1.1. Terminology All the basic terms used in this specification are defined in the documents [RFC1034], and [RFC1035]. In this document, there are two kinds of resolvers: the stub resolver and the recursive resolver. In this document, the resolver specially means the recursive resolver. 2. Motivation The RKIQ mechanism makes the DNSSEC much safer. It extends the DNSSEC safety from the root to the stub resolver. This solution tackles the DNSSEC last mile problem. 3. The RKIQ mechanism This mechanisem will use the public key technology to make sure that the dns response package from the recursive resolvers to the stub resolvers is correct and unchangeable. The stub resolver will store the public key of the reursive resolver domain. The reursive Yao Expires March 14, 2011 [Page 3] Internet-Draft resolverkey September 2010 resolver will give the siganature of all the response DNS data. Every recursive resolver has its own domain name. This domain name will have its own txt resource record. This txt resource record will store its own public key. +-------------+ +------+------+ | Trust Anchor| . . . . . . . . .>| Resolver | |(root anchor)| . | Domain key | +------+------+ . +-------------+ | . ^ | ^ . | | +--------------------------.--------------------+ | V | +------+------+ . . . > . +-------------+ | | +-----------+ | | Stub | | Resolver +--|--+ -->+ DNS | | | Resolver +------------->| Validator | | | Server | | +-------------+ +-------------+ | +-----------+ | RKIQ Service | +-----------------------------------------------+ 4. Using RKIQ as the trust measurement 4.1. DNS package siganature Every RKIQ enabled resolver will have at leat a pair of key, public key and private key. When the DNS message is sent from the resolver, the resolver will use the private key to generate a siganature for this DNS message. The siganature process will follow the definiton of [RFC4034] Then, it add the siganature to the additional section of the dns message. The format is that "owner name class rdata". The form of the rdata is algorithm + the siganature. 4.2. Validating the siganature The stub resolver receives the DNS message from the recursive resolver, removes the resolver domain name's txt resource record, and make the verification. If varification fails, it means that the dns has been demaged. otherwise, this dns message is a correct response without falsification. 4.3. Validating the public key The public key is also in the additional section of the dns message. The stub resolver must compare this public key with the public key stored in the local stub resolver. If these two keys are not same, either the dns message is damaged or the public key has been be updated by the recursive resolver. If the public key has been Yao Expires March 14, 2011 [Page 4] Internet-Draft resolverkey September 2010 updated, the stub resolve should use key management technology to update its key immediately before trying to verify the siganature. 5. RKIQ Key Management When the stub resolver initiats its configuration, it must get the root anchor or the public key of the recursive resolver or both through the security communications. 5.1. Get the trust from the root anchor If the trust anchor is the root anchor, the stub resolver should act as the recursive resolver and query the stub resolver's domain name for its public key. 5.2. Get the trust from the resolver key server The recursiver resolver public key can be stored in some public servers. The stub resolver can get the public key directly through the security transfering. 5.3. Get the trust from the recursive resolver query The recursive resolver may have two pairs of keys. They have different time expiration. When one is roll out, the other can transfer the new public key to the stub resolvers. 6. RKIQ Key Format and storage This document proposes a public key storage of the recursive resolver in DNS with the txt type resource record, and a syntesithed txt type resource record in the additonal section of the DNS message with the storage of the DNS message siganature. 6.1. Resolver Public key format and storage A stub resolver attempting to verify a RKIQ signature should obtain the public key that is associated with the signature for that message. The DNS record storing the public key with the domain owner name of ._resolver_domainkey. has a DNSKEY type which provides the public key information of the resolver. The DNSKEY definition will follow the definition of section section 2 of [RFC4034]. The administrator of the recursive resolver containing the relevant resolver domain name adds this information. Initial RKIQ DNS information is contained within DNSKEY RRs. Yao Expires March 14, 2011 [Page 5] Internet-Draft resolverkey September 2010 6.2. DNS message siganature The recursiver resolver which receives a request from the stub host about the security answer, should response a message including a The DNS record storing the siganatue with the domain owner name of ._resolver_domainkey. has a TXT type which provides the siganature information of the DNS message. The TXT definition will follow the definition of [RFC1034]. The administrator of the recursive resolver containing the relevant resolver domain name adds this information. 7. Acquire of the resolver domain name There are two ways to get the resolver domain name. The user can configure the resolver's domain name and IP address if they know they beforehand. If the user know the resolver's IP address only, the stub resolver can send a query of the resolver's IP address for the domain name. 8. IANA Considerations There is no IANA consideration. 9. Security Considerations The stub host should also get the trust anchor through the security communication. 10. Acknowledgements Many ideas are from the discussion in the DNSOP and DNSEXT mailling list. Thanks a lot to all in the list. Many important comments and suggestions are contributed by many members of the DNSEXT and DNSOP WGs. 11. Change History [[anchor19: RFC Editor: Please remove this section.]] 11.1. draft-yao-dnsop-rkiq: Version 00 Yao Expires March 14, 2011 [Page 6] Internet-Draft resolverkey September 2010 o resolver key identified query 12. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, April 2004. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. Yao Expires March 14, 2011 [Page 7] Internet-Draft resolverkey September 2010 Author's Address Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813007 Email: yaojk@cnnic.cn Yao Expires March 14, 2011 [Page 8]