Network Working Group J. Yao Internet-Draft X. Lee Intended status: Standards Track W. Mao Expires: February 13, 2011 CNNIC August 12, 2010 Resolver Key Identified DNS Query draft-yao-dnsop-resolverkey-00.txt Abstract DNSSEC hardens the DNS from the root server to 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 February 13, 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, et al. Expires February 13, 2011 [Page 1] Internet-Draft resolverkey August 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 . . . . . . . . . . . . . . . . . . . . . . 4 4. Using RKIQ as the trust measurement . . . . . . . . . . . . . . 4 4.1. DNS package siganature . . . . . . . . . . . . . . . . . . 4 4.2. Validating the siganature . . . . . . . . . . . . . . . . . 5 4.3. Validating the DNSKEY . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . 6 6. Acquire of the resolver domain name . . . . . . . . . . . . . . 6 7. TXT, MSIG and SIG(0) . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6 11.1. draft-yao-dnsop-rkiq: Version 00 . . . . . . . . . . . . . 7 12. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Yao, et al. Expires February 13, 2011 [Page 2] Internet-Draft resolverkey August 2010 1. Introduction DNSSEC (Domain Name System Security Extensions) [RFC4033] [RFC4034] [RFC4035] has secured the communication from the root server to 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 secured communication of queries and responses. [RFC4035] provides public key transaction signatures and a serious validating procedure to support this, but it needs very expensive computational resources. So the DNSSEC validating function is normally deployed in recursive resolvers instead of stub resolvers. How to get a security communication between the stub resolver and the validating resolver (recursive resolver) is a challenge ahead of us. TSIG[RFC2845] proposes to solve this problem with the key. Although, TSIG is lightweight, and provides both authentication and integrity checking, TSIG requires configuration of a shared secret, so it suffers from a serious 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. The proposed solution of the resolver key identified query (RKIQ) requests that every RKIQ enabled resolver has the domain name. The public key for the resolver can be stored in the DNS for the future query. The resolver can secure the communication between the recursive resolver and the stub resolver through some signature of the outgoing DNS messages. The RKIQ mechanism makes the DNSSEC much safer. It extends the DNSSEC safety from the root to the stub resolver. 1.1. Terminology All the basic terms used in this specification are defined in the documents [RFC1034], and [RFC1035]. In this document, the resolver refers to the recursive resolver. 2. Motivation This document tries to secure the communication between the stub resolver and the recursive resolver and tackles the problem of DNSSEC last mile problem. Yao, et al. Expires February 13, 2011 [Page 3] Internet-Draft resolverkey August 2010 3. The RKIQ mechanism This mechanism will use the public key technology to make sure that the dns response message from the recursive resolvers to the stub resolvers has the Data Origin Authentication and Data Integrity. The stub resolver will store the public key of the recursive resolver domain. The recursive resolver will produce the signature of all the response DNS datas. Every recursive resolver has its own domain name. This resolver domain name will have its own DNSKEY resource record. This DNSKEY resource record will store its own public key. The RKIQ mechanism has the following diagram: The stub resolve has to get the root anchor or the resolver domain name public key before it functions. If the stub resolver gets the root anchor, the stub resolver needs to function as the recursive resolver and gets the right resolver domain public key through the DNS lookup. Every RKIQ enabled resolver will add a txt resource record at the additional section of the DNS message. The RDATA part of the txt resource record will store the signature of the outgoing DNS message. After receiving the DNS message, the stub resolver can validate the DNS message with the resolver public key. +-------------+ +------+------+ | Trust Anchor| . . . . . . . . .>| Resolver | |(root anchor)| . | Domain key | +------+------+ . +-------------+ | . ^ | ^ . | | +--------------------------.--------------------+ | V | +------+------+ . . . > . +-------------+ | | +-----------+ | | Stub | | Resolver +--|--+ -->+ DNS | | | Resolver +------------->| | | | Server | | +-------------+ +-------------+ | +-----------+ | RKIQ Service | +-----------------------------------------------+ 4. Using RKIQ as the trust measurement 4.1. DNS package siganature Every RKIQ enabled resolver will have at least 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 signature for this DNS message. The signature process will follow the definition of the algorithm of [RFC4034]. Then, it add the signature to the additional section of the dns message. The format is : Yao, et al. Expires February 13, 2011 [Page 4] Internet-Draft resolverkey August 2010 TXT The RDATA will store the following fields separated by "+": Key Tag + algorithm + Signature Expiration + Signature Inception + Signer's Name +signature. The definition of the above fields will follow the definition of the MSIG document. [[anchor6: [[note:more detailed definition will be in future version]]]] The domain name of the resolver will in the form of _resolver_domainkey. and provides a txt record, which stores the signature. 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 verification fails, it means that the DNS message has been damaged. otherwise, this DNS message is a correct response without falsification and comes from the right resolver. 4.3. Validating the DNSKEY The public key information of the resolver will be stored in the format of DNSKEY. The resolver DNSKEYs are also put in the additional section of the dns message. One of the bits of the flag fields of the DNSKEY will be used to indicate that whether this DNSKEY is used to produce the signature. 5. RKIQ Key Management When the stub resolver initiates its configuration, it must get the root anchor or the public key of the recursive resolver or both through the security communications or some out of DNS band channels. 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 through the DNS lookup. 5.2. Get the trust from the resolver key server The recursive resolver public key can be stored in some public servers. The stub resolver can get the public key directly through the security transferring. Yao, et al. Expires February 13, 2011 [Page 5] Internet-Draft resolverkey August 2010 5.3. Get the trust from the recursive resolver query There may have more DNSKEYs for the resolver domain name. The DNS message should bring other DNSKEYs when the message returns to the stub resolver. The stub resolver should save all these DNSKEYs and try to use them when the old keys are expired or rolled out. 6. 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 them 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. The resolver should cache the IP address to the domain name all the time. 7. TXT, MSIG and SIG(0) The MSIG [MSIG] or SIG(0) [RFC2931] may be used for the storage of the signature instead of TXT. SIG(0) is designed for [RFC2535]. We need update the SIG(0) similar to the defintion of MSIG. 8. IANA Considerations TBD 9. Security Considerations TBD 10. Acknowledgements Many ideas are from the discussion in the DNSOP and DNSEXT mailing 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 [[anchor18: RFC Editor: Please remove this section.]] Yao, et al. Expires February 13, 2011 [Page 6] Internet-Draft resolverkey August 2010 11.1. draft-yao-dnsop-rkiq: Version 00 o resolver key identified query 12. Normative References [MSIG] Yao, J., Lee, X., and W. Mao, "lightweight DNSSEC", draft: MSIG for Lightweight DNSSEC, July 2010. [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. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. [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. Yao, et al. Expires February 13, 2011 [Page 7] Internet-Draft resolverkey August 2010 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. Authors' Addresses Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813007 Email: yaojk@cnnic.cn Xiaodong LEE CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813020 Email: lee@cnnic.cn Wei Mao CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58812230 Email: maowei_ietf@cnnic.cn Yao, et al. Expires February 13, 2011 [Page 8]