doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc2845.txt b/doc/rfc/rfc2845.txt
new file mode 100644
index 0000000..aa9f385
--- /dev/null
+++ b/doc/rfc/rfc2845.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                             P. Vixie
+Request for Comments: 2845                                             ISC
+Category: Standards Track                                   O. Gudmundsson
+Updates: 1035                                                     NAI Labs
+                                                           D. Eastlake 3rd
+                                                                  Motorola
+                                                             B. Wellington
+                                                                   Nominum
+                                                                  May 2000
+
+
+          Secret Key Transaction Authentication for DNS (TSIG)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This protocol allows for transaction level authentication using
+   shared secrets and one way hashing.  It can be used to authenticate
+   dynamic updates as coming from an approved client, or to authenticate
+   responses as coming from an approved recursive name server.
+
+   No provision has been made here for distributing the shared secrets;
+   it is expected that a network administrator will statically configure
+   name servers and clients using some out of band mechanism such as
+   sneaker-net until a secure automated mechanism for key distribution
+   is available.
+
+1 - Introduction
+
+   1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
+   hierarchical distributed database system that provides information
+   fundamental to Internet operations, such as name <=> address
+   translation and mail handling information.  DNS has recently been
+   extended [RFC2535] to provide for data origin authentication, and
+   public key distribution, all based on public key cryptography and
+   public key based digital signatures.  To be practical, this form of
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 1]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   security generally requires extensive local caching of keys and
+   tracing of authentication through multiple keys and signatures to a
+   pre-trusted locally configured key.
+
+   1.2. One difficulty with the [RFC2535] scheme is that common DNS
+   implementations include simple "stub" resolvers which do not have
+   caches.  Such resolvers typically rely on a caching DNS server on
+   another host.  It is impractical for these stub resolvers to perform
+   general [RFC2535] authentication and they would naturally depend on
+   their caching DNS server to perform such services for them.  To do so
+   securely requires secure communication of queries and responses.
+   [RFC2535] provides public key transaction signatures to support this,
+   but such signatures are very expensive computationally to generate.
+   In general, these require the same complex public key logic that is
+   impractical for stubs.  This document specifies use of a message
+   authentication code (MAC), specifically HMAC-MD5 (a keyed hash
+   function), to provide an efficient means of point-to-point
+   authentication and integrity checking for transactions.
+
+   1.3. A second area where use of straight [RFC2535] public key based
+   mechanisms may be impractical is authenticating dynamic update
+   [RFC2136] requests.  [RFC2535] provides for request signatures but
+   with [RFC2535] they, like transaction signatures, require
+   computationally expensive public key cryptography and complex
+   authentication logic.  Secure Domain Name System Dynamic Update
+   ([RFC2137]) describes how different keys are used in dynamically
+   updated zones.  This document's secret key based MACs can be used to
+   authenticate DNS update requests as well as transaction responses,
+   providing a lightweight alternative to the protocol described by
+   [RFC2137].
+
+   1.4. A further use of this mechanism is to protect zone transfers.
+   In this case the data covered would be the whole zone transfer
+   including any glue records sent.  The protocol described by [RFC2535]
+   does not protect glue records and unsigned records unless SIG(0)
+   (transaction signature) is used.
+
+   1.5. The authentication mechanism proposed in this document uses
+   shared secret keys to establish a trust relationship between two
+   entities.  Such keys must be protected in a fashion similar to
+   private keys, lest a third party masquerade as one of the intended
+   parties (forge MACs).  There is an urgent need to provide simple and
+   efficient authentication between clients and local servers and this
+   proposal addresses that need.  This proposal is unsuitable for
+   general server to server authentication for servers which speak with
+   many other servers, since key management would become unwieldy with
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 2]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   the number of shared keys going up quadratically.  But it is suitable
+   for many resolvers on hosts that only talk to a few recursive
+   servers.
+
+   1.6. A server acting as an indirect caching resolver -- a "forwarder"
+   in common usage -- might use transaction-based authentication when
+   communicating with its small number of preconfigured "upstream"
+   servers.  Other uses of DNS secret key authentication and possible
+   systems for automatic secret key distribution may be proposed in
+   separate future documents.
+
+   1.7. New Assigned Numbers
+
+      RRTYPE = TSIG (250)
+      ERROR = 0..15 (a DNS RCODE)
+      ERROR = 16 (BADSIG)
+      ERROR = 17 (BADKEY)
+      ERROR = 18 (BADTIME)
+
+   1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED",  and
+   "MAY" in this document are to be interpreted as described in [RFC
+   2119].
+
+2 - TSIG RR Format
+
+   2.1 TSIG RR Type
+
+   To provide secret key authentication, we use a new RR type whose
+   mnemonic is TSIG and whose type code is 250.  TSIG is a meta-RR and
+   MUST not be cached.  TSIG RRs are used for authentication between DNS
+   entities that have established a shared secret key.  TSIG RRs are
+   dynamically computed to cover a particular DNS transaction and are
+   not DNS RRs in the usual sense.
+
+   2.2 TSIG Calculation
+
+   As the TSIG RRs are related to one DNS request/response, there is no
+   value in storing or retransmitting them, thus the TSIG RR is
+   discarded once it has been used to authenticate a DNS message.  The
+   only message digest algorithm specified in this document is "HMAC-
+   MD5" (see [RFC1321], [RFC2104]).  The "HMAC-MD5" algorithm is
+   mandatory to implement for interoperability.  Other algorithms can be
+   specified at a later date.  Names and definitions of new algorithms
+   MUST be registered with IANA.  All multi-octet integers in the TSIG
+   record are sent in network byte order (see [RFC1035 2.3.2]).
+
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 3]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   2.3. Record Format
+
+    NAME The name of the key used in domain name syntax.  The name
+         should reflect the names of the hosts and uniquely identify
+         the key among a set of keys these two hosts may share at any
+         given time.  If hosts A.site.example and B.example.net share a
+         key, possibilities for the key name include
+         <id>.A.site.example, <id>.B.example.net, and
+         <id>.A.site.example.B.example.net.  It should be possible for
+         more than one key to be in simultaneous use among a set of
+         interacting hosts.  The name only needs to be meaningful to
+         the communicating hosts but a meaningful mnemonic name as
+         above is strongly recommended.
+
+         The name may be used as a local index to the key involved and
+         it is recommended that it be globally unique.  Where a key is
+         just shared between two hosts, its name actually only need
+         only be meaningful to them but it is recommended that the key
+         name be mnemonic and incorporate the resolver and server host
+         names in that order.
+
+    TYPE TSIG (250: Transaction SIGnature)
+
+    CLASS ANY
+
+    TTL  0
+
+    RdLen (variable)
+
+    RDATA
+
+      Field Name       Data Type      Notes
+      --------------------------------------------------------------
+      Algorithm Name   domain-name    Name of the algorithm
+                                      in domain name syntax.
+      Time Signed      u_int48_t      seconds since 1-Jan-70 UTC.
+      Fudge            u_int16_t      seconds of error permitted
+                                      in Time Signed.
+      MAC Size         u_int16_t      number of octets in MAC.
+      MAC              octet stream   defined by Algorithm Name.
+      Original ID      u_int16_t      original message ID
+      Error            u_int16_t      expanded RCODE covering
+                                      TSIG processing.
+      Other Len        u_int16_t      length, in octets, of
+                                      Other Data.
+      Other Data       octet stream   empty unless Error == BADTIME
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 4]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   2.4. Example
+
+      NAME   HOST.EXAMPLE.
+
+      TYPE   TSIG
+
+      CLASS  ANY
+
+      TTL    0
+
+      RdLen  as appropriate
+
+      RDATA
+
+         Field Name       Contents
+         -------------------------------------
+         Algorithm Name   SAMPLE-ALG.EXAMPLE.
+         Time Signed      853804800
+         Fudge            300
+         MAC Size         as appropriate
+         MAC              as appropriate
+         Original ID      as appropriate
+         Error            0 (NOERROR)
+         Other Len        0
+         Other Data       empty
+
+3 - Protocol Operation
+
+   3.1. Effects of adding TSIG to outgoing message
+
+   Once the outgoing message has been constructed, the keyed message
+   digest operation can be performed.  The resulting message digest will
+   then be stored in a TSIG which is appended to the additional data
+   section (the ARCOUNT is incremented to reflect this).  If the TSIG
+   record cannot be added without causing the message to be truncated,
+   the server MUST alter the response so that a TSIG can be included.
+   This response consists of only the question and a TSIG record, and
+   has the TC bit set and RCODE 0 (NOERROR).  The client SHOULD at this
+   point retry the request using TCP (per [RFC1035 4.2.2]).
+
+   3.2. TSIG processing on incoming messages
+
+   If an incoming message contains a TSIG record, it MUST be the last
+   record in the additional section.  Multiple TSIG records are not
+   allowed.  If a TSIG record is present in any other position, the
+   packet is dropped and a response with RCODE 1 (FORMERR) MUST be
+   returned.  Upon receipt of a message with a correctly placed TSIG RR,
+   the TSIG RR is copied to a safe location, removed from the DNS
+
+
+
+Vixie, et al.               Standards Track                     [Page 5]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   Message, and decremented out of the DNS message header's ARCOUNT.  At
+   this point the keyed message digest operation is performed.  If the
+   algorithm name or key name is unknown to the recipient, or if the
+   message digests do not match, the whole DNS message MUST be
+   discarded.  If the message is a query, a response with RCODE 9
+   (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17
+   (BADKEY) or TSIG ERROR 16 (BADSIG).  If no key is available to sign
+   this message it MUST be sent unsigned (MAC size == 0 and empty MAC).
+   A message to the system operations log SHOULD be generated, to warn
+   the operations staff of a possible security incident in progress.
+   Care should be taken to ensure that logging of this type of event
+   does not open the system to a denial of service attack.
+
+   3.3. Time values used in TSIG calculations
+
+   The data digested includes the two timer values in the TSIG header in
+   order to defend against replay attacks.  If this were not done, an
+   attacker could replay old messages but update the "Time Signed" and
+   "Fudge" fields to make the message look new.  This data is named
+   "TSIG Timers", and for the purpose of digest calculation they are
+   invoked in their "on the wire" format, in the following order: first
+   Time Signed, then Fudge.  For example:
+
+Field Name    Value       Wire Format         Meaning
+----------------------------------------------------------------------
+Time Signed   853804800   00 00 32 e4 07 00   Tue Jan 21 00:00:00 1997
+Fudge         300         01 2C               5 minutes
+
+   3.4. TSIG Variables and Coverage
+
+   When generating or verifying the contents of a TSIG record, the
+   following data are digested, in network byte order or wire format, as
+   appropriate:
+
+   3.4.1. DNS Message
+
+   A whole and complete DNS message in wire format, before the TSIG RR
+   has been added to the additional data section and before the DNS
+   Message Header's ARCOUNT field has been incremented to contain the
+   TSIG RR.  If the message ID differs from the original message ID, the
+   original message ID is substituted for the message ID.  This could
+   happen when forwarding a dynamic update request, for example.
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 6]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   3.4.2. TSIG Variables
+
+Source       Field Name       Notes
+-----------------------------------------------------------------------
+TSIG RR      NAME             Key name, in canonical wire format
+TSIG RR      CLASS            (Always ANY in the current specification)
+TSIG RR      TTL              (Always 0 in the current specification)
+TSIG RDATA   Algorithm Name   in canonical wire format
+TSIG RDATA   Time Signed      in network byte order
+TSIG RDATA   Fudge            in network byte order
+TSIG RDATA   Error            in network byte order
+TSIG RDATA   Other Len        in network byte order
+TSIG RDATA   Other Data       exactly as transmitted
+
+   The RR RDLEN and RDATA MAC Length are not included in the hash since
+   they are not guaranteed to be knowable before the MAC is generated.
+
+   The Original ID field is not included in this section, as it has
+   already been substituted for the message ID in the DNS header and
+   hashed.
+
+   For each label type, there must be a defined "Canonical wire format"
+   that specifies how to express a label in an unambiguous way.  For
+   label type 00, this is defined in [RFC2535], for label type 01, this
+   is defined in [RFC2673].  The use of label types other than 00 and 01
+   is not defined for this specification.
+
+   3.4.3. Request MAC
+
+   When generating the MAC to be included in a response, the request MAC
+   must be included in the digest.  The request's MAC is digested in
+   wire format, including the following fields:
+
+   Field        Type           Description
+   ---------------------------------------------------
+   MAC Length   u_int16_t      in network byte order
+   MAC Data     octet stream   exactly as transmitted
+
+   3.5. Padding
+
+   Digested components are fed into the hashing function as a continuous
+   octet stream with no interfield padding.
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 7]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+4 - Protocol Details
+
+   4.1. TSIG generation on requests
+
+   Client performs the message digest operation and appends a TSIG
+   record to the additional data section and transmits the request to
+   the server.  The client MUST store the message digest from the
+   request while awaiting an answer.  The digest components for a
+   request are:
+
+      DNS Message (request)
+      TSIG Variables (request)
+
+   Note that some older name servers will not accept requests with a
+   nonempty additional data section.  Clients SHOULD only attempt signed
+   transactions with servers who are known to support TSIG and share
+   some secret key with the client -- so, this is not a problem in
+   practice.
+
+   4.2. TSIG on Answers
+
+   When a server has generated a response to a signed request, it signs
+   the response using the same algorithm and key.  The server MUST not
+   generate a signed response to an unsigned request.  The digest
+   components are:
+
+      Request MAC
+      DNS Message (response)
+      TSIG Variables (response)
+
+   4.3. TSIG on TSIG Error returns
+
+   When a server detects an error relating to the key or MAC, the server
+   SHOULD send back an unsigned error message (MAC size == 0 and empty
+   MAC).  If an error is detected relating to the TSIG validity period,
+   the server SHOULD send back a signed error message.  The digest
+   components are:
+
+      Request MAC (if the request MAC validated)
+      DNS Message (response)
+      TSIG Variables (response)
+
+   The reason that the request is not included in this digest in some
+   cases is to make it possible for the client to verify the error.  If
+   the error is not a TSIG error the response MUST be generated as
+   specified in [4.2].
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 8]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   4.4. TSIG on TCP connection
+
+   A DNS TCP session can include multiple DNS envelopes.  This is, for
+   example, commonly used by zone transfer.  Using TSIG on such a
+   connection can protect the connection from hijacking and provide data
+   integrity.  The TSIG MUST be included on the first and last DNS
+   envelopes.  It can be optionally placed on any intermediary
+   envelopes.  It is expensive to include it on every envelopes, but it
+   MUST be placed on at least every 100'th envelope.  The first envelope
+   is processed as a standard answer, and subsequent messages have the
+   following digest components:
+
+      Prior Digest (running)
+      DNS Messages (any unsigned messages since the last TSIG)
+      TSIG Timers (current message)
+
+   This allows the client to rapidly detect when the session has been
+   altered; at which point it can close the connection and retry.  If a
+   client TSIG verification fails, the client MUST close the connection.
+   If the client does not receive TSIG records frequently enough (as
+   specified above) it SHOULD assume the connection has been hijacked
+   and it SHOULD close the connection.  The client SHOULD treat this the
+   same way as they would any other interrupted transfer (although the
+   exact behavior is not specified).
+
+   4.5. Server TSIG checks
+
+   Upon receipt of a message, server will check if there is a TSIG RR.
+   If one exists, the server is REQUIRED to return a TSIG RR in the
+   response.  The server MUST perform the following checks in the
+   following order, check KEY, check TIME values, check MAC.
+
+   4.5.1. KEY check and error handling
+
+   If a non-forwarding server does not recognize the key used by the
+   client, the server MUST generate an error response with RCODE 9
+   (NOTAUTH) and TSIG ERROR 17 (BADKEY).  This response MUST be unsigned
+   as specified in [4.3].  The server SHOULD log the error.
+
+   4.5.2. TIME check and error handling
+
+   If the server time is outside the time interval specified by the
+   request (which is: Time Signed, plus/minus Fudge), the server MUST
+   generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18
+   (BADTIME).  The server SHOULD also cache the most recent time signed
+   value in a message generated by a key, and SHOULD return BADTIME if a
+   message received later has an earlier time signed value.  A response
+   indicating a BADTIME error MUST be signed by the same key as the
+
+
+
+Vixie, et al.               Standards Track                     [Page 9]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   request.  It MUST include the client's current time in the time
+   signed field, the server's current time (a u_int48_t) in the other
+   data field, and 6 in the other data length field.  This is done so
+   that the client can verify a message with a BADTIME error without the
+   verification failing due to another BADTIME error.  The data signed
+   is specified in [4.3].  The server SHOULD log the error.
+
+   4.5.3. MAC check and error handling
+
+   If a TSIG fails to verify, the server MUST generate an error response
+   as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16
+   (BADSIG).  This response MUST be unsigned as specified in [4.3].  The
+   server SHOULD log the error.
+
+   4.6. Client processing of answer
+
+   When a client receives a response from a server and expects to see a
+   TSIG, it first checks if the TSIG RR is present in the response.
+   Otherwise, the response is treated as having a format error and
+   discarded.  The client then extracts the TSIG, adjusts the ARCOUNT,
+   and calculates the keyed digest in the same way as the server.  If
+   the TSIG does not validate, that response MUST be discarded, unless
+   the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to
+   verify the response as if it were a TSIG Error response, as specified
+   in [4.3].  A message containing an unsigned TSIG record or a TSIG
+   record which fails verification SHOULD not be considered an
+   acceptable response; the client SHOULD log an error and continue to
+   wait for a signed response until the request times out.
+
+   4.6.1. Key error handling
+
+   If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
+   validates, and the TSIG key is different from the key used on the
+   request, then this is a KEY error.  The client MAY retry the request
+   using the key specified by the server.  This should never occur, as a
+   server MUST NOT sign a response with a different key than signed the
+   request.
+
+   4.6.2. Time error handling
+
+   If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18
+   (BADTIME), or the current time does not fall in the range specified
+   in the TSIG record, then this is a TIME error.  This is an indication
+   that the client and server clocks are not synchronized.  In this case
+   the client SHOULD log the event.  DNS resolvers MUST NOT adjust any
+   clocks in the client based on BADTIME errors, but the server's time
+   in the other data field SHOULD be logged.
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 10]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   4.6.3. MAC error handling
+
+   If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG),
+   this is a MAC error, and client MAY retry the request with a new
+   request ID but it would be better to try a different shared key if
+   one is available.  Client SHOULD keep track of how many MAC errors
+   are associated with each key.  Clients SHOULD log this event.
+
+   4.7. Special considerations for forwarding servers
+
+   A server acting as a forwarding server of a DNS message SHOULD check
+   for the existence of a TSIG record.  If the name on the TSIG is not
+   of a secret that the server shares with the originator the server
+   MUST forward the message unchanged including the TSIG.  If the name
+   of the TSIG is of a key this server shares with the originator, it
+   MUST process the TSIG.  If the TSIG passes all checks, the forwarding
+   server MUST, if possible, include a TSIG of his own, to the
+   destination or the next forwarder.  If no transaction security is
+   available to the destination and the response has the AD flag (see
+   [RFC2535]), the forwarder MUST unset the AD flag before adding the
+   TSIG to the answer.
+
+5 - Shared Secrets
+
+   5.1. Secret keys are very sensitive information and all available
+   steps should be taken to protect them on every host on which they are
+   stored.  Generally such hosts need to be physically protected.  If
+   they are multi-user machines, great care should be taken that
+   unprivileged users have no access to keying material.  Resolvers
+   often run unprivileged, which means all users of a host would be able
+   to see whatever configuration data is used by the resolver.
+
+   5.2. A name server usually runs privileged, which means its
+   configuration data need not be visible to all users of the host.  For
+   this reason, a host that implements transaction-based authentication
+   should probably be configured with a "stub resolver" and a local
+   caching and forwarding name server.  This presents a special problem
+   for [RFC2136] which otherwise depends on clients to communicate only
+   with a zone's authoritative name servers.
+
+   5.3. Use of strong random shared secrets is essential to the security
+   of TSIG.  See [RFC1750] for a discussion of this issue.  The secret
+   should be at least as long as the keyed message digest, i.e. 16 bytes
+   for HMAC-MD5 or 20 bytes for HMAC-SHA1.
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 11]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+6 - Security Considerations
+
+   6.1. The approach specified here is computationally much less
+   expensive than the signatures specified in [RFC2535].  As long as the
+   shared secret key is not compromised, strong authentication is
+   provided for the last hop from a local name server to the user
+   resolver.
+
+   6.2. Secret keys should be changed periodically.  If the client host
+   has been compromised, the server should suspend the use of all
+   secrets known to that client.  If possible, secrets should be stored
+   in encrypted form.  Secrets should never be transmitted in the clear
+   over any network.  This document does not address the issue on how to
+   distribute secrets. Secrets should never be shared by more than two
+   entities.
+
+   6.3. This mechanism does not authenticate source data, only its
+   transmission between two parties who share some secret.  The original
+   source data can come from a compromised zone master or can be
+   corrupted during transit from an authentic zone master to some
+   "caching forwarder."  However, if the server is faithfully performing
+   the full [RFC2535] security checks, then only security checked data
+   will be available to the client.
+
+   6.4. A fudge value that is too large may leave the server open to
+   replay attacks.  A fudge value that is too small may cause failures
+   if machines are not time synchronized or there are unexpected network
+   delays.  The recommended value in most situation is 300 seconds.
+
+7 - IANA Considerations
+
+   IANA is expected to create and maintain a registry of algorithm names
+   to be used as "Algorithm Names" as defined in Section 2.3.  The
+   initial value should be "HMAC-MD5.SIG-ALG.REG.INT".  Algorithm names
+   are text strings encoded using the syntax of a domain name.  There is
+   no structure required other than names for different algorithms must
+   be unique when compared as DNS names, i.e., comparison is case
+   insensitive.  Note that the initial value mentioned above is not a
+   domain name, and therefore need not be a registered name within the
+   DNS.  New algorithms are assigned using the IETF Consensus policy
+   defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT
+   looks like a FQDN for historical reasons; future algorithm names are
+   expected to be simple (i.e., single-component) names.
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 12]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   IANA is expected to create and maintain a registry of "TSIG Error
+   values" to be used for "Error" values as defined in section 2.3.
+   Initial values should be those defined in section 1.7.  New TSIG
+   error codes for the TSIG error field are assigned using the IETF
+   Consensus policy defined in RFC 2434.
+
+8 - References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1034, November 1987.
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              April 1992.
+
+   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1995.
+
+   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5:
+              Keyed-MD5 for Message Authentication", RFC 2104, February
+              1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic
+              Updates in the Domain Name System", RFC 2136, April 1997.
+
+   [RFC2137]  Eastlake 3rd, D., "Secure Domain Name System Dynamic
+              Update", RFC 2137, April 1997.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
+              RFC 2673, August 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 13]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+9 - Authors' Addresses
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 7001
+   EMail: vixie@isc.org
+
+
+   Olafur Gudmundsson
+   NAI Labs
+   3060 Washington Road, Route 97
+   Glenwood, MD 21738
+
+   Phone: +1 443 259 2389
+   EMail: ogud@tislabs.com
+
+
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
+
+   Phone: +1 508 261 5434
+   EMail: dee3@torque.pothole.com
+
+
+   Brian Wellington
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 6022
+   EMail: Brian.Wellington@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 14]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+10  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 15]
+