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

bind-3.2.

   specification.

   If server receives other types of query signed with the partially
   revoked key and the corresponding MAC is verified, then server SHOULD
   return TSIG error message for response whose error code is
   "PartialRevoke" (See section 9.). However, if it is for TKEY key
   deletion request ([RFC2930] 4.2), server MAY process usual deletion
   operation defined therein.

   PartialRevoke error messages have the role to inform clients of the
   keys' partial revocation and urge them to send TKEY Renewal requests.
   These error responses MUST be signed with those partial revoked keys
   if the queries are signed with them. They are sent only when the keys
   used for queries' TSIG are found to be partially revoked. If the MAC
   of TSIG cannot be verified with the partially revoked keys, servers
   MUST NOT return PartialRevoke error with MAC, but should return
   another error such as "BADSIG" without MAC; in other words, a server
   informs its key's partial revocation only when the MAC in the
   received query is valid.


2.3.  Key Renewal Message Exchange

   If a client has received a PartialRevoke error and authenticated the
   response based on TSIG MAC, it sends a TKEY query for Key Renewal (in



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


   this document, we call it Renewal request, too.) to the server. The
   request MUST be signed with TSIG or SIG(0) [RFC2931] for
   authentication. If TSIG is selected, the client can sign it with the
   partial revoked key.

   Key Renewal can use one of several keying methods which is indicated
   in "Mode" field of TKEY RR, and its message structure is dependent on
   that method.

   The server which has received Key Renewal request first tries to
   verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
   verified with the partially revoked key, the request MUST be
   authenticated.

   After authentication, server must check existing old key's validity.
   If the partially revoked key indicated in the request TKEY's OldName
   and OldAlgorithm field (See section 2.3.1.) does not really exist at
   the server, "BADKEY" [RFC2845] is given in Error field for response.
   If any other error happens, server returns appropriate error messages
   following the specification described in section 2.5. If there are no
   errors, server returns a Key Renewal answer. This answer MUST be
   signed with TSIG or SIG(0) for authentication.

   When this answer is successfully returned and no error is detected by
   client, a new shared secret can be established. The details of
   concrete keying procedure are given in the section 2.5.

   As a result of this message exchange, client comes to know the newly
   generated key's attributes such as key's name, Inception Time and
   Expiry Limit. They are decided finally by the server, and are told to
   the client; in particular, however, once the server has decided
   Expiry Limit and returned a response, it should obey the decision as
   far as it can. In other words, they SHOULD NOT change time values for
   checking Expiry Limit in the future without any special reason, such
   as security issue like "Emergency Compulsory Revocation" described in
   section 8.

   On the other hand, Partial Revocation Time of this generated key is
   not decided based on the request, and not informed to the client. The
   server can determine any value as long as it is between Inception
   Time and Expiry Limit. However, it is recommended that the period
   from Inception to Partial Revocation should be fixed as the server
   side's configuration or should be set the same as the corresponding
   old key's one.

   Note:
      Even after the response is returned to client, possibly server
      sometimes receives another Renewal TKEY request whose OldName



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


      indicates the same partial revoked key. Mostly such messages
      originate in client's resending or rollback because of some kinds
      of errors. In this case, the server processes keying again and
      MUST replace the associated secret with the newest produced
      secret. The secret key produced before comes to be invalid and
      should be removed from memory; this process is called secret
      overwrite. Moreover, This regenerated key's name MUST always be
      different from the one which it overwrites for secret key's
      uniqueness and distinction. See section 6, too.

      Even if client sends Key Renewal request though the key described
      in OldName has not been partially revoked yet, server must do
      renewal processes.  But at the moment when the server accepts such
      requests with valid authentication, it MUST forcibly consider the
      key is already partially revoked, that is, the key's Partial
      Revocation Time must be changed into the present time (i.e., the
      time when the server receives the request).

2.3.1.  TKEY RR structure for Key Renewal

   TKEY RR for Key Renewal message has the structure given below. In
   principle, format and definition for each field follows [RFC2930].
   Note that each keying scheme sometimes needs different interpretation
   of RDATA field; for detail, see section 2.5.


        Field        Type         Comment
        -------      ------       -------
        NAME         domain       used for a new key, see below
        TYPE         u_int16_t    (defined in [RFC2930])
        CLASS        u_int16_t    (defined in [RFC2930])
        TTL          u_int32_t    (defined in [RFC2930])
        RDLEN        u_int16_t    (defined in [RFC2930])
        RDATA:
         Algorithm:   domain       algorithm for a new key
         Inception:   u_int32_t    about the keying material
         Expiration:  u_int32_t    about the keying material
         Mode:        u_int16_t    scheme for key agreement
                                   see section 9.
         Error:       u_int16_t    see description below
         Key Size:    u_int16_t    see description below
         Key Data:    octet-stream
         Other Size:  u_int16_t    (defined in [RFC2930])
                                   size of other data
         Other Data:               newly defined: see description below






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


     For "NAME" field, both non-root and root name are allowed. It may
     be used for a new key's name in the same manner as [RFC2930] 2.1.

     "Algorithm" specifies which algorithm is used for agreed keying
     material, which is used for identification of the next key.

     "Inception" and "Expiration" are used for the valid period of
     keying material. The meanings differ somewhat according to whether
     the message is request or answer, and its keying scheme.

     "Key Data" has different meanings according to keying schemes.

     "Mode" field stores the value in accordance with the keying method,
     and see section 2.5. Servers and clients supporting TKEY Renewal
     method MUST implement "Diffie-Hellman exchange for key renewal"
     scheme. All other modes are OPTIONAL.

     "Error" is an extended RCODE which includes "PartialRevoke" value
     too. See section 9.

     "Other Data" field has the structure given below.  They describe
     attributes of the key to be renewed.

        in Other Data filed:

          Field          Type     Comment
          -------        ------   -------
          OldNAME        domain   name of the old key
          OldAlgorithm   domain   algorithm of the old key


          "OldName" indicates the name of the previous key (usually,
          this is partially revoked key's name that client noticed by
          PartialRevoke answer from server), and "OldAlogirthm"
          indicates its algorithm.


