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

Versions: 00 01

Network Working Group                                      Jiankang. Yao
Internet-Draft                                                     CNNIC
Intended status: Standards Track                        October 25, 2010
Expires: May 24, 2011


                      MSIG for Lightweight DNSSEC
                      draft-yao-dnsext-msig-01.txt

Abstract

   DNSSEC is trying to be deployed everywhere.  Many are afraid of
   DNSSEC deployment, which are too heavy to be deployed.  There is a
   huge gap between the resources we need to deploy DNSSEC and the
   benefits or security we can get from the DNSSEC.  This document
   proposes a lightweight DNSSEC mechanism to make the DNSSEC to be
   deployed easily while getting the similar security with the heavy
   DNSSEC.

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



Yao                      Expires March 14, 2011                 [Page 1]


Internet-Draft                    msig                    September 2010


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   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.  MSIG mechanism . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Using RKIQ as the trust measurement  . . . . . . . . . . . . .  4
     3.1.  MSIG RR Format . . . . . . . . . . . . . . . . . . . . . .  4
       3.1.1.  MSIG RR type . . . . . . . . . . . . . . . . . . . . .  4
       3.1.2.  MSIG Calculation . . . . . . . . . . . . . . . . . . .  4
       3.1.3.  Record Format  . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Protocol Operation . . . . . . . . . . . . . . . . . . . .  6
       3.2.1.  Effects of adding MSIG to outgoing message . . . . . .  6
       3.2.2.  MSIG processing on incoming messages . . . . . . . . .  6
       3.2.3.  MSIG Variables and Coverage  . . . . . . . . . . . . .  6
   4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  MSIG generation on requests  . . . . . . . . . . . . . . .  7
     4.2.  MSIG on Answers  . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  MSIG on MSIG Error returns . . . . . . . . . . . . . . . .  7
     4.4.  Server MSIG checks . . . . . . . . . . . . . . . . . . . .  7
     4.5.  Client processing of answer  . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Change History . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  draft-yao-dnsext-msig: Version 00  . . . . . . . . . . . .  9
   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10








Yao                      Expires March 14, 2011                 [Page 2]


Internet-Draft                    msig                    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.  [RFC4035] provides public key transaction
   signatures to support this, but it needs to sign every resource
   record.  So for every resource record queried, a public key verifying
   procedure is necessary.  DNSSEC needs not only DS and DNSKEY resource
   record but also, NSEC or NSEC3 and RRSIG to deploy DNSSEC.  The size
   of the DNSSEC signed zone can be easily be expanded to 3 or 5 times
   of the original zone without enabled DNSSEC.  DNSCurv proposal has
   gotten some controversional discussion because it totally changed the
   DNS packet and may change the DNS to the new stuff.  TSIG is
   lightweight, and provides both authentication and integrity checking,
   but TSIG requires configuration of a shared secret, so it suffers
   from a serious key distribution problem and can not be used for
   server-server communications.  This document specifies the new
   mechanism which provides the message siganature (MSIG) between severs
   and servers or between servers and resolvers.

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.  MSIG mechanism

   This mechanisem will use the public key technology to make sure that
   the dns query or response packet is authenticated and integirated.
   There are RRSIG and NSEC (NSEC3) for every resource record [RFC1034]
   and [RFC1035] in the crrent DNSSEC technology [RFC4033] [RFC4034] and
   [RFC4035].  This document specifys that only DNSKEY and DS resource
   records can have the RRSIGs.  Other resource records such as MX, A
   resource record will not need the RRSIG resource record.  This make
   the zone to expand only a little.  This document defines a new
   resource record called MSIG, which store the DNS message siganature.
   The outgoing DNS message from one zone will use the zone's DNSKEY to
   produce a keyed-hash siganature similar to producing of RRSIG.  This
   siganature will be the part of RDATA of the MSIG resource record.
   The price of the DNSSEC deployment will be decreased as much as
   possible.  The recipient of the MSIG can use the public key to verify
   the siganature to prove whether the DNS message is recived from the
   proper sender and does not be tampered.  Both the DNS query and
   response can produce and bring the DNS siganature in the MSIG
   resource record.



Yao                      Expires March 14, 2011                 [Page 3]


Internet-Draft                    msig                    September 2010


3.  Using RKIQ as the trust measurement

