< draft-ietf-dnsext-sig-zero-01.txt		draft-ietf-dnsext-sig-zero-02.txt >
	INTERNET-DRAFT Donald E. Eastlake 3rd		INTERNET-DRAFT Donald E. Eastlake 3rd
	UPDATES RFC 2535 Motorola		UPDATES RFC 2535 Motorola
	Expires: October 2000 April 2000		Expires: December 2000 June 2000
	DNS Request and Transaction Signatures ( SIG(0)s )		DNS Request and Transaction Signatures ( SIG(0)s )
	--- ------- --- ----------- ---------- - ------- -		--- ------- --- ----------- ---------- - ------- -
	<draft-ietf-dnsext-sig-zero-01.txt>		<draft-ietf-dnsext-sig-zero-02.txt>
	Status of This Document		Status of This Document
	This draft is intended to become a Proposed Standard RFC updating		This draft is intended to become a Proposed Standard RFC updating
	Proposed Standard [RFC 2535]. Distribution of this document is		Proposed Standard [RFC 2535]. Distribution of this document is
	unlimited. Comments should be sent to the DNS Working Group mailing		unlimited. Comments should be sent to the DNS Working Group mailing
	list <namedroppers@internic.net> or to the author.		list <namedroppers@internic.net> or to the author.
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		all provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months. Internet-Drafts may be updated, replaced, or obsoleted by		and may be updated, replaced, or obsoleted by other documents at any
	other documents at any time. It is not appropriate to use Internet-		time. It is inappropriate to use Internet- Drafts as reference
	Drafts as reference material or to cite them other than as a		material or to cite them other than as "work in progress."
	``working draft'' or ``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.
	Abstract		Abstract
	Extensions to the Domain Name System (DNS) are described in [RFC		Extensions to the Domain Name System (DNS) are described in [RFC
	2535] that can provide data origin and transaction integrity and		2535] that can provide data origin and transaction integrity and
	authentication to security aware resolvers and applications through		authentication to security aware resolvers and applications through
	the use of cryptographic digital signatures.		the use of cryptographic digital signatures.
	Implementation experience has indicated the need for minor but non-		Implementation experience has indicated the need for minor but non-
	interoperable changes in Request and Transaction signature resource		interoperable changes in Request and Transaction signature resource
	records ( SIG(0)s ). These changes are documented herein.		records ( SIG(0)s ). These changes are documented herein.
	Acknowledgments		Acknowledgments
	The significant contributions and suggestions of the following		The contributions and suggestions of the following persons (in
	persons (in alphabetic order) to this draft are gratefully		alphabetic order) to this draft are gratefully acknowledged:
	acknowledged:
	Olafur Gudmundsson		Olafur Gudmundsson
	Ed Lewis		Ed Lewis
			Erik Nordmark
	Brian Wellington		Brian Wellington
	Table of Contents		Table of Contents
	Status of This Document....................................1		Status of This Document....................................1
	Abstract...................................................1		Abstract...................................................1
	Acknowledgments............................................2		Acknowledgments............................................2
	Table of Contents..........................................2		Table of Contents..........................................2
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	provide protected data resource records (RRs) or authenticatably deny		provide protected data resource records (RRs) or authenticatably deny
	their nonexistence. These services provide no protection for glue		their nonexistence. These services provide no protection for glue
	records, DNS requests, no protection for message headers on requests		records, DNS requests, no protection for message headers on requests
	or responses, and no protection of the overall integrity of a		or responses, and no protection of the overall integrity of a
	response.		response.
	2.1 Transaction Authentication		2.1 Transaction Authentication
	Transaction authentication means that a requester can be sure it is		Transaction authentication means that a requester can be sure it is
	at least getting the messages from the server it queried and that the		at least getting the messages from the server it queried and that the
	received messages are in response to me query it sent. This is		received messages are in response to the query it sent. This is
	accomplished by optionally adding either a TSIG RR [draft-ietf-		accomplished by optionally adding either a TSIG RR [draft-ietf-
	dnsext-tsig-*.txt] or, as described herein, a SIG(0) resource record		dnsext-tsig-*.txt] or, as described herein, a SIG(0) resource record
	at the end of the response which digitally signs the concatenation of		at the end of the response which digitally signs the concatenation of
	the server's response and the corresponding resolver query.		the server's response and the corresponding resolver query.
	2.2 Request Authentication		2.2 Request Authentication
	Requests can also be authenticated by including a TSIG or, as		Requests can also be authenticated by including a TSIG or, as
	described herein, a special SIG(0) RR at the end of the request.		described herein, a special SIG(0) RR at the end of the request.
	Authenticating requests serves no function in DNS servers the predate		Authenticating requests serves no function in DNS servers the predate
	skipping to change at page 5, line 42 ¶		skipping to change at page 5, line 42 ¶
	originating host and there MUST be a KEY RR at that name with the		originating host and there MUST be a KEY RR at that name with the
	public key corresponding to the private key used to calculate the		public key corresponding to the private key used to calculate the
	signature. (The host domain name used may be the inverse IP address		signature. (The host domain name used may be the inverse IP address
	mapping name for an IP address of the host if the relevant KEY is		mapping name for an IP address of the host if the relevant KEY is
	stored there.)		stored there.)
	For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are		For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
	meaningless. The TTL fields SHOULD be zero and the CLASS field		meaningless. The TTL fields SHOULD be zero and the CLASS field
	SHOULD be ANY. To conserve space, the owner name SHOULD be root (a		SHOULD be ANY. To conserve space, the owner name SHOULD be root (a
	single zero octet). When SIG(0) authentication on a response is		single zero octet). When SIG(0) authentication on a response is
	desired, that SIG RR must be considered the highest priority of any		desired, that SIG RR MUST be considered the highest priority of any
	additional information for inclusion in the response. If the SIG(0)		additional information for inclusion in the response. If the SIG(0)
	RR cannot be added without causing the message to be truncated, the		RR cannot be added without causing the message to be truncated, the
	server MUST alter the response so that a SIG(0) can be included.		server MUST alter the response so that a SIG(0) can be included.
	This response consists of only the question and a SIG(0) record, and		This response consists of only the question and a SIG(0) record, and
	has the TC bit set and RCODE 0 (NOERROR). The client should at this		has the TC bit set and RCODE 0 (NOERROR). The client should at this
	point retry the request using TCP.		point retry the request using TCP.
	3.1 Calculating Request and Transaction SIGs		3.1 Calculating Request and Transaction SIGs
	A DNS request may be optionally signed by including one SIG(0)s at		A DNS request may be optionally signed by including one SIG(0)s at
	the end of the query additional information section. Such a SIG is		the end of the query additional information section. Such a SIG is
	identified by having a "type covered" field of zero. It signs the		identified by having a "type covered" field of zero. It signs the
	preceding DNS request message including DNS header but not including		preceding DNS request message including DNS header but not including
	the UDP/IP header and before the request RR counts have been adjusted		the UDP/IP header and before the request RR counts have been adjusted
	for the inclusions of the request SIG(0).		for the inclusions of the request SIG(0).
	It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of		It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
	(1) the SIG's RDATA section omitting the signature subfield itself,		(1) the SIG's RDATA section entirely omitting (not just zeroing) the
	(2) the entire DNS query messages, including DNS header, but not the		signature subfield itself, (2) the DNS query messages, including DNS
	UDP/IP header and before the reply RR counts have been adjusted for		header, but not the UDP/IP header and before the reply RR counts have
	the inclusion of the SIG(0). That is		been adjusted for the inclusion of the SIG(0). That is
	data = RDATA | request - SIG(0)		data = RDATA | request - SIG(0)
	where "|" is concatenation and RDATA is the RDATA of the SIG(0) being		where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
	calculated less the signature itself.		calculated less the signature itself.
	Similarly, a SIG(0) can be used to secure a response and the request		Similarly, a SIG(0) can be used to secure a response and the request
	that produced it. Such transaction signatures are calculated by		that produced it. Such transaction signatures are calculated by
	using a "data" of (1) the SIG's RDATA section omitting the signature		using a "data" of (1) the SIG's RDATA section omitting the signature
	itself, (2) the entire DNS query message that produced this response,		itself, (2) the entire DNS query message that produced this response,
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 12 ¶
	where "|" is concatenations, RDATA is as above, and previous packet		where "|" is concatenations, RDATA is as above, and previous packet
	is the previous DNS payload including DNS header and the SIG(0) but		is the previous DNS payload including DNS header and the SIG(0) but
	not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an		not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an
	alternative, TSIG may be used after, if necessary, setting up a key		alternative, TSIG may be used after, if necessary, setting up a key
	with TKEY [draft-ietf-dnsext-tkey-*.txt].		with TKEY [draft-ietf-dnsext-tkey-*.txt].
	Except where needed to authenticate an update, TKEY, or similar		Except where needed to authenticate an update, TKEY, or similar
	privileged request, servers are not required to check a request		privileged request, servers are not required to check a request
	SIG(0).		SIG(0).
	Note: requests and response can either have a single TSIG or one		Note: requests and responses can either have a single TSIG or one
	SIG(0) but not both a TSIG and a SIG(0).		SIG(0) but not both a TSIG and a SIG(0).
	3.2 Processing Responses and SIG(0) RRs		3.2 Processing Responses and SIG(0) RRs
	If a SIG RR is at the end of the additional information section of a		If a SIG RR is at the end of the additional information section of a
	response and has a type covered of zero, it is a transaction		response and has a type covered of zero, it is a transaction
	signature covering the response and the query that produced the		signature covering the response and the query that produced the
	response. For TKEY responses, it MUST be checked and the message		response. For TKEY responses, it MUST be checked and the message
	rejected if the checks fail unless otherwise specified for the TKEY		rejected if the checks fail unless otherwise specified for the TKEY
	mode in use. For all other responses, it MAY be checked and the		mode in use. For all other responses, it MAY be checked and the
	message rejected if the checks fail.		message rejected if the checks fail.
	If a responses SIG(0) check succeed, such a transaction		If a response's SIG(0) check succeed, such a transaction
	authentication SIG does NOT directly authenticate the validity any		authentication SIG does NOT directly authenticate the validity any
	data-RRs in the message. However, it authenticates that they were		data-RRs in the message. However, it authenticates that they were
	sent by the queried server and have not been diddled. (Only a proper		sent by the queried server and have not been diddled. (Only a proper
	SIG(0) RR signed by the zone or a key tracing its authority to the		SIG(0) RR signed by the zone or a key tracing its authority to the
	zone or to static resolver configuration can directly authenticate		zone or to static resolver configuration can directly authenticate
	data-RRs, depending on resolver policy.) If a resolver or server does		data-RRs, depending on resolver policy.) If a resolver or server does
	not implement transaction and/or request SIGs, it MUST ignore them		not implement transaction and/or request SIGs, it MUST ignore them
	without error where they are optional and treat them as failing where		without error where they are optional and treat them as failing where
	they are required.		they are required.
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	4. Security Considerations		4. Security Considerations
	No additional considerations beyond those in [RFC 2535].		No additional considerations beyond those in [RFC 2535].
	The inclusion of the SIG(0) inception and expiration time under the		The inclusion of the SIG(0) inception and expiration time under the
	signature improves resistance to replay attacks.		signature improves resistance to replay attacks.
	5. IANA Considerations		5. IANA Considerations
	No new parameters are created or parameter values assigned by the		No new parameters are created or parameter values assigned by this
	document.		document.
	References		References
	[RFC 1982] - Robert Elz, Randy Bush, "Serial Number Arithmetic",		[RFC 1982] - Robert Elz, Randy Bush, "Serial Number Arithmetic",
	09/03/1996.		09/03/1996.
	[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate		[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", March 1997.		Requirement Levels", March 1997.
	skipping to change at page 9, line 9 ¶		skipping to change at page 9, line 9 ¶
	Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS		Eastlake, B. Wellington, "Secret Key Transaction Signatures for DNS
	(TSIG)".		(TSIG)".
	[draft-ietf-dnsext-tkey-*.txt] - D. Eastlake, "Secret Key		[draft-ietf-dnsext-tkey-*.txt] - D. Eastlake, "Secret Key
	Establishment for DNS (RR)".		Establishment for DNS (RR)".
	Author's Address		Author's Address
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	Motorola		Motorola
	65 Shindegan Hill Road		140 Forest Avenue
	Carmel, NY 10512 USA		Hudson, MA 01749 USA
	Telephone: +1-914-276-2668(h)		Telephone: +1-978-562-2827(h)
	+1-508-261-5434(w)		+1-508-261-5434(w)
	fax: +1-508-261-4447(w)		fax: +1 978-567-7941(h)
			+1-508-261-4447(w)
	email: Donald.Eastlake@motorola.com		email: Donald.Eastlake@motorola.com
	Expiration and File Name		Expiration and File Name
	This draft expires October 2000.		This draft expires December 2000.
	Its file name is draft-ietf-dnsext-sig-zero-01.txt.		Its file name is draft-ietf-dnsext-sig-zero-02.txt.
	Appendix: SIG(0) Changes from RFC 2535		Appendix: SIG(0) Changes from RFC 2535
	Add explanatory text concerning the differences between TSIG and		Add explanatory text concerning the differences between TSIG and
	SIG(0).		SIG(0).
	Change the data over which SIG(0) is calculated to include the SIG(0)		Change the data over which SIG(0) is calculated to include the SIG(0)
	RDATA other than the signature itself so as to secure the signature		RDATA other than the signature itself so as to secure the signature
	inception and expiration times and resist replay attacks. Specify		inception and expiration times and resist replay attacks. Specify
	SIG(0) for TCP.		SIG(0) for TCP.
	Add discussion of appropriate inception and expiration times for		Add discussion of appropriate inception and expiration times for
	SIG(0).		SIG(0).
	Add working to indicate that either a TSIG or one or more SIG(0)s may		Add wording to indicate that either a TSIG or one or more SIG(0)s may
	be present but not both.		be present but not both.
	Reword some areas for clarity.		Reword some areas for clarity.
End of changes. 17 change blocks.
	26 lines changed or deleted		26 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/