Internet DRAFT - draft-austein-dnsext-relax-gratuitous-tsig

draft-austein-dnsext-relax-gratuitous-tsig






Network Working Group                                         R. Austein
Internet-Draft                                                  M. Graff
Intended status: Informational                                       ISC
Expires: April 26, 2007                                 October 23, 2006


                  Relaxing Gratuitous TSIG Requirement
             draft-austein-dnsext-relax-gratuitous-tsig-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   GSS-TSIG is not implementable as specified due to an omission, and
   the specification contains an unnecessary restriction.  This note
   proposes a fix to both of these problems.








Austein & Graff          Expires April 26, 2007                 [Page 1]

Internet-Draft    Relaxing Gratuitous TSIG Requirement      October 2006


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Reserved Words  . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Interoperability Testing  . . . . . . . . . . . . . . . . . . . 4
   4.  Suggested Protocol Action . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8




































Austein & Graff          Expires April 26, 2007                 [Page 2]

Internet-Draft    Relaxing Gratuitous TSIG Requirement      October 2006


1.  Introduction

   GSS-TSIG ([RFC3645]) is not implementable as specified, and contains
   an unnecessary restriction.  This note discusses these problems and
   proposes a fix to both of these problems.

1.1.  Reserved Words

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


2.  Background

   TSIG ([RFC2845]) is a simple shared-secret channel security mechanism
   for DNS.  A companion mechanism, TKEY ([RFC2930]), provides an
   extensible mechanism for negotiating shared secrets for use with
   TSIG.

   GSS-TSIG ([RFC3645]) is a mechanism built on top of TKEY, GSS-API
   ([RFC2743]), and SPNEGO ([RFC4178]) which extends TSIG to support
   algorithms within the GSS-API framework (such as Kerberos 5
   [RFC4121]).  In recent years, GSS-TSIG has become one of the major
   uses of TSIG.

   Sadly, the current specifications are not sufficient to allow an
   implementor to achieve interoperability with GSS-TSIG as deployed.
   Much of the problem has been due to weaknesses of the original SPNEGO
   specification, which have been addressed in [RFC4178].  However, even
   after achieving SPNEGO interoperability, there's still a problem with
   GSS-TSIG, which we refer to here as the "gratuitous TSIG" problem.

   Section 4.2 of [RFC2845] clearly forbids signed responses to unsigned
   queries, and defines the format of a response signature in such a way
   that it cannot be computed without knowing the signature of the
   corresponding request.  Section 2.2 of [RFC3645] modifies the base
   TSIG protocol to allow an signed responses to unsigned requests on a
   per-algorithm basis, while sections 3.1.3.1 and 4.1.3 of [RFC3645]
   not only allow but require the final TKEY of the negotiation sequence
   to be signed using the newly-negotiated key.  Unfortunately, the
   format of the response signature in this case is not specified
   anywhere, which is a problem, since the definition in the base TSIG
   specification provides no way to compute such a signature.

   In spite of the language used in [RFC3645] 3.1.3.1, the issue here is
   not really security.  The change to the base TSIG protocol here does
   not add any security at all, as the GSS-API negotiation is self-



Austein & Graff          Expires April 26, 2007                 [Page 3]

Internet-Draft    Relaxing Gratuitous TSIG Requirement      October 2006


   authenticating.  This was known at the time that [RFC3645] was
   written (see archives of the Namedroppers mailing list, July 2002).
   The real reason for this change was simply that several vendors had
   shipped early implementations that required this TSIG to be present,
   and did not want the code they had already shipped to be declared
   non-compliant.  Due to an oversight, no one realized that this code
   violated the base TSIG specification until [RFC3645] was just about
   to be published; as a result, the authors requested and received
   permission from the DNSEXT working group to make this change to the
   base TSIG specification.  As is all too often the case with last-
   minute protocol changes, nobody noticed at the time that this left
   the GSS-TSIG specification incomplete.

   We refer to the problematic TSIG described above as the "gratuitous
   TSIG" because as far as we can tell it is unnecessary and serves no
   purpose except to complicate the protocol.

   To the best of our knowledge, there is no existing public
   specification of the GSS_GetMIC() input value to be used when
   generating the gratuitous TSIG.


