Yuji Kamite Internet-Draft Masaya Nakayama draft-kamite-dnsext-tkey-secret-renewal-00.txt University of Tokyo Expires: January 9, 2002 9 July 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 TKEY [RFC2930] provides methods of setting up shared secret keys for TSIG [RFC2845] other than manual exchange. But TKEY itself cannot control timing of key renewal very well though it can add or delete shared keys. Since continuing to sign messages with old keys permanently is not safe, hosts which make use of TSIG should pay attention to the time limit of secret usage. This document proposes a new Secret Key Renewal Mode in TKEY which periodically changes secret shared between two hosts. Servers check valid period of secret when they receive messages from clients, and if they have already expired, the servers demand that clients should send TKEY key renewal requests which are based on Diffie-Hellman exchange. After secret establishment by exchange, new secret keys become valid and the previous old keys are completely invalidated. Kamite, et. al. [Page 1] INTERNET-DRAFT July 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 secret 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 become too old, or dangerous after long time usage. It is ideal that the number of secret which a pair of hosts share should be limitted 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 againstattackers. 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, an old secret having been used until then should be revoked immediately. To accomplish this, DNS servers must support the protocol for key renewal. This document specifies the procedure to refresh secret keys between two hosts which called "TKEY Secret Key Renewal Mode". In this mode when clients send normal queries with TSIG signed with old keys, servers return error messages to notify that the time to renew has come. To make new shared secret, Diffie-Hellman Exchange is used. clients send TKEY requests for key renewal. After new secret establishment, they retry the query using the new keys. When servers receive them and succeeds to verify TSIG signed with new secrets, the keys are formally adopted, and at the same time old secrets are invalidated. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" in this document are to be interpreted as described in [RFC 2119]. 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. Kamite, et. al. [Page 2] INTERNET-DRAFT July 2001 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. When a server receives a query with TSIG and can find a key whose name is indicated in TSIG, the server checks inception/expiration time based on the information of the server's own. If 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 the inception time and expiration 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 or after the expiration time, the server behaves according to the protocol written below. 2.2. Partial key revocation When the server detects that the present time is past the expiration time or it judges that the key should be changed in advance before expiration time comes, the server comes into "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". Servers can partially revoke keys before their expiration times, but MUST NOT do it before inception times. If the times when servers get messages with TSIG are the same as or after the keys' expiration times, servers MUST partially revoke the keys. In "partial revocation" state, servers which have received queries signed with 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". "PartialRevoke" error messages have roles to inform clients of the keys' expiration 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 SHOULD NOT return "PartialRevoke" error, but SHOULD return "BADSIG". Kamite, et. al. [Page 3] INTERNET-DRAFT July 2001 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. 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 8. 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 8. For "NAME" field, both non-root and root name are allowed. It may be used for a new key's name according to [RFC2930] 2.1. Kamite, et. al. [Page 4] INTERNET-DRAFT July 2001 "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. See section 8. 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. 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: Kamite, et. al. [Page 5] INTERNET-DRAFT July 2001 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 times 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 allowing for request messages. However, if servers judge requested usage periods are too short, they can ignore them and decide expiration times freely based on their own security policies. Once servers have decided expiration times and already returned responses, they must obey them. In other words, they MUST NOT change time values for checking revocation in the future. Therefore, before sending responses, they must memorize correctly the time values with secret key data. 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. 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, they MUST forcibly consider the keys are already partially revoked. Kamite, et. al. [Page 6] INTERNET-DRAFT July 2001 2.4. Key Adoption After Receiving 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 tha 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 and shared 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 the memory, but also be stored in the form of some files. Make shure 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 though servers have already partially revoked keys, clients don't try to send any renewal requests. Even though very long time passes, the clients will be able Kamite, et. al. [Page 7] INTERNET-DRAFT July 2001 to refresh secrets only if they add TSIG signed with those partially revoked keys into requests, which is not safe. Therefore, servers should be able to reject all TSIG authentications making use of too old keys. If servers judge that too long time has passed after partial revocation, they can restrict measures of authentication to SIG(0) or TSIG without those keys. This is called "compulsory revocation" by servers about old keys. Servers don't allow any key renewal requests signed with compulsorily revoked keys, but return "BADKEY" errors as if they were completely deleted. But servers should remember what keys were compulsorily revoked in order to check OldName fields when clients send key renewal messages with other TSIG or SIG(0) in the future. The permissible time from partial revocation to compulsory revocation depends on servers. The time of compulsory revocation should not be before the time of partial revocation. 4.1. Example It might be ideal to provide both SIG(0) and TSIG as authentication methods if "compulsory revocation" is used. 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 hosts' long suspension against expectation, servers will have to carry out compulsory revocation. After recovery the clients will try to request key renewal to refresh old keys with SIG(0) signatures. 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 asked by other clients. Kamite, et. al. [Page 8] INTERNET-DRAFT July 2001 At this time, Server A is allowed to send "DH exchange for key renewal" 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 key expiration time and decide key renewal. If Server B has information about key expiration 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 key expiration 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 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 changing secrets by means of their own requests to others. After failure they will try to resending, 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. 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 Kamite, et. al. [Page 9] INTERNET-DRAFT July 2001 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. 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. 7. 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 Kamite, et. al. [Page 10] INTERNET-DRAFT July 2001 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. 8. 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. 9. 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 11] INTERNET-DRAFT July 2001 10. Authors' Addresses Yuji Kamite Information Technology Center, 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, University of Tokyo, 2-11-16 Yayoi, Bunkyo-ku, Tokyo, 113-8658, Japan. EMail: nakayama@nc.u-tokyo.ac.jp Kamite, et. al. [Page 12]