3.1.  MSIG RR Format

3.1.1.  MSIG RR type

   To provide secret key authentication, we use a new RR type whose
   mnemonic is MSIG and whose type code is X. MSIG is a meta-RR and MUST
   not be cached.  MSIG RRs are used for authentication between DNS
   entities.  MSIG RRs are dynamically computed to cover a particular
   DNS transaction and are not DNS RRs in the usual sense.

3.1.2.  MSIG Calculation

   As the MSIG RRs are related to one DNS request/response, there is no
   value in storing or retransmitting them, thus the MSIG RR is
   discarded once it has been used to authenticate a DNS message.  The
   only message digest algorithm specified in this document is same as
   the specification in DNSSEC [RFC4033] [RFC4034] and [RFC4035].  Other
   algorithms can be specified at a later date.  This document will
   follow the names and definitions of new algorithms registered with
   IANA for DNSSEC.  All multi-octet integers in the MSIG record are
   sent in network byte order (see [RFC1035 2.3.2]).

3.1.3.  Record Format


     <owner> <ttl> <class> MSIG <rdata>

   The owner name will be in the form of msig_.example.com while the
   example.com is the name of the apex of the zone if the msig is from
   the DNS servers, the "resolver.resolver" or the resolver's domain
   name if the msig is from the resolver.  The TTL is zero, the class
   can be any, and the RDATA has the following wire format

















Yao                      Expires March 14, 2011                 [Page 4]


Internet-Draft                    msig                    September 2010


                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Key Tag           |  Algorithm    |    reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Signature Expiration                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Signature Inception                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      /                       Signer's Name                           /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      /                            Signature                          /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



3.1.3.1.  The Key Tag Field

   The Key Tag field contains the key tag value of the DNSKEY RR that
   validates this signature, in network byte order.  Appendix B explains
   how to calculate Key Tag values of [RFC4034].

3.1.3.2.  The Algorithm Number Field

   The Algorithm Number field identifies the cryptographic algorithm
   used to create the signature.  A list of DNSSEC algorithm types can
   be found in Appendix A.1 of [RFC4034].

3.1.3.3.  The reserved Field

   This field is for future use.

3.1.3.4.  Signature Expiration and Inception Fields

   The Signature Expiration and Inception fields specify a validity
   period for the signature.  The RRSIG record MUST NOT be used for
   authentication prior to the inception date and MUST NOT be used for
   authentication after the expiration date.  The Signature Expiration
   and Inception field values specify a date and time in the form of a
   32-bit unsigned number of seconds elapsed since 1 January 1970
   00:00:00 UTC, ignoring leap seconds, in network byte order.






Yao                      Expires March 14, 2011                 [Page 5]


Internet-Draft                    msig                    September 2010


3.2.  Protocol Operation

3.2.1.  Effects of adding MSIG to outgoing message

   Once the outgoing message has been constructed, the keyed message
   digest operation can be performed.  The resulting message digest will
   then be stored in a MSIG which is appended to the additional data
   section (the ARCOUNT is incremented to reflect this).  If the MSIG
   record cannot be added without causing the message to be truncated,
   the server MUST alter the response so that a MSIG can be included.
   This response consists of only the question and a MSIG record, and
   has the TC bit set and RCODE 0 (NOERROR).  The client SHOULD at this
   point retry the request using TCP (per [RFC1035 4.2.2]).

3.2.2.  MSIG processing on incoming messages

   If an incoming message contains a MSIG record, it MUST be the last
   record in the additional section.  Multiple MSIG records are not
   allowed.  If a MSIG record is present in any other position, the
   packet is dropped and a response with RCODE 1 (FORMERR) MUST be
   returned.  Upon receipt of a message with a correctly placed MSIG RR,
   the MSIG RR is copied to a safe location, removed from the DNS
   Message, and decremented out of the DNS message header's ARCOUNT.  At
   this point the keyed message digest operation is performed.  If the
   algorithm name or key name is unknown to the recipient, or if the
   message digests do not match, the whole DNS message MUST be
   discarded.  If the message is a query, a response with RCODE 9
   (NOTAUTH) MUST be sent back to the originator with MSIG ERROR 17
   (BADKEY) or MSIG ERROR 16 (BADSIG).  If no key is available to sign
   this message it MUST be sent unsigned (MAC size == 0 and empty MAC).
   A message to the system operations log SHOULD be generated, to warn
   the operations staff of a possible security incident in progress.
   Care should be taken to ensure that logging of this type of event
   does not open the system to a denial of service attack.

