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

bind 9.3结合mysql数据库

DNSEXT Working Group                                        Yuji Kamite
INTERNET-DRAFT                                       NTT Communications
<draft-ietf-dnsext-tkey-renewal-mode-04.txt>            Masaya Nakayama
Expires: Aug. 2004                              The University of Tokyo
                                                              Feb. 2004




                      TKEY Secret Key Renewal Mode


Status of this Memo

  This document is an Internet-Draft and is in full conformance with all
  provisions of Section 10 of RFC2026.

  Internet-Drafts are working documents of the Internet Engineering Task
  Force (IETF), its areas, and its working groups.  Note that other
  groups may also distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as ``work in progress.''

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html


Abstract

   This document defines a new mode in TKEY and proposes an atomic
   method for changing secret keys used for TSIG periodically.
   Originally, TKEY provides methods of setting up shared secrets other
   than manual exchange, but it cannot control timing of key renewal
   very well though it can add or delete shared keys separately. This
   proposal is a systematical key renewal procedure intended for
   preventing signing DNS messages with old and non-safe keys
   permanently.








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


                           Table of Contents


1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1  Defined Words . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.2  New Format and Assigned Numbers . . . . . . . . . . . . . . .   4
  1.3  Overview of Secret Key Renewal Mode . . . . . . . . . . . . .   4
2  Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . .   5
  2.1  Key Usage Time Check  . . . . . . . . . . . . . . . . . . . .   5
  2.2  Partial Revocation  . . . . . . . . . . . . . . . . . . . . .   6
  2.3  Key Renewal Message Exchange  . . . . . . . . . . . . . . . .   7
    2.3.1  Query for Key Renewal . . . . . . . . . . . . . . . . . .   7
    2.3.2  Response for Key Renewal  . . . . . . . . . . . . . . . .   7
    2.3.3  Attributes of Generated Key . . . . . . . . . . . . . . .   8
    2.3.4  TKEY RR structure . . . . . . . . . . . . . . . . . . . .   8
  2.4  Key Adoption  . . . . . . . . . . . . . . . . . . . . . . . .  10
    2.4.1  Query for Key Adoption  . . . . . . . . . . . . . . . . .  10
    2.4.2  Response for Key Adoption . . . . . . . . . . . . . . . .  10
  2.5  Keying Schemes  . . . . . . . . . . . . . . . . . . . . . . .  11
    2.5.1  DH Exchange for Key Renewal . . . . . . . . . . . . . . .  11
    2.5.2  Server Assigned Keying for Key Renewal  . . . . . . . . .  12
    2.5.3  Resolver Assigned Keying for Key Renewal  . . . . . . . .  13
  2.6  Considerations about Non-compliant Hosts  . . . . . . . . . .  14
3  Secret Storage  . . . . . . . . . . . . . . . . . . . . . . . . .  15
4  Compulsory Key Revocation . . . . . . . . . . . . . . . . . . . .  15
  4.1  Compulsory Key Revocation by Server . . . . . . . . . . . . .  15
  4.2  Authentication Methods Considerations . . . . . . . . . . . .  15
5  Special Considerations for Two Servers' Case  . . . . . . . . . .  16
  5.1  To Cope with Collisions of Renewal Requests . . . . . . . . .  16
6  Key Name Considerations . . . . . . . . . . . . . . . . . . . . .  17
7  Example Usage of Secret Key Renewal Mode  . . . . . . . . . . . .  17
8  Security Considerations . . . . . . . . . . . . . . . . . . . . .  20
9  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . .  20
10 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . .  21
11 References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . .  22















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


1.  Introduction

   TSIG [RFC2845] provides DNS message integrity and the
   request/transaction authentication by means of message authentication
   codes (MAC). TSIG is a practical solution in view of calculation
   speed and availability. However, TSIG does not have exchanging
   mechanism of shared secret keys between server and resolver, and
   administrators might have to exchange secret keys manually. TKEY
   [RFC2930] is introduced to solve such problem and it can exchange
   secrets for TSIG via networks.

   In various modes of TKEY, a server and a resolver can add or delete a
   secret key be means of TKEY message exchange. However, the existing
   TKEY does not care fully about the management of keys which became
   too old, or dangerous after long time usage.

   It is ideal that the number of secret which a pair of hosts share
   should be limited only one, because having too many keys for the same
   purpose might not only be a burden to resolvers for managing and
   distinguishing according to servers to query, but also does not seem
   to be safe in terms of storage and protection against attackers.
   Moreover, perhaps holding old keys long time might give attackers
   chances to compromise by scrupulous calculation.

   Therefore, when a new shared secret is established by TKEY, the
   previous old secret should be revoked immediately. To accomplish
   this, DNS servers must support a protocol for key renewal. This
   document specifies procedure to refresh secret keys between two hosts
   which is defined within the framework of TKEY, and it is called "TKEY
   Secret Key Renewal Mode".

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].


