File: rfc2930.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (899 lines) | stat: -rw-r--r-- 34,894 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
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
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899






Network Working Group                                   D. Eastlake, 3rd
Request for Comments: 2930                                      Motorola
Category: Standards Track                                 September 2000


               Secret Key Establishment for DNS (TKEY RR)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   [RFC 2845] provides a means of authenticating Domain Name System
   (DNS) queries and responses using shared secret keys via the
   Transaction Signature (TSIG) resource record (RR).  However, it
   provides no mechanism for setting up such keys other than manual
   exchange. This document describes a Transaction Key (TKEY) RR that
   can be used in a number of different modes to establish shared secret
   keys between a DNS resolver and server.

Acknowledgments

   The comments and ideas of the following persons (listed in alphabetic
   order) have been incorporated herein and are gratefully acknowledged:

         Olafur Gudmundsson (TIS)

         Stuart Kwan (Microsoft)

         Ed Lewis (TIS)

         Erik Nordmark (SUN)

         Brian Wellington (Nominum)








Eastlake                    Standards Track                     [Page 1]

RFC 2930                    The DNS TKEY RR               September 2000


Table of Contents

   1. Introduction...............................................  2
   1.1 Overview of Contents......................................  3
   2. The TKEY Resource Record...................................  4
   2.1 The Name Field............................................  4
   2.2 The TTL Field.............................................  5
   2.3 The Algorithm Field.......................................  5
   2.4 The Inception and Expiration Fields.......................  5
   2.5 The Mode Field............................................  5
   2.6 The Error Field...........................................  6
   2.7 The Key Size and Data Fields..............................  6
   2.8 The Other Size and Data Fields............................  6
   3. General TKEY Considerations................................  7
   4. Exchange via Resolver Query................................  8
   4.1 Query for Diffie-Hellman Exchanged Keying.................  8
   4.2 Query for TKEY Deletion...................................  9
   4.3 Query for GSS-API Establishment........................... 10
   4.4 Query for Server Assigned Keying.......................... 10
   4.5 Query for Resolver Assigned Keying........................ 11
   5. Spontaneous Server Inclusion............................... 12
   5.1 Spontaneous Server Key Deletion........................... 12
   6. Methods of Encryption...................................... 12
   7. IANA Considerations........................................ 13
   8. Security Considerations.................................... 13
   References.................................................... 14
   Author's Address.............................................. 15
   Full Copyright Statement...................................... 16

1. Introduction

   The Domain Name System (DNS) is a hierarchical, distributed, highly
   available database used for bi-directional mapping between domain
   names and addresses, for email routing, and for other information
   [RFC 1034, 1035].  It has been extended to provide for public key
   security and dynamic update [RFC 2535, RFC 2136].  Familiarity with
   these RFCs is assumed.

   [RFC 2845] provides a means of efficiently authenticating DNS
   messages using shared secret keys via the TSIG resource record (RR)
   but provides no mechanism for setting up such keys other than manual
   exchange. This document specifies a TKEY RR that can be used in a
   number of different modes to establish and delete such shared secret
   keys between a DNS resolver and server.







Eastlake                    Standards Track                     [Page 2]

RFC 2930                    The DNS TKEY RR               September 2000


   Note that TKEY established keying material and TSIGs that use it are
   associated with DNS servers or resolvers.  They are not associated
   with zones.  They may be used to authenticate queries and responses
   but they do not provide zone based DNS data origin or denial
   authentication [RFC 2535].

   Certain modes of TKEY perform encryption which may affect their
   export or import status for some countries.  The affected modes
   specified in this document are the server assigned mode and the
   resolver assigned mode.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

   In all cases herein, the term "resolver" includes that part of a
   server which may make full and incremental [RFC 1995] zone transfer
   queries, forwards recursive queries, etc.

1.1 Overview of Contents

   Section 2 below specifies the TKEY RR and provides a description of
   and considerations for its constituent fields.

   Section 3 describes general principles of operations with TKEY.

   Section 4 discusses key agreement and deletion via DNS requests with
   the Query opcode for RR type TKEY.  This method is applicable to all
   currently defined TKEY modes, although in some cases it is not what
   would intuitively be called a "query".

   Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
   servers which is currently used only for key deletion.

   Section 6 describes encryption methods for transmitting secret key
   information. In this document these are used only for the server
   assigned mode and the resolver assigned mode.

   Section 7 covers IANA considerations in assignment of TKEY modes.

   Finally, Section 8 provides the required security considerations
   section.









