DNSEXT Working Group                                        Yuji Kamite
INTERNET-DRAFT                                       NTT Communications
<draft-ietf-dnsext-tkey-renewal-mode-01.txt>            Masaya Nakayama
<draft-ietf-dnsext-tkey-renewal-mode-00.txt>    the
Expires: Nov. 11, 2002                          The University of Tokyo
Expires:
                                                           May 2, 11, 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 used for TSIG
   [RFC2845]. [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 method proposal is a systematical key renewal procedure
   intended to prevent for preventing signing DNS 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.

                           Table of Contents

1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1  Overview of Secret Key Renewal Mode  Defined Words . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.2  Comparison of Secret Key Renewal  New Format and usual Diffie-Hellman
  Exchanged Keying Assigned Numbers . . . . . . . . . . . . . . .   4
  1.3  Overview of Secret Key Renewal Mode . . . . . . . . . . . . .   4
2  Shared secret key renewal Secret Key Renewal . . . . . . . . . . . . . . . . . . . .   5
  2.1  Detection of secret expiration  Key Usage Time Check  . . . . . . . . . . . . . . .   5
  2.2  Partial key revocation . . . . .   5
  2.2  Partial Revocation  . . . . . . . . . . . . . .   6
  2.3  Query for DH exchange for key renewal . . . . . . .   6
  2.3  Renewal Request . . . . . .   6
    2.3.1  Query . . . . . . . . . . . . . . . . .   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  . . . . . . . . . . . . . . . .   8
  2.4  Key Adoption  . . . . . . . . . .   9
    2.4.1  Query for Key Adoption  . . . . . . . . . . . . . .  10
  2.5  Considerations about non-compliant hosts for secret key
  renewal . . .   9
    2.4.2  Response for Key Adoption . . . . . . . . . . . . . . . .  10
  2.5  Considerations about Non-compliant Hosts  . . . . . . . . . .  10
3  Secret Storage  . . . . . . . . . . . . . . . . . . . . . . . . .  10  11
4  Compulsory key revocation Key Revocation by servers Server . . . . . . . . . . . . . .  10 .  11
  4.1  Example of compulsory key revocation . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
5  Special considerations Considerations for two servers' case Two Servers' Case  . . . . . . . . . .  11  12
  5.1  To cope Cope with collisions Collisions of renewal requests Renewal Requests . . . . . . . . .  12
6  Key name consideration Name Considerations . . . . . . . . . . . . . . . . . . . . .  13
7  Example usage Usage of TKEY Secret Key Renewal Mode  . . . . . . . . . .  14 . .  13
8  Security consideration Considerations . . . . . . . . . . . . . . . . . . . . .  16
9  IANA consideration Considerations . . . . . . . . . . . . . . . . . . . . . . .  16
10 References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   TSIG [RFC2845] provides whole DNS message integrity and the
   request/transaction authentication, authentication by means of message authentication
   codes (MAC). Moreover, TSIG is a practical solution in view of calculation
   speed and easily available. To make use availablity. However, TSIG does not have exchanging
   mechanism of TSIG, in most
   cases hosts must share shared secret keys by manual exchange, which is a
   little troublesome. but if you use between server and resolver, and
   administrators might have to exchange secret keys manually.  TKEY
   [RFC2930] as well, hosts is introduced to solve such problem and it can
   establish exchange
   secrets for TSIG via networks, not by manual exchange. 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, old 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 doesn't 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 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  Defined Words

   * Inception Time: Beginning 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 shared secret key lifetime. This
   value is within determined when the range of usage
   duration it considers safe. If it key is judged that generated.

   * Expiry Limit: Time limit of the key's validity. This value is
   determined when a new key is too old,
   the generated. After Expiry Limit, server comes to be in "partial revocation" state about the key.

   In this state, whenever a
   and client sends a normal query (e.g. question
   about A RR) other than TKEY "Renewal" request with (resolver) must not authenticate TSIG signed with the old key, key.
   Therefore, Renewal to the next key should be carried out before
   Expiry Limit.

   * Partial Revocation Time: Time when server returns an error message to notify that judges the key is too old
   and must be updated. It must be between Inception Time and Expiry
   Limit.  This value is determined by server freely following its
   security policy. e.g., if the time from Inception to renew has come.  This Partial
   Revocation is called "PartialRevoke" error
   message.

   The client short, renewal will be carried out more often, which got this error
   might be safer.

   * Revocation Time: Time when the key becomes invalid and can be
   removed. This value is able to notice that not determined in advance because 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
   actual time when revocation is used.  After new secret establishment, the client
   retries completed.

   * Adoption Time: Time when the original query to new key is adopted as the server.  When next key
   formally. After Adoption, the key is valid and server receives
   it and succeeds to client can
   generate or verify TSIG signed with making use of it. Adoption Time also means
   the new secret key, time when it becomes possible to remove the
   key is formally adopted, previous key, so
   Revocation and Adoption are usually done at the same time.

                  Partial
    Inception     Revocation    Revocation         Expiry Limit
     |                |              |             |
     |----------------|- - - - - - >>|- (revoked) -|
     |                |              |             |
    previous key      |      |       |
                             |- - - -|-------------------->> time the corresponding old
   secret is invalidated.
                             |       |               new key
                         Inception   Adoption

1.2.  Comparison  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 and usual Diffie-Hellman
Exchanged Keying

   If you use Diffie-Hellman Exchanged Keying [RFC2930], Mode

   When a new key can
   be generated after message exchange. Thus, server receives a query from a client signed with a TSIG key,
   It always checks if clients take heed of
   inception and expiration the present 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 within the range of operation.
   First, It usage
   duration it considers safe. If it is impossible for clients to sense timings of sending
   Diffie-Hellman Exchanged Keying queries based on judged that 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 old,
   i.e. after Partial Revocation Time, the server comes to get keying
   answers because DNS messages can be exchanged on UDP and might be
   sometimes dropped. Then, they will try 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 send requests again, and notify that the servers will have time
   to make other keys more. On top of that,
   possibly there might be malicious clients renew has come.  This is called "PartialRevoke" error message.

   The client which got this error is able to notice that want only it is
   necessary to annoy
   servers by sending refresh the secret.  To make a lot of requests.

   "Secret Key new shared secret, it
   sends a TKEY Renewal Mode" solves these problems.  Because request. In this mode's
   requests are often triggered by process, Diffie-Hellman
   Exchange is used.  After new secret establishment, the detection of "PartialRevoke" TSIG
   error answers (defined in client sends a
   TKEY Adoption request. If this document), clients know is admitted by the server, the new key renewal
   timing
   is formally adopted, and at any time even if they haven't traced old keys'
   inception/expiration the same 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
   secret is invalidated. Then the client can be said that this
   "Renewal" Mode specifies concrete procedure to switch an old key to send the first query again
   signed with the new one smoothly, not limited only in adding or deleting a 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 executed based on two hosts.

2.1.  Detection of secret expiration

   DNS servers permitting TSIG key renewal MUST keep and be able to
   recognize all secret inception phase commit
   mechanism. The first phase is the TKEY Renewal request and expiration time about keys. Each
   secret its
   response, which means preparatory confirmation for key has one inception time update. The
   second phase is Adoption request and one expiration time. 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 whose name that
   is
   indicated in TSIG, used for signing it, 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 its Inception time, Partial
   Revocation 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 Expiry Limit (this information is usually configured
   memorized 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. server).

   When the present time is before inception time, 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, Inception Time, or between
   inception time
   Inception Time and partial revocation time, 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.
   [RFC2845].

   When the present time is the same as the partial revocation time, Partial Revocation Time, or
   between the partial revocation time Partial Revocation Time and the expiration time, Expiry Limit, the server
   comes to be in Partial Revocation state about the TSIG key and
   behaves according to the protocol written below. next section.

   When the present time is the same as the expiration time 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 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 Revocation

   In Partial Revocation state, we say the server has partially revoked
   the key and the old key has come to be become 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

   Server which have has received queries signed with the partially revoked keys
   key MUST NOT answer them except when they are "DH exchange for key
   renewal" requests (see (See section 2.3.) or "key adoption" requests (See
   section
   2.3). 2.4.).  Instead, they return it returns TSIG error messages whose error
   codes are "PartialRevoke" (See section 9).

   "PartialRevoke" 9.)

   PartialRevoke error messages have the role to inform clients of the
   keys' partial revocation and urge them to send TKEY key renewal 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" 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 is valid.

