diff options
Diffstat (limited to 'doc/rfc/rfc2930.txt')
| -rw-r--r-- | doc/rfc/rfc2930.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc2930.txt b/doc/rfc/rfc2930.txt new file mode 100644 index 0000000..f99573d --- /dev/null +++ b/doc/rfc/rfc2930.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group D. Eastlake, 3rd +Request for Comments: 2930 Motorola +Category: Standards Track September 2000 + + + Secret Key Establishment for DNS (TKEY RR) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + [RFC 2845] provides a means of authenticating Domain Name System + (DNS) queries and responses using shared secret keys via the + Transaction Signature (TSIG) resource record (RR). However, it + provides no mechanism for setting up such keys other than manual + exchange. This document describes a Transaction Key (TKEY) RR that + can be used in a number of different modes to establish shared secret + keys between a DNS resolver and server. + +Acknowledgments + + The comments and ideas of the following persons (listed in alphabetic + order) have been incorporated herein and are gratefully acknowledged: + + Olafur Gudmundsson (TIS) + + Stuart Kwan (Microsoft) + + Ed Lewis (TIS) + + Erik Nordmark (SUN) + + Brian Wellington (Nominum) + + + + + + + + +Eastlake Standards Track [Page 1] + +RFC 2930 The DNS TKEY RR September 2000 + + +Table of Contents + + 1. Introduction............................................... 2 + 1.1 Overview of Contents...................................... 3 + 2. The TKEY Resource Record................................... 4 + 2.1 The Name Field............................................ 4 + 2.2 The TTL Field............................................. 5 + 2.3 The Algorithm Field....................................... 5 + 2.4 The Inception and Expiration Fields....................... 5 + 2.5 The Mode Field............................................ 5 + 2.6 The Error Field........................................... 6 + 2.7 The Key Size and Data Fields.............................. 6 + 2.8 The Other Size and Data Fields............................ 6 + 3. General TKEY Considerations................................ 7 + 4. Exchange via Resolver Query................................ 8 + 4.1 Query for Diffie-Hellman Exchanged Keying................. 8 + 4.2 Query for TKEY Deletion................................... 9 + 4.3 Query for GSS-API Establishment........................... 10 + 4.4 Query for Server Assigned Keying.......................... 10 + 4.5 Query for Resolver Assigned Keying........................ 11 + 5. Spontaneous Server Inclusion............................... 12 + 5.1 Spontaneous Server Key Deletion........................... 12 + 6. Methods of Encryption...................................... 12 + 7. IANA Considerations........................................ 13 + 8. Security Considerations.................................... 13 + References.................................................... 14 + Author's Address.............................................. 15 + Full Copyright Statement...................................... 16 + +1. Introduction + + The Domain Name System (DNS) is a hierarchical, distributed, highly + available database used for bi-directional mapping between domain + names and addresses, for email routing, and for other information + [RFC 1034, 1035]. It has been extended to provide for public key + security and dynamic update [RFC 2535, RFC 2136]. Familiarity with + these RFCs is assumed. + + [RFC 2845] provides a means of efficiently authenticating DNS + messages using shared secret keys via the TSIG resource record (RR) + but provides no mechanism for setting up such keys other than manual + exchange. This document specifies a TKEY RR that can be used in a + number of different modes to establish and delete such shared secret + keys between a DNS resolver and server. + + + + + + + +Eastlake Standards Track [Page 2] + +RFC 2930 The DNS TKEY RR September 2000 + + + Note that TKEY established keying material and TSIGs that use it are + associated with DNS servers or resolvers. They are not associated + with zones. They may be used to authenticate queries and responses + but they do not provide zone based DNS data origin or denial + authentication [RFC 2535]. + + Certain modes of TKEY perform encryption which may affect their + export or import status for some countries. The affected modes + specified in this document are the server assigned mode and the + resolver assigned mode. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + + In all cases herein, the term "resolver" includes that part of a + server which may make full and incremental [RFC 1995] zone transfer + queries, forwards recursive queries, etc. + +1.1 Overview of Contents + + Section 2 below specifies the TKEY RR and provides a description of + and considerations for its constituent fields. + + Section 3 describes general principles of operations with TKEY. + + Section 4 discusses key agreement and deletion via DNS requests with + the Query opcode for RR type TKEY. This method is applicable to all + currently defined TKEY modes, although in some cases it is not what + would intuitively be called a "query". + + Section 5 discusses spontaneous inclusion of TKEY RRs in responses by + servers which is currently used only for key deletion. + + Section 6 describes encryption methods for transmitting secret key + information. In this document these are used only for the server + assigned mode and the resolver assigned mode. + + Section 7 covers IANA considerations in assignment of TKEY modes. + + Finally, Section 8 provides the required security considerations + section. + + + + + + + + + +Eastlake Standards Track [Page 3] + +RFC 2930 The DNS TKEY RR September 2000 + + +2. The TKEY Resource Record + + The TKEY resource record (RR) has the structure given below. Its RR + type code is 249. + + Field Type Comment + ----- ---- ------- + + NAME domain see description below + TTYPE u_int16_t TKEY = 249 + CLASS u_int16_t ignored, SHOULD be 255 (ANY) + TTL u_int32_t ignored, SHOULD be zero + RDLEN u_int16_t size of RDATA + RDATA: + Algorithm: domain + Inception: u_int32_t + Expiration: u_int32_t + Mode: u_int16_t + Error: u_int16_t + Key Size: u_int16_t + Key Data: octet-stream + Other Size: u_int16_t + Other Data: octet-stream undefined by this specification + +2.1 The Name Field + + The Name field relates to naming keys. Its meaning differs somewhat + with mode and context as explained in subsequent sections. + + At any DNS server or resolver only one octet string of keying + material may be in place for any particular key name. An attempt to + establish another set of keying material at a server for an existing + name returns a BADNAME error. + + For a TKEY with a non-root name appearing in a query, the TKEY RR + name SHOULD be a domain locally unique at the resolver, less than 128 + octets long in wire encoding, and meaningful to the resolver to + assist in distinguishing keys and/or key agreement sessions. For + TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD + be a globally unique server assigned domain. + + A reasonable key naming strategy is as follows: + + If the key is generated as the result of a query with root as its + owner name, then the server SHOULD create a globally unique domain + name, to be the key name, by suffixing a pseudo-random [RFC 1750] + label with a domain name of the server. For example + 89n3mDgX072pp.server1.example.com. If generation of a new + + + +Eastlake Standards Track [Page 4] + +RFC 2930 The DNS TKEY RR September 2000 + + + pseudo-random name in each case is an excessive computation load + or entropy drain, a serial number prefix can be added to a fixed + pseudo-random name generated an DNS server start time, such as + 1001.89n3mDgX072pp.server1.example.com. + + If the key is generated as the result of a query with a non-root + name, say 789.resolver.example.net, then use the concatenation of + that with a name of the server. For example + 789.resolver.example.net.server1.example.com. + +2.2 The TTL Field + + The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to + be sure that older DNS implementations do not cache TKEY RRs. + +2.3 The Algorithm Field + + The algorithm name is in the form of a domain name with the same + meaning as in [RFC 2845]. The algorithm determines how the secret + keying material agreed to using the TKEY RR is actually used to + derive the algorithm specific key. + +2.4 The Inception and Expiration Fields + + The inception time and expiration times are in number of seconds + since the beginning of 1 January 1970 GMT ignoring leap seconds + treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages + between a DNS resolver and a DNS server where these fields are + meaningful, they are either the requested validity interval for the + keying material asked for or specify the validity interval of keying + material provided. + + To avoid different interpretations of the inception and expiration + times in TKEY RRs, resolvers and servers exchanging them must have + the same idea of what time it is. One way of doing this is with the + NTP protocol [RFC 2030] but that or any other time synchronization + used for this purpose MUST be done securely. + +2.5 The Mode Field + + The mode field specifies the general scheme for key agreement or the + purpose of the TKEY DNS message. Servers and resolvers supporting + this specification MUST implement the Diffie-Hellman key agreement + mode and the key deletion mode for queries. All other modes are + OPTIONAL. A server supporting TKEY that receives a TKEY request with + a mode it does not support returns the BADMODE error. The following + values of the Mode octet are defined, available, or reserved: + + + + +Eastlake Standards Track [Page 5] + +RFC 2930 The DNS TKEY RR September 2000 + + + Value Description + ----- ----------- + 0 - reserved, see section 7 + 1 server assignment + 2 Diffie-Hellman exchange + 3 GSS-API negotiation + 4 resolver assignment + 5 key deletion + 6-65534 - available, see section 7 + 65535 - reserved, see section 7 + +2.6 The Error Field + + The error code field is an extended RCODE. The following values are + defined: + + Value Description + ----- ----------- + 0 - no error + 1-15 a non-extended RCODE + 16 BADSIG (TSIG) + 17 BADKEY (TSIG) + 18 BADTIME (TSIG) + 19 BADMODE + 20 BADNAME + 21 BADALG + + When the TKEY Error Field is non-zero in a response to a TKEY query, + the DNS header RCODE field indicates no error. However, it is + possible if a TKEY is spontaneously included in a response the TKEY + RR and DNS header error field could have unrelated non-zero error + codes. + +2.7 The Key Size and Data Fields + + The key data size field is an unsigned 16 bit integer in network + order which specifies the size of the key exchange data field in + octets. The meaning of this data depends on the mode. + +2.8 The Other Size and Data Fields + + The Other Size and Other Data fields are not used in this + specification but may be used in future extensions. The RDLEN field + MUST equal the length of the RDATA section through the end of Other + Data or the RR is to be considered malformed and rejected. + + + + + + +Eastlake Standards Track [Page 6] + +RFC 2930 The DNS TKEY RR September 2000 + + +3. General TKEY Considerations + + TKEY is a meta-RR that is not stored or cached in the DNS and does + not appear in zone files. It supports a variety of modes for the + establishment and deletion of shared secret keys information between + DNS resolvers and servers. The establishment of such a shared key + requires that state be maintained at both ends and the allocation of + the resources to maintain such state may require mutual agreement. In + the absence of willingness to provide such state, servers MUST return + errors such as NOTIMP or REFUSED for an attempt to use TKEY and + resolvers are free to ignore any TKEY RRs they receive. + + The shared secret keying material developed by using TKEY is a plain + octet sequence. The means by which this shared secret keying + material, exchanged via TKEY, is actually used in any particular TSIG + algorithm is algorithm dependent and is defined in connection with + that algorithm. For example, see [RFC 2104] for how TKEY agreed + shared secret keying material is used in the HMAC-MD5 algorithm or + other HMAC algorithms. + + There MUST NOT be more than one TKEY RR in a DNS query or response. + + Except for GSS-API mode, TKEY responses MUST always have DNS + transaction authentication to protect the integrity of any keying + data, error codes, etc. This authentication MUST use a previously + established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST + NOT use any key that the response to be verified is itself providing. + + TKEY queries MUST be authenticated for all modes except GSS-API and, + under some circumstances, server assignment mode. In particular, if + the query for a server assigned key is for a key to assert some + privilege, such as update authority, then the query must be + authenticated to avoid spoofing. However, if the key is just to be + used for transaction security, then spoofing will lead at worst to + denial of service. Query authentication SHOULD use an established + secret (TSIG) key authenticator if available. Otherwise, it must use + a public (SIG(0)) key signature. It MUST NOT use any key that the + query is itself providing. + + In the absence of required TKEY authentication, a NOTAUTH error MUST + be returned. + + To avoid replay attacks, it is necessary that a TKEY response or + query not be valid if replayed on the order of 2**32 second (about + 136 years), or a multiple thereof, later. To accomplish this, the + keying material used in any TSIG or SIG(0) RR that authenticates a + TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds + + + + +Eastlake Standards Track [Page 7] + +RFC 2930 The DNS TKEY RR September 2000 + + + (about 68 years). Thus, on attempted replay, the authenticating TSIG + or SIG(0) RR will not be verifiable due to key expiration and the + replay will fail. + +4. Exchange via Resolver Query + + One method for a resolver and a server to agree about shared secret + keying material for use in TSIG is through DNS requests from the + resolver which are syntactically DNS queries for type TKEY. Such + queries MUST be accompanied by a TKEY RR in the additional + information section to indicate the mode in use and accompanied by + other information where required. + + Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY + ignore the recursive header bit in TKEY queries they receive. + +4.1 Query for Diffie-Hellman Exchanged Keying + + Diffie-Hellman (DH) key exchange is a means whereby two parties can + derive some shared secret information without requiring any secrecy + of the messages they exchange [Schneier]. Provisions have been made + for the storage of DH public keys in the DNS [RFC 2539]. + + A resolver sends a query for type TKEY accompanied by a TKEY RR in + the additional information section specifying the Diffie-Hellman mode + and accompanied by a KEY RR also in the additional information + section specifying a resolver Diffie-Hellman key. The TKEY RR + algorithm field is set to the authentication algorithm the resolver + plans to use. The "key data" provided in the TKEY is used as a random + [RFC 1750] nonce to avoid always deriving the same keying material + for the same pair of DH KEYs. + + The server response contains a TKEY in its answer section with the + Diffie-Hellman mode. The "key data" provided in this TKEY is used as + an additional nonce to avoid always deriving the same keying material + for the same pair of DH KEYs. If the TKEY error field is non-zero, + the query failed for the reason given. FORMERR is given if the query + included no DH KEY and BADKEY is given if the query included an + incompatible DH KEY. + + If the TKEY error field is zero, the resolver supplied Diffie-Hellman + KEY RR SHOULD be echoed in the additional information section and a + server Diffie-Hellman KEY RR will also be present in the answer + section of the response. Both parties can then calculate the same + shared secret quantity from the pair of Diffie-Hellman (DH) keys used + [Schneier] (provided these DH keys use the same generator and + modulus) and the data in the TKEY RRs. The TKEY RR data is mixed + with the DH result as follows: + + + +Eastlake Standards Track [Page 8] + +RFC 2930 The DNS TKEY RR September 2000 + + + keying material = + XOR ( DH value, MD5 ( query data | DH value ) | + MD5 ( server data | DH value ) ) + + Where XOR is an exclusive-OR operation and "|" is byte-stream + concatenation. The shorter of the two operands to XOR is byte-wise + left justified and padded with zero-valued bytes to match the length + of the other operand. "DH value" is the Diffie-Hellman value derived + from the KEY RRs. Query data and server data are the values sent in + the TKEY RR data fields. These "query data" and "server data" nonces + are suffixed by the DH value, digested by MD5, the results + concatenated, and then XORed with the DH value. + + The inception and expiry times in the query TKEY RR are those + requested for the keying material. The inception and expiry times in + the response TKEY RR are the maximum period the server will consider + the keying material valid. Servers may pre-expire keys so this is + not a guarantee. + +4.2 Query for TKEY Deletion + + Keys established via TKEY can be treated as soft state. Since DNS + transactions are originated by the resolver, the resolver can simply + toss keys, although it may have to go through another key exchange if + it later needs one. Similarly, the server can discard keys although + that will result in an error on receiving a query with a TSIG using + the discarded key. + + To avoid attempted reliance in requests on keys no longer in effect, + servers MUST implement key deletion whereby the server "discards" a + key on receipt from a resolver of an authenticated delete request for + a TKEY RR with the key's name. If the server has no record of a key + with that name, it returns BADNAME. + + Key deletion TKEY queries MUST be authenticated. This authentication + MAY be a TSIG RR using the key to be deleted. + + For querier assigned and Diffie-Hellman keys, the server MUST truly + "discard" all active state associated with the key. For server + assigned keys, the server MAY simply mark the key as no longer + retained by the client and may re-send it in response to a future + query for server assigned keying material. + + + + + + + + + +Eastlake Standards Track [Page 9] + +RFC 2930 The DNS TKEY RR September 2000 + + +4.3 Query for GSS-API Establishment + + This mode is described in a separate document under preparation which + should be seen for the full description. Basically the resolver and + server can exchange queries and responses for type TKEY with a TKEY + RR specifying the GSS-API mode in the additional information section + and a GSS-API token in the key data portion of the TKEY RR. + + Any issues of possible encryption of parts the GSS-API token data + being transmitted are handled by the GSS-API level. In addition, the + GSS-API level provides its own authentication so that this mode of + TKEY query and response MAY be, but do not need to be, authenticated + with TSIG RR or SIG(0) RR [RFC 2931]. + + The inception and expiry times in a GSS-API mode TKEY RR are ignored. + +4.4 Query for Server Assigned Keying + + Optionally, the server can assign keying for the resolver. It is + sent to the resolver encrypted under a resolver public key. See + section 6 for description of encryption methods. + + A resolver sends a query for type TKEY accompanied by a TKEY RR + specifying the "server assignment" mode and a resolver KEY RR to be + used in encrypting the response, both in the additional information + section. The TKEY algorithm field is set to the authentication + algorithm the resolver plans to use. It is RECOMMENDED that any "key + data" provided in the query TKEY RR by the resolver be strongly mixed + by the server with server generated randomness [RFC 1750] to derive + the keying material to be used. The KEY RR that appears in the query + need not be accompanied by a SIG(KEY) RR. If the query is + authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR + and that authentication is verified, then any SIG(KEY) provided in + the query SHOULD be ignored. The KEY RR in such a query SHOULD have + a name that corresponds to the resolver but it is only essential that + it be a public key for which the resolver has the corresponding + private key so it can decrypt the response data. + + The server response contains a TKEY RR in its answer section with the + server assigned mode and echoes the KEY RR provided in the query in + its additional information section. + + If the response TKEY error field is zero, the key data portion of the + response TKEY RR will be the server assigned keying data encrypted + under the public key in the resolver provided KEY RR. In this case, + the owner name of the answer TKEY RR will be the server assigned name + of the key. + + + + +Eastlake Standards Track [Page 10] + +RFC 2930 The DNS TKEY RR September 2000 + + + If the error field of the response TKEY is non-zero, the query failed + for the reason given. FORMERR is given if the query specified no + encryption key. + + The inception and expiry times in the query TKEY RR are those + requested for the keying material. The inception and expiry times in + the response TKEY are the maximum period the server will consider the + keying material valid. Servers may pre-expire keys so this is not a + guarantee. + + The resolver KEY RR MUST be authenticated, through the authentication + of this query with a TSIG or SIG(0) or the signing of the resolver + KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY + for which they know the private key, and thereby the attacker could + obtain a valid shared secret key from the server. + +4.5 Query for Resolver Assigned Keying + + Optionally, a server can accept resolver assigned keys. The keying + material MUST be encrypted under a server key for protection in + transmission as described in Section 6. + + The resolver sends a TKEY query with a TKEY RR that specifies the + encrypted keying material and a KEY RR specifying the server public + key used to encrypt the data, both in the additional information + section. The name of the key and the keying data are completely + controlled by the sending resolver so a globally unique key name + SHOULD be used. The KEY RR used MUST be one for which the server has + the corresponding private key, or it will not be able to decrypt the + keying material and will return a FORMERR. It is also important that + no untrusted party (preferably no other party than the server) has + the private key corresponding to the KEY RR because, if they do, they + can capture the messages to the server, learn the shared secret, and + spoof valid TSIGs. + + The query TKEY RR inception and expiry give the time period the + querier intends to consider the keying material valid. The server + can return a lesser time interval to advise that it will not maintain + state for that long and can pre-expire keys in any case. + + This mode of query MUST be authenticated with a TSIG or SIG(0). + Otherwise, an attacker can forge a resolver assigned TKEY query, and + thereby the attacker could specify a shared secret key that would be + accepted, used, and honored by the server. + + + + + + + +Eastlake Standards Track [Page 11] + +RFC 2930 The DNS TKEY RR September 2000 + + +5. Spontaneous Server Inclusion + + A DNS server may include a TKEY RR spontaneously as additional + information in responses. This SHOULD only be done if the server + knows the querier understands TKEY and has this option implemented. + This technique can be used to delete a key and may be specified for + modes defined in the future. A disadvantage of this technique is + that there is no way for the server to get any error or success + indication back and, in the case of UDP, no way to even know if the + DNS response reached the resolver. + +5.1 Spontaneous Server Key Deletion + + A server can optionally tell a client that it has deleted a secret + key by spontaneously including a TKEY RR in the additional + information section of a response with the key's name and specifying + the key deletion mode. Such a response SHOULD be authenticated. If + authenticated, it "deletes" the key with the given name. The + inception and expiry times of the delete TKEY RR are ignored. Failure + by a client to receive or properly process such additional + information in a response would mean that the client might use a key + that the server had discarded and would then get an error indication. + + For server assigned and Diffie-Hellman keys, the client MUST + "discard" active state associated with the key. For querier assigned + keys, the querier MAY simply mark the key as no longer retained by + the server and may re-send it in a future query specifying querier + assigned keying material. + +6. Methods of Encryption + + For the server assigned and resolver assigned key agreement modes, + the keying material is sent within the key data field of a TKEY RR + encrypted under the public key in an accompanying KEY RR [RFC 2535]. + This KEY RR MUST be for a public key algorithm where the public and + private keys can be used for encryption and the corresponding + decryption which recovers the originally encrypted data. The KEY RR + SHOULD correspond to a name for the decrypting resolver/server such + that the decrypting process has access to the corresponding private + key to decrypt the data. The secret keying material being sent will + generally be fairly short, usually less than 256 bits, because that + is adequate for very strong protection with modern keyed hash or + symmetric algorithms. + + If the KEY RR specifies the RSA algorithm, then the keying material + is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in + PKCS#1 [RFC 2437]. (Note, the secret keying material being sent is + directly RSA encrypted in PKCS#1 format. It is not "enveloped" under + + + +Eastlake Standards Track [Page 12] + +RFC 2930 The DNS TKEY RR September 2000 + + + some other symmetric algorithm.) In the unlikely event that the + keying material will not fit within one RSA modulus of the chosen + public key, additional RSA encryption blocks are included. The + length of each block is clear from the public RSA key specified and + the RSAES-PKCS1-v1_5 padding makes it clear what part of the + encrypted data is actually keying material and what part is + formatting or the required at least eight bytes of random [RFC 1750] + padding. + +7. IANA Considerations + + This section is to be interpreted as provided in [RFC 2434]. + + Mode field values 0x0000 and 0xFFFF are reserved. + + Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE + can only be assigned by an IETF Standards Action. + + Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF + are allocated by IESG approval or IETF consensus. + + Mode field values 0x1000 through 0xEFFF are allocated based on + Specification Required as defined in [RFC 2434]. + + Mode values should not be changed when the status of their use + changes. For example, a mode value assigned based just on providing + a specification should not be changed later just because that use's + status is changed to standards track. + + The following assignments are documented herein: + + RR Type 249 for TKEY. + + TKEY Modes 1 through 5 as listed in section 2.5. + + Extended RCODE Error values of 19, 20, and 21 as listed in section + 2.6. + +8. Security Considerations + + The entirety of this specification is concerned with the secure + establishment of a shared secret between DNS clients and servers in + support of TSIG [RFC 2845]. + + Protection against denial of service via the use of TKEY is not + provided. + + + + + +Eastlake Standards Track [Page 13] + +RFC 2930 The DNS TKEY RR September 2000 + + +References + + [Schneier] Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and + Sons + + [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC 1035] Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + September 1996. + + [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 + for IPv4, IPv6 and OSI", RFC 2030, October 1996. + + [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography + Specifications Version 2.0", RFC 2437, October 1998. + + [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + + + +Eastlake Standards Track [Page 14] + +RFC 2930 The DNS TKEY RR September 2000 + + + [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s )", RFC 2931, September 2000. + +Author's Address + + Donald E. Eastlake 3rd + Motorola + 140 Forest Avenue + Hudson, MA 01749 USA + + Phone: +1 978-562-2827 (h) + +1 508-261-5434 (w) + Fax: +1 508-261-4447 (w) + EMail: Donald.Eastlake@motorola.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 15] + +RFC 2930 The DNS TKEY RR September 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Eastlake Standards Track [Page 16] + |