idnits 2.17.1 draft-ietf-dnsext-tkey-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 178 has weird spacing: '...-stream undef...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2000) is 8779 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 1034' is mentioned on line 102, but not defined -- Looks like a reference, but probably isn't: '1035' on line 102 == Missing Reference: 'RFC 2535' is mentioned on line 573, but not defined ** Obsolete undefined reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Missing Reference: 'RFC 2136' is mentioned on line 103, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 127, but not defined == Missing Reference: 'RFC 1995' is mentioned on line 129, but not defined == Missing Reference: 'RFC 1750' is mentioned on line 594, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Missing Reference: 'RFC 1982' is mentioned on line 230, but not defined == Missing Reference: 'RFC 2030' is mentioned on line 239, but not defined ** Obsolete undefined reference: RFC 2030 (Obsoleted by RFC 4330) == Missing Reference: 'RFC 2104' is mentioned on line 314, but not defined == Missing Reference: 'RFC 2539' is mentioned on line 363, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 609, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSEXT Working Group Donald E. Eastlake, 3rd 2 INTERNET-DRAFT Motorola 3 Expires: September 2000 March 2000 5 Secret Key Establishment for DNS (TKEY RR) 6 ------ --- ------------- --- --- ----- --- 7 draft-ietf-dnsext-tkey-01.txt 9 Donald E. Eastlake 3rd 11 Status of This Document 13 This draft, file name draft-ietf-dnsext-tkey-01.txt, is intended to 14 be become a Proposed Standard RFC. Distribution of this document is 15 unlimited. Comments should be sent to the DNS working group mailing 16 list or to the author. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 [draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of 38 authenticating Domain Name System (DNS) queries and responses using 39 shared secret keys via the TSIG resource record (RR). However, it 40 provides no mechanism for setting up such keys other than manual 41 exchange. This document describes a TKEY RR that can be used in a 42 number of different modes to establish shared secret keys between a 43 DNS resolver and server. 45 Acknowledgments 47 The comments and ideas of the following persons (listed in alphabetic 48 order) have been incorporated herein and are gratefully acknowledged: 50 Olafur Gudmundsson (TIS) 52 Stuart Kwan (Microsoft) 54 Ed Lewis (TIS) 56 Brian Wellington (TIS) 58 Table of Contents 60 Status of This Document....................................1 62 Abstract...................................................2 63 Acknowledgments............................................2 65 Table of Contents..........................................3 67 1. Introduction............................................4 68 1.1 Overview of Contents...................................4 69 2. The TKEY Resource Record................................5 70 2.1 The Name Field.........................................5 71 2.2 The TTL Field..........................................6 72 2.3 The Algorithm Field....................................6 73 2.4 The Inception and Expiration Fields....................6 74 2.5 The Mode Field.........................................7 75 2.6 The Error Field........................................7 76 2.7 The Key Size and Data Fields...........................8 77 2.8 The Other Size and Data Fields.........................8 78 3. General TKEY Considerations.............................8 79 4. Exchange via Resolver Query.............................9 80 4.1 Query for Diffie-Hellman Exchanged Keying..............9 81 4.2 Query for TKEY Deletion...............................10 82 4.3 Query for GSS-API Establishment.......................11 83 4.4 Query for Server Assigned Keying......................11 84 4.5 Query for Resolver Assigned Keying....................12 85 5. Spontaneous Server Inclusion...........................13 86 5.1 Spontaneous Server Key Deletion.......................13 87 5.2 Spontaneous GSS-API Exchange..........................14 88 6. Methods of Encryption..................................14 89 7. IANA Considerations....................................14 90 8. Security Considerations................................15 92 References................................................16 94 Author's Address..........................................17 95 Expiration and File Name..................................17 97 1. Introduction 99 The Domain Name System (DNS) is a hierarchical, distributed, highly 100 available database used for bi-directional mapping between domain 101 names and addresses, for email routing, and for other information 102 [RFC 1034, 1035]. It has been extended to provide for public key 103 security and dynamic update [RFC 2535, RFC 2136]. Familiarity with 104 these RFCs is assumed. 106 [draft-ietf-{dnsind|dnsext}-tsig-*.txt] provides a means of 107 efficiently authenticating DNS messages using shared secret keys via 108 the TSIG resource record (RR) but provides no mechanism for setting 109 up such keys other than manual exchange. This document specifies a 110 TKEY RR that can be used in a number of different modes to establish 111 and delete such shared secret keys between a DNS resolver and server. 113 Note that TKEY established keying material and TSIGs that use it are 114 associated with DNS servers or resolvers. They are not associated 115 with zones. They may be used to authenticate queries and responses 116 but they do not provide zone based DNS data origin or denial 117 authentication [RFC 2535]. 119 Certain modes of TKEY perform encryption which may affect their 120 export or import status for some countries. The affected modes 121 specified in this document are the server assigned mode and the 122 resolver assigned mode. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC 2119]. 128 In all cases herein, the term "resolver" includes that part of a 129 server which may make full and incremental [RFC 1995] zone transfer 130 queries, forwards recursive queries, etc. 132 1.1 Overview of Contents 134 Section 2 below specifies the TKEY RR and provides a description of 135 and considerations for its constituent fields. 137 Section 3 describes general principles of operations with TKEY. 139 Section 4 discusses key agreement and deletion via DNS requests with 140 the Query opcode for RR type TKEY. This method is applicable to all 141 currently defined TKEY modes, although in some cases it is not what 142 would intuitively be called a "query". 144 Section 5 discusses spontaneous inclusion of TKEY RRs in responses by 145 servers. 147 Section 6 describes encryption methods for transmitting secret key 148 information. In this document these are used only for the server 149 assigned mode and the resolver assigned mode. 151 Section 7 covers IANA considerations in assignment of TKEY modes. 153 Finally, Section 8 provides the required security considerations 154 section. 156 2. The TKEY Resource Record 158 The TKEY resource record (RR) has the structure given below. Its RR 159 type code is 249. 161 Field Type Comment 162 ----- ---- ------- 164 NAME domain see description below 165 TTYPE u_int16_t TKEY = 249 166 CLASS u_int16_t ignored, SHOULD be 255 (ANY) 167 TTL u_int32_t ignored, SHOULD be zero 168 RDLEN u_int16_t size of RDATA 169 RDATA: 170 Algorithm: domain 171 Inception: u_int32_t 172 Expiration: u_int32_t 173 Mode: u_int16_t 174 Error: u_int16_t 175 Key Size: u_int16_t 176 Key Data: octet-stream 177 Other Size: u_int16_t 178 Other Data: octet-stream undefined by this specification 180 2.1 The Name Field 182 The Name field relates to naming keys. Its meaning differs somewhat 183 with mode and context as explained in subsequent sections. 185 At any DNS server or resolver only one octet string of keying 186 material may be in place for any particular key name. An attempt to 187 establish another set of keying material at a server for an existing 188 name returns a BADNAME error. 190 For a TKEY with a non-root name appearing in a query, the TKEY RR 191 name SHOULD be a domain locally unique at the resolver, less than 128 192 octets long in wire encoding, and meaningful to the resolver to 193 assist in distinguishing keys and/or key agreement sessions. For 194 TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD 195 be a globally unique server assigned domain. 197 A reasonable key naming strategy is as follows: 199 If the key is generated as the result of a query with root as 200 its owner name, then the server SHOULD create a globally unique 201 domain name, to be the key name, by suffixing a pseudo-random 202 [RFC 1750] label with a domain name of the server. For example 203 89n3mDgX072pp.server.example.com. If generation of a new 204 pseudo-random name in each case is an excessive computation load 205 or entropy drain, a serial number prefix can be added to a fixed 206 pseudo-random name generated an DNS server start time, such as 207 1001.89n3mDgX072pp.server.example.com. 209 If the key is generated as the result of a query with a non-root 210 name, say 789.resolver.example.net, then use the concatenation 211 of that with a name of the server. For example 212 789.resolver.example.net.server.example.com. 214 2.2 The TTL Field 216 The TTL field is meaningless. It SHOULD always be zero to be sure 217 that older DNS implementations do not cache TKEY RRs. 219 2.3 The Algorithm Field 221 The algorithm name is in the form of a domain name with the same 222 meaning as in [draft-ietf-{dnsind|dnsext}-tsig-*.txt]. The algorithm 223 determines how the secret keying material agreed to using the TKEY RR 224 is actually used to derive the algorithm specific key. 226 2.4 The Inception and Expiration Fields 228 The inception time and expiration times are in number of seconds 229 since the beginning of 1 January 1970 GMT ignoring leap seconds 230 treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages 231 between a DNS resolver and a DNS server where these fields are 232 meaningful, they are either the requested validity interval for the 233 keying material asked for or specify the validity interval of keying 234 material provided. 236 To avoid different interpretations of the inception and expiration 237 times in TKEY RRs, resolvers and servers exchanging them must have 238 the same idea of what time it is. One way of doing this is with the 239 NTP protocol [RFC 2030] but that or any other time synchronization 240 used for this purpose MUST be done securely. 242 2.5 The Mode Field 244 The mode field specifies the general scheme for key agreement or the 245 purpose of the TKEY DNS message. Servers and resolvers supporting 246 this specification MUST implement the Diffie-Hellman key agreement 247 mode and the key deletion mode for queries. All other modes are 248 OPTIONAL. A server supporting TKEY that receives a TKEY request with 249 a mode it does not support returns the BADMODE error. The following 250 values of the Mode octet are defined, available, or reserved: 252 Value Description 253 ----- ----------- 254 0 - reserved, see section 7 255 1 server assignment 256 2 Diffie-Hellman exchange 257 3 GSS-API negotiation 258 4 resolver assignment 259 5 key deletion 260 6-65534 - available, see section 7 261 65535 - reserved, see section 7 263 2.6 The Error Field 265 The error code field is an extended RCODE. The following values are 266 defined: 268 Value Description 269 ----- ----------- 270 0 - no error 271 1-15 a non-extended RCODE 272 16 BADSIG (tsig) 273 17 BADKEY (tsig) 274 18 BADTIME (tsig) 275 19 BADMODE 276 20 BADNAME 277 21 BADALG 279 When the TKEY Error Field is non-zero in a response to a TKEY query, 280 the DNS header RCODE field indicates no error. However, it is 281 possible if a TKEY is spontaneously included in a response the TKEY 282 RR and DNS header error field could have unrelated non-zero error 283 codes. 285 2.7 The Key Size and Data Fields 287 The key data size field is an unsigned 16 bit integer in network 288 order which specifies the size of the key exchange data field in 289 octets. The meaning of the key data depends on the mode. 291 2.8 The Other Size and Data Fields 293 The Other Size and Other Data fields are not used in this 294 specification but may be used in future extensions. The RDLEN field 295 MUST equal the length of the RDATA section through the end of Other 296 Data or the RR is to be considered malformed and rejected. 298 3. General TKEY Considerations 300 TKEY is a meta-RR that is not stored or cached in the DNS and does 301 not appear in zone files. It supports a variety of modes for the 302 establishment and deletion of shared secret keys information between 303 DNS resolvers and servers. The establishment of such a shared key 304 requires that state be maintained at both ends and the allocation of 305 the resources to maintain such state may require mutual agreement. In 306 the absence of willingness to provide such state, servers MUST return 307 errors such as NOTIMP or REFUSED for an attempt to use TKEY and 308 resolvers are free to ignore any TKEY RRs they receive. 310 The shared secret keying material developed by using TKEY is a plain 311 octet sequence. The means by which this shared secret keying 312 material, exchanged via TKEY, is actually used in any particular TSIG 313 algorithm is algorithm dependent and is defined in connection with 314 that algorithm. For example, see [RFC 2104] for how TKEY agreed 315 shared secret keying material is used in the HMAC-MD5 algorithm or 316 other HMAC algorithms. 318 There MUST NOT be more than one TKEY RR in a DNS query or response. 320 Except for GSS-API mode, TKEY responses MUST always have DNS 321 transaction authentication to protect the integrity of any keying 322 data, error codes, etc. This authentication MUST use a previously 323 established secret (TSIG) or public (SIG(0)) key and MUST NOT use any 324 key that the response to be verified is itself providing. 326 TKEY queries MUST be authenticated for all modes except GSS-API and, 327 under some circumstances, server assignment mode. In particular, if 328 the query for a server assigned key is for a key to assert some 329 privilege, such as update authority, then the query must be 330 authenticated to avoid spoofing. However, if the key is just to be 331 used for transaction security, then spoofing will lead at worst to 332 denial of service. Query authentication SHOULD use an established 333 secret (TSIG) key authenticator if available. Otherwise, it must use 334 a public (SIG(0)) key signature. It MUST NOT use any key that the 335 query is itself providing. 337 To avoid replay attacks, it is necessary that a TKEY response or 338 query not be valid if replayed on the order of 2**32 second (about 339 136 years), or a multiple thereof, later. To accomplish this, the 340 keying material used in any TSIG or SIG(0) RR that authenticates a 341 TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds 342 (about 68 years). Thus, on attempted replay, the authenticating TSIG 343 or SIG(0) RR will not be verifiable due to key expiration and the 344 replay will fail. 346 4. Exchange via Resolver Query 348 One method for a resolver and a server to agree about shared secret 349 keying material for use in TSIG is through DNS requests from the 350 resolver which are syntactically DNS queries for type TKEY. Such 351 queries MUST be accompanied by a TKEY RR in the additional 352 information section to indicate the mode in use and accompanied by 353 other information where required. 355 Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY 356 ignore the recursive header bit in TKEY queries they receive. 358 4.1 Query for Diffie-Hellman Exchanged Keying 360 Diffie-Hellman (DH) key exchange is means whereby two parties can 361 derive some shared secret information without requiring any secrecy 362 of the messages they exchange [Schneier]. Provisions have been made 363 for the storage of DH public keys in the DNS [RFC 2539]. 365 A resolver sends a query for type TKEY accompanied by a TKEY RR in 366 the additional information section specifying the Diffie-Hellman mode 367 and accompanied by a KEY RR also in the additional information 368 section specifying a resolver Diffie-Hellman key. The TKEY RR 369 algorithm field is set to the authentication algorithm the resolver 370 plans to use. The "key data" provided in the TKEY is used as a random 371 [RFC 1750] nonce to avoid always deriving the same keying material 372 for the same pair of DH KEYs. 374 The server response contains a TKEY in its answer section with the 375 Diffie-Hellman mode. The "key data" provided in this TKEY is used as 376 an additional nonce to avoid always deriving the same keying material 377 for the same pair of DH KEYs. If the TKEY error field is non-zero, 378 the query failed for the reason given. FORMERR is given if the query 379 included no DH KEY and BADKEY is given if the query included an 380 incompatible DH KEY. 382 If the TKEY error field is zero, the resolver supplied Diffie-Hellman 383 KEY RR SHOULD be echoed in the additional information section and a 384 server Diffie-Hellman KEY RR will also be present in the answer 385 section of the response. Both parties can then calculate the same 386 shared secret quantity from the pair of Diffie-Hellman (DH) keys used 387 [Schneier] (provided these DH keys use the same generator and 388 modulus) and the data in the TKEY RRs. The TKEY RR data is mixed 389 with the DH result as follows: 391 keying material = 392 XOR ( DH value, MD5 ( query data | DH value ) | 393 MD5 ( server data | DH value ) ) 395 Where XOR is an exclusive-OR operation and "|" is byte-stream 396 concatenation. The shorter of the two operands to XOR is byte-wise 397 left justified and padded with zero-valued bytes to match the length 398 of the other operand. "DH value" is the Diffie-Hellman value derived 399 from the KEY RRs. Query data and server data are the values sent in 400 the TKEY RR data fields. These "query data" and "server data" nonces 401 are suffixed by the DH value, digested by MD5, the results 402 concatenated, and then XORed with the DH value. 404 The inception and expiry times in the query TKEY RR are those 405 requested for the keying material. The inception and expiry times in 406 the response TKEY RR are the maximum period the server will consider 407 the keying material valid. Servers may pre-expire keys so this is 408 not a guarantee. 410 4.2 Query for TKEY Deletion 412 Keys established via TKEY can be treated as soft state. Since DNS 413 transactions are originated by the resolver, the resolver can simply 414 toss keys, although it may have to go through another key exchange if 415 it later needs one. Similarly, the server can discard keys although 416 that will result in an error on receiving a query with a TSIG using 417 the discarded key. 419 To avoid attempted reliance in requests on keys no longer in effect, 420 servers MUST implement key deletion whereby the server "discards" a 421 key on receipt from a resolver of an authenticated delete request for 422 a TKEY RR with the key's name. If the server has no record of a key 423 with that name, it returns BADNAME. 425 Key deletion TKEY queries MUST be authenticated. This authentication 426 MAY be a TSIG RR using the key to be deleted. 428 For querier assigned and Diffie-Hellman keys, the server MUST truly 429 "discard" all active state associated with the key. For server 430 assigned keys, the server MAY simply mark the key as no longer 431 retained by the client and may re-send it in response to a future 432 query for server assigned keying material. 434 4.3 Query for GSS-API Establishment 436 This mode is described in a separate document under preparation which 437 should be seen for the full description. Basically the resolver and 438 server can exchange queries and responses for type TKEY with a TKEY 439 RR specifying the GSS-API mode in the additional information section 440 and a GSS-API token in the key data portion of the TKEY RR. See also 441 section 5.2. 443 Any issues of possible encryption of parts the GSS-API token data 444 being transmitted are handled by the GSS-API level. In addition, the 445 GSS-API level provides its own authentication so that this mode of 446 TKEY query and response MAY be, but do not need to be, authenticated 447 with TSIG RR or SIG(0) RR. 449 The inception and expiry times in a GSS-API mode TKEY RR are ignored. 451 4.4 Query for Server Assigned Keying 453 Optionally, the server can assign keying for the resolver. It is 454 sent to the resolver encrypted under a resolver public key. See 455 section 6 for description of encryption methods. 457 A resolver sends a query for type TKEY accompanied by a TKEY RR 458 specifying the "server assignment" mode and a resolver KEY RR to be 459 used in encrypting the response, both in the additional information 460 section. The TKEY algorithm field is set to the authentication 461 algorithm the resolver plans to use. It is RECOMMENDED that any "key 462 data" provided in the query TKEY RR by the resolver be strongly mixed 463 by the server with server generated randomness [RFC 1750] to derive 464 the keying material to be used. The KEY RR that appears in the query 465 need not be accompanied by a SIG(KEY) RR. If the query is 466 authenticated by the resolver with a TSIG RR [draft-ietf- 467 {dnsind|dnsext}-tsig-*.txt] or SIG(0) RR and that authentication is 468 verified, then any SIG(KEY) provided in the query SHOULD be ignored. 469 The KEY RR in such a query SHOULD have a name that corresponds to the 470 resolver but it is only essential that it be a public key for which 471 the resolver has the corresponding private key so it can decrypt the 472 response data. 474 The server response contains a TKEY RR in its answer section with the 475 server assigned mode and echoes the KEY RR provided in the query in 476 its additional information section. 478 If the reponse TKEY error field is zero, the key data portion of the 479 response TKEY RR will be the server assigned keying data encrypted 480 under the public key in the resolver provided KEY RR. In this case, 481 the owner name of the answer TKEY RR will be the server assigned name 482 of the key. 484 If the error field of the response TKEY is non-zero, the query failed 485 for the reason given. FORMERR is given if the query specified no 486 encryption key. 488 The inception and expiry times in the query TKEY RR are those 489 requested for the keying material. The inception and expiry times in 490 the response TKEY are the maximum period the server will consider the 491 keying material valid. Servers may pre-expire keys so this is not a 492 guarantee. 494 The resolver KEY RR MUST be authenticated, through the authentication 495 of this query with a TSIG or SIG(0) or the signing of the resolver 496 KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY 497 for which they know the private key, and thereby the attacker could 498 obtain a valid shared secret key from the server. 500 4.5 Query for Resolver Assigned Keying 502 Optionally, a server can accept resolver assigned keys. The keying 503 material must be encrypted under a server key for protection in 504 transmission as described in Section 6. 506 The resolver sends a TKEY query with a TKEY RR that specifies the 507 encrypted keying material and a KEY RR specifying the server public 508 key used to encrypt the data, both in the additional information 509 section. The name of the key and the keying data are completely 510 controlled by the sending resolver so a globally unique key name 511 SHOULD be used. The KEY RR used MUST be one for which the server has 512 the corresponding private key, or it will not be able to decrypt the 513 keying material and will return a FORMERR, and no untrusted party 514 (preferably no other party than the server) has the private key, or 515 the untrusted private key holder can capture the messages to the 516 server, learn the shared secret, and spoof valid TSIGs. 518 The query TKEY RR inception and expiry give the time period the 519 querier intends to consider the keying material valid. The server 520 can return a lesser time interval to advise that it will not maintain 521 state for that long and can pre-expire keys in any case. 523 This mode of query MUST be authenticated with a TSIG or SIG(0). 524 Otherwise, an attacker can forge a resolver assigned TKEY query, and 525 thereby the attacker could specify a shared secret key that would be 526 accepted, used, and honored by the server. 528 5. Spontaneous Server Inclusion 530 A DNS server may include a TKEY RR spontaneously as additional 531 information in responses. This SHOULD only be done if the server 532 knows the querier understands TKEY and has this option implemented. 533 This technique can be used for GSS-API exchange, and to delete a key. 534 A disadvantage of this technique is that there is no way for the 535 server to get any error or success indication back and, in the case 536 of UDP, no way to even know if the DNS response reached the resolver. 538 5.1 Spontaneous Server Key Deletion 540 A server can optionally tell a client that it has deleted a symmetric 541 key by spontaneously including a TKEY RR in the additional 542 information section of a response with the key's name and specifying 543 the key deletion mode. Such a response SHOULD be authenticated. If 544 authenticated, it "deletes" the key with the given name. The 545 inception and expiry times of the delete TKEY RR are ignored. Failure 546 by a client to receive or properly process such additional 547 information in a response would mean that the client might use a key 548 that the server had discarded and would then get an error indication. 550 For server assigned and Diffie-Hellman keys, the client must truly 551 "discard" all active state associated with the key. For querier 552 assigned keys, the querier MAY simply mark the key as no longer 553 retained by the server and may re-send it in a future query 554 specifying querier assigned keying material. 556 5.2 Spontaneous GSS-API Exchange 558 A server can spontaneously include in the additional information 559 section of a response, a GSS-API mode TKEY RR. The information in 560 the key data section of such a TKEY is a GSS-API token which SHOULD 561 be fed by the resolver to its local GSS-API implementation. If such 562 a response is authenticated, the authentication MAY be verify before 563 processing the data. To the extent that GSS-API provides its own 564 security, such a response need not be authenticated. To the extent 565 that GSS-API handles duplicated messages, such a spontaneous TKEY 566 could be sent repeatedly, until, for example, a response via a GSS- 567 API mode TKEY query is received. See also section 4.3. 569 6. Methods of Encryption 571 For the server assigned and resolver assigned key agreement modes, 572 the keying material is sent within the key data field of a TKEY RR 573 encrypted under the public key in an accompanying KEY RR [RFC 2535]. 574 This KEY RR MUST be for a public key algorithm where the public and 575 private keys can be used for encryption and the corresponding 576 decryption which recovers the originally encrypted data. The KEY RR 577 SHOULD correspond to a name for the decrypting resolver/server such 578 that the decrypting process has access to the corresponding private 579 key to decrypt the data. The secret keying material being sent will 580 generally be fairly short, usually less than 256 bits, because that 581 is adequate for very strong protection with modern keyed hash or 582 symmetric algorithms. 584 If the KEY RR specifies the RSA algorithm, then the keying material 585 is encrypted as per the description of RSA encryption in PKCS#1 [RFC 586 2437]. (Note, the secret keying material being sent is directly RSA 587 encrypted in PKCS#1 format, It is not "enveloped" under some other 588 symmetric algorithm.) In the unlikely event that the keying material 589 will not fit within one RSA modulus of the chosen public key, 590 additional RSA encryption blocks are included. The length of each 591 block is clear from the public RSA key specified and the PKCS#1 592 padding makes it clear what part of the encrypted data is actually 593 keying material and what part is formatting or the required at least 594 eight bytes of random [RFC 1750] padding. 596 7. IANA Considerations 598 This section is to be interpreted as provided in [RFC 2434]. 600 Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF 601 can only be assigned by an IETF standards action. Special 602 consideration should be given before the allocation of meaning for 603 Mode field values 0x0000 and 0xFFFF. 605 Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF 606 are allocated by IESG approval or IETF consensus. 608 Mode field values 0x1000 through 0xEFFF are allocated based on 609 Specification Required as defined in [RFC 2434]. 611 Mode values should not be changed when the status of their use 612 changes. For example, a mode value assigned for an Experimental 613 Standard should not be changed later just because that standard's 614 status is changed to Proposed. 616 The following assignments are documented herein: 618 RR Type 249 for TKEY. 620 TKEY Modes 1 through 5 as listed in section 2.5. 622 Extended RCODE Error values of 19, 20, and 21 as listed in 623 section 2.6. 625 8. Security Considerations 627 The entirety of this specification is concerned with the secure 628 establishment of a shared secret between DNS clients and servers in 629 support of TSIG. 631 Protection against denial of service via the use of TKEY is not 632 provided. 634 References 636 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 637 Algorithms, and Source Code in C", 1996, John Wiley and Sons 639 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 640 STD 13, November 1987. 642 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 643 Specifications", STD 13, November 1987. 645 RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness 646 Recommendations for Security", December 1994. 648 RFC 1982 - Robert Elz, Randy Bush, "Serial Number Arithmetic", 649 09/03/1996. 651 RFC 1995 - Masataka Ohta, "Incremental Zone Transfer in DNS", August 652 1996. 654 RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 655 for IPv4, IPv6 and OSI", October 1996. 657 RFC 2104 - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 658 for Message Authentication", February 1997. 660 RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate 661 Requirement Levels", March 1997. 663 RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 664 Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. 666 RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 667 Considerations Section in RFCs, October 1998. 669 RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography 670 Specifications Version 2.0", October 1998. 672 RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", 673 March 1999. 675 RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain 676 Name System (DNS)", March 1999. 678 draft-ietf-{dnsind|dnsext}-tsig-*.txt - P. Vixie, O. Gudmundsson, D. 679 Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". 681 Author's Address 683 Donald E. Eastlake 3rd 684 Motorola 685 65 Shindegan Hill Road, RR #1 686 Carmel, NY 10512 USA 688 Telephone: +1 914-276-2668 (h) 689 +1 508-261-5434 (w) 690 FAX: +1 914-276-2947 (h) 691 email: Donald.Eastlake@motorola.com 693 Expiration and File Name 695 This draft expires August 2000. 697 Its file name is draft-ietf-dnsext-tkey-01.txt.