rfc2930.txt

bind 9.3结合mysql数据库

   defined:

         Value   Description
         -----   -----------
          0       - no error
          1-15   a non-extended RCODE
          16     BADSIG   (TSIG)
          17     BADKEY   (TSIG)
          18     BADTIME  (TSIG)
          19     BADMODE
          20     BADNAME
          21     BADALG

   When the TKEY Error Field is non-zero in a response to a TKEY query,
   the DNS header RCODE field indicates no error. However, it is
   possible if a TKEY is spontaneously included in a response the TKEY
   RR and DNS header error field could have unrelated non-zero error
   codes.

2.7 The Key Size and Data Fields

   The key data size field is an unsigned 16 bit integer in network
   order which specifies the size of the key exchange data field in
   octets. The meaning of this data depends on the mode.

2.8 The Other Size and Data Fields

   The Other Size and Other Data fields are not used in this
   specification but may be used in future extensions.  The RDLEN field
   MUST equal the length of the RDATA section through the end of Other
   Data or the RR is to be considered malformed and rejected.






Eastlake                    Standards Track                     [Page 6]

RFC 2930                    The DNS TKEY RR               September 2000


3. General TKEY Considerations

   TKEY is a meta-RR that is not stored or cached in the DNS and does
   not appear in zone files.  It supports a variety of modes for the
   establishment and deletion of shared secret keys information between
   DNS resolvers and servers.  The establishment of such a shared key
   requires that state be maintained at both ends and the allocation of
   the resources to maintain such state may require mutual agreement. In
   the absence of willingness to provide such state, servers MUST return
   errors such as NOTIMP or REFUSED for an attempt to use TKEY and
   resolvers are free to ignore any TKEY RRs they receive.

   The shared secret keying material developed by using TKEY is a plain
   octet sequence.  The means by which this shared secret keying
   material, exchanged via TKEY, is actually used in any particular TSIG
   algorithm is algorithm dependent and is defined in connection with
   that algorithm.  For example, see [RFC 2104] for how TKEY agreed
   shared secret keying material is used in the HMAC-MD5 algorithm or
   other HMAC algorithms.

   There MUST NOT be more than one TKEY RR in a DNS query or response.

   Except for GSS-API mode, TKEY responses MUST always have DNS
   transaction authentication to protect the integrity of any keying
   data, error codes, etc.  This authentication MUST use a previously
   established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
   NOT use any key that the response to be verified is itself providing.

   TKEY queries MUST be authenticated for all modes except GSS-API and,
   under some circumstances, server assignment mode.  In particular, if
   the query for a server assigned key is for a key to assert some
   privilege, such as update authority, then the query must be
   authenticated to avoid spoofing.  However, if the key is just to be
   used for transaction security, then spoofing will lead at worst to
   denial of service.  Query authentication SHOULD use an established
   secret (TSIG) key authenticator if available.  Otherwise, it must use
   a public (SIG(0)) key signature.  It MUST NOT use any key that the
   query is itself providing.

   In the absence of required TKEY authentication, a NOTAUTH error MUST
   be returned.

   To avoid replay attacks, it is necessary that a TKEY response or
   query not be valid if replayed on the order of 2**32 second (about
   136 years), or a multiple thereof, later.  To accomplish this, the
   keying material used in any TSIG or SIG(0) RR that authenticates a
   TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds




Eastlake                    Standards Track                     [Page 7]

RFC 2930                    The DNS TKEY RR               September 2000


   (about 68 years).  Thus, on attempted replay, the authenticating TSIG
   or SIG(0) RR will not be verifiable due to key expiration and the
   replay will fail.

4. Exchange via Resolver Query

   One method for a resolver and a server to agree about shared secret
   keying material for use in TSIG is through DNS requests from the
   resolver which are syntactically DNS queries for type TKEY.  Such
   queries MUST be accompanied by a TKEY RR in the additional
   information section to indicate the mode in use and accompanied by
   other information where required.

   Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
   ignore the recursive header bit in TKEY queries they receive.

4.1 Query for Diffie-Hellman Exchanged Keying

   Diffie-Hellman (DH) key exchange is a means whereby two parties can
   derive some shared secret information without requiring any secrecy
   of the messages they exchange [Schneier].  Provisions have been made
   for the storage of DH public keys in the DNS [RFC 2539].

   A resolver sends a query for type TKEY accompanied by a TKEY RR in
   the additional information section specifying the Diffie-Hellman mode
   and accompanied by a KEY RR also in the additional information
   section specifying a resolver Diffie-Hellman key.  The TKEY RR
   algorithm field is set to the authentication algorithm the resolver
   plans to use. The "key data" provided in the TKEY is used as a random
   [RFC 1750] nonce to avoid always deriving the same keying material
   for the same pair of DH KEYs.

   The server response contains a TKEY in its answer section with the
   Diffie-Hellman mode. The "key data" provided in this TKEY is used as
   an additional nonce to avoid always deriving the same keying material
   for the same pair of DH KEYs. If the TKEY error field is non-zero,
   the query failed for the reason given. FORMERR is given if the query
   included no DH KEY and BADKEY is given if the query included an
   incompatible DH KEY.

   If the TKEY error field is zero, the resolver supplied Diffie-Hellman
   KEY RR SHOULD be echoed in the additional information section and a
   server Diffie-Hellman KEY RR will also be present in the answer
   section of the response.  Both parties can then calculate the same
   shared secret quantity from the pair of Diffie-Hellman (DH) keys used
   [Schneier] (provided these DH keys use the same generator and
   modulus) and the data in the TKEY RRs.  The TKEY RR data is mixed
   with the DH result as follows:



Eastlake                    Standards Track                     [Page 8]

