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

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

DNS Extensions                                              Yuji Kamite
Internet-Draft                                       NTT Communications
Expires: April 15, 2005                                 Masaya Nakayama
                                                The University of Tokyo
                                                       October 14, 2004



                      TKEY Secret Key Renewal Mode
                 draft-ietf-dnsext-tkey-renewal-mode-05


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on April 15, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

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



Kamite, et. al.          Expires April 15, 2005                 [Page 1]

INTERNET-DRAFT                                              October 2004


   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.

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.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
  11.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
    11.1   Normative References . . . . . . . . . . . . . . . . . . . 21
    11.2   Informative References . . . . . . . . . . . . . . . . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
       Intellectual Property and Copyright Statements . . . . . . . . 23







Kamite, et. al.          Expires April 15, 2005                 [Page 2]

INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                 [Page 3]

INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                 [Page 4]

INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                 [Page 5]

INTERNET-DRAFT                                              October 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
   (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.