2.4.  Key Adoption

2.4.1.  Query for Key Adoption

   After receiving a TKEY Renewal answer, the client gets the same
   secret as the server. Then, it sends a TKEY Adoption request. The
   request's question section's QNAME field is the same as the NAME
   filed of TKEY written below. In additional section, there is one TKEY
   RR that has the structure and values described below.





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


     "NAME" field is the new key's name to be adopted which was already
     generated by Renewal message exchange. "Algorithm" is its algo-
     rithm. "Inception" means the key's Inception Time, and "Expiration"
     means Expiry Limit.

     "Mode" field is the value of "key adoption". See section 9.

     "Other Data" field in Adoption has the same structure as that of
     Renewal request message. "OldName" means the previous old key, and
     "OldAlogirthm" means its algorithm.

   Key Adoption request MUST be signed with TSIG or SIG(0) for
   authentication. The client can sign TSIG with the previous key. Note
   that until Adoption is finished, the new key is treated as invalid,
   thus it cannot be used for authentication immediately.


2.4.2.  Response for Key Adoption

   The server which has received Adoption request, it verifies TSIG or
   SIG(0) accompanying it. If the TSIG is signed with the partially
   revoked key and can be verified, the message MUST be authenticated.

   If the next new key indicated by the request TKEY's "NAME" is not
   really present at the server, BADNAME [RFC2845] is given in Error
   field and the error message is returned.

   If the next key really exists and it has not been adopted formally
   yet, the server confirms the previous key's existence indicated by
   the "OldName" and "OldAlgorithm" field. If it succeeds, the server
   executes Adoption of the next key and Revocation of the previous key.
   Response message duplicates the request's TKEY RR with NOERROR,
   including "OldName" and "OldAlgorithm" that indicate the revoked key.

   If the next key exists but it is already adopted, the server returns
   a response message regardless of the substance of the request TKEY's
   "OldName". In this response, Response TKEY RR has the same data as
   the request's one except as to its "Other Data" that is changed into
   null (i.e., "Other Size" is zero), which is intended for telling the
   client that the previous key name was ignored, and the new key is
   already available.

   Client sometimes has to retry Adoption request. Suppose the client
   sent request signed with the partially revoked key, but its response
   did not return successfully (e.g., due to the drop of UDP packet).
   Client will probably retry Adoption request; however, the request
   will be refused in the form of TSIG "BADKEY" error because the
   previous key was already revoked. In this case, client should



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


   retransmit Adoption request signed with the next key, and expect a
   response which has null "Other Data" for confirming the completion of
   renewal.


2.5.  Keying Schemes

   In Renewal message exchanges, there are no limitations as to which
   keying method is actually used. The specification of keying
   algorithms is independent of the general procedure of Renewal that is
   described in section 2.3.

   Now this document specifies three algorithms in this section, but
   other future documents can make extensions defining other methods.


2.5.1.  DH Exchange for Key Renewal

   This scheme is defined as an extended method of [RFC2930] 4.1. This
   specification only describes the difference from it and special
   notice; assume that all other points, such as keying material
   computation, are the exactly same as the specification of [RFC2930]
   4.1.

   Query
      In Renewal request for type TKEY with this mode, there is one TKEY
      RR and one KEY RR in the additional information section. KEY RR is
      the client's Diffie-Hellman public key [RFC2539].

      QNAME in question section is the same as that of "NAME" field in
      TKEY RR, i.e., it means the requested new key's name.

      TKEY "Mode" field stores the value of "DH exchange for key
      renewal". See section 9.

      TKEY "Inception" and "Expiration" are those requested for the
      keying material, that is, requested usage period of a new key.

      TKEY "Key Data" is used as a random, following [RFC2930] 4.1.

   Response
      The server which received this request first verifies the TSIG or
      SIG(0). After authentication, the old key's existence validity is
      checked, following section 2.3. If any incompatible DH key is
      found in the request, "BADKEY" [RFC2845] is given in Error field
      for response. "FORMERR" is given if the query included no DH KEY.

      If there are no errors, the server processes a response according



Kamite, et. al.                                                [Page 11]