idnits 2.17.1 draft-yao-dnsop-resolverkey-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 10, 2010) is 4975 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2845' is mentioned on line 104, but not defined ** Obsolete undefined reference: RFC 2845 (Obsoleted by RFC 8945) == Unused Reference: 'RFC2119' is defined on line 275, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC2671' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'RFC2672' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC3597' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'RFC3743' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC5155' is defined on line 308, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Downref: Normative reference to an Informational RFC: RFC 3743 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jiankang. Yao 3 Internet-Draft CNNIC 4 Intended status: Standards Track September 10, 2010 5 Expires: March 14, 2011 7 Resolver Key Identified DNS Query 8 draft-yao-dnsop-resolverkey-01.txt 10 Abstract 12 DNSSEC hardens the DNS between the root server and the recursive 13 resolver. It does not secure the communications between the stub 14 resolver and the recursive resolver. This document specifies the 15 mechanism which deals with securing the communications between them. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 14, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. The RKIQ mechanism . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Using RKIQ as the trust measurement . . . . . . . . . . . . . . 4 68 4.1. DNS package siganature . . . . . . . . . . . . . . . . . . 4 69 4.2. Validating the siganature . . . . . . . . . . . . . . . . . 4 70 4.3. Validating the public key . . . . . . . . . . . . . . . . . 4 71 5. RKIQ Key Management . . . . . . . . . . . . . . . . . . . . . . 5 72 5.1. Get the trust from the root anchor . . . . . . . . . . . . 5 73 5.2. Get the trust from the resolver key server . . . . . . . . 5 74 5.3. Get the trust from the recursive resolver query . . . . . . 5 75 6. RKIQ Key Format and storage . . . . . . . . . . . . . . . . . . 5 76 6.1. Resolver Public key format and storage . . . . . . . . . . 5 77 6.2. DNS message siganature . . . . . . . . . . . . . . . . . . 6 78 7. Acquire of the resolver domain name . . . . . . . . . . . . . . 6 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 82 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6 83 11.1. draft-yao-dnsop-rkiq: Version 00 . . . . . . . . . . . . . 6 84 12. Normative References . . . . . . . . . . . . . . . . . . . . . 7 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 1. Introduction 89 DNSSEC (Domain Name System Security Extensions) [RFC4033] [RFC4034] 90 [RFC4035] has secured the communication between the root server and 91 the recursive resolver. The stub resolver is the piece of the Domain 92 Name System that resides on nearly every computer and translates an 93 application's request for data into a DNS query, and then sends that 94 query to one or more resolvers or name servers that function as the 95 resolver. It is impractical for these stub resolvers to perform 96 general [RFC4035] authentication and they would naturally depend on 97 their validating resolvers to perform such services for them. To do 98 so securely requires secure communication of queries and responses. 99 [RFC4035] provides public key transaction signatures to support this, 100 but such signatures are very expensive computationally to generate. 101 So the DNSSEC validating function is normally deployed in recursive 102 resolvers insteand of stub resolvers. How to get a security 103 communication between the stub resolver and the validaing resolver 104 (resursive resolver) is a big challange ahead of us. TSIG[RFC2845] 105 proposes to solve this problem with the symmentic key. Although, 106 TSIG is lightweight, and provides both authentication and integrity 107 checking, TSIG requires configuration of a shared secret, so it 108 suffers from a nasty key distribution problem. If your recursive 109 resolvers handles hundreds or thousands of stub resolvers, you'd need 110 to configure a shared secret with each of them. This document 111 specifies the new mechanism which deals with securing the 112 communications between the stub resolver and the recursive resolver. 114 1.1. Terminology 116 All the basic terms used in this specification are defined in the 117 documents [RFC1034], and [RFC1035]. In this document, there are two 118 kinds of resolvers: the stub resolver and the recursive resolver. In 119 this document, the resolver specially means the recursive resolver. 121 2. Motivation 123 The RKIQ mechanism makes the DNSSEC much safer. It extends the 124 DNSSEC safety from the root to the stub resolver. This solution 125 tackles the DNSSEC last mile problem. 127 3. The RKIQ mechanism 129 This mechanisem will use the public key technology to make sure that 130 the dns response package from the recursive resolvers to the stub 131 resolvers is correct and unchangeable. The stub resolver will store 132 the public key of the reursive resolver domain. The reursive 133 resolver will give the siganature of all the response DNS data. 134 Every recursive resolver has its own domain name. This domain name 135 will have its own txt resource record. This txt resource record will 136 store its own public key. 138 +-------------+ +------+------+ 139 | Trust Anchor| . . . . . . . . .>| Resolver | 140 |(root anchor)| . | Domain key | 141 +------+------+ . +-------------+ 142 | . ^ | 143 ^ . | | 144 +--------------------------.--------------------+ | V 145 | +------+------+ . . . > . +-------------+ | | +-----------+ 146 | | Stub | | Resolver +--|--+ -->+ DNS | 147 | | Resolver +------------->| Validator | | | Server | 148 | +-------------+ +-------------+ | +-----------+ 149 | RKIQ Service | 150 +-----------------------------------------------+ 152 4. Using RKIQ as the trust measurement 154 4.1. DNS package siganature 156 Every RKIQ enabled resolver will have at leat a pair of key, public 157 key and private key. When the DNS message is sent from the resolver, 158 the resolver will use the private key to generate a siganature for 159 this DNS message. The siganature process will follow the definiton 160 of [RFC4034] Then, it add the siganature to the additional section of 161 the dns message. The format is that "owner name class rdata". The 162 form of the rdata is algorithm + the siganature. 164 4.2. Validating the siganature 166 The stub resolver receives the DNS message from the recursive 167 resolver, removes the resolver domain name's txt resource record, and 168 make the verification. If varification fails, it means that the dns 169 has been demaged. otherwise, this dns message is a correct response 170 without falsification. 172 4.3. Validating the public key 174 The public key is also in the additional section of the dns message. 175 The stub resolver must compare this public key with the public key 176 stored in the local stub resolver. If these two keys are not same, 177 either the dns message is damaged or the public key has been be 178 updated by the recursive resolver. If the public key has been 179 updated, the stub resolve should use key management technology to 180 update its key immediately before trying to verify the siganature. 182 5. RKIQ Key Management 184 When the stub resolver initiats its configuration, it must get the 185 root anchor or the public key of the recursive resolver or both 186 through the security communications. 188 5.1. Get the trust from the root anchor 190 If the trust anchor is the root anchor, the stub resolver should act 191 as the recursive resolver and query the stub resolver's domain name 192 for its public key. 194 5.2. Get the trust from the resolver key server 196 The recursiver resolver public key can be stored in some public 197 servers. The stub resolver can get the public key directly through 198 the security transfering. 200 5.3. Get the trust from the recursive resolver query 202 The recursive resolver may have two pairs of keys. They have 203 different time expiration. When one is roll out, the other can 204 transfer the new public key to the stub resolvers. 206 6. RKIQ Key Format and storage 208 This document proposes a public key storage of the recursive resolver 209 in DNS with the txt type resource record, and a syntesithed txt type 210 resource record in the additonal section of the DNS message with the 211 storage of the DNS message siganature. 213 6.1. Resolver Public key format and storage 215 A stub resolver attempting to verify a RKIQ signature should obtain 216 the public key that is associated with the signature for that 217 message. The DNS record storing the public key with the domain owner 218 name of ._resolver_domainkey. has a DNSKEY 219 type which provides the public key information of the resolver. The 220 DNSKEY definition will follow the definition of section section 2 of 221 [RFC4034]. The administrator of the recursive resolver containing 222 the relevant resolver domain name adds this information. Initial 223 RKIQ DNS information is contained within DNSKEY RRs. 225 6.2. DNS message siganature 227 The recursiver resolver which receives a request from the stub host 228 about the security answer, should response a message including a The 229 DNS record storing the siganatue with the domain owner name of 230 ._resolver_domainkey. has a TXT type which 231 provides the siganature information of the DNS message. The TXT 232 definition will follow the definition of [RFC1034]. The 233 administrator of the recursive resolver containing the relevant 234 resolver domain name adds this information. 236 7. Acquire of the resolver domain name 238 There are two ways to get the resolver domain name. The user can 239 configure the resolver's domain name and IP address if they know they 240 beforehand. If the user know the resolver's IP address only, the 241 stub resolver can send a query of the resolver's IP address for the 242 domain name. 244 8. IANA Considerations 246 There is no IANA consideration. 248 9. Security Considerations 250 The stub host should also get the trust anchor through the security 251 communication. 253 10. Acknowledgements 255 Many ideas are from the discussion in the DNSOP and DNSEXT mailling 256 list. Thanks a lot to all in the list. Many important comments and 257 suggestions are contributed by many members of the DNSEXT and DNSOP 258 WGs. 260 11. Change History 262 [[anchor19: RFC Editor: Please remove this section.]] 264 11.1. draft-yao-dnsop-rkiq: Version 00 265 o resolver key identified query 267 12. Normative References 269 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 270 STD 13, RFC 1034, November 1987. 272 [RFC1035] Mockapetris, P., "Domain names - implementation and 273 specification", STD 13, RFC 1035, November 1987. 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, March 1997. 278 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 279 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 280 RFC 2136, April 1997. 282 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 283 RFC 2671, August 1999. 285 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 286 RFC 2672, August 1999. 288 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 289 (RR) Types", RFC 3597, September 2003. 291 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 292 Engineering Team (JET) Guidelines for Internationalized 293 Domain Names (IDN) Registration and Administration for 294 Chinese, Japanese, and Korean", RFC 3743, April 2004. 296 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 297 Rose, "DNS Security Introduction and Requirements", 298 RFC 4033, March 2005. 300 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 301 Rose, "Resource Records for the DNS Security Extensions", 302 RFC 4034, March 2005. 304 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 305 Rose, "Protocol Modifications for the DNS Security 306 Extensions", RFC 4035, March 2005. 308 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 309 Security (DNSSEC) Hashed Authenticated Denial of 310 Existence", RFC 5155, March 2008. 312 Author's Address 314 Jiankang YAO 315 CNNIC 316 No.4 South 4th Street, Zhongguancun 317 Beijing 319 Phone: +86 10 58813007 320 Email: yaojk@cnnic.cn