2.3.  Renewal Request

2.3.1.  Query for DH exchange Exchange for key renewal

2.3.1.  Query Key Renewal

   If a client has received a "PartialRevoke" PartialRevoke Error and authenticated the
   response based on TSIG MAC, it sends a TKEY secret query for Diffie-Hellman
   exchange for key renewal
   request (in this document, we call it Renewal
   request, too.) 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 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. 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. 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 9.

     In "DH DH exchange for key renewal" 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 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 and can be
   verified, key, the message request
   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. authenticated and accepted.

   If the partially revoked key indicated in the request TKEY TKEY's OldName
   doesn't
   field does not really exist at the server, or incompatible DH key is
   found in the request, BADKEY "BADKEY" [RFC 2845] is given in Error Field. FORMERR
   "FORMERR" is given if the query included no DH KEY.

   If there is are no error, errors, the server processes a response according to
   Diffie-Hellman exchanged keying.  Response message's details  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 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

     "NAME" field specifies the name of newly produced key which the
     client will have to use.

     TKEY Inception

     "Inception" field and Expiration time "Expiration" field mean the period of the
     produced key usage. Inception time MUST "Inception" should be set to be the time when
     the new key is generated, thus after clients receive responses, they can use
     new keys immediately. Expiration actually generated or the time before it, and it
     will be regarded as Inception Time. "Expiration" is determined by servers
     allowing for request messages. However, if servers judge requested
     usage periods are too short or too long, they can ignore them
     the server, and
     decide expiration time freely based on their own security policies. it will be regarded as Expiry Limit.

     Once servers have the server has decided expiration time Expiry Limit and already returned
     responses, they a response,
     it should obey them as long as they it can. In other words, they SHOULD
     NOT change time values for checking expiration Expiry Limit in the future
     without any special reason (e.g. (e.g., a security issue such as "emergency compulsory revocation"
     "Emergency Compulsory Revocation" described in Section section 8).
     Therefore,

     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.

     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 sending responses, they 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 memorize correctly
   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 values with secret key data.

     Note that (i.e., the "partial revocation" time about
   when the server receives the request).

2.4.  Key Adoption

2.4.1.  Query for Key Adoption

   After receiving a new key isn't
     decided base on TKEY Renewal answer, the client's client gets the same
   secret as the server. Then, it sends a TKEY Adoption request. The server can set freely any
     value as long
   request's question section's QNAME field is the same as it the NAME
   filed of TKEY written below. In additional section, there is between inception one TKEY
   RR. TKEY RR has the structure and expiration. However,
     it values described below.

     "NAME" field is recommended that the period from inception new key's name to "partial
     revocation" time should be fixed as adopted which was already
     generated by Renewal message. "Algorithm" is its algorithm. "Incep-
     tion" means the server side's configuration
     or should be set 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 corresponding previous old key's one.

     TKEY
     key, and "OldAlogirthm" means its algorithm.

   Key Data is used as an additional nonce to avoid deriving the
     same keying material Adoption request MUST be signed with TSIG or SIG(0) for
   authentication. The client can sign TSIG with the same pair of DH key, which previous key. Note
   that until Adoption is finished, the same new next key is treated as [RFC2930] 4.1.
   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 TKEY error field TSIG is zero, The resolver supplied Diffie-
     Hellman KEY RR SHOULD be echoed in signed with the additional section partially
   revoked key and a
     server Diffie-Hellman KEY RR will also can be present in verified, the answer
     section like [RFC2930] 4.1.

   At this moment, message MUST be authenticated.

   If the server gets a next new secret. However, it might
   receive another "DH exchange for key renewal" TKEY indicated by the request whose
   OldName in TKEY indicates TKEY's "NAME" is not
   really present at the same partial revoked key. Mostly such
   messages originate server, BADNAME [RFC 2845] is given in client's resending. In this case, the server
   processes Diffie-Hellman exchanged keying again Error
   Field and MUST replace the
   stored secret with error message is returned.

   If the newest produced secret. The secret next key
   produced before comes to be invalid really exists and should be removed from
   memory.

   Even if clients send "DH exchange for key renewal" though the keys
   described in OldName have it has not been partially revoked adopted formally
   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, server confirms the previous key's "partial
   revocation" time must be set to be the present time (i.e. existence indicated by
   the time
   when "OldName" field. If it succeeds, the server receives the request).

