1. Introduction

   The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
   protocol was developed to provide a lightweight authentication and
   integrity of messages between two DNS entities, such as client and
   server or server and server.  TSIG can be used to protect dynamic
   update messages, authenticate regular message or to off-load
   complicated DNSSEC [RFC2535] processing from a client to a server and
   still allow the client to be assured of the integrity of the answers.

   The TSIG protocol [RFC2845] is extensible through the definition of
   new algorithms.  This document specifies an algorithm based on the
   Generic Security Service Application Program Interface (GSS-API)
   [RFC2743].  GSS-API is a framework that provides an abstraction of
   security to the application protocol developer.  The security
   services offered can include authentication, integrity, and
   confidentiality.

   The GSS-API framework has several benefits:

   *  Mechanism and protocol independence.  The underlying mechanisms
      that realize the security services can be negotiated on the fly
      and varied over time.  For example, a client and server MAY use
      Kerberos [RFC1964] for one transaction, whereas that same server
      MAY use SPKM [RFC2025] with a different client.

   *  The protocol developer is removed from the responsibility of
      creating and managing a security infrastructure.  For example, the
      developer does not need to create new key distribution or key
      management systems.  Instead the developer relies on the security
      service mechanism to manage this on its behalf.

   The scope of this document is limited to the description of an
   authentication mechanism only.  It does not discuss and/or propose an
   authorization mechanism.  Readers that are unfamiliar with GSS-API
   concepts are encouraged to read the characteristics and concepts
   section of [RFC2743] before examining this protocol in detail.  It is
   also assumed that the reader is familiar with [RFC2845], [RFC2930],
   [RFC1034] and [RFC1035].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", and "MAY" in this document are to be interpreted as
   described in BCP 14, RFC 2119 [RFC2119].