Eastlake                    Standards Track                     [Page 3]

RFC 2930                    The DNS TKEY RR               September 2000


2. The TKEY Resource Record

   The TKEY resource record (RR) has the structure given below.  Its RR
   type code is 249.

      Field       Type         Comment
      -----       ----         -------

      NAME         domain      see description below
      TTYPE        u_int16_t   TKEY = 249
      CLASS        u_int16_t   ignored, SHOULD be 255 (ANY)
      TTL          u_int32_t   ignored, SHOULD be zero
      RDLEN        u_int16_t   size of RDATA
      RDATA:
       Algorithm:   domain
       Inception:   u_int32_t
       Expiration:  u_int32_t
       Mode:        u_int16_t
       Error:       u_int16_t
       Key Size:    u_int16_t
       Key Data:    octet-stream
       Other Size:  u_int16_t
       Other Data:  octet-stream  undefined by this specification

2.1 The Name Field

   The Name field relates to naming keys.  Its meaning differs somewhat
   with mode and context as explained in subsequent sections.

   At any DNS server or resolver only one octet string of keying
   material may be in place for any particular key name.  An attempt to
   establish another set of keying material at a server for an existing
   name returns a BADNAME error.

   For a TKEY with a non-root name appearing in a query, the TKEY RR
   name SHOULD be a domain locally unique at the resolver, less than 128
   octets long in wire encoding, and meaningful to the resolver to
   assist in distinguishing keys and/or key agreement sessions.   For
   TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
   be a globally unique server assigned domain.

   A reasonable key naming strategy is as follows:

      If the key is generated as the result of a query with root as its
      owner name, then the server SHOULD create a globally unique domain
      name, to be the key name, by suffixing a pseudo-random [RFC 1750]
      label with a domain name of the server.  For example
      89n3mDgX072pp.server1.example.com.  If generation of a new



Eastlake                    Standards Track                     [Page 4]

RFC 2930                    The DNS TKEY RR               September 2000


      pseudo-random name in each case is an excessive computation load
      or entropy drain, a serial number prefix can be added to a fixed
      pseudo-random name generated an DNS server start time, such as
      1001.89n3mDgX072pp.server1.example.com.

      If the key is generated as the result of a query with a non-root
      name, say 789.resolver.example.net, then use the concatenation of
      that with a name of the server.  For example
      789.resolver.example.net.server1.example.com.

2.2 The TTL Field

   The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
   be sure that older DNS implementations do not cache TKEY RRs.

2.3 The Algorithm Field

   The algorithm name is in the form of a domain name with the same
   meaning as in [RFC 2845].  The algorithm determines how the secret
   keying material agreed to using the TKEY RR is actually used to
   derive the algorithm specific key.

2.4 The Inception and Expiration Fields

   The inception time and expiration times are in number of seconds
   since the beginning of 1 January 1970 GMT ignoring leap seconds
   treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
   between a DNS resolver and a DNS server where these fields are
   meaningful, they are either the requested validity interval for the
   keying material asked for or specify the validity interval of keying
   material provided.

   To avoid different interpretations of the inception and expiration
   times in TKEY RRs, resolvers and servers exchanging them must have
   the same idea of what time it is.  One way of doing this is with the
   NTP protocol [RFC 2030] but that or any other time synchronization
   used for this purpose MUST be done securely.

2.5 The Mode Field

   The mode field specifies the general scheme for key agreement or the
   purpose of the TKEY DNS message.  Servers and resolvers supporting
   this specification MUST implement the Diffie-Hellman key agreement
   mode and the key deletion mode for queries.  All other modes are
   OPTIONAL.  A server supporting TKEY that receives a TKEY request with
   a mode it does not support returns the BADMODE error.  The following
   values of the Mode octet are defined, available, or reserved:




Eastlake                    Standards Track                     [Page 5]

RFC 2930                    The DNS TKEY RR               September 2000


         Value    Description
         -----    -----------
          0        - reserved, see section 7
          1       server assignment
          2       Diffie-Hellman exchange
          3       GSS-API negotiation
          4       resolver assignment
          5       key deletion
         6-65534   - available, see section 7
         65535     - reserved, see section 7

