draft-ietf-dnsext-tkey-renewal-mode-00.txt   draft-ietf-dnsext-tkey-renewal-mode-01.txt 
DNSEXT Working Group Yuji Kamite DNSEXT Working Group Yuji Kamite
INTERNET-DRAFT Masaya Nakayama INTERNET-DRAFT NTT Communications
<draft-ietf-dnsext-tkey-renewal-mode-00.txt> the University of Tokyo <draft-ietf-dnsext-tkey-renewal-mode-01.txt> Masaya Nakayama
Expires: May 2, 2002 November 2, 2001 Expires: Nov. 11, 2002 The University of Tokyo
May 11, 2002
TKEY Secret Key Renewal Mode TKEY Secret Key Renewal Mode
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 33 skipping to change at page 1, line 34
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document defines a new mode in TKEY [RFC2930] and proposes an This document defines a new mode in TKEY [RFC2930] and proposes an
atomic method for changing periodically secret keys for TSIG atomic method for changing secret keys used for TSIG [RFC2845]
[RFC2845]. This method is intended to prevent signing messages with periodically. Originally, TKEY provides methods of setting up shared
old and non-safe keys permanently. A server checks the valid periods secrets other than manual exchange, but it cannot control timing of
of keys whenever it receives queries, and if any key is too old, it key renewal very well though it can add or delete shared keys
is demanded that the client sharing it should send a secret renewal separately. This proposal is a systematical key renewal procedure
request. After secret establishment and a query with a new signature intended for preventing signing DNS messages with old and non-safe
is received, the key becomes valid formally and the previous one is keys permanently.
invalidated.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 3 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Comparison of Secret Key Renewal and usual Diffie-Hellman 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4
Exchanged Keying . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4
2 Shared secret key renewal . . . . . . . . . . . . . . . . . . . . 5 2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5
2.1 Detection of secret expiration . . . . . . . . . . . . . . . 5 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5
2.2 Partial key revocation . . . . . . . . . . . . . . . . . . . 6 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6
2.3 Query for DH exchange for key renewal . . . . . . . . . . . . 6 2.3 Renewal Request . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Query . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Query for DH Exchange for Key Renewal . . . . . . . . . . 6
2.3.2 Response . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2 Response for DH Exchange for Key Renewal . . . . . . . . 8
2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Considerations about non-compliant hosts for secret key 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 9
renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10
3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5 Considerations about Non-compliant Hosts . . . . . . . . . . 10
4 Compulsory key revocation by servers . . . . . . . . . . . . . . 10 3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Example of compulsory key revocation . . . . . . . . . . . . 11 4 Compulsory Key Revocation by Server . . . . . . . . . . . . . . . 11
5 Special considerations for two servers' case . . . . . . . . . . 11 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 To cope with collisions of renewal requests . . . . . . . . . 12 5 Special Considerations for Two Servers' Case . . . . . . . . . . 12
6 Key name consideration . . . . . . . . . . . . . . . . . . . . . 13 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 12
7 Example usage of TKEY Secret Key Renewal Mode . . . . . . . . . . 14 6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 13
8 Security consideration . . . . . . . . . . . . . . . . . . . . . 16 7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 13
9 IANA consideration . . . . . . . . . . . . . . . . . . . . . . . 16 8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 16
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 16
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
TSIG [RFC2845] provides whole DNS message integrity and the TSIG [RFC2845] provides DNS message integrity and the
request/transaction authentication, by means of message request/transaction authentication by means of message authentication
authentication codes (MAC). Moreover, TSIG is practical in view of codes (MAC). TSIG is a practical solution in view of calculation
calculation speed and easily available. To make use of TSIG, in most speed and availablity. However, TSIG does not have exchanging
cases hosts must share secret keys by manual exchange, which is a mechanism of shared secret keys between server and resolver, and
little troublesome. but if you use TKEY [RFC2930] as well, hosts can administrators might have to exchange secret keys manually. TKEY
establish secrets for TSIG via networks, not by manual exchange. [RFC2930] is introduced to solve such problem and it can exchange
secrets for TSIG via networks.
In various modes of TKEY, a server and a resolver can add or delete a In various modes of TKEY, a server and a resolver can add or delete a
secret key be means of TKEY message exchange. However, old TKEY secret key be means of TKEY message exchange. However, the existing
doesn't care fully about the management of keys which became too old, TKEY doesn't care fully about the management of keys which became too
or dangerous after long time usage. old, or dangerous after long time usage.
It is ideal that the number of secret which a pair of hosts share It is ideal that the number of secret which a pair of hosts share
should be limited only one, because having too many keys for the same should be limited only one, because having too many keys for the same
purpose might not only be a burden to resolvers for managing and purpose might not only be a burden to resolvers for managing and
distinguishing according to servers to query, but also doesn't seem distinguishing according to servers to query, but also does not seem
to be safe in terms of storage and protection against attackers. to be safe in terms of storage and protection against attackers.
Moreover, perhaps holding old keys long time might give attackers Moreover, perhaps holding old keys long time might give attackers
chances to compromise by scrupulous calculation. chances to compromise by scrupulous calculation.
Therefore, When a new shared secret is established by TKEY, the Therefore, when a new shared secret is established by TKEY, the
previous old secret used until then should be revoked immediately. To previous old secret should be revoked immediately. To accomplish
accomplish this, DNS servers must support a protocol for key renewal. this, DNS servers must support a protocol for key renewal. This
document specifies procedure to refresh secret keys between two hosts
This document specifies procedure to refresh secret keys between two which is defined within the framework of TKEY, and it is called "TKEY
hosts which is defined within the framework of TKEY, and it is called Secret Key Renewal Mode".
"TKEY Secret Key Renewal Mode".
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" in this The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
1.1. Overview of Secret Key Renewal Mode 1.1. Defined Words
* Inception Time: Beginning of the shared secret key lifetime. This
value is determined when the key is generated.
* Expiry Limit: Time limit of the key's validity. This value is
determined when a new key is generated. After Expiry Limit, server
and client (resolver) must not authenticate TSIG signed with the key.
Therefore, Renewal to the next key should be carried out before
Expiry Limit.
* Partial Revocation Time: Time when server judges the key is too old
and must be updated. It must be between Inception Time and Expiry
Limit. This value is determined by server freely following its
security policy. e.g., if the time from Inception to Partial
Revocation is short, renewal will be carried out more often, which
might be safer.
* Revocation Time: Time when the key becomes invalid and can be
removed. This value is not determined in advance because it is the
actual time when revocation is completed.
* Adoption Time: Time when the new key is adopted as the next key
formally. After Adoption, the key is valid and server and client can
generate or verify TSIG making use of it. Adoption Time also means
the time when it becomes possible to remove the previous key, so
Revocation and Adoption are usually done at the same time.
Partial
Inception Revocation Revocation Expiry Limit
| | | |
|----------------|- - - - - - >>|- (revoked) -|
| | | |
previous key | | |
|- - - -|-------------------->> time
| | new key
Inception Adoption
1.2. New Format and Assigned Numbers
TSIG
ERROR = (PartialRevoke), to be defined
TKEY
Mode = (DH exchange for key renewal), to be defined
For detailed format, see section 2.3.
Mode = (key adoption), to be defined
For detailed format, see section 2.4.
1.3. Overview of Secret Key Renewal Mode
When a server receives a query from a client signed with a TSIG key, When a server receives a query from a client signed with a TSIG key,
It always checks if the present time is within the range of usage It always checks if the present time is within the range of usage
duration it considers safe. If it is judged that the key is too old, duration it considers safe. If it is judged that the key is too old,
the server comes to be in "partial revocation" state about the key. i.e. after Partial Revocation Time, the server comes to be in Partial
Revocation state about the key.
In this state, whenever a client sends a normal query (e.g. question In this state, whenever a client sends a normal query (e.g., question
about A RR) other than TKEY "Renewal" request with TSIG signed with about A RR) other than TKEY Renewal request with TSIG signed with the
the old key, the server returns an error message to notify that the old key, the server returns an error message to notify that the time
time to renew has come. This is called "PartialRevoke" error to renew has come. This is called "PartialRevoke" error message.
message.
The client which got this error is able to notice that it is The client which got this error is able to notice that it is
necessary to refresh the secret. To make a new shared secret, it necessary to refresh the secret. To make a new shared secret, it
sends a TKEY "Renewal" request. In the "Renewal" process, Diffie- sends a TKEY Renewal request. In this process, Diffie-Hellman
Hellman Exchange is used. After new secret establishment, the client Exchange is used. After new secret establishment, the client sends a
retries the original query to the server. When the server receives TKEY Adoption request. If this is admitted by the server, the new key
it and succeeds to verify TSIG signed with the new secret key, the is formally adopted, and at the same time the corresponding old
key is formally adopted, and at the same time the corresponding old secret is invalidated. Then the client can send the first query again
secret is invalidated. signed with the new key.
1.2. Comparison of Secret Key Renewal and usual Diffie-Hellman
Exchanged Keying
If you use Diffie-Hellman Exchanged Keying [RFC2930], a new key can
be generated after message exchange. Thus, if clients take heed of
inception and expiration time of their keys and can send DH Exchanged
Keying queries, it is possible to change secrets in regular
intervals.
However, this method has a few difficulties in terms of operation.
First, It is impossible for clients to sense timings of sending
Diffie-Hellman Exchanged Keying queries based on the previous answers
returned from servers: no information about key refresh timing is
written in answer messages.
In addition, if clients send Keying requests too many times, servers
will have to create a great many secret keys, which will waste
servers' memory. For example, clients occasionally fail to get keying
answers because DNS messages can be exchanged on UDP and might be
sometimes dropped. Then, they will try to send requests again, and
the servers will have to make other keys more. On top of that,
possibly there might be malicious clients that want only to annoy
servers by sending a lot of requests.
"Secret Key Renewal Mode" solves these problems. Because this mode's Key renewal procedure is executed based on two phase commit
requests are often triggered by the detection of "PartialRevoke" TSIG mechanism. The first phase is the TKEY Renewal request and its
error answers (defined in this document), clients know key renewal response, which means preparatory confirmation for key update. The
timing at any time even if they haven't traced old keys' second phase is Adoption request and its response. If the server gets
inception/expiration time or have forgotten them. Besides, memory request and client receives the response successfully, they can
waste can be prevented because servers always restrict clients which finish renewal process. If any error happens and renewal process
can establish new secrets to those who have the corresponding fails during these phases, client should roll back to the beginning
previous old secrets, and servers never permit that two or more new of the first phase, and send TKEY Renewal request again. This
keys following one old key are created. It can be said that this rollback can be done until the Expiry Limit of the key.
"Renewal" Mode specifies concrete procedure to switch an old key to
new one smoothly, not limited only in adding or deleting a key.
2. Shared secret key renewal 2. Shared Secret Key Renewal
Suppose a server and a client agree to change their TSIG keys Suppose a server and a client agree to change their TSIG keys
periodically. Key renewal procedure is defined between two hosts. periodically. Key renewal procedure is defined between two hosts.
2.1. Detection of secret expiration 2.1. Key Usage Time Check
DNS servers permitting TSIG key renewal MUST keep and be able to
recognize all secret inception and expiration time about keys. Each
secret key has one inception time and one expiration time. Whenever a
server receives a query with TSIG and can find a key whose name is
indicated in TSIG, the server checks inception and expiration time
based on the information of the server's own.
At least either one of two hosts which make use of TKEY Key Renewal Whenever a server receives a query with TSIG and can find a key that
Mode MUST be able to own and supervise the time values about their is used for signing it, the server checks its Inception time, Partial
shared keys too. The value is called "partial revocation time" which Revocation time and Expiry Limit (this information is usually
means secret renewal timing. "partial revocation time" about each key memorized by the server).
MUST be between the key's inception and expiration time. The time is
usually configured by the administrator of the server. That is to
say, the server can freely decide them following its security policy:
if the time from inception to partial revocation time is short, key
renewal will be often carried out, which might be safer.
When the present time is before inception time, the server MUST NOT When the present time is before Inception Time, the server MUST NOT
verify TSIG with the key, and server acts the same way as when no verify TSIG with the key, and server acts the same way as when no
valid key is found, following [RFC2845]. valid key is found, following [RFC2845].
When the present time is equal to inception time, or between When the present time is equal to Inception Time, or between
inception time and partial revocation time, the behavior of the Inception Time and Partial Revocation Time, the behavior of the
server is the same as when a valid key is found, required in server is the same as when a valid key is found, required in
[RFC2845], as long as the server is not in the process of "partial
key revocation" written below.
When the present time is the same as the partial revocation time, or
between the partial revocation time and the expiration time, the
server behaves according to the protocol written below.
When the present time is the same as the expiration time or after it,
the server MUST NOT verify TSIG with the key, and returns error
messages in the same way as when no valid key is found, following
[RFC2845]. [RFC2845].
2.2. Partial key revocation When the present time is the same as the Partial Revocation Time, or
between the Partial Revocation Time and Expiry Limit, the server
comes to be in Partial Revocation state about the TSIG key and
behaves according to the next section.
When the server detects that the present time is past the partial When the present time is the same as the Expiry Time or after it, the
revocation time, the server comes to be in "partial revocation" state server MUST NOT verify TSIG with the key, and returns error messages
about the TSIG key. Now we say the server has partially revoked the in the same way as when no valid key is found, following [RFC2845].
key and the old key has come to be a "partially revoked key".
If the server judges with some reason that the key must be changed in 2.2. Partial Revocation
advance before partial revocation time, it can move immediately into
"partial revocation" state, but in that case the server MUST set its
partial revocation time to the present time. Servers can partially
revoke keys before their partial revocation time which they set
before, but MUST NOT do it before inception time.
In "partial revocation" state, servers which have received queries In Partial Revocation state, we say the server has partially revoked
signed with the partially revoked keys MUST NOT answer them except the key and the key has become a "partially revoked key".
when they are "DH exchange for key renewal" requests (see section
2.3). Instead, they return TSIG error messages whose error codes are
"PartialRevoke" (See section 9).
"PartialRevoke" error messages have the role to inform clients of the Server which has received queries signed with the partially revoked
keys' partial revocation and urge them to send TKEY key renewal key MUST NOT answer them except when they are "DH exchange for key
requests. These error responses MUST be signed with those partial renewal" requests (See section 2.3.) or "key adoption" requests (See
revoked keys if the queries are signed with them. They are sent only section 2.4.). Instead, it returns TSIG error messages whose error
when the keys used for queries' TSIG are found to be partially codes are "PartialRevoke" (See section 9.)
revoked. If the MAC of TSIG cannot be verified with the partially
revoked keys, servers MUST NOT return "PartialRevoke" error with MAC,
but should return another error such as "BADSIG" without MAC; in
other words, a server informs its key's partial revocation only when
the MAC in the received query was valid.
2.3. Query for DH exchange for key renewal PartialRevoke error messages have the role to inform clients of the
keys' partial revocation and urge them to send TKEY Renewal requests.
These error responses MUST be signed with those partial revoked keys
if the queries are signed with them. They are sent only when the keys
used for queries' TSIG are found to be partially revoked. If the MAC
of TSIG cannot be verified with the partially revoked keys, servers
MUST NOT return PartialRevoke error with MAC, but should return
another error such as "BADSIG" without MAC; in other words, a server
informs its key's partial revocation only when the MAC in the
received query is valid.
2.3.1. Query 2.3. Renewal Request
If a client has received a "PartialRevoke" Error and authenticated 2.3.1. Query for DH Exchange for Key Renewal
the response based on TSIG MAC, it sends a TKEY secret key renewal
request to the server. The request MUST be signed with TSIG or be If a client has received a PartialRevoke Error and authenticated the
added SIG(0) [RFC2931] for authentication. The client can use the response based on TSIG MAC, it sends a TKEY query for Diffie-Hellman
partial revoked key for TSIG. exchange for key renewal (in this document, we call it Renewal
request, too.) to the server. The request MUST be signed with TSIG or
SIG(0) [RFC2931] for authentication. The client can use the partial
revoked key for TSIG.
The request message has the structure given below. The request message has the structure given below.
Question section's QNAME field is the same as the NAME filed of Question section's QNAME field is the same as the NAME filed of
TKEY written below. TKEY written below.
In additional section, there is one KEY RR and one TKEY RR. KEY RR In additional section, there is one KEY RR and one TKEY RR. KEY RR
is the client's Diffie-Hellman public key [RFC2539]. TKEY RR has is the client's Diffie-Hellman public key [RFC2539]. TKEY RR has
the structure and values described below: the structure and values described below:
skipping to change at page 7, line 32 skipping to change at page 7, line 27
Mode: u_int16_t "DH exchange for key renewal" Mode: u_int16_t "DH exchange for key renewal"
see section 9. see section 9.
Error: u_int16_t see description below Error: u_int16_t see description below
Key Size: u_int16_t see description below Key Size: u_int16_t see description below
Key Data: octet-stream Key Data: octet-stream
Other Size: u_int16_t (defined in [RFC2930]) Other Size: u_int16_t (defined in [RFC2930])
size of other data size of other data
Other Data: newly defined: see description below Other Data: newly defined: see description below
Mode field of TKEY RR in the message stores the value of "DH Mode field of TKEY RR in the message stores the value of "DH
exchange for key renewal" which is newly defined. See section 9. exchange for key renewal". See section 9.
For "NAME" field, both non-root and root name are allowed. It may For "NAME" field, both non-root and root name are allowed. It may
be used for a new key's name in the same manner as [RFC2930] 2.1. be used for a new key's name in the same manner as [RFC2930] 2.1.
"Algorithm" is the domain name for a new secret as a result of this "Algorithm" is the domain name for a new secret as a result of this
key renewal message. It specifies the algorithm used with a newly key renewal message. It specifies the algorithm used with a newly
produced key. In many cases algorithm is not changed after key produced key.
renewal but may be changed (e.g. from HMAC-MD5 to HMAC-SHA1). The
client should allow for what algorithms are supported by the server
when it wants to change.
"Inception" and "Expiration" times are those requested for the
keying material, that is, requested usage period of a new key.
"Key Data" is used as a random. This is provided in the same way as
[RFC2930] 4.1 in order to avoid always deriving the same keying
material.
"Inception" and "Expiration" are those requested for the keying
material, that is, requested usage period of a new key. "Key Data"
is used as a random. This is provided in the same way as [RFC2930]
4.1 in order to avoid always deriving the same keying material.
"Error" is an extended RCODE which includes "PartialRevoke" value. "Error" is an extended RCODE which includes "PartialRevoke" value.
See section 9. See section 9.
In "DH exchange for key renewal" mode, "Other Data" field has the In DH exchange for key renewal mode, "Other Data" field has the
structure given below. They describe attributes of the partially structure given below. They describe attributes of the partially
revoked key. revoked key.
in Other Data filed: in Other Data filed:
Field Type Comment Field Type Comment
------- ------ ------- ------- ------ -------
OldNAME domain name of the old key OldNAME domain name of the old key
OldAlgorithm domain algorithm of the old key OldAlgorithm domain algorithm of the old key
2.3.2. Response 2.3.2. Response for DH Exchange for Key Renewal
The server which has received a "DH exchange for key renewal" TKEY The server which has received a "DH exchange for key renewal" TKEY
request, it tries to verify TSIG or SIG(0) accompanying it. request, it tries to verify TSIG or SIG(0) accompanying it. If the
verified TSIG is signed with the partially revoked key, the request
If the TSIG is signed with the partially revoked key and can be MUST be authenticated and accepted.
verified, the message MUST be authenticated. Note that in this case
the server doesn't return "PartialRevoke" error but do the same
process as when TSIG signed with other valid keys or SIG(0) is
confirmed in requests.
If the partially revoked key indicated in the request TKEY OldName If the partially revoked key indicated in the request TKEY's OldName
doesn't really exist at the server, or incompatible DH key is found field does not really exist at the server, or incompatible DH key is
in the request, BADKEY [RFC 2845] is given in Error Field. FORMERR is found in the request, "BADKEY" [RFC 2845] is given in Error Field.
given if the query included no DH KEY. "FORMERR" is given if the query included no DH KEY.
If there is no error, the server processes a response according to If there are no errors, the server processes a response according to
Diffie-Hellman exchanged keying. Response message's details are Diffie-Hellman exchanged keying. Details of response messages are
below: below:
In answer section, there is one TKEY RR. The TKEY RR shows the In answer section, there is one TKEY RR. The TKEY RR shows the
newly produced key's attributes such as a key name and a algorithm. newly produced key's attributes such as a key name and algorithm.
Its format is defined as a response of the previous key renewal Its format is defined as a response of the previous key renewal
request, so all values are equal to 2.3.1 except TKEY NAME, TKEY request, so all values are equal to 2.3.1 except TKEY NAME, TKEY
RDLEN, RDATA's Inception, Expiration, Key Size and Key Data as long RDLEN, RDATA's Inception, Expiration, Key Size and Key Data as long
as no error has occurred. as no error has occurred.
NAME field specifies the name of newly produced key which the "NAME" field specifies the name of newly produced key which the
client will have to use. client will have to use.
TKEY Inception and Expiration time mean the period of the produced "Inception" field and "Expiration" field mean the period of the
key usage. Inception time MUST be set to the time when the new key produced key usage. "Inception" should be set to be the time when
is generated, thus after clients receive responses, they can use the new key is actually generated or the time before it, and it
new keys immediately. Expiration time will be determined by servers will be regarded as Inception Time. "Expiration" is determined by
allowing for request messages. However, if servers judge requested the server, and it will be regarded as Expiry Limit.
usage periods are too short or too long, they can ignore them and
decide expiration time freely based on their own security policies.
Once servers have decided expiration time and already returned Once the server has decided Expiry Limit and returned a response,
responses, they should obey them as long as they can. In other it should obey them as long as it can. In other words, they SHOULD
words, they SHOULD NOT change time values for checking expiration NOT change time values for checking Expiry Limit in the future
in the future without any special reason (e.g. a security issue without any special reason (e.g., a security issue such as
such as "emergency compulsory revocation" described in Section 8). "Emergency Compulsory Revocation" described in section 8).
Therefore, before sending responses, they must memorize correctly
the time values with secret key data.
Note that the "partial revocation" time about a new key isn't Note that the Partial Revocation Time about a new key is not
decided base on the client's request. The server can set freely any decided and informed based only on the client's request. The server
value as long as it is between inception and expiration. However, can decide any value as long as it is between Inception and Expiry
it is recommended that the period from inception to "partial Limit. However, it is recommended that the period from Inception to
revocation" time should be fixed as the server side's configuration Partial Revocation should be fixed as the server side's
or should be set the same as the corresponding old key's one. configuration or should be set the same as the corresponding old
key's one.
TKEY Key Data is used as an additional nonce to avoid deriving the TKEY Key Data is used as an additional nonce to avoid deriving the
same keying material for the same pair of DH key, which is the same same keying material for the same pair of DH key, which is the same
as [RFC2930] 4.1. as [RFC2930] 4.1.
If the TKEY error field is zero, The resolver supplied Diffie- If the TKEY error field is zero, The resolver supplied Diffie-
Hellman KEY RR SHOULD be echoed in the additional section and a Hellman KEY RR SHOULD be echoed in the additional section and a
server Diffie-Hellman KEY RR will also be present in the answer server Diffie-Hellman KEY RR will also be present in the answer
section like [RFC2930] 4.1. section like [RFC2930] 4.1.
At this moment, the server gets a new secret. However, it might At this moment, the server gets a new secret. However, it might
receive another "DH exchange for key renewal" TKEY request whose receive another "DH exchange for key renewal" TKEY request whose
OldName in TKEY indicates the same partial revoked key. Mostly such OldName indicates the same partial revoked key. Mostly such messages
messages originate in client's resending. In this case, the server originate in client's resending or rollback. In this case, the server
processes Diffie-Hellman exchanged keying again and MUST replace the processes Diffie-Hellman exchanged keying again and MUST replace the
stored secret with the newest produced secret. The secret key stored secret with the newest produced secret. The secret key
produced before comes to be invalid and should be removed from produced before comes to be invalid and should be removed from
memory. memory.
Even if clients send "DH exchange for key renewal" though the keys Even if client sends "DH exchange for key renewal" though the key
described in OldName have not been partially revoked yet, servers described in OldName has not been partially revoked yet, server must
must do renewal processes. But the moment servers get key renewal do renewal processes. But at the moment when the servers accepts
requests with valid authentication, they MUST forcibly consider the such requests with valid authentication, it MUST forcibly consider
keys are already partially revoked, that is, the key's "partial the key is already partially revoked, that is, the key's Partial
revocation" time must be set to be the present time (i.e. the time Revocation Time must be changed into the present time (i.e., the time
when the server receives the request). when the server receives the request).
2.4. Key Adoption 2.4. Key Adoption
After Receiving a TKEY answer, the client gets the same secret as the 2.4.1. Query for Key Adoption
server. Then, it tries to resolve the original question which was
wanted first (i.e. the question clients tried to ask before it got
the "PartialRevoke" error).
As soon as the message signed with the new key reaches the server and After receiving a TKEY Renewal answer, the client gets the same
is verified, the new key is formally adopted and at the same time the secret as the server. Then, it sends a TKEY Adoption request. The
partially revoked key expires completely. After that the server MUST request's question section's QNAME field is the same as the NAME
NOT verify any queries with the completely revoked key. At this filed of TKEY written below. In additional section, there is one TKEY
moment the server comes to be out of "partial revocation sate", and RR. TKEY RR has the structure and values described below.
it is only the new adopted key that is used between the server and
the host.
2.5. Considerations about non-compliant hosts for secret key renewal "NAME" field is the new key's name to be adopted which was already
generated by Renewal message. "Algorithm" is its algorithm. "Incep-
tion" means the key's Inception Time, and "Expiration" means Expiry
Limit.
Key renewal requests and responses must be exchanged between hosts "Mode" field is the value of "key adoption", which is defined
newly. See section 9.
"Other Data" field in Adoption has the same structure as that of
"DH exchange for key renewal". "OldName" means the previous old
key, and "OldAlogirthm" means its algorithm.
Key Adoption request MUST be signed with TSIG or SIG(0) for
authentication. The client can sign TSIG with the previous key. Note
that until Adoption is finished, the new next key is treated as
invalid, thus it cannot be used for authentication immediately.
2.4.2. Response for Key Adoption
The server which has received Adoption request, it verifies TSIG or
SIG(0) accompanying it. If the TSIG is signed with the partially
revoked key and can be verified, the message MUST be authenticated.
If the next new key indicated by the request TKEY's "NAME" is not
really present at the server, BADNAME [RFC 2845] is given in Error
Field and the error message is returned.
If the next key really exists and it has not been adopted formally
yet, the server confirms the previous key's existence indicated by
the "OldName" field. If it succeeds, the server executes Adoption of
the next key and Revocation of the previous key. Response message
duplicates the request's TKEY RR with NoError, including "OldName"
and "OldAlgorithm" that indicate the revoked key.
If the next key exists but it is already adopted, the server returns
a response message regardless of the substance of the request TKEY's
"OldName". In this response, Response TKEY RR has the same data as
the request's one except as to its "Other Data" that is changed into
null (i.e., "Other Size" is zero), which is intended for telling the
client that the previous key name was ignored, and the new key is
already available.
Client sometimes has to retry Adoption request. Suppose the client
sent request signed with the partially revoked key, but its response
did not return successfully (e.g., due to the drop of UDP packet).
Client will probably retry Adoption request; however, the request
will be refused in the form of TSIG "BADKEY" error because the
previous key was already revoked. In this case, client should
retransmit Adoption request signed with the next key, and expect a
response which has null "Other Data" for confirming the completion of
renewal.
2.5. Considerations about Non-compliant Hosts
Key Renewal requests and responses must be exchanged between hosts
which can understand them and do proper processes. "PartialRevoke" which can understand them and do proper processes. "PartialRevoke"
error messages will be only ignored if they should be returned to error messages will be only ignored if they should be returned to
non-compliant hosts. non-compliant hosts.
Note that servers don't inform actively the necessity of renewal to Note that server does not inform actively the necessity of renewal to
clients, but inform it as responses invoked by clients' queries. clients, but inform it as responses invoked by client's query.
Servers don't need to care whether the "PartialRevoke" errors have Server needs not care whether the "PartialRevoke" errors has reached
reached clients or not. If clients have not received yet because of client or not. If client has not received yet because of any reasons
any reasons such as UDP packet drops, they will resend the queries, such as packet drops, it will resend the queries, and finally will be
and finally will be able to get "PartialRevoke" information about the able to get "PartialRevoke" information.
keys they have been using.
3. Secret Storage 3. Secret Storage
Every hosts should keep all secrets and attached information (e.g. Every server should keep all secrets and attached information, e.g.
inception and expiration etc.) safe to be able to recover from Inception, Expiry Limit etc. safe to be able to recover from
unexpected stop of the server. To accomplish this, formally adopted unexpected stop. To accomplish this, formally adopted keys should be
keys should be memorized not only on memory, but also be stored in memorized not only on memory, but also be stored in the form of some
the form of some files. Make sure that this should be protected files. Make sure that this should be protected strongly not to be
strongly not to be read by others. If possible, they should be stored read by others. If possible, they should be stored in encrypted form.
in encrypted form.
4. Compulsory key revocation by servers 4. Compulsory Key Revocation by Server
There is a rare but possible case that although servers have already There is a rare but possible case that although servers have already
partially revoked keys, clients don't try to send any renewal partially revoked keys, clients do not try to send any renewal
requests. If this state continues, in the future it will become the requests. If this state continues, in the future it will become the
time of expiration. After expiration, the keys will be completely time of Expiry Limit. After Expiry Limit, the keys will be expired
removed, so this is called compulsory key revocation by servers. and completely removed, so this is called Compulsory Key Revocation
by server.
If expiration time is too distant from the partial revocation time, If Expiry Limit is too distant from the Partial Revocation Time, then
then even though very long time passes, clients will be able to even though very long time passes, clients will be able to refresh
refresh secrets only if they add TSIG signed with those old partially secrets only if they add TSIG signed with those old partially revoked
revoked keys into requests, which is not safe. keys into requests, which is not safe.
On the other hand, if expiration time is too close to partial On the other hand, if Expiry Limit is too close to Partial Revocation
revocation time, perhaps clients might not be able to notice their Time, perhaps clients might not be able to notice their keys' Partial
keys' partial revocation by getting "PartialRevoke" errors. Revocation by getting "PartialRevoke" errors.
Therefore, servers should set proper expiration time to their keys, Therefore, servers should set proper Expiry Limit to their keys,
considering both their keys' safety, and enough time for clients to considering both their keys' safety, and enough time for clients to
send requests and process renewal. send requests and process renewal.
4.1. Example of compulsory key revocation 4.1. Example
It might be ideal to provide both SIG(0) and TSIG as authentication It might be ideal to provide both SIG(0) and TSIG as authentication
methods. For example: methods. For example:
A client and a server start SIG(0) authentication at first, to A client and a server start SIG(0) authentication at first, to
establish TSIG shared keys by means of "Query for Diffie-Hellman establish TSIG shared keys by means of "Query for Diffie-Hellman
Exchanged Keying" as described in [RFC 2930] 4.1. Once they get Exchanged Keying" as described in [RFC 2930] 4.1. Once they get
shared secret, they keep using TSIG for usual queries and shared secret, they keep using TSIG for usual queries and
responses. After a while the server returns a "ParitalRevoke" error responses. After a while the server returns a "ParitalRevoke" error
and they begin a key renewal process. Both TSIG signed with and they begin a key renewal process. Both TSIG signed with
partially revoked keys and SIG(0) are okay for authentication, but partially revoked keys and SIG(0) are okay for authentication, but
TSIG would be more easy to use considering calculation efficiency. TSIG would be more easy to use considering calculation efficiency.
If some troubles should happen such as client host's long If any troubles should happen such as client host's long suspension
suspension against expectation, the server will carry out against expectation, the server will do compulsory revocation.
compulsory revocation. After recovery if the client sends a key After recovery if the client sends a key Renewal request to refresh
renewal request to refresh the old key, it will fail because the the old key, it will fail because the key is removed from the
key is removed from the server. So, the client will send "Query for server. So, the client will send "Query for Diffie-Hellman
Diffie-Hellman Exchanged Keying" with SIG(0) to make a new shared Exchanged Keying" with SIG(0) to make a new shared key again.
key again.
5. Special considerations for two servers' case 5. Special Considerations for Two servers' Case
This section refers to the case where both two hosts are DNS servers This section refers to the case where both two hosts are DNS servers
which can act as full resolvers as well. If one server (called which can act as full resolvers as well. If one server (called Server
"Server A") decides to partially revoke a shared key (called "Key A- A) comes to want to refresh a shared key (called "Key A-B"), it will
B"), it will await a TKEY renewal request from the other server await a TKEY Renewal request from the other server (called Server B).
(called "Server B"). But perhaps Server A will have to send queries But perhaps Server A will have to send queries with TSIG immediately
with TSIG immediately to Server B to resolve some queries if it is to Server B to resolve some queries if it is asked by other clients.
asked by other clients.
At this time, Server A is allowed to send a "Renewal" request to At this time, Server A is allowed to send a Renewal request to Server
Server B, if Server A finds the key to use now is too old and should B, if Server A finds the key to use now is too old and should be
be renewed. To provide this function, both servers MUST be able to renewed. To provide this function, both servers should be able to
receive and process key renewal request from each other if they agree receive and process key renewal request from each other if they agree
to refresh their shared secret keys by "DH exchange for key renewal" to refresh their shared secret keys by DH exchange for key renewal
procedures. procedures.
Note that the initiative in key renewal belongs to Server A because Note that the initiative in key renewal belongs to Server A because
it can notice the "partial revocation" time and decide key renewal. it can notice the Partial Revocation Time and decide key renewal. If
If Server B has information about "partial revocation" time as well, Server B has information about Partial Revocation Time as well, it
it can also decide for itself to send "DH exchange for key renewal" can also decide for itself to send "DH exchange for key renewal" to
to Server A. But it is not essential for both two servers have Server A. But it is not essential for both two servers have
information about key renewal timing. information about key renewal timing.
5.1. To cope with collisions of renewal requests 5.1. To Cope with Collisions of Renewal Requests
At least one of two hosts which use "DH exchange for key renewal" At least one of two hosts which use "DH exchange for key renewal"
must know their key renewal information such as "partial revocation" must know their key renewal information such as Partial Revocation
times. Surely both of them can have information. Time. It is okay that both hosts have it.
Provided that both two servers know key renewal timing information, Provided that both two servers know key renewal timing information,
there is possibility for them to begin partial revocation and sending there is possibility for them to begin partial revocation and sending
renewal requests to each other at the same time. Such collisions will renewal requests to each other at the same time. Such collisions will
not happen so often because key renewal requests are usually invoked not happen so often because Renewal requests are usually invoked when
when hosts want to send queries, but we should take the possibility hosts want to send queries, but it is possible.
into consideration.
When one of two servers try to send renewal requests, it must protect When one of two servers try to send Renewal requests, it must protect
old secrets that it has partially revoked and prevent it from being old secrets that it has partially revoked and prevent it from being
refreshed by any requests from the other server (i.e. it must lock refreshed by any requests from the other server (i.e., it must lock
the old secret during the process of renewal). While the server is the old secret during the process of renewal). While the server is
sending renewal requests and waiting responses, it ignores the other sending Renewal requests and waiting responses, it ignores the other
server's key renewal requests. server's Renewal requests.
Therefore, servers might fail to change secrets by means of their own Therefore, servers might fail to change secrets by means of their own
requests to others. After failure they will try to resend, but they requests to others. After failure they will try to resend, but they
should wait for random delays by the next retries. If they get any should wait for random delays by the next retries. If they get any
key renewal requests from others while they are awaiting the delays, Renewal requests from others while they are waiting, their shared
their shared keys may be changed, then they don't need to send any keys may be refreshed, then they do not need to send any Renewal
renewal requests now for themselves because the secrets are already requests now for themselves.
refreshed.
6. Key name consideration 6. Key Name Considerations
Since both servers and clients have only to distinguish new secrets Since both servers and clients have only to distinguish new secrets
and old ones, keys' names don't need to be specified. But it is and old ones, keys' names do not need to be specified strictly. But
recommended that some serial number or key generation time should be it is recommended that some serial number or key generation time
added to the name and that the names of keys between the same pair of should be added to the name and that the names of keys between the
hosts should have some common labels among their keys. For example, same pair of hosts should have some common labels among their keys.
suppose A.example.com. (Server A) and B.example.com. (Client B) For example, suppose A.example.com. and B.example.com. share the key
shares the key like this: "<serial number>.A.example.com.B.example.com." such as
"10010.A.example.com.B.example.com.". After key renewal, they change
10010.A.example.com.B.example.com. their secret and name into "10011.A.example.com.B.example.com."
and after the process of key renewal, they change their secret and
name into
10011.A.example.com.B.example.com.
If Server A is configured to accept TKEY key renewal requests by
Client B whose OldNAME field is such as:
<serial number>.A.example.com.B.example.com.
and the name of newly produced keys always follow the same format
too, it will be safer because Client B can renew only his secret keys
but cannot change others' keys. Even if Client B should send TKEY key
renewal requests whose OldNAME is like:
<serial number>.A.example.com.C.others.com.
Server A will refuse it because the shared keys between A and B are
restricted to have the name such as <serial
number>.A.example.com.B.example.com. and this request is considered
to be beyond Client B's authority.
But, a more safer method to prevent others from changing keys beyond
their authorities is that a server also memorizes correctly which
hosts own keys (i.e. memorizes key identities with regard to owners)
and it only accepts renewal requests from hosts those identities have
been confirmed by checking request's TSIG or SIG(0).
Servers and clients must be able to use keys properly according to Servers and clients must be able to use keys properly according to
hosts to query. If new keys are generated and adopted, they must use servers to query. Because TSIG secret keys themselves do not have any
only them because old keys have already expired. Because TSIG secret particular IDs to be distinguished and would be identified by their
keys themselves don't have any IDs to be distinguished and would be names and algorithm, it must be understood correctly what keys are
identified by their names and algorithm, hosts must understand refreshed.
correctly what keys are refreshed.
7. Example usage of TKEY Secret Key Renewal Mode 7. Example Usage of Secret Key Renewal Mode
This is an example of "Renewal" mode usage where a Server, This is an example of Renewal mode usage where a Server,
ns.example.com, and a Client, client.exmple.com have an initial server.example.com, and a Client, client.exmple.com have an initial
shared secret key named "00.client.example.com.ns.example.com" shared secret key named "00.client.example.com.server.example.com".
(1) The time values about key (1) The time values about key
"00.client.example.com.ns.example.com" was set as follows: "00.client.example.com.server.example.com" was set as follows:
inception is at 6:00, expiration is at 11:00. Inception Time is at 6:00, Expiry Limit is at 11:00.
(2) At Server, a time value about renewal timing has been set too: (2) At Server, a time value about renewal timing has been set too:
partial revocation time is at 8:00. This may be unknown to Client Partial Revocation Time is at 8:00.
because it was freely set by Server's administrator.
(3) Suppose the present time is 7:00. If Client sends a query (3) Suppose the present time is 7:00. If Client sends a query
signed with key "00.client.example.com.ns.example.com" to ask the signed with key "00.client.example.com.server.example.com" to ask
IP address of "www.somedomain.com", finally it will get a proper the IP address of "www.somedomain.com", finally it will get a
answer from Server with valid TSIG (No Error). proper answer from Server with valid TSIG (No Error).
(4) At 9:00. Client sends a query signed with key (4) At 9:00. Client sends a query signed with key
"00.client.example.com.ns.example.com" to ask the IP address of "00.client.example.com.server.example.com" to ask the IP address of
"www.otherdomain.com". But it won't get a proper answer from "www.otherdomain.com". But it will not get a proper answer from
Server. The response doesn't have any IP address information about Server. The response does not have any IP address information about
"www.otherdomain.com". Instead, it includes valid TSIG MAC signed "www.otherdomain.com". Instead, it includes valid TSIG MAC signed
with "00.client.example.com.ns.example.com", but its Error Code with "00.client.example.com.server.example.com", and its Error Code
indicates "PartialRevoke". indicates PartialRevoke.
(5) At 9:01. Since Client has understood that its key has been (5) At 9:01. Client sends a Renewal request to Server. This request
considered to be old by Server, it will send a "Renewal" request to is signed with key "00.client.example.com.server.example.com". It
Server. This request is signed with key includes data such as:
"00.client.example.com.ns.example.com". It includes data such as:
Question Section: Question Section:
QNAME = 01.client.example.com. (This can be set freely by QNAME = 01.client.example.com. (Client can set this freely)
Client)
TYPE = TKEY TYPE = TKEY
Additional Section: Additional Section:
01.client.example.com. TKEY 01.client.example.com. TKEY
Algorithm = hmac-md5-sig-alg.reg.int. Algorithm = hmac-md5-sig-alg.reg.int.
Inception = (value which means 9:01) Inception = (value which means 8:55)
Expiration = (value which means 14:00) Expiration = (value which means 14:00)
Mode = (DH exchange for key renewal) Mode = (DH exchange for key renewal)
OldName = 00.client.example.com.ns.example.com. OldName = 00.client.example.com.server.example.com.
OldAlgorithm = hmac-md5-sig-alg.reg.int. OldAlgorithm = hmac-md5-sig-alg.reg.int.
(Additional Section contains a KEY RR and a TSIG RR) Additional Section also contains a KEY RR for DH and a TSIG RR.
(6) As soon as Server receives this request, it tries to verify
TSIG. It is valid but signed with partial revoked key (6) As soon as Server receives this request, it verifies TSIG. It
"00.client.example.com.ns.example.com". However, since this is a is signed with the partially revoked key
request for "Renewal", Server accepts processing the renewal. "00.client.example.com.server.example.com". and Server accepts the
Server creates a new key by Diffie-Hellman calculation and returns request. It creates a new key by Diffie-Hellman calculation and
an answer which includes data such as: returns an answer which includes data such as:
Answer Section: Answer Section:
01.client.example.com.server.example.com. TKEY 01.client.example.com.server.example.com. TKEY
Algorithm = hmac-md5-sig-alg.reg.int. Algorithm = hmac-md5-sig-alg.reg.int.
Inception = (value meaning 9:01) Inception = (value meaning 8:55)
Expiration = (value meaning 14:00) Expiration = (value meaning 14:00)
Mode = (DH exchange for key renewal) Mode = (DH exchange for key renewal)
OldName = 00.client.example.com.ns.example.com. OldName = 00.client.example.com.server.example.com.
OldAlgorithm = hmac-md5-sig-alg.reg.int. OldAlgorithm = hmac-md5-sig-alg.reg.int.
(Answer Section also contains KEY RRs) Answer Section also contains KEY RRs for DH.
(Additional Section contains a TSIG RR) Additional Section also contains a TSIG RR.
This response is signed with key This response is signed with key
"00.client.example.com.ns.example.com" without error. "00.client.example.com.server.example.com" without error.
At the same time, Server decides to set the partial revocation time At the same time, Server decides to set the Partial Revocation Time
of this new key "01.client.example.com.server.example.com." as of this new key "01.client.example.com.server.example.com." as
11:00. 11:00.
(7) Client gets the response and checks TSIG MAC, and calculates (7) Client gets the response and checks TSIG MAC, and calculates
Diffie-Hellman. It will get a new key, and it has been named Diffie-Hellman. It will get a new key, and it has been named
"01.client.example.com.server.example.com" by Server. "01.client.example.com.server.example.com" by Server.
(8) Client will retry to send an original question about (8) At 9:02. Client sends an Adoption request to Server. This
"www.otherdomain.com". It is signed with the created key request is signed with the previous key
"01.client.example.com.server.example.com". "00.client.example.com.server.example.com". It includes:
(9) Server verifies the query's TSIG. Since it succeeds, it adopts Question Section:
key "01.client.example.com.server.example.com" formally. Key QNAME = 01.client.example.com.server.example.com.
"00.client.example.com.server.example.com." is removed from Server. TYPE = TKEY
Then, it returns an answer about the IP address of
"www.otherdomain.com" with TSIG signed with key
"01.client.example.com.server.example.com".
(10) Client knows key "01.client.example.com.server.example.com." Additional Section:
is adopted by Server. 01.client.example.com.server.example.com. TKEY
Algorithm = hmac-md5-sig-alg.reg.int.
Inception = (value which means 8:55)
Expiration = (value which means 14:00)
Mode = (key adoption)
OldName = 00.client.example.com.server.example.com.
OldAlgorithm = hmac-md5-sig-alg.reg.int.
(11) This key is valid until 11:00. After that, it will be Additional Section also contains a TSIG RR.
partially revoked again.
8. Security consideration (9) Server verifies the query's TSIG. It is signed with the
previous key and authenticated. It returns a response whose TKEY RR
is the same as the request's one. The response is signed with key
"00.client.example.com.server.example.com.". As soon as the
response is sent, Server revokes and removes the previous key. At
the same time, key "01.client.example.com.server.example.com." is
validated.
(10) Client acknowledges the success of Adoption by receiving the
response. Then, it will retry to send an original question about
"www.otherdomain.com". It is signed with the adopted key
"01.client.example.com.server.example.com", so Server authenticates
it and returns an answer.
(11) This key is used until 11:00. After that, it will be partially
revoked again.
8. Security Considerations
This document considers about how to refresh shared secret. Secret This document considers about how to refresh shared secret. Secret
changed by this method is used at servers in support of TSIG changed by this method is used at servers in support of TSIG
[RFC2845]. [RFC2845].
[RFC 2104] says that current attacks to HMAC do not indicate a [RFC 2104] says that current attacks to HMAC do not indicate a
specific recommended frequency for key changes but periodic key specific recommended frequency for key changes but periodic key
refreshment is a fundamental security practice that helps against refreshment is a fundamental security practice that helps against
potential weaknesses of the function and keys, and limits the damage potential weaknesses of the function and keys, and limits the damage
of an exposed key. This TKEY secret key renewal mode provides the of an exposed key. This TKEY secret key renewal mode provides the
method of periodical key refreshment. method of periodical key refreshment.
TKEY secret key renewal mode forbids clients to send queries as long TKEY Secret Key Renewal Mode forbids clients to send queries as long
as they don't change old keys. This means that when keys become old, as they do not change old keys. This means that when keys become old,
clients must spend rather lots of time to get answers they wanted clients must spend rather lots of time to get answers they wanted
originally because at first they must send key renewal requests. Thus originally because at first they must send key Renewal requests. Thus
the usage period of secrets should be considered carefully based on the usage period of secrets should be considered carefully based on
both TKEY processing performance and security. both TKEY processing performance and security.
This document specifies the procedure of periodical key renewal, but This document specifies the procedure of periodical key renewal, but
actually there is possibility for servers to have no choice other actually there is possibility for servers to have no choice other
than revoking their secret keys immediately especially when the keys than revoking their secret keys immediately especially when the keys
are found to be compromised by attackers. This is called "emergency are found to be compromised by attackers. This is called "Emergency
compulsory revocation". In this case, the server must set the Compulsory Revocation". For example, suppose the original Expiry
compromised key's expiration at the present time: the key must be Limit was set at 15:00, Partial Revocation Time at 12:00 and
revoked compulsorily. For example, suppose the original expiration Inception Time at 10:00. if at 11:00 the key is found to be
time was set at 15:00, partial revocation time at 12:00 and inception compromised, the server sets Expiry Limit forcibly to be 11:00 or
at 10:00. if at 11:00 the key is found to be compromised, the server before it.
can forcibly set expiration time 11:00.
Consequently, once "compulsory revocation" (See section 4) is carried Consequently, once Compulsory Revocation (See section 4) is carried
out, normal "renewal" process described in this document cannot be out, normal renewal process described in this document cannot be done
done any more as far as the key is concerned. But, after such any more as far as the key is concerned. But, after such accidents
accidents happened, the two hosts are able to establish secret keys happened, the two hosts are able to establish secret keys and begin
and begin "renewal" procedure only if they have other (non- renewal procedure only if they have other (non-compromised) shared
compromised) shared TSIG keys or safe SIG(0) keys for the TSIG keys or safe SIG(0) keys for the authentication of initial
authentication of initial secret establishment using Diffie-Hellman secret establishment using Diffie-Hellman Exchanged Keying.
Exchanged Keying.
9. IANA consideration 9. IANA Considerations
IANA needs to allocate a value for "DH exchange for key renewal" in IANA needs to allocate a value for "DH exchange for key renewal" and
the mode filed of TKEY. It also needs to allocate a value for "key adoption" in the mode filed of TKEY. It also needs to allocate a
"PartialRevoke" from the extended RCODE space. value for "PartialRevoke" from the extended RCODE space.
10. References 10. References
[RFC2104] [RFC2104]
H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
Authentication", RFC2104, February 1997. Authentication", RFC2104, February 1997.
[RFC2119] [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
skipping to change at page 18, line 8 skipping to change at page 18, line 8
D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
RFC 2930, September 2000. RFC 2930, September 2000.
[RFC2931] [RFC2931]
D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
)", RFC 2931, September 2000. )", RFC 2931, September 2000.
Authors' Addresses Authors' Addresses
Yuji Kamite Yuji Kamite
Information Technology Center, NTT Communications Corporation
the University of Tokyo, Tokyo Opera City Tower 21F,
2-11-16 Yayoi, Bunkyo-ku, 20-2, 3-chome, Nishi-Shinjuku, Shinjuku-ku,
Tokyo, 113-8658, Japan. Tokyo, 163-1421, Japan.
EMail: kamite@kaynet.ecc.u-tokyo.ac.jp EMail: y.kamite@ntt.com
Masaya Nakayama Masaya Nakayama
The University of Tokyo
Information Technology Center, Information Technology Center,
the University of Tokyo,
2-11-16 Yayoi, Bunkyo-ku, 2-11-16 Yayoi, Bunkyo-ku,
Tokyo, 113-8658, Japan. Tokyo, 113-8658, Japan.
EMail: nakayama@nc.u-tokyo.ac.jp EMail: nakayama@nc.u-tokyo.ac.jp
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/