1 Network Working Group D. Eastlake, 3rd
2 Request for Comments: 2930 Motorola
3 Category: Standards Track September 2000
4
5
6 Secret Key Establishment for DNS (TKEY RR)
7
8 Status of this Memo
9
10 This document specifies an Internet standards track protocol for the
11 Internet community, and requests discussion and suggestions for
12 improvements. Please refer to the current edition of the "Internet
13 Official Protocol Standards" (STD 1) for the standardization state
14 and status of this protocol. Distribution of this memo is unlimited.
15
16 Copyright Notice
17
18 Copyright (C) The Internet Society (2000). All Rights Reserved.
19
20 Abstract
21
22 [RFC 2845] provides a means of authenticating Domain Name System
23 (DNS) queries and responses using shared secret keys via the
24 Transaction Signature (TSIG) resource record (RR). However, it
25 provides no mechanism for setting up such keys other than manual
26 exchange. This document describes a Transaction Key (TKEY) RR that
27 can be used in a number of different modes to establish shared secret
28 keys between a DNS resolver and server.
29
30 Acknowledgments
31
32 The comments and ideas of the following persons (listed in alphabetic
33 order) have been incorporated herein and are gratefully acknowledged:
34
35 Olafur Gudmundsson (TIS)
36
37 Stuart Kwan (Microsoft)
38
39 Ed Lewis (TIS)
40
41 Erik Nordmark (SUN)
42
43 Brian Wellington (Nominum)
44
45
46
47
48
49
50
51
52 Eastlake Standards Track [Page 1]
53 RFC 2930 The DNS TKEY RR September 2000
54
55
56 Table of Contents
57
58 1. Introduction............................................... 2
59 1.1 Overview of Contents...................................... 3
60 2. The TKEY Resource Record................................... 4
61 2.1 The Name Field............................................ 4
62 2.2 The TTL Field............................................. 5
63 2.3 The Algorithm Field....................................... 5
64 2.4 The Inception and Expiration Fields....................... 5
65 2.5 The Mode Field............................................ 5
66 2.6 The Error Field........................................... 6
67 2.7 The Key Size and Data Fields.............................. 6
68 2.8 The Other Size and Data Fields............................ 6
69 3. General TKEY Considerations................................ 7
70 4. Exchange via Resolver Query................................ 8
71 4.1 Query for Diffie-Hellman Exchanged Keying................. 8
72 4.2 Query for TKEY Deletion................................... 9
73 4.3 Query for GSS-API Establishment........................... 10
74 4.4 Query for Server Assigned Keying.......................... 10
75 4.5 Query for Resolver Assigned Keying........................ 11
76 5. Spontaneous Server Inclusion............................... 12
77 5.1 Spontaneous Server Key Deletion........................... 12
78 6. Methods of Encryption...................................... 12
79 7. IANA Considerations........................................ 13
80 8. Security Considerations.................................... 13
81 References.................................................... 14
82 Author's Address.............................................. 15
83 Full Copyright Statement...................................... 16
84
85 1. Introduction
86
87 The Domain Name System (DNS) is a hierarchical, distributed, highly
88 available database used for bi-directional mapping between domain
89 names and addresses, for email routing, and for other information
90 [RFC 1034, 1035]. It has been extended to provide for public key
91 security and dynamic update [RFC 2535, RFC 2136]. Familiarity with
92 these RFCs is assumed.
93
94 [RFC 2845] provides a means of efficiently authenticating DNS
95 messages using shared secret keys via the TSIG resource record (RR)
96 but provides no mechanism for setting up such keys other than manual
97 exchange. This document specifies a TKEY RR that can be used in a
98 number of different modes to establish and delete such shared secret
99 keys between a DNS resolver and server.
100
101
102
103
104
105
106
107 Eastlake Standards Track [Page 2]
108 RFC 2930 The DNS TKEY RR September 2000
109
110
111 Note that TKEY established keying material and TSIGs that use it are
112 associated with DNS servers or resolvers. They are not associated
113 with zones. They may be used to authenticate queries and responses
114 but they do not provide zone based DNS data origin or denial
115 authentication [RFC 2535].
116
117 Certain modes of TKEY perform encryption which may affect their
118 export or import status for some countries. The affected modes
119 specified in this document are the server assigned mode and the
120 resolver assigned mode.
121
122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
124 document are to be interpreted as described in [RFC 2119].
125
126 In all cases herein, the term "resolver" includes that part of a
127 server which may make full and incremental [RFC 1995] zone transfer
128 queries, forwards recursive queries, etc.
129
130 1.1 Overview of Contents
131
132 Section 2 below specifies the TKEY RR and provides a description of
133 and considerations for its constituent fields.
134
135 Section 3 describes general principles of operations with TKEY.
136
137 Section 4 discusses key agreement and deletion via DNS requests with
138 the Query opcode for RR type TKEY. This method is applicable to all
139 currently defined TKEY modes, although in some cases it is not what
140 would intuitively be called a "query".
141
142 Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
143 servers which is currently used only for key deletion.
144
145 Section 6 describes encryption methods for transmitting secret key
146 information. In this document these are used only for the server
147 assigned mode and the resolver assigned mode.
148
149 Section 7 covers IANA considerations in assignment of TKEY modes.
150
151 Finally, Section 8 provides the required security considerations
152 section.
153
154
155
156
157
158
159
160
161
162 Eastlake Standards Track [Page 3]
163 RFC 2930 The DNS TKEY RR September 2000
164
165
166 2. The TKEY Resource Record
167
168 The TKEY resource record (RR) has the structure given below. Its RR
169 type code is 249.
170
171 Field Type Comment
172 ----- ---- -------
173
174 NAME domain see description below
175 TTYPE u_int16_t TKEY = 249
176 CLASS u_int16_t ignored, SHOULD be 255 (ANY)
177 TTL u_int32_t ignored, SHOULD be zero
178 RDLEN u_int16_t size of RDATA
179 RDATA:
180 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 specification
189
190 2.1 The Name Field
191
192 The Name field relates to naming keys. Its meaning differs somewhat
193 with mode and context as explained in subsequent sections.
194
195 At any DNS server or resolver only one octet string of keying
196 material may be in place for any particular key name. An attempt to
197 establish another set of keying material at a server for an existing
198 name returns a BADNAME error.
199
200 For a TKEY with a non-root name appearing in a query, the TKEY RR
201 name SHOULD be a domain locally unique at the resolver, less than 128
202 octets long in wire encoding, and meaningful to the resolver to
203 assist in distinguishing keys and/or key agreement sessions. For
204 TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
205 be a globally unique server assigned domain.
206
207 A reasonable key naming strategy is as follows:
208
209 If the key is generated as the result of a query with root as its
210 owner name, then the server SHOULD create a globally unique domain
211 name, to be the key name, by suffixing a pseudo-random [RFC 1750]
212 label with a domain name of the server. For example
213 89n3mDgX072pp.server1.example.com. If generation of a new
214
215
216
217 Eastlake Standards Track [Page 4]
218 RFC 2930 The DNS TKEY RR September 2000
219
220
221 pseudo-random name in each case is an excessive computation load
222 or entropy drain, a serial number prefix can be added to a fixed
223 pseudo-random name generated an DNS server start time, such as
224 1001.89n3mDgX072pp.server1.example.com.
225
226 If the key is generated as the result of a query with a non-root
227 name, say 789.resolver.example.net, then use the concatenation of
228 that with a name of the server. For example
229 789.resolver.example.net.server1.example.com.
230
231 2.2 The TTL Field
232
233 The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
234 be sure that older DNS implementations do not cache TKEY RRs.
235
236 2.3 The Algorithm Field
237
238 The algorithm name is in the form of a domain name with the same
239 meaning as in [RFC 2845]. The algorithm determines how the secret
240 keying material agreed to using the TKEY RR is actually used to
241 derive the algorithm specific key.
242
243 2.4 The Inception and Expiration Fields
244
245 The inception time and expiration times are in number of seconds
246 since the beginning of 1 January 1970 GMT ignoring leap seconds
247 treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
248 between a DNS resolver and a DNS server where these fields are
249 meaningful, they are either the requested validity interval for the
250 keying material asked for or specify the validity interval of keying
251 material provided.
252
253 To avoid different interpretations of the inception and expiration
254 times in TKEY RRs, resolvers and servers exchanging them must have
255 the same idea of what time it is. One way of doing this is with the
256 NTP protocol [RFC 2030] but that or any other time synchronization
257 used for this purpose MUST be done securely.
258
259 2.5 The Mode Field
260
261 The mode field specifies the general scheme for key agreement or the
262 purpose of the TKEY DNS message. Servers and resolvers supporting
263 this specification MUST implement the Diffie-Hellman key agreement
264 mode and the key deletion mode for queries. All other modes are
265 OPTIONAL. A server supporting TKEY that receives a TKEY request with
266 a mode it does not support returns the BADMODE error. The following
267 values of the Mode octet are defined, available, or reserved:
268
269
270
271
272 Eastlake Standards Track [Page 5]
273 RFC 2930 The DNS TKEY RR September 2000
274
275
276 Value Description
277 ----- -----------
278 0 - reserved, see section 7
279 1 server assignment
280 2 Diffie-Hellman exchange
281 3 GSS-API negotiation
282 4 resolver assignment
283 5 key deletion
284 6-65534 - available, see section 7
285 65535 - reserved, see section 7
286
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
287 2.6 The Error Field
288
289 The error code field is an extended RCODE. The following values are
290 defined:
291
292 Value Description
293 ----- -----------
294 0 - no error
295 1-15 a non-extended RCODE
296 16 BADSIG (TSIG)
297 17 BADKEY (TSIG)
298 18 BADTIME (TSIG)
299 19 BADMODE
300 20 BADNAME
301 21 BADALG
302
303 When the TKEY Error Field is non-zero in a response to a TKEY query,
304 the DNS header RCODE field indicates no error. However, it is
305 possible if a TKEY is spontaneously included in a response the TKEY
306 RR and DNS header error field could have unrelated non-zero error
307 codes.
308
309 2.7 The Key Size and Data Fields
310
311 The key data size field is an unsigned 16 bit integer in network
312 order which specifies the size of the key exchange data field in
313 octets. The meaning of this data depends on the mode.
314
315 2.8 The Other Size and Data Fields
316
317 The Other Size and Other Data fields are not used in this
318 specification but may be used in future extensions. The RDLEN field
319 MUST equal the length of the RDATA section through the end of Other
320 Data or the RR is to be considered malformed and rejected.
321
322
323
324
325
326
327 Eastlake Standards Track [Page 6]
328 RFC 2930 The DNS TKEY RR September 2000
329
330
331 3. General TKEY Considerations
332
333 TKEY is a meta-RR that is not stored or cached in the DNS and does
334 not appear in zone files. It supports a variety of modes for the
335 establishment and deletion of shared secret keys information between
336 DNS resolvers and servers. The establishment of such a shared key
337 requires that state be maintained at both ends and the allocation of
338 the resources to maintain such state may require mutual agreement. In
339 the absence of willingness to provide such state, servers MUST return
340 errors such as NOTIMP or REFUSED for an attempt to use TKEY and
341 resolvers are free to ignore any TKEY RRs they receive.
342
343 The shared secret keying material developed by using TKEY is a plain
344 octet sequence. The means by which this shared secret keying
345 material, exchanged via TKEY, is actually used in any particular TSIG
346 algorithm is algorithm dependent and is defined in connection with
347 that algorithm. For example, see [RFC 2104] for how TKEY agreed
348 shared secret keying material is used in the HMAC-MD5 algorithm or
349 other HMAC algorithms.
350
351 There MUST NOT be more than one TKEY RR in a DNS query or response.
352
353 Except for GSS-API mode, TKEY responses MUST always have DNS
354 transaction authentication to protect the integrity of any keying
355 data, error codes, etc. This authentication MUST use a previously
356 established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
357 NOT use any key that the response to be verified is itself providing.
358
359 TKEY queries MUST be authenticated for all modes except GSS-API and,
360 under some circumstances, server assignment mode. In particular, if
361 the query for a server assigned key is for a key to assert some
362 privilege, such as update authority, then the query must be
363 authenticated to avoid spoofing. However, if the key is just to be
364 used for transaction security, then spoofing will lead at worst to
365 denial of service. Query authentication SHOULD use an established
366 secret (TSIG) key authenticator if available. Otherwise, it must use
367 a public (SIG(0)) key signature. It MUST NOT use any key that the
368 query is itself providing.
369
370 In the absence of required TKEY authentication, a NOTAUTH error MUST
371 be returned.
372
373 To avoid replay attacks, it is necessary that a TKEY response or
374 query not be valid if replayed on the order of 2**32 second (about
375 136 years), or a multiple thereof, later. To accomplish this, the
376 keying material used in any TSIG or SIG(0) RR that authenticates a
377 TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
378
379
380
381
382 Eastlake Standards Track [Page 7]
383 RFC 2930 The DNS TKEY RR September 2000
384
385
386 (about 68 years). Thus, on attempted replay, the authenticating TSIG
387 or SIG(0) RR will not be verifiable due to key expiration and the
388 replay will fail.
389
390 4. Exchange via Resolver Query
391
392 One method for a resolver and a server to agree about shared secret
393 keying material for use in TSIG is through DNS requests from the
394 resolver which are syntactically DNS queries for type TKEY. Such
395 queries MUST be accompanied by a TKEY RR in the additional
396 information section to indicate the mode in use and accompanied by
397 other information where required.
398
399 Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
400 ignore the recursive header bit in TKEY queries they receive.
401
402 4.1 Query for Diffie-Hellman Exchanged Keying
403
404 Diffie-Hellman (DH) key exchange is a means whereby two parties can
405 derive some shared secret information without requiring any secrecy
406 of the messages they exchange [Schneier]. Provisions have been made
407 for the storage of DH public keys in the DNS [RFC 2539].
408
409 A resolver sends a query for type TKEY accompanied by a TKEY RR in
410 the additional information section specifying the Diffie-Hellman mode
411 and accompanied by a KEY RR also in the additional information
412 section specifying a resolver Diffie-Hellman key. The TKEY RR
413 algorithm field is set to the authentication algorithm the resolver
414 plans to use. The "key data" provided in the TKEY is used as a random
415 [RFC 1750] nonce to avoid always deriving the same keying material
416 for the same pair of DH KEYs.
417
418 The server response contains a TKEY in its answer section with the
419 Diffie-Hellman mode. The "key data" provided in this TKEY is used as
420 an additional nonce to avoid always deriving the same keying material
421 for the same pair of DH KEYs. If the TKEY error field is non-zero,
422 the query failed for the reason given. FORMERR is given if the query
423 included no DH KEY and BADKEY is given if the query included an
424 incompatible DH KEY.
425
426 If the TKEY error field is zero, the resolver supplied Diffie-Hellman
427 KEY RR SHOULD be echoed in the additional information section and a
428 server Diffie-Hellman KEY RR will also be present in the answer
429 section of the response. Both parties can then calculate the same
430 shared secret quantity from the pair of Diffie-Hellman (DH) keys used
431 [Schneier] (provided these DH keys use the same generator and
432 modulus) and the data in the TKEY RRs. The TKEY RR data is mixed
433 with the DH result as follows:
434
435
436
437 Eastlake Standards Track [Page 8]
438 RFC 2930 The DNS TKEY RR September 2000
439
440
441 keying material =
442 XOR ( DH value, MD5 ( query data | DH value ) |
443 MD5 ( server data | DH value ) )
444
445 Where XOR is an exclusive-OR operation and "|" is byte-stream
446 concatenation. The shorter of the two operands to XOR is byte-wise
447 left justified and padded with zero-valued bytes to match the length
448 of the other operand. "DH value" is the Diffie-Hellman value derived
449 from the KEY RRs. Query data and server data are the values sent in
450 the TKEY RR data fields. These "query data" and "server data" nonces
451 are suffixed by the DH value, digested by MD5, the results
452 concatenated, and then XORed with the DH value.
453
454 The inception and expiry times in the query TKEY RR are those
455 requested for the keying material. The inception and expiry times in
456 the response TKEY RR are the maximum period the server will consider
457 the keying material valid. Servers may pre-expire keys so this is
458 not a guarantee.
459
460 4.2 Query for TKEY Deletion
461
462 Keys established via TKEY can be treated as soft state. Since DNS
463 transactions are originated by the resolver, the resolver can simply
464 toss keys, although it may have to go through another key exchange if
465 it later needs one. Similarly, the server can discard keys although
466 that will result in an error on receiving a query with a TSIG using
467 the discarded key.
468
469 To avoid attempted reliance in requests on keys no longer in effect,
470 servers MUST implement key deletion whereby the server "discards" a
471 key on receipt from a resolver of an authenticated delete request for
472 a TKEY RR with the key's name. If the server has no record of a key
473 with that name, it returns BADNAME.
474
475 Key deletion TKEY queries MUST be authenticated. This authentication
476 MAY be a TSIG RR using the key to be deleted.
477
478 For querier assigned and Diffie-Hellman keys, the server MUST truly
479 "discard" all active state associated with the key. For server
480 assigned keys, the server MAY simply mark the key as no longer
481 retained by the client and may re-send it in response to a future
482 query for server assigned keying material.
483
484
485
486
487
488
489
490
491
492 Eastlake Standards Track [Page 9]
493 RFC 2930 The DNS TKEY RR September 2000
494
495
496 4.3 Query for GSS-API Establishment
497
498 This mode is described in a separate document under preparation which
499 should be seen for the full description. Basically the resolver and
500 server can exchange queries and responses for type TKEY with a TKEY
501 RR specifying the GSS-API mode in the additional information section
502 and a GSS-API token in the key data portion of the TKEY RR.
503
504 Any issues of possible encryption of parts the GSS-API token data
505 being transmitted are handled by the GSS-API level. In addition, the
506 GSS-API level provides its own authentication so that this mode of
507 TKEY query and response MAY be, but do not need to be, authenticated
508 with TSIG RR or SIG(0) RR [RFC 2931].
509
510 The inception and expiry times in a GSS-API mode TKEY RR are ignored.
511
512 4.4 Query for Server Assigned Keying
513
514 Optionally, the server can assign keying for the resolver. It is
515 sent to the resolver encrypted under a resolver public key. See
516 section 6 for description of encryption methods.
517
518 A resolver sends a query for type TKEY accompanied by a TKEY RR
519 specifying the "server assignment" mode and a resolver KEY RR to be
520 used in encrypting the response, both in the additional information
521 section. The TKEY algorithm field is set to the authentication
522 algorithm the resolver plans to use. It is RECOMMENDED that any "key
523 data" provided in the query TKEY RR by the resolver be strongly mixed
524 by the server with server generated randomness [RFC 1750] to derive
525 the keying material to be used. The KEY RR that appears in the query
526 need not be accompanied by a SIG(KEY) RR. If the query is
527 authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
528 and that authentication is verified, then any SIG(KEY) provided in
529 the query SHOULD be ignored. The KEY RR in such a query SHOULD have
530 a name that corresponds to the resolver but it is only essential that
531 it be a public key for which the resolver has the corresponding
532 private key so it can decrypt the response data.
533
534 The server response contains a TKEY RR in its answer section with the
535 server assigned mode and echoes the KEY RR provided in the query in
536 its additional information section.
537
538 If the response TKEY error field is zero, the key data portion of the
539 response TKEY RR will be the server assigned keying data encrypted
540 under the public key in the resolver provided KEY RR. In this case,
541 the owner name of the answer TKEY RR will be the server assigned name
542 of the key.
543
544
545
546
547 Eastlake Standards Track [Page 10]
548 RFC 2930 The DNS TKEY RR September 2000
549
550
551 If the error field of the response TKEY is non-zero, the query failed
552 for the reason given. FORMERR is given if the query specified no
553 encryption key.
554
555 The inception and expiry times in the query TKEY RR are those
556 requested for the keying material. The inception and expiry times in
557 the response TKEY are the maximum period the server will consider the
558 keying material valid. Servers may pre-expire keys so this is not a
559 guarantee.
560
561 The resolver KEY RR MUST be authenticated, through the authentication
562 of this query with a TSIG or SIG(0) or the signing of the resolver
563 KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY
564 for which they know the private key, and thereby the attacker could
565 obtain a valid shared secret key from the server.
566
567 4.5 Query for Resolver Assigned Keying
568
569 Optionally, a server can accept resolver assigned keys. The keying
570 material MUST be encrypted under a server key for protection in
571 transmission as described in Section 6.
572
573 The resolver sends a TKEY query with a TKEY RR that specifies the
574 encrypted keying material and a KEY RR specifying the server public
575 key used to encrypt the data, both in the additional information
576 section. The name of the key and the keying data are completely
577 controlled by the sending resolver so a globally unique key name
578 SHOULD be used. The KEY RR used MUST be one for which the server has
579 the corresponding private key, or it will not be able to decrypt the
580 keying material and will return a FORMERR. It is also important that
581 no untrusted party (preferably no other party than the server) has
582 the private key corresponding to the KEY RR because, if they do, they
583 can capture the messages to the server, learn the shared secret, and
584 spoof valid TSIGs.
585
586 The query TKEY RR inception and expiry give the time period the
587 querier intends to consider the keying material valid. The server
588 can return a lesser time interval to advise that it will not maintain
589 state for that long and can pre-expire keys in any case.
590
591 This mode of query MUST be authenticated with a TSIG or SIG(0).
592 Otherwise, an attacker can forge a resolver assigned TKEY query, and
593 thereby the attacker could specify a shared secret key that would be
594 accepted, used, and honored by the server.
595
596
597
598
599
600
601
602 Eastlake Standards Track [Page 11]
603 RFC 2930 The DNS TKEY RR September 2000
604
605
606 5. Spontaneous Server Inclusion
607
608 A DNS server may include a TKEY RR spontaneously as additional
609 information in responses. This SHOULD only be done if the server
610 knows the querier understands TKEY and has this option implemented.
611 This technique can be used to delete a key and may be specified for
612 modes defined in the future. A disadvantage of this technique is
613 that there is no way for the server to get any error or success
614 indication back and, in the case of UDP, no way to even know if the
615 DNS response reached the resolver.
616
617 5.1 Spontaneous Server Key Deletion
618
619 A server can optionally tell a client that it has deleted a secret
620 key by spontaneously including a TKEY RR in the additional
621 information section of a response with the key's name and specifying
622 the key deletion mode. Such a response SHOULD be authenticated. If
623 authenticated, it "deletes" the key with the given name. The
624 inception and expiry times of the delete TKEY RR are ignored. Failure
625 by a client to receive or properly process such additional
626 information in a response would mean that the client might use a key
627 that the server had discarded and would then get an error indication.
628
629 For server assigned and Diffie-Hellman keys, the client MUST
630 "discard" active state associated with the key. For querier assigned
631 keys, the querier MAY simply mark the key as no longer retained by
632 the server and may re-send it in a future query specifying querier
633 assigned keying material.
634
635 6. Methods of Encryption
636
637 For the server assigned and resolver assigned key agreement modes,
638 the keying material is sent within the key data field of a TKEY RR
639 encrypted under the public key in an accompanying KEY RR [RFC 2535].
640 This KEY RR MUST be for a public key algorithm where the public and
641 private keys can be used for encryption and the corresponding
642 decryption which recovers the originally encrypted data. The KEY RR
643 SHOULD correspond to a name for the decrypting resolver/server such
644 that the decrypting process has access to the corresponding private
645 key to decrypt the data. The secret keying material being sent will
646 generally be fairly short, usually less than 256 bits, because that
647 is adequate for very strong protection with modern keyed hash or
648 symmetric algorithms.
649
650 If the KEY RR specifies the RSA algorithm, then the keying material
651 is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
652 PKCS#1 [RFC 2437]. (Note, the secret keying material being sent is
653 directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
654
655
656
657 Eastlake Standards Track [Page 12]
658 RFC 2930 The DNS TKEY RR September 2000
659
660
661 some other symmetric algorithm.) In the unlikely event that the
662 keying material will not fit within one RSA modulus of the chosen
663 public key, additional RSA encryption blocks are included. The
664 length of each block is clear from the public RSA key specified and
665 the RSAES-PKCS1-v1_5 padding makes it clear what part of the
666 encrypted data is actually keying material and what part is
667 formatting or the required at least eight bytes of random [RFC 1750]
668 padding.
669
670 7. IANA Considerations
671
672 This section is to be interpreted as provided in [RFC 2434].
673
674 Mode field values 0x0000 and 0xFFFF are reserved.
675
676 Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
677 can only be assigned by an IETF Standards Action.
678
679 Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
680 are allocated by IESG approval or IETF consensus.
681
682 Mode field values 0x1000 through 0xEFFF are allocated based on
683 Specification Required as defined in [RFC 2434].
684
685 Mode values should not be changed when the status of their use
686 changes. For example, a mode value assigned based just on providing
687 a specification should not be changed later just because that use's
688 status is changed to standards track.
689
690 The following assignments are documented herein:
691
692 RR Type 249 for TKEY.
693
694 TKEY Modes 1 through 5 as listed in section 2.5.
695
696 Extended RCODE Error values of 19, 20, and 21 as listed in section
697 2.6.
698
699 8. Security Considerations
700
701 The entirety of this specification is concerned with the secure
702 establishment of a shared secret between DNS clients and servers in
703 support of TSIG [RFC 2845].
704
705 Protection against denial of service via the use of TKEY is not
706 provided.
707
708
709
710
711
712 Eastlake Standards Track [Page 13]
713 RFC 2930 The DNS TKEY RR September 2000
714
715
716 References
717
718 [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
719 Algorithms, and Source Code in C", 1996, John Wiley and
720 Sons
721
722 [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
723 STD 13, RFC 1034, November 1987.
724
725 [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
726 Specifications", STD 13, RFC 1035, November 1987.
727
728 [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
729 Recommendations for Security", RFC 1750, December 1994.
730
731 [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
732 September 1996.
733
734 [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
735 August 1996.
736
737 [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
738 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
739
740 [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
741 Hashing for Message Authentication", RFC 2104, February
742 1997.
743
744 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
745 Requirement Levels", BCP 14, RFC 2119, March 1997.
746
747 [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
748 Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
749 April 1997.
750
751 [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
752 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
753 October 1998.
754
755 [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
756 Specifications Version 2.0", RFC 2437, October 1998.
757
758 [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
759 RFC 2535, March 1999.
760
761 [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
762 Domain Name System (DNS)", RFC 2539, March 1999.
763
764
765
766
767 Eastlake Standards Track [Page 14]
768 RFC 2930 The DNS TKEY RR September 2000
769
770
771 [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
772 Wellington, "Secret Key Transaction Authentication for DNS
773 (TSIG)", RFC 2845, May 2000.
774
775 [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
776 (SIG(0)s )", RFC 2931, September 2000.
777
778 Author's Address
779
780 Donald E. Eastlake 3rd
781 Motorola
782 140 Forest Avenue
783 Hudson, MA 01749 USA
784
785 Phone: +1 978-562-2827 (h)
786 +1 508-261-5434 (w)
787 Fax: +1 508-261-4447 (w)
788 EMail: Donald.Eastlake@motorola.com
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822 Eastlake Standards Track [Page 15]
823 RFC 2930 The DNS TKEY RR September 2000
824
825
826 Full Copyright Statement
827
828 Copyright (C) The Internet Society (2000). All Rights Reserved.
829
830 This document and translations of it may be copied and furnished to
831 others, and derivative works that comment on or otherwise explain it
832 or assist in its implementation may be prepared, copied, published
833 and distributed, in whole or in part, without restriction of any
834 kind, provided that the above copyright notice and this paragraph are
835 included on all such copies and derivative works. However, this
836 document itself may not be modified in any way, such as by removing
837 the copyright notice or references to the Internet Society or other
838 Internet organizations, except as needed for the purpose of
839 developing Internet standards in which case the procedures for
840 copyrights defined in the Internet Standards process must be
841 followed, or as required to translate it into languages other than
842 English.
843
844 The limited permissions granted above are perpetual and will not be
845 revoked by the Internet Society or its successors or assigns.
846
847 This document and the information contained herein is provided on an
848 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
849 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
850 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
851 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
852 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
853
854 Acknowledgement
855
856 Funding for the RFC Editor function is currently provided by the
857 Internet Society.
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877 Eastlake Standards Track [Page 16]
878
RFC6895 clarifies "that there is one DNS error number space for headers, OPT extended headers, TSIG RRs, and TKEY RRs."