2.6 The Error Field

   The error code field is an extended RCODE.  The following values are
   defined:

         Value   Description
         -----   -----------
          0       - no error
          1-15   a non-extended RCODE
          16     BADSIG   (TSIG)
          17     BADKEY   (TSIG)
          18     BADTIME  (TSIG)
          19     BADMODE
          20     BADNAME
          21     BADALG

   When the TKEY Error Field is non-zero in a response to a TKEY query,
   the DNS header RCODE field indicates no error. However, it is
   possible if a TKEY is spontaneously included in a response the TKEY
   RR and DNS header error field could have unrelated non-zero error
   codes.

2.7 The Key Size and Data Fields

   The key data size field is an unsigned 16 bit integer in network
   order which specifies the size of the key exchange data field in
   octets. The meaning of this data depends on the mode.

2.8 The Other Size and Data Fields

   The Other Size and Other Data fields are not used in this
   specification but may be used in future extensions.  The RDLEN field
   MUST equal the length of the RDATA section through the end of Other
   Data or the RR is to be considered malformed and rejected.






Eastlake                    Standards Track                     [Page 6]

RFC 2930                    The DNS TKEY RR               September 2000


3. General TKEY Considerations

   TKEY is a meta-RR that is not stored or cached in the DNS and does
   not appear in zone files.  It supports a variety of modes for the
   establishment and deletion of shared secret keys information between
   DNS resolvers and servers.  The establishment of such a shared key
   requires that state be maintained at both ends and the allocation of
   the resources to maintain such state may require mutual agreement. In
   the absence of willingness to provide such state, servers MUST return
   errors such as NOTIMP or REFUSED for an attempt to use TKEY and
   resolvers are free to ignore any TKEY RRs they receive.

   The shared secret keying material developed by using TKEY is a plain
   octet sequence.  The means by which this shared secret keying
   material, exchanged via TKEY, is actually used in any particular TSIG
   algorithm is algorithm dependent and is defined in connection with
   that algorithm.  For example, see [RFC 2104] for how TKEY agreed
   shared secret keying material is used in the HMAC-MD5 algorithm or
   other HMAC algorithms.

   There MUST NOT be more than one TKEY RR in a DNS query or response.

   Except for GSS-API mode, TKEY responses MUST always have DNS
   transaction authentication to protect the integrity of any keying
   data, error codes, etc.  This authentication MUST use a previously
   established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
   NOT use any key that the response to be verified is itself providing.

   TKEY queries MUST be authenticated for all modes except GSS-API and,
   under some circumstances, server assignment mode.  In particular, if
   the query for a server assigned key is for a key to assert some
   privilege, such as update authority, then the query must be
   authenticated to avoid spoofing.  However, if the key is just to be
   used for transaction security, then spoofing will lead at worst to
   denial of service.  Query authentication SHOULD use an established
   secret (TSIG) key authenticator if available.  Otherwise, it must use
   a public (SIG(0)) key signature.  It MUST NOT use any key that the
   query is itself providing.

   In the absence of required TKEY authentication, a NOTAUTH error MUST
   be returned.

   To avoid replay attacks, it is necessary that a TKEY response or
   query not be valid if replayed on the order of 2**32 second (about
   136 years), or a multiple thereof, later.  To accomplish this, the
   keying material used in any TSIG or SIG(0) RR that authenticates a
   TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds




Eastlake                    Standards Track                     [Page 7]

RFC 2930                    The DNS TKEY RR               September 2000


   (about 68 years).  Thus, on attempted replay, the authenticating TSIG
   or SIG(0) RR will not be verifiable due to key expiration and the
   replay will fail.

4. Exchange via Resolver Query

   One method for a resolver and a server to agree about shared secret
   keying material for use in TSIG is through DNS requests from the
   resolver which are syntactically DNS queries for type TKEY.  Such
   queries MUST be accompanied by a TKEY RR in the additional
   information section to indicate the mode in use and accompanied by
   other information where required.

   Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
   ignore the recursive header bit in TKEY queries they receive.

