draft-ietf-dnsext-tkey-renewal-mode-01.txt   draft-ietf-dnsext-tkey-renewal-mode-02.txt 
DNSEXT Working Group Yuji Kamite DNSEXT Working Group Yuji Kamite
INTERNET-DRAFT NTT Communications INTERNET-DRAFT NTT Communications
<draft-ietf-dnsext-tkey-renewal-mode-01.txt> Masaya Nakayama <draft-ietf-dnsext-tkey-renewal-mode-02.txt> Masaya Nakayama
Expires: Nov. 11, 2002 The University of Tokyo Expires: Mar. 24, 2003 The University of Tokyo
May 11, 2002 Sep. 24, 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 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4
1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4
2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5 2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5
2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5
2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6
2.3 Renewal Request . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 6
2.3.1 Query for DH Exchange for Key Renewal . . . . . . . . . . 6 2.3.1 TKEY RR structure for Key Renewal . . . . . . . . . . . . 8
2.3.2 Response for DH Exchange for Key Renewal . . . . . . . . 8
2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 9 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 9
2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10
2.5 Considerations about Non-compliant Hosts . . . . . . . . . . 10 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 10
3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11
4 Compulsory Key Revocation by Server . . . . . . . . . . . . . . . 11 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12
4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13
5 Special Considerations for Two Servers' Case . . . . . . . . . . 12 2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14
5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 12 3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 14
6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 13 4 Compulsory Key Revocation by Server . . . . . . . . . . . . . . . 14
7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 13 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 16 5 Special Considerations for Two Servers' Case . . . . . . . . . . 15
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 16 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 18 7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17
8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 19
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
TSIG [RFC2845] provides DNS message integrity and the TSIG [RFC2845] provides DNS message integrity and the
request/transaction authentication by means of message authentication request/transaction authentication by means of message authentication
codes (MAC). TSIG is a practical solution in view of calculation codes (MAC). TSIG is a practical solution in view of calculation
speed and availablity. However, TSIG does not have exchanging speed and availability. However, TSIG does not have exchanging
mechanism of shared secret keys between server and resolver, and mechanism of shared secret keys between server and resolver, and
administrators might have to exchange secret keys manually. TKEY administrators might have to exchange secret keys manually. TKEY
[RFC2930] is introduced to solve such problem and it can exchange [RFC2930] is introduced to solve such problem and it can exchange
secrets for TSIG via networks. 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, the existing secret key be means of TKEY message exchange. However, the existing
TKEY doesn't care fully about the management of keys which became too TKEY does not care fully about the management of keys which became
old, or dangerous after long time usage. too 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 does not 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 should be revoked immediately. To accomplish previous old secret should be revoked immediately. To accomplish
this, DNS servers must support a protocol for key renewal. This this, DNS servers must support a protocol for key renewal. This
document specifies procedure to refresh secret keys between two hosts document specifies procedure to refresh secret keys between two hosts
which is defined within the framework of TKEY, and it is called "TKEY which is defined within the framework of TKEY, and it is called "TKEY
Secret Key Renewal Mode". Secret Key Renewal Mode".
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" in this The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and
document are to be interpreted as described in [RFC 2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC 2119].
1.1. Defined Words 1.1. Defined Words
* Inception Time: Beginning of the shared secret key lifetime. This * Inception Time: Beginning of the shared secret key lifetime. This
value is determined when the key is generated. value is determined when the key is generated.
* Expiry Limit: Time limit of the key's validity. This value is * Expiry Limit: Time limit of the key's validity. This value is
determined when a new key is generated. After Expiry Limit, server determined when a new key is generated. After Expiry Limit, server
and client (resolver) must not authenticate TSIG signed with the key. and client (resolver) must not authenticate TSIG signed with the key.
Therefore, Renewal to the next key should be carried out before Therefore, Renewal to the next key should be carried out before
Expiry Limit. Expiry Limit.
* Partial Revocation Time: Time when server judges the key is too old * Partial Revocation Time: Time when server judges the key is too old
and must be updated. It must be between Inception Time and Expiry and must be updated. It must be between Inception Time and Expiry
Limit. This value is determined by server freely following its Limit. This value is determined by server freely following its
security policy. e.g., if the time from Inception to Partial security policy. e.g., If the time from Inception to Partial
Revocation is short, renewal will be carried out more often, which Revocation is short, renewal will be carried out more often, which
might be safer. might be safer.
* Revocation Time: Time when the key becomes invalid and can be * Revocation Time: Time when the key becomes invalid and can be
removed. This value is not determined in advance because it is the removed. This value is not determined in advance because it is the
actual time when revocation is completed. actual time when revocation is completed.
* Adoption Time: Time when the new key is adopted as the next key * 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 formally. After Adoption, the key is valid and server and client can
generate or verify TSIG making use of it. Adoption Time also means generate or verify TSIG making use of it. Adoption Time also means
skipping to change at page 4, line 35 skipping to change at page 4, line 36
|- - - -|-------------------->> time |- - - -|-------------------->> time
| | new key | | new key
Inception Adoption Inception Adoption
1.2. New Format and Assigned Numbers 1.2. New Format and Assigned Numbers
TSIG TSIG
ERROR = (PartialRevoke), to be defined ERROR = (PartialRevoke), to be defined
TKEY TKEY
Mode = (DH exchange for key renewal), to be defined Mode = (server assignment for key renewal), to be defined
For detailed format, see section 2.3. Mode = (Diffie-Hellman exchange for key renewal), to be
defined
Mode = (resolver assignment for key renewal), to be defined
Mode = (key adoption), to be defined Mode = (key adoption), to be defined
For detailed format, see section 2.4.
1.3. Overview of Secret Key Renewal Mode 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,
i.e. after Partial Revocation Time, the server comes to be in Partial i.e., after Partial Revocation Time, the server comes to be in
Revocation state about the key. 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 the about A RR) other than TKEY Renewal request with TSIG signed with the
old key, the server returns an error message to notify that the time old key, the server returns an error message to notify that the time
to renew has come. This is called "PartialRevoke" error message. to renew has come. This is called "PartialRevoke" error 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 this process, Diffie-Hellman sends a TKEY Renewal request, in which several keying methods are
Exchange is used. After new secret establishment, the client sends a available. After new secret establishment, the client sends a TKEY
TKEY Adoption request. If this is admitted by the server, the new key Adoption request. If this is admitted by the server, the new key is
is formally adopted, and at the same time the corresponding old formally adopted, and at the same time the corresponding old secret
secret is invalidated. Then the client can send the first query again is invalidated. Then the client can send the first query again signed
signed with the new key. with the new key.
Key renewal procedure is executed based on two phase commit Key renewal procedure is executed based on two-phase commit
mechanism. The first phase is the TKEY Renewal request and its mechanism. The first phase is the TKEY Renewal request and its
response, which means preparatory confirmation for key update. The response, which means preparatory confirmation for key update. The
second phase is Adoption request and its response. If the server gets second phase is Adoption request and its response. If the server gets
request and client receives the response successfully, they can request and client receives the response successfully, they can
finish renewal process. If any error happens and renewal process finish renewal process. If any error happens and renewal process
fails during these phases, client should roll back to the beginning fails during these phases, client should roll back to the beginning
of the first phase, and send TKEY Renewal request again. This of the first phase, and send TKEY Renewal request again. This
rollback can be done until the Expiry Limit of the key. rollback can be done until the Expiry Limit of the 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. Key Usage Time Check 2.1. Key Usage Time Check
Whenever a server receives a query with TSIG and can find a key that Whenever a server receives a query with TSIG and can find a key that
is used for signing it, the server checks its Inception time, Partial is used for signing it, the server checks its Inception Time, Partial
Revocation time and Expiry Limit (this information is usually Revocation Time and Expiry Limit (this information is usually
memorized by the server). memorized by the server).
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]. [RFC2845].
skipping to change at page 6, line 16 skipping to change at page 6, line 18
When the present time is the same as the Expiry Time or after it, the When the present time is the same as the Expiry Time or after it, the
server MUST NOT verify TSIG with the key, and returns error messages 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]. in the same way as when no valid key is found, following [RFC2845].
2.2. Partial Revocation 2.2. Partial Revocation
In Partial Revocation state, we say the server has partially revoked In Partial Revocation state, we say the server has partially revoked
the key and the key has become a "partially revoked key". the key and the key has become a "partially revoked key".
Server which has received queries signed with the partially revoked Server which has received queries signed with the partially revoked
key MUST NOT answer them except when they are "DH exchange for key key MUST NOT answer them except when they are Renewal requests (See
renewal" requests (See section 2.3.) or "key adoption" requests (See section 2.3.) or "key adoption" requests (See section 2.4.). Instead,
section 2.4.). Instead, it returns TSIG error messages whose error it returns TSIG error messages whose error codes are "PartialRevoke"
codes are "PartialRevoke" (See section 9.) (See section 9.)
PartialRevoke error messages have the role to inform clients of the PartialRevoke error messages have the role to inform clients of the
keys' partial revocation and urge them to send TKEY Renewal requests. keys' partial revocation and urge them to send TKEY Renewal requests.
These error responses MUST be signed with those partial revoked keys 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 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 used for queries' TSIG are found to be partially revoked. If the MAC
of TSIG cannot be verified with the partially revoked keys, servers of TSIG cannot be verified with the partially revoked keys, servers
MUST NOT return PartialRevoke error with MAC, but should return MUST NOT return PartialRevoke error with MAC, but should return
another error such as "BADSIG" without MAC; in other words, a server another error such as "BADSIG" without MAC; in other words, a server
informs its key's partial revocation only when the MAC in the informs its key's partial revocation only when the MAC in the
received query is valid. received query is valid.
2.3. Renewal Request 2.3. Key Renewal Message Exchange
2.3.1. Query for DH Exchange for Key Renewal If a client has received a PartialRevoke error and authenticated the
response based on TSIG MAC, it sends a TKEY query 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. If TSIG is selected, the client can sign it with the
partial revoked key.
If a client has received a PartialRevoke Error and authenticated the Key Renewal can use one of several keying methods which is indicated
response based on TSIG MAC, it sends a TKEY query for Diffie-Hellman in "Mode" field of TKEY RR, and its message structure is dependent on
exchange for key renewal (in this document, we call it Renewal that method.
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 server which has received Key Renewal request first tries to
verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
verified with the partially revoked key, the request MUST be
authenticated.
Question section's QNAME field is the same as the NAME filed of After authentication, server must check existing old key's validity.
TKEY written below. If the partially revoked key indicated in the request TKEY's OldName
and OldAlgorithm field (See section 2.3.1.) does not really exist at
the server, "BADKEY" [RFC 2845] is given in Error field for response.
If any other error happens, server returns appropriate error messages
following the specification described in section 2.5. If there are no
errors, server returns a Key Renewal answer. This answer MUST be
signed with TSIG or SIG(0) for authentication.
In additional section, there is one KEY RR and one TKEY RR. KEY RR When this answer is successfully returned and no error is detected by
is the client's Diffie-Hellman public key [RFC2539]. TKEY RR has client, a new shared secret can be established. The details of
the structure and values described below: concrete keying procedure are given in the section 2.5.
As a result of this message exchange, client comes to know the newly
generated key's attributes such as key's name, Inception Time and
Expiry Limit. They are decided finally by the server, and are told to
the client; in particular, however, once the server has decided
Expiry Limit and returned a response, it should obey the decision as
far as it can. In other words, they SHOULD NOT change time values for
checking Expiry Limit in the future without any special reason, such
as security issue like "Emergency Compulsory Revocation" described in
section 8.
On the other hand, Partial Revocation Time of this generated key is
not decided based on the request, and not informed to the client. The
server can determine any value as long as it is between Inception
Time and Expiry Limit. However, it is recommended that the period
from Inception to Partial Revocation should be fixed as the server
side's configuration or should be set the same as the corresponding
old key's one.
Note:
Even after the response is returned to client, possibly server
sometimes receives another Renewal TKEY request whose OldName
indicates the same partial revoked key. Mostly such messages
originate in client's resending or rollback because of some kinds
of errors. In this case, the server processes keying again and
MUST replace the associated secret with the newest produced
secret. The secret key produced before comes to be invalid and
should be removed from memory; this process is called secret
overwrite. Moreover, This regenerated key's name MUST always be
different from the one which it overwrites for secret key's
uniqueness and distinction. See section 6, too.
Even if client sends Key Renewal request though the key described
in OldName has not been partially revoked yet, server must do
renewal processes. But at the moment when the server accepts such
requests with valid authentication, it MUST forcibly consider the
key is already partially revoked, that is, the key's Partial
Revocation Time must be changed into the present time (i.e., the
time when the server receives the request).
2.3.1. TKEY RR structure for Key Renewal
TKEY RR for Key Renewal message has the structure given below. In
principle, format and definition for each field follows [RFC2930].
Note that each keying scheme sometimes needs different interpretation
of RDATA field; for detail, see section 2.5.
Field Type Comment Field Type Comment
------- ------ ------- ------- ------ -------
NAME domain used for a new key, see below NAME domain used for a new key, see below
TYPE u_int16_t (defined in [RFC2930]) TYPE u_int16_t (defined in [RFC2930])
CLASS u_int16_t (defined in [RFC2930]) CLASS u_int16_t (defined in [RFC2930])
TTL u_int32_t (defined in [RFC2930]) TTL u_int32_t (defined in [RFC2930])
RDLEN u_int16_t (defined in [RFC2930]) RDLEN u_int16_t (defined in [RFC2930])
RDATA: RDATA:
Algorithm: domain algorithm for a new key Algorithm: domain algorithm for a new key
Inception: u_int32_t about the keying material Inception: u_int32_t about the keying material
Expiration: u_int32_t about the keying material Expiration: u_int32_t about the keying material
Mode: u_int16_t "DH exchange for key renewal" Mode: u_int16_t scheme for key agreement
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
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
key renewal message. It specifies the algorithm used with a newly
produced key.
"Inception" and "Expiration" are those requested for the keying "Algorithm" specifies which algorithm is used for agreed keying
material, that is, requested usage period of a new key. "Key Data" material, which is used for identification of the next key.
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.
See section 9.
In DH exchange for key renewal mode, "Other Data" field has the "Inception" and "Expiration" are used for the valid period of
structure given below. They describe attributes of the partially keying material. The meanings differ somewhat according to whether
revoked key. the message is request or answer, and its keying scheme.
"Key Data" has different meanings according to keying schemes.
"Mode" field stores the value in accordance with the keying method,
and see section 2.5. Servers and clients supporting TKEY Renewal
method MUST implement "Diffie-Hellman exchange for key renewal"
scheme. All other modes are OPTIONAL.
"Error" is an extended RCODE which includes "PartialRevoke" value
too. See section 9.
"Other Data" field has the structure given below. They describe
attributes of the key to be renewed.
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 for DH Exchange for Key Renewal "OldName" indicates the name of the previous key (usually,
this is partially revoked key's name that client noticed by
The server which has received a "DH exchange for key renewal" TKEY PartialRevoke answer from server), and "OldAlogirthm"
request, it tries to verify TSIG or SIG(0) accompanying it. If the indicates its algorithm.
verified TSIG is signed with the partially revoked key, the request
MUST be authenticated and accepted.
If the partially revoked key indicated in the request TKEY's OldName
field does not really exist at the server, or incompatible DH key is
found in the request, "BADKEY" [RFC 2845] is given in Error Field.
"FORMERR" is given if the query included no DH KEY.
If there are no errors, the server processes a response according to
Diffie-Hellman exchanged keying. Details of response messages are
below:
In answer section, there is one TKEY RR. The TKEY RR shows the
newly produced key's attributes such as a key name and algorithm.
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
RDLEN, RDATA's Inception, Expiration, Key Size and Key Data as long
as no error has occurred.
"NAME" field specifies the name of newly produced key which the
client will have to use.
"Inception" field and "Expiration" field mean the period of the
produced key usage. "Inception" should be set to be the time when
the new key is actually generated or the time before it, and it
will be regarded as Inception Time. "Expiration" is determined by
the server, and it will be regarded as Expiry Limit.
Once the server has decided Expiry Limit and returned a response,
it should obey them as long as it can. In other words, they SHOULD
NOT change time values for checking Expiry Limit in the future
without any special reason (e.g., a security issue such as
"Emergency Compulsory Revocation" described in section 8).
Note that the Partial Revocation Time about a new key is not
decided and informed based only on the client's request. The server
can decide any value as long as it is between Inception and Expiry
Limit. However, it is recommended that the period from Inception to
Partial Revocation should be fixed as the server side's
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
same keying material for the same pair of DH key, which is the same
as [RFC2930] 4.1.
If the TKEY error field is zero, The resolver supplied Diffie-
Hellman KEY RR SHOULD be echoed in the additional section and a
server Diffie-Hellman KEY RR will also be present in the answer
section like [RFC2930] 4.1.
At this moment, the server gets a new secret. However, it might
receive another "DH exchange for key renewal" TKEY request whose
OldName indicates the same partial revoked key. Mostly such messages
originate in client's resending or rollback. In this case, the server
processes Diffie-Hellman exchanged keying again and MUST replace the
stored secret with the newest produced secret. The secret key
produced before comes to be invalid and should be removed from
memory.
Even if client sends "DH exchange for key renewal" though the key
described in OldName has not been partially revoked yet, server must
do renewal processes. But at the moment when the servers accepts
such requests with valid authentication, it MUST forcibly consider
the key is already partially revoked, that is, the key's Partial
Revocation Time must be changed into the present time (i.e., the time
when the server receives the request).
2.4. Key Adoption 2.4. Key Adoption
2.4.1. Query for Key Adoption 2.4.1. Query for Key Adoption
After receiving a TKEY Renewal answer, the client gets the same After receiving a TKEY Renewal answer, the client gets the same
secret as the server. Then, it sends a TKEY Adoption request. The secret as the server. Then, it sends a TKEY Adoption request. The
request's question section's QNAME field is the same as the NAME request's question section's QNAME field is the same as the NAME
filed of TKEY written below. In additional section, there is one TKEY filed of TKEY written below. In additional section, there is one TKEY
RR. TKEY RR has the structure and values described below. RR that has the structure and values described below.
"NAME" field is the new key's name to be adopted which was already "NAME" field is the new key's name to be adopted which was already
generated by Renewal message. "Algorithm" is its algorithm. "Incep- generated by Renewal message exchange. "Algorithm" is its algorithm
tion" means the key's Inception Time, and "Expiration" means Expiry name. "Inception" means the key's Inception Time, and "Expiration"
Limit. means Expiry Limit.
"Mode" field is the value of "key adoption", which is defined "Mode" field is the value of "key adoption". See section 9.
newly. See section 9.
"Other Data" field in Adoption has the same structure as that of "Other Data" field in Adoption has the same structure as that of
"DH exchange for key renewal". "OldName" means the previous old Renewal request message. "OldName" means the previous old key, and
key, and "OldAlogirthm" means its algorithm. "OldAlogirthm" means its algorithm.
Key Adoption request MUST be signed with TSIG or SIG(0) for Key Adoption request MUST be signed with TSIG or SIG(0) for
authentication. The client can sign TSIG with the previous key. Note authentication. The client can sign TSIG with the previous key. Note
that until Adoption is finished, the new next key is treated as that until Adoption is finished, the new key is treated as invalid,
invalid, thus it cannot be used for authentication immediately. thus it cannot be used for authentication immediately.
2.4.2. Response for Key Adoption 2.4.2. Response for Key Adoption
The server which has received Adoption request, it verifies TSIG or The server which has received Adoption request, it verifies TSIG or
SIG(0) accompanying it. If the TSIG is signed with the partially SIG(0) accompanying it. If the TSIG is signed with the partially
revoked key and can be verified, the message MUST be authenticated. 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 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 really present at the server, BADNAME [RFC 2845] is given in Error
Field and the error message is returned. field and the error message is returned.
If the next key really exists and it has not been adopted formally If the next key really exists and it has not been adopted formally
yet, the server confirms the previous key's existence indicated by yet, the server confirms the previous key's existence indicated by
the "OldName" field. If it succeeds, the server executes Adoption of the "OldName" and "OldAlgorithm" field. If it succeeds, the server
the next key and Revocation of the previous key. Response message executes Adoption of the next key and Revocation of the previous key.
duplicates the request's TKEY RR with NoError, including "OldName" Response message duplicates the request's TKEY RR with NOERROR,
and "OldAlgorithm" that indicate the revoked key. including "OldName" and "OldAlgorithm" that indicate the revoked key.
If the next key exists but it is already adopted, the server returns 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 a response message regardless of the substance of the request TKEY's
"OldName". In this response, Response TKEY RR has the same data as "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 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 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 client that the previous key name was ignored, and the new key is
already available. already available.
Client sometimes has to retry Adoption request. Suppose the client Client sometimes has to retry Adoption request. Suppose the client
sent request signed with the partially revoked key, but its response sent request signed with the partially revoked key, but its response
did not return successfully (e.g., due to the drop of UDP packet). did not return successfully (e.g., due to the drop of UDP packet).
Client will probably retry Adoption request; however, the request Client will probably retry Adoption request; however, the request
will be refused in the form of TSIG "BADKEY" error because the will be refused in the form of TSIG "BADKEY" error because the
previous key was already revoked. In this case, client should previous key was already revoked. In this case, client should
retransmit Adoption request signed with the next key, and expect a retransmit Adoption request signed with the next key, and expect a
response which has null "Other Data" for confirming the completion of response which has null "Other Data" for confirming the completion of
renewal. renewal.
2.5. Considerations about Non-compliant Hosts 2.5. Keying Schemes
In Renewal message exchanges, there are no limitations as to which
keying method is actually used. The specification of keying
algorithms is independent of the general procedure of Renewal that is
described in section 2.3.
Now this document specifies three algorithms in this section, but
other future documents can make extensions defining other methods.
2.5.1. DH Exchange for Key Renewal
This scheme is defined as an extended method of [RFC2930] 4.1. This
specification only describes the difference from it and special
notice; assume that all other points, such as keying material
computation, are the exactly same as the specification of [RFC2930]
4.1.
Query
In Renewal request for type TKEY with this mode, there is one TKEY
RR and one KEY RR in the additional information section. KEY RR is
the client's Diffie-Hellman public key [RFC2539].
QNAME in question section is the same as that of "NAME" field in
TKEY RR, i.e., it means the requested new key's name.
TKEY "Mode" field stores the value of "DH exchange for key
renewal". See section 9.
TKEY "Inception" and "Expiration" are those requested for the
keying material, that is, requested usage period of a new key.
TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
Response
The server which received this request first verifies the TSIG or
SIG(0). After authentication, the old key's existence validity is
checked, following section 2.3. If any incompatible DH key is
found in the request, "BADKEY" [RFC 2845] is given in Error field
for response. "FORMERR" is given if the query included no DH KEY.
If there are no errors, the server processes a response according
to Diffie-Hellman algorithm and returns the answer. In this
answer, there is one TKEY RR in answer section and KEY RR(s) in
additional section.
As long as no error has occurred, all values of TKEY are equal to
that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
Inception, Expiration, Key Size and Key Data.
TKEY "NAME" field in the answer specifies the name of newly
produced key which the client will have to use.
TKEY "Inception" and "Expiration" mean the periods of the produced
key usage. "Inception" should be set to be the time when the new
key is actually generated or the time before it, and it will be
regarded as Inception Time. "Expiration" is determined by the
server, and it will be regarded as Expiry Limit.
TKEY "Key Data" is used as an additional nonce, following
[RFC2930] 4.1.
The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
the additional section and a server Diffie-Hellman KEY RR will
also be present in the answer section, following [RFC2930] 4.1.
2.5.2. Server Assigned Keying for Key Renewal
This scheme is defined as an extended method of [RFC2930] 4.4. This
specification only describes the difference from it and special
notice; assume that all other points, such as secret encrypting
method, are the exactly same as the specification of [RFC2930] 4.4.
Query
In Renewal request for type TKEY with this mode, there is one TKEY
RR and one KEY RR in the additional information section. KEY RR is
used in encrypting the response.
QNAME in question section is the same as that of "NAME" field in
TKEY RR, i.e., it means the requested new key's name.
TKEY "Mode" field stores the value of "server assignment for key
renewal". See section 9.
TKEY "Inception" and "Expiration" are those requested for the
keying material, that is, requested usage period of a new key.
TKEY "Key Data" is provided following the specification of
[RFC2930] 4.4.
Response
The server which received this request first verifies the TSIG or
SIG(0). Resolver KEY RR is also authenticated by means of
verifying that TSIG or SIG(0). After authentication, the old key's
existence validity is checked, following section 2.3. "FORMERR" is
given if the query specified no encryption key.
If there are no errors, the server response contains one TKEY RR
in the answer section, and echoes the KEY RR provided in the query
in the additional information section.
TKEY "NAME" field in the answer specifies the name of newly
produced key which the client will have to use.
TKEY "Inception" and "Expiration" mean the periods of the produced
key usage. "Inception" should be set to be the time when the new
key is actually generated or the time before it, and it will be
regarded as Inception Time. "Expiration" is determined by the
server, and it will be regarded as Expiry Limit.
TKEY "Key Data" is the assigned keying data encrypted under the
public key in the resolver provided KEY RR, which is the same as
[RFC2930] 4.4.
2.5.3. Resolver Assigned Keying for Key Renewal
This scheme is defined as an extended method of [RFC2930] 4.5. This
specification only describes the difference from it and special
notice; assume that all other points, such as secret encrypting
method, are the exactly same as the specification of [RFC2930] 4.5.
Query
In Renewal request for type TKEY with this mode, there is one TKEY
RR and one KEY RR in the additional information section. TKEY RR
has the encrypted keying material and KEY RR is the server public
key used to encrypt the data.
QNAME in question section is the same as that of "NAME" field in
TKEY RR, i.e., it means the requested new key's name.
TKEY "Mode" field stores the value of "resolver assignment for key
renewal". See section 9.
TKEY "Inception" and "Expiration" are those requested for the
keying material, that is, requested usage period of a new key.
TKEY "Key Data" is the encrypted keying material.
Response
The server which received this request first verifies the TSIG or
SIG(0). After authentication, the old key's existence validity is
checked, following section 2.3. "FORMERR" is given if the server
does not have the corresponding private key for the KEY RR that
was shown in the request.
If there are no errors, the server returns response. The response
must have a TKEY RR in the answer section to tell the shared key's
name and its usage time values.
TKEY "NAME" field in the answer specifies the name of newly
produced key which the client will have to use.
TKEY "Inception" and "Expiration" mean the periods of the produced
key usage. "Inception" should be set to be the time when the new
key is actually generated or the time before it, and it will be
regarded as Inception Time. "Expiration" is determined by the
server, and it will be regarded as Expiry Limit.
2.6. Considerations about Non-compliant Hosts
Key Renewal requests and responses must be exchanged between 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 server does not 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 client's query. clients, but inform it as responses invoked by client's query.
Server needs not care whether the "PartialRevoke" errors has reached Server needs not care whether the "PartialRevoke" errors has reached
client or not. If client has not received yet because of any reasons client or not. If client has not received yet because of any reasons
such as packet drops, it will resend the queries, and finally will be such as packet drops, it will resend the queries, and finally will be
able to get "PartialRevoke" information. able to get "PartialRevoke" information.
3. Secret Storage 3. Secret Storage
Every server should keep all secrets and attached information, e.g. Every server should keep all secrets and attached information, e.g.,
Inception, Expiry Limit etc. safe to be able to recover from Inception Time, Expiry Limit, etc. safely to be able to recover from
unexpected stop. To accomplish this, formally adopted keys should be unexpected stop. To accomplish this, formally adopted keys should be
memorized not only on memory, but also be stored in the form of some memorized not only on memory, but also be stored in the form of some
files. Make sure that this should be protected strongly not to be files. Make sure that this should be protected strongly not to be
read by others. If possible, they should be stored in encrypted form. read by others. If possible, they should be stored in encrypted form.
4. Compulsory Key Revocation by Server 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 do not 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 Expiry Limit. After Expiry Limit, the keys will be expired time of Expiry Limit. After Expiry Limit, the keys will be expired
and completely removed, so this is called Compulsory Key Revocation and completely removed, so this is called Compulsory Key Revocation
by server. by server.
If Expiry Limit is too distant from the Partial Revocation Time, then If Expiry Limit is too distant from the Partial Revocation Time, then
even though very long time passes, clients will be able to refresh even though very long time passes, clients will be able to refresh
secrets only if they add TSIG signed with those old partially revoked secrets only if they add TSIG signed with those old partially revoked
keys into requests, which is not safe. keys into requests, which is not safe.
skipping to change at page 12, line 9 skipping to change at page 15, line 21
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 easier to use considering calculation efficiency.
If any troubles should happen such as client host's long suspension If any troubles should happen such as client host's long suspension
against expectation, the server will do compulsory revocation. against expectation, the server will do Compulsory Revocation.
After recovery if the client sends a key Renewal request to refresh After recovery if the client sends a key Renewal request to refresh
the old key, it will fail because the key is removed from the the old key, it will fail because the key is removed from the
server. So, the client will send "Query for Diffie-Hellman server. So, the client will send "Query for Diffie-Hellman
Exchanged Keying" with SIG(0) to make a new shared key again. Exchanged Keying" with SIG(0) to make a new shared 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 Server which can act as full resolvers as well. If one server (called Server
A) comes to want to refresh a shared key (called "Key A-B"), it will A) comes to want to refresh a shared key (called "Key A-B"), it will
await a TKEY Renewal request from the other server (called Server B). await a TKEY Renewal request from the other server (called Server B).
But perhaps Server A will have to send queries with TSIG immediately But perhaps Server A will have to send queries with TSIG immediately
to Server B to resolve some queries if it is asked by other clients. to Server B to resolve some queries if it is asked by other clients.
At this time, Server A is allowed to send a Renewal request to Server At this time, Server A is allowed to send a Renewal request to Server
B, if Server A finds the key to use now is too old and should be B, if Server A finds the key to use now is too old and should be
renewed. To provide this function, both servers should 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.
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. If it can notice the Partial Revocation Time and decide key renewal. If
Server B has information about Partial Revocation Time as well, it Server B has information about Partial Revocation Time as well, it
can also decide for itself to send "DH exchange for key renewal" to can also decide for itself to send Renewal request to Server A. But
Server A. But it is not essential for both two servers have it is not essential for both two servers have information about key
information about key renewal timing. 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 Key Renewal must know their key
must know their key renewal information such as Partial Revocation renewal information such as Partial Revocation Time. It is okay that
Time. It is okay that both hosts have it. 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 Renewal requests are usually invoked when not happen so often because Renewal requests are usually invoked when
hosts want to send queries, but it is possible. hosts want to send queries, but it is possible.
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 Renewal requests. server's Renewal requests.
skipping to change at page 13, line 31 skipping to change at page 16, line 41
6. Key Name Considerations 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 do not need to be specified strictly. But and old ones, keys' names do not need to be specified strictly. But
it is recommended that some serial number or key generation time it is recommended that some serial number or key generation time
should be added to the name and that the names of keys between the should be added to the name and that the names of keys between the
same pair of hosts should have some common labels among their keys. same pair of hosts should have some common labels among their keys.
For example, suppose A.example.com. and B.example.com. share the key For example, suppose A.example.com. and B.example.com. share the key
"<serial number>.A.example.com.B.example.com." such as "<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.". After key renewal, they change
their secret and name into "10011.A.example.com.B.example.com." their secret and name into "10011.A.example.com.B.example.com." If
secret overwrite occurs as a result of client's retransmission,
server must change the next key's name somehow; for example, server
increases serial number forcibly, or add some random numbers to the
name.
Servers and clients must be able to use keys properly according to Servers and clients must be able to use keys properly according to
servers to query. Because TSIG secret keys themselves do not have any servers to query. Because TSIG secret keys themselves do not have any
particular IDs to be distinguished and would be identified by their particular IDs to be distinguished and would be identified by their
names and algorithm, it must be understood correctly what keys are names and algorithm, it must be understood correctly what keys are
refreshed. refreshed.
7. Example Usage of 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,
skipping to change at page 14, line 11 skipping to change at page 17, line 21
(1) The time values about key (1) The time values about key
"00.client.example.com.server.example.com" was set as follows: "00.client.example.com.server.example.com" was set as follows:
Inception Time is at 6:00, Expiry Limit 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. Partial Revocation Time is at 8:00.
(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.server.example.com" to ask signed with key "00.client.example.com.server.example.com" to ask
the IP address of "www.somedomain.com", finally it will get a the IP address of "www.somedomain.com", finally it will get a
proper answer from Server with valid TSIG (No Error). proper answer from Server with valid TSIG (NOERROR).
(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.server.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 will not get a proper answer from "www.otherdomain.com". But it will not get a proper answer from
Server. The response does not 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.server.example.com", and its Error Code with "00.client.example.com.server.example.com", and its Error Code
indicates PartialRevoke. indicates PartialRevoke.
(5) At 9:01. Client sends a Renewal request to Server. This request (5) At 9:01. Client sends a Renewal request to Server. This request
skipping to change at page 16, line 18 skipping to change at page 19, line 27
8. Security Considerations 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. TKEY Secret Key Renewal provides the method of
method of periodical key refreshment. periodical key refreshment.
TKEY Secret Key Renewal Mode forbids clients to send queries as long TKEY Secret Key Renewal forbids clients to send queries as long as
as they do not change old keys. This means that when keys become old, 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". For example, suppose the original Expiry Compulsory Revocation". For example, suppose the original Expiry
Limit was set at 15:00, Partial Revocation Time at 12:00 and Limit was set at 15:00, Partial Revocation Time at 12:00 and
Inception Time at 10:00. if at 11:00 the key is found to be Inception Time at 10:00. if at 11:00 the key is found to be
compromised, the server sets Expiry Limit forcibly to be 11:00 or compromised, the server sets Expiry Limit forcibly to be 11:00 or
before it. before it.
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 done out, normal renewal process described in this document cannot be done
any more as far as the key is concerned. But, after such accidents any more as far as the key is concerned. But, after such accidents
happened, the two hosts are able to establish secret keys and begin happened, the two hosts are able to establish secret keys and begin
renewal procedure only if they have other (non-compromised) shared renewal procedure only if they have other (non-compromised) shared
TSIG keys or safe SIG(0) keys for the authentication of initial TSIG keys or safe SIG(0) keys for the authentication of initial
secret establishment using Diffie-Hellman Exchanged Keying. secret establishment such as Diffie-Hellman Exchanged Keying.
9. IANA Considerations 9. IANA Considerations
IANA needs to allocate a value for "DH exchange for key renewal" and IANA needs to allocate a value for "DH exchange for key renewal",
"key adoption" in the mode filed of TKEY. It also needs to allocate a "server assignment for key renewal", "resolver assignment for key
value for "PartialRevoke" from the extended RCODE space. renewal" and "key adoption" in the mode filed of TKEY. It also needs
to allocate a 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 9 skipping to change at page 21, line 9
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
NTT Communications Corporation NTT Communications Corporation
Innovative IP Architecture Center,
Tokyo Opera City Tower 21F, Tokyo Opera City Tower 21F,
20-2, 3-chome, Nishi-Shinjuku, Shinjuku-ku, 20-2, 3-chome, Nishi-Shinjuku, Shinjuku-ku,
Tokyo, 163-1421, Japan. Tokyo, 163-1421, Japan.
EMail: y.kamite@ntt.com EMail: y.kamite@ntt.com
Masaya Nakayama Masaya Nakayama
The University of Tokyo The University of Tokyo
Information Technology Center, Information Technology Center,
2-11-16 Yayoi, Bunkyo-ku, 2-11-16 Yayoi, Bunkyo-ku,
Tokyo, 113-8658, Japan. Tokyo, 113-8658, Japan.
 End of changes. 

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