idnits 2.17.1 draft-ietf-dnsind-tkey-03.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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 188 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 (December 1999) is 8897 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 95, but not defined -- Looks like a reference, but probably isn't: '1035' on line 95 == Missing Reference: 'RFC 2535' is mentioned on line 523, but not defined ** Obsolete undefined reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Missing Reference: 'RFC 2136' is mentioned on line 96, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 109, but not defined == Missing Reference: 'RFC 1995' is mentioned on line 123, but not defined == Missing Reference: 'RFC 2104' is mentioned on line 130, but not defined == Missing Reference: 'RFC 1982' is mentioned on line 204, but not defined == Missing Reference: 'RFC 1750' is mentioned on line 543, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Missing Reference: 'RFC 2539' is mentioned on line 363, but not defined == Missing Reference: 'RFC 2434' is mentioned on line 547, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'RFC 2030' is mentioned on line 571, but not defined ** Obsolete undefined reference: RFC 2030 (Obsoleted by RFC 4330) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 8 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Working Group Donald E. Eastlake, 3rd 2 INTERNET-DRAFT IBM 3 Expires: June 2000 December 1999 4 draft-ietf-dnsind-tkey-03.txt 6 Secret Key Establishment for DNS (TKEY RR) 7 ------ --- ------------- --- --- ----- --- 9 Donald E. Eastlake 3rd 11 Status of This Document 13 This draft, file name draft-ietf-dnsind-tkey-03.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 25 months. Internet-Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet- 27 Drafts as reference material or to cite them other than as a 28 ``working draft'' or ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating 39 Domain Name System (DNS) queries and responses using shared secret 40 keys via the TSIG resource record. However, it provides no mechanism 41 for setting up such keys other than manual exchange. This document 42 describes a TKEY RR that can be used in a number of different modes 43 to establish shared secret keys between a DNS resolver and server. 45 Acknowledgments 47 The substantial comments and ideas of the following persons (listed 48 in alphabetic order) have been incorporated herein and are gratefully 49 acknowledged: 51 Olafur Gudmundsson (TIS) 53 Stuart Kwan (Microsoft) 55 Brian Wellington (TIS) 57 Table of Contents 59 Status of This Document....................................1 61 Abstract...................................................2 62 Acknowledgments............................................2 64 Table of Contents..........................................3 66 1. Introduction............................................4 67 1.1 General Principles.....................................4 68 1.2 Overview of Contents...................................5 69 2. The TKEY Resource Record................................5 70 2.1 Key Naming.............................................7 71 3. Exchange via Resolver Query.............................8 72 3.1 Query for Server Assigned Keying.......................8 73 3.2 Query for Diffie-Hellman Exchanged Keying..............9 74 3.3 Query for GSS-API Established.........................11 75 3.4 Query for Querier Assigned Keying.....................11 76 3.5 Query for TKEY Deletion...............................12 77 4. Spontaneous Server Inclusion...........................12 78 4.1 Spontaneous GSS-API Exchange..........................12 79 4.2 Spontaneous Server Key Deletion.......................13 80 5. Methods of Encryption..................................13 81 6. IANA Considerations....................................14 82 7. Security Considerations................................14 83 Changes from Previous Draft...............................15 85 References................................................16 87 Author's Address..........................................17 88 Expiration and File Name..................................17 90 1. Introduction 92 The Domain Name System (DNS) is a hierarchical, distributed, highly 93 available database used for bi-directional mapping between domain 94 names and addresses, for email routing, and for other information 95 [RFC 1034, 1035]. It has been extended to provide for public key 96 security and dynamic update [RFC 2535, RFC 2136]. Familiarity with 97 these RFCs is assumed. 99 [draft-ietf-dnsind-tsig-*.txt] provides a means of efficiently 100 authenticating DNS messages using shared secret keys via the TSIG 101 resource record (RR) but provides no mechanism for setting up such 102 keys other than manual exchange. This document describes a TKEY RR 103 that can be used in a number of different modes to establish and 104 delete such shared secret keys between a DNS resolver and server. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC 2119]. 110 1.1 General Principles 112 TKEY is a meta-RR that is not stored or cached in the DNS and does 113 not appear in zone files. It supports a variety of modes for the 114 establishment and deletion of shared secret keys between DNS entities 115 such as resolvers and servers. The establishment of such a key 116 requires that state be maintained at both the resolver and the server 117 and the allocation of the resources to maintain such state may 118 require mutual agreement. In the absence of such agreement, servers 119 MUST return errors such as NotImp or Refused for an attempt to use 120 TKEY and resolvers are free to ignore any TKEY RRs they receive. 122 In all cases herein, the term "resolver" includes that part of a 123 server which makes full and incremental [RFC 1995] zone transfer 124 queries as well as other queries. 126 The shared secret keying material developed by using TKEY is a plain 127 octet sequence. The means by which this shared secret keying 128 material, exchanged via TKEY, is actually used in any particular TSIG 129 algorithm is algorithm dependent and is defined in connection with 130 that algorithm. For example, see [RFC 2104] for how TKEY agreed 131 shared secret keying material is used in HMAC-MD5.SIG-ALG.REG.INT or 132 any other HMAC algorithm. 134 Note that TKEY established keying material and TSIGs that use it are 135 associated with DNS hosts. They are not associated with zones. They 136 may be used to authenticate queries and responses but they do not 137 provide zone based DNS data origin or denial authentication [RFC 138 2535]. 140 Certain modes of TKEY perform encryption which may affect their 141 export or import status for some countries. The affected modes 142 specified in this document are the server assigned mode and the 143 resolver assigned mode. 145 There MUST NOT be more than one TKEY RR in a DNS query or response. 147 1.2 Overview of Contents 149 Section 2 below specifies the TKEY resource record and provides a 150 description of its constituent fields. 152 Section 3 discusses key agreement and deletion via DNS requests with 153 the Query opcode for type TKEY. This method is applicable to all 154 currently defined TKEY modes although in some cases it is not what 155 would intuitively be called a "query". 157 Section 4 discusses spontaneous inclusion of TKEY RRs in responses by 158 servers. This is applicable to key deletion and to the GSS-API mode. 160 Section 5 describes encryption methods for transmitting secret key 161 information. 163 Section 6 covers IANA considerations in assignment of TKEY modes. 165 Finally, Section 7 touches on some security considerations. 167 2. The TKEY Resource Record 169 The TKEY resource record (RR) has the structure given below. Its RR 170 type code is 249. 172 Field Type Comment 173 ----- ---- ------- 175 NAME domain see description below 176 TTYPE u_int16_t TKEY 177 CLASS u_int16_t ignored, should be 255 (ANY) 178 TTL u_int32_t SHOULD be zero 179 RDLEN u_int16_t size of RDATA 180 RDATA: Algorithm: domain 181 Inception: u_int32_t 182 Expiration: u_int32_t 183 Mode: u_int16_t 184 Error: u_int16_t 185 Key Size: u_int16_t 186 Key Data: octet-stream 187 Other Size: u_int16_t 188 Other Data: octet-stream undefined by this protocol 190 The Name field relates to naming keys. Its meaning differs somewhat 191 with mode and context as explained in subsequent sections. Section 192 2.1 below gives key naming guidelines. 194 The TTL field SHOULD always be zero to be sure that older DNS 195 implementations do not cache TKEY RRs. 197 The algorithm name is a domain name with the same meaning as in 198 [draft-ietf-dnsind-tsig-*.txt]. The algorithm determines how the 199 secret keying material agreed to using the TKEY RR is actually used 200 to derive the algorithm specific key that is used. 202 The inception time and expiration time are in number of seconds since 203 the beginning of 1 January 1970 GMT ignoring leap seconds treated as 204 modulo 2**32 using ring arithmetic [RFC 1982]. In messages between a 205 DNS resolver to a DNS server where these fields are meaningful, they 206 are either the requested validity interval for the keying material 207 asked for or specify the validity interval of keying material 208 provided. See Security Considerations section in reference to replay 209 attacks. 211 The mode field specifies the general scheme for key agreement or 212 purpose of the TKEY DNS message. Server and resolvers supporting 213 this specification MUST implement the Diffie-Hellman key agreement 214 and the key deletion modes. All other modes are OPTIONAL. A server 215 supporting TKEY that receives a TKEY request with a mode it does not 216 support MUST return the BADMODE error. The following values of the 217 Mode octet are defined, available, or reserved: 219 Value Description 220 ----- ----------- 221 0 - reserved 222 1 server/responder assignment 223 2 Diffie-Hellman exchange 224 3 GSS-API negotiation 225 4 resolver/querier assignment 226 5 key deletion 227 6-65534 - available, see IANA considerations section 228 65535 -reserved 230 The error code field is an extended RCODE. The following values are 231 defined: 233 Value Description 234 ----- ----------- 235 0 - no error 236 1-15 a DNS RCODE 237 16 BADSIG 238 17 BADKEY 239 18 BADTIME 240 19 BADMODE 241 20 BADNAME 242 21 BADALG 244 When an extended RCODE appears in the TKEY in a response, the DNS 245 header RCODE field indicates no error. 247 The key data size field is an unsigned 16 bit integer in network 248 order which specifies the size of the key exchange data field in 249 octets. The meaning of the key data depends on the mode. 251 The Other Size and Other Data fields are not used in this 252 specification but may be used in future extensions. The RDLEN field 253 MUST equal the length of the RDATA section through the end of Other 254 Data or the RR is to be considered malformed and rejected. 256 2.1 Key Naming 258 At any host only one octet string of keying material may be in place 259 at the same time for any particular key name. An attempt to 260 establish another set of keying material at a server for an existing 261 name SHOULD return a BADNAME error. 263 A reasonable key naming strategy is as follows: 265 If the key is generated as the result of a query with root as 266 its owner name, they the server SHOULD create a pseudo-random 268 [RFC 1750] based unique name ending with a name of the server 269 host. For example 89n3mdg072pp.server.example.com. If 270 generation of a new pseudo-random name in each case is an 271 excessive computation load or entropy drain, a serial number 272 prefix can be added to a single pseudo-random name generated an 273 DNS server start time, such as 274 1001.89n3mdg072pp.server.example.com. 276 If the key is generated as the result of a query with a non-root 277 name, say 1001.foo.example.net, then use the concatenation of 278 that with a name of the server host. For example 279 1001.foo.example.net.server.example.com. 281 3. Exchange via Resolver Query 283 One method for a resolver and a server to agree about shared secret 284 keying material for use in TSIG is through DNS requests from the 285 resolver which are syntactically DNS queries for type TKEY. Such 286 queries MUST be accompanied by a TKEY RR in the additional 287 information section to indicate the mode in use and accompanied by 288 other information where required. 290 For a TKEY appearing in a query, the TKEY RR name SHOULD be a domain 291 locally unique at the resolver (or globally unique), less than 128 292 octets long, and meaningful to the resolver to assist in 293 distinguishing keys and/or key agreement sessions. (For resolvers 294 not wishing to make this use of the name, it may be specified as root 295 to minimize length.) For TKEY(s) appearing in a response to a query, 296 the TKEY RR name SHOULD be a globally unique server assigned domain. 297 If the TKEY in a response is the result of a query containing a TKEY 298 with a non-root name, that query TKEY name SHOULD be incorporated as 299 a prefix of the response TKEY name. See section 2.1 suggesting a 300 more specific naming strategy. 302 Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY 303 ignore the recursive header bit in TKEY queries they receive. 305 3.1 Query for Server Assigned Keying 307 In server assigned keying, the DNS server host generates the keying 308 material and it is sent to the resolver encrypted under a resolver 309 host public key. See section 5 for description of encryption 310 methods. 312 A resolver sends a query for type TKEY accompanied by a TKEY RR 313 specifying the "server assignment" mode and a resolver host KEY RR to 314 be used in encrypting the response, both in the additional 315 information section. The TKEY algorithm field is set to the signature 316 algorithm the resolver plans to use. It is RECOMMENDED that any "key 317 data" optionally provided in the query TKEY RR by the resolver be 318 strongly mixed with server generated randomness [RFC 1750] to derive 319 the keying material to be used. The KEY RR that appears in the query 320 SHOULD have a zero TTL and it need not be accompanied by a SIG(KEY) 321 RR. If the query is signed by the resolver host with a TSIG RR 322 [draft-ietf-dnsind-tsig-*.txt] or SIG(0) RR and that signature is 323 verified, then any SIG(KEY) provided in the query SHOULD be ignored. 324 The KEY RR in such a query SHOULD have a name that corresponds to the 325 resolver host but it is only essential that it be a public key for 326 which the resolver has the corresponding private key so it can 327 decrypt the response data. 329 The server response contains a TKEY RR in its answer section with the 330 server assigned mode and echoes back the KEY RR provided in the query 331 in its additional information section. 333 If the error field is zero, the key data portion of the response TKEY 334 RR will be the server assigned keying data encrypted under the public 335 key in the resolver provided KEY RR. In this case, the name of the 336 answer TKEY RR will be the server assigned name of the key and SHOULD 337 be globally unique. 339 If the error field of the response TKEY is non-zero, the query failed 340 for the reason given. FORMERR is given if the query specified no 341 encryption key. 343 The inception and expiry times in the query TKEY RR are those 344 requested for the keying material. The inception and expiry times in 345 the response TKEY are the maximum period the server will consider the 346 keying material valid. Servers may pre-expire keys so this is not a 347 guarantee. 349 NOTE: Accepting and responding to an unsigned query of this mode may 350 drain some entropy from an entropy pool being maintained by the 351 server and used for secret key generation and so might enable an 352 entropy exhaustion attack. In addition, some significant amount 353 of computational resources may be used in the public key 354 encryption of response data. To protect against these effects, 355 a server SHOULD require such a query to be signed and MAY rate 356 limit responses. 358 3.2 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 client sends a query for type TKEY accompanied by a TKEY RR in the 366 additional information section specifying the "Diffie-Hellman" mode 367 and accompanied by a KEY RR also in the additional information 368 section specifying a client host Diffie-Hellman key. The TKEY RR 369 algorithm field is set to the signature algorithm the resolver plans 370 to use. The "key data" provided in the TKEY is used as a nonce to 371 avoid always deriving the same keying material for the same pair of 372 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 error field is non-zero, the 378 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 error field is zero, the client host supplied Diffie-Hellman 383 KEY should be echoed back and a server host Diffie-Hellman KEY RR 384 will also be present in the response. Both parties can then 385 calculate the same shared secret quantity from the pair of Diffie- 386 Hellman keys used [Schneier], provided they use the same modulus, and 387 the data in the TKEY RRs. The TKEY RR data is mixed with the DH 388 result as follows: 390 keying material = 391 XOR ( DH value, MD5 ( query data | DH value ) | 392 MD5 ( server data | DH value ) ) 394 where XOR is a byte wise left justified xor padding the shorter octet 395 stream with zeros, DH value is the Diffie-Hellman value derived from 396 the KEY RRs, "query data" and "server data" are the TKEY RR data 397 fields sent by those parties, and "|" is concatenation. These "query 398 data" and "server data" nonces are suffixed by the DH value, digested 399 by MD5, the results concatenated, and then XORed with the DH value. 401 The inception and expiry times in the query TKEY RR are those 402 requested for the keying material. The inception and expiry times in 403 the response TKEY RR are the maximum period the server will consider 404 the keying material valid. Servers may pre-expire keys so this is 405 not a guarantee. 407 NOTE: Accepting and responding to an unsigned query of this mode may 408 use significant computation at the server; however, if the 409 server requires that the request be signed and if no shared 410 secret is in place to permit a TSIG [draft-ietf-dnsind-tsig- 411 *.txt] to be used on the request, it would be necessary to use a 412 SIG(0) the verification of which would impose its own 413 computational load. 415 3.3 Query for GSS-API Established 417 This is described in a separate document which should be seen for the 418 full description. Basically the resolver and server can exchange 419 queries and responses for type TKEY with a TKEY RR specifying the 420 GSS-API mode in the additional information section and a GSS-API 421 token in the key data portion. 423 Any issues of possible encryption of parts the GSS-API token data 424 being transmitted are handled by the GSS-API level. In addition, the 425 GSS-API level provides its own authentication so that this mode of 426 TKEY query and response MAY be, but do not need to be, signed with 427 TSIG RR or SIG(0) RR. 429 The inception and expiry time in a GSS-API mode TKEY RR are ignored. 431 3.4 Query for Querier Assigned Keying 433 Optionally, a server can accept resolver assigned keys. The keying 434 material must be encrypted under a server host key for protection in 435 transmission as described in Section 5. 437 The resolver sends a TKEY query with a TKEY RR that specifies the 438 keying data and a KEY RR specifying the server host public key used 439 to encrypt the data both in the additional information section. The 440 name of the key and the keying data are completely controlled by the 441 sending resolver so a globally unique key name SHOULD be used. The 442 server SHOULD require that this request be signed with a TSIG, if 443 there already exists an appropriate shared secret, or a SIG(0) by the 444 querying host. The KEY RR used MUST be one for which the server has 445 the corresponding private key or it will not be able to decrypt the 446 keying material and will return a FORMERR. 448 The query TKEY RR inception and expiry give the time period the 449 querier intends to consider the keying material valid. The server 450 can return a lesser time interval to advise that it will not maintain 451 state for that long and can pre-expire keys in any case. 453 3.5 Query for TKEY Deletion 455 Keys established via TKEY can be treated as soft state. Since DNS 456 transactions are originated by the resolver, the resolver can simply 457 toss keys, although it may have to go through another key exchange if 458 it later needs one. Similarly, the server can discard keys although 459 that will result in an error on receiving a query with a TSIG using 460 the discarded key. 462 To avoid attempted reliance in queries on keys no longer in effect, 463 servers MUST implement key deletion whereby the server "discards" a 464 key on receipt from a resolver of an authenticated delete request for 465 a TKEY RR with the key's name. If the server has no record of a key 466 with that name, it returns BADNAME. 468 Key deletion TKEY queries MUST be signed. This signature may be a 469 TSIG RR using the key to be deleted. 471 For querier assigned and Diffie-Hellman keys, the server MUST truly 472 "discard" all active state associated with the key. For server 473 assigned keys, the server MAY simply mark the key as no longer 474 retained by the client and may re-send it in response to a future 475 query for server assigned keying material. 477 4. Spontaneous Server Inclusion 479 A DNS server may include a TKEY RR spontaneously as additional 480 information in responses. This SHOULD only be done if the server 481 knows the querier understands TKEY and has this option implemented. 482 This technique can be used for GSS-API exchange, and to delete a key. 483 A disadvantage of this technique is that there is no way for the 484 server to get any immediate error or success indication back and, in 485 the case of UDP, no way to even know if the DNS response reached the 486 resolver. 488 4.1 Spontaneous GSS-API Exchange 490 A server can spontaneously include in the additional information 491 section of a response, a GSS-API mode TKEY RR. The information in 492 the key data section of such a TKEY is a GSS-API token which SHOULD 493 be fed by the resolver to its local GSS-API implementation. If such 494 a response is signed, the signature must verify before processing the 495 data. To the extent that GSS-API provides its own security, such a 496 response may not need to be signed. To the extent that GSS-API 497 handles duplicated messages, such a spontaneous TKEY can be sent 498 repeatedly, until, for example, a response via a GSS-API mode TKEY 499 query is received. 501 4.2 Spontaneous Server Key Deletion 503 A server can optionally tell a client that it has deleted a symmetric 504 key by spontaneously including a TKEY RR in the additional 505 information section of a response with the key's name and specifying 506 the key deletion mode. Such a response SHOULD be signed. If 507 authenticated, it "deletes" the key with the given name. The 508 inception and expiry times of the delete TKEY RR are ignored. Failure 509 by a client to receive or properly process such additional 510 information in a response would mean that the client might use a key 511 that the server had discarded and would then get an error indication. 513 For server assigned and Diffie-Hellman keys, the client must truly 514 "discard" all active state associated with the key. For querier 515 assigned keys, the queries MAY simply mark the key as no longer 516 retained by the server and may re-send it in a future query 517 specifying querier assigned keying material. 519 5. Methods of Encryption 521 For the server assigned and resolver assigned key agreement, the 522 keying material is sent within the key data field of a TKEY RR 523 encrypted under the public key in an accompanying KEY RR [RFC 2535]. 524 This KEY RR MUST be for a public key algorithm where the public and 525 private keys can be used for encryption and the corresponding 526 decyrption which recovers the originally encrypted data. The KEY RR 527 MUST correspond to a name for the decrypting host such that the 528 decrypting host has the corresponding private key to decrypt the 529 data. The secret keying material being sent will generally be fairly 530 short, usually less than 256 bits, because that is adequate for very 531 strong protection with modern keyed hash or symmetric algorithms. 533 If the KEY RR specifies the RSA algorithm, then the keying material 534 is encrypted as per the description of RSA encryption in PKCS#1 [RFC 535 2437]. (Note, the secret keying material being sent is directly RSA 536 encrypted in PKCS#1 format, It is not "enveloped" under some other 537 symmetric algorithm.) In the unlikely event that the keying material 538 will not fit within one RSA modulus of the chosen public key, 539 additional RSA encryption blocks are included. The length of each 540 block is clear from the public RSA key specified and the PKCS#1 541 padding makes it clear what part of the encrypted data is actually 542 keying material and what part is formatting or the required at least 543 eight bytes of random [RFC 1750] padding. 545 6. IANA Considerations 547 This section is to be interpreted as provided in [RFC 2434]. 549 Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF 550 can only be assigned by an IETF standards action (and 1 through 5 are 551 assigned by this Proposed Standard). Special consideration should be 552 given before the allocation of meaning for Mode field values 0x0000 553 and 0xFFFF. 555 Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF 556 are allocated by an IETF consensus. 558 Mode field values 0x1000 through 0xEFFF are allocated based on RFC 559 documentation of their use. 561 Mode values should not be changed when the status of their use 562 changes. I.E. a mode value assigned for an Experimental Standard 563 should not be changed later just because that standard's status is 564 changed to Proposed. 566 7. Security Considerations 568 To avoid different interpretations of the inception and expiration 569 times in TKEY RRs, resolvers and servers exchanging them must have 570 the same idea of what time it is. One way of doing this is with the 571 NTP protocol [RFC 2030] but that or any other time synchronization 572 MUST be done securely. 574 TKEY queries SHOULD be signed and those using the querier 575 establishment mode MUST be signed to authenticate their origin. 576 However, for currently defined modes, relatively little damage will 577 be done if an unsigned query of this sort is accepted and processed, 578 as described above, for each mode. In addition, requiring that a TKEY 579 query be signed by a TSIG (if there exists an acceptable exchanged 580 key between the parties) or a SIG(0) may itself impose significant 581 computational requirements on the server, particularly in verifying 582 SIG(0) public key signatures. 584 Responses to TKEY queries MUST always have DNS transaction signatures 585 to protect the integrity of any keying data, error codes, etc. This 586 signature MUST use a previously established secret (TSIG) or public 587 (SIG(0)) key and MUST NOT use any key that the response to be 588 verified is itself providing. 590 To avoid replay attacks, it is necessary that a response or querier 591 establishment mode query involving TKEY not be valid if replayed on 592 the order of 2**32 second (about 136 years) later. To accomplish 593 this, the keying material used in any TSIG or SIG(0) RR that 594 authenticates a TKEY message MUST NOT have a lifetime of more then 595 2**31 - 1 seconds (about 68 years). Thus, on attempted replay, the 596 authenticating TSIG or SIG(0) RR will not be verifiable due to key 597 expiration and the replay will fail. 599 General protection against denial of service via the use of TKEY is 600 not provided. 602 Changes from Previous Draft 604 Fix one letter typo in Section 5. 606 Make default CLASS for TKEY be ANY. 608 References 610 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 611 Algorithms, and Source Code in C", 1996, John Wiley and Sons 613 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 614 STD 13, November 1987. 616 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 617 Specifications", STD 13, November 1987. 619 RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness 620 Recommendations for Security", December 1994. 622 RFC 1982 - Robert Elz, Randy Bush, "Serial Number Arithmetic", 623 09/03/1996. 625 RFC 1995 - Masataka Ohta, "Incremental Zone Transfer in DNS", August 626 1996. 628 RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 629 for IPv4, IPv6 and OSI", October 1996. 631 RFC 2104 - H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 632 for Message Authentication", February 1997. 634 RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate 635 Requirement Levels", March 1997. 637 RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 638 Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. 640 RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 641 Considerations Section in RFCs, October 1998. 643 RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography 644 Specifications Version 2.0", October 1998. 646 RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", 647 March 1999. 649 RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain 650 Name System (DNS)", March 1999. 652 draft-ietf-dnsind-tsig-*.txt - P. Vixie, O. Gudmundsson, D. 653 Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". 655 Author's Address 657 Donald E. Eastlake 3rd 658 65 Shindegan Hill Road, RR #1 659 Carmel, NY 10512 USA 661 Telephone: +1 914-276-2668 (h) 662 +1 914-784-7913 (w) 663 FAX: +1 914-276-2947 (h) 664 email: dee3@torque.pothole.com 666 Expiration and File Name 668 This draft expires June 2000. 670 Its file name is draft-ietf-dnsind-tkey-03.txt.