2.4.  Key executes Adoption

   After Receiving a TKEY answer, of
   the client gets next key and Revocation of the same secret as previous key. Response message
   duplicates the
   server. Then, it tries to resolve request's TKEY RR with NoError, including "OldName"
   and "OldAlgorithm" that indicate the original question which was
   wanted first (i.e. revoked key.

   If the question clients tried to ask before next key exists but it got is already adopted, the "PartialRevoke" error).

   As soon 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 message signed with
   client that the new previous key reaches the server name was ignored, and
   is verified, the new key is formally adopted and at
   already available.

   Client sometimes has to retry Adoption request. Suppose the same time client
   sent request signed with the partially revoked key expires completely. After that the server MUST
   NOT verify any queries with key, but its response
   did not return successfully (e.g., due to the completely revoked key. At this
   moment drop of UDP packet).
   Client will probably retry Adoption request; however, the server comes to request
   will be out refused in the form of "partial revocation sate", and
   it is only TSIG "BADKEY" error because the new adopted
   previous key that is used between was already revoked. In this case, client should
   retransmit Adoption request signed with the server next key, and expect a
   response which has null "Other Data" for confirming the host. completion of
   renewal.

2.5.  Considerations about non-compliant hosts for secret key renewal Non-compliant Hosts

   Key renewal 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 server does not inform actively the necessity of renewal to
   clients, but inform it as responses invoked by clients' queries.
   Servers don't need to client's query.
   Server needs not care whether the "PartialRevoke" errors have has reached clients
   client or not. If clients have client has not received yet because of any reasons
   such as UDP packet drops, they it will resend the queries, and finally will be
   able to get "PartialRevoke" information about the
   keys they have been using. information.

