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

bind 9.3结合mysql数据库

   (See section 2.4.), then server does proper process following each
   specification. If it is for TKEY key deletion request ([RFC2930]
   4.2), server MAY process usual deletion operation defined therein.

   If server receives other types of query signed with the partially
   revoked key, and both the corresponding MAC and signed TIME are
   verified, then server begins returning answer whose TSIG error code
   is "PartialRevoke" (See section 9.). Server MUST randomly but with
   increasing frequency return PartialRevoke when in the Partial
   Revocation state.

   Server can decide when it actually sends PartialRevoke, checking if
   it is appropriate time for renewal. Server MUST NOT return
   PartialRevoke if this is apart long lived TSIG transaction (such as
   AXFR) that started before the Partial Revocation Time.

   If the client receives PartialRevoke and understands it, then it MUST
   retry the query with the old key unless a new key has been adopted.
   Client SHOULD start the process to renew the TSIG key. For key
   renewal procedure, see details in Section 2.3 and 2.4.

   PartialRevoke period (i.e., time while server returns PartialRevoke
   randomely) SHOULD be small, say 2-5% of key lifetime. This is
   server's choice.




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


   Server MUST keep track of clients ignoring PartialRevoke, thus
   indicating ignorance of this TKEY mode.

   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
   signing keys 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 MUST return another error
   such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
   words, a server informs its key's partial revocation only when the
   MAC in the received query is valid.


2.3.  Key Renewal Message Exchange

2.3.1.  Query 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 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. If TSIG is selected, the client can sign it with the
   partial revoked key.

   Key Renewal can use one of several keying methods which is indicated
   in "Mode" field of TKEY RR, and its message structure is dependent on
   that method.


2.3.2.  Response for Key Renewal

   The server which has received Key Renewal request first tries to
   verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
   verified with the partially revoked key, the request MUST be
   authenticated.

   After authentication, server must check existing old key's validity.
   If the partially revoked key indicated in the request TKEY's OldName
   and OldAlgorithm field (See section 2.3.4.) does not exist at the
   server, "BADKEY" [RFC2845] is given in Error field for response. If
   any other error happens, server returns appropriate error messages
   following the specification described in section 2.5. If there are no
   errors, server returns a Key Renewal answer. This answer MUST be
   signed with TSIG or SIG(0) for authentication.

   When this answer is successfully returned and no error is detected by



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


   client, a new shared secret can be established. The details of
   concrete keying procedure are given in the section 2.5.

   Note:
      Sometimes Adoption message and new Renewal request will cross on
      the wire. In this case the newly generated key Adoption message is
      resent.


2.3.3.  Attributes of Generated Key

   As a result of this message exchange, client comes to know the newly
   generated key's attributes such as key's name, Inception Time and
   Expiry Limit. They are decided by the server and told to the client;
   in particular, however, once the server has decided Expiry Limit and
   returned a response, it should obey the decision as far as it can. In
   other words, they SHOULD NOT change time values for checking Expiry
   Limit in the future without any special reason, such as security
   issue like "Emergency Compulsory Revocation" described in section 8.

   On the other hand, Partial Revocation Time of this generated key is
   not decided based on the request, and not informed to the client. The
   server can determine any value as long as it is between Inception
   Time and Expiry Limit. However, the period from Inception to Partial
   Revocation SHOULD be fixed as the server side's configuration or be
   set the same as the corresponding old key's one.

   Note:
      Even if client sends Key Renewal request though the key described
      in OldName has not been partially revoked yet, server does renewal
      processes.  At the moment when the server 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.3.4.  TKEY RR structure

   TKEY RR for Key Renewal message has the structure given below. In
   principle, format and definition for each field follows [RFC2930].
   Note that each keying scheme sometimes needs different interpretation
   of RDATA field; for detail, see section 2.5.

        Field        Type         Comment
        -------      ------       -------
        NAME         domain       used for a new key, see below
        TYPE         u_int16_t    (defined in [RFC2930])



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


        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    scheme for key agreement
                                   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


     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" specifies which algorithm is used for agreed keying
     material, which is used for identification of the next key.

     "Inception" and "Expiration" are used for the valid period of
     keying material. The meanings differ somewhat according to whether
     the message is request or answer, and its keying scheme.

     "Key Data" has different meanings according to keying schemes.

     "Mode" field stores the value in accordance with the keying method,
     and see section 2.5. Servers and clients supporting TKEY Renewal
     method MUST implement "Diffie-Hellman exchange for key renewal"
     scheme. All other modes are OPTIONAL.

     "Error" is an extended RCODE which includes "PartialRevoke" value
     too. See section 9.

     "Other Data" field has the structure given below.  They describe
     attributes of the key to be renewed.

        in Other Data filed:

          Field          Type     Comment
          -------        ------   -------
          OldNAME        domain   name of the old key
          OldAlgorithm   domain   algorithm of the old key





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


          "OldName" indicates the name of the previous key (usually,
          this is partially revoked key's name that client noticed by
          PartialRevoke answer from server), and "OldAlogirthm"
          indicates its algorithm.


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 that 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 exchange. "Algorithm" is its
     algorithm. "Inception" means the key's Inception Time, and
     "Expiration" means Expiry Limit.

     "Mode" field is the value of "key adoption". See section 9.

     "Other Data" field in Adoption has the same structure as that of
     Renewal request message. "OldName" means the previous old key, and
     "OldAlogirthm" means its algorithm.

   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 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
   present at the server, BADNAME [RFC2845] is given in Error field and
   the error message is returned.

   If the next key exists but it has not been adopted formally yet, the
   server confirms the previous key's existence indicated by the
   "OldName" and "OldAlgorithm" 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,



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


   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 will
   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.  Keying Schemes

   In Renewal message exchanges, there are no limitations as to which
   keying method is actually used. The specification of keying
   algorithms is independent of the general procedure of Renewal that is
   described in section 2.3.

   Now this document specifies three algorithms in this section, but
   other future documents can make extensions defining other methods.


2.5.1.  DH Exchange for Key Renewal

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

   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
      the client's Diffie-Hellman public key [RFC2539].

      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.




Kamite, et. al.                                                [Page 11]