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

bind 源码 最新实现 linux/unix/windows平台

     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.          Expires April 15, 2005                [Page 18]

INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 19]

INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 20]

INTERNET-DRAFT                                              October 2004


10.  Acknowledgements

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


11.  References

11.1.  Normative References

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

11.2.  Informative References

[RFC2104]
     H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
     Authentication", RFC2104, February 1997.















Kamite, et. al.          Expires April 15, 2005                [Page 21]

INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 22]

INTERNET-DRAFT                                              October 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Kamite, et. al.          Expires April 15, 2005                [Page 23]