draft-ietf-dnsext-tkey-renewal-mode-03.txt   draft-ietf-dnsext-tkey-renewal-mode-04.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-03.txt> Masaya Nakayama <draft-ietf-dnsext-tkey-renewal-mode-04.txt> Masaya Nakayama
Expires: Sep. 3, 2003 The University of Tokyo Expires: Aug. 2004 The University of Tokyo
Mar. 3, 2003 Feb. 2004
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 33
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
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 and proposes an atomic
atomic method for changing secret keys used for TSIG [RFC2845] method for changing secret keys used for TSIG periodically.
periodically. Originally, TKEY provides methods of setting up shared Originally, TKEY provides methods of setting up shared secrets other
secrets other than manual exchange, but it cannot control timing of than manual exchange, but it cannot control timing of key renewal
key renewal very well though it can add or delete shared keys very well though it can add or delete shared keys separately. This
separately. This proposal is a systematical key renewal procedure proposal is a systematical key renewal procedure intended for
intended for preventing signing DNS messages with old and non-safe preventing signing DNS messages with old and non-safe keys
keys permanently. permanently.
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 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 6 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 7
2.3.1 TKEY RR structure for Key Renewal . . . . . . . . . . . . 8 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . . . 7
2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . . 7
2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 9 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . . . 8
2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . . . 8
2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 10
2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10
2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11
2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12
2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13
2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14 2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14
3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 14 3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Compulsory Key Revocation by Server . . . . . . . . . . . . . . . 15 4 Compulsory Key Revocation . . . . . . . . . . . . . . . . . . . . 15
4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . . . 15
4.2 Authentication Methods Considerations . . . . . . . . . . . . 15
5 Special Considerations for Two Servers' Case . . . . . . . . . . 16 5 Special Considerations for Two Servers' Case . . . . . . . . . . 16
5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16
6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17 6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17
7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17 7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17
8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 19 8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 20
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 21
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22
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 availability. 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
skipping to change at page 4, line 33 skipping to change at page 4, line 33
|----------------|- - - - - - >>|- (revoked) -| |----------------|- - - - - - >>|- (revoked) -|
| | | | | | | |
previous key | | | previous key | | |
|- - - -|-------------------->> 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), TBD
TKEY TKEY
Mode = (server assignment for key renewal), to be defined Mode = (server assignment for key renewal), TBD
Mode = (Diffie-Hellman exchange for key renewal), to be Mode = (Diffie-Hellman exchange for key renewal), TBD
defined Mode = (resolver assignment for key renewal), TBD
Mode = (resolver assignment for key renewal), to be defined Mode = (key adoption), TBD
Mode = (key adoption), to be defined
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 i.e., after Partial Revocation Time, the server comes to be in
Partial Revocation state about the key, and this key is called Partial Revocation state about the key, and this key is called
partially revoked. partially revoked.
In this state, whenever a client sends a normal query (e.g., question In this state, if a client sends a normal query (e.g., question about
about A RR) other than TKEY Renewal request with TSIG signed with the A RR) other than TKEY Renewal request with TSIG signed with the old
old key, the server returns an error message to notify that the time key, the server returns an error message to notify that the time to
to renew has come. This is called "PartialRevoke" error message. renew has come. This is called "PartialRevoke" error message. It is
server's choice whether it returns PartialRevoke or not. If and only
if the server is ready for changing its own key, it decides to return
PartialRevoke.
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 which several keying methods are sends a TKEY Renewal request, in which several keying methods are
available. It can make use of TSIG authentication signed with the available. It can make use of TSIG authentication signed with the
partially revoked key mentioned above. partially revoked key mentioned above.
After new secret establishment, the client sends a TKEY Adoption After new secret establishment, the client sends a TKEY Adoption
request for renewal confirmation. This can also be authenticated with request for renewal confirmation. This can also be authenticated with
the partially revoked key. If this is admitted by the server, the new the partially revoked key. If this is admitted by the server, the new
skipping to change at page 5, line 47 skipping to change at page 5, line 49
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 the
valid key is found, following [RFC2845]. key used by the client is not recognized. It follows [RFC2845] 4.5.1.
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. It follows [RFC2845]
[RFC2845]. 4.5.2 and 4.5.3.
When the present time is the same as the Partial Revocation Time, or When the present time is the same as the Partial Revocation Time, or
between the Partial Revocation Time and Expiry Limit, the server between the Partial Revocation Time and Expiry Limit, the server
comes to be in Partial Revocation state about the TSIG key and comes to be in Partial Revocation state about the TSIG key and
behaves according to the next section. behaves according to the next section.
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 the key used by the client is not recognized.
It follows [RFC2845] 4.5.1.
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".
If server has received a query signed with the partially revoked key If server has received a query signed with the partially revoked key
for TKEY Renewal request (See section 2.3.) or "key adoption" request for TKEY Renewal request (See section 2.3.) or Key Adoption request
(See section 2.4.), then server does proper process following each (See section 2.4.), then server does proper process following each
specification. specification. If it is for TKEY key deletion request ([RFC2930]
4.2), server MAY process usual deletion operation defined therein.
If server receives other types of query signed with the partially If server receives other types of query signed with the partially
revoked key and the corresponding MAC is verified, then server SHOULD revoked key, and both the corresponding MAC and signed TIME are
return TSIG error message for response whose error code is verified, then server begins returning answer whose TSIG error code
"PartialRevoke" (See section 9.). However, if it is for TKEY key is "PartialRevoke" (See section 9.). Server MUST randomly but with
deletion request ([RFC2930] 4.2), server MAY process usual deletion increasing frequency return PartialRevoke when in the Partial
operation defined therein. Revocation state.
Server can decide when it actually sends PartialRevoke, checking if
it is appropriate time for renewal. Server MUST NOT return
PartialRevoke if this is apart long lived TSIG transaction (such as
AXFR) that started before the Partial Revocation Time.
If the client receives PartialRevoke and understands it, then it MUST
retry the query with the old key unless a new key has been adopted.
Client SHOULD start the process to renew the TSIG key. For key
renewal procedure, see details in Section 2.3 and 2.4.
PartialRevoke period (i.e., time while server returns PartialRevoke
randomely) SHOULD be small, say 2-5% of key lifetime. This is
server's choice.
Server MUST keep track of clients ignoring PartialRevoke, thus
indicating ignorance of this TKEY mode.
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
used for queries' TSIG are found to be partially revoked. If the MAC signing keys are found to be partially revoked. If the MAC of TSIG
of TSIG cannot be verified with the partially revoked keys, servers cannot be verified with the partially revoked keys, servers MUST NOT
MUST NOT return PartialRevoke error with MAC, but should return return PartialRevoke error with MAC, but MUST return another error
another error such as "BADSIG" without MAC; in other words, a server such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
informs its key's partial revocation only when the MAC in the words, a server informs its key's partial revocation only when the
received query is valid. MAC in the received query is valid.
2.3. Key Renewal Message Exchange 2.3. Key Renewal Message Exchange
2.3.1. Query for Key Renewal
If a client has received a PartialRevoke error and authenticated the 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 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 this document, we call it Renewal request, too.) to the server. The
request MUST be signed with TSIG or SIG(0) [RFC2931] for request MUST be signed with TSIG or SIG(0) [RFC2931] for
authentication. If TSIG is selected, the client can sign it with the authentication. If TSIG is selected, the client can sign it with the
partial revoked key. partial revoked key.
Key Renewal can use one of several keying methods which is indicated Key Renewal can use one of several keying methods which is indicated
in "Mode" field of TKEY RR, and its message structure is dependent on in "Mode" field of TKEY RR, and its message structure is dependent on
that method. that method.
2.3.2. Response for Key Renewal
The server which has received Key Renewal request first tries to The server which has received Key Renewal request first tries to
verify TSIG or SIG(0) accompanying it. If the TSIG is signed and verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
verified with the partially revoked key, the request MUST be verified with the partially revoked key, the request MUST be
authenticated. authenticated.
After authentication, server must check existing old key's validity. After authentication, server must check existing old key's validity.
If the partially revoked key indicated in the request TKEY's OldName 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 and OldAlgorithm field (See section 2.3.4.) does not exist at the
the server, "BADKEY" [RFC2845] is given in Error field for response. server, "BADKEY" [RFC2845] is given in Error field for response. If
If any other error happens, server returns appropriate error messages any other error happens, server returns appropriate error messages
following the specification described in section 2.5. If there are no following the specification described in section 2.5. If there are no
errors, server returns a Key Renewal answer. This answer MUST be errors, server returns a Key Renewal answer. This answer MUST be
signed with TSIG or SIG(0) for authentication. signed with TSIG or SIG(0) for authentication.
When this answer is successfully returned and no error is detected by When this answer is successfully returned and no error is detected by
client, a new shared secret can be established. The details of client, a new shared secret can be established. The details of
concrete keying procedure are given in the section 2.5. concrete keying procedure are given in the section 2.5.
Note:
Sometimes Adoption message and new Renewal request will cross on
the wire. In this case the newly generated key Adoption message is
resent.
2.3.3. Attributes of Generated Key
As a result of this message exchange, client comes to know the newly 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 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 Expiry Limit. They are decided by the server and told to the client;
the client; in particular, however, once the server has decided in particular, however, once the server has decided Expiry Limit and
Expiry Limit and returned a response, it should obey the decision as returned a response, it should obey the decision as far as it can. In
far as it can. In other words, they SHOULD NOT change time values for other words, they SHOULD NOT change time values for checking Expiry
checking Expiry Limit in the future without any special reason, such Limit in the future without any special reason, such as security
as security issue like "Emergency Compulsory Revocation" described in issue like "Emergency Compulsory Revocation" described in section 8.
section 8.
On the other hand, Partial Revocation Time of this generated key is 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 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 server can determine any value as long as it is between Inception
Time and Expiry Limit. However, it is recommended that the period Time and Expiry Limit. However, the period from Inception to Partial
from Inception to Partial Revocation should be fixed as the server Revocation SHOULD be fixed as the server side's configuration or be
side's configuration or should be set the same as the corresponding set the same as the corresponding old key's one.
old key's one.
Note: 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 Even if client sends Key Renewal request though the key described
in OldName has not been partially revoked yet, server must do in OldName has not been partially revoked yet, server does renewal
renewal processes. But at the moment when the server accepts such processes. At the moment when the server accepts such requests
requests with valid authentication, it MUST forcibly consider the with valid authentication, it MUST forcibly consider the key is
key is already partially revoked, that is, the key's Partial already partially revoked, that is, the key's Partial Revocation
Revocation Time must be changed into the present time (i.e., the Time must be changed into the present time (i.e., the time when
time when the server receives the request). the server receives the request).
2.3.1. TKEY RR structure for Key Renewal 2.3.4. TKEY RR structure
TKEY RR for Key Renewal message has the structure given below. In TKEY RR for Key Renewal message has the structure given below. In
principle, format and definition for each field follows [RFC2930]. principle, format and definition for each field follows [RFC2930].
Note that each keying scheme sometimes needs different interpretation Note that each keying scheme sometimes needs different interpretation
of RDATA field; for detail, see section 2.5. 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])
skipping to change at page 10, line 6 skipping to change at page 10, line 20
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 that 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 exchange. "Algorithm" is its algo- generated by Renewal message exchange. "Algorithm" is its
rithm. "Inception" means the key's Inception Time, and "Expiration" algorithm. "Inception" means the key's Inception Time, and
means Expiry Limit. "Expiration" means Expiry Limit.
"Mode" field is the value of "key adoption". See section 9. "Mode" field is the value of "key adoption". 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
Renewal request message. "OldName" means the previous old key, and Renewal request message. "OldName" means the previous old 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 key is treated as invalid, that until Adoption is finished, the new key is treated as 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 [RFC2845] is given in Error present at the server, BADNAME [RFC2845] is given in Error field and
field and the error message is returned. the error message is returned.
If the next key really exists and it has not been adopted formally If the next key exists but it has not been adopted formally yet, the
yet, the server confirms the previous key's existence indicated by server confirms the previous key's existence indicated by the
the "OldName" and "OldAlgorithm" field. If it succeeds, the server "OldName" and "OldAlgorithm" field. If it succeeds, the server
executes Adoption of the next key and Revocation of the previous key. executes Adoption of the next key and Revocation of the previous key.
Response message duplicates the request's TKEY RR with NOERROR, Response message duplicates the request's TKEY RR with NOERROR,
including "OldName" 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 will
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. Keying Schemes 2.5. Keying Schemes
In Renewal message exchanges, there are no limitations as to which In Renewal message exchanges, there are no limitations as to which
keying method is actually used. The specification of keying keying method is actually used. The specification of keying
algorithms is independent of the general procedure of Renewal that is algorithms is independent of the general procedure of Renewal that is
described in section 2.3. described in section 2.3.
skipping to change at page 11, line 43 skipping to change at page 12, line 14
TKEY "Mode" field stores the value of "DH exchange for key TKEY "Mode" field stores the value of "DH exchange for key
renewal". See section 9. renewal". See section 9.
TKEY "Inception" and "Expiration" are those requested for the TKEY "Inception" and "Expiration" are those requested for the
keying material, that is, requested usage period of a new key. keying material, that is, requested usage period of a new key.
TKEY "Key Data" is used as a random, following [RFC2930] 4.1. TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
Response Response
The server which received this request first verifies the TSIG or The server which received this request first verifies the TSIG,
SIG(0). After authentication, the old key's existence validity is SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
checked, following section 2.3. If any incompatible DH key is old key's existence validity is checked, following section 2.3. If
found in the request, "BADKEY" [RFC2845] is given in Error field any incompatible DH key is found in the request, "BADKEY"
for response. "FORMERR" is given if the query included no DH KEY. [RFC2845] 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 If there are no errors, the server processes a response according
to Diffie-Hellman algorithm and returns the answer. In this to Diffie-Hellman algorithm and returns the answer. In this
answer, there is one TKEY RR in answer section and KEY RR(s) in answer, there is one TKEY RR in answer section and KEY RR(s) in
additional section. additional section.
As long as no error has occurred, all values of TKEY are equal to 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 that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
Inception, Expiration, Key Size and Key Data. Inception, Expiration, Key Size and Key Data.
TKEY "NAME" field in the answer specifies the name of newly TKEY "NAME" field in the answer specifies the name of newly
produced key which the client will have to use. produced key which the client MUST use.
TKEY "Inception" and "Expiration" mean the periods of the produced TKEY "Inception" and "Expiration" mean the periods of the produced
key usage. "Inception" should be set to be the time when the new key usage. "Inception" is set to be the time when the new key is
key is actually generated or the time before it, and it will be actually generated or the time before it, and it will be regarded
regarded as Inception Time. "Expiration" is determined by the as Inception Time. "Expiration" is determined by the server, and
server, and it will be regarded as Expiry Limit. it will be regarded as Expiry Limit.
TKEY "Key Data" is used as an additional nonce, following TKEY "Key Data" is used as an additional nonce, following
[RFC2930] 4.1. [RFC2930] 4.1.
The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
the additional section and a server Diffie-Hellman KEY RR will the additional section and a server Diffie-Hellman KEY RR will
also be present in the answer section, following [RFC2930] 4.1. also be present in the answer section, following [RFC2930] 4.1.
2.5.2. Server Assigned Keying for Key Renewal 2.5.2. Server Assigned Keying for Key Renewal
skipping to change at page 13, line 6 skipping to change at page 13, line 23
TKEY "Mode" field stores the value of "server assignment for key TKEY "Mode" field stores the value of "server assignment for key
renewal". See section 9. renewal". See section 9.
TKEY "Inception" and "Expiration" are those requested for the TKEY "Inception" and "Expiration" are those requested for the
keying material, that is, requested usage period of a new key. keying material, that is, requested usage period of a new key.
TKEY "Key Data" is provided following the specification of TKEY "Key Data" is provided following the specification of
[RFC2930] 4.4. [RFC2930] 4.4.
Response Response
The server which received this request first verifies the TSIG or The server which received this request first verifies the TSIG,
SIG(0). Resolver KEY RR is also authenticated by means of SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
verifying that TSIG or SIG(0). After authentication, the old key's old key's existence validity is checked, following section 2.3.
existence validity is checked, following section 2.3. "FORMERR" is "FORMERR" is given if the query specified no encryption key.
given if the query specified no encryption key.
If there are no errors, the server response contains one TKEY RR 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 answer section, and echoes the KEY RR provided in the query
in the additional information section. in the additional information section.
TKEY "NAME" field in the answer specifies the name of newly TKEY "NAME" field in the answer specifies the name of newly
produced key which the client will have to use. produced key which the client MUST use.
TKEY "Inception" and "Expiration" mean the periods of the produced TKEY "Inception" and "Expiration" mean the periods of the produced
key usage. "Inception" should be set to be the time when the new key usage. "Inception" is set to be the time when the new key is
key is actually generated or the time before it, and it will be actually generated or the time before it, and it will be regarded
regarded as Inception Time. "Expiration" is determined by the as Inception Time. "Expiration" is determined by the server, and
server, and it will be regarded as Expiry Limit. it will be regarded as Expiry Limit.
TKEY "Key Data" is the assigned keying data encrypted under the TKEY "Key Data" is the assigned keying data encrypted under the
public key in the resolver provided KEY RR, which is the same as public key in the resolver provided KEY RR, which is the same as
[RFC2930] 4.4. [RFC2930] 4.4.
2.5.3. Resolver Assigned Keying for Key Renewal 2.5.3. Resolver Assigned Keying for Key Renewal
This scheme is defined as an extended method of [RFC2930] 4.5. This This scheme is defined as an extended method of [RFC2930] 4.5. This
specification only describes the difference from it and special specification only describes the difference from it and special
notice; assume that all other points, such as secret encrypting notice; assume that all other points, such as secret encrypting
skipping to change at page 14, line 6 skipping to change at page 14, line 23
TKEY "Mode" field stores the value of "resolver assignment for key TKEY "Mode" field stores the value of "resolver assignment for key
renewal". See section 9. renewal". See section 9.
TKEY "Inception" and "Expiration" are those requested for the TKEY "Inception" and "Expiration" are those requested for the
keying material, that is, requested usage period of a new key. keying material, that is, requested usage period of a new key.
TKEY "Key Data" is the encrypted keying material. TKEY "Key Data" is the encrypted keying material.
Response Response
The server which received this request first verifies the TSIG or The server which received this request first verifies the TSIG,
SIG(0). After authentication, the old key's existence validity is SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
checked, following section 2.3. "FORMERR" is given if the server old key's existence validity is checked, following section 2.3.
does not have the corresponding private key for the KEY RR that "FORMERR" is given if the server does not have the corresponding
was shown in the request. private key for the KEY RR that was shown sin the request.
If there are no errors, the server returns response. The response If there are no errors, the server returns a response. The
must have a TKEY RR in the answer section to tell the shared key's response contains a TKEY RR in the answer section to tell the
name and its usage time values. shared key's name and its usage time values.
TKEY "NAME" field in the answer specifies the name of newly TKEY "NAME" field in the answer specifies the name of newly
produced key which the client will have to use. produced key which the client MUST use.
TKEY "Inception" and "Expiration" mean the periods of the produced TKEY "Inception" and "Expiration" mean the periods of the produced
key usage. "Inception" should be set to be the time when the new key usage. "Inception" is set to be the time when the new key is
key is actually generated or the time before it, and it will be actually generated or the time before it, and it will be regarded
regarded as Inception Time. "Expiration" is determined by the as Inception Time. "Expiration" is determined by the server, and
server, and it will be regarded as Expiry Limit. it will be regarded as Expiry Limit.
2.6. Considerations about Non-compliant Hosts 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 keeps all secrets and attached information, e.g.,
Inception Time, Expiry Limit, etc. safely 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. It will become more secure if they are stored in ecrypted
read by others. If possible, they should be stored in encrypted form. form.
4. Compulsory Key Revocation by Server 4. Compulsory Key Revocation
4.1. 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
skipping to change at page 15, line 27 skipping to change at page 15, line 41
keys into requests, which is not safe. keys into requests, which is not safe.
On the other hand, if Expiry Limit is too close to Partial Revocation On the other hand, if Expiry Limit is too close to Partial Revocation
Time, perhaps clients might not be able to notice their keys' Partial Time, perhaps clients might not be able to notice their keys' Partial
Revocation by getting "PartialRevoke" errors. Revocation by getting "PartialRevoke" errors.
Therefore, servers should set proper Expiry Limit 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 4.2. Authentication Methods Considerations
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 [RFC2930] 4.1. Once they get Exchanged Keying" as described in [RFC2930] 4.1. Once they get
shared secret, they keep using TSIG for usual queries and shared secret, they keep using TSIG for queries and responses.
responses. After a while the server returns a "ParitalRevoke" error After a while the server returns a "ParitalRevoke" error and they
and they begin a key renewal process. Both TSIG signed with begin a key renewal process. Both TSIG signed with partially
partially revoked keys and SIG(0) are okay for authentication, but revoked keys and SIG(0) are okay for authentication, but TSIG would
TSIG would be easier to use considering calculation efficiency. be easier to use considering calculation efficiency.
If any troubles should happen such as client host's long suspension Suppose now client is halted for long time with some reason.
against expectation, the server will do Compulsory Revocation. Because server does not execute any renewal process, it will
After recovery if the client sends a key Renewal request to refresh finally do Compulsory Revocation. Even if client restarts and sends
the old key, it will fail because the key is removed from the a key Renewal request, it will fail because old key is already
server. So, the client will send "Query for Diffie-Hellman deleted at server.
Exchanged Keying" with SIG(0) to make a new shared key again.
At this moment, however, if client also uses SIG(0) as another
authentication method, it can make a new shared key again and
recover successfully by sending "Query for Diffie-Hellman Exchanged
Keying" with SIG(0).
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 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 and using one shared key
A) comes to want to refresh a shared key (called "Key A-B"), it will only. If one server (called Server A) wants to refresh a shared key
await a TKEY Renewal request from the other server (called Server B). (called "Key A-B"), it will await a TKEY Renewal request from the
But perhaps Server A will have to send queries with TSIG immediately other server (called Server B). However, perhaps Server A wants to
to Server B to resolve some queries if it is asked by other clients. refresh the key right now.
At this time, Server A is allowed to send a Renewal request to Server In this case, 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 knows the Key A-B is too old and wants to renew it
renewed. To provide this function, both servers should be able to immediately.
receive and process key renewal request from each other if they agree
to refresh their shared secret keys.
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 Renewal request to Server A. But can also decide for itself to send Renewal request to Server A.
it is not essential for both two servers have information about key However, it is not essential for both two servers have information
renewal timing. 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 Key Renewal must know their key At least one of two hosts which use Key Renewal must know their key
renewal information such as Partial Revocation Time. It is okay that renewal information such as Partial Revocation 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 tries to send Renewal requests, it MUST
old secrets that it has partially revoked and prevent it from being protect old secrets that it has partially revoked and prevent it from
refreshed by any requests from the other server (i.e., it must lock being refreshed by any requests from the other server (i.e., it must
the old secret during the process of renewal). While the server is lock the old secret during the process of renewal). While the server
sending Renewal requests and waiting responses, it ignores the other is sending Renewal requests and waiting responses, it ignores the
server's Renewal requests. other 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
Renewal requests from others while they are waiting, their shared Renewal requests from others while they are waiting, their shared
keys may be refreshed, then they do not need to send any Renewal keys may be refreshed, then they do not need to send any Renewal
requests now for themselves. requests now for themselves.
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.
it is recommended that some serial number or key generation time However, it is recommended that some serial number or key generation
should be added to the name and that the names of keys between the time be added to the name and that the names of keys between the same
same pair of hosts should have some common labels among their keys. pair of hosts should have some common labels among their keys. For
For example, suppose A.example.com. and B.example.com. share the key 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." If their secret and name into "10011.A.example.com.B.example.com."
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 for each query.
servers to query. Because TSIG secret keys themselves do not have any Because TSIG secret keys themselves do not have any particular IDs to
particular IDs to be distinguished and would be identified by their be distinguished and would be identified by their names and
names and algorithm, it must be understood correctly what keys are 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,
server.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.server.example.com". shared secret key named "00.client.example.com.server.example.com".
(1) The time values about key (1) The time values for 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 1:00, Expiry Limit is at 21:00.
(2) At Server, a time value about renewal timing has been set too: (2) At Server, renewal time has been set: Partial Revocation Time
Partial Revocation Time is at 8:00. is at 20:00.
(3) Suppose the present time is 7:00. If Client sends a query (3) Suppose the present time is 19:55. 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.example.com", finally it will get a proper
proper answer from Server with valid TSIG (NOERROR). answer from Server with valid TSIG (NOERROR).
(4) At 9:00. Client sends a query signed with key (4) At 20:05. Client sends a query to ask the IP address of
"00.client.example.com.server.example.com" to ask the IP address of "www2.example.com". It is signed with key
"www.otherdomain.com". But it will not get a proper answer from "00.client.example.com.server.example.com". Server returns an
Server. The response does not have any IP address information about answer for the IP address. However, server has begun retuning
"www.otherdomain.com". Instead, it includes valid TSIG MAC signed PartialRevoke Error randomely. This answer includes valid TSIG MAC
with "00.client.example.com.server.example.com", and its Error Code signed with "00.client.example.com.server.example.com", and its
indicates PartialRevoke. Error Code indicates PartialRevoke. Client understands that the
current key is partially revoked.
(5) At 9:01. Client sends a Renewal request to Server. This request (5) At 20:06. Client sends a Renewal request to Server. This
is signed with key "00.client.example.com.server.example.com". It request is signed with key
includes data such as: "00.client.example.com.server.example.com". It includes data such
as:
Question Section: Question Section:
QNAME = 01.client.example.com. (Client can set this freely) QNAME = 01.client.example.com. (Client can set this freely)
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 8:55) Inception = (value meaning 20:00)
Expiration = (value which means 14:00) Expiration = (value meaning next day's 16:00)
Mode = (DH exchange for key renewal) Mode = (DH exchange for key renewal)
OldName = 00.client.example.com.server.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 also contains a KEY RR for DH 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 verifies TSIG. It (6) As soon as Server receives this request, it verifies TSIG. It
is signed with the partially revoked key is signed with the partially revoked key
"00.client.example.com.server.example.com". and Server accepts the "00.client.example.com.server.example.com". and Server accepts the
request. It creates a new key by Diffie-Hellman calculation and request. It creates a new key by Diffie-Hellman calculation and
returns 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 8:55) Inception = (value meaning 20:00)
Expiration = (value meaning 14:00) Expiration = (value meaning next day's 16:00)
Mode = (DH exchange for key renewal) Mode = (DH exchange for key renewal)
OldName = 00.client.example.com.server.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 for DH. Answer Section also contains KEY RRs for DH.
Additional Section also 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.server.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 next
11:00. day's 15: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) At 9:02. Client sends an Adoption request to Server. This (8) At 20:07. Client sends an Adoption request to Server. This
request is signed with the previous key request is signed with the previous key
"00.client.example.com.server.example.com". It includes: "00.client.example.com.server.example.com". It includes:
Question Section: Question Section:
QNAME = 01.client.example.com.server.example.com. QNAME = 01.client.example.com.server.example.com.
TYPE = TKEY TYPE = TKEY
Additional Section: Additional 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 which means 8:55) Inception = (value meaning 20:00)
Expiration = (value which means 14:00) Expiration = (value meaning next day's 16:00)
Mode = (key adoption) Mode = (key adoption)
OldName = 00.client.example.com.server.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 also contains a TSIG RR. Additional Section also contains a TSIG RR.
(9) Server verifies the query's TSIG. It is signed with the (9) Server verifies the query's TSIG. It is signed with the
previous key and authenticated. It returns a response whose TKEY RR 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 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 "00.client.example.com.server.example.com.". As soon as the
response is sent, Server revokes and removes the previous key. At response is sent, Server revokes and removes the previous key. At
the same time, key "01.client.example.com.server.example.com." is the same time, key "01.client.example.com.server.example.com." is
validated. validated.
(10) Client acknowledges the success of Adoption by receiving the (10) Client acknowledges the success of Adoption by receiving the
response. Then, it will retry to send an original question about response. Then, it retries to send an original question about
"www.otherdomain.com". It is signed with the adopted key "www2.example.com". It is signed with the adopted key
"01.client.example.com.server.example.com", so Server authenticates "01.client.example.com.server.example.com", so Server authenticates
it and returns an answer. it and returns an answer.
(11) This key is used until 11:00. After that, it will be partially (11) This key is used until next day's 15:00. After that, it will
revoked again. be partially revoked again.
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].
[RFC2104] says that current attacks to HMAC do not indicate a [RFC2104] 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. TKEY Secret Key Renewal provides the method of of an exposed key. TKEY Secret Key Renewal provides the method of
periodical key refreshment. periodical key refreshment.
TKEY Secret Key Renewal forbids clients to send queries as long as In TKEY Secret Key Renewal, clients need to send two requests
they do not change old keys. This means that when keys become old, (Renewal and Adoption) and spend time to finish their key renewal
clients must spend rather lots of time to get answers they wanted processes. Thus the usage period of secrets should be considered
originally because at first they must send key Renewal requests. Thus carefully based on both TKEY processing performance and security.
the usage period of secrets should be considered carefully based on
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 21:00, Partial Revocation Time at 20:00 and
Inception Time at 10:00. if at 11:00 the key is found to be Inception Time at 1: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. However, after such
happened, the two hosts are able to establish secret keys and begin accidents happened, the two hosts are able to establish secret keys
renewal procedure only if they have other (non-compromised) shared and begin renewal procedure only if they have other (non-compromised)
TSIG keys or safe SIG(0) keys for the authentication of initial shared TSIG keys or safe SIG(0) keys for the authentication of
secret establishment such as Diffie-Hellman Exchanged Keying. initial 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", IANA needs to allocate a value for "DH exchange for key renewal",
"server assignment for key renewal", "resolver assignment for key "server assignment for key renewal", "resolver assignment for key
renewal" and "key adoption" in the mode filed of TKEY. It also needs renewal" and "key adoption" in the mode filed of TKEY. It also needs
to allocate a value for "PartialRevoke" from the extended RCODE to allocate a value for "PartialRevoke" from the extended RCODE
space. space.
10. References 10. Acknowledgement
The authors would like to thank Olafur Gudmundsson, whose helpful
input and comments contributed greatly to this document.
11. 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.
[RFC2539] [RFC2539]
skipping to change at page 22, line 9 skipping to change at page 22, 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
Tokyo Opera City Tower 21F, 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
20-2, 3-chome, Nishi-Shinjuku, Shinjuku-ku, 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 Information Technology Center, The University of Tokyo
Information Technology Center, 2-11-16 Yayoi, Bunkyo-ku, Tokyo
2-11-16 Yayoi, Bunkyo-ku, 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/