idnits 2.17.1 draft-ietf-dnssec-tkey-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnssec-tkey-01.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-tkey-01.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-tkey-01.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnssec-tkey-01.txt,', but the file name used is 'draft-ietf-dnssec-tkey-01' == 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 189: '...TL u_int32_t SHOULD be zero...' RFC 2119 keyword, line 204: '... The TTL field SHOULD always be zero...' RFC 2119 keyword, line 219: '... keying material MUST NOT have a lifet...' RFC 2119 keyword, line 255: '... MUST equal the length of the RDATA ...' RFC 2119 keyword, line 262: '...Y. Such queries MUST either be accomp...' (24 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 199 has weird spacing: '...-stream undef...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (September 1998) is 9353 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 1995' is mentioned on line 128, but not defined == Missing Reference: 'RFC 1982' is mentioned on line 214, but not defined == Missing Reference: 'RFC 1750' is mentioned on line 506, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Missing Reference: 'RFC 2136' is mentioned on line 478, but not defined == Missing Reference: 'RFC 2030' is mentioned on line 534, but not defined ** Obsolete undefined reference: RFC 2030 (Obsoleted by RFC 4330) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' Summary: 12 errors (**), 1 flaw (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSSEC Working Group Donald E. Eastlake, 3rd 3 INTERNET-DRAFT IBM 4 Expires: March 1999 September 1998 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-dnssec-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 security mailing list 16 or to the author. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and 38 securing Domain Name System (DNS) queries and responses using shared 39 secret keys via the TSIG resource record (RR). However, it provides 40 no mechanism for setting up such keys other than manual exchange. 41 This document describes a TKEY RR that can be used in a number of 42 different modes to establish shared secret keys between a DNS 43 resolver and server. 45 [changes from last draft: add IANA considerations section, make time 46 fields module 2**32, minor edits, update author info, ...] 48 Acknowledgments 50 The substantial comments and ideas of the following persons (listed 51 in alphabetic order) have been incorporated herein and are gratefully 52 acknowledged: 54 Olafur Gudmundsson 56 Stuart Kwan 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 General Principles.....................................4 69 1.2 Overview of Contents...................................5 71 2. The TKEY Resource Record................................6 73 3. Exchange via Resolver Query.............................8 74 3.1 Query for Server Assigned Keying.......................8 75 3.2 Query for Diffie-Hellman Exchanged Keying..............9 76 3.3 Query for GSS-API Established.........................10 78 4. Spontaneous Server Inclusion...........................11 79 4.1 Spontaneous Server Assigned Keying....................11 80 4.2 Spontaneous Diffie-Hellman Keying.....................11 81 4.3 Spontaneous GSS-API Exchange..........................11 82 4.4 Spontaneous Key Deletion..............................12 84 5. TKEY Dynamic Update Requests...........................13 85 5.1 Exchange via TKEY 'Add'...............................13 86 5.2 TKEY Deletion.........................................13 88 6. Methods of Encryption..................................14 90 7. IANA Considerations....................................15 92 8. Security Considerations................................16 94 References................................................17 96 Author's Address..........................................18 97 Expiration and File Name..................................18 99 1. Introduction 101 The Domain Name System (DNS) is a hierarchical, distributed, highly 102 available database used for mapping between domain names and 103 addresses, for email routing, and for other information [RFC 1034, 104 1035]. It has been extended to provide for public key security and 105 dynamic update [RFC 2136, draft-ietf-dnssec-secext2-*.txt, draft- 106 ietf-dnssec-update2-*.txt]. 108 [draft-ietf-dnsind-tsig-*.txt] provides a means of more efficiently 109 authenticating and securing DNS messages using shared secret keys via 110 the TSIG resource record (RR) but provides no mechanism for setting 111 up such keys other than manual exchange. This document describes a 112 TKEY RR that can be used in a number of different modes to establish 113 such shared secret keys between a DNS resolver and server. 115 1.1 General Principles 117 TKEY is a meta-RR that is not stored or cached in the DNS and does 118 not appear in zone files. It supports a variety of modes for the 119 establishment and deletion of shared secret keys between DNS entities 120 such as resolvers and servers. The establishment of such a key 121 requires that state be maintained at both the resolver and the server 122 and the allocation of the resources to maintain such state may 123 require mutual agreement. In the absence of such agreement, servers 124 are free to return errors for any attempt to use TKEY and resolvers 125 are free to ignore any TKEY RRs they receive. 127 In all cases herein, the term "resolver" includes that part of a 128 server which makes full and incremental [RFC 1995] zone transfer 129 queries as well as other queries. 131 Servers are not required to implement any particular mode or modes of 132 the defined modes of TKEY shared secret key establishment or deletion 133 and may return errors for any they do not support. Based on 134 experience, in the future more modes may be added or some modes 135 described herein may be deprecated. 137 The means by which the shared secret keying material exchanged via 138 TKEY is actually used in any particular TSIG algorithm is algorithm 139 dependent and is defined in connection with that algorithm. 141 Note that this keying material and TSIGs that use it are associated 142 with DNS hosts. They are not tied to zones. They may be used to 143 authenticate queries and responses but they do not provide zone 144 stored DNS data origin authentication [draft-ietf-dnssec-secext2- 145 *.txt]. 147 Two modes of TKEY, the server assigned and resolver assigned modes, 148 perform encryption which may effect their export or inport status for 149 some countries. All other aspects of DNS security, including the 150 SIG, KEY, NXT, and TSIG RRs and all other defined modes of TKEY 151 perform authentication (signatures and signature verification) only. 153 1.2 Overview of Contents 155 Section 2 below specifies the TKEY resource record (RR) and provides 156 a high level description of its constituent fields. 158 Section 3 discusses key exchange via queries for type TKEY. This is 159 applicable to the server assigned, Diffie-Hellman exchange, and GSS- 160 API establishment modes. 162 Section 4 discusses spontaneous inclusion of TKEY RRs in responses by 163 servers. This is applicable to key deletion and to server assigned 164 and Diffie-Hellman exchange key establishment. 166 Section 5 discusses use of dynamic update requests for type TKEY. 167 This supports optional key exchange via resolver update request, 168 which is applicable to key deletion and to the resolver assigned 169 mode. 171 Section 6 describes encryption methods for transmitting secret key 172 information. 174 Section 7 covers IANA considerations in assignment of TKEY modes. 176 Finally, Section 8 touches on some security considerations. 178 2. The TKEY Resource Record 180 The TKEY resource record (RR) has the structure given below. Its RR 181 type code is 249. 183 Field Type Comment 184 ----- ---- ------- 186 NAME domain see description below 187 TTYPE u_int16_t TKEY 188 CLASS u_int16_t ignored, should be zero 189 TTL u_int32_t SHOULD be zero 190 RDLEN u_int16_t size of RDATA 191 RDATA: Algorithhm: domain 192 Inception: u_int32_t 193 Expiration: u_int32_t 194 Mode: u_int16_t 195 Error: u_int16_t 196 Key Size: u_int16_t 197 Key Data: octet-stream 198 Other Size: u_int16_t 199 Other Data: octet-stream undefined by this protocol 201 The Name field's meaning differs somewhat with mode and context as 202 explained in subsequent sections. 204 The TTL field SHOULD always be zero to be sure that older DNS 205 implementations do not cache TKEY RRs. 207 The algorithm name is a domain name with the same meaning as in 208 [draft-ietf-dnsind-tsig-*.txt]. The algorithm determines how the 209 secret keying material exchanged using the TKEY RR is actually used 210 to derive the algorithm specific key that is used. 212 The inception time and expiration time are in number of seconds since 213 the beginning of 1 January 1970 GMT ignoring leap seconds treated as 214 modulo 2**32 using ring arithmetic [RFC 1982]. In messages between a 215 DNS resolver to a DNS server where these fields are meaningful, they 216 are the either requested validity interval for the keying material 217 asked for or specify the validity interval of keying material 218 provided. To avoid reply attack, to keying material used to 219 authenticate TKEY keying material MUST NOT have a lifetime of more 220 then 2**31 seconds. This applies to keying material used in either a 221 TSIG or a SIG(0) transacation or request signature. 223 The mode field specifies the general scheme for key agreement. Note 224 that implementation of TKEY as a whole and of any particular mode is 225 optional. The following values of the Mode octet are defined or 226 reserved: 228 Value Description 229 ----- ----------- 230 0 - reserved 231 1 server/responder assignment 232 2 Diffie-Hellman exchange 233 3 GSS-API negotiation 234 4 resolver/querier assignment 235 5 key deletion 236 6-65534 - available, see IANA considerations section 237 65535 -reserved 239 The error code field is an extended RCODE. The following values are 240 defined: 241 Value Description 242 ----- ----------- 243 0 - no error 244 1-15 a DNS RCODE 245 16 BADSIG 246 17 BADKEY 247 18 BADTIME 248 19 BADMODE 250 The key data size field is an unsigned 16 bit integer in network 251 order which specifies the size of the key exchange data field in 252 octets. The meaning of the key data depends on the mode. 254 The Other Size and Other Data fields are not used. The RDLEN field 255 MUST equal the length of the RDATA section through the end of other 256 data or the RR is to be considered malformed and rejected. 258 3. Exchange via Resolver Query 260 One method for a resolver and a server to establish a shared secret 261 key for use in TSIG is through queries from the resolver for type 262 TKEY. Such queries MUST either be accompanied by one or more TKEY 263 RRs in the additional information section to indicate the mode(s) in 264 use and other information where required or the resolver and server 265 must have a prior agreement that supplies any information that would 266 otherwise have had to be conveyed by TKEY RR(s) in the query. 268 For TKEY(s) appearing in a query, the TKEY RR name SHOULD be a domain 269 locally unique at the resolver (or globally unique), less than 128 270 octets long, and meaningful to the resolver to distinguish keys 271 and/or key agreement sessions. (For resolvers not wishing to make 272 this use of the name, it may be specified as root to minimize 273 length.) For TKEY(s) appearing in a response to a query, the TKEY RR 274 name SHOULD be a globally unique server assigned domain. If the TKEY 275 in a response is the result of a query containing a TKEY with a non- 276 root name, that query TKEY name SHOULD be incorporated as the prefix 277 of the response TKEY name. 279 Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY 280 ignore the recursive header bit in TKEY queries they receive. 282 For every mode defined below, the inception and expiration times in a 283 query TKEY are set to the time interval for which the resolver wishes 284 the requested key to be valid and they are set in a successful 285 response to the actual time interval during which the server will 286 consider the key valid. Future modes may be defined which ignore the 287 inception and expiration time fields. 289 3.1 Query for Server Assigned Keying 291 In server assigned keying, the DNS server host generates the keying 292 material and it is sent to the resolver encrypted under a resolver 293 host key. See section 6 for description of encryption methods. 295 A resolver sends a query for type TKEY accompanied by a TKEY RR 296 specifying the "server assignment" mode and a resolver host KEY RR to 297 be used in encrypting the response, both in the additional 298 information section. The TKEY algorithm field is set to the signature 299 algorithm the resolver plans to use. It is recommended that any "key 300 data" provided in the query TKEY be strongly mixed with server 301 generated randomness [RFC 1750] to derive the keying material to be 302 used. The KEY that appears in the query SHOULD have a zero TTL. It 303 need not be accompanied by a SIG(KEY) and if the query is signed by 304 the resolver host and that signature is verified, then any SIG(KEY) 305 provided MAY be ignored for key exchange purposes. The KEY RR in 306 such a query SHOULD have a name that corresponds to the resolver host 307 but it is only essential that it be a public key for which the 308 resolver has the corresponding private key so it can decrypt the 309 response data. 311 Accepting and responding to an unsigned query of this sort may drain 312 some entropy from an entropy pool being maintained by the server and 313 used for secret key generation and so might enable an entropy 314 exhaustion attack. In addition, some significant amount of 315 computational resources may be used in the public key encryption of 316 response data. To protect against these effects, a server SHOULD 317 require such a query to be signed and MAY rate limit responses. 319 The server response contains a TKEY in its answer section with the 320 server assigned mode. If the error field is non-zero, the query 321 failed for the reason given. If the error field is zero, the KEY RR 322 provided in the query will be echoed back and the key data portion of 323 the response TKEY RR will be the server assigned keying data 324 encrypted under the public key in the KEY RR. The name of the TKEY 325 RR will be the server assigned name of the key and SHOULD be globally 326 unique. 328 3.2 Query for Diffie-Hellman Exchanged Keying 330 Diffie-Hellman (DH) key exchange is means whereby two parties can 331 derive some shared secret information without requiring any secrecy 332 of the messages they exchange [Schneier]. Provisions have been made 333 for the storage of DH public keys in the DNS [draft-ietf-dnssec-dhk- 334 *.txt]. 336 A client sends a query for type TKEY accompanied by a TKEY RR in the 337 additional information section specifying the "Diffie-Hellman" mode 338 and accompanied by a KEY RR specifying a client host Diffie-Hellman 339 key. The TKEY algorithm field is set to the signature algorithm the 340 resolver plans to use and any "key data" provided is ignored by the 341 server. 343 Accepting and responding to an unsigned query of this sort may use 344 significant computation at the server; however, if the server 345 requires that the request be signed, then if no shared secret is in 346 place to permit a TSIG to be used on the request, it would be 347 necessary to use a SIG(0) the verification of which would impose its 348 own computational load. 350 The server response contains a TKEY in its answer section with the 351 Diffie-Hellman mode. If the error field is non-zero, the query failed 352 for the reason given. If the error field is zero, the client host 353 supplied Diffie-Hellman KEY should be echoed back and a server host 354 Diffie-Hellman KEY RR will also be present. 356 Both parties can calculate the same shared secret quantity from the 357 pair of Diffie-Hellman keys used [Schneier] provided they use the 358 same modulus. If the server host does not have an appropriate 359 Diffie-Hellman key to use for the exchange, it should return the 360 BADKEY error. 362 3.3 Query for GSS-API Established 364 This is described in a separate document [draft-skwan-gss-tsig-*.txt] 365 which should be seen for the full description. Basically, when an 366 acceptable symmetric key is not yet in place, the resolver can send a 367 query for type TKEY with a TKEY specifying the GSS-API mode in the 368 additional information section and a GSS-API token in the key data 369 portion. The server responds with a TKEY specifying the GSS-API mode 370 and a GSS-API token in the key data portion. The resolver and server 371 feed these tokens to their local GSS implementation and interate 372 until an error is encountered or a key (GSS-API session) is 373 established. A similar exchange can be used to delete a GSS-API 374 session. 376 Any issues of possible encryption of the GSS-API token data being 377 transmitted are handled by the GSS-API level. In addition, the GSS- 378 API level provides authentication so that this mode of TKEY query and 379 response MAY be, but do not need to be, signed with TSIG or SIG(0). 381 4. Spontaneous Server Inclusion 383 A DNS server may include TKEY RRs spontaneously as additional 384 information in responses. This SHOULD only be done if the server 385 knows the querier understands TKEY and has this option implemented. 386 This technique can be used to establish a server assigned key, a 387 Diffie-Hellman exchange key, for GSS-API exchange, and to delete a 388 key. A disadvantage of this technique is that there is no way for 389 the server to get any immediate error or success indication back and, 390 in the case of UDP, no way to even know if the DNS response reached 391 the resolver. 393 4.1 Spontaneous Server Assigned Keying 395 A server can include in the additional information section of a 396 response a server assignment mode TKEY with encrypted keying material 397 in its key data section along with a KEY RR specifying the client 398 public key used for the encryption. Such a response SHOULD be signed 399 but the KEY RR need not be signed by a SIG(KEY). A server should 400 only do this if there is sufficient room in a query and it has reason 401 to believe the resolver will understand such additional data. The 402 KEY RR used MUST be one for which the resolver host has the 403 corresponding private key or it will not be able to decrypt the 404 keying material. 406 4.2 Spontaneous Diffie-Hellman Keying 408 A server can include in the additional information section of a 409 response a Diffie-Hellman exchange mode TKEY along with two KEY RRs 410 specifying the client and server host public keys used for the 411 exchange. Such a response SHOULD be signed but the KEY RRs need not 412 be signed by a SIG(KEY). A server should only do this if there is 413 sufficient room in a query and it has reason to believe the resolver 414 host will understand such additional data. 416 4.3 Spontaneous GSS-API Exchange 418 A server can spontaneously include in the additional information 419 section of a response, a GSS-API mode TKEY. The information in the 420 key data section of such a TKEY is a GSS-API token which SHOULD be 421 fed by the resolver to its local GSS-API implementation. If such a 422 response is signed, the signature must verify before processing the 423 data. To the extent that GSS-API provides its own security, such a 424 response may not need to be signed. To the extent that GSS-API 425 handles duplicated messages, such a spontaneous TKEY can be sent 426 repeatedly, until, perhaps, a response via a GSS-API mode TKEY query 427 is received. 429 4.4 Spontaneous Key Deletion 431 A server can hint to a client that it has deleted a symmetric key by 432 spontaneously including a TKEY RR in the additional information 433 section of a response with the key's name and specifying the key 434 deletion mode. Such a response SHOULD be signed. If authenticated, 435 it deletes all keys with the given name whose effective time period 436 overlaps the inception to expiration period given in the TKEY. (If 437 the inception time of one symmetric key is equal to the expiration 438 time of another, or vice versa, they do not overlap.) Failure by a 439 client to receive or properly process such additional information in 440 a response would simply mean that the client might use a key that the 441 server had discarded and then get an error indication. 443 5. TKEY Dynamic Update Requests 445 If a DNS server supports dynamic update [RFC 2136], then dynamic 446 update request can be used to exchange resolver assigned symmetric 447 keys as described in section 5.1 below and to delete previously 448 exchanged keys from a server as described in section 5.2 below. 450 5.1 Exchange via TKEY 'Add' 452 Optionally, a server can accept resolver assigned keys. The keying 453 material must be encrypted under a server host key for protection in 454 transmission as described in Section 6. 456 The resolver sends an update request to add a TKEY RR that specifies 457 the keying data with a KEY RR in the additional information section 458 specifying the server host public key used to encrypt the data. The 459 name of the key and the keying data are completely controlled by the 460 sending resolver so a globally unique key name SHOULD be used. The 461 server SHOULD require that this request be signed with a TSIG, if 462 there already exists an appropriate shared secret, or a SIG(0) by the 463 resolver host. The KEY RR used MUST be one for which the server has 464 the corresponding private key or it will not be able to decrypt the 465 keying material. 467 5.2 TKEY Deletion 469 Keys established via TKEY can be treated as soft state. Since DNS 470 transactions are originated by the resolver, the resolver can simply 471 toss keys, although it may have to go through another key exchange if 472 it later needs one. Similarly, the server can discard keys although 473 that will result in an error on receiving a query with a TSIG using 474 the discarded key. 476 The key expiration provided in the TKEY and the ability of each party 477 to discard keys may be adequate but servers that support dynamic 478 update [RFC 2136] may optionally implement key deletion whereby the 479 server discards a key on receipt from a resolver of a delete request 480 for a TKEY with the key's name. The mode and most fields of the TKEY 481 being "deleted" are ignored. But, to allow for the possibility of 482 multiple keys with the same name but different time periods, the only 483 key deleted are those whose time period overlaps with that specified 484 by the inception and expiration in the TKEY being "deleted". 486 6. Methods of Encryption 488 For the server assigned and resolver assigned key exchange, the 489 keying material is sent within the key data field of a TKEY RR 490 encrypted under the private key corresponding to the public key in an 491 accompanying KEY RR [draft-ietf-dnssec-secext2-*.txt]. The secret 492 keying material being send will generally be fairly short, usually 493 less than 256 bits, because that is adequate for very strong 494 protection with modern keyed hash or symmetric algorithms. 496 If the KEY RR specifies the RSA algorithm, then the keying material 497 is encrypted as per the description of RSA encryption in PKCS-1. 498 (Note, the secret keying material being sent is directly RSA 499 encrypted in PKCS-1 format, It is not "enveloped" under some other 500 symmetric algorithm.) In the unlikely event that the keying material 501 will not fit within one RSA modulus of the chosen public key, 502 additional RSA encryption blocks are included. The length of each 503 block is clear from the public RSA key specified and the PKCS-1 504 padding makes it clear what part of the encrypted data is actually 505 keying material and what part is formatting or the required at least 506 eight bytes of random [RFC 1750] padding. 508 7. IANA Considerations 510 Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF 511 can only be assigned by an IETF standards action excluding 512 Experimental Standards (and 1 through 5 are assigned by this Proposed 513 Standard). Special consideration should be given before the 514 allocation of meaning for Mode field values 0x0000 and 0xFFFF. 516 Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF 517 are allocated by an IETF consensus (i.e., at this time, an IESG vote) 518 excluding Experimental Standards. 520 Mode field values 0x1000 through 0xEFFF are allocated based on RFC 521 documentation of their use or the issuance of an Experimental 522 Standard. 524 Mode values should not be changed when the status of their use 525 changes. I.E. a mode value assigned for an Experimental Standard 526 should not be changed later just because that standard's status is 527 changed to Proposed. 529 8. Security Considerations 531 To avoid different interpretations of the inception and expiration 532 times in TKEY RRs, resovlers and servers exchanging them must have 533 the same idea of what time it is. One way of doing this is with the 534 NTP protocol [RFC 2030] but that or any other time synchronization 535 MUST be done securely. 537 It is recommended that the server require TKEY queries be signed. 538 However, for currently defined modes, relatively little damage will 539 be done if an unsigned query of this sort is accepted and processed, 540 as described below for each mode. In addition, requiring that a TKEY 541 query be signed by a TSIG (if there exists an acceptable exchanged 542 key between the parties) or a SIG(0) may itself impose significant 543 computational requirements on the server, particularly in verifying 544 SIG(0) public key signatures. 546 Responses to TKEY queries SHOULD always have DNS transaction 547 signatures to protect the integrity of any keying data, error codes, 548 etc. This signature, if present, MUST use a previously established 549 secret (TSIG) or public (SIG(0)) key and MUST NOT use any key that 550 the response to be verified is itself providing. 552 References 554 PKCS-1 - RSA Encryption Standard (An RSA Laboratories Technical 555 Note). 557 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 558 STD 13, November 1987. 560 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 561 Specifications", STD 13, November 1987. 563 RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness 564 Recommendations for Security", December 1994. 566 RFC 1982 - Robert Elz, Rrandy Bush, "Serial Number Arithmetic", 567 09/03/1996. 569 RFC 1995 - Masatka Ohta, "Incremental Zone Transfer in DNS", August 570 1996. 572 RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 573 for IPv4, IPv6 and OSI", October 1996. 575 RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic 576 Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. 578 draft-ietf-dnsind-tsig-*.txt - P. Vixie, O. Gudmundsson, D. 579 Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". 581 draft-ietf-dnssec-dhk-*.txt - D. Eastlake 583 draft-ietf-dnssec-update2-*.txt - Donald E. Eastlake 3rd, "Secure 584 Domain Name System Dynamic Update". 586 draft-ietf-dnssec-secext2-*.txt - Donald E. Eastlake 3rd, "Domain 587 Name System Security Extensions". 589 draft-skwan-gss-tsig-*.txt - S. Kwan, P. Garg, R. Viswanathan, "GSS 590 Algorithm for TSIG (GSS-TSIG)" 592 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 593 Algorithms, and Source Code in C", 1996, John Wiley and Sons 595 Author's Address 597 Donald E. Eastlake 3rd 598 IBM 599 318 Acton Street 600 Carlisle, MA 01741 USA 602 Telephone: +1 978 287 4877 603 +1 914 784 7913 604 FAX: +1 978 371 7148 605 email: dee3@us.ibm.com 607 Expiration and File Name 609 This draft expires March 1999. 611 Its file name is draft-ietf-dnssec-tkey-01.txt.