1.1.  Defined Words

   * Inception Time: Beginning of the shared secret key lifetime. This
   value is determined when the key is generated.

   * Expiry Limit: Time limit of the key's validity. This value is
   determined when a new key is generated. After Expiry Limit, server
   and client (resolver) must not authenticate TSIG signed with the key.
   Therefore, Renewal to the next key should be carried out before
   Expiry Limit.

   * Partial Revocation Time: Time when server judges the key is too old



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


   and must be updated. It must be between Inception Time and Expiry
   Limit.  This value is determined by server freely following its
   security policy. e.g., If the time from Inception to Partial
   Revocation is short, renewal will be carried out more often, which
   might be safer.

   * Revocation Time: Time when the key becomes invalid and can be
   removed. This value is not determined in advance because it is the
   actual time when revocation is completed.

   * Adoption Time: Time when the new key is adopted as the next key
   formally. After Adoption, the key is valid and server and client can
   generate or verify TSIG making use of it. Adoption Time also means
   the time when it becomes possible to remove the previous key, so
   Revocation and Adoption are usually done at the same time.


                  Partial
    Inception     Revocation    Revocation         Expiry Limit
     |                |              |             |
     |----------------|- - - - - - >>|- (revoked) -|
     |                |              |             |
    previous key      |      |       |
                             |- - - -|-------------------->> time
                             |       |               new key
                         Inception   Adoption


1.2.  New Format and Assigned Numbers

   TSIG
         ERROR = (PartialRevoke), TBD

   TKEY
         Mode  = (server assignment for key renewal), TBD
         Mode  = (Diffie-Hellman exchange for key renewal), TBD
         Mode  = (resolver assignment for key renewal), TBD
         Mode  = (key adoption), TBD


1.3.  Overview of Secret Key Renewal Mode

   When a server receives a query from a client signed with a TSIG key,
   It always checks if the present time is within the range of usage
   duration it considers safe. If it is judged that the key is too old,
   i.e., after Partial Revocation Time, the server comes to be in
   Partial Revocation state about the key, and this key is called
   partially revoked.



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


   In this state, if a client sends a normal query (e.g., question about
   A RR) other than TKEY Renewal request with TSIG signed with the old
   key, the server returns an error message to notify that the time to
   renew has come. This is called "PartialRevoke" error message. It is
   server's choice whether it returns PartialRevoke or not. If and only
   if the server is ready for changing its own key, it decides to return
   PartialRevoke.

   The client which got this error is able to notice that it is
   necessary to refresh the secret. To make a new shared secret, it
   sends a TKEY Renewal request, in which several keying methods are
   available. It can make use of TSIG authentication signed with the
   partially revoked key mentioned above.

   After new secret establishment, the client sends a TKEY Adoption
   request for renewal confirmation. This can also be authenticated with
   the partially revoked key. If this is admitted by the server, the new
   key is formally adopted, and at the same time the corresponding old
   secret is invalidated. Then the client can send the first query again
   signed with the new key.

   Key renewal procedure is executed based on two-phase commit
   mechanism. The first phase is the TKEY Renewal request and its
   response, which means preparatory confirmation for key update. The
   second phase is Adoption request and its response. If the server gets
   request and client receives the response successfully, they can
   finish renewal process. If any error happens and renewal process
   fails during these phases, client should roll back to the beginning
   of the first phase, and send TKEY Renewal request again. This
   rollback can be done until the Expiry Limit of the key.


2.  Shared Secret Key Renewal

   Suppose a server and a client agree to change their TSIG keys
   periodically. Key renewal procedure is defined between two hosts.

2.1.  Key Usage Time Check

   Whenever a server receives a query with TSIG and can find a key that
   is used for signing it, the server checks its Inception Time, Partial
   Revocation Time and Expiry Limit (this information is usually
   memorized by the server).

   When the present time is before Inception Time, the server MUST NOT
   verify TSIG with the key, and server acts the same way as when the
   key used by the client is not recognized. It follows [RFC2845] 4.5.1.




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


   When the present time is equal to Inception Time, or between
   Inception Time and Partial Revocation Time, the behavior of the
   server is the same as when a valid key is found. It follows [RFC2845]
   4.5.2 and 4.5.3.

   When the present time is the same as the Partial Revocation Time, or
   between the Partial Revocation Time and Expiry Limit, the server
   comes to be in Partial Revocation state about the TSIG key and
   behaves according to the next section.

   When the present time is the same as the Expiry Time or after it, the
   server MUST NOT verify TSIG with the key, and returns error messages
   in the same way as when the key used by the client is not recognized.
   It follows [RFC2845] 4.5.1.


2.2.  Partial Revocation

   In Partial Revocation state, we say the server has partially revoked
   the key and the key has become a "partially revoked key".

   If server has received a query signed with the partially revoked key
   for TKEY Renewal request (See section 2.3.) or Key Adoption request