4.1 Query for Diffie-Hellman Exchanged Keying

   Diffie-Hellman (DH) key exchange is a means whereby two parties can
   derive some shared secret information without requiring any secrecy
   of the messages they exchange [Schneier].  Provisions have been made
   for the storage of DH public keys in the DNS [RFC 2539].

   A resolver sends a query for type TKEY accompanied by a TKEY RR in
   the additional information section specifying the Diffie-Hellman mode
   and accompanied by a KEY RR also in the additional information
   section specifying a resolver Diffie-Hellman key.  The TKEY RR
   algorithm field is set to the authentication algorithm the resolver
   plans to use. The "key data" provided in the TKEY is used as a random
   [RFC 1750] nonce to avoid always deriving the same keying material
   for the same pair of DH KEYs.

   The server response contains a TKEY in its answer section with the
   Diffie-Hellman mode. The "key data" provided in this TKEY is used as
   an additional nonce to avoid always deriving the same keying material
   for the same pair of DH KEYs. If the TKEY error field is non-zero,
   the query failed for the reason given. FORMERR is given if the query
   included no DH KEY and BADKEY is given if the query included an
   incompatible DH KEY.

   If the TKEY error field is zero, the resolver supplied Diffie-Hellman
   KEY RR SHOULD be echoed in the additional information section and a
   server Diffie-Hellman KEY RR will also be present in the answer
   section of the response.  Both parties can then calculate the same
   shared secret quantity from the pair of Diffie-Hellman (DH) keys used
   [Schneier] (provided these DH keys use the same generator and
   modulus) and the data in the TKEY RRs.  The TKEY RR data is mixed
   with the DH result as follows:



Eastlake                    Standards Track                     [Page 8]

RFC 2930                    The DNS TKEY RR               September 2000


      keying material =
           XOR ( DH value, MD5 ( query data | DH value ) |
                           MD5 ( server data | DH value ) )

   Where XOR is an exclusive-OR operation and "|" is byte-stream
   concatenation.  The shorter of the two operands to XOR is byte-wise
   left justified and padded with zero-valued bytes to match the length
   of the other operand.  "DH value" is the Diffie-Hellman value derived
   from the KEY RRs. Query data and server data are the values sent in
   the TKEY RR data fields.  These "query data" and "server data" nonces
   are suffixed by the DH value, digested by MD5, the results
   concatenated, and then XORed with the DH value.

   The inception and expiry times in the query TKEY RR are those
   requested for the keying material.  The inception and expiry times in
   the response TKEY RR are the maximum period the server will consider
   the keying material valid.  Servers may pre-expire keys so this is
   not a guarantee.

4.2 Query for TKEY Deletion

   Keys established via TKEY can be treated as soft state.  Since DNS
   transactions are originated by the resolver, the resolver can simply
   toss keys, although it may have to go through another key exchange if
   it later needs one.  Similarly, the server can discard keys although
   that will result in an error on receiving a query with a TSIG using
   the discarded key.

   To avoid attempted reliance in requests on keys no longer in effect,
   servers MUST implement key deletion whereby the server "discards" a
   key on receipt from a resolver of an authenticated delete request for
   a TKEY RR with the key's name.  If the server has no record of a key
   with that name, it returns BADNAME.

   Key deletion TKEY queries MUST be authenticated.  This authentication
   MAY be a TSIG RR using the key to be deleted.

   For querier assigned and Diffie-Hellman keys, the server MUST truly
   "discard" all active state associated with the key.  For server
   assigned keys, the server MAY simply mark the key as no longer
   retained by the client and may re-send it in response to a future
   query for server assigned keying material.









Eastlake                    Standards Track                     [Page 9]

RFC 2930                    The DNS TKEY RR               September 2000


4.3 Query for GSS-API Establishment

   This mode is described in a separate document under preparation which
   should be seen for the full description.  Basically the resolver and
   server can exchange queries and responses for type TKEY with a TKEY
   RR specifying the GSS-API mode in the additional information section
   and a GSS-API token in the key data portion of the TKEY RR.

   Any issues of possible encryption of parts the GSS-API token data
   being transmitted are handled by the GSS-API level.  In addition, the
   GSS-API level provides its own authentication so that this mode of
   TKEY query and response MAY be, but do not need to be, authenticated
   with TSIG RR or SIG(0) RR [RFC 2931].

   The inception and expiry times in a GSS-API mode TKEY RR are ignored.

