diff --git a/doc/rfc/rfc2929.txt b/doc/rfc/rfc2929.txt new file mode 100644 index 0000000000..f055968935 --- /dev/null +++ b/doc/rfc/rfc2929.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group D. Eastlake, 3rd +Request for Comments: 2929 Motorola +BCP: 42 E. Brunner-Williams +Category: Best Current Practice Engage + B. Manning + ISI + September 2000 + + Domain Name System (DNS) IANA Considerations + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + Internet Assigned Number Authority (IANA) parameter assignment + considerations are given for the allocation of Domain Name System + (DNS) classes, Resource Record (RR) types, operation codes, error + codes, etc. + +Table of Contents + + 1. Introduction................................................. 2 + 2. DNS Query/Response Headers................................... 2 + 2.1 One Spare Bit?.............................................. 3 + 2.2 Opcode Assignment........................................... 3 + 2.3 RCODE Assignment............................................ 4 + 3. DNS Resource Records......................................... 5 + 3.1 RR TYPE IANA Considerations................................. 6 + 3.1.1 Special Note on the OPT RR................................ 7 + 3.2 RR CLASS IANA Considerations................................ 7 + 3.3 RR NAME Considerations...................................... 8 + 4. Security Considerations...................................... 9 + References...................................................... 9 + Authors' Addresses.............................................. 11 + Full Copyright Statement........................................ 12 + + + + + + + + +Eastlake, et al. Best Current Practice [Page 1] + +RFC 2929 DNS IANA Considerations September 2000 + + +1. Introduction + + The Domain Name System (DNS) provides replicated distributed secure + hierarchical databases which hierarchically store "resource records" + (RRs) under domain names. + + This data is structured into CLASSes and zones which can be + independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535] + familiarity with which is assumed. + + This document covers, either directly or by reference, general IANA + parameter assignment considerations applying across DNS query and + response headers and all RRs. There may be additional IANA + considerations that apply to only a particular RR type or + query/response opcode. See the specific RFC defining that RR type or + query/response opcode for such considerations if they have been + defined. + + IANA currently maintains a web page of DNS parameters. See + . + + "IETF Standards Action", "IETF Consensus", "Specification Required", + and "Private Use" are as defined in [RFC 2434]. + +2. DNS Query/Response Headers + + The header for DNS queries and responses contains field/bits in the + following diagram taken from [RFC 2136, 2535]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT/ZOCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT/PRCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT/UPCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The ID field identifies the query and is echoed in the response so + they can be matched. + + + + +Eastlake, et al. Best Current Practice [Page 2] + +RFC 2929 DNS IANA Considerations September 2000 + + + The QR bit indicates whether the header is for a query or a response. + + The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful + only in queries or only in responses, depending on the bit. However, + many DNS implementations copy the query header as the initial value + of the response header without clearing bits. Thus any attempt to + use a "query" bit with a different meaning in a response or to define + a query meaning for a "response" bit is dangerous given existing + implementation. Such meanings may only be assigned by an IETF + Standards Action. + + The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), + authority count (NSCOUNT), and additional information count (ARCOUNT) + express the number of records in each section for all opcodes except + Update. These fields have the same structure and data type for + Update but are instead the counts for the zone (ZOCOUNT), + prerequisite (PRCOUNT), update (UPCOUNT), and additional information + (ARCOUNT) sections. + +2.1 One Spare Bit? + + There have been ancient DNS implementations for which the Z bit being + on in a query meant that only a response from the primary server for + a zone is acceptable. It is believed that current DNS + implementations ignore this bit. + + Assigning a meaning to the Z bit requires an IETF Standards Action. + +2.2 Opcode Assignment + + New OpCode assignments require an IETF Standards Action. + + Currently DNS OpCodes are assigned as follows: + + OpCode Name Reference + + 0 Query [RFC 1035] + 1 IQuery (Inverse Query) [RFC 1035] + 2 Status [RFC 1035] + 3 available for assignment + 4 Notify [RFC 1996] + 5 Update [RFC 2136] + 6-15 available for assignment + + + + + + + + +Eastlake, et al. Best Current Practice [Page 3] + +RFC 2929 DNS IANA Considerations September 2000 + + +2.3 RCODE Assignment + + It would appear from the DNS header above that only four bits of + RCODE, or response/error code are available. However, RCODEs can + appear not only at the top level of a DNS response but also inside + OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. + The OPT RR provides an eight bit extension resulting in a 12 bit + RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field. + + Error codes appearing in the DNS header and in these three RR types + all refer to the same error code space with the single exception of + error code 16 which has a different meaning in the OPT RR from its + meaning in other contexts. See table below. + + RCODE Name Description Reference + Decimal + Hexadecimal + 0 NoError No Error [RFC 1035] + 1 FormErr Format Error [RFC 1035] + 2 ServFail Server Failure [RFC 1035] + 3 NXDomain Non-Existent Domain [RFC 1035] + 4 NotImp Not Implemented [RFC 1035] + 5 Refused Query Refused [RFC 1035] + 6 YXDomain Name Exists when it should not [RFC 2136] + 7 YXRRSet RR Set Exists when it should not [RFC 2136] + 8 NXRRSet RR Set that should exist does not [RFC 2136] + 9 NotAuth Server Not Authoritative for zone [RFC 2136] + 10 NotZone Name not contained in zone [RFC 2136] + 11-15 available for assignment + 16 BADVERS Bad OPT Version [RFC 2671] + 16 BADSIG TSIG Signature Failure [RFC 2845] + 17 BADKEY Key not recognized [RFC 2845] + 18 BADTIME Signature out of time window [RFC 2845] + 19 BADMODE Bad TKEY Mode [RFC 2930] + 20 BADNAME Duplicate key name [RFC 2930] + 21 BADALG Algorithm not supported [RFC 2930] + 22-3840 available for assignment + 0x0016-0x0F00 + 3841-4095 Private Use + 0x0F01-0x0FFF + 4096-65535 available for assignment + 0x1000-0xFFFF + + Since it is important that RCODEs be understood for interoperability, + assignment of new RCODE listed above as "available for assignment" + requires an IETF Consensus. + + + + + +Eastlake, et al. Best Current Practice [Page 4] + +RFC 2929 DNS IANA Considerations September 2000 + + +3. DNS Resource Records + + All RRs have the same top level format shown in the figure below + taken from [RFC 1035]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + NAME is an owner name, i.e., the name of the node to which this + resource record pertains. NAMEs are specific to a CLASS as described + in section 3.2. NAMEs consist of an ordered sequence of one or more + labels each of which has a label type [RFC 1035, 2671]. + + TYPE is a two octet unsigned integer containing one of the RR TYPE + codes. See section 3.1. + + CLASS is a two octet unsigned integer containing one of the RR CLASS + codes. See section 3.2. + + TTL is a four octet (32 bit) bit unsigned integer that specifies the + number of seconds that the resource record may be cached before the + source of the information should again be consulted. Zero is + interpreted to mean that the RR can only be used for the transaction + in progress. + + RDLENGTH is an unsigned 16 bit integer that specifies the length in + octets of the RDATA field. + + + + + + +Eastlake, et al. Best Current Practice [Page 5] + +RFC 2929 DNS IANA Considerations September 2000 + + + RDATA is a variable length string of octets that constitutes the + resource. The format of this information varies according to the + TYPE and in some cases the CLASS of the resource record. + +3.1 RR TYPE IANA Considerations + + There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, + and MetaTYPEs. + + Data TYPEs are the primary means of storing data. QTYPES can only be + used in queries. Meta-TYPEs designate transient data associated with + an particular DNS message and in some cases can also be used in + queries. Thus far, data TYPEs have been assigned from 1 upwards plus + the block from 100 through 103 while Q and Meta Types have been + assigned from 255 downwards (except for the OPT Meta-RR which is + assigned TYPE 41). There have been DNS implementations which made + caching decisions based on the top bit of the bottom byte of the RR + TYPE. + + There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG + [RFC 2845], and TKEY [RFC 2930]. + + There are currently five QTYPEs assigned: * (all), MAILA, MAILB, + AXFR, and IXFR. + + Considerations for the allocation of new RR TYPEs are as follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC + 2535] and in other circumstances and must never be allocated + for ordinary use. + + 1 - 127 + 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data + TYPEs by IETF Consensus. + + 128 - 255 + 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and + Meta TYPEs by IETF Consensus. + + 256 - 32767 + 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF + Consensus. + + + + + +Eastlake, et al. Best Current Practice [Page 6] + +RFC 2929 DNS IANA Considerations September 2000 + + + 32768 - 65279 + 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. + + 65280 - 65535 + 0xFF00 - 0xFFFF - Private Use. + +3.1.1 Special Note on the OPT RR + + The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its + primary purpose is to extend the effective field size of various DNS + fields including RCODE, label type, flag bits, and RDATA size. In + particular, for resolvers and servers that recognize it, it extends + the RCODE field from 4 to 12 bits. + +3.2 RR CLASS IANA Considerations + + DNS CLASSes have been little used but constitute another dimension of + the DNS distributed database. In particular, there is no necessary + relationship between the name space or root servers for one CLASS and + those for another CLASS. The same name can have completely different + meanings in different CLASSes although the label types are the same + and the null label is usable only as root in every CLASS. However, + as global networking and DNS have evolved, the IN, or Internet, CLASS + has dominated DNS use. + + There are two subcategories of DNS CLASSes: normal data containing + classes and QCLASSes that are only meaningful in queries or updates. + + The current CLASS assignments and considerations for future + assignments are as follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - assignment requires an IETF Standards Action. + + 1 + 0x0001 - Internet (IN). + + 2 + 0x0002 - available for assignment by IETF Consensus as a data CLASS. + + 3 + 0x0003 - Chaos (CH) [Moon 1981]. + + 4 + 0x0004 - Hesiod (HS) [Dyer 1987]. + + + +Eastlake, et al. Best Current Practice [Page 7] + +RFC 2929 DNS IANA Considerations September 2000 + + + 5 - 127 + 0x0005 - 0x007F - available for assignment by IETF Consensus as data + CLASSes only. + + 128 - 253 + 0x0080 - 0x00FD - available for assignment by IETF Consensus as + QCLASSes only. + + 254 + 0x00FE - QCLASS None [RFC 2136]. + + 255 + 0x00FF - QCLASS Any [RFC 1035]. + + 256 - 32767 + 0x0100 - 0x7FFF - assigned by IETF Consensus. + + 32768 - 65280 + 0x8000 - 0xFEFF - assigned based on Specification Required as defined + in [RFC 2434]. + + 65280 - 65534 + 0xFF00 - 0xFFFE - Private Use. + + 65535 + 0xFFFF - can only be assigned by an IETF Standards Action. + +3.3 RR NAME Considerations + + DNS NAMEs are sequences of labels [RFC 1035]. The last label in each + NAME is "ROOT" which is the zero length label. By definition, the + null or ROOT label can not be used for any other NAME purpose. + + At the present time, there are two categories of label types, data + labels and compression labels. Compression labels are pointers to + data labels elsewhere within an RR or DNS message and are intended to + shorten the wire encoding of NAMEs. The two existing data label + types are sometimes referred to as Text and Binary. Text labels can, + in fact, include any octet value including zero octets but most + current uses involve only [US-ASCII]. For retrieval, Text labels are + defined to treat ASCII upper and lower case letter codes as matching. + Binary labels are bit sequences [RFC 2673]. + + IANA considerations for label types are given in [RFC 2671]. + + + + + + + +Eastlake, et al. Best Current Practice [Page 8] + +RFC 2929 DNS IANA Considerations September 2000 + + + NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon + 1981] CLASSes are essentially for local use. The IN or Internet + CLASS is thus the only DNS CLASS in global use on the Internet at + this time. + + A somewhat dated description of name allocation in the IN Class is + given in [RFC 1591]. Some information on reserved top level domain + names is in Best Current Practice 32 [RFC 2606]. + +4. Security Considerations + + This document addresses IANA considerations in the allocation of + general DNS parameters, not security. See [RFC 2535] for secure DNS + considerations. + +References + + [Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical + Plan - Name Service, April 1987, + + [Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts + Institute of Technology Artificial Intelligence + Laboratory, June 1981. + + [RFC 1034] Mockapetris, P., "Domain Names - Concepts and + Facilities", STD 13, RFC 1034, November 1987. + + [RFC 1035] Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC 1591] Postel, J., "Domain Name System Structure and + Delegation", RFC 1591, March 1994. + + [RFC 1996] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, August 1996. + + [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 2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + + + + +Eastlake, et al. Best Current Practice [Page 9] + +RFC 2929 DNS IANA Considerations September 2000 + + + [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC 2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS + Names", RFC 2606, June 1999. + + [RFC 2671] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC 2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, August 1999. + + [RFC 2673] Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for + DNS (TSIG)", RFC 2845, May 2000. + + [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [US-ASCII] ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, + 1968. + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake, et al. Best Current Practice [Page 10] + +RFC 2929 DNS IANA Considerations September 2000 + + +Authors' Addresses + + 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-508-261-4447 (w) + EMail: Donald.Eastlake@motorola.com + + + Eric Brunner-Williams + Engage + 100 Brickstone Square, 2nd Floor + Andover, MA 01810 + + Phone: +1-207-797-0525 (h) + +1-978-684-7796 (w) + Fax: +1-978-684-3118 + EMail: brunner@engage.com + + + Bill Manning + USC/ISI + 4676 Admiralty Way, #1001 + Marina del Rey, CA 90292 USA + + Phone: +1-310-822-1511 + EMail: bmanning@isi.edu + + + + + + + + + + + + + + + + + + + + +Eastlake, et al. Best Current Practice [Page 11] + +RFC 2929 DNS IANA Considerations 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, et al. Best Current Practice [Page 12] + diff --git a/doc/rfc/rfc2930.txt b/doc/rfc/rfc2930.txt new file mode 100644 index 0000000000..f99573dd1c --- /dev/null +++ b/doc/rfc/rfc2930.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group D. Eastlake, 3rd +Request for Comments: 2930 Motorola +Category: Standards Track September 2000 + + + Secret Key Establishment for DNS (TKEY RR) + +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 + + [RFC 2845] provides a means of authenticating Domain Name System + (DNS) queries and responses using shared secret keys via the + Transaction Signature (TSIG) resource record (RR). However, it + provides no mechanism for setting up such keys other than manual + exchange. This document describes a Transaction Key (TKEY) RR that + can be used in a number of different modes to establish shared secret + keys between a DNS resolver and server. + +Acknowledgments + + The comments and ideas of the following persons (listed in alphabetic + order) have been incorporated herein and are gratefully acknowledged: + + Olafur Gudmundsson (TIS) + + Stuart Kwan (Microsoft) + + Ed Lewis (TIS) + + Erik Nordmark (SUN) + + Brian Wellington (Nominum) + + + + + + + + +Eastlake Standards Track [Page 1] + +RFC 2930 The DNS TKEY RR September 2000 + + +Table of Contents + + 1. Introduction............................................... 2 + 1.1 Overview of Contents...................................... 3 + 2. The TKEY Resource Record................................... 4 + 2.1 The Name Field............................................ 4 + 2.2 The TTL Field............................................. 5 + 2.3 The Algorithm Field....................................... 5 + 2.4 The Inception and Expiration Fields....................... 5 + 2.5 The Mode Field............................................ 5 + 2.6 The Error Field........................................... 6 + 2.7 The Key Size and Data Fields.............................. 6 + 2.8 The Other Size and Data Fields............................ 6 + 3. General TKEY Considerations................................ 7 + 4. Exchange via Resolver Query................................ 8 + 4.1 Query for Diffie-Hellman Exchanged Keying................. 8 + 4.2 Query for TKEY Deletion................................... 9 + 4.3 Query for GSS-API Establishment........................... 10 + 4.4 Query for Server Assigned Keying.......................... 10 + 4.5 Query for Resolver Assigned Keying........................ 11 + 5. Spontaneous Server Inclusion............................... 12 + 5.1 Spontaneous Server Key Deletion........................... 12 + 6. Methods of Encryption...................................... 12 + 7. IANA Considerations........................................ 13 + 8. Security Considerations.................................... 13 + References.................................................... 14 + Author's Address.............................................. 15 + Full Copyright Statement...................................... 16 + +1. Introduction + + The Domain Name System (DNS) is a hierarchical, distributed, highly + available database used for bi-directional mapping between domain + names and addresses, for email routing, and for other information + [RFC 1034, 1035]. It has been extended to provide for public key + security and dynamic update [RFC 2535, RFC 2136]. Familiarity with + these RFCs is assumed. + + [RFC 2845] provides a means of efficiently authenticating DNS + messages using shared secret keys via the TSIG resource record (RR) + but provides no mechanism for setting up such keys other than manual + exchange. This document specifies a TKEY RR that can be used in a + number of different modes to establish and delete such shared secret + keys between a DNS resolver and server. + + + + + + + +Eastlake Standards Track [Page 2] + +RFC 2930 The DNS TKEY RR September 2000 + + + Note that TKEY established keying material and TSIGs that use it are + associated with DNS servers or resolvers. They are not associated + with zones. They may be used to authenticate queries and responses + but they do not provide zone based DNS data origin or denial + authentication [RFC 2535]. + + Certain modes of TKEY perform encryption which may affect their + export or import status for some countries. The affected modes + specified in this document are the server assigned mode and the + resolver assigned mode. + + 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]. + + In all cases herein, the term "resolver" includes that part of a + server which may make full and incremental [RFC 1995] zone transfer + queries, forwards recursive queries, etc. + +1.1 Overview of Contents + + Section 2 below specifies the TKEY RR and provides a description of + and considerations for its constituent fields. + + Section 3 describes general principles of operations with TKEY. + + Section 4 discusses key agreement and deletion via DNS requests with + the Query opcode for RR type TKEY. This method is applicable to all + currently defined TKEY modes, although in some cases it is not what + would intuitively be called a "query". + + Section 5 discusses spontaneous inclusion of TKEY RRs in responses by + servers which is currently used only for key deletion. + + Section 6 describes encryption methods for transmitting secret key + information. In this document these are used only for the server + assigned mode and the resolver assigned mode. + + Section 7 covers IANA considerations in assignment of TKEY modes. + + Finally, Section 8 provides the required security considerations + section. + + + + + + + + + +Eastlake Standards Track [Page 3] + +RFC 2930 The DNS TKEY RR September 2000 + + +2. The TKEY Resource Record + + The TKEY resource record (RR) has the structure given below. Its RR + type code is 249. + + Field Type Comment + ----- ---- ------- + + NAME domain see description below + TTYPE u_int16_t TKEY = 249 + CLASS u_int16_t ignored, SHOULD be 255 (ANY) + TTL u_int32_t ignored, SHOULD be zero + RDLEN u_int16_t size of RDATA + RDATA: + Algorithm: domain + Inception: u_int32_t + Expiration: u_int32_t + Mode: u_int16_t + Error: u_int16_t + Key Size: u_int16_t + Key Data: octet-stream + Other Size: u_int16_t + Other Data: octet-stream undefined by this specification + +2.1 The Name Field + + The Name field relates to naming keys. Its meaning differs somewhat + with mode and context as explained in subsequent sections. + + At any DNS server or resolver only one octet string of keying + material may be in place for any particular key name. An attempt to + establish another set of keying material at a server for an existing + name returns a BADNAME error. + + For a TKEY with a non-root name appearing in a query, the TKEY RR + name SHOULD be a domain locally unique at the resolver, less than 128 + octets long in wire encoding, and meaningful to the resolver to + assist in distinguishing keys and/or key agreement sessions. For + TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD + be a globally unique server assigned domain. + + A reasonable key naming strategy is as follows: + + If the key is generated as the result of a query with root as its + owner name, then the server SHOULD create a globally unique domain + name, to be the key name, by suffixing a pseudo-random [RFC 1750] + label with a domain name of the server. For example + 89n3mDgX072pp.server1.example.com. If generation of a new + + + +Eastlake Standards Track [Page 4] + +RFC 2930 The DNS TKEY RR September 2000 + + + pseudo-random name in each case is an excessive computation load + or entropy drain, a serial number prefix can be added to a fixed + pseudo-random name generated an DNS server start time, such as + 1001.89n3mDgX072pp.server1.example.com. + + If the key is generated as the result of a query with a non-root + name, say 789.resolver.example.net, then use the concatenation of + that with a name of the server. For example + 789.resolver.example.net.server1.example.com. + +2.2 The TTL Field + + The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to + be sure that older DNS implementations do not cache TKEY RRs. + +2.3 The Algorithm Field + + The algorithm name is in the form of a domain name with the same + meaning as in [RFC 2845]. The algorithm determines how the secret + keying material agreed to using the TKEY RR is actually used to + derive the algorithm specific key. + +2.4 The Inception and Expiration Fields + + The inception time and expiration times are in number of seconds + since the beginning of 1 January 1970 GMT ignoring leap seconds + treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages + between a DNS resolver and a DNS server where these fields are + meaningful, they are either the requested validity interval for the + keying material asked for or specify the validity interval of keying + material provided. + + To avoid different interpretations of the inception and expiration + times in TKEY RRs, resolvers and servers exchanging them must have + the same idea of what time it is. One way of doing this is with the + NTP protocol [RFC 2030] but that or any other time synchronization + used for this purpose MUST be done securely. + +2.5 The Mode Field + + The mode field specifies the general scheme for key agreement or the + purpose of the TKEY DNS message. Servers and resolvers supporting + this specification MUST implement the Diffie-Hellman key agreement + mode and the key deletion mode for queries. All other modes are + OPTIONAL. A server supporting TKEY that receives a TKEY request with + a mode it does not support returns the BADMODE error. The following + values of the Mode octet are defined, available, or reserved: + + + + +Eastlake Standards Track [Page 5] + +RFC 2930 The DNS TKEY RR September 2000 + + + Value Description + ----- ----------- + 0 - reserved, see section 7 + 1 server assignment + 2 Diffie-Hellman exchange + 3 GSS-API negotiation + 4 resolver assignment + 5 key deletion + 6-65534 - available, see section 7 + 65535 - reserved, see section 7 + +2.6 The Error Field + + The error code field is an extended RCODE. The following values are + defined: + + Value Description + ----- ----------- + 0 - no error + 1-15 a non-extended RCODE + 16 BADSIG (TSIG) + 17 BADKEY (TSIG) + 18 BADTIME (TSIG) + 19 BADMODE + 20 BADNAME + 21 BADALG + + When the TKEY Error Field is non-zero in a response to a TKEY query, + the DNS header RCODE field indicates no error. However, it is + possible if a TKEY is spontaneously included in a response the TKEY + RR and DNS header error field could have unrelated non-zero error + codes. + +2.7 The Key Size and Data Fields + + The key data size field is an unsigned 16 bit integer in network + order which specifies the size of the key exchange data field in + octets. The meaning of this data depends on the mode. + +2.8 The Other Size and Data Fields + + The Other Size and Other Data fields are not used in this + specification but may be used in future extensions. The RDLEN field + MUST equal the length of the RDATA section through the end of Other + Data or the RR is to be considered malformed and rejected. + + + + + + +Eastlake Standards Track [Page 6] + +RFC 2930 The DNS TKEY RR September 2000 + + +3. General TKEY Considerations + + TKEY is a meta-RR that is not stored or cached in the DNS and does + not appear in zone files. It supports a variety of modes for the + establishment and deletion of shared secret keys information between + DNS resolvers and servers. The establishment of such a shared key + requires that state be maintained at both ends and the allocation of + the resources to maintain such state may require mutual agreement. In + the absence of willingness to provide such state, servers MUST return + errors such as NOTIMP or REFUSED for an attempt to use TKEY and + resolvers are free to ignore any TKEY RRs they receive. + + The shared secret keying material developed by using TKEY is a plain + octet sequence. The means by which this shared secret keying + material, exchanged via TKEY, is actually used in any particular TSIG + algorithm is algorithm dependent and is defined in connection with + that algorithm. For example, see [RFC 2104] for how TKEY agreed + shared secret keying material is used in the HMAC-MD5 algorithm or + other HMAC algorithms. + + There MUST NOT be more than one TKEY RR in a DNS query or response. + + Except for GSS-API mode, TKEY responses MUST always have DNS + transaction authentication to protect the integrity of any keying + data, error codes, etc. This authentication MUST use a previously + established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST + NOT use any key that the response to be verified is itself providing. + + TKEY queries MUST be authenticated for all modes except GSS-API and, + under some circumstances, server assignment mode. In particular, if + the query for a server assigned key is for a key to assert some + privilege, such as update authority, then the query must be + authenticated to avoid spoofing. However, if the key is just to be + used for transaction security, then spoofing will lead at worst to + denial of service. Query authentication SHOULD use an established + secret (TSIG) key authenticator if available. Otherwise, it must use + a public (SIG(0)) key signature. It MUST NOT use any key that the + query is itself providing. + + In the absence of required TKEY authentication, a NOTAUTH error MUST + be returned. + + To avoid replay attacks, it is necessary that a TKEY response or + query not be valid if replayed on the order of 2**32 second (about + 136 years), or a multiple thereof, later. To accomplish this, the + keying material used in any TSIG or SIG(0) RR that authenticates a + TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds + + + + +Eastlake Standards Track [Page 7] + +RFC 2930 The DNS TKEY RR September 2000 + + + (about 68 years). Thus, on attempted replay, the authenticating TSIG + or SIG(0) RR will not be verifiable due to key expiration and the + replay will fail. + +4. Exchange via Resolver Query + + One method for a resolver and a server to agree about shared secret + keying material for use in TSIG is through DNS requests from the + resolver which are syntactically DNS queries for type TKEY. Such + queries MUST be accompanied by a TKEY RR in the additional + information section to indicate the mode in use and accompanied by + other information where required. + + Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY + ignore the recursive header bit in TKEY queries they receive. + +4.1 Query for Diffie-Hellman Exchanged Keying + + Diffie-Hellman (DH) key exchange is a means whereby two parties can + derive some shared secret information without requiring any secrecy + of the messages they exchange [Schneier]. Provisions have been made + for the storage of DH public keys in the DNS [RFC 2539]. + + A resolver sends a query for type TKEY accompanied by a TKEY RR in + the additional information section specifying the Diffie-Hellman mode + and accompanied by a KEY RR also in the additional information + section specifying a resolver Diffie-Hellman key. The TKEY RR + algorithm field is set to the authentication algorithm the resolver + plans to use. The "key data" provided in the TKEY is used as a random + [RFC 1750] nonce to avoid always deriving the same keying material + for the same pair of DH KEYs. + + The server response contains a TKEY in its answer section with the + Diffie-Hellman mode. The "key data" provided in this TKEY is used as + an additional nonce to avoid always deriving the same keying material + for the same pair of DH KEYs. If the TKEY error field is non-zero, + the query failed for the reason given. FORMERR is given if the query + included no DH KEY and BADKEY is given if the query included an + incompatible DH KEY. + + If the TKEY error field is zero, the resolver supplied Diffie-Hellman + KEY RR SHOULD be echoed in the additional information section and a + server Diffie-Hellman KEY RR will also be present in the answer + section of the response. Both parties can then calculate the same + shared secret quantity from the pair of Diffie-Hellman (DH) keys used + [Schneier] (provided these DH keys use the same generator and + modulus) and the data in the TKEY RRs. The TKEY RR data is mixed + with the DH result as follows: + + + +Eastlake Standards Track [Page 8] + +RFC 2930 The DNS TKEY RR September 2000 + + + keying material = + XOR ( DH value, MD5 ( query data | DH value ) | + MD5 ( server data | DH value ) ) + + Where XOR is an exclusive-OR operation and "|" is byte-stream + concatenation. The shorter of the two operands to XOR is byte-wise + left justified and padded with zero-valued bytes to match the length + of the other operand. "DH value" is the Diffie-Hellman value derived + from the KEY RRs. Query data and server data are the values sent in + the TKEY RR data fields. These "query data" and "server data" nonces + are suffixed by the DH value, digested by MD5, the results + concatenated, and then XORed with the DH value. + + The inception and expiry times in the query TKEY RR are those + requested for the keying material. The inception and expiry times in + the response TKEY RR are the maximum period the server will consider + the keying material valid. Servers may pre-expire keys so this is + not a guarantee. + +4.2 Query for TKEY Deletion + + Keys established via TKEY can be treated as soft state. Since DNS + transactions are originated by the resolver, the resolver can simply + toss keys, although it may have to go through another key exchange if + it later needs one. Similarly, the server can discard keys although + that will result in an error on receiving a query with a TSIG using + the discarded key. + + To avoid attempted reliance in requests on keys no longer in effect, + servers MUST implement key deletion whereby the server "discards" a + key on receipt from a resolver of an authenticated delete request for + a TKEY RR with the key's name. If the server has no record of a key + with that name, it returns BADNAME. + + Key deletion TKEY queries MUST be authenticated. This authentication + MAY be a TSIG RR using the key to be deleted. + + For querier assigned and Diffie-Hellman keys, the server MUST truly + "discard" all active state associated with the key. For server + assigned keys, the server MAY simply mark the key as no longer + retained by the client and may re-send it in response to a future + query for server assigned keying material. + + + + + + + + + +Eastlake Standards Track [Page 9] + +RFC 2930 The DNS TKEY RR September 2000 + + +4.3 Query for GSS-API Establishment + + This mode is described in a separate document under preparation which + should be seen for the full description. Basically the resolver and + server can exchange queries and responses for type TKEY with a TKEY + RR specifying the GSS-API mode in the additional information section + and a GSS-API token in the key data portion of the TKEY RR. + + Any issues of possible encryption of parts the GSS-API token data + being transmitted are handled by the GSS-API level. In addition, the + GSS-API level provides its own authentication so that this mode of + TKEY query and response MAY be, but do not need to be, authenticated + with TSIG RR or SIG(0) RR [RFC 2931]. + + The inception and expiry times in a GSS-API mode TKEY RR are ignored. + +4.4 Query for Server Assigned Keying + + Optionally, the server can assign keying for the resolver. It is + sent to the resolver encrypted under a resolver public key. See + section 6 for description of encryption methods. + + A resolver sends a query for type TKEY accompanied by a TKEY RR + specifying the "server assignment" mode and a resolver KEY RR to be + used in encrypting the response, both in the additional information + section. The TKEY algorithm field is set to the authentication + algorithm the resolver plans to use. It is RECOMMENDED that any "key + data" provided in the query TKEY RR by the resolver be strongly mixed + by the server with server generated randomness [RFC 1750] to derive + the keying material to be used. The KEY RR that appears in the query + need not be accompanied by a SIG(KEY) RR. If the query is + authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR + and that authentication is verified, then any SIG(KEY) provided in + the query SHOULD be ignored. The KEY RR in such a query SHOULD have + a name that corresponds to the resolver but it is only essential that + it be a public key for which the resolver has the corresponding + private key so it can decrypt the response data. + + The server response contains a TKEY RR in its answer section with the + server assigned mode and echoes the KEY RR provided in the query in + its additional information section. + + If the response TKEY error field is zero, the key data portion of the + response TKEY RR will be the server assigned keying data encrypted + under the public key in the resolver provided KEY RR. In this case, + the owner name of the answer TKEY RR will be the server assigned name + of the key. + + + + +Eastlake Standards Track [Page 10] + +RFC 2930 The DNS TKEY RR September 2000 + + + If the error field of the response TKEY is non-zero, the query failed + for the reason given. FORMERR is given if the query specified no + encryption key. + + The inception and expiry times in the query TKEY RR are those + requested for the keying material. The inception and expiry times in + the response TKEY are the maximum period the server will consider the + keying material valid. Servers may pre-expire keys so this is not a + guarantee. + + The resolver KEY RR MUST be authenticated, through the authentication + of this query with a TSIG or SIG(0) or the signing of the resolver + KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY + for which they know the private key, and thereby the attacker could + obtain a valid shared secret key from the server. + +4.5 Query for Resolver Assigned Keying + + Optionally, a server can accept resolver assigned keys. The keying + material MUST be encrypted under a server key for protection in + transmission as described in Section 6. + + The resolver sends a TKEY query with a TKEY RR that specifies the + encrypted keying material and a KEY RR specifying the server public + key used to encrypt the data, both in the additional information + section. The name of the key and the keying data are completely + controlled by the sending resolver so a globally unique key name + SHOULD be used. The KEY RR used MUST be one for which the server has + the corresponding private key, or it will not be able to decrypt the + keying material and will return a FORMERR. It is also important that + no untrusted party (preferably no other party than the server) has + the private key corresponding to the KEY RR because, if they do, they + can capture the messages to the server, learn the shared secret, and + spoof valid TSIGs. + + The query TKEY RR inception and expiry give the time period the + querier intends to consider the keying material valid. The server + can return a lesser time interval to advise that it will not maintain + state for that long and can pre-expire keys in any case. + + This mode of query MUST be authenticated with a TSIG or SIG(0). + Otherwise, an attacker can forge a resolver assigned TKEY query, and + thereby the attacker could specify a shared secret key that would be + accepted, used, and honored by the server. + + + + + + + +Eastlake Standards Track [Page 11] + +RFC 2930 The DNS TKEY RR September 2000 + + +5. Spontaneous Server Inclusion + + A DNS server may include a TKEY RR spontaneously as additional + information in responses. This SHOULD only be done if the server + knows the querier understands TKEY and has this option implemented. + This technique can be used to delete a key and may be specified for + modes defined in the future. A disadvantage of this technique is + that there is no way for the server to get any error or success + indication back and, in the case of UDP, no way to even know if the + DNS response reached the resolver. + +5.1 Spontaneous Server Key Deletion + + A server can optionally tell a client that it has deleted a secret + key by spontaneously including a TKEY RR in the additional + information section of a response with the key's name and specifying + the key deletion mode. Such a response SHOULD be authenticated. If + authenticated, it "deletes" the key with the given name. The + inception and expiry times of the delete TKEY RR are ignored. Failure + by a client to receive or properly process such additional + information in a response would mean that the client might use a key + that the server had discarded and would then get an error indication. + + For server assigned and Diffie-Hellman keys, the client MUST + "discard" active state associated with the key. For querier assigned + keys, the querier MAY simply mark the key as no longer retained by + the server and may re-send it in a future query specifying querier + assigned keying material. + +6. Methods of Encryption + + For the server assigned and resolver assigned key agreement modes, + the keying material is sent within the key data field of a TKEY RR + encrypted under the public key in an accompanying KEY RR [RFC 2535]. + This KEY RR MUST be for a public key algorithm where the public and + private keys can be used for encryption and the corresponding + decryption which recovers the originally encrypted data. The KEY RR + SHOULD correspond to a name for the decrypting resolver/server such + that the decrypting process has access to the corresponding private + key to decrypt the data. The secret keying material being sent will + generally be fairly short, usually less than 256 bits, because that + is adequate for very strong protection with modern keyed hash or + symmetric algorithms. + + If the KEY RR specifies the RSA algorithm, then the keying material + is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in + PKCS#1 [RFC 2437]. (Note, the secret keying material being sent is + directly RSA encrypted in PKCS#1 format. It is not "enveloped" under + + + +Eastlake Standards Track [Page 12] + +RFC 2930 The DNS TKEY RR September 2000 + + + some other symmetric algorithm.) In the unlikely event that the + keying material will not fit within one RSA modulus of the chosen + public key, additional RSA encryption blocks are included. The + length of each block is clear from the public RSA key specified and + the RSAES-PKCS1-v1_5 padding makes it clear what part of the + encrypted data is actually keying material and what part is + formatting or the required at least eight bytes of random [RFC 1750] + padding. + +7. IANA Considerations + + This section is to be interpreted as provided in [RFC 2434]. + + Mode field values 0x0000 and 0xFFFF are reserved. + + Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE + can only be assigned by an IETF Standards Action. + + Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF + are allocated by IESG approval or IETF consensus. + + Mode field values 0x1000 through 0xEFFF are allocated based on + Specification Required as defined in [RFC 2434]. + + Mode values should not be changed when the status of their use + changes. For example, a mode value assigned based just on providing + a specification should not be changed later just because that use's + status is changed to standards track. + + The following assignments are documented herein: + + RR Type 249 for TKEY. + + TKEY Modes 1 through 5 as listed in section 2.5. + + Extended RCODE Error values of 19, 20, and 21 as listed in section + 2.6. + +8. Security Considerations + + The entirety of this specification is concerned with the secure + establishment of a shared secret between DNS clients and servers in + support of TSIG [RFC 2845]. + + Protection against denial of service via the use of TKEY is not + provided. + + + + + +Eastlake Standards Track [Page 13] + +RFC 2930 The DNS TKEY RR September 2000 + + +References + + [Schneier] Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and + Sons + + [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC 1035] Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + September 1996. + + [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 + for IPv4, IPv6 and OSI", RFC 2030, October 1996. + + [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + + [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 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography + Specifications Version 2.0", RFC 2437, October 1998. + + [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + + + +Eastlake Standards Track [Page 14] + +RFC 2930 The DNS TKEY RR September 2000 + + + [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s )", RFC 2931, 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 508-261-4447 (w) + EMail: Donald.Eastlake@motorola.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 15] + +RFC 2930 The DNS TKEY RR 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 16] + diff --git a/doc/rfc/rfc2931.txt b/doc/rfc/rfc2931.txt new file mode 100644 index 0000000000..84cc97e2d2 --- /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] +