3.  Interoperability Testing

   The authors of this note have recently had occasion to test a GSS-
   TSIG implementation against several different versions of the most
   widely deployed implementation.  Our results can be summarized as
   follows:

   o  In all of our testing, we have not found even a single
      implementation that actually rejects the GSS-TSIG protocol
      negotiation (as required by [RFC3645] 3.1.3.1) if the name server
      simply omits the gratuitous TSIG.
   o  While we still do not know how the other implementations calculate
      the input value to GSS_GetMIC(), we do know that it is not any of
      the values that we consider obvious, because we've tried them all
      and they have all failed.

   We are thus in effect left in the silly position of being forced to
   violate the specification in order to interoperate with the other
   existing implementations.

   No doubt vendors who have implemented GSS-TSIG and want to
   interoperate would be willing to tell us how they calculate the input
   value to GSS_GetMIC(), but as the specification is demonstrably
   incomplete in its current form, a revision of the specification would
   be necessary in any case.




Austein & Graff          Expires April 26, 2007                 [Page 4]

Internet-Draft    Relaxing Gratuitous TSIG Requirement      October 2006


4.  Suggested Protocol Action

   Since, as far as we can tell, the gratuitous TSIG serves no useful
   purpose and is not required for interoperation with the existing
   implementations, we propose abolishing it.  In deference to the
   Robustness Principle, we suggest continuing to allow the gratuitous
   TSIG, but no longer requiring it.  Specifically:

   Amend [RFC3645] 4.1.3 to change

      The message MUST be signed with a TSIG record as described in
      section 5, Sending and Verifying Signed Messages.

   to

      The message MAY be signed with a TSIG record as described in
      section 5, Sending and Verifying Signed Messages.

   Amend [RFC3645] 3.1.3.1 to change

      Confirmation is in the form of a query response with RCODE=NOERROR
      and with the last client supplied TKEY record in the answer
      section of the query.  The response MUST be signed with a TSIG
      record.  Note that the server is allowed to sign a response to
      unsigned client's query due to modification to the RFC 2845
      specified in Section 2.2 above.  The signature in the TSIG record
      MUST be verified using the procedure detailed in section 5,
      Sending and Verifying Signed Messages.  If the response is not
      signed, OR if the response is signed but the signature is invalid,
      then an attacker has tampered with the message in transit or has
      attempted to send the client a false response.  In this case, the
      client MAY continue waiting for a response to its last TKEY query
      until the time period since the client sent last TKEY query
      expires.  Such a time period is specified by the policy local to
      the client.  This is a new option that allows the DNS client to
      accept multiple answers for one query ID and select one (not
      necessarily the first one) based on some criteria.

   to

      Confirmation is in the form of a query response with RCODE=NOERROR
      and with the last client supplied TKEY record in the answer
      section of the query.  The response MAY be signed with a TSIG
      record.  Note that the server is allowed to sign a response to
      unsigned client's query due to modification to the RFC 2845
      specified in Section 2.2 above.





Austein & Graff          Expires April 26, 2007                 [Page 5]

Internet-Draft    Relaxing Gratuitous TSIG Requirement      October 2006


5.  IANA Considerations

   This document has no IANA Considerations.


6.  Security Considerations

   This note proposes a minor simplification to an excessively complex
   channel security mechanism.  To the best of the authors' knowledge,
   this change does not weaken the mechanism.

   Note that discussion of the security properties of the "gratuitous
   TSIG" (not called by that name) in [RFC3645] 3.1.3.1 is incorrect,
   and that the working group responsible for publication of [RFC3645]
   was aware of this error at the time of publication.  See archives of
   the Namedroppers mailing list, July 2002, for details.


7.  Acknowledgements

   Thanks to Cricket Liu, Russ Mundy, and Joe Quanaim.  Apologies to
   anyone inadvertently omitted from the above list.


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, May 2000.

   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
              RR)", RFC 2930, September 2000.

   [RFC3645]  Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
              and R. Hall, "Generic Security Service Algorithm for
              Secret Key Transaction Authentication for DNS (GSS-TSIG)",
              RFC 3645, October 2003.

8.2.  Informative References

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.




Austein & Graff          Expires April 26, 2007                 [Page 6]

Internet-Draft    Relaxing Gratuitous TSIG Requirement      October 2006


   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
              Version 5 Generic Security Service Application Program
              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
              July 2005.

   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
              Simple and Protected Generic Security Service Application
              Program Interface (GSS-API) Negotiation Mechanism",
              RFC 4178, October 2005.


Authors' Addresses

   Rob Austein
   ISC
   950 Charter Street
   Redwood City, CA  94063
   USA

   Email: sra@isc.org


   Michael Graff
   ISC
   950 Charter Street
   Redwood City, CA  94063
   USA

   Email: michael_graff@isc.org






















Austein & Graff          Expires April 26, 2007                 [Page 7]

Internet-Draft    Relaxing Gratuitous TSIG Requirement      October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Austein & Graff          Expires April 26, 2007                 [Page 8]