diff --git a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-00.txt b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-00.txt new file mode 100644 index 0000000000..ee290a77c7 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-00.txt @@ -0,0 +1,1009 @@ + + + + +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] +