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

bind-3.2.

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

     (2) At Server, a time value about renewal timing has been set too:
     Partial Revocation Time is at 8:00.

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

     (4) At 9:00. Client sends a query signed with key
     "00.client.example.com.server.example.com" to ask the IP address of
     "www.otherdomain.com". But it will not get a proper answer from
     Server. The response does not have any IP address information about
     "www.otherdomain.com". Instead, it includes valid TSIG MAC signed
     with "00.client.example.com.server.example.com", and its Error Code
     indicates PartialRevoke.



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


     (5) At 9:01. 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 which means 8:55)
          Expiration   = (value which means 14: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 8:55)
          Expiration   = (value meaning 14:00)
          Mode         = (DH exchange for key renewal)
          OldName      = 00.client.example.com.server.example.com.
          OldAlgorithm = hmac-md5-sig-alg.reg.int.
      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
     11: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.





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


     (8) At 9:02. 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 which means 8:55)
          Expiration   = (value which means 14: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 will retry to send an original question about
     "www.otherdomain.com". It is signed with the adopted key
     "01.client.example.com.server.example.com", so Server authenticates
     it and returns an answer.

     (11) This key is used until 11: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



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


   periodical key refreshment.

   TKEY Secret Key Renewal forbids clients to send queries as long as
   they do not change old keys. This means that when keys become old,
   clients must spend rather lots of time to get answers they wanted
   originally because at first they must send key Renewal requests. 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 15:00, Partial Revocation Time at 12:00 and
   Inception Time at 10: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. But, 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.


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





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


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


Authors' Addresses

   Yuji Kamite
   NTT Communications Corporation
   Innovative IP Architecture Center,
   Tokyo Opera City Tower 21F,
   20-2, 3-chome, Nishi-Shinjuku, Shinjuku-ku,
   Tokyo, 163-1421, Japan.
   EMail: [e-mail]


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


































Kamite, et. al.                                                [Page 22]