[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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. <resolver-domain-name> 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. <resolver-domain-name> 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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/