From 6112b0e8fa92322f0fd0c23e86f92d4dad0f4e32 Mon Sep 17 00:00:00 2001 From: Bob Halley Date: Wed, 12 May 1999 23:51:54 +0000 Subject: [PATCH] draft updates --- doc/draft/draft-duerst-dns-i18n-01.txt | 899 ++++++++++++++++++ doc/draft/draft-ietf-dnsind-dddd-01.txt | 334 +++++++ .../draft-ietf-dnsind-indirect-key-00.txt | 470 +++++++++ .../draft-ietf-dnsind-keyreferral-00.txt | 440 +++++++++ doc/draft/draft-ietf-dnsind-rollover-00.txt | 648 +++++++++++++ ...ft-ietf-dnsind-simple-secure-update-00.txt | 278 ++++++ ...y-01.txt => draft-ietf-dnsind-tkey-00.txt} | 742 ++++++--------- 7 files changed, 3355 insertions(+), 456 deletions(-) create mode 100644 doc/draft/draft-duerst-dns-i18n-01.txt create mode 100644 doc/draft/draft-ietf-dnsind-dddd-01.txt create mode 100644 doc/draft/draft-ietf-dnsind-indirect-key-00.txt create mode 100644 doc/draft/draft-ietf-dnsind-keyreferral-00.txt create mode 100644 doc/draft/draft-ietf-dnsind-rollover-00.txt create mode 100644 doc/draft/draft-ietf-dnsind-simple-secure-update-00.txt rename doc/draft/{draft-ietf-dnssec-tkey-01.txt => draft-ietf-dnsind-tkey-00.txt} (77%) diff --git a/doc/draft/draft-duerst-dns-i18n-01.txt b/doc/draft/draft-duerst-dns-i18n-01.txt new file mode 100644 index 0000000000..fb71e11962 --- /dev/null +++ b/doc/draft/draft-duerst-dns-i18n-01.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Draft M. Duerst + University of Zurich +Expires in six months July 1997 + + + Internationalization of Domain Names + + +Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working doc- + uments of the Internet Engineering Task Force (IETF), its areas, and + its working groups. Note that other groups may also distribute work- + ing documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a "working + draft" or "work in progress". + + To learn the current status of any Internet-Draft, please check the + 1id-abstracts.txt listing contained in the Internet-Drafts Shadow + Directories on ds.internic.net (US East Coast), nic.nordu.net + (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific + Rim). + + Distribution of this document is unlimited. Please send comments to + the author at . + + +Abstract + + Internet domain names are currently limited to a very restricted + character set. This document proposes the introduction of a new + "zero-level" domain (ZLD) to allow the use of arbitrary characters + from the Universal Character Set (ISO 10646/Unicode) in domain names. + The proposal is fully backwards compatible and does not need any + changes to DNS. + + +Table of contents + + 0. Change History ................................................. 2 + 0.8 Changes (to be) Made from Version 01 to Version 02 (or later) 2 + 0.9 Changes Made from Version 00 to Version 01 .................. 2 + 1. Introduction ................................................... 3 + 1.1 Motivation .................................................. 3 + + + + Expires End of January 1998 [Page 1] + +Internet Draft Internationalization of Domain Names July 1997 + + + 1.2 Notational Conventions ...................................... 4 + 2. The Hidden Zero Level Domain ................................... 4 + 3. Encoding International Characters .............................. 5 + 3.1 Encoding Requirements ....................................... 5 + 3.2 Encoding Definition ......................................... 5 + 3.3 Encoding Example ............................................ 7 + 3.4 Length Considerations ....................................... 8 + 4. Usage Considerations ........................................... 8 + 4.1 General Usage ............................................... 8 + 4.2 Usage Restrictions .......................................... 9 + 4.3 Domain Name Creation ....................................... 10 + 4.4 Usage in URLs .............................................. 12 + 5. Alternate Proposals ........................................... 13 + 5.1 The Dillon Proposal ........................................ 13 + 5.2 Using a Separate Lookup Service ............................ 13 + 6. Generic Considerations ........................................ 14 + 5.1 Security Considerations .................................... 14 + 5.2 Internationalization Considerations ........................ 14 + Acknowledgements ................................................. 14 + Bibliography ..................................................... 15 + Author's Address ................................................. 16 + + + + +0. Change History + + + +0.8 Changes (to be) Made from Version 01 to Version 02 (or later) + + + - Decide on ZLD name (.i or .i18n.int or something else) + + - Decide on casing solution + + - Decide on exact syntax + + - Proposals for experimental setup + + + + +0.9 Changes Made from Version 00 to Version 01 + + + + + + + + Expires End of January 1998 [Page 2] + +Internet Draft Internationalization of Domain Names July 1997 + + + - Minor rewrites and clarifications + + - Added the following references: [RFC1730], [Kle96], [ISO3166], + [iNORM] + + - Slightly expanded discussion about casing + + - Added some variant proposals for syntax + + - Added some explanations about different kinds of name parallelism + + - Added some explanation about independent addition of internation- + alized names in subdomains without bothering higher-level domains + + - Added some explanations about tools needed for support, and the + MX/CNAME problem + + - Change to RFC1123 (numbers allowed at beginning of labels) + + + + +1. Introduction + + +1.1 Motivation + + + The lower layers of the Internet do not discriminate any language or + script. On the application level, however, the historical dominance + of the US and the ASCII character set [ASCII] as a lowest common + denominator have led to limitations. The process of removing these + limitations is called internationalization (abbreviated i18n). One + example of the abovementioned limitations are domain names [RFC1034, + RFC1035], where only the letters of the basic Latin alphabet (case- + insensitive), the decimal digits, and the hyphen are allowed. + + While such restrictions are convenient if a domain name is intended + to be used by arbitrary people around the globe, there may be very + good reasons for using aliases that are more easy to remember or type + in a local context. This is similar to traditional mail addresses, + where both local scripts and conventions and the Latin script can be + used. + + There are many good reasons for domain name i18n, and some arguments + that are brought forward against such an extension. This document, + however, does not discuss the pros and cons of domain name i18n. It + proposes and discusses a solution and therefore eliminates one of the + + + + Expires End of January 1998 [Page 3] + +Internet Draft Internationalization of Domain Names July 1997 + + + most often heard arguments agains, namely "it cannot be done". + + The solution proposed in this document consists of the introduction + of a new "zero-level" domain building the root of a new domain + branch, and an encoding of the Universal Character Set (UCS) + [ISO10646] into the limited character set of domain names. + + + +1.2 Notational Conventions + + In the domain name examples in this document, characters of the basic + Latin alphabet (expressible in ASCII) are denoted with lower case + letters. Upper case letters are used to represent characters outside + ASCII, such as accented characters of the Latin alphabet, characters + of other alphabets and syllabaries, ideographic characters, and vari- + ous signs. + + +2. The Hidden Zero Level Domain + + The domain name system uses the domain "in-addr.arpa" to convert + internet addresses back to domain names. One way to view this is to + say that in-addr.arpa forms the root of a separate hierarchy. This + hierarchy has been made part of the main domain name hierarchy just + for implementation convenience. While syntactically, in-addr.arpa is + a second level domain (SLD), functionally it is a zero level domain + (ZLD) in the same way as "." is a ZLD. A similar example of a ZLD is + the domain tpc.int, which provides a hierarchy of the global phone + numbering system [RFC1530] for services such as paging and printing + to fax machines. + + For domain name i18n to work inside the tight restrictions of domain + name syntax, one has to define an encoding that maps strings of UCS + characters to strings of characters allowable in domain names, and a + means to distinguish domain names that are the result of such an + encoding from ordinary domain names. + + This document proposes to create a new ZLD to distinguish encoded + i18n domain names from traditional domain names. This domain would + be hidden from the user in the same way as a user does not see in- + addr.arpa. This domain could be called "i18n.arpa" (although the use + of arpa in this context is definitely not appropriate), simply + "i18n", or even just "i". Below, we are using "i" for shortness, + while we leave the decision on the actual name to further discussion. + + + + + + + Expires End of January 1998 [Page 4] + +Internet Draft Internationalization of Domain Names July 1997 + + +3. Encoding International Characters + + + + +3.1 Encoding Requirements + + + Until quite recently, the thought of going beyond ASCII for something + such as domain names failed because of the lack of a single encom- + passing character set for the scripts and languages of the world. + Tagging techniques such as those used in MIME headers [RFC1522] would + be much too clumsy for domain names. + + The definition of ISO 10646 [ISO10646], codepoint by codepoint iden- + tical with Unicode [Unicode], provides a single Universal Character + Set (UCS). A recent report [RFCIAB] clearly recommends to base the + i18n of the Internet on these standards. + + An encoding for i18n domain names therefore has to take the charac- + ters of ISO 10646/Unicode as a starting point. The full four-byte + (31 bit) form of UCS, called UCS4, should be used. A limitation to + the two-byte form (UCS2), which allows only for the encoding of the + Base Multilingual Plane, is too restricting. + + For the mapping between UCS4 and the strongly limited character set + of domain names, the following constraints have to be considered: + + - The structure of domain names, and therefore the "dot", have to be + conserved. Encoding is done for individual labels. + + - Individual labels in domain names allow the basic Latin alphabet + (monocase, 26 letters), decimal digits, and the "-" inside the + label. The capacity per octet is therefore limited to somewhat + above 5 bits. + + - There is no need nor possibility to preserve any characters. + + - Frequent characters (i.e. ASCII, alphabetic, UCS2, in that order) + should be encoded relatively compactly. A variable-length encoding + (similar to UTF-8) seems desirable. + + + +3.2 Encoding Definition + + + Several encodings for UCS, so called UCS Transform Formats, exist + + + + Expires End of January 1998 [Page 5] + +Internet Draft Internationalization of Domain Names July 1997 + + + already, namely UTF-8 [RFC2044], UTF-7 [RFC1642], and UTF-16 [Uni- + code]. Unfortunately, none of them is suitable for our purposes. We + therefore use the following encoding: + + - To accommodate the slanted probability distribution of characters + in UCS4, a variable-length encoding is used. + + - Each target letter encodes 5 bits of information. Four bits of + information encode character data, the fifth bit is used to indi- + cate continuation of the variable-length encoding. + + - Continuation is indicated by distinguishing the initial letter + from the subsequent letter. + + - Leading four-bit groups of binary value 0000 of UCS4 characters + are discarded, except for the last TWO groups (i.e. the last + octet). This means that ASCII and Latin-1 characters need two + target letters, the main alphabets up to and including Tibetan + need three target letters, the rest of the characters in the BMP + need four target letters, all except the last (private) plane in + the UTF-16/Surrogates area [Unicode] need five target letters, and + so on. + + - The letters representing the various bit groups in the various + positions are chosen according to the following table: + + + Nibble Value Initial Subsequent + Hex Binary + 0 0000 G 0 + 1 0001 H 1 + 2 0010 I 2 + 3 0011 J 3 + 4 0100 K 4 + 5 0101 L 5 + 6 0110 M 6 + 7 0111 N 7 + 8 1000 O 8 + 9 1001 P 9 + A 1010 Q A + B 1011 R B + C 1100 S C + D 1101 T D + E 1110 U E + F 1111 V F + + + [Should we try to eliminate "I" and "O" from initial? "I" might be + + + + Expires End of January 1998 [Page 6] + +Internet Draft Internationalization of Domain Names July 1997 + + + eliminated because then an algorithm can more easily detect ".i". "O" + could lead to some confusion with "0". What other protocols are + there that might be able to use a similar solution, but that might + have other restrictions for the initial letters? Proposal to run ini- + tial range from H to X. Extracting the initial bits then becomes ^ + 'H'. Proposal to have a special convention for all-ASCII labels + (start label with one of the letters not used above).] + + Please note that this solution has the following interesting proper- + ties: + + - For subsequent positions, there is an equivalence between the hex- + adecimal value of the character code and the target letter used. + This assures easy conversion and checking. + + - The absence of digits from the "initial" column, and the fact that + the hyphen is not used, assures that the resulting string conforms + to domain name syntax. + + - Raw sorting of encoded and unencoded domain names is equivalent. + + - The boundaries of characters can always be detected easily. + (While this is important for representations that are used inter- + nally for text editing, it is actually not very important here, + because tools for editing can be assumed to use a more straight- + forward representation internally.) + + - Unless control characters are allowed, the target string will + never actually contain a G. + + + +3.3 Encoding Example + + + As an example, the current domain + + is.s.u-tokyo.ac.jp + + with the components standing for information science, science, the + University of Tokyo, academic, and Japan, might in future be repre- + sented by + + JOUHOU.RI.TOUDAI.GAKU.NIHON + + (a transliteration of the kanji that might probably be chosen to rep- + resent the same domain). Writing each character in U+HHHH notation as + in [Unicode], this results in the following (given for reference + + + + Expires End of January 1998 [Page 7] + +Internet Draft Internationalization of Domain Names July 1997 + + + only, not the actual encoding or something being typed in by the + user): + + U+60c5U+5831.U+7406.U+6771U+5927.U+5b66.U+65e5U+672c + + The software handling internationalized domain names will translate + this, according to the above specifications, before submitting it to + the DNS resolver, to: + + M0C5L831.N406.M771L927.LB66.M5E5M72C.i + + + +3.4 Length Considerations + + + DNS allows for a maximum of 63 positions in each part, and for 255 + positions for the overall domain name including dots. This allows up + to 15 ideographs, or up to 21 letters e.g. from the Hebrew or Arabic + alphabet, in a label. While this does not allow for the same margin + as in the case of ASCII domain names, it should still be quite suffi- + cient. [Problems could only surface for languages that use very long + words or terms and don't know any kind of abbreviations or similar + shortening devices. Do these exist? Islandic expert asserted + Islandic is not a problem.] DNS contains a compression scheme that + avoids sending the same trailing portion of a domain name twice in + the same transmission. Long domain names are therefore not that much + of a concern. + + +4. Usage Considerations + + + +4.1 General Usage + + + To implement this proposal, neither DNS servers nor resolvers need + changes. These programs will only deal with the encoded form of the + domain name with the .i suffix. Software that wants to offer an + internationalized user interface (for example a web browser) is + responsible for the necessary conversions. It will analyze the domain + name, call the resolver directly if the domain name conforms to the + domain name syntax restrictions, and otherwise encode the name + according to the specifications of Section 3.2 and append the .i suf- + fix before calling the resolver. New implementations of resolvers + will of course offer a companion function to gethostbyname accepting + a ISO10646/Unicode string as input. + + + + Expires End of January 1998 [Page 8] + +Internet Draft Internationalization of Domain Names July 1997 + + + For domain name administrators, them main tool that will be needed is + a program to compile files configuring zones from an UTF-8 notation + (or any other suitable encoding) to the encoding described in Section + 3.3. Utility tools will include a corresponding decompiler, checkers + for various kinds of internationalization-related errors, and tools + for managing syntactic parallelism (see Section 4.3). + + +4.2 Usage Restrictions + + + While this proposal in theory allows to have control characters such + as BEL or NUL or symbols such as arrows and smilies in domain names, + such characters should clearly be excluded from domain names. Whether + this has to be explicitly specified or whether the difficulty to type + these characters on any keyboard of the world will limit their use + has to be discussed. One approach is to start with a very restricted + subset and gradually relax it; the other is to allow almost anything + and to rely on common sense. Anyway, such specifications should go + into a separate document to allow easy updates. + + A related point is the question of equivalence. For historical rea- + sons, ISO 10646/Unicode contain considerable number of compatibility + characters and allow more than one representation for characters with + diacritics. To guarantee smooth interoperability in these and related + cases, additional restrictions or the definition of some form of nor- + malization seem necessary. However, this is a general problem + affecting all areas where ISO 10646/Unicode is used in identifiers, + and should therefore be addressed in a generic way. See [iNORM] for + an initial proposal. + + Equally related is the problem of case equivalence. Users can very + well distinguish between upper case and lower case. Also, casing in + an i18n context is not as straightforward as for ASCII, so that case + equivalence is best avoided. Problems therefore result not from the + fact that case is distinguished for i18n domain names, but from the + fact that existing domain names do not distinguish case. Where it is + impossible to distinguish between next.com and NeXT.com, the same two + subdomains would easily be distinguishable if subordinate to a i18n + domain. There are several possible solutions. One is to try to grad- + ually migrate from a case-insensitive solution to a case-sensitive + solution even for ASCII. Another is to allow case-sensitivity only + beyond ASCII. Another is to restrict anything beyond ASCII to lower- + case only (lowercase distinguishes better than uppercase, and is also + generally used for ASCII domain names). + + A problem that also has to be discussed and solved is bidirectional- + ity. Arabic and Hebrew characters are written right-to-left, and the + + + + Expires End of January 1998 [Page 9] + +Internet Draft Internationalization of Domain Names July 1997 + + + mixture with other characters results in a divergence between logical + and graphical sequence. See [HTML-I18N] for more explanations. The + proposal of [Yer96] for dealing with bidirectionality in URLs could + probably be applied to domain names. Anyway, there should be a gen- + eral solution for identifiers, not a DNS-specific solution. + + +4.3 Domain Name Creation + + + The ".i" ZLD should be created as such to allow the internationaliza- + tion of domain names. Rules for creating subdomains inside ".i" + should follow the established rules for the creation of functionally + equivalent domains in the existing domain hierarchy, and should + evolve in parallel. + + For the actual domain hierarchy, the amount of parallelism between + the current ASCII-oriented hierarchy and some internationalized hier- + archy depends on various factors. In some cases, two fully parallel + hierarchies may emerge. In other cases, if more than one script or + language is used locally, more than two parallel hierarchies may + emerge. Some nodes, e.g. in intranets, may only appear in an i18n + hierarchy, whereas others may only appear in the current hierarchy. + In some cases, the pecularities of scripts, languages, cultures, and + the local marketplace may lead to completely different hierarchies. + + Also, one has to be aware that there may be several kinds of paral- + lelisms. The first one is called syntactic parallelism. If there is + a domain XXXX.yy.zz and a domain vvvv.yy.zz, then the domain yy.zz + will have to exist both in the traditional DNS hierarchy as well as + within the hierarchy starting at the .i ZLD, with appropriate encod- + ing. + + The second type of parallelism is called transcription parallelism. + It results by transcribing or transliterating relations between ASCII + domain names and domain names in other scripts. + + The third type of parallelism is called semantic parallelism. It + results from translating elements of a domain name from one language + to another, possibly also changing the script or set of used charac- + ters. + + On the host level, parallelism means that there are two names for the + same host. Conventions should exist to decide whether the parallel + names should have separate IP addresses or not (A record or CNAME + record). With separate IP addresses, address to name lookup is easy, + otherwise it needs special precautions to be able to find all names + corresponding to a given host address. Another detail entering this + + + + Expires End of January 1998 [Page 10] + +Internet Draft Internationalization of Domain Names July 1997 + + + consideration is that MX records only work for hostnames/domains, + not for CNAME aliases. This at least has the consequence that alias + resolution for internationalized mail addresses has to occur before + MX record lookup. + + When discussing and applying the rules for creating domain names, + some peculiarities of i18n domain names should be carefully consid- + ered: + + - Depending on the script, reasonable lengths for domain name parts + may differ greatly. For ideographic scripts, a part may often be + only a one-letter code. Established rules for lengths may need + adaptation. For example, a rule for country TLDs could read: one + ideographic character or two other characters. + + - If the number of generic TLDs (.com, .edu, .org, .net) is kept + low, then it may be feasible to restrict i18n TLDs to country + TLDs. + + - There are no ISO 3166 [ISO3166] two-letter codes in scripts other + than Latin. I18n domain names for countries will have to be + designed from scratch. + + - The names of some countries or regions may pose greater political + problems when expressed in the native script than when expressed + in 2-letter ISO 3166 codes. + + - I18n country domain names should in principle only be created in + those scripts that are used locally. There is probably little use + in creating an Arabic domain name for China, for example. + + - In those cases where domain names are open to a wide range of + applicants, a special procedure for accepting applications should + be used so that a reasonable-quality fit between ASCII domain + names and i18n domain names results where desired. This would + probably be done by establishing a period of about a month for + applications inside a i18n domain newly created as a parallel for + an existing domain, and resolving the detected conflicts. For + syntactically parallel domain names, the owners should always be + the same. Administration may be split in some cases to account for + the necessary linguistic knowledge. For domain names with tran- + scription parallelism and semantic parallelism, the question of + owner identity should depend on the real-life situation (trade- + marks,...). + + - It will be desirable to have internationalized subdomains in non- + internationalized TLDs. As an example, many companies in France + may want to register an accented version of their company name, + + + + Expires End of January 1998 [Page 11] + +Internet Draft Internationalization of Domain Names July 1997 + + + while remaining under the .fr TLD. For this, .fr would have to be + reregistered as .M6N2.i. Accented and other internationalized sub- + domains would go below .M6N2.i, whereas unaccented ones would go + below .fr in its plain form. + + - To generalize the above case, one may need to create a requirement + that any domain name registry would have to register and manage + syntactically parallel domain names below the .i ZLD upon request + to allow registration of i18n domain names in arbitrary subdo- + mains. An alternative to this is to organize domain name search + so that e.g. in a search for XXXXXX.fr, if M6N2.i is not found in + .i, the name server for .fr is queried for XXXXXX.M6N2.i (with + XXXXXX appropriately encoded). This convention would allow lower- + level domains to introduce internationalized subdomains without + depending on higher-level domains. + + + +4.4 Usage in URLs + + According to current definitions, URLs encode sequences of octets + into a sequence of characters from a character set that is almost as + limited as the character set of domain names [RFC1738]. This is + clearly not satisfying for i18n. + + Internationalizing URLs, i.e. assigning character semantics to the + encoded octets, can either be done separately for each part and/or + scheme, or in an uniform way. Doing it separately has the serious + disadvantage that software providing user interfaces for URLs in gen- + eral would have to know about all the different i18n solutions of the + different parts and schemes. Many of these solutions may not even be + known yet. + + It is therefore definitely more advantageous to decide on a single + and consistent solution for URL internationalization. The most valu- + able candidate [Yer96], for many reasons, is UTF-8 [RFC2044], an + ASCII-compatible encoding of UCS4. + + Therefore, an URL containing the domain name of the example of Sec- + tion 3.3 should not be written as: + + ftp://M0C5L831.N406.M771L927.LB66.M5E5M72C.i + + (although this will also work) but rather + + ftp://%e6%83%85%e5%a0%b1.%e7%90%86.%e6%9d%b1%e5%a4%a7. + %e5%ad%a6.%e6%97%a5%e6%9c%ac + + + + + Expires End of January 1998 [Page 12] + +Internet Draft Internationalization of Domain Names July 1997 + + + In this canonical form, the trailing .i is absent, and the octets can + be reconstructed from the %HH-encoding and interpreted as UTF-8 by + generic URL software. The software part dealing with domain names + will carry out the conversion to the .i form. + + +5. Alternate Proposals + + + +5.1 The Dillon Proposal + + The proposal of Michael Dillon [Dillon96] is also based on encoding + Unicode into the limited character set of domain names. Distinction + is done for each part, using the hyphen in initial position. Because + this does not fully conform to the syntax of existing domain names, + it is questionable whether it is backwards-compatible. On the other + hand, this has the advantage that local i18n domain names can be + installed easily without cooperation by the manager of the superdo- + main. + + A variable-length scheme with base 36 is used that can encode up to + 1610 characters, absolutely insufficient for Chinese or Japanese. + Characters assumed not to be used in i18n domain names are excluded, + i.e. only one case is allowed for basic Latin characters. This means + that large tables have to be worked out carefully to convert between + ISO 10646/Unicode and the actual number that is encoded with base 36. + + +5.2 Using a Separate Lookup Service + + Instead of using a special encoding and burdening DNS with i18n, one + could build and use a separate lookup service for i18n domain names. + Instead of converting to UCS4 and encoding according to Section 3.2, + and then calling the DNS resolver, a program would contact this new + service when seeing a domain name with characters outside the allowed + range. + + Such solutions have various problems. There are many directory ser- + vices and proposals for how to use them in a way similar to DNS. For + an overview and a specific proposal, see [Kle96]. However, while + there are many proposals, a real service containing the necessary + data and providing the wide installed base and distributed updating + is in DNS does not exist. + + Most directory service proposals also do not offer uniqueness. + Defining unique names again for a separate service will duplicate + much of the work done for DNS. If uniqueness is not guaranteed, the + + + + Expires End of January 1998 [Page 13] + +Internet Draft Internationalization of Domain Names July 1997 + + + user is bundened with additional selection steps. + + Using a separate lookup service for the internationalization of + domain names also results in more complex implementations than the + proposal made in this draft. Contrary to what some people might + expect, the use of a separate lookup service also does not solve a + capacity problem with DNS, because there is no such problem, nor will + one be created with the introduction of i18n domain names. + + +6. Generic Considerations + + + +6.1 Security Considerations + + This proposal is believed not to raise any other security considera- + tions than the current use of the domain name system. + + +6.2 Internationalization Considerations + + This proposal addresses internationalization as such. The main addi- + tional consideration with respect to internationalization may be the + indication of language. However, for concise identifiers such as + domain names, language tagging would be too much of a burden and + would create complex dependencies with semantics. + + + NOTE -- This section is introduced based on a recommenda- + tion in [RFCIAB]. A similar section addressing internation- + alization should be included in all application level + internet drafts and RFCs. + + + + + +Acknowledgements + + I am grateful in particular to the following persons for their advice + or criticism: Bert Bos, Lori Brownell, Michael Dillon, Donald E. + Eastlake 3rd, David Goldsmith, Larry Masinter, Ryan Moats, Keith + Moore, Thorvardur Kari Olafson, Erik van der Poel, Jurgen Schwertl, + Paul A. Vixie, Francois Yergeau, + + + + + + + Expires End of January 1998 [Page 14] + +Internet Draft Internationalization of Domain Names July 1997 + + +Bibliography + + [ASCII] Coded Character Set -- 7-Bit American Standard Code + for Information Interchange, ANSI X3.4-1986. + + [Dillon96] M. Dillon, "Multilingual Domain Names", Memra Software + Inc., November 1996 (circulated Dec. 6, 1996 on iahc- + discuss@iahc.org). + + [HTML-I18N] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Inter- + nationalization of the Hypertext Markup Language", + Work in progress (draft-ietf-html-i18n-05.txt), August + 1996. + + [iNORM] M. Duerst, "Normalization of Internationalized Identi- + fiers", draft-duerst-i18n-norm-00.txt, July 1997. + + [ISO3166] ISO 3166, "Code for the representation of names of + countries", ISO 3166:1993. + + [ISO10646] ISO/IEC 10646-1:1993. International standard -- Infor- + mation technology -- Universal multiple-octet coded + character Set (UCS) -- Part 1: Architecture and basic + multilingual plane. + + [Kle96] J. Klensin and T. Wolf, Jr., "Domain Names and Company + Name Retrieval", Work in progress (draft-klensin-tld- + whois-01.txt), November 1996. + + [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facili- + ties", ISI, Nov. 1987. + + [RFC1035] P. Mockapetris, "Domain Names - Implementation and + Specification", ISI, Nov. 1987. + + [RFC1522] K. Moore, "MIME (Multipurpose Internet Mail Exten- + sions) Part Two: Message Header Extensions for Non- + ASCII Text", University of Tennessee, September 1993. + + [RFC1642] D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor- + mation Format of Unicode", Taligent Inc., July 1994. + + [RFC1730] C. Malamud and M. Rose, "Principles of Operation for + the TPC.INT Subdomain: General Principles and Policy", + Internet Multicasting Service, October 1993. + + [RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill, + "Uniform Resource Locators (URL)", CERN, Dec. 1994. + + + + Expires End of January 1998 [Page 15] + +Internet Draft Internationalization of Domain Names July 1997 + + + [RFC2044] F. Yergeau, "UTF-8, A Transformation Format of Unicode + and ISO 10646", Alis Technologies, October 1996. + + [RFCIAB] C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. + Atkinson, M. Crispin, P. Svanberg, "Report from the + IAB Character Set Workshop", October 1996 (currently + available as draft-weider-iab-char-wrkshop-00.txt). + + [Unicode] The Unicode Consortium, "The Unicode Standard, Version + 2.0", Addison-Wesley, Reading, MA, 1996. + + [Yer96] F. Yergeau, "Internationalization of URLs", Alis Tech- + nologies, + . + + + +Author's Address + + Martin J. Duerst + Multimedia-Laboratory + Department of Computer Science + University of Zurich + Winterthurerstrasse 190 + CH-8057 Zurich + Switzerland + + Tel: +41 1 257 43 16 + Fax: +41 1 363 00 35 + E-mail: mduerst@ifi.unizh.ch + + + NOTE -- Please write the author's name with u-Umlaut wherever + possible, e.g. in HTML as Dürst. + + + + + + + + + + + + + + + + + + Expires End of January 1998 [Page 16] + \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsind-dddd-01.txt b/doc/draft/draft-ietf-dnsind-dddd-01.txt new file mode 100644 index 0000000000..0d3b429c54 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-dddd-01.txt @@ -0,0 +1,334 @@ + +DNSIND Working Group Brian Wellington (TISLabs) +INTERNET-DRAFT Olafur Gudmundsson (TISLabs) + April 1999 + + + +Updates: RFC 2136 + + + + Deferred Dynamic Domain Name System (DNS) Delete Operations + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + 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.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + This document proposes a mechanism for notifying a dynamic DNS server + that a delete operation should be performed at a certain point in the + future. This works within the framework of the current DNS dynamic + update protocol, and provides needed functionality for clients with + leased dynamic addresses. + + + + + + + + + +Expires October 1999 [Page 1] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + +1 - Introduction + +Dynamic update operations for the Domain Name System [RFC1034, RFC1035] +are defined in [RFC2136], but there is no automated method of specifying +that records should have a fixed lifetime, or lease. + +1.1 - Overview of DNS Dynamic Update + +DNS dynamic update defines a new DNS opcode and a new interpretation of +the DNS message if that opcode is used. An update can specify +insertions or deletions of data, along with prerequisites necessary for +the updates to occur. All tests and changes for a DNS update request +are restricted to a single zone, and are performed at the primary server +for the zone. The primary server for a dynamic zone must increment the +zone SOA serial number when an update occurs or before the next +retrieval of the SOA. + +1.2 - Overview of DHCP leases + +DHCP [RFC2131] provides a means for a host to obtain a network address +from a DHCP server. The server may ``lease'' this address to the host, +meaning that it is valid only for the period of time specified in the +lease. The host may may extend its lease with subsequent requests, or +may issue a message to release the address back to the server when it is +no longer needed. + +2 - Background + +When a host receives dynamic addresses with associated dynamic DNS +records, the records can be updated by either the host or the DHCP +server. In many cases, update by the server is recommended, since the +server maintains lease information for each address. In some cases, +though, the server cannot update some or all of the DNS records. This +happens when the DNS and DHCP server are under different administration, +for example. + +A host can easily update its own DNS records when receiving information +from the DHCP server. It can also delete its records when shutting +down. If the host unexpectedly goes down, though, it cannot delete the +records. When the DHCP lease on the address expires and is not renewed, +the DHCP server may reassign the address. The DNS records now point to +an assigned address, but not the correct address. Until the host +updates its records again, DNS will contain bad information. + +Since the DHCP and DNS servers are often not co-located with the +clients, the possibility of a host unexpectedly going down and not +communicating with the servers is non-trivial. + + + + +Expires October 1999 [Page 2] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + +If the host could set a lease on the DNS records similar to that on its +address, the DNS records would lose validity at the same time as the +address. This would prevent bad information from remaining in DNS. DNS +has no such provision for leases, though, since this would require +storing a lease time along with each record (or each record in a dynamic +zone). + +An alternative method is suggested. A ``delete'' update is sent along +with the ``add'' update, but the delete is marked in such a way that it +will not be exectuted immediately. Instead, it will be stored for the +specified amount of time before being applied. If the host wishes to +extend or shorten the lifetime of the DNS record(s), it can replace the +``deferred delete'' record, which will reset the lease time of the +record(s). The ``deferred delete'' record would, of course, also be +removed if a normal delete update was received. + +3 - Protocol changes + +When doing a delete update operation as defined in [RFC2136] (deleting +an RR, an RRset, or all RRset from a name), the TTL field MUST be +specified as 0. An [RFC2136] compliant server will silently ignore (*) +an update record with a non-zero TTL. This document overloads the TTL +field. If TTL is non-zero, the value represents the number of seconds +(a 32 bit unsigned integer) before which the delete will be applied to +the zone. Thus, the delete operation will be deferred for that number +of seconds, where the number of seconds indicates the lease time. A 32 +bit integer provides for a lease time of over 136 years, which should be +long enough for most uses. + +3.1 - Storage and execution + +Deferred delete records are stored, persistently, by the name server. +The name server SHOULD attempt to evaluate the deletes in a timely +manner. If multiple deferred deletes are sent in the same DNS message +with the same TTL value, they MUST be processed atomically if processed +as planned (that is, none of the deferred deletes are updated or +cancelled). + +3.2 - Processing of deferred deletes + +When a deferred delete is received, the server must check to see if it +matches an existing deferred delete records, where matching indicates +the same name, type, class, and rdata. If a match is found, the new +deferred delete MUST replace the old one. If the deferred delete does +not refer to any record in the server, it should fail as a normal delete +would. + + + + + +Expires October 1999 [Page 3] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + +3.3 - Processing of normal deletes + +When a normal delete is received and accepted, the server SHOULD purge +any matching deferred delete records. + +3.4 - Processing of cancellations + +The value 0xFFFFFFFF (the largest unsigned 32 bit integer) in the TTL +field has a special meaning. If a delete containing this lease time is +received, the server will unconditionally remove any matching deferred +deletes. If no deferred delete matches, this request will be silently +ignored. + +3.5 - Processing of adds + +When data is added through a dynamic update which matches a deferred +delete, there is no additional processing done. + +4 - TTL handling + +Any record that may be deleted SHOULD have a short TTL compared to its +lease time, to prevent deleted data from being cached past its +expiration. + +When the time until an RR is deleted becomes low enough, the server MAY +modify the TTL of the RRset. Whenever the TTL is automatically reduced +by this process, the zone will be considered ``changed'' for the purpose +of automatic SOA SERIAL increment (as in [RFC2136]) and real time zone +slave notification [RFC1996]. As these operations can potentially be +expensive (more so if DNSSEC [RFC2535] signatures must be regenerated), +the specific limits and effects are left to the implementation. + +If the TTL is modified by the server, it is not reset if the lease is +renewed. Therefore, the original RR SHOULD be sent with the lease +renewal if the client expects that the server has modified the TTL. + + + + + + + + + + + + + + + + +Expires October 1999 [Page 4] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + +5 - Usage + +Normally, a deferred delete update will initially be sent along with an +add, although this is not required. Further updates to the deferred +delete may be sent independently, although the add should be sent again. +If the deferred delete is associated with a leased address, the lease +time of the update SHOULD be approximately equal to the lease time of +the address. + +6 - Protocol robustness + +This protocol has no inherent protection against replayed messages, +which can either originate from an attack or faulty hardware. To +prevent this problem, prerequisites should be used in the update +message, such as a test for the existence of a TXT record describing the +lease, which would be added along with the other records (see [RFC2136], +section 5). + +7 - Security considerations + +This addition to the dynamic DNS protocol does not affect the security +of the protocol. If security is desired, TSIG [TSIG] and/or DNSSEC +[RFC2535] authentication should be used, as specified in [simple-update] +or [RFC2137, update2]. The authors strongly recommend using security +along with this protocol. + +If a DNSSEC signed-zone is modified with deferred deletes, the server +must resign any affected records when the delete is executed. No +special processing is required when the delete is received. + +8 - IANA Considerations + +None. + +9 - References + +[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' + RFC 1034, ISI, November 1987. + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification,'' RFC 1035, ISI, November 1987. + +[RFC1996] P. Vixie ``A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY),'' RFC 1996, ISC, August 1996. + +[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic + Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore + & Cisco & DEC, April 1997. + + + +Expires October 1999 [Page 5] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + +[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC + 2137, CyberCash, April 1997. + +[RFC2535] D. Eastlake ``Domain Name System Security Extensions,'' RFC + 2535, IBM, March 1999. + +[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington + ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- + ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs, + February 1999. + +[simple-update] + B. Wellington ``Simple Secure Domain Name System (DNS) + Dynamic Update,'' draft-ietf-dnssec-simple-update-00.txt, + TISLabs, November 1998. + +[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic + Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite + Systems Company, August 1998. + +8 - Author's Address + + + Brian Wellington Olafur Gudmundsson + TISLabs at Network Associates TISLabs at Network Associates + 3060 Washington Road, Route 97 3060 Washington Road, Route 97 + Glenwood, MD 21738 Glenwood, MD 21738 + +1 443 259 2369 +1 443 259 2389 + + + + + + + + + + + + + + + + + + + + + + + +Expires October 1999 [Page 6] + diff --git a/doc/draft/draft-ietf-dnsind-indirect-key-00.txt b/doc/draft/draft-ietf-dnsind-indirect-key-00.txt new file mode 100644 index 0000000000..7857081ee9 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-indirect-key-00.txt @@ -0,0 +1,470 @@ +DNSIND Working Group D. Eastlake +INTERNET-DRAFT IBM +Expires October 1999 + April 1999 +draft-ietf-dnsind-indirect-key-00.txt + + + Indirect KEY RRs in the Domain Name System (DNS) + -------- --- --- -- --- ------ ---- ------ ----- + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnsind-indirect-key-00.txt, is + intended to be become a Proposed Standard RFC. Distribution of this + document is unlimited. Comments should be sent to the DNSSEC mailing + list or to the author. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + +Abstract + + [RFC 2535] defines a means for storing cryptographic public keys in + the Domain Name System. An additional code point is defined for the + algorithm field of the KEY resource record (RR) to indicate that the + key is not stored in the KEY RR but is pointed to by the KEY RR. + Encodings to indicate different types of key and pointer formats are + specified. + + [This draft is moved from the DNSSEC WG as part of that WG's merger + into me DNSIND WG. It would have been draft-ietf-dnssec-indirect- + key-02.txt in the DNSSEC WG.] + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Indirect KEY RRs + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. The Indirect KEY RR Algorithm...........................3 + 2.1 The Target Type Field..................................4 + 2.2 The Target Algorithm Field.............................5 + 2.3 The Hash Fields........................................5 + 3. Performance Considerations..............................6 + 4. IANA Considerations.....................................6 + 5. Security Considerations.................................6 + References.................................................7 + Author's Address...........................................7 + Expiration and File Name...................................8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Indirect KEY RRs + + +1. Introduction + + The Domain Name System (DNS) security extensions [RFC 2535] provide + for the general storage of public keys in the domain name system via + the KEY resource record (RR). These KEY RRs are used in support of + DNS security and may be used to support other security protocols. + KEY RRs can be associated with users, zones, and hosts or other end + entities named in the DNS. + + For reasons given below, it will sometimes be desireable to store a + key or keys elsewhere and merely point to it from the KEY RR. + Indirect key storage makes it possible to point to a key service via + a URL, to have a compact pointer to a larger key or set of keys, to + point to a certificate either inside DNS [RFC 2538] or outside the + DNS, and where appropriate, to store a key or key set applicable to + many DNS entries in some place and point to it from those entries. + + However, to simplify DNSSEC implementation, this technique MUST NOT + be used for KEY RRs used in for verification in DNSSEC, i.e., the + value of the "protocol" field of an indirect KEY RR MUST NOT be 3. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", + "RECOMMENDED", and "MAY" in this document are to be interpreted as + described in [RFC 2119]. + + + +2. The Indirect KEY RR Algorithm + + Domain Name System (DNS) KEY Resource Record (RR) [RFC 2535] + algorithm number 252 is defined as the indirect key algorithm. This + algorithm MAY NOT be used for zone keys in support of DNS security. + All KEYs used in DNSSEC validation MUST be stored directly in the + DNS. + + When the algorithm byte of a KEY RR has the value 252, the "public + key" portion of the RR is formated as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | target type | target alg. | hash type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | hash size | hash (variable size) / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ + | / + / pointer (variable size) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Indirect KEY RRs + + +2.1 The Target Type Field + + Target type specifies the type of the key containing data being + pointed at. + + Target type + ----------- + + 0 - reserved, see section 4 + + 1 - indicates that the pointer is a domain name from which KEY RRs + [RFC 2535] should be retrieved. Name compression in the pointer + field is prohibited. + + 2 - indicates that the pointer is a null terminated character string + which is a URL [RFC 1738]. For exisiting data transfer URL + schemes, such as ftp, http, shttp, etc., the data is the same as + the public key portion of a KEY RR. (New URL schemes may be + defined which return multiple keys.) + + 3 - indicates that the pointer is a domain name from which CERT RRs + [RFC 2538] should be retrieved. Name compression in the pointer + field is prohibited. + + 4 - indicates that the pointer is a null terminated character string + which is a URL [RFC 1738]. For exisiting data transfer URL + schemes, such as ftp, http, shttp, etc., the data is the same as + the entire RDATA portion of a CERT RR [RFC 2538]. (New URL + schemes may be defined which return multiple such data blocks.) + + 5 - indicates that the pointer is a null terminated character string + which is a URL [RFC 1738]. For exisiting data transfer URL + schemes, such as ftp, http, shttp, etc., the data is a PKCS#1 [RFC + 2437] format key. (New URL schemes may be defined which return + multiple keys.) + + 6 through 255 - available for assignment, see section 4. + + 256 through 511 (i.e., 256 + n) - indicate that the pointer is a null + terminated character string which is a URL [RFC 1738]. For + exisiting data transfer URL schemes, such as ftp, http, shttp, + etc., the data is a certificate of the type indicated by a CERT RR + [RFC 2538] certificate type of n. That is, target types 257, 258, + and 259 are PKIX, SPKI, and PGP certificates and target types 509 + and 510 are URL and OID private certificate types. (New URL + schemes may be defined which return multiple such certificates.) + + 512 through 65534 - available for assignment, see section 4. + + 65535 reserved, see section 4. + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Indirect KEY RRs + + +2.2 The Target Algorithm Field + + The algorithm field is as defined in [RFC 2535]. If non-zero, it + specifies the algorithm type of the target key or keys pointed. If + zero, it does not specify what algorithm the target key or keys apply + to. + + + +2.3 The Hash Fields + + If the indirecting KEY RRset [RFC 2181, 2535] is retrieved from an + appropriately secure DNS zone with a resolver implementing DNS + security, then there would be a high level of confidence in the + entire value of the KEY RRset including any direct keys. This may or + may not be true of any indirect key pointed to. If an indirect key + is embodied in a certificate or retrieved via a secure protocol such + as SHTTP, it may also be secure. But an indirecting KEY RR could, + for example, simply have an FTP URL pointing to a binary key stored + elsewhere, the retrieval of which would not be secure. + + The hash option in algorithm 252 KEY RRs provides a means of + extending the security of the indirecting KEY RR to the actual key + material pointed at. By including a hash in a secure indirecting RR, + this secure hash can be checked against the hash of the actual keying + material + + Type Hash Algorithm + ---- -------------- + 0 indicates no hash present + 1 MD5 [RFC 1321] + 2 SHA-1 + 3 RIPEMD + 4-252 available, see section 4 + 253 private, domain name (see below) + 254 private, OID (see below) + 255 reserved + + Codes 253 and 254 indicate that a private, proprietary, local, or + experimental hash algorithm is used. For code 253, the hash field + begins with a wire encoded domain name (with compression prohibited) + that indicates the algorithm to use. For code 254, the hash field + begins with a one byte unsigned OID length followed by a BER encoded + OID which indicates the algorithm to use. + + The hash size field is an unsigned octet count of the hash field size + less the length of any code 253 or 254 prefix. For some hash + algorithms it may be fixed by the algorithm choice but this will not + always be the case. For example, hash size is used to distinguish + between RIPEMD-128 (16 octets) and RIPEMD-160 (20 octets). If the + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Indirect KEY RRs + + + hash algorithm field is 0, the hash size MUST be zero and no hash + octets are present. + + The hash field itself is variable size with its length specified by + the hash size field and any code 253 or 254 prefix. + + + +3. Performance Considerations + + With current public key technology, an indirect key will sometimes be + shorter than the keying material it points at. In addition, there + can be cases where a single indirect KEY RR points to multiple keys + elsewhere. This may improve DNS performance in the retrieval of the + initial KEY RR. However, an additional retrieval step then needs to + be done to get the actually keying material which must be added to + the overall time to get the public key. + + + +4. IANA Considerations + + IETF consensus, standards action, and similar terms in this section + are as define in [RFC 2434]. + + KEY RR algorithm number 252 was already reserved for indirect keys in + RFC 2535. + + An IETF standards action is required to allocate target type codes + hex x0000, x0006 through x00FF, x0200 through x0FFF, and xFFFF. + Codes in the range x1000 through x7FFF can be allocated by an IETF + consensus. Codes x8000 through xFEFF are available on a first come + first serve basis. Codes xFF00 through xFFFE are available for + experimentation or private local use without allocation. Use of + codes in this block may result in conflicts outside such experiment + or locality. + + An IETF consensus is required to allocate an indirect KEY RR hash + algorithm code in the range 4-252 and a standards action is required + to allocate hash algorithm code 255. Codes 253 and 254 should cover + requirements for local, private, or proprietary algorithms. + + + +5. Security Considerations + + The indirecting step of using an indirect KEY RR adds complexity and + additional steps where security could go wrong. If the indirect key + RR was retrieved from a zone that was insecure for the resolver, you + have no security. If the indirect key RR, although secure itself, + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Indirect KEY RRs + + + point to a key which can not be securely retrieved and is not + validateted by a secure hash in the indirect key RR, you have no + security. + + + +References + + RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", + STD 13, November 1987. + + RFC 1035 - P. Mockapetris, "Domain Names - Implementation and + Specifications", STD 13, November 1987. + + RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992. + + RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform + Resource Locators (URL)", December 1994. + + RFC 2119 - "Key words for use in RFCs to Indicate Requirement + Levels", S. Bradner. March 1997. + + RFC 2181 - R. Elz, R. Bush, "Clarifications to the DNS + Specification", July 1997. + + RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", October 1998. + + RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography + Specifications Version 2.0", October 1998. + + RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", + March 1999. + + RFC 2538 - D. Eastlake, O. Gudmundsson, "Storing Certificates in the + Domain Name System (DNS)", March 1999. + + + +Author's Address + + Donald E. Eastlake 3rd + IBM + 65 shindegan Hill Road, RR #1 + Carmel, NY 10512 USA + + Telephone: +1-914-784-7913 (w) + +1-914-276-2668 (h) + FAX: +1-914-784-3833 (w) + EMail: dee3@us.ibm.com + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Indirect KEY RRs + + +Expiration and File Name + + This draft expires October 1999. + + Its file name is draft-ietf-dnsind-indirect-key-00.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + diff --git a/doc/draft/draft-ietf-dnsind-keyreferral-00.txt b/doc/draft/draft-ietf-dnsind-keyreferral-00.txt new file mode 100644 index 0000000000..7670b4c66e --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-keyreferral-00.txt @@ -0,0 +1,440 @@ + +DNSIND WG Edward Lewis +INTERNET DRAFT TIS Labs +May Update: RFC 2535 Jerry Scharf +Catagory: I-D ISC + April 1, 1999 + + The Zone Key Referral + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments should be sent to the authors or the DNSIND WG mailing list + . + + This draft expires on October 1, 1999 + +Copyright Notice + + Copyright (C) The Internet Society (1999). All rights + reserved. + +Notes on this document + +This section will only appear in the -00.txt edition of this draft. + +This document originated in the DNSSEC working group in June 1998. The +discussion of the issues in this draft were tabled until the publication +of the then current DNSSEC drafts as RFCs. + +The first version of this document lists a third author, John Gilmore. +He is listed as an author because he was one of the initiators of what is +proposed. In this and following versions he is only listed in the +Acknowledgements (as opposed to being an author) as he has not been +involved in the writing/editing of the draft. This has been done to +avoid assigning his name to a document he may not have a chance to read, +this is not intended as a slight on his efforts. + +When commenting on this draft, please be aware that some terms used here +are up for negotiation before progressing - such as "thief" and "road +block" appearing later in the draft. Comments which are left justified +were added during the re-issuing of the draft, they add context that +may have been lost over time. + + Abstract + + A new type of key is defined to address the problems of + performance in large delegeted zones and issues of liability of + registrars with regards to the storing of public keys belonging + to zone cuts. This new key type also brings DNSSEC more in line + with the DNS treatment of zone cuts and speeds recovery in + handling privatekey exposure. + + The new type of key is a referral record that is stored, signed, + at the parent zone's place for the delegation point. A resolver + receiving this record is being informed that there are genuine + public keys at the child's authoritative name servers. The + parent no longer needs to store the child's public keys locally. + +1 Introduction + + There are a number of different reasons for the proposal of this + new key type. Reasons include: + o the performance impact that RFC 2535 has on name servers + o the problem of updating a widely delegated parent zone on demand + o statements in RFC 2181 on authoritative data at delegations + o perceived liability of the operator of a name server or registry + + To address these issues, which are expanded upon below, a new + key type is proposed - a "zone key referral" - to join the user + key, host key, and zone key types defined in RFC 2535. + +1.1 Performance Issues + + A sample zone will be used to illustrate the problem. The + example will part from reality mostly in the length of zone + names, which changes the size of the owner and resource record + data fields. + + # $ORIGIN test. + # @ IN SOA + # IN SIG SOA + # IN KEY <1024 bit zone key> + # IN SIG KEY + # IN SIG KEY + # IN NS ns.test. + # IN SIG NS + # IN NXT my-org.test. NS SOA SIG KEY NXT + # IN SIG NXT + # + # my-org IN KEY <1024 bit zone key> + # IN KEY <1024 bit zone key> + # IN SIG KEY + # IN NS ns1.my-org.test. + # IN NS ns2.my-org.test. + # IN NXT them.test. NS SIG KEY NXT + # IN SIG NXT + # + # them IN KEY 0xC100 3 1 + # IN SIG KEY + # IN NS ns1.them.test. + # IN NS ns2.them.test. + # IN NXT test. NS SIG KEY NXT + # IN SIG NXT + + In this zone file fragment, "my-org" is a delegation point of + interest with two registered public keys. Presumably, one key + is for signatures generated currently and the other is for still + living and valid but older signatures. "them" is another + delegation point, with a NULL key. This signifies that this zone + is unsecured. + + To analyze the performance impact of the storing of keys, the + number of bytes used to represent the RRs in the procotol format + is used. The actual number of bytes stored will likely be + higher, accounting for data structure overhead and alignment. + The actual number of bytes transferred will be lower due to DNS + name compression. + + The number of bytes for my-org's two 1024-bit keys, two NS + records, NXT and the associated signatures is 526. The bytes + needed for them (with the NULL key) is 346. Currently, there + are close to 2 million entries in com., so if we take my-org as + a typical domain, over 1GB on memory will be needed for com. + + The zone keys used in the example are set to 1024 bits. This + number may range from as low as 512 bits upwards to over 3000 + bits. To scale the above numbers to a different key size, + multiply the difference in key sizes by 4 for my-org and by 2 + for them, and adjust the numbers accordingly. + + The increased size of the data held for the zone cuts will have + two impacts at the transport and below layers. Bandwidth beyond + that currently needed will be used to carry the KEY records. + The inclusion of all of the child's keys will also push DNS over + the UDP size limit and start using TCP - which could cause + critical problems for current heavily used name servers, like + the roots. + + Another impact, not illustrated by the example, is the frequency + of updates. If each time a public key for my-org is added or + deleted, the SOA serial number will have to increase, and the + SOA signed again. If an average zone changes its keys(s) once + per month, there will be on average 45 updates per minute in a + zone of 2 million delegations. + +(The multiple algorithms issue is an extension of multiple keys. The +example should be updated to show at least a DSS key as well as an RSA +key.) + +1.2 Security Incident Recovery (w/ respect to keys only) + + Once a zone administrator is alerted that any key's private + counterpart has been discovered (exposed), the first action to + be taken is to stop advertising the public key in DNS. This + doesn't end the availability of the key - it will be residing in + caches - but is the closest action resembling revokation + available in DNS. + + Stopping the advertisement in the zone's name servers is as + quick as altering the master file and restarting the name + server. Having to do this in two places will will only delay + the time until the recovery is complete. + + For example, a registrar of a top level domain has decided to + update its zone only on Mondays and Fridays due to the size of + the zone. A customer/delegatee is the victim of a break in, in + which one of the items taken is the file of private keys used to + sign DNS data. If this occurs on a Tuesday, the thief has until + Friday to use the keys before they disappear from the DNS, even + if the child stops publishing them immediately. + + If the public key set is in the parent zone, and the parent zone + is not able to make the change quickly, the public key cannot be + revoked quickly. If the parent only refers to there being a key + at the child zone, then the child has the agility to change the + keys - even issue a NULL key, which will force all signatures in + the zone to become suspect. + +1.3 DNS Clarifications + + RFC 2181, section 6, clarifies the status of data appearing at a + zone cut. Data at a zone cut is served authoritatively from the + servers listed in the NS set present at the zone cut. The data + is not (necessarily) served authoritatively from the parent. + (The exception is in servers handling both the parent and child + zone.) + + Section 6 also mentions that there are two exceptions created by + DNSSEC, the NXT single record set and the KEY set. This + proposal addresses the exception relating to the KEY set, + limiting its severity (but falling short of removing it + altogether). By limiting the exception, we will be simplifying + DNS. + +1.4 Liability + + Liability is a legal concept, so it is not wise to attempt an + engineering solution to it. However, the perceived liability + incurred in using DNSSEC by registrars may prevent the adoption + of DNSSEC. Hence DNSSEC should be engineered in such a away to + address the concern. + + One source of liability is the notion that by advertising a + public key for a child zone, a parent zone is providing a + service of security. With that comes responsibility. By having + the parent merely indicate that a child has a key (or has no + key), the parent is providing less in the way of security. If + the parent is wrong, the potential loss is less. Instead of + falsely authenticated data, configuration errors will be + apparent to the resolving client. + +2 The Proposal + + The proposal is to introduce a new key type which indicates + whether the delegated zone is running secured or not. Running + secured is either a zone signed with at least one key, an + experimental zone, or a zone with only NULL keys published. + + The Zone Referral Key will resemble the NULL key in syntax. + There will be a flags field, an algorithm field, and a protocol + field, but no public key material. The Referral Key is signed + by the parent zone, as was the public key set in RFC 2065. + There is only one Referral Key RR present. + + The Referral Key flags field will have the following values: + Field Bit(s) Value Meaning + + A/C 0- 1 0b01 indicates a key will be found + 0b11 indicates a key will not be found + 0b?0 error (referral cannot encrypt) + XT 2 0 no extended flags are needed + Z 4- 5 0 must be zero for all keys + NAMTYP 6- 7 0b11 this is a referral to a zone key + Z 8-11 0 must be zero for all keys + SIG 12-15 0 must be zero for a referral key + + The legal values of the flags field are (in summary): + + Hex Value Indicates + 0x4300 The delegation has a key record set + 0xC300 The delegation has no key record + + Other values are not valid for Referral Keys (but may be valid + for other keys). + + The Protocol field must be set to 3, the DNSSEC protocol value. + + The Algorithm field must be 0. + +The algorithm is not important at this point. So long as the searcher +knows to expect a key set at the delegated zone's apex, a secure chain +is possible. One the key set is retrieved and verified, then the +algorithms used in the delegated zone are known. (The issue is that a +zone may be signed in algorithm 1 and not 3, 3 and not 1, both, etc., +and a secure resolver must know this in order to set signature arrival +expectations. + +2.1 Example + + The Referral key for my-org.test. and them.test. would appear as + the following in the zone master file: + + my-org.test. IN KEY 0x4300 3 0 + them.test. IN KEY 0xC300 3 0 + + In the example introduced earlier, the master file would change + to the following. + + # $ORIGIN test. + # @ IN SOA + # IN SIG SOA + # IN KEY <1024 bit zone key> + # IN SIG KEY + # IN SIG KEY + # IN NS ns.test. + # IN SIG NS + # IN NXT my-org.test. NS SOA SIG KEY NXT + # IN SIG NXT + # + # my-org IN KEY 0x4300 3 0 + # IN SIG KEY + # IN NS ns1.my-org.test. + # IN NS ns2.my-org.test. + # IN NXT them.test. NS SIG KEY NXT + # IN SIG NXT + # + # them IN KEY 0xC300 3 1 + # IN SIG KEY + # IN NS ns1.them.test. + # IN NS ns2.them.test. + # IN NXT test. NS SIG KEY NXT + # IN SIG NXT + +3 Analysis + + By removing the public keys from the parent's master file, the + parent is no longer a road block during an emergency removal of + keys. A parent zone is unchanged as a zone changes from NULL + keys to experimental keys to fully signed. The parent is also + not providing a security service, other than to authentically + claim the existence of a KEY record set - akin to the "hints" of + the name servers. + + The change also improves the prospect for performance. The need + for multiple KEY RR's, each one on the order of 100 bytes, is + removed and replaced by a single KEY RR of the order of 25 + bytes. Saving bytes reduces the need to use TCP to avoid + truncated responses. Also, the need for updating the zone drops + - no longer will there be updates for each key change. + + As far as the statements by RFC 2181 conerning authority levels, + the Referral Key is not authortative and would be superseeded by + a verified set of the real zone keys. The only caveat is that + once the verified set of keys expire (assuming the parent has to + learn the keys from another server), the Referal Key must + reappear. This is an example of what has been labelled "mount- + like semantics." + + [No reference for mount-like semantics has yet been found.] + + The last point is important. This requires the "mount-like + semantics" that have been discussed for the BIND name servers. + Once hints are overridden by learned, authorititative and + verified data, the hints are not discarded. Hints in this state + are stored and become visible when the learned data expires. + +4 IANA Considerations + + Other than using a new value in the flags field of the KEY RR, + no new number assignments are needed. The flags field is not + under the control of IANA as of yet. There are no requirements + placed on IANA by this draft. + +5 Security Considerations + + There has been some debate about whether the Referral key should + be treated as a hint - just like the NS records. If so, then + there is no need to sign the Referral Key, and an unsigned + (hence non-authenticated) security record is of little value. + So, is the Referral Key even needed? + + Authentication in DNSSEC is done from the data "back" towards a + trusted point - e.g., "up" to the root. Since the + authentication is done by going repeatedly from child to parent, + why bother having the parent indicate the status of the child? + + The answer is in the scenario in which a resolver somewhere has + obtained data which fails the verification process. Perhaps the + signature is wrong, a key in the chain of trust is unavailable, + the set should have had a signature, but none is found (or vice + versa), or the trail of signed-by names is not acceptable. In + this case, the resolver needs to find the authoritative zone, + its status and its name server set. + + If a zone is being attacked by a masquerader, and parents do not + make any statements about the security of child zones, then an + easy and successfull attack may occur. An attacker only needs + to supply either fake name server records or glue records to + redirect queries. + + While this attack will not be stopped as far as denial of + service, the masquerader can be stopped from being accepted as + an authoritative source if the parent of the zone claims the + child is secure and signs the public keys of the true child and + not the masquerader. + + The masquerader cannot successfully claim that the zone is + unsigned, because it must have a zone key signed by the parent. + NULL or not, the key would not be trusted by the resolver, + assuming the parent has not also been duped. The resolver, + sensing this, should report an error or security incident, and + not accept data. + +6 Acknowledgements + + John Gilmore originally raised the issues that have led to this + document. + +7 Author's addresses + +Edward Lewis Jerry Scharf + +3060 Washinton Rd (Rte 97) +Glenwood, MD 21738 ++1(443)259-2352 + +8 References + +RFC 2181 "Clarifications to the DNS Specification", Elz and Bush +RFC 2535 "Domain Name System Security Extensions", Eastlake + +9 Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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 implmentation 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." + +This draft expires on October 1, 1999 diff --git a/doc/draft/draft-ietf-dnsind-rollover-00.txt b/doc/draft/draft-ietf-dnsind-rollover-00.txt new file mode 100644 index 0000000000..8d8cef1cfc --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-rollover-00.txt @@ -0,0 +1,648 @@ +INTERNET-DRAFT DNSIND Key Rollover +UPDATES RFC 1996 April 1999 + Expires October 1999 +draft-ietf-dnsind-rollover-00.txt + + + + Domain Name System (DNS) Security Key Rollover + ------ ---- ------ ----- -------- --- -------- + + Donald E. Eastlake 3rd, Mark Andrews + + + +Status of This Document + + This draft, file name draft-ietf-dnsind-rollover-00.txt, is intended + to be become a Proposed Standard RFC. Distribution of this document + is unlimited. Comments should be sent to the DNS working group + mailing list or to the authors. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +Abstract + + Deployment of Domain Name System (DNS) security with good cryptologic + practice will involve large volumes of key rollover traffic. A + standard format and protocol for such messages will be necessary for + this to be practical and is specified herein. + + [Note: this draft has been moved to dnsind from dnssec as part of the + ongoing combination of these working groups. It would have been + draft-ietf-dnssec-rollover-01.txt otherwise.] + + + + +D. Eastlake 3rd, M. Andrews [Page 1] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Key Rollover Scenario...................................3 + 3. Rollover Operation......................................5 + 3.1 Rollover to Parent.....................................5 + 3.2 Rollover to Children...................................6 + 4. Secure Zone Cuts and Joinders...........................7 + 5. Security Considerations.................................8 + 6. IANA Considerations.....................................9 + + References................................................10 + Authors Address...........................................10 + Expiration and File Name..................................11 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 2] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + +1. Introduction + + The Domain Name System (DNS) [RFC 1034, 1035] is the global + hierarchical replicated distributed database system for Internet + addressing, mail proxy, and other information. The DNS has been + extended to include digital signatures and cryptographic keys as + described in [RFC 2535]. + + The principle security service provided for DNS data is data origin + authentication. The owner of each zone signs the data in that zone + with a private key known only to the zone owner. Anyone that knows + the corresponding public key can then authenticate that zone data is + from the zone owner. To avoid having to preconfigure resolvers with + all zone's public keys, keys are stored in the DNS with each zone's + key signed by its parent (if the parent is secure). + + To obtain high levels of security, keys must be periodically changed, + or "rolled over". The longer a private key is used, the more likely + it is to be compromised due to cryptanalysis, accident, or treachery + [RFC 2541]. + + In a widely deployed DNS security system, the volume of update + traffic will be large. Just consider the .com zone. If only 10% of + its children are secure and change their keys only once a year, you + are talking about hundreds of thousands of new child public keys that + must be securely sent to the .com manager to sign and return with + their new parent signature. And when .com rolls over its private + key, it will needs to send hundred of thousands of new signatures on + the existing child public keys to the child zones. + + It will be impractical to handle such update volumes manually on a + case by case basis. The bulk of such key rollover updates must be + automated. + + The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" + in this document are to be interpreted as described in [RFC 2119]. + + + +2. Key Rollover Scenario + + Although DNSSEC provides for the storage of other keys in the DNS for + other purposes, DNSSEC zone keys are included solely for the purpose + of being retrieved to authenticate DNSSEC signatures. Thus, when a + zone key is being rolled over, the old public key should be left in + the zone, along with the addition of the new public key, for as long + as it will reasonably be needed to authenticate old signatures that + have been cached or are held by applications. Similarly, old parent + SIGs should be retained for a short time after a parent KEY(s) roll + over and new parent SIGs have been installed. + + +D. Eastlake 3rd, M. Andrews [Page 3] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + + If DNSSEC were universally deployed and all DNS server's clocks were + synchronized and zone transfers were instantaneous etc., it might be + possible to avoid ever having duplicate old/new KEY/SIG RRsets due to + simultaneous expiration of SIGs everywhere in the DNS. But these + assumptions do not hold. Security aware DNS servers decrease the TTL + of secure RRs served as the expiration of their authenticating SIG(s) + approaches but some dithered fudge must generally be left due to + clock skew, RR retention by applications, and the like. Retaining + old KEYs for a while after rolling over to new KEYs will be necessary + in practical cases. + + Assume a middle zone with a secure parent and a secure child wishes + to role over its KEY RRset. This RRset would probably be one KEY RR + per crypto algorithm used to secure the zone, but for this scenario, + we will simply assume it is one KEY RR. The old KEY RR and two SIG + RRs will exist at the apex of the middle zone. (These RRs may also + exist at the leaf node for this zone in its parent if the parent + chooses to store them there.) The contents of the middle zone and the + zone KEY RRs of its secure child will have SIGs under the old key. + + The middle zone owner needs to communicate with its parent to obtain + a new parental signature covering both the old and new KEY RRs and + covering just the new KEY RR. The signature on both is needed so the + old KEY can be retain for the period it might be needed to + authenticate old SIGs. The middle zone would probably want to obtain + these in advance so that it can install them at the right time along + with its new SIG RRs covering the content of its zone. Finally, it + needs to give new SIG RRs to its child that cover its KEY RRs so it + must signal its children to ask for such SIG RRs. + + BEFORE ROLLOVER SHORTLY AFTER AFTER ROLLOVER + + p.x KEY P1 p.x KEY P1 p.x KEY P1 + p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1 + p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP + + m.p.x KEY M1 m.p.x KEY M2 m.p.x KEY M2 + m.p.x SIG(KEY) P1 m.p.x KEY M1 m.p.x SIG(KEY) P1 + m.p.x SIG(KEY) M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) M2 + m.p.x SIG(KEY) M2 + + c.m.p.x KEY C1 c.m.p.x KEY C1 c.m.p.x KEY C1 + c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) M2 c.m.p.x SIG(KEY) M2 + c.m.p.x SIG(KEY) C1 c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) C1 + c.m.p.x SIG(KEY) C1 + + p = parent, m = middle, c = child, GP = grandparent key + P* = parent key, M* = middle zone key, C* = child key + + + + +D. Eastlake 3rd, M. Andrews [Page 4] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + +3. Rollover Operation + + Rollover operations use a DNS request syntactically identical to the + UPDATE request [RFC 2136] (except that the operation code is ROLLOVER + which is equal to (TBD)) and use a new form of NOTIFY [RFC 1996]. + Considerations for such requests to the parent and children of a zone + are givens below. + + All rollover operations involve significant amounts of cryptographic + calculations. Appropriate rate limiting SHOULD be applied to avoid + denial of service attacks. + + [This draft does not consider cross-certification key rollover.] + + + +3.1 Rollover to Parent + + A zone rolling over its KEY RRset sends an upward ROLLOVER request to + its parent. Actually, it will normally do two upward ROLLOVERs, one + for a combined KEY RRset of its old and new KEYs and one for just its + new KEY RRset, as discussed above. + + The server selection algorithm in [RFC 2136] section 4 should be + used. A child needs to be configured with or determine the name of + its parent but SHOULD NOT remember the location of its parent other + than via normal DNS caching of address RRs so that rollover will + continue to work if its parent servers are moved. + + The ROLLOVER request Zone should be specified as the parent zone. + The request Update section has the new KEY RRset on which the parent + signature is requested along with the requesting zone's SIG(s) under + its old KEY(s) as RRs to be "added" to the parent zone. The + inception and expiration times in this child SIG or SIGs are the + requested inception and expiration times for the new parent SIG(s). + The "prerequisites" section has the old child KEY RRset with the + parent SIG (see next paragraph). + + An upward ROLLOVER request MUST be signed and if not signed a BADAUTH + response generated. The signature MUST be under the previous zone + KEY, so the parent can validate it, or under a valid TSIG key + [draft-ietf-dnsind-tsig-*.txt] arranged with the parent. Including + the "prerequisite" section as specified above enables a parent that + keeps no record of its children's KEYs to still authenticate a + child's ROLLOVER request based on the old child KEY because the + parent is presented with its own SIG on the old KEY. + + If the ROLLOVER command is erroneous or violates parental policy, an + Error response is returned. If a parent retains copies of its + children's KEYs, it may use that knowledge to validate ROLLOVER + + +D. Eastlake 3rd, M. Andrews [Page 5] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + + request SIGs and ignore the "prerequisites" section. + + If the ROLLOVER command is OK and the parent can sign online, its + response MAY include the new parent SIG(s) in the response Update + section. This response MUST be sent to the originator of the + request. + + If the parent can not sign online, it should return a response with + an empty Update section and queue the SIG(s) calculation request. + This response MUST be sent to the originator of the request. + + ROLLOVER response messages MUST always include the actual parent's + SOA signed with a key the child should recognize in the Additional + Information section (see section 4 below). + + Regardless of whether the server has sent the new signatures above, + it MUST, once it has calculated the new SIG(s), send a ROLLOVER to + the child zone using the DNS port (53) and the server selection + algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust + contains the KEY RRset that triggered it and the new SIG(s). There + are several reasons for sending the ROLLOVER response regardless of + whether the new SIG RR(s) were sent in the original response. One is + to provide an indication to the operators of the zone in the event + someone is trying to hijack the zone. Another is that this maximizes + the probability of the response getting through. + + Although the parent zone need not hold or serve the child's key, if + it does the ROLLOVER command REQUEST SHOULD NOT automatically update + the parent zone. A later UPDATE command can be used to actually put + the new KEY into the parent zone if desired and supported by parent + policy. + + This document does not cover the question of parental policy on key + rollovers. Parents may have restrictions on how far into the future + they will sign KEY RRsets, what algorithms or key lengths they will + support, might require payment for the service, etc. The signing of + a future KEY by a parent is, to some extent, a granting of future + authoritative existence to the controller of the child private key + even if the child zone ownership should change. The only effective + way of invalidating such future signed child public keys would be for + the parent to roll over its key(s), which might be an expensive + operation. + + + +3.2 Rollover to Children + + When a secure zone is going to rollover its key(s), it needs to re- + sign the zone keys of any secure children under its new key(s). The + parent simply notifIES the child via a rollover NOTIFY [RFC 1996] + + +D. Eastlake 3rd, M. Andrews [Page 6] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + + that the parent KEY(s) have changed. The child then proceeds to do + an upward ROLLOVER request, as described in 3.1 above to obtain the + new parental SIG(s). + + A rollover NOTIFY is a NOTIFY request [RFC 1996] that has a QTYPE of + SIG and the owner name of the child zone. The answer section has the + current parent SOA signed by a key the child will know (see section + 4). + + A rollover NOTIFY MUST be signed and if not signed a BADAUTH response + generated. The signature MUST be under the previous parental zone + KEY, so the child can validate it, or under a valid TSIG key [draft- + ietf-dnsind-tsig-*.txt] negotiated between parent and child. + + The rollover NOTIFY can be sent to any of the nameservers for the + child using the nameserver selection algorithm defined in RFC 2136, + Section 4. Nameservers for the child zone receiving a rollover + NOTIFY query will forward the rollover NOTIFY in the same manner as + an UPDATE is forwarded. + + Unless the master server is configured to initiate an automatic + ROLLOVER it MUST seek to inform its operators that a rollover NOTIFY + request has been received. This could be done by a number of methods + including generating a log message, generating an email request to + the child zone's SOA RNAME or any other method defined in the + server's configuration for the zone. The default SHOULD be to send + mail to the zone's SOA RNAME. As with all rollover operations, care + should be taken to rate limit these messages so prevent them being + used to facilitate a denial of service attack. + + Once the message has been sent (or suppressed if so configured) to + the child zone's administrator the master server for the child zone + is free to respond to the rollover NOTIFY request. + + + +4. Secure Zone Cuts and Joinders + + There are two other events that have some similarity to key rollover. + + The first is when a secure zone the is more than one level deep has a + zone cut introduced inside it. For example, assume zone example.com + has a.b.c.example.com, d.b.c.example.com and e.example.com in it. A + zone cut could be introduced such that b.c.example.com became a + separate child zone of example.com. A real world exampe would be a + company that structures its DNS as host.branch.company.example. It + might start out will all of these names in one zone but later decide + to delegate all or some of the branches to branch zone file + maintainers. + + + +D. Eastlake 3rd, M. Andrews [Page 7] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + + The second is when a secure zone absorbs a child zone eliminating a + zone cut. This is simply the inverse of the previous paragraph. + + From the point of view of the parent zone above the splitting zone or + above the upper of the two combining zones, there is no change. + + When a zone is split by introducing a cut, the newly created child + must be properly configured. + + However, from the point of view of a child of the splitting zone + which becomes a grandchild or a grandchild that becomes a child due + to joinder, there is a change in parent name. Therefore, in general, + there is a change in parent KEY(s). Unless the entity that handles + rollovers for the zone whose parent name has changed is appropriately + updated, future automated rollover will fail because it will be sent + to the old parent. + + For this reason and so that other consistency checks can be made, the + parent SOA and SIG(SOA) are always included in the Answer section of + rollover NOTIFY requests and in ROLLOVER responsess. For automated + rollover to the new cut or joined state to work, these SOAs must be + signed with old KEY(s) of the former parent so the signatures can be + validated by the zone whose parent name is changing. In the case of + a joinder, if the private key of the pinched out middle zone is not + available, then manual update of the former grandchild, now child, + will be necessary. In the case of introducing a cut, operational + coordination with the former parent, now grandparent, signing the + initial updates to the former child, now grandchild, will be needed + to automate the reconfiguration of the zones. + + + +5. Security Considerations + + The security of ROLLOVER or UPDATE requests is essential, otherwise + false children could steal parental authorization or a false parent + could cause a child to install an invalid signature on its zone key, + etc. + + A ROLLOVER request can be authenticated by request SIG(s)under the + old zone KEY(s) of the requestor [RFC 2535]. The response SHOULD + have transaction SIG(s) under the old zone KEY(s) of the responder. + (This public key security could be used to rollover a zone to the + unsecured state but at that point it would generally not be possible + to roll back without manual intervention.) + + Alternatively, if there is a prior arrangement between a child and a + parent, ROLLOVER requests and responses can be secured and + authenticated using TSIG [draft-ietf-dnsind-tsig-*.txt]. (TSIG + security could be used to rollover a zone to unsecured and to + + +D. Eastlake 3rd, M. Andrews [Page 8] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + + rollover an unsecured zone to the secured state.) + + A server that implements online signing SHOULD have the ability to + black list a zone and force manual processing or demand that a + particular signature be used to generate the ROLLOVER request. This + it to allow ROLLOVER to be used even after a private key has been + compromised. + + + +6. IANA Considerations + + The DNS operation code (TBD) is assigned to ROLLOVER. There are no + other IANA considerations in this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 9] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + +References + + [RFC 1034] - "Domain names - concepts and facilities", P. + Mockapetris, 11/01/1987. + + [RFC 1035] - "Domain names - implementation and specification", P. + Mockapetris, 11/01/1987. + + [RFC 1996] - "A Mechanism for Prompt Notification of Zone Changes + (DNS NOTIFY)", P. Vixie, August 1996. + + [RFC 2119] - "Key words for use in RFCs to Indicate Requirement + Levels", S. Bradner. March 1997. + + [RFC 2136] - "Dynamic Updates in the Domain Name System (DNS + UPDATE)", P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April + 1997. + + [draft-ietf-dnsind-tsig-*.txt] + + [RFC 2535] - "Domain Name System Security Extensions", D. Eastlake. + March 1999. + + [RFC 2541] - "DNS Security Operational Considerations", D. Eastlake. + March 1999. + + + +Authors Address + + Donald E. Eastlake 3rd + IBM + 65 Sindegan Hill Road, RR #1 + Carmel, NY 10512 + + Telephone: +1 914-276-2668 (h) + +1 914-784-7913 (w) + FAX: +1 914-784-3833 (w) + EMail: dee3@us.ibm.com + + + Mark Andrews + Internet Software Consortium + 1 Seymour Street + Dundas Valley, NSW 2117 + AUSTRALIA + + Telephone: +61-2-9871-4742 + Email: marka@isc.org + + + +D. Eastlake 3rd, M. Andrews [Page 10] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + +Expiration and File Name + + This draft expires in October 1999. + + Its file name is draft-ietf-dnsind-rollover-00.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 11] + + diff --git a/doc/draft/draft-ietf-dnsind-simple-secure-update-00.txt b/doc/draft/draft-ietf-dnsind-simple-secure-update-00.txt new file mode 100644 index 0000000000..b22553a976 --- /dev/null +++ b/doc/draft/draft-ietf-dnsind-simple-secure-update-00.txt @@ -0,0 +1,278 @@ + +DNSIND Working Group Brian Wellington (TISLabs) +INTERNET-DRAFT April 1999 + + + +MAY Updates: RFC 2535, RFC 2136, [TSIG] +MAY Replaces: RFC 2137, [update2] + + + + Simple Secure Domain Name System (DNS) Dynamic Update + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + 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.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + This draft proposes an alternative method for performing secure + Domain Name System (DNS) dynamic updates. The method described here + is both simple and flexible enough to represent any policy decisions. + Secure communication based on request/transaction signatures [TSIG] + is used to provide authentication and authorization. + + + + + + + + + +Expires October 1999 [Page 1] + +INTERNET-DRAFT Simple Secure Dynamic Update April 1999 + + +1 - Introduction + +Dynamic update operations for the Domain Name System are defined in +[RFC2136], but no mechanisms for security have been defined. Request +and transaction signatures are defined in [TSIG]. + +Familiarity with the DNS system [RFC1034, RFC1035] as well as the +proposals mentioned above is assumed. Familiarity with DNS Security +[RFC2535] is assumed in section (4). + +1.1 - Overview of DNS Dynamic Update + +DNS dynamic update defines a new DNS opcode and a new interpretation of +the DNS message if that opcode is used. An update can specify +insertions or deletions of data, along with prerequisites necessary for +the updates to occur. All tests and changes for a DNS update request +are restricted to a single zone, and are performed at the primary server +for the zone. The primary server for a dynamic zone must increment the +zone SOA serial number when an update occurs or before the next +retrieval of the SOA. + +1.2 - Overview of DNS Transaction Security + +[TSIG] provides a means for two processes that share a secret key to +authenticate DNS requests and responses sent between them. This is done +by appending TSIG digital signature (keyed hash) RRs to those messages. +Keyed hashes are simple to calculate and verify, and do not require +caching of data. + +2 - Authentication + +TSIG records are attached to all secure dynamic update messages. This +allows the server to verifiably determine the originator of the message. +It can then use this information in the decision of whether to accept +the update. DNSSEC SIG records may be included in an update message, +but MAY NOT be used for authentication purposes in the update protocol. +If a message fails the authentication test due to an unauthorized key, +the failure is indicated with the REFUSED rcode. Other TSIG or dynamic +update errors are returned unchanged. + + + + + + + + + + + + +Expires October 1999 [Page 2] + +INTERNET-DRAFT Simple Secure Dynamic Update April 1999 + + +3 - Policy + +All policy is dictated by the server and is configurable by the zone +administrator. The server's policy defines criteria which determine if +the key used to sign the update is permitted to update the records +requested. By default, a key cannot make any changes to the zone; the +key's scope must be explicitly enabled. There are several reasons that +this process is implemented in the server and not the protocol (as in +[RFC2137, update2], where the signatory bits of KEY records may define +the policy). + +3.1 - Flexibility + +Storing policy in the signatory fields of DNS keys is overly +restrictive. Only a fixed number of bits are present, which means that +only a fixed number of policy decisions are representable. There are +many decisions that do not fit into the framework imposed by the +signatory field; a zone administrator cannot effectively impose a policy +not implemented in the draft defining the field. + +There may be any number of policies applied in the process of +authorization, and there are no restrictions on the scope of these +policies. Implementation of the policies is beyond the scope of this +document. + +3.2 - Simplicity + +Policy decisions in the server could be used as an adjunct to policy +fields in the KEY records. This could lead to confusion if the policies +are inconsistent. Furthermore, since there is no need to expose +policies, a central configuration point is more logical. + +3.3 - Extendibility + +If a policy is changed, there are no changes made to the DNS protocol or +the data on the wire. This means that new policies can be defined at +any point without adverse effects or interoperability concerns. + + + + + + + + + + + + + + +Expires October 1999 [Page 3] + +INTERNET-DRAFT Simple Secure Dynamic Update April 1999 + + +4 - Interaction with DNSSEC + +A successful update request may or may not include SIG records for each +RRset. Since SIG records are not used for authentication in this +protocol, they are not required. If the updated zone is signed, the +server will generate SIG records for each incoming RRset with the Zone +key (which MUST be online). If there are any non-DNSSEC SIG records +present, they are retained. If there are SIG records that have been +generated by the appropriate zone KEY, these SIGs are verified and +retained if the verification is successful. DNSSEC SIG records +generated by other KEYs are dropped. The server will generate SIG +records for each set with the Zone key, unless one has already been +verified. The server will also generate a new SOA record and possibly +new NXT records, and sign these with the Zone key. + +The server MUST update the SOA record and MAY generate new NXT records +when an update is received. Unlike traditional dynamic update, the +client is forbidden from updating SOA 1 NXT records. + +5 - Security considerations + +For a secure zone to support dynamic update, the Zone key MUST be online +(unlike [RFC2137]). No additional protection is offered by having the +Zone key offline and an Update key online, since compromising any key +that can sign the zone's data compromises the zone itself. + +6 - References + +[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' + RFC 1034, ISI, November 1987. + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification,'' RFC 1035, ISI, November 1987. + +[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic + Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore + & Cisco & DEC, April 1997. + +[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC + 2137, CyberCash, April 1997. + +[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC + 2065, IBM, March 1999. + +[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington + ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- + ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs, + February 1999. + + + +Expires October 1999 [Page 4] + +INTERNET-DRAFT Simple Secure Dynamic Update April 1999 + + +[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic + Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite + Systems Company, August 1998. + +7 - Author's Address + + + Brian Wellington + TISLabs at Network Associates + 3060 Washington Road, Route 97 + Glenwood, MD 21738 + +1 443 259 2369 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires October 1999 [Page 5] + diff --git a/doc/draft/draft-ietf-dnssec-tkey-01.txt b/doc/draft/draft-ietf-dnsind-tkey-00.txt similarity index 77% rename from doc/draft/draft-ietf-dnssec-tkey-01.txt rename to doc/draft/draft-ietf-dnsind-tkey-00.txt index 9349a36ab7..1f31086b74 100644 --- a/doc/draft/draft-ietf-dnssec-tkey-01.txt +++ b/doc/draft/draft-ietf-dnsind-tkey-00.txt @@ -1,8 +1,6 @@ - - -DNSSEC Working Group Donald E. Eastlake, 3rd +DNS Working Group Donald E. Eastlake, 3rd INTERNET-DRAFT IBM -Expires: March 1999 September 1998 +Expires: November 1999 May 1999 @@ -15,12 +13,13 @@ Expires: March 1999 September 1998 Status of This Document - This draft, file name draft-ietf-dnssec-tkey-01.txt, is intended to + This draft, file name draft-ietf-dnsind-tkey-00.txt, is intended to be become a Proposed Standard RFC. Distribution of this document is - unlimited. Comments should be sent to the DNS security mailing list - or to the author. + unlimited. Comments should be sent to the DNS working group mailing + list or to the author. - This document is an Internet-Draft. Internet-Drafts are working + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -31,6 +30,12 @@ Status of This Document Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern @@ -54,11 +59,10 @@ Status of This Document - Donald E. Eastlake, 3rd [Page 1] -INTERNET-DRAFT The DNS TKEY RR September 1998 +INTERNET-DRAFT The DNS TKEY RR May 1999 Abstract @@ -71,9 +75,6 @@ Abstract different modes to establish shared secret keys between a DNS resolver and server. - [changes from last draft: add IANA considerations section, make time - fields module 2**32, minor edits, update author info, ...] - Acknowledgments @@ -82,9 +83,12 @@ Acknowledgments in alphabetic order) have been incorporated herein and are gratefully acknowledged: - Olafur Gudmundsson + Olafur Gudmundsson + + Stuart Kwan + + - Stuart Kwan @@ -116,7 +120,7 @@ Acknowledgments Donald E. Eastlake, 3rd [Page 2] -INTERNET-DRAFT The DNS TKEY RR September 1998 +INTERNET-DRAFT The DNS TKEY RR May 1999 Table of Contents @@ -131,34 +135,34 @@ Table of Contents 1. Introduction............................................4 1.1 General Principles.....................................4 1.2 Overview of Contents...................................5 - - 2. The TKEY Resource Record................................6 - - 3. Exchange via Resolver Query.............................8 + 2. The TKEY Resource Record................................5 + 3. Exchange via Resolver Query.............................7 3.1 Query for Server Assigned Keying.......................8 3.2 Query for Diffie-Hellman Exchanged Keying..............9 - 3.3 Query for GSS-API Established.........................10 - - 4. Spontaneous Server Inclusion...........................11 - 4.1 Spontaneous Server Assigned Keying....................11 - 4.2 Spontaneous Diffie-Hellman Keying.....................11 + 3.3 Query for GSS-API Established..........................9 + 4. Spontaneous Server Inclusion...........................10 + 4.1 Spontaneous Server Assigned Keying....................10 + 4.2 Spontaneous Diffie-Hellman Keying.....................10 4.3 Spontaneous GSS-API Exchange..........................11 - 4.4 Spontaneous Key Deletion..............................12 + 4.4 Spontaneous Key Deletion..............................11 + 5. TKEY Dynamic Update Requests...........................11 + 5.1 Exchange via TKEY 'Add'...............................11 + 5.2 TKEY Deletion.........................................12 + 6. Methods of Encryption..................................12 + 7. IANA Considerations....................................13 + 8. Security Considerations................................13 + + References................................................14 + + Author's Address..........................................15 + Expiration and File Name..................................15 + - 5. TKEY Dynamic Update Requests...........................13 - 5.1 Exchange via TKEY 'Add'...............................13 - 5.2 TKEY Deletion.........................................13 - 6. Methods of Encryption..................................14 - 7. IANA Considerations....................................15 - 8. Security Considerations................................16 - References................................................17 - Author's Address..........................................18 - Expiration and File Name..................................18 @@ -174,7 +178,7 @@ Table of Contents Donald E. Eastlake, 3rd [Page 3] -INTERNET-DRAFT The DNS TKEY RR September 1998 +INTERNET-DRAFT The DNS TKEY RR May 1999 1. Introduction @@ -183,8 +187,7 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 available database used for 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 2136, draft-ietf-dnssec-secext2-*.txt, draft- - ietf-dnssec-update2-*.txt]. + dynamic update [RFC 2136, RFC 2535]. [draft-ietf-dnsind-tsig-*.txt] provides a means of more efficiently authenticating and securing DNS messages using shared secret keys via @@ -193,6 +196,10 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 TKEY RR that can be used in a number of different modes to establish such shared secret keys between a DNS resolver and server. + 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]. + 1.1 General Principles @@ -217,29 +224,29 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 experience, in the future more modes may be added or some modes described herein may be deprecated. - The means by which the shared secret keying material exchanged via - TKEY is actually used in any particular TSIG algorithm is algorithm + The means by which the 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. Note that this keying material and TSIGs that use it are associated with DNS hosts. They are not tied to zones. They may be used to authenticate queries and responses but they do not provide zone - stored DNS data origin authentication [draft-ietf-dnssec-secext2- - *.txt]. - Donald E. Eastlake, 3rd [Page 4] -INTERNET-DRAFT The DNS TKEY RR September 1998 +INTERNET-DRAFT The DNS TKEY RR May 1999 + stored DNS data origin authentication [RFC 2535]. + Two modes of TKEY, the server assigned and resolver assigned modes, - perform encryption which may effect their export or inport status for - some countries. All other aspects of DNS security, including the - SIG, KEY, NXT, and TSIG RRs and all other defined modes of TKEY - perform authentication (signatures and signature verification) only. + perform encryption which may effect their export or + import status for some countries. All other aspects of DNS security, + including the SIG, KEY, NXT, and TSIG RRs and all other defined modes + of TKEY perform authentication (signatures and signature + verification) only. @@ -270,13 +277,10 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 +2. The TKEY Resource Record - - - - - - + The TKEY resource record (RR) has the structure given below. Its RR + type code is 249. @@ -290,31 +294,26 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 Donald E. Eastlake, 3rd [Page 5] -INTERNET-DRAFT The DNS TKEY RR September 1998 +INTERNET-DRAFT The DNS TKEY RR May 1999 -2. The TKEY Resource Record + Field Type Comment + ----- ---- ------- - 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 - CLASS u_int16_t ignored, should be zero - TTL u_int32_t SHOULD be zero - RDLEN u_int16_t size of RDATA - RDATA: Algorithhm: 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 protocol + NAME domain see description below + TTYPE u_int16_t TKEY + CLASS u_int16_t ignored, should be zero + TTL u_int32_t 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 protocol The Name field's meaning differs somewhat with mode and context as explained in subsequent sections. @@ -331,12 +330,12 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 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 to a DNS server where these fields are meaningful, they - are the either requested validity interval for the keying material + are either the requested validity interval for the keying material asked for or specify the validity interval of keying material - provided. To avoid reply attack, to keying material used to + provided. To avoid replay attacks, to keying material used to authenticate TKEY keying material MUST NOT have a lifetime of more then 2**31 seconds. This applies to keying material used in either a - TSIG or a SIG(0) transacation or request signature. + TSIG or a SIG(0) transaction or request signature. The mode field specifies the general scheme for key agreement. Note that implementation of TKEY as a whole and of any particular mode is @@ -345,10 +344,15 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 + + + + + Donald E. Eastlake, 3rd [Page 6] -INTERNET-DRAFT The DNS TKEY RR September 1998 +INTERNET-DRAFT The DNS TKEY RR May 1999 Value Description @@ -383,32 +387,6 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 7] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - 3. Exchange via Resolver Query One method for a resolver and a server to establish a shared secret @@ -427,6 +405,14 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 length.) For TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD be a globally unique server assigned domain. If the TKEY in a response is the result of a query containing a TKEY with a non- + + +Donald E. Eastlake, 3rd [Page 7] + + +INTERNET-DRAFT The DNS TKEY RR May 1999 + + root name, that query TKEY name SHOULD be incorporated as the prefix of the response TKEY name. @@ -453,24 +439,16 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 be used in encrypting the response, both in the additional information section. The TKEY algorithm field is set to the signature algorithm the resolver plans to use. It is recommended that any "key - data" provided in the query TKEY be strongly mixed with server - generated randomness [RFC 1750] to derive the keying material to be - used. The KEY that appears in the query SHOULD have a zero TTL. It - need not be accompanied by a SIG(KEY) and if the query is signed by - the resolver host and that signature is verified, then any SIG(KEY) - provided MAY be ignored for key exchange purposes. The KEY RR in - - -Donald E. Eastlake, 3rd [Page 8] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - - such a query SHOULD have a name that corresponds to the resolver host - 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. + data" optionally provided in the query TKEY by the resolver be + strongly mixed with server generated randomness [RFC 1750] to derive + the keying material to be used. The KEY that appears in the query + SHOULD have a zero TTL. It need not be accompanied by a SIG(KEY) and + if the query is signed by the resolver host and that signature is + verified, then any SIG(KEY) provided MAY be ignored for key exchange + purposes. The KEY RR in such a query SHOULD have a name that + corresponds to the resolver host 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. Accepting and responding to an unsigned query of this sort may drain some entropy from an entropy pool being maintained by the server and @@ -485,9 +463,17 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 failed for the reason given. If the error field is zero, the KEY RR provided in the query will be echoed back and the key data portion of the response TKEY RR will be the server assigned keying data - encrypted under the public key in the KEY RR. The name of the TKEY - RR will be the server assigned name of the key and SHOULD be globally - unique. + + +Donald E. Eastlake, 3rd [Page 8] + + +INTERNET-DRAFT The DNS TKEY RR May 1999 + + + encrypted under the public key in the resolver provided KEY RR. The + name of the TKEY RR will be the server assigned name of the key and + SHOULD be globally unique. @@ -496,15 +482,14 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 Diffie-Hellman (DH) key exchange is 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 [draft-ietf-dnssec-dhk- - *.txt]. + for the storage of DH public keys in the DNS [RFC 2539]. A client 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 specifying a client host Diffie-Hellman key. The TKEY algorithm field is set to the signature algorithm the - resolver plans to use and any "key data" provided is ignored by the - server. + resolver plans to use and any "key data" provided in the TKEY is + ignored by the server. Accepting and responding to an unsigned query of this sort may use significant computation at the server; however, if the server @@ -517,18 +502,10 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 Diffie-Hellman mode. If the error field is non-zero, the query failed for the reason given. If the error field is zero, the client host supplied Diffie-Hellman KEY should be echoed back and a server host + Diffie-Hellman KEY RR will also be present in the response. - -Donald E. Eastlake, 3rd [Page 9] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - - Diffie-Hellman KEY RR will also be present. - - Both parties can calculate the same shared secret quantity from the - pair of Diffie-Hellman keys used [Schneier] provided they use the + Both parties can then calculate the same shared secret quantity from + the pair of Diffie-Hellman keys used [Schneier] provided they use the same modulus. If the server host does not have an appropriate Diffie-Hellman key to use for the exchange, it should return the BADKEY error. @@ -544,45 +521,26 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 additional information section and a GSS-API token in the key data portion. The server responds with a TKEY specifying the GSS-API mode and a GSS-API token in the key data portion. The resolver and server - feed these tokens to their local GSS implementation and interate - until an error is encountered or a key (GSS-API session) is - established. A similar exchange can be used to delete a GSS-API - session. + + +Donald E. Eastlake, 3rd [Page 9] + + +INTERNET-DRAFT The DNS TKEY RR May 1999 + + + feed these tokens to their local GSS implementation and iterate until + an error is encountered or a key (GSS-API session) is established. A + similar exchange can be used to delete a GSS-API session. Any issues of possible encryption of the GSS-API token data being transmitted are handled by the GSS-API level. In addition, the GSS- - API level provides authentication so that this mode of TKEY query and - response MAY be, but do not need to be, signed with TSIG or SIG(0). + API level provides its own authentication so that this mode of TKEY + query and response MAY be, but do not need to be, signed with TSIG + or SIG(0). - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 10] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - 4. Spontaneous Server Inclusion A DNS server may include TKEY RRs spontaneously as additional @@ -606,9 +564,9 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 but the KEY RR need not be signed by a SIG(KEY). A server should only do this if there is sufficient room in a query and it has reason to believe the resolver will understand such additional data. The - KEY RR used MUST be one for which the resolver host has the - corresponding private key or it will not be able to decrypt the - keying material. + KEY RR used MUST be one for which it is believed that the resolver + host has the corresponding private key or it will not be able to + decrypt the keying material. @@ -623,6 +581,11 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 host will understand such additional data. +Donald E. Eastlake, 3rd [Page 10] + + +INTERNET-DRAFT The DNS TKEY RR May 1999 + 4.3 Spontaneous GSS-API Exchange @@ -633,14 +596,6 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 response is signed, the signature must verify before processing the data. To the extent that GSS-API provides its own security, such a response may not need to be signed. To the extent that GSS-API - - -Donald E. Eastlake, 3rd [Page 11] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - handles duplicated messages, such a spontaneous TKEY can be sent repeatedly, until, perhaps, a response via a GSS-API mode TKEY query is received. @@ -654,51 +609,15 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 section of a response with the key's name and specifying the key deletion mode. Such a response SHOULD be signed. If authenticated, it deletes all keys with the given name whose effective time period - overlaps the inception to expiration period given in the TKEY. (If - the inception time of one symmetric key is equal to the expiration - time of another, or vice versa, they do not overlap.) Failure by a - client to receive or properly process such additional information in - a response would simply mean that the client might use a key that the - server had discarded and then get an error indication. + overlaps the inception to expiration period given in the deletion + mode TKEY. (If the inception time of one symmetric key is equal to + the expiration time of another, or vice versa, they do not overlap.) + Failure by a client to receive or properly process such additional + information in a response would simply mean that the client might use + a key that the server had discarded and then get an error indication. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 12] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - 5. TKEY Dynamic Update Requests If a DNS server supports dynamic update [RFC 2136], then dynamic @@ -718,6 +637,14 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 the keying data with a KEY RR in the additional information section specifying the server host public key used to encrypt the data. The name of the key and the keying data are completely controlled by the + + +Donald E. Eastlake, 3rd [Page 11] + + +INTERNET-DRAFT The DNS TKEY RR May 1999 + + sending resolver so a globally unique key name SHOULD be used. The server SHOULD require that this request be signed with a TSIG, if there already exists an appropriate shared secret, or a SIG(0) by the @@ -743,80 +670,47 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 for a TKEY with the key's name. The mode and most fields of the TKEY being "deleted" are ignored. But, to allow for the possibility of multiple keys with the same name but different time periods, the only - key deleted are those whose time period overlaps with that specified + keys deleted are those whose time period overlaps with that specified by the inception and expiration in the TKEY being "deleted". - - - -Donald E. Eastlake, 3rd [Page 13] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - 6. Methods of Encryption For the server assigned and resolver assigned key exchange, the keying material is sent within the key data field of a TKEY RR encrypted under the private key corresponding to the public key in an - accompanying KEY RR [draft-ietf-dnssec-secext2-*.txt]. The secret - keying material being send 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. + accompanying KEY RR [RFC 2535]. The secret keying material being + send 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 RSA encryption in PKCS-1. - (Note, the secret keying material being sent is directly RSA - encrypted in PKCS-1 format, It is not "enveloped" under some other + is encrypted as per the description of RSA 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 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 PKCS-1 + block is clear from the public RSA key specified and the PKCS#1 padding makes it clear what part of the encrypted data is actually keying material and what part is formatting or the required at least + + +Donald E. Eastlake, 3rd [Page 12] + + +INTERNET-DRAFT The DNS TKEY RR May 1999 + + eight bytes of random [RFC 1750] padding. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 14] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - 7. IANA Considerations + This section is to be interpreted as provided in [RFC 2434]. + Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF can only be assigned by an IETF standards action excluding Experimental Standards (and 1 through 5 are assigned by this Proposed @@ -824,8 +718,7 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 allocation of meaning for Mode field values 0x0000 and 0xFFFF. Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF - are allocated by an IETF consensus (i.e., at this time, an IESG vote) - excluding Experimental Standards. + are allocated by an IETF consensus excluding Experimental Standards. Mode field values 0x1000 through 0xEFFF are allocated based on RFC documentation of their use or the issuance of an Experimental @@ -838,6 +731,117 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 +8. Security Considerations + + 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 + MUST be done securely. + + It is recommended that the server require TKEY queries be signed. + However, for currently defined modes, relatively little damage will + be done if an unsigned query of this sort is accepted and processed, + as described above, for each mode. In addition, requiring that a TKEY + query be signed by a TSIG (if there exists an acceptable exchanged + key between the parties) or a SIG(0) may itself impose significant + computational requirements on the server, particularly in verifying + SIG(0) public key signatures. + + Responses to TKEY queries SHOULD always have DNS transaction + signatures to protect the integrity of any keying data, error codes, + etc. This signature, if present, MUST use a previously established + secret (TSIG) or public (SIG(0)) key and MUST NOT use any key that + the response to be verified is itself providing. + + +Donald E. Eastlake, 3rd [Page 13] + + +INTERNET-DRAFT The DNS TKEY RR May 1999 + + +References + + RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", + STD 13, November 1987. + + RFC 1035 - P. Mockapetris, "Domain Names - Implementation and + Specifications", STD 13, November 1987. + + RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness + Recommendations for Security", December 1994. + + RFC 1982 - Robert Elz, Randy Bush, "Serial Number Arithmetic", + 09/03/1996. + + RFC 1995 - masataka Ohta, "Incremental Zone Transfer in DNS", August + 1996. + + RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 + for IPv4, IPv6 and OSI", October 1996. + + RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. + + RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs, October 1998. + + RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography + Specifications Version 2.0", October 1998. + + RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", + March 1999. + + RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain + Name System (DNS)", March 1999. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + draft-ietf-dnssec-update2-*.txt - Donald E. Eastlake 3rd, "Secure + Domain Name System Dynamic Update". + + draft-ietf-dnsind-tsig-*.txt - P. Vixie, O. Gudmundsson, D. + Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". + + draft-skwan-gss-tsig-*.txt - S. Kwan, P. Garg, R. Viswanathan, "GSS + Algorithm for TSIG (GSS-TSIG)" + + + +Donald E. Eastlake, 3rd [Page 14] + + +INTERNET-DRAFT The DNS TKEY RR May 1999 + + +Author's Address + + Donald E. Eastlake 3rd + IBM + 65 Shindegan Hill Road, RR #1 + Carmel, NY 10512 USA + + Telephone: +1 914-276-2668 (h) + +1 914-784-7913 (w) + FAX: +1 914-784-3833 (w) + email: dee3@us.ibm.com + + + +Expiration and File Name + + This draft expires November 1999. + + Its file name is draft-ietf-dnsind-tkey-00.txt. + + + + @@ -869,177 +873,3 @@ INTERNET-DRAFT The DNS TKEY RR September 1998 Donald E. Eastlake, 3rd [Page 15] - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -8. Security Considerations - - To avoid different interpretations of the inception and expiration - times in TKEY RRs, resovlers 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 - MUST be done securely. - - It is recommended that the server require TKEY queries be signed. - However, for currently defined modes, relatively little damage will - be done if an unsigned query of this sort is accepted and processed, - as described below for each mode. In addition, requiring that a TKEY - query be signed by a TSIG (if there exists an acceptable exchanged - key between the parties) or a SIG(0) may itself impose significant - computational requirements on the server, particularly in verifying - SIG(0) public key signatures. - - Responses to TKEY queries SHOULD always have DNS transaction - signatures to protect the integrity of any keying data, error codes, - etc. This signature, if present, MUST use a previously established - secret (TSIG) or public (SIG(0)) key and MUST NOT use any key that - the response to be verified is itself providing. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 16] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -References - - PKCS-1 - RSA Encryption Standard (An RSA Laboratories Technical - Note). - - RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", - STD 13, November 1987. - - RFC 1035 - P. Mockapetris, "Domain Names - Implementation and - Specifications", STD 13, November 1987. - - RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness - Recommendations for Security", December 1994. - - RFC 1982 - Robert Elz, Rrandy Bush, "Serial Number Arithmetic", - 09/03/1996. - - RFC 1995 - Masatka Ohta, "Incremental Zone Transfer in DNS", August - 1996. - - RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 - for IPv4, IPv6 and OSI", October 1996. - - RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. - - draft-ietf-dnsind-tsig-*.txt - P. Vixie, O. Gudmundsson, D. - Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". - - draft-ietf-dnssec-dhk-*.txt - D. Eastlake - - draft-ietf-dnssec-update2-*.txt - Donald E. Eastlake 3rd, "Secure - Domain Name System Dynamic Update". - - draft-ietf-dnssec-secext2-*.txt - Donald E. Eastlake 3rd, "Domain - Name System Security Extensions". - - draft-skwan-gss-tsig-*.txt - S. Kwan, P. Garg, R. Viswanathan, "GSS - Algorithm for TSIG (GSS-TSIG)" - - [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C", 1996, John Wiley and Sons - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 17] - - -INTERNET-DRAFT The DNS TKEY RR September 1998 - - -Author's Address - - Donald E. Eastlake 3rd - IBM - 318 Acton Street - Carlisle, MA 01741 USA - - Telephone: +1 978 287 4877 - +1 914 784 7913 - FAX: +1 978 371 7148 - email: dee3@us.ibm.com - - - -Expiration and File Name - - This draft expires March 1999. - - Its file name is draft-ietf-dnssec-tkey-01.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Donald E. Eastlake, 3rd [Page 18] -