diff options
Diffstat (limited to 'doc/rfc/rfc2931.txt')
| -rw-r--r-- | doc/rfc/rfc2931.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2931.txt b/doc/rfc/rfc2931.txt new file mode 100644 index 0000000..84cc97e --- /dev/null +++ b/doc/rfc/rfc2931.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 2931 Motorola +Updates: 2535 September 2000 +Category: Standards Track + + + DNS Request and Transaction Signatures ( SIG(0)s ) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + Extensions to the Domain Name System (DNS) are described in [RFC + 2535] that can provide data origin and transaction integrity and + authentication to security aware resolvers and applications through + the use of cryptographic digital signatures. + + Implementation experience has indicated the need for minor but non- + interoperable changes in Request and Transaction signature resource + records ( SIG(0)s ). These changes are documented herein. + +Acknowledgments + + The contributions and suggestions of the following persons (in + alphabetic order) to this memo are gratefully acknowledged: + + Olafur Gudmundsson + + Ed Lewis + + Erik Nordmark + + Brian Wellington + + + + + + + + +Eastlake Standards Track [Page 1] + +RFC 2931 DNS SIG(0) September 2000 + + +Table of Contents + + 1. Introduction................................................. 2 + 2. SIG(0) Design Rationale...................................... 3 + 2.1 Transaction Authentication.................................. 3 + 2.2 Request Authentication...................................... 3 + 2.3 Keying...................................................... 3 + 2.4 Differences Between TSIG and SIG(0)......................... 4 + 3. The SIG(0) Resource Record................................... 4 + 3.1 Calculating Request and Transaction SIGs.................... 5 + 3.2 Processing Responses and SIG(0) RRs......................... 6 + 3.3 SIG(0) Lifetime and Expiration.............................. 7 + 4. Security Considerations...................................... 7 + 5. IANA Considerations.......................................... 7 + References...................................................... 7 + Author's Address................................................ 8 + Appendix: SIG(0) Changes from RFC 2535.......................... 9 + Full Copyright Statement........................................ 10 + +1. Introduction + + This document makes minor but non-interoperable changes to part of + [RFC 2535], familiarity with which is assumed, and includes + additional explanatory text. These changes concern SIG Resource + Records (RRs) that are used to digitally sign DNS requests and + transactions / responses. Such a resource record, because it has a + type covered field of zero, is frequently called a SIG(0). The + changes are based on implementation and attempted implementation + experience with TSIG [RFC 2845] and the [RFC 2535] specification for + SIG(0). + + Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2 + and 4.3. No changes are made herein related to the KEY or NXT RRs or + to the processing involved with data origin and denial authentication + for DNS data. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + + + + + + + + + + + + +Eastlake Standards Track [Page 2] + +RFC 2931 DNS SIG(0) September 2000 + + +2. SIG(0) Design Rationale + + SIG(0) provides protection for DNS transactions and requests that is + not provided by the regular SIG, KEY, and NXT RRs specified in [RFC + 2535]. The authenticated data origin services of secure DNS either + provide protected data resource records (RRs) or authenticatably deny + their nonexistence. These services provide no protection for glue + records, DNS requests, no protection for message headers on requests + or responses, and no protection of the overall integrity of a + response. + +2.1 Transaction Authentication + + Transaction authentication means that a requester can be sure it is + at least getting the messages from the server it queried and that the + received messages are in response to the query it sent. This is + accomplished by optionally adding either a TSIG RR [RFC 2845] or, as + described herein, a SIG(0) resource record at the end of the response + which digitally signs the concatenation of the server's response and + the corresponding resolver query. + +2.2 Request Authentication + + Requests can also be authenticated by including a TSIG or, as + described herein, a special SIG(0) RR at the end of the request. + Authenticating requests serves no function in DNS servers that + predate the specification of dynamic update. Requests with a non- + empty additional information section produce error returns or may + even be ignored by a few such older DNS servers. However, this syntax + for signing requests is defined for authenticating dynamic update + requests [RFC 2136], TKEY requests [RFC 2930], or future requests + requiring authentication. + +2.3 Keying + + The private keys used in transaction security belong to the host + composing the DNS response message, not to the zone involved. + Request authentication may also involve the private key of the host + or other entity composing the request or of a zone to be affected by + the request or other private keys depending on the request authority + it is sought to establish. The corresponding public key(s) are + normally stored in and retrieved from the DNS for verification as KEY + RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY). + + Because requests and replies are highly variable, message + authentication SIGs can not be pre-calculated. Thus it will be + necessary to keep the private key on-line, for example in software or + in a directly connected piece of hardware. + + + +Eastlake Standards Track [Page 3] + +RFC 2931 DNS SIG(0) September 2000 + + +2.4 Differences Between TSIG and SIG(0) + + There are significant differences between TSIG and SIG(0). + + Because TSIG involves secret keys installed at both the requester and + server the presence of such a key implies that the other party + understands TSIG and very likely has the same key installed. + Furthermore, TSIG uses keyed hash authentication codes which are + relatively inexpensive to compute. Thus it is common to authenticate + requests with TSIG and responses are authenticated with TSIG if the + corresponding request is authenticated. + + SIG(0) on the other hand, uses public key authentication, where the + public keys are stored in DNS as KEY RRs and a private key is stored + at the signer. Existence of such a KEY RR does not necessarily imply + implementation of SIG(0). In addition, SIG(0) involves relatively + expensive public key cryptographic operations that should be + minimized and the verification of a SIG(0) involves obtaining and + verifying the corresponding KEY which can be an expensive and lengthy + operation. Indeed, a policy of using SIG(0) on all requests and + verifying it before responding would, for some configurations, lead + to a deadly embrace with the attempt to obtain and verify the KEY + needed to authenticate the request SIG(0) resulting in additional + requests accompanied by a SIG(0) leading to further requests + accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not + required on requests halves the number of public key operations + required by the transaction. + + For these reasons, SIG(0)s SHOULD only be used on requests when + necessary to authenticate that the requester has some required + privilege or identity. SIG(0)s on replies are defined in such a way + as to not require a SIG(0) on the corresponding request and still + provide transaction protection. For other replies, whether they are + authenticated by the server or required to be authenticated by the + requester SHOULD be a local configuration option. + +3. The SIG(0) Resource Record + + The structure of and type number of SIG resource records (RRs) is + given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and + the parts of Sections 4.2 and 4.3 related to SIG(0) should be + considered replaced by the material below. Any conflict between [RFC + 2535] and this document concerning SIG(0) RRs should be resolved in + favor of this document. + + For all transaction SIG(0)s, the signer field MUST be a name of the + originating host and there MUST be a KEY RR at that name with the + public key corresponding to the private key used to calculate the + + + +Eastlake Standards Track [Page 4] + +RFC 2931 DNS SIG(0) September 2000 + + + signature. (The host domain name used may be the inverse IP address + mapping name for an IP address of the host if the relevant KEY is + stored there.) + + For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are + meaningless. The TTL fields SHOULD be zero and the CLASS field + SHOULD be ANY. To conserve space, the owner name SHOULD be root (a + single zero octet). When SIG(0) authentication on a response is + desired, that SIG RR MUST be considered the highest priority of any + additional information for inclusion in the response. If the SIG(0) + RR cannot be added without causing the message to be truncated, the + server MUST alter the response so that a SIG(0) can be included. + This response consists of only the question and a SIG(0) record, and + has the TC bit set and RCODE 0 (NOERROR). The client should at this + point retry the request using TCP. + +3.1 Calculating Request and Transaction SIGs + + A DNS request may be optionally signed by including one SIG(0)s at + the end of the query additional information section. Such a SIG is + identified by having a "type covered" field of zero. It signs the + preceding DNS request message including DNS header but not including + the UDP/IP header and before the request RR counts have been adjusted + for the inclusions of the request SIG(0). + + It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of + (1) the SIG's RDATA section entirely omitting (not just zeroing) the + signature subfield itself, (2) the DNS query messages, including DNS + header, but not the UDP/IP header and before the reply RR counts have + been adjusted for the inclusion of the SIG(0). That is + + data = RDATA | request - SIG(0) + + where "|" is concatenation and RDATA is the RDATA of the SIG(0) being + calculated less the signature itself. + + Similarly, a SIG(0) can be used to secure a response and the request + that produced it. Such transaction signatures are calculated by + using a "data" of (1) the SIG's RDATA section omitting the signature + itself, (2) the entire DNS query message that produced this response, + including the query's DNS header but not its UDP/IP header, and (3) + the entire DNS response message, including DNS header but not the + UDP/IP header and before the response RR counts have been adjusted + for the inclusion of the SIG(0). + + + + + + + +Eastlake Standards Track [Page 5] + +RFC 2931 DNS SIG(0) September 2000 + + + That is + + data = RDATA | full query | response - SIG(0) + + where "|" is concatenation and RDATA is the RDATA of the SIG(0) being + calculated less the signature itself. + + Verification of a response SIG(0) (which is signed by the server host + key, not the zone key) by the requesting resolver shows that the + query and response were not tampered with in transit, that the + response corresponds to the intended query, and that the response + comes from the queried server. + + In the case of a DNS message via TCP, a SIG(0) on the first data + packet is calculated with "data" as above and for each subsequent + packet, it is calculated as follows: + + data = RDATA | DNS payload - SIG(0) | previous packet + + where "|" is concatenations, RDATA is as above, and previous packet + is the previous DNS payload including DNS header and the SIG(0) but + not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an + alternative, TSIG may be used after, if necessary, setting up a key + with TKEY [RFC 2930]. + + Except where needed to authenticate an update, TKEY, or similar + privileged request, servers are not required to check a request + SIG(0). + + Note: requests and responses can either have a single TSIG or one + SIG(0) but not both a TSIG and a SIG(0). + +3.2 Processing Responses and SIG(0) RRs + + If a SIG RR is at the end of the additional information section of a + response and has a type covered of zero, it is a transaction + signature covering the response and the query that produced the + response. For TKEY responses, it MUST be checked and the message + rejected if the checks fail unless otherwise specified for the TKEY + mode in use. For all other responses, it MAY be checked and the + message rejected if the checks fail. + + If a response's SIG(0) check succeed, such a transaction + authentication SIG does NOT directly authenticate the validity any + data-RRs in the message. However, it authenticates that they were + sent by the queried server and have not been diddled. (Only a proper + SIG(0) RR signed by the zone or a key tracing its authority to the + zone or to static resolver configuration can directly authenticate + + + +Eastlake Standards Track [Page 6] + +RFC 2931 DNS SIG(0) September 2000 + + + data-RRs, depending on resolver policy.) If a resolver or server does + not implement transaction and/or request SIGs, it MUST ignore them + without error where they are optional and treat them as failing where + they are required. + +3.3 SIG(0) Lifetime and Expiration + + The inception and expiration times in SIG(0)s are for the purpose of + resisting replay attacks. They should be set to form a time bracket + such that messages outside that bracket can be ignored. In IP + networks, this time bracket should not normally extend further than 5 + minutes into the past and 5 minutes into the future. + +4. Security Considerations + + No additional considerations beyond those in [RFC 2535]. + + The inclusion of the SIG(0) inception and expiration time under the + signature improves resistance to replay attacks. + +5. IANA Considerations + + No new parameters are created or parameter values assigned by this + document. + +References + + [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + September 1996. + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Signatures for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC + 2930, September 2000. + + + + + +Eastlake Standards Track [Page 7] + +RFC 2931 DNS SIG(0) September 2000 + + +Author's Address + + Donald E. Eastlake 3rd + Motorola + 140 Forest Avenue + Hudson, MA 01749 USA + + Phone: +1-978-562-2827(h) + +1-508-261-5434(w) + Fax: +1 978-567-7941(h) + +1-508-261-4447(w) + EMail: Donald.Eastlake@motorola.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 8] + +RFC 2931 DNS SIG(0) September 2000 + + +Appendix: SIG(0) Changes from RFC 2535 + + Add explanatory text concerning the differences between TSIG and + SIG(0). + + Change the data over which SIG(0) is calculated to include the SIG(0) + RDATA other than the signature itself so as to secure the signature + inception and expiration times and resist replay attacks. Specify + SIG(0) for TCP. + + Add discussion of appropriate inception and expiration times for + SIG(0). + + Add wording to indicate that either a TSIG or one or more SIG(0)s may + be present but not both. + + Reword some areas for clarity. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 9] + +RFC 2931 DNS SIG(0) September 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 10] + |