3.  Secret Storage

   Every hosts server should keep all secrets and attached information (e.g.
   inception and expiration etc.) information, e.g.
   Inception, Expiry Limit etc. safe to be able to recover from
   unexpected stop of the server. 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 Key Revocation by servers Server

   There is a rare but possible case that although servers have already
   partially revoked keys, clients don't do not try to send any renewal
   requests. If this state continues, in the future it will become the
   time of expiration. Expiry Limit. After expiration, Expiry Limit, the keys will be expired
   and completely removed, so this is called compulsory key revocation Compulsory Key Revocation
   by servers. server.

   If expiration time Expiry Limit is too distant from the partial revocation time, 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 Expiry Limit is too close to partial
   revocation time, Partial Revocation
   Time, perhaps clients might not be able to notice their keys' partial revocation Partial
   Revocation by getting "PartialRevoke" errors.

   Therefore, servers should set proper expiration time Expiry Limit 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 any troubles should happen such as client host's long suspension
     against expectation, the server will carry out do compulsory revocation.
     After recovery if the client sends a key
     renewal 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 Considerations for two Two servers' case 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 Server
   A) comes to partially revoke want to refresh a shared key (called "Key A-
   B"), A-B"), it will
   await a TKEY renewal Renewal request from the other server (called "Server B"). 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" 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 should be able to
   receive and process key renewal request from each other if they agree
   to refresh their shared secret keys by "DH DH exchange for key renewal" renewal
   procedures.

   Note that the initiative in key renewal belongs to Server A because
   it can notice the "partial revocation" time Partial Revocation Time and decide key renewal. If
   Server B has information about "partial revocation" time 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 Cope with collisions Collisions of renewal requests 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 Partial Revocation
   Time. It is okay that both of them can hosts have information. 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
   not happen so often because key renewal because Renewal requests are usually invoked when
   hosts want to send queries, but we should take the possibility
   into consideration. it is possible.

   When one of two servers try to send renewal 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. (i.e., it must lock
   the old secret during the process of renewal). While the server is
   sending renewal Renewal requests and waiting responses, it ignores the other
   server's key renewal 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
   Renewal requests from others while they are awaiting the delays, waiting, their shared
   keys may be changed, refreshed, then they don't do not need to send any
   renewal Renewal
   requests now for themselves because the secrets are already
   refreshed. themselves.

6.  Key name consideration Name Considerations

   Since both servers and clients have only to distinguish new secrets
   and old ones, keys' names don't do not need to be specified. 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. (Server A) and B.example.com. (Client B)
   shares share the key like this:

     10010.A.example.com.B.example.com.

   and after the process of
   "<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.

   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). "10011.A.example.com.B.example.com."

   Servers and clients must be able to use keys properly according to
   hosts
   servers 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 do not have any
   particular IDs to be distinguished and would be identified by their
   names and algorithm, hosts it must understand be understood correctly what keys are
   refreshed.

