[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

DNSSEC Working Group                                                TKEY
INTERNET-DRAFT                                             February 1998
                                                     Expires August 1998



               Secret Key Establishment for DNS (TKEY RR)
               ------ --- ------------- --- --- ----- ---

                         Donald E. Eastlake 3rd



Status of This Document

   This draft, file name draft-ietf-dnssec-tkey-00.txt, is intended to
   be become a Proposed Standard RFC.  Distribution of this document is
   unlimited. Comments should be sent to the DNS security mailing list
   <dns-security@tis.com> or to the author.

   This document is an Internet-Draft.  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.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
   ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
   munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).



















Donald E. Eastlake, 3rd                                         [Page 1]


INTERNET-DRAFT                                           The DNS TKEY RR


Abstract

   [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and
   securing Domain Name System (DNS) queries and responses using shared
   secret keys via the TSIG resource record (RR).  However, it provides
   no mechanism for setting up such keys other than manual exchange.
   This document describes a TKEY RR that can be used in a number of
   different modes to establish shared secret keys between a DNS
   resolver and server.



Acknowledgments

   The substantial comments and ideas of the following persons (listed
   in alphabetic order) have been incorporated herein and are gratefully
   acknowledged:

             Olafur Gudmundsson <ogud@tis.com>

             Stuart Kwan <skwan@microsoft.com>































Donald E. Eastlake, 3rd                                         [Page 2]


INTERNET-DRAFT                                           The DNS TKEY RR


Table of Contents

      Status of This Document....................................1

      Abstract...................................................2
      Acknowledgments............................................2

      Table of Contents..........................................3

      1. Introduction............................................4
      1.1 General Principles.....................................4
      1.2 Overview of Contents...................................5

      2. The TKEY Resource Record................................6

      3. Exchange via Resolver Query.............................8
      3.1 Query for Server Assigned Keying.......................9
      3.2 Query for Diffie-Hellman Exchanged Keying..............9
      3.3 Query for GSS-API Established.........................10

      4. Spontaneous Server Inclusion...........................11
      4.1 Spontaneous Server Assigned Keying....................11
      4.2 Spontaneous Diffie-Hellman Keying.....................11
      4.3 Spontaneous GSS-API Exchange..........................11
      4.4 Spontaneous Key Deletion..............................12

      5. TKEY Dynamic Update Requests...........................13
      5.1 Exchange via TKEY 'Add'...............................13
      5.2 TKEY Deletion.........................................13

      6. Methods of Encryption..................................14
      7. Security Considerations................................14

      References................................................15

      Author's Address..........................................16
      Expiration and File Name..................................16















Donald E. Eastlake, 3rd                                         [Page 3]


INTERNET-DRAFT                                           The DNS TKEY RR


1. Introduction

   The Domain Name System (DNS) is a hierarchical, distributed, highly
   available database used for mapping between domain names and
   addresses, for email routing, and for other information [RFC 1034,
   1035].  It has been extended to provide for public key security and
   dynamic update [RFCs 2065, 2136, 2137].

   [draft-ietf-dnsind-tsig-*.txt] provides a means of more efficiently
   authenticating and securing DNS messages using shared secret keys via
   the TSIG resource record (RR) but provides no mechanism for setting
   up such keys other than manual exchange. This document describes a
   TKEY RR that can be used in a number of different modes to establish
   such shared secret keys between a DNS resolver and server.



1.1 General Principles

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

   In all cases herein, the term "resolver" includes that part of a
   server which makes full and partial zone transfer queries as well as
   other queries.

   Servers are not required to implement any particular mode or modes of
   the defined modes of TKEY shared secret key establishment or deletion
   and may return errors for any they do not support.  Based on
   experience, more modes may be added or some modes described herein
   may be deprecated.

   The means by which the 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.  [But
   should probably define for HMAC-MD5 as an example in this draft...]

   It should be noted that this keying material and TSIGs that use it
   are associated with DNS hosts.  They are not tied to zones.  They may
   be used to authenticate queries and responses but they do not provide
   zone stored DNS data origin authentication [RFC 2065].

   Two modes of TKEY, the server assigned and resolver assigned modes,


Donald E. Eastlake, 3rd                                         [Page 4]


INTERNET-DRAFT                                           The DNS TKEY RR


   perform encryption which may effect their export status from some
   countries.  All other aspects of DNS security, including the SIG,
   KEY, NXT, and TSIG RRs and all other defined modes of TKEY perform
   authentication (signatures and signature verification) only.



1.2 Overview of Contents

   Section 2 below specifies the TKEY resource record (RR) and provides
   a high level description of its consiituent fields.

   Section 3 discusses key exchange via queries for type TKEY.  This is
   applicable to the server assigned, Diffie-Hellman exchange, and GSS-
   API establishment modes.

   Section 4 discusses spontaneous inclusion of TKEY RRs in responses by
   servers.  This is application to key deletion and to server assigned
   and Diffie-Hellman exchange key establishment.

   Section 5 discusses use of dynamic update requests for type TKEY.
   This supports optional key exchange via resolver update request,
   which is applicable to key deletion and to the resolver assigned
   mode.

   Section 6 describes encryption methods for transmitting secret key
   information.

   Finally, Section 7 touches on some security considerations.























Donald E. Eastlake, 3rd                                         [Page 5]


INTERNET-DRAFT                                           The DNS TKEY RR


2. The TKEY Resource Record

   The TKEY resource record (RR) has the structure given below.  Its RR
   type code is 249.

      Field       Type         Comment
      -----       ----         -------

      NAME         domain      see description below
      TTYPE        u_int16_t   TKEY
      CLASS        u_int16_t   ignored, should be zero
      TTL          u_int32_t   always zero
      RDLEN        u_int16_t   size of RDATA
      RDATA: Algorithhm:  domain
       Inception:   u_int32_t
       Expiration:  u_int32_t Mode:        u_int16_t
       Error:       u_int16_t
       Key Size:    u_int16_t
       Key Data:    octet-stream
       Other Size:  u_int16_t
       Other Data:  octet-stream  undefined by this protocol

   The Name field's meaning differs somewhat with mode and context as
   explained in subsequent sections.

   The TTL field SHOULD always be zero to be sure that older DNS
   implementations do not cache TKEY RRs.

   The algorithm name is a domain name with the same meaning as in
   [draft-ietf-dnsind-tsig-*.txt].  The algorithm determines how the
   secret keying material exchanged using the TKEY RR is actually used
   to derive the algorithm specific key that is used.

   The inception time and expiration time are in number of seconds since
   the beginning of 1 January 1970 GMT ignoring leap seconds. In
   messages from a DNS resolver to a server where these fields are
   meaningful, they are the requested validity interval for the keying
   material. In messages from a server to a resolver where these fields
   are meaningful, they specify that validity interval.

   The mode field specifies the general scheme for key agreement.  Note
   that implementation of TKEY as a whole and of any particular mode is
   optional. The following values of the Mode octet are defined or
   reserved:








Donald E. Eastlake, 3rd                                         [Page 6]


INTERNET-DRAFT                                           The DNS TKEY RR


          Value    Description
          -----    -----------
           0        - reserved
           1       server/responder assignment
           2       Diffie-Hellman exchange
           3       GSS-API negotiation
           4       resolver/querier assignment
           5       key deletion
          6-65534   - available for IANA assignment
          65535     -reserved

   The error code field is an extended RCODE.  The following values are
   defined:
          Value   Description
          -----   -----------
           0       - no error
           1-15   a DNS RCODE
           16     BADSIG
           17     BADKEY
           18     BADTIME
           19     BADMODE other   - available for IANA assignment
           65535   - reserved

   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 the key exchange data depends on the mode.

   The other data size and data fields are not used.  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.






















Donald E. Eastlake, 3rd                                         [Page 7]


INTERNET-DRAFT                                           The DNS TKEY RR


3. Exchange via Resolver Query

   The most common method for a resolver and a server to establish a
   shared secret key for use in TSIG is through queries from the
   resolver for type TKEY.  Such queries MUST either be accompanied by
   one or more TKEY RRs in the additional information section to
   indicate the mode(s) in use and other information where required or
   the resolver and server must have a prior agreement that supplies any
   information that would otherwise have had to be conveyed by TKEY
   RR(s) in the query.

   For TKEY(s) appearing in a query, The TKEY RR name SHOULD be a domain
   locally unique at the resolver, less than 128 octets long, and
   meaningful to the resolver to distinguish keys and/or key agreement
   sessions.  (For resolvers not wishing to make this use of the name,
   it may be specified as root to minimize length.) For TKEY(s)
   appearing in a response to a query, it SHOULD be a globally unique
   server assigned domain.  If the TKEY in a response is the result of a
   query containing a TKEY with a non-root name, that query TKEY name
   SHOULD be incorporated as the prefix of the response TKEY name.

   Type TKEY queries SHOULD NOT be recursive and any accompanying TKEY
   RRs should have a zero TTL.

   For every mode defined below, the inception and expiration times in
   the query TKEY are set to the time interval for which the resolver
   wishes the requested key to be valid and they are set in a successful
   response to the actual time interval during which the server will
   consider the key valid.  Future modes may be defined which ignore the
   inception and expiration time fields.

   It is recommended that the server require that queries be signed.
   However, for currently defined modes, relatively little damage will
   be done if an unsigned query of this sort is accepted and processed,
   as described below for each mode. In addition, requiring that a TKEY
   query be signed by a TSIG (if there exists an acceptable exchanged
   key between the parties) or a SIG(0) may itself impose significant
   computational requirements on the server, particularly in verifying
   SIG(0) public key signatures.

   Responses to TKEY queries SHOULD always have DNS transaction
   signatures to protect the integrity of any keying data, error codes,
   etc. This signature MUST use a previously established secret (TSIG)
   or public (SIG(0)) key and MUST NOT use any key that the response to
   be verified is itself providing.







Donald E. Eastlake, 3rd                                         [Page 8]


INTERNET-DRAFT                                           The DNS TKEY RR


3.1 Query for Server Assigned Keying

   In server assigned keying, the DNS server host generates the keying
   material and it is sent to the resolver encrypted under a resolver
   host 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 host KEY RR to
   be used in encrypting the response, both in the additional
   information section. The TKEY algorithm field is set to the signature
   algorithm the resolver plans to use.  Any "key data" provided in the
   query TKEY may be either ignored by the server or strongly mixed with
   server generated randomness [RFC 1750] to derive the keying material
   to be used.  The KEY that appears in the query SHOULD have a zero
   TTL.  It need not be accompanied by a SIG(KEY) and if the query is
   signed by the resolver host and that signature is verified, then any
   SIG(KEY) provided MAY be ignored for key exchange purposes.  The KEY
   RR in such a query SHOULD have a name that corresponds to the
   resolver host 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.

   Accepting and responding to an unsigned query of this sort may drain
   some entropy from an entropy pool being maintained by the server and
   used for secret key generation and so might enable an entropy
   exhaustion attack.  In addition, some significant amount of
   computational resources may be used in the public key encryption of
   response data.  To protect against these effects, a server SHOULD
   require such a query to be signed as described at the beginning of
   Section 3 and MAY rate limit responses.

   The server response contains a TKEY in its answer section with the
   server assigned mode. If the error field is non-zero, the query
   failed for the reason given. If the error field is zero, the KEY RR
   provided in the query will be echoed back and the key data portion of
   the response TKEY RR will be the server assigned keying data
   encrypted under the public key in the KEY RR.  The name of the TKEY
   RR will be the server assigned name of the key and SHOULD be globally
   unique.



3.2 Query for Diffie-Hellman Exchanged Keying

   Diffie-Hellman (DH) key exchange is 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 [draft-ietf-dnssec-dhk-
   *.txt].



Donald E. Eastlake, 3rd                                         [Page 9]


INTERNET-DRAFT                                           The DNS TKEY RR


   A client 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 specifying a client host Diffie-Hellman
   key.  The TKEY algorithm field is set to the signature algorithm the
   resolver plans to use and any "key data" provided MUST be either
   ignored by the server or treated as an error.

   Accepting and responding to an unsigned query of this sort may use
   significant computation at the server; however, if the server
   requires that the request be signed, then if no shared secret is in
   place to permit a TSIG to be used on the request, it would be
   necessary to use a SIG(0) the verification of which would impose its
   own computational load.

   The server response contains a TKEY in its answer section with the
   Diffie-Hellman mode. If the error field is non-zero, the query failed
   for the reason given. If the error field is zero, the client host
   supplied Diffie-Hellman KEY should be echoed back and a server host
   Diffie-Hellman KEY RR will also be present.

   Both parties can calculate the same shared secret quantity from the
   pair of Diffie-Hellman keys used [Schneier] provided they use the
   same modulus.  If the server host does not have an appropriate
   Diffie-Hellman key to use for the exchange, it should return the
   BADKEY error.



3.3 Query for GSS-API Established

   This is described in a separate document [draft-skwan-gss-tsig-*.txt]
   which should be seen for the full description.  Basically, when an
   acceptable symmetric key is not yet in place, the resolver can send a
   query for type TKEY with a TKEY specifying the GSS-API mode in the
   additional information section and a GSS-API token in the key data
   portion. The server responds with a TKEY specifying the GSS-API mode
   and a GSS-API token in the key data portion. The resolver and server
   feed these tokens to their local GSS implementation and interate
   until an error is encountered or a key (GSS-API session) is
   established. A similar exchange can be used to delete a GSS-API
   session.

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






Donald E. Eastlake, 3rd                                        [Page 10]


INTERNET-DRAFT                                           The DNS TKEY RR


4. Spontaneous Server Inclusion

   A DNS server may include TKEY RRs spontaneously as additional
   information in responses.  This SHOULD only be done if the server
   knows the querier understands TKEY and has this option implemented.
   The TKEY should have a zero TTL. This technique can be used to
   establish a server assigned key, a Diffie-Hellman exchange key, for
   GSS-API exchange, and to delete a key.  A disadvantage of this
   technique is that there is no way for the server to get any immediate
   error or success indication back and, in the case of UDP, no way to
   even know if the DNS response reached the resolver.



4.1 Spontaneous Server Assigned Keying

   A server can include in the additional information section of a
   response a server assignment mode TKEY with encrypted keying material
   in its key data section along with a KEY RR specifying the client
   public key used for the encryption.  Such a response SHOULD be signed
   but the KEY RR need not be signed by a SIG(KEY).  A server should
   only do this if there is sufficient room in a query and it has reason
   to believe the resolver will understand such additional data.  The
   KEY RR used MUST be one for which the resolver host has the
   corresponding private key or it will not be able to decrypt the
   keying material.



4.2 Spontaneous Diffie-Hellman Keying

   A server can include in the additional information section of a
   response a Diffie-Hellman exchange mode TKEY along with two KEY RRs
   specifying the client and server host public keys used for the
   exchange.  Such a response SHOULD be signed but the KEY RRs need not
   be signed by a SIG(KEY).  A server should only do this if there is
   sufficient room in a query and it has reason to believe the resolver
   host will understand such additional data.



4.3 Spontaneous GSS-API Exchange

   A server can spontaneously include in the additional information
   section of a response, a GSS-API mode TKEY.  The information in the
   key data section of such a TKEY is a GSS-API token which SHOULD be
   feed by the resolver to its local GSS-API implementation.  If such a
   response is signed, the signature must verify before processing the
   data.  To the extent that GSS-API provides its own security, such a
   response MAY NOT need to be signed.  To the extent that GSS-API


Donald E. Eastlake, 3rd                                        [Page 11]


INTERNET-DRAFT                                           The DNS TKEY RR


   handled duplicated messages, such a spontaneous TKEY can be sent
   repeatedly, until, perhaps, a response via a GSS-API mode TKEY query
   is received.



4.4 Spontaneous Key Deletion

   A server can hint to a client that it has deleted a key by
   spontaneously including a TKEY RR in the additional information
   section of a response with the key deletion mode.  Such a response
   SHOULD be signed.  If authenticated, it deletes all keys with the
   given name whose effective time period overlaps the inception to
   expiration period given in the TKEY.  Failure by a client to receive
   or properly process such additional information in a response would
   simply mean that the client might use a key that the server had
   discarded and get back an error indication.



































Donald E. Eastlake, 3rd                                        [Page 12]


INTERNET-DRAFT                                           The DNS TKEY RR


5. TKEY Dynamic Update Requests

   If a DNS server supports dynamic update [RFC 2136], then dynamic
   update request can be used to exchange resolver assigned keys as
   described in section 5.1 below and to delete previously exchanged
   keys from a server as described in section 5.2 below.



5.1 Exchange via TKEY 'Add'

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

   The resolver sends an update request adding a TKEY RR that specifies
   the keying data with a KEY RR in the additional information section
   specifying the server host public key used to encrypt the data.  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
   server SHOULD require that this request be signed with a TSIG, if
   there already exists an appropriate shared secret, or a SIG(0) by the
   resolver host.  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.



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

   The key expiration provided in the TKEY and the ability of each party
   to discard keys may be adequate but servers that support dynamic
   update [RFC 2136] may optionally implement key deletion whereby the
   server discards a key on receipt from a resolver of a delete request
   for a TKEY with the key's name.  The mode and most fields of the TKEY
   being "deleted" are ignored.  But, to allow for the possibility of
   multiple keys with the same name but different time periods, the only
   key deleted are those whose time period overlaps with that specified
   by the inception and expiration in the TKEY being "deleted".






Donald E. Eastlake, 3rd                                        [Page 13]


INTERNET-DRAFT                                           The DNS TKEY RR


6. Methods of Encryption

   For the server assigned and resolver assigned key exchange, the
   keying material is sent within the keying data field of a TKEY RR
   encrypted under the private key corresponding to the public key in an
   accompanying KEY RR [RFC 2065]. The secret keying material being send
   will generally be fairly short, usually less than 256 bits, because
   that is adequate for strong protection with modern keyed hash or
   symmetric algorithms.

   If the KEY RR specifies the RSA algorithm, then the keying material
   is encrypted as per the description of RSA encryption in PKCS-1.
   (Note, the secret keying material being sent is directly RSA
   encrypted, it is not "enveloped" under some other symetric
   algorithm.)  In the unlikely event that the keying material will not
   fit within one RSA modulus of the chosen public key, additional RSA
   encryption blocks are included.  The length of each block is clear
   from the public RSA key specified and the PKCS-1 padding makes it
   clear what part of the encyrpted data is actually keying material and
   what part is formatting or the required at least eight bytes of
   random [RFC 1750] padding.



7. Security Considerations

   To avoid different interpretations of the inception and expiration
   times in TKEY RRs, resovlers and servers exchanging them must have
   the same idea of what time it is.























Donald E. Eastlake, 3rd                                        [Page 14]


INTERNET-DRAFT                                           The DNS TKEY RR


References

   PKCS-1 - RSA Encryption Standard (An RSA Laboratories Technical
   Note).

   RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",
   STD 13, November 1987.

   RFC 1035 - P. Mockapetris, "Domain Names - Implementation and
   Specifications", STD 13, November 1987.

   RFC 1750 - D. Eastlake, S.  Crocker & J. Schiller, "Randomness
   Recommendations for Security", December 1994.

   RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security
   Extensions", 01/03/1997.

   RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic
   Updates in the Domain Name System (DNS UPDATE)", 04/21/1997.

   RFC 2137 - Donald Eastlake, "Secure Domain Name System Dynamic
   Update", 04/21/1997.

   draft-ietf-dnsind-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
   Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".

   draft-ietf-dnssec-dhk-*.txt - D. Eastlake

   draft-skwan-gss-tsig-*.txt - S. Kwan, P. Garg, R. Viswanathan, "GSS
   Algorithm for TSIG (GSS-TSIG)"

   [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
   Algorithms, and Source Code in C", 1996, John Wiley and Sons



















Donald E. Eastlake, 3rd                                        [Page 15]


INTERNET-DRAFT                                           The DNS TKEY RR


Author's Address

   Donald E. Eastlake 3rd
   CyberCash, Inc.
   318 Acton Street
   Carlisle, MA 01741 USA

   Telephone:   +1 978 287 4877
                +1 703 620-4200 (main office, Reston, VA)
   FAX:         +1 978 371 7148
   email:       dee@cybercash.com



Expiration and File Name

   This draft expires August 1998.

   Its file name is draft-ietf-dnssec-tkey-00.txt.

































Donald E. Eastlake, 3rd                                        [Page 16]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/