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

bind 9.3结合mysql数据库

   "<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 for each 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 for key
     "00.client.example.com.server.example.com" was set as follows:
     Inception Time is at 1:00, Expiry Limit is at 21:00.

     (2) At Server, renewal time has been set: Partial Revocation Time
     is at 20:00.




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


     (3) Suppose the present time is 19:55. If Client sends a query
     signed with key "00.client.example.com.server.example.com" to ask
     the IP address of "www.example.com", finally it will get a proper
     answer from Server with valid TSIG (NOERROR).

     (4) At 20:05. Client sends a query to ask the IP address of
     "www2.example.com". It is signed with key
     "00.client.example.com.server.example.com". Server returns an
     answer for the IP address. However, server has begun retuning
     PartialRevoke Error randomely. This answer includes valid TSIG MAC
     signed with "00.client.example.com.server.example.com", and its
     Error Code indicates PartialRevoke. Client understands that the
     current key is partially revoked.

     (5) At 20:06. 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 meaning 20:00)
          Expiration   = (value meaning next day's 16: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 20:00)
          Expiration   = (value meaning next day's 16:00)
          Mode         = (DH exchange for key renewal)
          OldName      = 00.client.example.com.server.example.com.
          OldAlgorithm = hmac-md5-sig-alg.reg.int.



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


     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 next
     day's 15: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 20:07. 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 meaning 20:00)
          Expiration   = (value meaning next day's 16: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 retries to send an original question about
     "www2.example.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 19]

INTERNET-DRAFT                                                 Feb. 2004


     (11) This key is used until next day's 15: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].

   [RFC2104] 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. TKEY Secret Key Renewal provides the method of
   periodical key refreshment.

   In TKEY Secret Key Renewal, clients need to send two requests
   (Renewal and Adoption) and spend time to finish their key renewal
   processes. 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 21:00, Partial Revocation Time at 20:00 and
   Inception Time at 1: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. However, 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 such as Diffie-Hellman Exchanged Keying.


9.  IANA Considerations

   IANA needs to allocate a value for "DH exchange for key renewal",
   "server assignment for key renewal", "resolver assignment 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 20]

INTERNET-DRAFT                                                 Feb. 2004


10.  Acknowledgement

   The authors would like to thank Olafur Gudmundsson, whose helpful
   input and comments contributed greatly to this document.


11.  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 21]

INTERNET-DRAFT                                                 Feb. 2004


Authors' Addresses

   Yuji Kamite
   NTT Communications Corporation
   Tokyo Opera City Tower
   3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
   163-1421, Japan
   EMail: [e-mail]


   Masaya Nakayama
   Information Technology Center, The University of Tokyo
   2-11-16 Yayoi, Bunkyo-ku, Tokyo
   113-8658, Japan
   EMail: [e-mail]




































Kamite, et. al.                                                [Page 22]