7.  Example usage Usage of TKEY Secret Key Renewal Mode

   This is an example of "Renewal" Renewal mode usage where a Server,
   ns.example.com,
   server.example.com, and a Client, client.exmple.com have an initial
   shared secret key named "00.client.example.com.ns.example.com" "00.client.example.com.server.example.com".

     (1) The time values about key
     "00.client.example.com.ns.example.com"
     "00.client.example.com.server.example.com" was set as follows:
     inception
     Inception Time is at 6:00, expiration Expiry Limit is at 11:00.

     (2) At Server, a time value about renewal timing has been set too:
     partial revocation time
     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" "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.ns.example.com"
     "00.client.example.com.server.example.com" to ask the IP address of
     "www.otherdomain.com". But it won't will not get a proper answer from
     Server. The response doesn't does not 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 "00.client.example.com.server.example.com", and its Error Code
     indicates "PartialRevoke". PartialRevoke.

     (5) At 9:01. Since Client has understood that its key has been
     considered to be old by Server, it will send sends a "Renewal" Renewal request to Server. This request
     is signed with key
     "00.client.example.com.ns.example.com". "00.client.example.com.server.example.com". It
     includes data such as:

      Question Section:
         QNAME = 01.client.example.com. (This (Client can be set freely by
     Client) this freely)
         TYPE  = TKEY

      Additional Section:
         01.client.example.com. TKEY
          Algorithm    = hmac-md5-sig-alg.reg.int.
          Inception    = (value which means 9:01) 8:55)
          Expiration   = (value which means 14:00)
          Mode         = (DH exchange for key renewal)
          OldName      = 00.client.example.com.ns.example.com. 00.client.example.com.server.example.com.
          OldAlgorithm = hmac-md5-sig-alg.reg.int.

      (Additional

      Additional Section also contains a KEY RR for DH and a TSIG RR) RR.

     (6) As soon as Server receives this request, it tries to verify verifies TSIG. It
     is valid but signed with partial the partially revoked key
     "00.client.example.com.ns.example.com". However, since this is a
     request for "Renewal",
     "00.client.example.com.server.example.com". and Server accepts processing the renewal.
     Server
     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 9:01) 8:55)
          Expiration   = (value meaning 14:00)
          Mode         = (DH exchange for key renewal)
          OldName      = 00.client.example.com.ns.example.com. 00.client.example.com.server.example.com.

          OldAlgorithm = hmac-md5-sig-alg.reg.int.
      (Answer
      Answer Section also contains KEY RRs)

      (Additional RRs for DH.

      Additional Section also contains a TSIG RR) RR.
     This response is signed with key
     "00.client.example.com.ns.example.com"
     "00.client.example.com.server.example.com" without error.

     At the same time, Server decides to set the partial revocation time 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 will retry to send sends an original question about
     "www.otherdomain.com". It Adoption request to Server. This
     request is signed with the created previous key
     "01.client.example.com.server.example.com".
     "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. Since it succeeds, it adopts
     key "01.client.example.com.server.example.com" formally. Key
     "00.client.example.com.server.example.com." It is removed from Server.
     Then, it signed with the
     previous key and authenticated. It returns an answer about a response whose TKEY RR
     is the IP address of
     "www.otherdomain.com" with TSIG same as the request's one. The response is signed with key
     "01.client.example.com.server.example.com".

     (10) Client knows
     "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 adopted
     validated.

     (10) Client acknowledges the success of Adoption by Server. 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.

     (11) This key is valid used until 11:00. After that, it will be partially
     revoked again.

8.  Security consideration 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 Secret Key Renewal Mode forbids clients to send queries as long
   as they don't 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 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. "Emergency
   Compulsory Revocation". For example, suppose the original expiration
   time Expiry
   Limit was set at 15:00, partial revocation time Partial Revocation Time at 12:00 and inception
   Inception Time at 10:00.  if at 11:00 the key is found to be
   compromised, the server
   can sets Expiry Limit forcibly set expiration time 11:00. to be 11:00 or
   before it.

   Consequently, once "compulsory revocation" Compulsory Revocation (See section 4) is carried
   out, normal "renewal" 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"
   renewal procedure only if they have other (non-
   compromised) (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 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.

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.

Authors' Addresses

   Yuji Kamite
   Information Technology Center,
   the University of Tokyo,
   2-11-16 Yayoi, Bunkyo-ku,
   NTT Communications Corporation
   Tokyo Opera City Tower 21F,
   20-2, 3-chome, Nishi-Shinjuku, Shinjuku-ku,
   Tokyo, 113-8658, 163-1421, Japan.
   EMail: kamite@kaynet.ecc.u-tokyo.ac.jp y.kamite@ntt.com

   Masaya Nakayama
   The University of Tokyo
   Information Technology Center,
   the University of Tokyo,
   2-11-16 Yayoi, Bunkyo-ku,
   Tokyo, 113-8658, Japan.
   EMail: nakayama@nc.u-tokyo.ac.jp