RFC 2930                    The DNS TKEY RR               September 2000


      keying material =
           XOR ( DH value, MD5 ( query data | DH value ) |
                           MD5 ( server data | DH value ) )

   Where XOR is an exclusive-OR operation and "|" is byte-stream
   concatenation.  The shorter of the two operands to XOR is byte-wise
   left justified and padded with zero-valued bytes to match the length
   of the other operand.  "DH value" is the Diffie-Hellman value derived
   from the KEY RRs. Query data and server data are the values sent in
   the TKEY RR data fields.  These "query data" and "server data" nonces
   are suffixed by the DH value, digested by MD5, the results
   concatenated, and then XORed with the DH value.

   The inception and expiry times in the query TKEY RR are those
   requested for the keying material.  The inception and expiry times in
   the response TKEY RR are the maximum period the server will consider
   the keying material valid.  Servers may pre-expire keys so this is
   not a guarantee.

4.2 Query for TKEY Deletion

   Keys established via TKEY can be treated as soft state.  Since DNS
   transactions are originated by the resolver, the resolver can simply
   toss keys, although it may have to go through another key exchange if
   it later needs one.  Similarly, the server can discard keys although
   that will result in an error on receiving a query with a TSIG using
   the discarded key.

   To avoid attempted reliance in requests on keys no longer in effect,
   servers MUST implement key deletion whereby the server "discards" a
   key on receipt from a resolver of an authenticated delete request for
   a TKEY RR with the key's name.  If the server has no record of a key
   with that name, it returns BADNAME.

   Key deletion TKEY queries MUST be authenticated.  This authentication
   MAY be a TSIG RR using the key to be deleted.

   For querier assigned and Diffie-Hellman keys, the server MUST truly
   "discard" all active state associated with the key.  For server
   assigned keys, the server MAY simply mark the key as no longer
   retained by the client and may re-send it in response to a future
   query for server assigned keying material.









Eastlake                    Standards Track                     [Page 9]

RFC 2930                    The DNS TKEY RR               September 2000


4.3 Query for GSS-API Establishment

   This mode is described in a separate document under preparation which
   should be seen for the full description.  Basically the resolver and
   server can exchange queries and responses for type TKEY with a TKEY
   RR specifying the GSS-API mode in the additional information section
   and a GSS-API token in the key data portion of the TKEY RR.

   Any issues of possible encryption of parts the GSS-API token data
   being transmitted are handled by the GSS-API level.  In addition, the
   GSS-API level provides its own authentication so that this mode of
   TKEY query and response MAY be, but do not need to be, authenticated
   with TSIG RR or SIG(0) RR [RFC 2931].

   The inception and expiry times in a GSS-API mode TKEY RR are ignored.

4.4 Query for Server Assigned Keying

   Optionally, the server can assign keying for the resolver.  It is
   sent to the resolver encrypted under a resolver public key.  See
   section 6 for description of encryption methods.

   A resolver sends a query for type TKEY accompanied by a TKEY RR
   specifying the "server assignment" mode and a resolver KEY RR to be
   used in encrypting the response, both in the additional information
   section. The TKEY algorithm field is set to the authentication
   algorithm the resolver plans to use.  It is RECOMMENDED that any "key
   data" provided in the query TKEY RR by the resolver be strongly mixed
   by the server with server generated randomness [RFC 1750] to derive
   the keying material to be used.  The KEY RR that appears in the query
   need not be accompanied by a SIG(KEY) RR.  If the query is
   authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
   and that authentication is verified, then any SIG(KEY) provided in
   the query SHOULD be ignored.  The KEY RR in such a query SHOULD have
   a name that corresponds to the resolver but it is only essential that
   it be a public key for which the resolver has the corresponding
   private key so it can decrypt the response data.

   The server response contains a TKEY RR in its answer section with the
   server assigned mode and echoes the KEY RR provided in the query in
   its additional information section.

   If the response TKEY error field is zero, the key data portion of the
   response TKEY RR will be the server assigned keying data encrypted
   under the public key in the resolver provided KEY RR.  In this case,
   the owner name of the answer TKEY RR will be the server assigned name
   of the key.




Eastlake                    Standards Track                    [Page 10]

RFC 2930                    The DNS TKEY RR               September 2000


   If the error field of the response TKEY is non-zero, the query failed
   for the reason given.  FORMERR is given if the query specified no
   encryption key.

   The inception and expiry times in the query TKEY RR are those
   requested for the keying material.  The inception and expiry times in
   the response TKEY are the maximum period the server will consider the
   keying material valid.  Servers may pre-expire keys so this is not a
   guarantee.

   The resolver KEY RR MUST be authenticated, through the authentication
   of this query with a TSIG or SIG(0) or the signing of the resolver
   KEY with a SIG(KEY).  Otherwise, an attacker can forge a resolver KEY
   for which they know the private key, and thereby the attacker could
   obtain a valid shared secret key from the server.

4.5 Query for Resolver Assigned Keying

   Optionally, a server can accept resolver assigned keys.  The keying
   material MUST be encrypted under a server key for protection in
   transmission as described in Section 6.

   The resolver sends a TKEY query with a TKEY RR that specifies the
   encrypted keying material and a KEY RR specifying the server public
   key used to encrypt the data, both in the additional information
   section.  The name of the key and the keying data are completely
   controlled by the sending resolver so a globally unique key name
   SHOULD be used.  The KEY RR used MUST be one for which the server has
   the corresponding private key, or it will not be able to decrypt the
   keying material and will return a FORMERR. It is also important that
   no untrusted party (preferably no other party than the server) has
   the private key corresponding to the KEY RR because, if they do, they
   can capture the messages to the server, learn the shared secret, and
   spoof valid TSIGs.