+++ /dev/null
-
-
-
-
-DNSEXT Working Group Yuji Kamite
-INTERNET-DRAFT Masaya Nakayama
-<draft-ietf-dnsext-tkey-renewal-mode-00.txt> 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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:
-
- <serial number>.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:
-
- <serial number>.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 <serial
- number>.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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
--- /dev/null
+
+
+
+
+
+
+DNSEXT Working Group Yuji Kamite
+INTERNET-DRAFT NTT Communications
+<draft-ietf-dnsext-tkey-renewal-mode-01.txt> Masaya Nakayama
+Expires: Nov. 11, 2002 The University of Tokyo
+ May 11, 2002
+
+
+
+
+ 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 secret keys used for TSIG [RFC2845]
+ periodically. Originally, TKEY provides methods of setting up shared
+ secrets other than manual exchange, but it cannot control timing of
+ key renewal very well though it can add or delete shared keys
+ separately. This proposal is a systematical key renewal procedure
+ intended for preventing signing DNS messages with old and non-safe
+ keys permanently.
+
+
+
+
+
+
+
+Kamite, et. al. [Page 1]
+\f
+INTERNET-DRAFT May 2002
+
+
+ Table of Contents
+
+
+1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4
+ 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4
+2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5
+ 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5
+ 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6
+ 2.3 Renewal Request . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.3.1 Query for DH Exchange for Key Renewal . . . . . . . . . . 6
+ 2.3.2 Response for DH Exchange for Key Renewal . . . . . . . . 8
+ 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 9
+ 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10
+ 2.5 Considerations about Non-compliant Hosts . . . . . . . . . . 10
+3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 11
+4 Compulsory Key Revocation by Server . . . . . . . . . . . . . . . 11
+ 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+5 Special Considerations for Two Servers' Case . . . . . . . . . . 12
+ 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 12
+6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 13
+7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 13
+8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 16
+9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 16
+10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamite, et. al. [Page 2]
+\f
+INTERNET-DRAFT May 2002
+
+
+1. Introduction
+
+ TSIG [RFC2845] provides DNS message integrity and the
+ request/transaction authentication by means of message authentication
+ codes (MAC). TSIG is a practical solution in view of calculation
+ speed and availablity. However, TSIG does not have exchanging
+ mechanism of shared secret keys between server and resolver, and
+ administrators might have to exchange secret keys manually. TKEY
+ [RFC2930] is introduced to solve such problem and it can exchange
+ secrets for TSIG via networks.
+
+ In various modes of TKEY, a server and a resolver can add or delete a
+ secret key be means of TKEY message exchange. However, the existing
+ 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 does not 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 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. Defined Words
+
+ * Inception Time: Beginning of the shared secret key lifetime. This
+ value is determined when the key is generated.
+
+ * Expiry Limit: Time limit of the key's validity. This value is
+ determined when a new key is generated. After Expiry Limit, server
+ and client (resolver) must not authenticate TSIG signed with the key.
+ Therefore, Renewal to the next key should be carried out before
+ Expiry Limit.
+
+ * Partial Revocation Time: Time when server judges the key is too old
+ and must be updated. It must be between Inception Time and Expiry
+
+
+
+Kamite, et. al. [Page 3]
+\f
+INTERNET-DRAFT May 2002
+
+
+ Limit. This value is determined by server freely following its
+ security policy. e.g., if the time from Inception to Partial
+ Revocation is short, renewal will be carried out more often, which
+ might be safer.
+
+ * Revocation Time: Time when the key becomes invalid and can be
+ removed. This value is not determined in advance because it is the
+ actual time when revocation is completed.
+
+ * Adoption Time: Time when the new key is adopted as the next key
+ formally. After Adoption, the key is valid and server and client can
+ generate or verify TSIG making use of it. Adoption Time also means
+ the time when it becomes possible to remove the previous key, so
+ Revocation and Adoption are usually done at the same time.
+
+
+ Partial
+ Inception Revocation Revocation Expiry Limit
+ | | | |
+ |----------------|- - - - - - >>|- (revoked) -|
+ | | | |
+ previous key | | |
+ |- - - -|-------------------->> time
+ | | new key
+ Inception Adoption
+
+
+1.2. New Format and Assigned Numbers
+
+ TSIG
+ ERROR = (PartialRevoke), to be defined
+
+ TKEY
+ Mode = (DH exchange for key renewal), to be defined
+ For detailed format, see section 2.3.
+ Mode = (key adoption), to be defined
+ For detailed format, see section 2.4.
+
+
+1.3. 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,
+ i.e. after Partial Revocation Time, 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
+
+
+
+Kamite, et. al. [Page 4]
+\f
+INTERNET-DRAFT May 2002
+
+
+ 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.
+
+ 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 this process, Diffie-Hellman
+ Exchange is used. After new secret establishment, the client sends a
+ TKEY Adoption request. If this is admitted by the server, the new key
+ is formally adopted, and at the same time the corresponding old
+ secret is invalidated. Then the client can send the first query again
+ signed with the new key.
+
+ Key renewal procedure is executed based on two phase commit
+ mechanism. The first phase is the TKEY Renewal request and its
+ response, which means preparatory confirmation for key update. The
+ second phase is Adoption request and its response. If the server gets
+ request and client receives the response successfully, they can
+ finish renewal process. If any error happens and renewal process
+ fails during these phases, client should roll back to the beginning
+ of the first phase, and send TKEY Renewal request again. This
+ rollback can be done until the Expiry Limit of the key.
+
+
+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. Key Usage Time Check
+
+ Whenever a server receives a query with TSIG and can find a key that
+ is used for signing it, the server checks its Inception time, Partial
+ Revocation time and Expiry Limit (this information is usually
+ memorized by the server).
+
+ 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].
+
+ When the present time is the same as the Partial Revocation Time, or
+ between the Partial Revocation Time and Expiry Limit, the server
+ comes to be in Partial Revocation state about the TSIG key and
+
+
+
+Kamite, et. al. [Page 5]
+\f
+INTERNET-DRAFT May 2002
+
+
+ behaves according to the next section.
+
+ When the present time is the same as the Expiry Time or after it, the
+ server MUST NOT verify TSIG with the key, and returns error messages
+ in the same way as when no valid key is found, following [RFC2845].
+
+
+2.2. Partial Revocation
+
+ In Partial Revocation state, we say the server has partially revoked
+ the key and the key has become a "partially revoked key".
+
+ Server which has received queries signed with the partially revoked
+ key MUST NOT answer them except when they are "DH exchange for key
+ renewal" requests (See section 2.3.) or "key adoption" requests (See
+ section 2.4.). Instead, it returns 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 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 is valid.
+
+
+2.3. Renewal Request
+
+2.3.1. Query for DH Exchange for Key Renewal
+
+ If a client has received a PartialRevoke Error and authenticated the
+ response based on TSIG MAC, it sends a TKEY query for Diffie-Hellman
+ exchange for key renewal (in this document, we call it Renewal
+ request, too.) to the server. The request MUST be signed with TSIG or
+ SIG(0) [RFC2931] for authentication. 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
+
+
+
+Kamite, et. al. [Page 6]
+\f
+INTERNET-DRAFT May 2002
+
+
+ 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". 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.
+
+ "Inception" and "Expiration" 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 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
+
+
+
+Kamite, et. al. [Page 7]
+\f
+INTERNET-DRAFT May 2002
+
+
+ OldAlgorithm domain algorithm of the old key
+
+
+2.3.2. Response for DH Exchange for Key Renewal
+
+ 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
+ verified TSIG is signed with the partially revoked key, the request
+ MUST be authenticated and accepted.
+
+ If the partially revoked key indicated in the request TKEY's OldName
+ field does not really exist at the server, or incompatible DH key is
+ found in the request, "BADKEY" [RFC 2845] is given in Error Field.
+ "FORMERR" is given if the query included no DH KEY.
+
+ If there are no errors, the server processes a response according to
+ Diffie-Hellman exchanged keying. Details of response messages are
+ below:
+
+ In answer section, there is one TKEY RR. The TKEY RR shows the
+ newly produced key's attributes such as a key name and algorithm.
+ Its format is defined as a response of the previous key renewal
+ request, so all values are equal to 2.3.1 except TKEY NAME, TKEY
+ RDLEN, RDATA's Inception, Expiration, Key Size and Key Data as long
+ as no error has occurred.
+
+ "NAME" field specifies the name of newly produced key which the
+ client will have to use.
+
+ "Inception" field and "Expiration" field mean the period of the
+ produced key usage. "Inception" should be set to be the time when
+ the new key is actually generated or the time before it, and it
+ will be regarded as Inception Time. "Expiration" is determined by
+ the server, and it will be regarded as Expiry Limit.
+
+ Once the server has decided Expiry Limit and returned a response,
+ it should obey them as long as it can. In other words, they SHOULD
+ NOT change time values for checking Expiry Limit in the future
+ without any special reason (e.g., a security issue such as
+ "Emergency Compulsory Revocation" described in section 8).
+
+ Note that the Partial Revocation Time about a new key is not
+ decided and informed based only on the client's request. The server
+ can decide any value as long as it is between Inception and Expiry
+ Limit. However, it is recommended that the period from Inception to
+ Partial Revocation should be fixed as the server side's
+ configuration or should be set the same as the corresponding old
+ key's one.
+
+
+
+Kamite, et. al. [Page 8]
+\f
+INTERNET-DRAFT May 2002
+
+
+ TKEY Key Data is used as an additional nonce to avoid deriving the
+ same keying material for the same pair of DH key, which is the same
+ as [RFC2930] 4.1.
+
+ If the TKEY error field is zero, The resolver supplied Diffie-
+ Hellman KEY RR SHOULD be echoed in the additional section and a
+ server Diffie-Hellman KEY RR will also be present in the answer
+ section like [RFC2930] 4.1.
+
+ At this moment, the server gets a new secret. However, it might
+ receive another "DH exchange for key renewal" TKEY request whose
+ OldName indicates the same partial revoked key. Mostly such messages
+ originate in client's resending or rollback. In this case, the server
+ processes Diffie-Hellman exchanged keying again and MUST replace the
+ stored secret with the newest produced secret. The secret key
+ produced before comes to be invalid and should be removed from
+ memory.
+
+ Even if client sends "DH exchange for key renewal" though the key
+ described in OldName has not been partially revoked yet, server must
+ do renewal processes. But at the moment when the servers accepts
+ such requests with valid authentication, it MUST forcibly consider
+ the key is already partially revoked, that is, the key's Partial
+ Revocation Time must be changed into the present time (i.e., the time
+ when the server receives the request).
+
+
+2.4. Key Adoption
+
+2.4.1. Query for Key Adoption
+
+ After receiving a TKEY Renewal answer, the client gets the same
+ secret as the server. Then, it sends a TKEY Adoption request. The
+ request's question section's QNAME field is the same as the NAME
+ filed of TKEY written below. In additional section, there is one TKEY
+ RR. TKEY RR has the structure and values described below.
+
+ "NAME" field is the new key's name to be adopted which was already
+ generated by Renewal message. "Algorithm" is its algorithm. "Incep-
+ tion" means the key's Inception Time, and "Expiration" means Expiry
+ Limit.
+
+ "Mode" field is the value of "key adoption", which is defined
+ newly. See section 9.
+
+ "Other Data" field in Adoption has the same structure as that of
+ "DH exchange for key renewal". "OldName" means the previous old
+ key, and "OldAlogirthm" means its algorithm.
+
+
+
+Kamite, et. al. [Page 9]
+\f
+INTERNET-DRAFT May 2002
+
+
+ Key Adoption request MUST be signed with TSIG or SIG(0) for
+ authentication. The client can sign TSIG with the previous key. Note
+ that until Adoption is finished, the new next key is treated as
+ invalid, thus it cannot be used for authentication immediately.
+
+
+2.4.2. Response for Key Adoption
+
+ The server which has received Adoption request, it verifies 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.
+
+ If the next new key indicated by the request TKEY's "NAME" is not
+ really present at the server, BADNAME [RFC 2845] is given in Error
+ Field and the error message is returned.
+
+ If the next key really exists and it has not been adopted formally
+ yet, the server confirms the previous key's existence indicated by
+ the "OldName" field. If it succeeds, the server executes Adoption of
+ the next key and Revocation of the previous key. Response message
+ duplicates the request's TKEY RR with NoError, including "OldName"
+ and "OldAlgorithm" that indicate the revoked key.
+
+ If the next key exists but it is already adopted, the server returns
+ a response message regardless of the substance of the request TKEY's
+ "OldName". In this response, Response TKEY RR has the same data as
+ the request's one except as to its "Other Data" that is changed into
+ null (i.e., "Other Size" is zero), which is intended for telling the
+ client that the previous key name was ignored, and the new key is
+ already available.
+
+ Client sometimes has to retry Adoption request. Suppose the client
+ sent request signed with the partially revoked key, but its response
+ did not return successfully (e.g., due to the drop of UDP packet).
+ Client will probably retry Adoption request; however, the request
+ will be refused in the form of TSIG "BADKEY" error because the
+ previous key was already revoked. In this case, client should
+ retransmit Adoption request signed with the next key, and expect a
+ response which has null "Other Data" for confirming the completion of
+ renewal.
+
+
+2.5. Considerations about Non-compliant Hosts
+
+ 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.
+
+
+
+Kamite, et. al. [Page 10]
+\f
+INTERNET-DRAFT May 2002
+
+
+ Note that server does not inform actively the necessity of renewal to
+ clients, but inform it as responses invoked by client's query.
+ Server needs not care whether the "PartialRevoke" errors has reached
+ client or not. If client has not received yet because of any reasons
+ such as packet drops, it will resend the queries, and finally will be
+ able to get "PartialRevoke" information.
+
+
+3. Secret Storage
+
+ Every server should keep all secrets and attached information, e.g.
+ Inception, Expiry Limit etc. safe to be able to recover from
+ unexpected stop. 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 Server
+
+ There is a rare but possible case that although servers have already
+ partially revoked keys, clients do not try to send any renewal
+ requests. If this state continues, in the future it will become the
+ time of Expiry Limit. After Expiry Limit, the keys will be expired
+ and completely removed, so this is called Compulsory Key Revocation
+ by server.
+
+ If Expiry Limit 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 Expiry Limit 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 Expiry Limit to their keys,
+ considering both their keys' safety, and enough time for clients to
+ send requests and process renewal.
+
+
+4.1. Example
+
+ 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
+
+
+
+Kamite, et. al. [Page 11]
+\f
+INTERNET-DRAFT May 2002
+
+
+ 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 any troubles should happen such as client host's long suspension
+ against expectation, the server will do 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) comes to want to refresh a shared key (called "Key A-B"), it will
+ await a TKEY Renewal request from the other server (called Server B).
+ 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.
+
+ 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 should 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
+ Time. It is okay that both hosts have it.
+
+ 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
+
+
+
+Kamite, et. al. [Page 12]
+\f
+INTERNET-DRAFT May 2002
+
+
+ not happen so often because Renewal requests are usually invoked when
+ hosts want to send queries, but it is possible.
+
+ 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 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
+ Renewal requests from others while they are waiting, their shared
+ keys may be refreshed, then they do not need to send any Renewal
+ requests now for themselves.
+
+
+6. Key Name Considerations
+
+ Since both servers and clients have only to distinguish new secrets
+ and old ones, keys' names do not need to be specified strictly. 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. and B.example.com. share the key
+ "<serial number>.A.example.com.B.example.com." such as
+ "10010.A.example.com.B.example.com.". After key renewal, they change
+ their secret and name into "10011.A.example.com.B.example.com."
+
+ Servers and clients must be able to use keys properly according to
+ servers to query. Because TSIG secret keys themselves do not have any
+ particular IDs to be distinguished and would be identified by their
+ names and algorithm, it must be understood correctly what keys are
+ refreshed.
+
+
+7. Example Usage of Secret Key Renewal Mode
+
+ This is an example of Renewal mode usage where a Server,
+ server.example.com, and a Client, client.exmple.com have an initial
+ shared secret key named "00.client.example.com.server.example.com".
+
+ (1) The time values about key
+ "00.client.example.com.server.example.com" was set as follows:
+ Inception Time is at 6:00, Expiry Limit is at 11:00.
+
+
+
+
+
+Kamite, et. al. [Page 13]
+\f
+INTERNET-DRAFT May 2002
+
+
+ (2) At Server, a time value about renewal timing has been set too:
+ Partial Revocation Time is at 8:00.
+
+ (3) Suppose the present time is 7:00. If Client sends a query
+ signed with key "00.client.example.com.server.example.com" to ask
+ 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.server.example.com" to ask the IP address of
+ "www.otherdomain.com". But it will not get a proper answer from
+ Server. The response does not have any IP address information about
+ "www.otherdomain.com". Instead, it includes valid TSIG MAC signed
+ with "00.client.example.com.server.example.com", and its Error Code
+ indicates PartialRevoke.
+
+ (5) At 9:01. Client sends a Renewal request to Server. This request
+ is signed with key "00.client.example.com.server.example.com". It
+ includes data such as:
+
+ Question Section:
+ QNAME = 01.client.example.com. (Client can set this freely)
+ TYPE = TKEY
+
+ Additional Section:
+ 01.client.example.com. TKEY
+ Algorithm = hmac-md5-sig-alg.reg.int.
+ Inception = (value which means 8:55)
+ Expiration = (value which means 14:00)
+ Mode = (DH exchange for key renewal)
+ OldName = 00.client.example.com.server.example.com.
+ OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+ Additional Section also contains a KEY RR for DH and a TSIG RR.
+
+ (6) As soon as Server receives this request, it verifies TSIG. It
+ is signed with the partially revoked key
+ "00.client.example.com.server.example.com". and Server accepts the
+ request. It 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 8:55)
+ Expiration = (value meaning 14:00)
+ Mode = (DH exchange for key renewal)
+ OldName = 00.client.example.com.server.example.com.
+
+
+
+Kamite, et. al. [Page 14]
+\f
+INTERNET-DRAFT May 2002
+
+
+ OldAlgorithm = hmac-md5-sig-alg.reg.int.
+ Answer Section also contains KEY RRs for DH.
+
+ Additional Section also contains a TSIG RR.
+ This response is signed with key
+ "00.client.example.com.server.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) At 9:02. Client sends an Adoption request to Server. This
+ request is signed with the previous key
+ "00.client.example.com.server.example.com". It includes:
+
+ Question Section:
+ QNAME = 01.client.example.com.server.example.com.
+ TYPE = TKEY
+
+ Additional Section:
+ 01.client.example.com.server.example.com. TKEY
+ Algorithm = hmac-md5-sig-alg.reg.int.
+ Inception = (value which means 8:55)
+ Expiration = (value which means 14:00)
+ Mode = (key adoption)
+ OldName = 00.client.example.com.server.example.com.
+ OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+ Additional Section also contains a TSIG RR.
+
+ (9) Server verifies the query's TSIG. It is signed with the
+ previous key and authenticated. It returns a response whose TKEY RR
+ is the same as the request's one. The response is signed with key
+ "00.client.example.com.server.example.com.". As soon as the
+ response is sent, Server revokes and removes the previous key. At
+ the same time, key "01.client.example.com.server.example.com." is
+ validated.
+
+ (10) Client acknowledges the success of Adoption by receiving the
+ response. Then, it will retry to send an original question about
+ "www.otherdomain.com". It is signed with the adopted key
+ "01.client.example.com.server.example.com", so Server authenticates
+ it and returns an answer.
+
+
+
+
+Kamite, et. al. [Page 15]
+\f
+INTERNET-DRAFT May 2002
+
+
+ (11) This key is used until 11:00. After that, it will be partially
+ revoked again.
+
+
+8. Security Considerations
+
+ 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 do not 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". For example, suppose the original Expiry
+ Limit was set at 15:00, Partial Revocation Time at 12:00 and
+ Inception Time at 10:00. if at 11:00 the key is found to be
+ compromised, the server sets Expiry Limit forcibly to be 11:00 or
+ before it.
+
+ 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 Considerations
+
+ IANA needs to allocate a value for "DH exchange for key renewal" and
+ "key adoption" 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]
+\f
+INTERNET-DRAFT May 2002
+
+
+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]
+\f
+INTERNET-DRAFT May 2002
+
+
+Authors' Addresses
+
+ Yuji Kamite
+ NTT Communications Corporation
+ Tokyo Opera City Tower 21F,
+ 20-2, 3-chome, Nishi-Shinjuku, Shinjuku-ku,
+ Tokyo, 163-1421, Japan.
+ EMail: y.kamite@ntt.com
+
+
+ Masaya Nakayama
+ The University of Tokyo
+ Information Technology Center,
+ 2-11-16 Yayoi, Bunkyo-ku,
+ Tokyo, 113-8658, Japan.
+ EMail: nakayama@nc.u-tokyo.ac.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamite, et. al. [Page 18]
+\f
+
projects / thirdparty / bind9.git / commitdiff
