6 DNS Extensions Yuji Kamite
7 Internet-Draft NTT Communications
8 Expires: April 15, 2005 Masaya Nakayama
9 The University of Tokyo
14 TKEY Secret Key Renewal Mode
15 draft-ietf-dnsext-tkey-renewal-mode-05
20 This document is an Internet-Draft and is subject to all provisions
21 of section 3 of RFC 3667. By submitting this Internet-Draft, each
22 author represents that any applicable patent or other IPR claims of
23 which he or she is aware have been or will be disclosed, and any of
24 which he or she become aware will be disclosed, in accordance with
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF), its areas, and its working groups. Note that
29 other groups may also distribute working documents as
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 The list of current Internet-Drafts can be accessed at
38 http://www.ietf.org/ietf/1id-abstracts.txt.
40 The list of Internet-Draft Shadow Directories can be accessed at
41 http://www.ietf.org/shadow.html.
43 This Internet-Draft will expire on April 15, 2005.
47 Copyright (C) The Internet Society (2004).
51 This document defines a new mode in TKEY and proposes an atomic
52 method for changing secret keys used for TSIG periodically.
53 Originally, TKEY provides methods of setting up shared secrets other
57 Kamite, et. al. Expires April 15, 2005 [Page 1]
59 INTERNET-DRAFT October 2004
62 than manual exchange, but it cannot control timing of key renewal
63 very well though it can add or delete shared keys separately. This
64 proposal is a systematical key renewal procedure intended for
65 preventing signing DNS messages with old and non-safe keys
70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
71 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3
72 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4
73 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4
74 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5
75 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5
76 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6
77 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7
78 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7
79 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7
80 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8
81 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8
82 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
83 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10
84 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10
85 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
86 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11
87 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12
88 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13
89 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14
90 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
91 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15
92 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15
93 4.2 Authentication Methods Considerations . . . . . . . . . . 15
94 5. Special Considerations for Two Servers' Case . . . . . . . . 16
95 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16
96 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17
97 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17
98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
102 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21
103 11.2 Informative References . . . . . . . . . . . . . . . . . . 21
104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
105 Intellectual Property and Copyright Statements . . . . . . . . 23
113 Kamite, et. al. Expires April 15, 2005 [Page 2]
115 INTERNET-DRAFT October 2004
120 TSIG [RFC2845] provides DNS message integrity and the
121 request/transaction authentication by means of message authentication
122 codes (MAC). TSIG is a practical solution in view of calculation
123 speed and availability. However, TSIG does not have exchanging
124 mechanism of shared secret keys between server and resolver, and
125 administrators might have to exchange secret keys manually. TKEY
126 [RFC2930] is introduced to solve such problem and it can exchange
127 secrets for TSIG via networks.
129 In various modes of TKEY, a server and a resolver can add or delete a
130 secret key be means of TKEY message exchange. However, the existing
131 TKEY does not care fully about the management of keys which became
132 too old, or dangerous after long time usage.
134 It is ideal that the number of secret which a pair of hosts share
135 should be limited only one, because having too many keys for the same
136 purpose might not only be a burden to resolvers for managing and
137 distinguishing according to servers to query, but also does not seem
138 to be safe in terms of storage and protection against attackers.
139 Moreover, perhaps holding old keys long time might give attackers
140 chances to compromise by scrupulous calculation.
142 Therefore, when a new shared secret is established by TKEY, the
143 previous old secret should be revoked immediately. To accomplish
144 this, DNS servers must support a protocol for key renewal. This
145 document specifies procedure to refresh secret keys between two hosts
146 which is defined within the framework of TKEY, and it is called "TKEY
147 Secret Key Renewal Mode".
149 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
150 "OPTIONAL" in this document are to be interpreted as described in
156 * Inception Time: Beginning of the shared secret key lifetime. This
157 value is determined when the key is generated.
159 * Expiry Limit: Time limit of the key's validity. This value is
160 determined when a new key is generated. After Expiry Limit, server
161 and client (resolver) must not authenticate TSIG signed with the key.
162 Therefore, Renewal to the next key should be carried out before
165 * Partial Revocation Time: Time when server judges the key is too old
169 Kamite, et. al. Expires April 15, 2005 [Page 3]
171 INTERNET-DRAFT October 2004
174 and must be updated. It must be between Inception Time and Expiry
175 Limit. This value is determined by server freely following its
176 security policy. e.g., If the time from Inception to Partial
177 Revocation is short, renewal will be carried out more often, which
180 * Revocation Time: Time when the key becomes invalid and can be
181 removed. This value is not determined in advance because it is the
182 actual time when revocation is completed.
184 * Adoption Time: Time when the new key is adopted as the next key
185 formally. After Adoption, the key is valid and server and client can
186 generate or verify TSIG making use of it. Adoption Time also means
187 the time when it becomes possible to remove the previous key, so
188 Revocation and Adoption are usually done at the same time.
192 Inception Revocation Revocation Expiry Limit
194 |----------------|- - - - - - >>|- (revoked) -|
197 |- - - -|-------------------->> time
202 1.2. New Format and Assigned Numbers
205 ERROR = (PartialRevoke), TBD
208 Mode = (server assignment for key renewal), TBD
209 Mode = (Diffie-Hellman exchange for key renewal), TBD
210 Mode = (resolver assignment for key renewal), TBD
211 Mode = (key adoption), TBD
214 1.3. Overview of Secret Key Renewal Mode
216 When a server receives a query from a client signed with a TSIG key,
217 It always checks if the present time is within the range of usage
218 duration it considers safe. If it is judged that the key is too old,
219 i.e., after Partial Revocation Time, the server comes to be in
220 Partial Revocation state about the key, and this key is called
225 Kamite, et. al. Expires April 15, 2005 [Page 4]
227 INTERNET-DRAFT October 2004
230 In this state, if a client sends a normal query (e.g., question about
231 A RR) other than TKEY Renewal request with TSIG signed with the old
232 key, the server returns an error message to notify that the time to
233 renew has come. This is called "PartialRevoke" error message. It is
234 server's choice whether it returns PartialRevoke or not. If and only
235 if the server is ready for changing its own key, it decides to return
238 The client which got this error is able to notice that it is
239 necessary to refresh the secret. To make a new shared secret, it
240 sends a TKEY Renewal request, in which several keying methods are
241 available. It can make use of TSIG authentication signed with the
242 partially revoked key mentioned above.
244 After new secret establishment, the client sends a TKEY Adoption
245 request for renewal confirmation. This can also be authenticated with
246 the partially revoked key. If this is admitted by the server, the new
247 key is formally adopted, and at the same time the corresponding old
248 secret is invalidated. Then the client can send the first query again
249 signed with the new key.
251 Key renewal procedure is executed based on two-phase commit
252 mechanism. The first phase is the TKEY Renewal request and its
253 response, which means preparatory confirmation for key update. The
254 second phase is Adoption request and its response. If the server gets
255 request and client receives the response successfully, they can
256 finish renewal process. If any error happens and renewal process
257 fails during these phases, client should roll back to the beginning
258 of the first phase, and send TKEY Renewal request again. This
259 rollback can be done until the Expiry Limit of the key.
262 2. Shared Secret Key Renewal
264 Suppose a server and a client agree to change their TSIG keys
265 periodically. Key renewal procedure is defined between two hosts.
267 2.1. Key Usage Time Check
269 Whenever a server receives a query with TSIG and can find a key that
270 is used for signing it, the server checks its Inception Time, Partial
271 Revocation Time and Expiry Limit (this information is usually
272 memorized by the server).
274 When the present time is before Inception Time, the server MUST NOT
275 verify TSIG with the key, and server acts the same way as when the
276 key used by the client is not recognized. It follows [RFC2845] 4.5.1.
281 Kamite, et. al. Expires April 15, 2005 [Page 5]
283 INTERNET-DRAFT October 2004
286 When the present time is equal to Inception Time, or between
287 Inception Time and Partial Revocation Time, the behavior of the
288 server is the same as when a valid key is found. It follows [RFC2845]
291 When the present time is the same as the Partial Revocation Time, or
292 between the Partial Revocation Time and Expiry Limit, the server
293 comes to be in Partial Revocation state about the TSIG key and
294 behaves according to the next section.
296 When the present time is the same as the Expiry Time or after it, the
297 server MUST NOT verify TSIG with the key, and returns error messages
298 in the same way as when the key used by the client is not recognized.
299 It follows [RFC2845] 4.5.1.
302 2.2. Partial Revocation
304 In Partial Revocation state, we say the server has partially revoked
305 the key and the key has become a "partially revoked key".
307 If server has received a query signed with the partially revoked key
308 for TKEY Renewal request (See section 2.3.) or Key Adoption request
309 (See section 2.4.), then server does proper process following each
310 specification. If it is for TKEY key deletion request ([RFC2930]
311 4.2), server MAY process usual deletion operation defined therein.
313 If server receives other types of query signed with the partially
314 revoked key, and both the corresponding MAC and signed TIME are
315 verified, then server begins returning answer whose TSIG error code
316 is "PartialRevoke" (See section 9.). Server MUST randomly but with
317 increasing frequency return PartialRevoke when in the Partial
320 Server can decide when it actually sends PartialRevoke, checking if
321 it is appropriate time for renewal. Server MUST NOT return
322 PartialRevoke if this is apart long lived TSIG transaction (such as
323 AXFR) that started before the Partial Revocation Time.
325 If the client receives PartialRevoke and understands it, then it MUST
326 retry the query with the old key unless a new key has been adopted.
327 Client SHOULD start the process to renew the TSIG key. For key
328 renewal procedure, see details in Section 2.3 and 2.4.
330 PartialRevoke period (i.e., time while server returns PartialRevoke
331 randomely) SHOULD be small, say 2-5% of key lifetime. This is
337 Kamite, et. al. Expires April 15, 2005 [Page 6]
339 INTERNET-DRAFT October 2004
342 Server MUST keep track of clients ignoring PartialRevoke, thus
343 indicating ignorance of this TKEY mode.
345 PartialRevoke error messages have the role to inform clients of the
346 keys' partial revocation and urge them to send TKEY Renewal requests.
347 These error responses MUST be signed with those partial revoked keys
348 if the queries are signed with them. They are sent only when the
349 signing keys are found to be partially revoked. If the MAC of TSIG
350 cannot be verified with the partially revoked keys, servers MUST NOT
351 return PartialRevoke error with MAC, but MUST return another error
352 such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
353 words, a server informs its key's partial revocation only when the
354 MAC in the received query is valid.
357 2.3. Key Renewal Message Exchange
359 2.3.1. Query for Key Renewal
361 If a client has received a PartialRevoke error and authenticated the
362 response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
363 this document, we call it Renewal request, too.) to the server. The
364 request MUST be signed with TSIG or SIG(0) [RFC2931] for
365 authentication. If TSIG is selected, the client can sign it with the
368 Key Renewal can use one of several keying methods which is indicated
369 in "Mode" field of TKEY RR, and its message structure is dependent on
373 2.3.2. Response for Key Renewal
375 The server which has received Key Renewal request first tries to
376 verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
377 verified with the partially revoked key, the request MUST be
380 After authentication, server must check existing old key's validity.
381 If the partially revoked key indicated in the request TKEY's OldName
382 and OldAlgorithm field (See section 2.3.4.) does not exist at the
383 server, "BADKEY" [RFC2845] is given in Error field for response. If
384 any other error happens, server returns appropriate error messages
385 following the specification described in section 2.5. If there are no
386 errors, server returns a Key Renewal answer. This answer MUST be
387 signed with TSIG or SIG(0) for authentication.
389 When this answer is successfully returned and no error is detected by
393 Kamite, et. al. Expires April 15, 2005 [Page 7]
395 INTERNET-DRAFT October 2004
398 client, a new shared secret can be established. The details of
399 concrete keying procedure are given in the section 2.5.
402 Sometimes Adoption message and new Renewal request will cross on
403 the wire. In this case the newly generated key Adoption message is
407 2.3.3. Attributes of Generated Key
409 As a result of this message exchange, client comes to know the newly
410 generated key's attributes such as key's name, Inception Time and
411 Expiry Limit. They are decided by the server and told to the client;
412 in particular, however, once the server has decided Expiry Limit and
413 returned a response, it should obey the decision as far as it can. In
414 other words, they SHOULD NOT change time values for checking Expiry
415 Limit in the future without any special reason, such as security
416 issue like "Emergency Compulsory Revocation" described in section 8.
418 On the other hand, Partial Revocation Time of this generated key is
419 not decided based on the request, and not informed to the client. The
420 server can determine any value as long as it is between Inception
421 Time and Expiry Limit. However, the period from Inception to Partial
422 Revocation SHOULD be fixed as the server side's configuration or be
423 set the same as the corresponding old key's one.
426 Even if client sends Key Renewal request though the key described
427 in OldName has not been partially revoked yet, server does renewal
428 processes. At the moment when the server accepts such requests
429 with valid authentication, it MUST forcibly consider the key is
430 already partially revoked, that is, the key's Partial Revocation
431 Time must be changed into the present time (i.e., the time when
432 the server receives the request).
435 2.3.4. TKEY RR structure
437 TKEY RR for Key Renewal message has the structure given below. In
438 principle, format and definition for each field follows [RFC2930].
439 Note that each keying scheme sometimes needs different interpretation
440 of RDATA field; for detail, see section 2.5.
443 ------- ------ -------
444 NAME domain used for a new key, see below
445 TYPE u_int16_t (defined in [RFC2930])
449 Kamite, et. al. Expires April 15, 2005 [Page 8]
451 INTERNET-DRAFT October 2004
454 CLASS u_int16_t (defined in [RFC2930])
455 TTL u_int32_t (defined in [RFC2930])
456 RDLEN u_int16_t (defined in [RFC2930])
458 Algorithm: domain algorithm for a new key
459 Inception: u_int32_t about the keying material
460 Expiration: u_int32_t about the keying material
461 Mode: u_int16_t scheme for key agreement
463 Error: u_int16_t see description below
464 Key Size: u_int16_t see description below
465 Key Data: octet-stream
466 Other Size: u_int16_t (defined in [RFC2930])
468 Other Data: newly defined: see description below
471 For "NAME" field, both non-root and root name are allowed. It may
472 be used for a new key's name in the same manner as [RFC2930] 2.1.
474 "Algorithm" specifies which algorithm is used for agreed keying
475 material, which is used for identification of the next key.
477 "Inception" and "Expiration" are used for the valid period of
478 keying material. The meanings differ somewhat according to whether
479 the message is request or answer, and its keying scheme.
481 "Key Data" has different meanings according to keying schemes.
483 "Mode" field stores the value in accordance with the keying method,
484 and see section 2.5. Servers and clients supporting TKEY Renewal
485 method MUST implement "Diffie-Hellman exchange for key renewal"
486 scheme. All other modes are OPTIONAL.
488 "Error" is an extended RCODE which includes "PartialRevoke" value
491 "Other Data" field has the structure given below. They describe
492 attributes of the key to be renewed.
497 ------- ------ -------
498 OldNAME domain name of the old key
499 OldAlgorithm domain algorithm of the old key
505 Kamite, et. al. Expires April 15, 2005 [Page 9]
507 INTERNET-DRAFT October 2004
510 "OldName" indicates the name of the previous key (usually,
511 this is partially revoked key's name that client noticed by
512 PartialRevoke answer from server), and "OldAlogirthm"
513 indicates its algorithm.
518 2.4.1. Query for Key Adoption
520 After receiving a TKEY Renewal answer, the client gets the same
521 secret as the server. Then, it sends a TKEY Adoption request. The
522 request's question section's QNAME field is the same as the NAME
523 filed of TKEY written below. In additional section, there is one TKEY
524 RR that has the structure and values described below.
526 "NAME" field is the new key's name to be adopted which was already
527 generated by Renewal message exchange. "Algorithm" is its
528 algorithm. "Inception" means the key's Inception Time, and
529 "Expiration" means Expiry Limit.
531 "Mode" field is the value of "key adoption". See section 9.
533 "Other Data" field in Adoption has the same structure as that of
534 Renewal request message. "OldName" means the previous old key, and
535 "OldAlogirthm" means its algorithm.
537 Key Adoption request MUST be signed with TSIG or SIG(0) for
538 authentication. The client can sign TSIG with the previous key. Note
539 that until Adoption is finished, the new key is treated as invalid,
540 thus it cannot be used for authentication immediately.
543 2.4.2. Response for Key Adoption
545 The server which has received Adoption request, it verifies TSIG or
546 SIG(0) accompanying it. If the TSIG is signed with the partially
547 revoked key and can be verified, the message MUST be authenticated.
549 If the next new key indicated by the request TKEY's "NAME" is not
550 present at the server, BADNAME [RFC2845] is given in Error field and
551 the error message is returned.
553 If the next key exists but it has not been adopted formally yet, the
554 server confirms the previous key's existence indicated by the
555 "OldName" and "OldAlgorithm" field. If it succeeds, the server
556 executes Adoption of the next key and Revocation of the previous key.
557 Response message duplicates the request's TKEY RR with NOERROR,
561 Kamite, et. al. Expires April 15, 2005 [Page 10]
563 INTERNET-DRAFT October 2004
566 including "OldName" and "OldAlgorithm" that indicate the revoked key.
568 If the next key exists but it is already adopted, the server returns
569 a response message regardless of the substance of the request TKEY's
570 "OldName". In this response, Response TKEY RR has the same data as
571 the request's one except as to its "Other Data" that is changed into
572 null (i.e., "Other Size" is zero), which is intended for telling the
573 client that the previous key name was ignored, and the new key is
576 Client sometimes has to retry Adoption request. Suppose the client
577 sent request signed with the partially revoked key, but its response
578 did not return successfully (e.g., due to the drop of UDP packet).
579 Client will probably retry Adoption request; however, the request
580 will be refused in the form of TSIG "BADKEY" error because the
581 previous key was already revoked. In this case, client will
582 retransmit Adoption request signed with the next key, and expect a
583 response which has null "Other Data" for confirming the completion of
589 In Renewal message exchanges, there are no limitations as to which
590 keying method is actually used. The specification of keying
591 algorithms is independent of the general procedure of Renewal that is
592 described in section 2.3.
594 Now this document specifies three algorithms in this section, but
595 other future documents can make extensions defining other methods.
598 2.5.1. DH Exchange for Key Renewal
600 This scheme is defined as an extended method of [RFC2930] 4.1. This
601 specification only describes the difference from it and special
602 notice; assume that all other points, such as keying material
603 computation, are the exactly same as the specification of [RFC2930]
607 In Renewal request for type TKEY with this mode, there is one TKEY
608 RR and one KEY RR in the additional information section. KEY RR is
609 the client's Diffie-Hellman public key [RFC2539].
611 QNAME in question section is the same as that of "NAME" field in
612 TKEY RR, i.e., it means the requested new key's name.
617 Kamite, et. al. Expires April 15, 2005 [Page 11]
619 INTERNET-DRAFT October 2004
622 TKEY "Mode" field stores the value of "DH exchange for key
623 renewal". See section 9.
625 TKEY "Inception" and "Expiration" are those requested for the
626 keying material, that is, requested usage period of a new key.
628 TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
631 The server which received this request first verifies the TSIG,
632 SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
633 old key's existence validity is checked, following section 2.3. If
634 any incompatible DH key is found in the request, "BADKEY"
635 [RFC2845] is given in Error field for response. "FORMERR" is given
636 if the query included no DH KEY.
638 If there are no errors, the server processes a response according
639 to Diffie-Hellman algorithm and returns the answer. In this
640 answer, there is one TKEY RR in answer section and KEY RR(s) in
643 As long as no error has occurred, all values of TKEY are equal to
644 that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
645 Inception, Expiration, Key Size and Key Data.
647 TKEY "NAME" field in the answer specifies the name of newly
648 produced key which the client MUST use.
650 TKEY "Inception" and "Expiration" mean the periods of the produced
651 key usage. "Inception" is set to be the time when the new key is
652 actually generated or the time before it, and it will be regarded
653 as Inception Time. "Expiration" is determined by the server, and
654 it will be regarded as Expiry Limit.
656 TKEY "Key Data" is used as an additional nonce, following
659 The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
660 the additional section and a server Diffie-Hellman KEY RR will
661 also be present in the answer section, following [RFC2930] 4.1.
664 2.5.2. Server Assigned Keying for Key Renewal
666 This scheme is defined as an extended method of [RFC2930] 4.4. This
667 specification only describes the difference from it and special
668 notice; assume that all other points, such as secret encrypting
669 method, are the exactly same as the specification of [RFC2930] 4.4.
673 Kamite, et. al. Expires April 15, 2005 [Page 12]
675 INTERNET-DRAFT October 2004
679 In Renewal request for type TKEY with this mode, there is one TKEY
680 RR and one KEY RR in the additional information section. KEY RR is
681 used in encrypting the response.
683 QNAME in question section is the same as that of "NAME" field in
684 TKEY RR, i.e., it means the requested new key's name.
686 TKEY "Mode" field stores the value of "server assignment for key
687 renewal". See section 9.
689 TKEY "Inception" and "Expiration" are those requested for the
690 keying material, that is, requested usage period of a new key.
692 TKEY "Key Data" is provided following the specification of
696 The server which received this request first verifies the TSIG,
697 SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
698 old key's existence validity is checked, following section 2.3.
699 "FORMERR" is given if the query specified no encryption key.
701 If there are no errors, the server response contains one TKEY RR
702 in the answer section, and echoes the KEY RR provided in the query
703 in the additional information section.
705 TKEY "NAME" field in the answer specifies the name of newly
706 produced key which the client MUST use.
708 TKEY "Inception" and "Expiration" mean the periods of the produced
709 key usage. "Inception" is set to be the time when the new key is
710 actually generated or the time before it, and it will be regarded
711 as Inception Time. "Expiration" is determined by the server, and
712 it will be regarded as Expiry Limit.
714 TKEY "Key Data" is the assigned keying data encrypted under the
715 public key in the resolver provided KEY RR, which is the same as
719 2.5.3. Resolver Assigned Keying for Key Renewal
721 This scheme is defined as an extended method of [RFC2930] 4.5. This
722 specification only describes the difference from it and special
723 notice; assume that all other points, such as secret encrypting
724 method, are the exactly same as the specification of [RFC2930] 4.5.
729 Kamite, et. al. Expires April 15, 2005 [Page 13]
731 INTERNET-DRAFT October 2004
735 In Renewal request for type TKEY with this mode, there is one TKEY
736 RR and one KEY RR in the additional information section. TKEY RR
737 has the encrypted keying material and KEY RR is the server public
738 key used to encrypt the data.
740 QNAME in question section is the same as that of "NAME" field in
741 TKEY RR, i.e., it means the requested new key's name.
743 TKEY "Mode" field stores the value of "resolver assignment for key
744 renewal". See section 9.
746 TKEY "Inception" and "Expiration" are those requested for the
747 keying material, that is, requested usage period of a new key.
749 TKEY "Key Data" is the encrypted keying material.
752 The server which received this request first verifies the TSIG,
753 SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
754 old key's existence validity is checked, following section 2.3.
755 "FORMERR" is given if the server does not have the corresponding
756 private key for the KEY RR that was shown sin the request.
758 If there are no errors, the server returns a response. The
759 response contains a TKEY RR in the answer section to tell the
760 shared key's name and its usage time values.
762 TKEY "NAME" field in the answer specifies the name of newly
763 produced key which the client MUST use.
765 TKEY "Inception" and "Expiration" mean the periods of the produced
766 key usage. "Inception" is set to be the time when the new key is
767 actually generated or the time before it, and it will be regarded
768 as Inception Time. "Expiration" is determined by the server, and
769 it will be regarded as Expiry Limit.
772 2.6. Considerations about Non-compliant Hosts
774 Key Renewal requests and responses must be exchanged between hosts
775 which can understand them and do proper processes. PartialRevoke
776 error messages will be only ignored if they should be returned to
779 Note that server does not inform actively the necessity of renewal to
780 clients, but inform it as responses invoked by client's query.
781 Server needs not care whether the PartialRevoke errors has reached
785 Kamite, et. al. Expires April 15, 2005 [Page 14]
787 INTERNET-DRAFT October 2004
790 client or not. If client has not received yet because of any reasons
791 such as packet drops, it will resend the queries, and finally will be
792 able to get PartialRevoke information.
797 Every server keeps all secrets and attached information, e.g.,
798 Inception Time, Expiry Limit, etc. safely to be able to recover from
799 unexpected stop. To accomplish this, formally adopted keys SHOULD be
800 memorized not only on memory, but also be stored in the form of some
801 files. It will become more secure if they are stored in ecrypted
805 4. Compulsory Key Revocation
807 4.1. Compulsory Key Revocation by Server
809 There is a rare but possible case that although servers have already
810 partially revoked keys, clients do not try to send any Renewal
811 requests. If this state continues, in the future it will become the
812 time of Expiry Limit. After Expiry Limit, the keys will be expired
813 and completely removed, so this is called Compulsory Key Revocation
816 If Expiry Limit is too distant from the Partial Revocation Time, then
817 even though very long time passes, clients will be able to refresh
818 secrets only if they add TSIG signed with those old partially revoked
819 keys into requests, which is not safe.
821 On the other hand, if Expiry Limit is too close to Partial Revocation
822 Time, perhaps clients might not be able to notice their keys' Partial
823 Revocation by getting "PartialRevoke" errors.
825 Therefore, servers should set proper Expiry Limit to their keys,
826 considering both their keys' safety, and enough time for clients to
827 send requests and process renewal.
830 4.2. Authentication Methods Considerations
832 It might be ideal to provide both SIG(0) and TSIG as authentication
833 methods. For example:
835 A client and a server start SIG(0) authentication at first, to
836 establish TSIG shared keys by means of "Query for Diffie-Hellman
837 Exchanged Keying" as described in [RFC2930] 4.1. Once they get
841 Kamite, et. al. Expires April 15, 2005 [Page 15]
843 INTERNET-DRAFT October 2004
846 shared secret, they keep using TSIG for queries and responses.
847 After a while the server returns a "ParitalRevoke" error and they
848 begin a key renewal process. Both TSIG signed with partially
849 revoked keys and SIG(0) are okay for authentication, but TSIG would
850 be easier to use considering calculation efficiency.
852 Suppose now client is halted for long time with some reason.
853 Because server does not execute any renewal process, it will
854 finally do Compulsory Revocation. Even if client restarts and sends
855 a key Renewal request, it will fail because old key is already
858 At this moment, however, if client also uses SIG(0) as another
859 authentication method, it can make a new shared key again and
860 recover successfully by sending "Query for Diffie-Hellman Exchanged
864 5. Special Considerations for Two servers' Case
866 This section refers to the case where both hosts are DNS servers
867 which can act as full resolvers as well and using one shared key
868 only. If one server (called Server A) wants to refresh a shared key
869 (called "Key A-B"), it will await a TKEY Renewal request from the
870 other server (called Server B). However, perhaps Server A wants to
871 refresh the key right now.
873 In this case, Server A is allowed to send a Renewal request to Server
874 B, if Server A knows the Key A-B is too old and wants to renew it
877 Note that the initiative in key renewal belongs to Server A because
878 it can notice the Partial Revocation Time and decide key renewal. If
879 Server B has information about Partial Revocation Time as well, it
880 can also decide for itself to send Renewal request to Server A.
881 However, it is not essential for both two servers have information
882 about key renewal timing.
884 5.1. To Cope with Collisions of Renewal Requests
886 At least one of two hosts which use Key Renewal must know their key
887 renewal information such as Partial Revocation Time. It is okay that
890 Provided that both two servers know key renewal timing information,
891 there is possibility for them to begin partial revocation and sending
892 Renewal requests to each other at the same time. Such collisions will
893 not happen so often because Renewal requests are usually invoked when
897 Kamite, et. al. Expires April 15, 2005 [Page 16]
899 INTERNET-DRAFT October 2004
902 hosts want to send queries, but it is possible.
904 When one of two servers tries to send Renewal requests, it MUST
905 protect old secrets that it has partially revoked and prevent it from
906 being refreshed by any requests from the other server (i.e., it must
907 lock the old secret during the process of renewal). While the server
908 is sending Renewal requests and waiting responses, it ignores the
909 other server's Renewal requests.
911 Therefore, servers might fail to change secrets by means of their own
912 requests to others. After failure they will try to resend, but they
913 should wait for random delays by the next retries. If they get any
914 Renewal requests from others while they are waiting, their shared
915 keys may be refreshed, then they do not need to send any Renewal
916 requests now for themselves.
919 6. Key Name Considerations
921 Since both servers and clients have only to distinguish new secrets
922 and old ones, keys' names do not need to be specified strictly.
923 However, it is recommended that some serial number or key generation
924 time be added to the name and that the names of keys between the same
925 pair of hosts should have some common labels among their keys. For
926 example, suppose A.example.com. and B.example.com. share the key
927 "<serial number>.A.example.com.B.example.com." such as
928 "10010.A.example.com.B.example.com.". After key renewal, they change
929 their secret and name into "10011.A.example.com.B.example.com."
931 Servers and clients must be able to use keys properly for each query.
932 Because TSIG secret keys themselves do not have any particular IDs to
933 be distinguished and would be identified by their names and
934 algorithm, it must be understood correctly what keys are refreshed.
937 7. Example Usage of Secret Key Renewal Mode
939 This is an example of Renewal mode usage where a Server,
940 server.example.com, and a Client, client.exmple.com have an initial
941 shared secret key named "00.client.example.com.server.example.com".
943 (1) The time values for key
944 "00.client.example.com.server.example.com" was set as follows:
945 Inception Time is at 1:00, Expiry Limit is at 21:00.
947 (2) At Server, renewal time has been set: Partial Revocation Time
953 Kamite, et. al. Expires April 15, 2005 [Page 17]
955 INTERNET-DRAFT October 2004
958 (3) Suppose the present time is 19:55. If Client sends a query
959 signed with key "00.client.example.com.server.example.com" to ask
960 the IP address of "www.example.com", finally it will get a proper
961 answer from Server with valid TSIG (NOERROR).
963 (4) At 20:05. Client sends a query to ask the IP address of
964 "www2.example.com". It is signed with key
965 "00.client.example.com.server.example.com". Server returns an
966 answer for the IP address. However, server has begun retuning
967 PartialRevoke Error randomely. This answer includes valid TSIG MAC
968 signed with "00.client.example.com.server.example.com", and its
969 Error Code indicates PartialRevoke. Client understands that the
970 current key is partially revoked.
972 (5) At 20:06. Client sends a Renewal request to Server. This
973 request is signed with key
974 "00.client.example.com.server.example.com". It includes data such
978 QNAME = 01.client.example.com. (Client can set this freely)
982 01.client.example.com. TKEY
983 Algorithm = hmac-md5-sig-alg.reg.int.
984 Inception = (value meaning 20:00)
985 Expiration = (value meaning next day's 16:00)
986 Mode = (DH exchange for key renewal)
987 OldName = 00.client.example.com.server.example.com.
988 OldAlgorithm = hmac-md5-sig-alg.reg.int.
990 Additional Section also contains a KEY RR for DH and a TSIG RR.
992 (6) As soon as Server receives this request, it verifies TSIG. It
993 is signed with the partially revoked key
994 "00.client.example.com.server.example.com". and Server accepts the
995 request. It creates a new key by Diffie-Hellman calculation and
996 returns an answer which includes data such as:
999 01.client.example.com.server.example.com. TKEY
1000 Algorithm = hmac-md5-sig-alg.reg.int.
1001 Inception = (value meaning 20:00)
1002 Expiration = (value meaning next day's 16:00)
1003 Mode = (DH exchange for key renewal)
1004 OldName = 00.client.example.com.server.example.com.
1005 OldAlgorithm = hmac-md5-sig-alg.reg.int.
1009 Kamite, et. al. Expires April 15, 2005 [Page 18]
1011 INTERNET-DRAFT October 2004
1014 Answer Section also contains KEY RRs for DH.
1016 Additional Section also contains a TSIG RR.
1017 This response is signed with key
1018 "00.client.example.com.server.example.com" without error.
1020 At the same time, Server decides to set the Partial Revocation Time
1021 of this new key "01.client.example.com.server.example.com." as next
1024 (7) Client gets the response and checks TSIG MAC, and calculates
1025 Diffie-Hellman. It will get a new key, and it has been named
1026 "01.client.example.com.server.example.com" by Server.
1028 (8) At 20:07. Client sends an Adoption request to Server. This
1029 request is signed with the previous key
1030 "00.client.example.com.server.example.com". It includes:
1033 QNAME = 01.client.example.com.server.example.com.
1037 01.client.example.com.server.example.com. TKEY
1038 Algorithm = hmac-md5-sig-alg.reg.int.
1039 Inception = (value meaning 20:00)
1040 Expiration = (value meaning next day's 16:00)
1041 Mode = (key adoption)
1042 OldName = 00.client.example.com.server.example.com.
1043 OldAlgorithm = hmac-md5-sig-alg.reg.int.
1045 Additional Section also contains a TSIG RR.
1047 (9) Server verifies the query's TSIG. It is signed with the
1048 previous key and authenticated. It returns a response whose TKEY RR
1049 is the same as the request's one. The response is signed with key
1050 "00.client.example.com.server.example.com.". As soon as the
1051 response is sent, Server revokes and removes the previous key. At
1052 the same time, key "01.client.example.com.server.example.com." is
1055 (10) Client acknowledges the success of Adoption by receiving the
1056 response. Then, it retries to send an original question about
1057 "www2.example.com". It is signed with the adopted key
1058 "01.client.example.com.server.example.com", so Server authenticates
1059 it and returns an answer.
1065 Kamite, et. al. Expires April 15, 2005 [Page 19]
1067 INTERNET-DRAFT October 2004
1070 (11) This key is used until next day's 15:00. After that, it will
1071 be partially revoked again.
1074 8. Security Considerations
1076 This document considers about how to refresh shared secret. Secret
1077 changed by this method is used at servers in support of TSIG
1080 [RFC2104] says that current attacks to HMAC do not indicate a
1081 specific recommended frequency for key changes but periodic key
1082 refreshment is a fundamental security practice that helps against
1083 potential weaknesses of the function and keys, and limits the damage
1084 of an exposed key. TKEY Secret Key Renewal provides the method of
1085 periodical key refreshment.
1087 In TKEY Secret Key Renewal, clients need to send two requests
1088 (Renewal and Adoption) and spend time to finish their key renewal
1089 processes. Thus the usage period of secrets should be considered
1090 carefully based on both TKEY processing performance and security.
1092 This document specifies the procedure of periodical key renewal, but
1093 actually there is possibility for servers to have no choice other
1094 than revoking their secret keys immediately especially when the keys
1095 are found to be compromised by attackers. This is called "Emergency
1096 Compulsory Revocation". For example, suppose the original Expiry
1097 Limit was set at 21:00, Partial Revocation Time at 20:00 and
1098 Inception Time at 1:00. if at 11:00 the key is found to be
1099 compromised, the server sets Expiry Limit forcibly to be 11:00 or
1102 Consequently, once Compulsory Revocation (See section 4.) is carried
1103 out, normal renewal process described in this document cannot be done
1104 any more as far as the key is concerned. However, after such
1105 accidents happened, the two hosts are able to establish secret keys
1106 and begin renewal procedure only if they have other (non-compromised)
1107 shared TSIG keys or safe SIG(0) keys for the authentication of
1108 initial secret establishment such as Diffie-Hellman Exchanged Keying.
1111 9. IANA Considerations
1113 IANA needs to allocate a value for "DH exchange for key renewal",
1114 "server assignment for key renewal", "resolver assignment for key
1115 renewal" and "key adoption" in the mode filed of TKEY. It also needs
1116 to allocate a value for "PartialRevoke" from the extended RCODE
1121 Kamite, et. al. Expires April 15, 2005 [Page 20]
1123 INTERNET-DRAFT October 2004
1126 10. Acknowledgements
1128 The authors would like to thank Olafur Gudmundsson, whose helpful
1129 input and comments contributed greatly to this document.
1134 11.1. Normative References
1137 Bradner, S., "Key words for use in RFCs to Indicate Requirement
1138 Levels", RFC 2119, March 1997.
1141 D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
1142 System (DNS)", RFC 2539, March 1999.
1145 Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
1146 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
1150 D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
1151 RFC 2930, September 2000.
1154 D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
1155 )", RFC 2931, September 2000.
1157 11.2. Informative References
1160 H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
1161 Authentication", RFC2104, February 1997.
1177 Kamite, et. al. Expires April 15, 2005 [Page 21]
1179 INTERNET-DRAFT October 2004
1185 NTT Communications Corporation
1186 Tokyo Opera City Tower
1187 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
1189 EMail: y.kamite@ntt.com
1193 Information Technology Center, The University of Tokyo
1194 2-11-16 Yayoi, Bunkyo-ku, Tokyo
1196 EMail: nakayama@nc.u-tokyo.ac.jp
1233 Kamite, et. al. Expires April 15, 2005 [Page 22]
1235 INTERNET-DRAFT October 2004
1238 Intellectual Property Statement
1240 The IETF takes no position regarding the validity or scope of any
1241 Intellectual Property Rights or other rights that might be claimed to
1242 pertain to the implementation or use of the technology described in
1243 this document or the extent to which any license under such rights
1244 might or might not be available; nor does it represent that it has
1245 made any independent effort to identify any such rights. Information
1246 on the procedures with respect to rights in RFC documents can be
1247 found in BCP 78 and BCP 79.
1249 Copies of IPR disclosures made to the IETF Secretariat and any
1250 assurances of licenses to be made available, or the result of an
1251 attempt made to obtain a general license or permission for the use of
1252 such proprietary rights by implementers or users of this
1253 specification can be obtained from the IETF on-line IPR repository at
1254 http://www.ietf.org/ipr.
1256 The IETF invites any interested party to bring to its attention any
1257 copyrights, patents or patent applications, or other proprietary
1258 rights that may cover technology that may be required to implement
1259 this standard. Please address the information to the IETF at
1263 Disclaimer of Validity
1265 This document and the information contained herein are provided on an
1266 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1267 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1268 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1269 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1270 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1271 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1276 Copyright (C) The Internet Society (2004). This document is subject
1277 to the rights, licenses and restrictions contained in BCP 78, and
1278 except as set forth therein, the authors retain all their rights.
1283 Funding for the RFC Editor function is currently provided by the
1289 Kamite, et. al. Expires April 15, 2005 [Page 23]