4.4 Query for Server Assigned Keying

   Optionally, the server can assign keying for the resolver.  It is
   sent to the resolver encrypted under a resolver public key.  See
   section 6 for description of encryption methods.

   A resolver sends a query for type TKEY accompanied by a TKEY RR
   specifying the "server assignment" mode and a resolver KEY RR to be
   used in encrypting the response, both in the additional information
   section. The TKEY algorithm field is set to the authentication
   algorithm the resolver plans to use.  It is RECOMMENDED that any "key
   data" provided in the query TKEY RR by the resolver be strongly mixed
   by the server with server generated randomness [RFC 1750] to derive
   the keying material to be used.  The KEY RR that appears in the query
   need not be accompanied by a SIG(KEY) RR.  If the query is
   authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
   and that authentication is verified, then any SIG(KEY) provided in
   the query SHOULD be ignored.  The KEY RR in such a query SHOULD have
   a name that corresponds to the resolver but it is only essential that
   it be a public key for which the resolver has the corresponding
   private key so it can decrypt the response data.

   The server response contains a TKEY RR in its answer section with the
   server assigned mode and echoes the KEY RR provided in the query in
   its additional information section.

   If the response TKEY error field is zero, the key data portion of the
   response TKEY RR will be the server assigned keying data encrypted
   under the public key in the resolver provided KEY RR.  In this case,
   the owner name of the answer TKEY RR will be the server assigned name
   of the key.




Eastlake                    Standards Track                    [Page 10]

RFC 2930                    The DNS TKEY RR               September 2000


   If the error field of the response TKEY is non-zero, the query failed
   for the reason given.  FORMERR is given if the query specified no
   encryption key.

   The inception and expiry times in the query TKEY RR are those
   requested for the keying material.  The inception and expiry times in
   the response TKEY are the maximum period the server will consider the
   keying material valid.  Servers may pre-expire keys so this is not a
   guarantee.

   The resolver KEY RR MUST be authenticated, through the authentication
   of this query with a TSIG or SIG(0) or the signing of the resolver
   KEY with a SIG(KEY).  Otherwise, an attacker can forge a resolver KEY
   for which they know the private key, and thereby the attacker could
   obtain a valid shared secret key from the server.

4.5 Query for Resolver Assigned Keying

   Optionally, a server can accept resolver assigned keys.  The keying
   material MUST be encrypted under a server key for protection in
   transmission as described in Section 6.

   The resolver sends a TKEY query with a TKEY RR that specifies the
   encrypted keying material and a KEY RR specifying the server public
   key used to encrypt the data, both in the additional information
   section.  The name of the key and the keying data are completely
   controlled by the sending resolver so a globally unique key name
   SHOULD be used.  The KEY RR used MUST be one for which the server has
   the corresponding private key, or it will not be able to decrypt the
   keying material and will return a FORMERR. It is also important that
   no untrusted party (preferably no other party than the server) has
   the private key corresponding to the KEY RR because, if they do, they
   can capture the messages to the server, learn the shared secret, and
   spoof valid TSIGs.

   The query TKEY RR inception and expiry give the time period the
   querier intends to consider the keying material valid.  The server
   can return a lesser time interval to advise that it will not maintain
   state for that long and can pre-expire keys in any case.

   This mode of query MUST be authenticated with a TSIG or SIG(0).
   Otherwise, an attacker can forge a resolver assigned TKEY query, and
   thereby the attacker could specify a shared secret key that would be
   accepted, used, and honored by the server.







Eastlake                    Standards Track                    [Page 11]

RFC 2930                    The DNS TKEY RR               September 2000


5. Spontaneous Server Inclusion

   A DNS server may include a TKEY RR spontaneously as additional
   information in responses.  This SHOULD only be done if the server
   knows the querier understands TKEY and has this option implemented.
   This technique can be used to delete a key and may be specified for
   modes defined in the future.  A disadvantage of this technique is
   that there is no way for the server to get any error or success
   indication back and, in the case of UDP, no way to even know if the
   DNS response reached the resolver.

