< draft-austein-dnsext-relax-gratuitous-tsig-00.txt		draft-austein-dnsext-relax-gratuitous-tsig-01.txt >
	Network Working Group R. Austein		Network Working Group R. Austein
	Internet-Draft M. Graff		Internet-Draft M. Graff
	Expires: December 16, 2006 ISC		Intended status: Informational ISC
	June 14, 2006		Expires: April 26, 2007 October 23, 2006
	Relaxing Gratuitous TSIG Requirement		Relaxing Gratuitous TSIG Requirement
	draft-austein-dnsext-relax-gratuitous-tsig-00		draft-austein-dnsext-relax-gratuitous-tsig-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 16, 2006.		This Internet-Draft will expire on April 26, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	GSS-TSIG is not implementable as specified due to an omission, and		GSS-TSIG is not implementable as specified due to an omission, and
	the specification contains an unnecessary restriction. This note		the specification contains an unnecessary restriction. This note
	proposes a fix to both of these problems.		proposes a fix to both of these problems.
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Interoperability Testing . . . . . . . . . . . . . . . . . . . 4		3. Interoperability Testing . . . . . . . . . . . . . . . . . . . 4
	4. Suggested Protocol Action . . . . . . . . . . . . . . . . . . . 5		4. Suggested Protocol Action . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . . 6		8.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	Intellectual Property and Copyright Statements . . . . . . . . . . 9		Intellectual Property and Copyright Statements . . . . . . . . . . 8
	1. Introduction		1. Introduction
	GSS-TSIG ([RFC3645]) is not implementable as specified, and contains		GSS-TSIG ([RFC3645]) is not implementable as specified, and contains
	an unnecessary restriction. This note discusses these problems and		an unnecessary restriction. This note discusses these problems and
	proposes a fix to both of these problems.		proposes a fix to both of these problems.
	1.1. Reserved Words		1.1. Reserved Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	and did not want the code they had already shipped to be declared		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		non-compliant. Due to an oversight, no one realized that this code
	violated the base TSIG specification until [RFC3645] was just about		violated the base TSIG specification until [RFC3645] was just about
	to be published; as a result, the authors requested and received		to be published; as a result, the authors requested and received
	permission from the DNSEXT working group to make this change to the		permission from the DNSEXT working group to make this change to the
	base TSIG specification. As is all too often the case with last-		base TSIG specification. As is all too often the case with last-
	minute protocol changes, nobody noticed at the time that this left		minute protocol changes, nobody noticed at the time that this left
	the GSS-TSIG specification incomplete.		the GSS-TSIG specification incomplete.
	We refer to the problematic TSIG described above as the "gratuitous		We refer to the problematic TSIG described above as the "gratuitous
	TSIG" because as far as we can tell it is in fact gratuitous, and		TSIG" because as far as we can tell it is unnecessary and serves no
	serves no purpose except to complicate the protocol.		purpose except to complicate the protocol.
	To the best of our knowledge, there is no existing public		To the best of our knowledge, there is no existing public
	specification of the GSS_GetMIC() input value to be used when		specification of the GSS_GetMIC() input value to be used when
	generating the gratuitous TSIG.		generating the gratuitous TSIG.
	3. Interoperability Testing		3. Interoperability Testing
	The authors of this note have recently had occasion to test a GSS-		The authors of this note have recently had occasion to test a GSS-
	TSIG implementation against several different versions of the most		TSIG implementation against several different versions of the most
	widely deployed implementation. Our results can be summarized as		widely deployed implementation. Our results can be summarized as
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 31 ¶
	To the best of our knowledge, there is no existing public		To the best of our knowledge, there is no existing public
	specification of the GSS_GetMIC() input value to be used when		specification of the GSS_GetMIC() input value to be used when
	generating the gratuitous TSIG.		generating the gratuitous TSIG.
	3. Interoperability Testing		3. Interoperability Testing
	The authors of this note have recently had occasion to test a GSS-		The authors of this note have recently had occasion to test a GSS-
	TSIG implementation against several different versions of the most		TSIG implementation against several different versions of the most
	widely deployed implementation. Our results can be summarized as		widely deployed implementation. Our results can be summarized as
	follows:		follows:
	o In all of our testing, we have not found even a single		o In all of our testing, we have not found even a single
	implementation that actually rejects the GSS-TSIG protocol		implementation that actually rejects the GSS-TSIG protocol
	negotiation (as required by [RFC3645] 3.1.3.1) if the name server		negotiation (as required by [RFC3645] 3.1.3.1) if the name server
	simply omits the gratuitous TSIG.		simply omits the gratuitous TSIG.
	o While we still do not know how the other implementations calculate		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 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		the values that we consider obvious, because we've tried them all
	and they have all failed.		and they have all failed.
	We are thus in effect left in the ridiculous position of being forced		We are thus in effect left in the silly position of being forced to
	to violate the specification in order to interoperate with the other		violate the specification in order to interoperate with the other
	existing implementations.		existing implementations.
	No doubt vendors who have implemented this and want to interoperate		No doubt vendors who have implemented GSS-TSIG and want to
	would be willing to tell us how they calculate the input value to		interoperate would be willing to tell us how they calculate the input
	GSS_GetMIC(), but as the specification is demonstrably incomplete in		value to GSS_GetMIC(), but as the specification is demonstrably
	its current form, a revision of the specification would be necessary		incomplete in its current form, a revision of the specification would
	in any case.		be necessary in any case.
	4. Suggested Protocol Action		4. Suggested Protocol Action
	Since, as far as we can tell, the gratuitous TSIG serves no useful		Since, as far as we can tell, the gratuitous TSIG serves no useful
	purpose and is not in fact required for interoperation with the		purpose and is not required for interoperation with the existing
	existing implementations, we propose abolishing it. In deference to		implementations, we propose abolishing it. In deference to the
	the Robustness Principle, we suggest continuing to allow the		Robustness Principle, we suggest continuing to allow the gratuitous
	gratuitous TSIG, but no longer requiring it. Specifically:		TSIG, but no longer requiring it. Specifically:
	Amend [RFC3645] 4.1.3 to change		Amend [RFC3645] 4.1.3 to change
	The message MUST be signed with a TSIG record as described in		The message MUST be signed with a TSIG record as described in
	section 5, Sending and Verifying Signed Messages.		section 5, Sending and Verifying Signed Messages.
	to		to
	The message MAY be signed with a TSIG record as described in		The message MAY be signed with a TSIG record as described in
	section 5, Sending and Verifying Signed Messages.		section 5, Sending and Verifying Signed Messages.
	Amend [RFC3645] 3.1.3.1 to change		Amend [RFC3645] 3.1.3.1 to change
	Confirmation is in the form of a query response with RCODE=NOERROR		Confirmation is in the form of a query response with RCODE=NOERROR
	and with the last client supplied TKEY record in the answer		and with the last client supplied TKEY record in the answer
	section of the query. The response MUST be signed with a TSIG		section of the query. The response MUST be signed with a TSIG
	record. Note that the server is allowed to sign a response to		record. Note that the server is allowed to sign a response to
	unsigned client's query due to modification to the RFC 2845		unsigned client's query due to modification to the RFC 2845
	specified in Section 2.2 above. The signature in the TSIG record		specified in Section 2.2 above. The signature in the TSIG record
	MUST be verified using the procedure detailed in section 5,		MUST be verified using the procedure detailed in section 5,
	Sending and Verifying Signed Messages. If the response is not		Sending and Verifying Signed Messages. If the response is not
	signed, OR if the response is signed but the signature is invalid,		signed, OR if the response is signed but the signature is invalid,
	then an attacker has tampered with the message in transit or has		then an attacker has tampered with the message in transit or has
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 42 ¶
	Sending and Verifying Signed Messages. If the response is not		Sending and Verifying Signed Messages. If the response is not
	signed, OR if the response is signed but the signature is invalid,		signed, OR if the response is signed but the signature is invalid,
	then an attacker has tampered with the message in transit or has		then an attacker has tampered with the message in transit or has
	attempted to send the client a false response. In this case, the		attempted to send the client a false response. In this case, the
	client MAY continue waiting for a response to its last TKEY query		client MAY continue waiting for a response to its last TKEY query
	until the time period since the client sent 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		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		the client. This is a new option that allows the DNS client to
	accept multiple answers for one query ID and select one (not		accept multiple answers for one query ID and select one (not
	necessarily the first one) based on some criteria.		necessarily the first one) based on some criteria.
	to		to
	Confirmation is in the form of a query response with RCODE=NOERROR		Confirmation is in the form of a query response with RCODE=NOERROR
	and with the last client supplied TKEY record in the answer		and with the last client supplied TKEY record in the answer
	section of the query. The response MAY be signed with a TSIG		section of the query. The response MAY be signed with a TSIG
	record. Note that the server is allowed to sign a response to		record. Note that the server is allowed to sign a response to
	unsigned client's query due to modification to the RFC 2845		unsigned client's query due to modification to the RFC 2845
	specified in Section 2.2 above.		specified in Section 2.2 above.
	Alert readers will note that the latter change removes more text than
	just the gratuitous TSIG check per se. The remainder of the
	paragraph in question is not relevant once the requirement to check
	the gratuitous TSIG has been relaxed, and as the last few sentences
	of the paragraph demonstrate a serious misunderstanding of how the
	DNS and TKEY protocols work, simply removing the now-irrelevant text
	seems best.
	5. IANA Considerations		5. IANA Considerations
	This document has no IANA Considerations.		This document has no IANA Considerations.
	6. Security Considerations		6. Security Considerations
	This note proposes a minor simplification to an excessively complex		This note proposes a minor simplification to an excessively complex
	channel security mechanism. To the best of the authors' knowledge,		channel security mechanism. To the best of the authors' knowledge,
	this change does not weaken the mechanism.		this change does not weaken the mechanism.
	skipping to change at page 9, line 5 ¶		skipping to change at page 8, line 5 ¶
	Email: sra@isc.org		Email: sra@isc.org
	Michael Graff		Michael Graff
	ISC		ISC
	950 Charter Street		950 Charter Street
	Redwood City, CA 94063		Redwood City, CA 94063
	USA		USA
	Email: michael_graff@isc.org		Email: michael_graff@isc.org
	Intellectual Property Statement		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		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 9, line 29 ¶		skipping to change at page 8, line 45 ¶
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	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.
	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.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 19 change blocks.
	44 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/