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