5.1 Spontaneous Server Key Deletion

   A server can optionally tell a client that it has deleted a secret
   key by spontaneously including a TKEY RR in the additional
   information section of a response with the key's name and specifying
   the key deletion mode.  Such a response SHOULD be authenticated.  If
   authenticated, it "deletes" the key with the given name.  The
   inception and expiry times of the delete TKEY RR are ignored. Failure
   by a client to receive or properly process such additional
   information in a response would mean that the client might use a key
   that the server had discarded and would then get an error indication.

   For server assigned and Diffie-Hellman keys, the client MUST
   "discard" active state associated with the key.  For querier assigned
   keys, the querier MAY simply mark the key as no longer retained by
   the server and may re-send it in a future query specifying querier
   assigned keying material.

6. Methods of Encryption

   For the server assigned and resolver assigned key agreement modes,
   the keying material is sent within the key data field of a TKEY RR
   encrypted under the public key in an accompanying KEY RR [RFC 2535].
   This KEY RR MUST be for a public key algorithm where the public and
   private keys can be used for encryption and the corresponding
   decryption which recovers the originally encrypted data.  The KEY RR
   SHOULD correspond to a name for the decrypting resolver/server such
   that the decrypting process has access to the corresponding private
   key to decrypt the data.  The secret keying material being sent will
   generally be fairly short, usually less than 256 bits, because that
   is adequate for very strong protection with modern keyed hash or
   symmetric algorithms.

   If the KEY RR specifies the RSA algorithm, then the keying material
   is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
   PKCS#1 [RFC 2437].  (Note, the secret keying material being sent is
   directly RSA encrypted in PKCS#1 format. It is not "enveloped" under



Eastlake                    Standards Track                    [Page 12]

RFC 2930                    The DNS TKEY RR               September 2000


   some other symmetric algorithm.)  In the unlikely event that the
   keying material will not fit within one RSA modulus of the chosen
   public key, additional RSA encryption blocks are included.  The
   length of each block is clear from the public RSA key specified and
   the RSAES-PKCS1-v1_5 padding makes it clear what part of the
   encrypted data is actually keying material and what part is
   formatting or the required at least eight bytes of random [RFC 1750]
   padding.

7. IANA Considerations

   This section is to be interpreted as provided in [RFC 2434].

   Mode field values 0x0000 and 0xFFFF are reserved.

   Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
   can only be assigned by an IETF Standards Action.

   Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
   are allocated by IESG approval or IETF consensus.

   Mode field values 0x1000 through 0xEFFF are allocated based on
   Specification Required as defined in [RFC 2434].

   Mode values should not be changed when the status of their use
   changes.  For example, a mode value assigned based just on providing
   a specification should not be changed later just because that use's
   status is changed to standards track.

   The following assignments are documented herein:

      RR Type 249 for TKEY.

      TKEY Modes 1 through 5 as listed in section 2.5.

      Extended RCODE Error values of 19, 20, and 21 as listed in section
      2.6.

8. Security Considerations

   The entirety of this specification is concerned with the secure
   establishment of a shared secret between DNS clients and servers in
   support of TSIG [RFC 2845].

   Protection against denial of service via the use of TKEY is not
   provided.





Eastlake                    Standards Track                    [Page 13]

RFC 2930                    The DNS TKEY RR               September 2000


References

   [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
              Algorithms, and Source Code in C", 1996, John Wiley and
              Sons

   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, November 1987.

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
              Specifications", STD 13, RFC 1035, November 1987.

   [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
              Recommendations for Security", RFC 1750, December 1994.

   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              September 1996.

   [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              August 1996.

   [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
              for IPv4, IPv6 and OSI", RFC 2030, October 1996.

   [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
              April 1997.

   [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
              Specifications Version 2.0", RFC 2437, October 1998.

   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
              Domain Name System (DNS)", RFC 2539, March 1999.




Eastlake                    Standards Track                    [Page 14]

RFC 2930                    The DNS TKEY RR               September 2000


   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.

   [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
              (SIG(0)s )", RFC 2931, September 2000.

Author's Address

   Donald E. Eastlake 3rd
   Motorola
   140 Forest Avenue
   Hudson, MA 01749 USA

   Phone: +1 978-562-2827 (h)
          +1 508-261-5434 (w)
   Fax:   +1 508-261-4447 (w)
   EMail: Donald.Eastlake@motorola.com

































Eastlake                    Standards Track                    [Page 15]

RFC 2930                    The DNS TKEY RR               September 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Eastlake                    Standards Track                    [Page 16]