3.2.3.  MSIG Variables and Coverage

   A whole and complete DNS message in wire format, before the MSIG RR
   has been added to the additional data section and before the DNS
   Message Header's ARCOUNT field has been incremented to contain the
   MSIG RR.  If the message ID differs from the original message ID, the
   original message ID is substituted for the message ID.  This could
   happen when forwarding a dynamic update request, for example.


4.  Protocol Details





Yao                      Expires March 14, 2011                 [Page 6]


Internet-Draft                    msig                    September 2010


4.1.  MSIG generation on requests

   Client performs the message digest operation and appends a MSIG
   record to the additional data section and transmits the request to
   the server.  The client MUST store the message digest from the
   request while awaiting an answer.  The digest components for a
   request are: DNS Message (request) MSIG Variables (request) Note that
   some older name servers will not accept requests with a nonempty
   additional data section.  Clients SHOULD only attempt signed
   transactions with servers who are known to support MSIG and share
   some secret key with the client -- so, this is not a problem in
   practice.

4.2.  MSIG on Answers

   When a server has generated a response to a signed request, it signs
   the response using the same algorithm and key.  The server MUST not
   generate a signed response to an unsigned request.  The digest
   components are:

         Request MAC
         DNS Message (response)
         MSIG Variables (response)

4.3.  MSIG on MSIG Error returns

   When a server detects an error relating to the key or MAC, the server
   SHOULD send back an unsigned error message (MAC size == 0 and empty
   MAC).  If an error is detected relating to the MSIG validity period,
   the server SHOULD send back a signed error message.  The digest
   components are:

         Request MAC (if the request MAC validated)
         DNS Message (response)
         MSIG Variables (response)

   The reason that the request is not included in this digest in some
   cases is to make it possible for the client to verify the error.  If
   the error is not a MSIG error the response MUST be generated as
   specified in [4.2].

4.4.  Server MSIG checks

   Upon receipt of a message, server will check if there is a MSIG RR.
   If one exists, the server is REQUIRED to return a MSIG RR in the
   response.  The server MUST perform the following checks in the
   following order, check KEY, check TIME values, check MAC.  If a non-
   forwarding server does not recognize the key used by the client, the



Yao                      Expires March 14, 2011                 [Page 7]


Internet-Draft                    msig                    September 2010


   server MUST generate an error response with RCODE 9 (NOTAUTH) and
   MSIG ERROR 17 (BADKEY).  This response MUST be unsigned as specified
   in [4.3].  The server SHOULD log the error.

4.5.  Client processing of answer

   When a client receives a response from a server and expects to see a
   MSIG, it first checks if the MSIG RR is present in the response.
   Otherwise, the response is treated as having a format error and
   discarded.  The client then extracts the MSIG, adjusts the ARCOUNT,
   and calculates the keyed digest in the same way as the server.  If
   the MSIG does not validate, that response MUST be discarded, unless
   the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to
   verify the response as if it were a MSIG Error response, as specified
   in [4.3].  A message containing an unsigned MSIG record or a MSIG
   record which fails verification SHOULD not be considered an
   acceptable response; the client SHOULD log an error and continue to
   wait for a signed response until the request times out.

   If an RCODE on a response is 9 (NOTAUTH), and the response MSIG
   validates, and the MSIG key is different from the key used on the
   request, then this is a KEY error.  The client MAY retry the request
   using the key specified by the server.  This should never occur, as a
   server MUST NOT sign a response with a different key than signed the
   request.


5.  IANA Considerations

   TBD


6.  Security Considerations

   TBD


7.  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.


8.  Change History

   [[anchor25: RFC Editor: Please remove this section.]]



Yao                      Expires March 14, 2011                 [Page 8]


Internet-Draft                    msig                    September 2010


8.1.  draft-yao-dnsext-msig: Version 00

   o  MSIG for lightweight DNSSEC


9.  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



Yao                      Expires March 14, 2011                 [Page 9]


Internet-Draft                    msig                    September 2010


              Existence", RFC 5155, March 2008.


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 10]


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