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

bind 9.3结合mysql数据库


INTERNET-DRAFT                                                 Feb. 2004


      TKEY "Mode" field stores the value of "DH exchange 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 used as a random, following [RFC2930] 4.1.

   Response
      The server which received this request first verifies the TSIG,
      SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
      old key's existence validity is checked, following section 2.3. If
      any incompatible DH key is found in the request, "BADKEY"
      [RFC2845] is given in Error field for response. "FORMERR" is given
      if the query included no DH KEY.

      If there are no errors, the server processes a response according
      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 MUST use.

      TKEY "Inception" and "Expiration" mean the periods of the produced
      key usage. "Inception" is 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.



Kamite, et. al.                                                [Page 12]

INTERNET-DRAFT                                                 Feb. 2004


   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.

   Response
      The server which received this request first verifies the TSIG,
      SIG(0) or DNSSEC lookup of KEY RR used. 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 MUST use.

      TKEY "Inception" and "Expiration" mean the periods of the produced
      key usage. "Inception" is 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.




Kamite, et. al.                                                [Page 13]

INTERNET-DRAFT                                                 Feb. 2004


   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.

   Response
      The server which received this request first verifies the TSIG,
      SIG(0) or DNSSEC lookup of KEY RR used. 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 sin the request.

      If there are no errors, the server returns a response. The
      response contains 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 MUST use.

      TKEY "Inception" and "Expiration" mean the periods of the produced
      key usage. "Inception" is 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



Kamite, et. al.                                                [Page 14]

INTERNET-DRAFT                                                 Feb. 2004


   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 keeps 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. It will become more secure if they are stored in ecrypted
   form.


4.  Compulsory Key Revocation

4.1.  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.2.  Authentication Methods Considerations

   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



Kamite, et. al.                                                [Page 15]

INTERNET-DRAFT                                                 Feb. 2004


     shared secret, they keep using TSIG for 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.

     Suppose now client is halted for long time with some reason.
     Because server does not execute any renewal process, it will
     finally do Compulsory Revocation. Even if client restarts and sends
     a key Renewal request, it will fail because old key is already
     deleted at server.

     At this moment, however, if client also uses SIG(0) as another
     authentication method, it can make a new shared key again and
     recover successfully by sending "Query for Diffie-Hellman Exchanged
     Keying" with SIG(0).


5.  Special Considerations for Two servers' Case

   This section refers to the case where both hosts are DNS servers
   which can act as full resolvers as well and using one shared key
   only. If one server (called Server A) wants to refresh a shared key
   (called "Key A-B"), it will await a TKEY Renewal request from the
   other server (called Server B). However, perhaps Server A wants to
   refresh the key right now.

   In this case, Server A is allowed to send a Renewal request to Server
   B, if Server A knows the Key A-B is too old and wants to renew it
   immediately.

   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.
   However, 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



Kamite, et. al.                                                [Page 16]

INTERNET-DRAFT                                                 Feb. 2004


   hosts want to send queries, but it is possible.

   When one of two servers tries 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.
   However, it is recommended that some serial number or key generation
   time 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