DNSEXT Working Group Yuji Kamite INTERNET-DRAFT Masaya Nakayama the University of Tokyo Expires: May 2, 2002 November 2, 2001 TKEY Secret Key Renewal Mode Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document defines a new mode in TKEY [RFC2930] and proposes an atomic method for changing periodically secret keys for TSIG [RFC2845]. This method is intended to prevent signing messages with old and non-safe keys permanently. A server checks the valid periods of keys whenever it receives queries, and if any key is too old, it is demanded that the client sharing it should send a secret renewal request. After secret establishment and a query with a new signature is received, the key becomes valid formally and the previous one is invalidated. Kamite, et. al. [Page 1] INTERNET-DRAFT November 2001 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 3 1.2 Comparison of Secret Key Renewal and usual Diffie-Hellman Exchanged Keying . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Shared secret key renewal . . . . . . . . . . . . . . . . . . . . 5 2.1 Detection of secret expiration . . . . . . . . . . . . . . . 5 2.2 Partial key revocation . . . . . . . . . . . . . . . . . . . 6 2.3 Query for DH exchange for key renewal . . . . . . . . . . . . 6 2.3.1 Query . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2 Response . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5 Considerations about non-compliant hosts for secret key renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 Compulsory key revocation by servers . . . . . . . . . . . . . . 10 4.1 Example of compulsory key revocation . . . . . . . . . . . . 11 5 Special considerations for two servers' case . . . . . . . . . . 11 5.1 To cope with collisions of renewal requests . . . . . . . . . 12 6 Key name consideration . . . . . . . . . . . . . . . . . . . . . 13 7 Example usage of TKEY Secret Key Renewal Mode . . . . . . . . . . 14 8 Security consideration . . . . . . . . . . . . . . . . . . . . . 16 9 IANA consideration . . . . . . . . . . . . . . . . . . . . . . . 16 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 18 Kamite, et. al. [Page 2] INTERNET-DRAFT November 2001 1. Introduction TSIG [RFC2845] provides whole DNS message integrity and the request/transaction authentication, by means of message authentication codes (MAC). Moreover, TSIG is practical in view of calculation speed and easily available. To make use of TSIG, in most cases hosts must share secret keys by manual exchange, which is a little troublesome. but if you use TKEY [RFC2930] as well, hosts can establish secrets for TSIG via networks, not by manual exchange. In various modes of TKEY, a server and a resolver can add or delete a secret key be means of TKEY message exchange. However, old TKEY doesn't care fully about the management of keys which became too old, or dangerous after long time usage. 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 purpose might not only be a burden to resolvers for managing and distinguishing according to servers to query, but also doesn't seem to be safe in terms of storage and protection against attackers. Moreover, perhaps holding old keys long time might give attackers chances to compromise by scrupulous calculation. Therefore, When a new shared secret is established by TKEY, the previous old secret used until then should be revoked immediately. To accomplish this, DNS servers must support a protocol for key renewal. This document specifies procedure to refresh secret keys between two hosts which is defined within the framework of TKEY, and it is called "TKEY Secret Key Renewal Mode". The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" in this document are to be interpreted as described in [RFC 2119]. 1.1. Overview of Secret Key Renewal Mode 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 duration it considers safe. If it is judged that the key is too old, the server comes to be in "partial revocation" state about the key. 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 old key, the server returns an error message to notify that the time to renew has come. This is called "PartialRevoke" error message. Kamite, et. al. [Page 3] INTERNET-DRAFT November 2001 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 sends a TKEY "Renewal" request. In the "Renewal" process, Diffie- Hellman Exchange is used. After new secret establishment, the client retries the original query to the server. When the server receives it and succeeds to verify TSIG signed with the new secret key, the key is formally adopted, and at the same time the corresponding old secret is invalidated. 1.2. Comparison of Secret Key Renewal and usual Diffie-Hellman Exchanged Keying If you use Diffie-Hellman Exchanged Keying [RFC2930], a new key can be generated after message exchange. Thus, if clients take heed of inception and expiration time of their keys and can send DH Exchanged Keying queries, it is possible to change secrets in regular intervals. However, this method has a few difficulties in terms of operation. First, It is impossible for clients to sense timings of sending Diffie-Hellman Exchanged Keying queries based on the previous answers returned from servers: no information about key refresh timing is written in answer messages. In addition, if clients send Keying requests too many times, servers will have to create a great many secret keys, which will waste servers' memory. For example, clients occasionally fail to get keying answers because DNS messages can be exchanged on UDP and might be sometimes dropped. Then, they will try to send requests again, and the servers will have to make other keys more. On top of that, possibly there might be malicious clients that want only to annoy servers by sending a lot of requests. "Secret Key Renewal Mode" solves these problems. Because this mode's requests are often triggered by the detection of "PartialRevoke" TSIG error answers (defined in this document), clients know key renewal timing at any time even if they haven't traced old keys' inception/expiration time or have forgotten them. Besides, memory waste can be prevented because servers always restrict clients which can establish new secrets to those who have the corresponding previous old secrets, and servers never permit that two or more new keys following one old key are created. It can be said that this "Renewal" Mode specifies concrete procedure to switch an old key to new one smoothly, not limited only in adding or deleting a key. Kamite, et. al. [Page 4] INTERNET-DRAFT November 2001 2. Shared secret key renewal Suppose a server and a client agree to change their TSIG keys periodically. Key renewal procedure is defined between two hosts. 2.1. Detection of secret expiration DNS servers permitting TSIG key renewal MUST keep and be able to recognize all secret inception and expiration time about keys. Each secret key has one inception time and one expiration time. Whenever a server receives a query with TSIG and can find a key whose name is indicated in TSIG, the server checks inception and expiration time based on the information of the server's own. At least either one of two hosts which make use of TKEY Key Renewal Mode MUST be able to own and supervise the time values about their shared keys too. The value is called "partial revocation time" which means secret renewal timing. "partial revocation time" about each key MUST be between the key's inception and expiration time. The time is usually configured by the administrator of the server. That is to say, the server can freely decide them following its security policy: if the time from inception to partial revocation time is short, key renewal will be often carried out, which might be safer. When the present time is before inception time, the server MUST NOT verify TSIG with the key, and server acts the same way as when no valid key is found, following [RFC2845]. When the present time is equal to inception time, or between inception time and partial revocation time, the behavior of the server is the same as when a valid key is found, required in [RFC2845], as long as the server is not in the process of "partial key revocation" written below. When the present time is the same as the partial revocation time, or between the partial revocation time and the expiration time, the server behaves according to the protocol written below. When the present time is the same as the expiration time or after it, the server MUST NOT verify TSIG with the key, and returns error messages in the same way as when no valid key is found, following [RFC2845]. Kamite, et. al. [Page 5] INTERNET-DRAFT November 2001 2.2. Partial key revocation When the server detects that the present time is past the partial revocation time, the server comes to be in "partial revocation" state about the TSIG key. Now we say the server has partially revoked the key and the old key has come to be a "partially revoked key". If the server judges with some reason that the key must be changed in advance before partial revocation time, it can move immediately into "partial revocation" state, but in that case the server MUST set its partial revocation time to the present time. Servers can partially revoke keys before their partial revocation time which they set before, but MUST NOT do it before inception time. In "partial revocation" state, servers which have received queries signed with the partially revoked keys MUST NOT answer them except when they are "DH exchange for key renewal" requests (see section 2.3). Instead, they return TSIG error messages whose error codes are "PartialRevoke" (See section 9). "PartialRevoke" error messages have the role to inform clients of the keys' partial revocation and urge them to send TKEY key renewal requests. These error responses MUST be signed with those partial revoked keys if the queries are signed with them. They are sent only when the keys used for queries' TSIG are found to be partially revoked. If the MAC of TSIG cannot be verified with the partially revoked keys, servers MUST NOT return "PartialRevoke" error with MAC, but should return another error such as "BADSIG" without MAC; in other words, a server informs its key's partial revocation only when the MAC in the received query was valid. 2.3. Query for DH exchange for key renewal 2.3.1. Query If a client has received a "PartialRevoke" Error and authenticated the response based on TSIG MAC, it sends a TKEY secret key renewal request to the server. The request MUST be signed with TSIG or be added SIG(0) [RFC2931] for authentication. The client can use the partial revoked key for TSIG. The request message has the structure given below. Question section's QNAME field is the same as the NAME filed of TKEY written below. Kamite, et. al. [Page 6] INTERNET-DRAFT November 2001 In additional section, there is one KEY RR and one TKEY RR. KEY RR is the client's Diffie-Hellman public key [RFC2539]. TKEY RR has the structure and values described below: Field Type Comment ------- ------ ------- NAME domain used for a new key, see below TYPE u_int16_t (defined in [RFC2930]) CLASS u_int16_t (defined in [RFC2930]) TTL u_int32_t (defined in [RFC2930]) RDLEN u_int16_t (defined in [RFC2930]) RDATA: Algorithm: domain algorithm for a new key Inception: u_int32_t about the keying material Expiration: u_int32_t about the keying material Mode: u_int16_t "DH exchange for key renewal" see section 9. Error: u_int16_t see description below Key Size: u_int16_t see description below Key Data: octet-stream Other Size: u_int16_t (defined in [RFC2930]) size of other data Other Data: newly defined: see description below Mode field of TKEY RR in the message stores the value of "DH exchange for key renewal" which is newly defined. See section 9. 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. "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. In many cases algorithm is not changed after key renewal but may be changed (e.g. from HMAC-MD5 to HMAC-SHA1). The client should allow for what algorithms are supported by the server when it wants to change. "Inception" and "Expiration" times are those requested for the keying material, that is, requested usage period of a new key. "Key Data" is used as a random. This is provided in the same way as [RFC2930] 4.1 in order to avoid always deriving the same keying material. "Error" is an extended RCODE which includes "PartialRevoke" value. Kamite, et. al. [Page 7] INTERNET-DRAFT November 2001 See section 9. In "DH exchange for key renewal" mode, "Other Data" field has the structure given below. They describe attributes of the partially revoked key. in Other Data filed: Field Type Comment ------- ------ ------- OldNAME domain name of the old key OldAlgorithm domain algorithm of the old key 2.3.2. Response The server which has received a "DH exchange for key renewal" TKEY request, it tries to verify TSIG or SIG(0) accompanying it. If the TSIG is signed with the partially revoked key and can be verified, the message MUST be authenticated. Note that in this case the server doesn't return "PartialRevoke" error but do the same process as when TSIG signed with other valid keys or SIG(0) is confirmed in requests. If the partially revoked key indicated in the request TKEY OldName doesn't 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 is no error, the server processes a response according to Diffie-Hellman exchanged keying. Response message's details 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 a 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. TKEY Inception and Expiration time mean the period of the produced key usage. Inception time MUST be set to the time when the new key is generated, thus after clients receive responses, they can use new keys immediately. Expiration time will be determined by servers Kamite, et. al. [Page 8] INTERNET-DRAFT November 2001 allowing for request messages. However, if servers judge requested usage periods are too short or too long, they can ignore them and decide expiration time freely based on their own security policies. Once servers have decided expiration time and already returned responses, they should obey them as long as they can. In other words, they SHOULD NOT change time values for checking expiration in the future without any special reason (e.g. a security issue such as "emergency compulsory revocation" described in Section 8). Therefore, before sending responses, they must memorize correctly the time values with secret key data. Note that the "partial revocation" time about a new key isn't decided base on the client's request. The server can set freely any value as long as it is between inception and expiration. However, it is recommended that the period from inception to "partial revocation" time 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 in TKEY indicates the same partial revoked key. Mostly such messages originate in client's resending. 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 clients send "DH exchange for key renewal" though the keys described in OldName have not been partially revoked yet, servers must do renewal processes. But the moment servers get key renewal requests with valid authentication, they MUST forcibly consider the keys are already partially revoked, that is, the key's "partial revocation" time must be set to be the present time (i.e. the time when the server receives the request). Kamite, et. al. [Page 9] INTERNET-DRAFT November 2001 2.4. Key Adoption After Receiving a TKEY answer, the client gets the same secret as the server. Then, it tries to resolve the original question which was wanted first (i.e. the question clients tried to ask before it got the "PartialRevoke" error). As soon as the message signed with the new key reaches the server and is verified, the new key is formally adopted and at the same time the partially revoked key expires completely. After that the server MUST NOT verify any queries with the completely revoked key. At this moment the server comes to be out of "partial revocation sate", and it is only the new adopted key that is used between the server and the host. 2.5. Considerations about non-compliant hosts for secret key renewal Key renewal requests and responses must be exchanged between hosts which can understand them and do proper processes. "PartialRevoke" error messages will be only ignored if they should be returned to non-compliant hosts. Note that servers don't inform actively the necessity of renewal to clients, but inform it as responses invoked by clients' queries. Servers don't need to care whether the "PartialRevoke" errors have reached clients or not. If clients have not received yet because of any reasons such as UDP packet drops, they will resend the queries, and finally will be able to get "PartialRevoke" information about the keys they have been using. 3. Secret Storage Every hosts should keep all secrets and attached information (e.g. inception and expiration etc.) safe to be able to recover from unexpected stop of the server. To accomplish this, formally adopted keys should be 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 read by others. If possible, they should be stored in encrypted form. 4. Compulsory key revocation by servers There is a rare but possible case that although servers have already partially revoked keys, clients don't try to send any renewal requests. If this state continues, in the future it will become the Kamite, et. al. [Page 10] INTERNET-DRAFT November 2001 time of expiration. After expiration, the keys will be completely removed, so this is called compulsory key revocation by servers. If expiration time is too distant from the partial revocation time, then even though very long time passes, clients will be able to refresh secrets only if they add TSIG signed with those old partially revoked keys into requests, which is not safe. On the other hand, if expiration time is too close to partial revocation time, perhaps clients might not be able to notice their keys' partial revocation by getting "PartialRevoke" errors. Therefore, servers should set proper expiration time to their keys, considering both their keys' safety, and enough time for clients to send requests and process renewal. 4.1. Example of compulsory key revocation It might be ideal to provide both SIG(0) and TSIG as authentication methods. For example: A client and a server start SIG(0) authentication at first, to establish TSIG shared keys by means of "Query for Diffie-Hellman Exchanged Keying" as described in [RFC 2930] 4.1. Once they get shared secret, they keep using TSIG for usual queries and responses. After a while the server returns a "ParitalRevoke" error and they begin a key renewal process. Both TSIG signed with partially revoked keys and SIG(0) are okay for authentication, but TSIG would be more easy to use considering calculation efficiency. If some troubles should happen such as client host's long suspension against expectation, the server will carry out compulsory revocation. 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 server. So, the client will send "Query for Diffie-Hellman Exchanged Keying" with SIG(0) to make a new shared key again. 5. Special considerations for two servers' case 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 A") decides to partially revoke a shared key (called "Key A- B"), it will await a TKEY renewal request from the other server (called "Server B"). But perhaps Server A will have to send queries with TSIG immediately to Server B to resolve some queries if it is Kamite, et. al. [Page 11] INTERNET-DRAFT November 2001 asked by other clients. 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 renewed. To provide this function, both servers MUST be able to receive and process key renewal request from each other if they agree to refresh their shared secret keys by "DH exchange for key renewal" procedures. Note that the initiative in key renewal belongs to Server A because it can notice the "partial revocation" time and decide key renewal. If Server B has information about "partial revocation" time as well, it can also decide for itself to send "DH exchange for key renewal" to Server A. But it is not essential for both two servers have information about key renewal timing. 5.1. To cope with collisions of renewal requests At least one of two hosts which use "DH exchange for key renewal" must know their key renewal information such as "partial revocation" times. Surely both of them can have information. Provided that both two servers know key renewal timing information, there is possibility for them to begin partial revocation and sending renewal requests to each other at the same time. Such collisions will not happen so often because key renewal requests are usually invoked when hosts want to send queries, but we should take the possibility into consideration. 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 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 sending renewal requests and waiting responses, it ignores the other server's key renewal requests. Therefore, servers might fail to change secrets by means of their own 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 key renewal requests from others while they are awaiting the delays, their shared keys may be changed, then they don't need to send any renewal requests now for themselves because the secrets are already refreshed. Kamite, et. al. [Page 12] INTERNET-DRAFT November 2001 6. Key name consideration Since both servers and clients have only to distinguish new secrets and old ones, keys' names don't need to be specified. But it is recommended that some serial number or key generation time 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. For example, suppose A.example.com. (Server A) and B.example.com. (Client B) shares the key like this: 10010.A.example.com.B.example.com. and after the process of key renewal, they change their secret and name into 10011.A.example.com.B.example.com. If Server A is configured to accept TKEY key renewal requests by Client B whose OldNAME field is such as: .A.example.com.B.example.com. and the name of newly produced keys always follow the same format too, it will be safer because Client B can renew only his secret keys but cannot change others' keys. Even if Client B should send TKEY key renewal requests whose OldNAME is like: .A.example.com.C.others.com. Server A will refuse it because the shared keys between A and B are restricted to have the name such as .A.example.com.B.example.com. and this request is considered to be beyond Client B's authority. But, a more safer method to prevent others from changing keys beyond their authorities is that a server also memorizes correctly which hosts own keys (i.e. memorizes key identities with regard to owners) and it only accepts renewal requests from hosts those identities have been confirmed by checking request's TSIG or SIG(0). Servers and clients must be able to use keys properly according to hosts to query. If new keys are generated and adopted, they must use only them because old keys have already expired. Because TSIG secret keys themselves don't have any IDs to be distinguished and would be identified by their names and algorithm, hosts must understand correctly what keys are refreshed. Kamite, et. al. [Page 13] INTERNET-DRAFT November 2001 7. Example usage of TKEY Secret Key Renewal Mode This is an example of "Renewal" mode usage where a Server, ns.example.com, and a Client, client.exmple.com have an initial shared secret key named "00.client.example.com.ns.example.com" (1) The time values about key "00.client.example.com.ns.example.com" was set as follows: inception is at 6:00, expiration is at 11:00. (2) At Server, a time value about renewal timing has been set too: partial revocation time is at 8:00. This may be unknown to Client because it was freely set by Server's administrator. (3) Suppose the present time is 7:00. If Client sends a query signed with key "00.client.example.com.ns.example.com" to ask the IP address of "www.somedomain.com", finally it will get a proper answer from Server with valid TSIG (No Error). (4) At 9:00. Client sends a query signed with key "00.client.example.com.ns.example.com" to ask the IP address of "www.otherdomain.com". But it won't get a proper answer from Server. The response doesn't have any IP address information about "www.otherdomain.com". Instead, it includes valid TSIG MAC signed with "00.client.example.com.ns.example.com", but its Error Code indicates "PartialRevoke". (5) At 9:01. Since Client has understood that its key has been considered to be old by Server, it will send a "Renewal" request to Server. This request is signed with key "00.client.example.com.ns.example.com". It includes data such as: Question Section: QNAME = 01.client.example.com. (This can be set freely by Client) TYPE = TKEY Additional Section: 01.client.example.com. TKEY Algorithm = hmac-md5-sig-alg.reg.int. Inception = (value which means 9:01) Expiration = (value which means 14:00) Mode = (DH exchange for key renewal) OldName = 00.client.example.com.ns.example.com. OldAlgorithm = hmac-md5-sig-alg.reg.int. (Additional Section contains a KEY RR and a TSIG RR) Kamite, et. al. [Page 14] INTERNET-DRAFT November 2001 (6) As soon as Server receives this request, it tries to verify TSIG. It is valid but signed with partial revoked key "00.client.example.com.ns.example.com". However, since this is a request for "Renewal", Server accepts processing the renewal. Server creates a new key by Diffie-Hellman calculation and returns an answer which includes data such as: Answer Section: 01.client.example.com.server.example.com. TKEY Algorithm = hmac-md5-sig-alg.reg.int. Inception = (value meaning 9:01) Expiration = (value meaning 14:00) Mode = (DH exchange for key renewal) OldName = 00.client.example.com.ns.example.com. OldAlgorithm = hmac-md5-sig-alg.reg.int. (Answer Section also contains KEY RRs) (Additional Section contains a TSIG RR) This response is signed with key "00.client.example.com.ns.example.com" without error. At the same time, Server decides to set the partial revocation time of this new key "01.client.example.com.server.example.com." as 11:00. (7) Client gets the response and checks TSIG MAC, and calculates Diffie-Hellman. It will get a new key, and it has been named "01.client.example.com.server.example.com" by Server. (8) Client will retry to send an original question about "www.otherdomain.com". It is signed with the created key "01.client.example.com.server.example.com". (9) Server verifies the query's TSIG. Since it succeeds, it adopts key "01.client.example.com.server.example.com" formally. Key "00.client.example.com.server.example.com." is removed from Server. Then, it returns an answer about the IP address of "www.otherdomain.com" with TSIG signed with key "01.client.example.com.server.example.com". (10) Client knows key "01.client.example.com.server.example.com." is adopted by Server. (11) This key is valid until 11:00. After that, it will be partially revoked again. Kamite, et. al. [Page 15] INTERNET-DRAFT November 2001 8. Security consideration This document considers about how to refresh shared secret. Secret changed by this method is used at servers in support of TSIG [RFC2845]. [RFC 2104] says that current attacks to HMAC do not indicate a specific recommended frequency for key changes but periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key. This TKEY secret key renewal mode provides the method of periodical key refreshment. TKEY secret key renewal mode forbids clients to send queries as long as they don't change old keys. This means that when keys become old, clients must spend rather lots of time to get answers they wanted originally because at first they must send key renewal requests. Thus 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 actually there is possibility for servers to have no choice other than revoking their secret keys immediately especially when the keys are found to be compromised by attackers. This is called "emergency compulsory revocation". In this case, the server must set the compromised key's expiration at the present time: the key must be revoked compulsorily. For example, suppose the original expiration time was set at 15:00, partial revocation time at 12:00 and inception at 10:00. if at 11:00 the key is found to be compromised, the server can forcibly set expiration time 11:00. Consequently, once "compulsory revocation" (See section 4) is carried out, normal "renewal" process described in this document cannot be done 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 "renewal" procedure only if they have other (non- compromised) shared TSIG keys or safe SIG(0) keys for the authentication of initial secret establishment using Diffie-Hellman Exchanged Keying. 9. IANA consideration IANA needs to allocate a value for "DH exchange for key renewal" in the mode filed of TKEY. It also needs to allocate a value for "PartialRevoke" from the extended RCODE space. Kamite, et. al. [Page 16] INTERNET-DRAFT November 2001 10. References [RFC2104] H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message Authentication", RFC2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2539] D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2930] D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', RFC 2930, September 2000. [RFC2931] D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s )", RFC 2931, September 2000. Kamite, et. al. [Page 17] INTERNET-DRAFT November 2001 Authors' Addresses Yuji Kamite Information Technology Center, the University of Tokyo, 2-11-16 Yayoi, Bunkyo-ku, Tokyo, 113-8658, Japan. EMail: kamite@kaynet.ecc.u-tokyo.ac.jp Masaya Nakayama Information Technology Center, the University of Tokyo, 2-11-16 Yayoi, Bunkyo-ku, Tokyo, 113-8658, Japan. EMail: nakayama@nc.u-tokyo.ac.jp Kamite, et. al. [Page 18]