draft-ietf-dnsext-tkey-renewal-mode-03.txt

bind-3.2.


INTERNET-DRAFT                                                 Mar. 2003


      to Diffie-Hellman algorithm and returns the answer. In this
      answer, there is one TKEY RR in answer section and KEY RR(s) in
      additional section.

      As long as no error has occurred, all values of TKEY are equal to
      that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
      Inception, Expiration, Key Size and Key Data.

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

      TKEY "Inception" and "Expiration" mean the periods 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.

      TKEY "Key Data" is used as an additional nonce, following
      [RFC2930] 4.1.

      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, following [RFC2930] 4.1.


2.5.2.  Server Assigned Keying for Key Renewal

   This scheme is defined as an extended method of [RFC2930] 4.4. This
   specification only describes the difference from it and special
   notice; assume that all other points, such as secret encrypting
   method, are the exactly same as the specification of [RFC2930] 4.4.

   Query
      In Renewal request for type TKEY with this mode, there is one TKEY
      RR and one KEY RR in the additional information section. KEY RR is
      used in encrypting the response.

      QNAME in question section is the same as that of "NAME" field in
      TKEY RR, i.e., it means the requested new key's name.

      TKEY "Mode" field stores the value of "server assignment for key
      renewal". See section 9.

      TKEY "Inception" and "Expiration" are those requested for the
      keying material, that is, requested usage period of a new key.

      TKEY "Key Data" is provided following the specification of
      [RFC2930] 4.4.



Kamite, et. al.                                                [Page 12]

INTERNET-DRAFT                                                 Mar. 2003


   Response
      The server which received this request first verifies the TSIG or
      SIG(0). Resolver KEY RR is also authenticated by means of
      verifying that TSIG or SIG(0). After authentication, the old key's
      existence validity is checked, following section 2.3. "FORMERR" is
      given if the query specified no encryption key.

      If there are no errors, the server response contains one TKEY RR
      in the answer section, and echoes the KEY RR provided in the query
      in the additional information section.

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

      TKEY "Inception" and "Expiration" mean the periods 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.

      TKEY "Key Data" is the assigned keying data encrypted under the
      public key in the resolver provided KEY RR, which is the same as
      [RFC2930] 4.4.


2.5.3.  Resolver Assigned Keying for Key Renewal

   This scheme is defined as an extended method of [RFC2930] 4.5. This
   specification only describes the difference from it and special
   notice; assume that all other points, such as secret encrypting
   method, are the exactly same as the specification of [RFC2930] 4.5.

   Query
      In Renewal request for type TKEY with this mode, there is one TKEY
      RR and one KEY RR in the additional information section. TKEY RR
      has the encrypted keying material and KEY RR is the server public
      key used to encrypt the data.

      QNAME in question section is the same as that of "NAME" field in
      TKEY RR, i.e., it means the requested new key's name.

      TKEY "Mode" field stores the value of "resolver assignment for key
      renewal". See section 9.

      TKEY "Inception" and "Expiration" are those requested for the
      keying material, that is, requested usage period of a new key.

      TKEY "Key Data" is the encrypted keying material.



Kamite, et. al.                                                [Page 13]

INTERNET-DRAFT                                                 Mar. 2003


   Response
      The server which received this request first verifies the TSIG or
      SIG(0). After authentication, the old key's existence validity is
      checked, following section 2.3. "FORMERR" is given if the server
      does not have the corresponding private key for the KEY RR that
      was shown in the request.

      If there are no errors, the server returns response. The response
      must have a TKEY RR in the answer section to tell the shared key's
      name and its usage time values.

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

      TKEY "Inception" and "Expiration" mean the periods 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.


2.6.  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.

   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 Time, Expiry Limit, etc. safely 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.







Kamite, et. al.                                                [Page 14]

INTERNET-DRAFT                                                 Mar. 2003


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
     Exchanged Keying" as described in [RFC2930] 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 easier 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.








Kamite, et. al.                                                [Page 15]

INTERNET-DRAFT                                                 Mar. 2003


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.

   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 Renewal request 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 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
   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.



Kamite, et. al.                                                [Page 16]

INTERNET-DRAFT                                                 Mar. 2003


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." If
   secret overwrite occurs as a result of client's retransmission,
   server must change the next key's name somehow; for example, server
   increases serial number forcibly, or add some random numbers to the
   name.

   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