< draft-ietf-dnsext-simple-secure-update-01.txt		draft-ietf-dnsext-simple-secure-update-02.txt >
	DNSIND Working Group Brian Wellington (NAILabs)		DNSEXT Working Group Brian Wellington (Nominum)
	<draft-ietf-dnsext-simple-secure-update-01.txt>		INTERNET-DRAFT October 2000
	Updates: RFC 2535, RFC 2136,		<draft-ietf-dnsext-simple-secure-update-02.txt>
	Replaces: RFC 2137, [update2]
			Updates: RFC 2535, RFC 2136
			Replaces: RFC 2137
	Secure Domain Name System (DNS) Dynamic Update		Secure Domain Name System (DNS) Dynamic Update
	Status of this Memo		Status of this Memo
	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.		all provisions of Section 10 of RFC2026.
	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 31 ¶		skipping to change at page 1, line 33 ¶
	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
	Comments should be sent to the authors or the DNSIND WG mailing list		Comments should be sent to the authors or the DNSEXT WG mailing list
	namedroppers@internic.net.		namedroppers@ops.ietf.org.
	This draft expires on November 12, 2000.		This draft expires on April 2, 2000.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2000). All rights reserved.		Copyright (C) The Internet Society (2000). All rights reserved.
	Abstract		Abstract
	This document proposes a method for performing secure Domain Name		This document proposes a method for performing secure Domain Name
	System (DNS) dynamic updates. The method described here is intended		System (DNS) dynamic updates. The method described here is intended
	to be flexible and useful while requiring as few changes to the		to be flexible and useful while requiring as few changes to the
	protocol as possible. The authentication of the dynamic update		protocol as possible. The authentication of the dynamic update
	message is separate from later DNSSEC validation of the data. Secure		message is separate from later DNSSEC validation of the data. Secure
	communication based on authenticated requests and transactions is		communication based on authenticated requests and transactions is
	used to provide authorization.		used to provide authorization.
			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 RFC 2119 [RFC2119].
	1 - Introduction		1 - Introduction
	This document defines a means to secure dynamic updates of the Domain		This document defines a means to secure dynamic updates of the Domain
	Name System (DNS), allowing only authorized sources to make changes to a		Name System (DNS), allowing only authorized sources to make changes to a
	zone's contents. The existing unsecured dynamic update operations form		zone's contents. The existing unsecured dynamic update operations form
	the basis for this work.		the basis for this work.
	Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update		Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
	[RFC2136] is helpful and is assumed by this document. In addition,		[RFC2136] is helpful and is assumed by this document. In addition,
	knowledge of DNS security extensions [RFC2535], SIG(0) transaction		knowledge of DNS security extensions [RFC2535], SIG(0) transaction
	security [RFC2535], and TSIG transaction security [TSIG] is recommended.		security [RFC2535, RFC2931], and TSIG transaction security [RFC2845] is
			recommended.
	This document updates portions of RFC 2535, in particular section 3.1.2.		This document updates portions of RFC 2535, in particular section 3.1.2,
	This document obsoletes RFC 2137, an alternate proposal for secure		and RFC 2136. This document obsoletes RFC 2137, an alternate proposal
	dynamic update, due to implementation experience.		for secure dynamic update, due to implementation experience.
	1.1 - Overview of DNS Dynamic Update		1.1 - Overview of DNS Dynamic Update
	DNS dynamic update defines a new DNS opcode and a new interpretation of		DNS dynamic update defines a new DNS opcode and a new interpretation of
	the DNS message if that opcode is used. An update can specify		the DNS message if that opcode is used. An update can specify
	insertions or deletions of data, along with prerequisites necessary for		insertions or deletions of data, along with prerequisites necessary for
	the updates to occur. All tests and changes for a DNS update request		the updates to occur. All tests and changes for a DNS update request
	are restricted to a single zone, and are performed at the primary server		are restricted to a single zone, and are performed at the primary server
	for the zone. The primary server for a dynamic zone must increment the		for the zone. The primary server for a dynamic zone must increment the
	zone SOA serial number when an update occurs or before the next		zone SOA serial number when an update occurs or before the next
	retrieval of the SOA.		retrieval of the SOA.
	1.2 - Overview of DNS Transaction Security		1.2 - Overview of DNS Transaction Security
	Exchanges of DNS messages which include TSIG [TSIG] or SIG(0) [RFC2535]		Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0)
	records allow two DNS entities to authenticate DNS requests and		[RFC2535, RFC2931] records allow two DNS entities to authenticate DNS
	responses sent between them. A TSIG MAC (message authentication code)		requests and responses sent between them. A TSIG MAC (message
	is derived from a shared secret, and a SIG(0) is generated from a		authentication code) is derived from a shared secret, and a SIG(0) is
	private key whose public counterpart is stored in DNS. In both cases, a		generated from a private key whose public counterpart is stored in DNS.
	record containing the message signature/MAC is included as the final		In both cases, a record containing the message signature/MAC is included
	resource record in a DNS message. Keyed hashes, used in TSIG, are		as the final resource record in a DNS message. Keyed hashes, used in
	inexpensive to calculate and verify. Public key encryption, as used in		TSIG, are inexpensive to calculate and verify. Public key encryption,
	SIG(0), is more scalable as the public keys are stored in DNS.		as used in SIG(0), is more scalable as the public keys are stored in
			DNS.
	1.3 - Comparison of data authentication and message authentication		1.3 - Comparison of data authentication and message authentication
	Message based authentication, using TSIG or SIG(0), provides protection		Message based authentication, using TSIG or SIG(0), provides protection
	for the entire message with a single signing and single verification		for the entire message with a single signing and single verification
	which, in the case of TSIG, is a relatively inexpensive MAC creation and		which, in the case of TSIG, is a relatively inexpensive MAC creation and
	check. For update requests, this signature can establish, based on		check. For update requests, this signature can establish, based on
	policy or key negotation, the authority to make the request.		policy or key negotation, the authority to make the request.
	DNSSEC SIG records can be used to protect the integrity of individual		DNSSEC SIG records can be used to protect the integrity of individual
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 49 ¶
	As specified in [signing-auth], the DNSSEC validation process performed		As specified in [signing-auth], the DNSSEC validation process performed
	by a resolver MUST NOT process any non-zone keys unless local policy		by a resolver MUST NOT process any non-zone keys unless local policy
	dictates otherwise. When performing secure dynamic update, all zone		dictates otherwise. When performing secure dynamic update, all zone
	data modified in a signed zone MUST be signed by a relevant zone key.		data modified in a signed zone MUST be signed by a relevant zone key.
	This completely disassociates authentication of an update request from		This completely disassociates authentication of an update request from
	authentication of the data itself.		authentication of the data itself.
	The primary usefulness of host and user keys, with respect to DNSSEC, is		The primary usefulness of host and user keys, with respect to DNSSEC, is
	to authenticate messages, including dynamic updates. Thus, host and		to authenticate messages, including dynamic updates. Thus, host and
	user keys MAY be used to generate SIG(0) records to authenticate updates		user keys MAY be used to generate SIG(0) records to authenticate updates
	and MAY be used in the TKEY [TKEY] process to generate TSIG shared		and MAY be used in the TKEY [RFC2930] process to generate TSIG shared
	secrets. In both cases, no SIG records generated by non-zone keys will		secrets. In both cases, no SIG records generated by non-zone keys will
	be used in a DNSSEC validation process unless local policy dictates.		be used in a DNSSEC validation process unless local policy dictates.
	Authentication of data, once it is present in DNS, only involves DNSSEC		Authentication of data, once it is present in DNS, only involves DNSSEC
	zone keys and signatures generated by them.		zone keys and signatures generated by them.
	1.5 - Signatory strength		1.5 - Signatory strength
	[RFC2535, section 3.1.2] defines the signatory field of a key as the		[RFC2535, section 3.1.2] defines the signatory field of a key as the
	final 4 bits of the flags field, but does not define its value. This		final 4 bits of the flags field, but does not define its value. This
	proposal leaves this field undefined. Updating [RFC2535], this field		proposal leaves this field undefined. Updating [RFC2535], this field
	SHOULD be set to 0 in KEY records, and MUST be ignored.		SHOULD be set to 0 in KEY records, and MUST be ignored.
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 31 ¶
	Considerations section.		Considerations section.
	3.2 - Additional policies		3.2 - Additional policies
	Users are free to implement any policies. Policies may be as specific		Users are free to implement any policies. Policies may be as specific
	or general as desired, and as complex as desired. They may depend on		or general as desired, and as complex as desired. They may depend on
	the principal or any other characteristics of the signed message.		the principal or any other characteristics of the signed message.
	4 - Interaction with DNSSEC		4 - Interaction with DNSSEC
			Although this protocol does not change the way updates to secure zones
			are processed, there are a number of issues that should be clarified.
			4.1 - Adding SIGs
	An authorized update request MAY include SIG records with each RRset.		An authorized update request MAY include SIG records with each RRset.
	Since SIG records (except SIG(0) records) MUST NOT be used for		Since SIG records (except SIG(0) records) MUST NOT be used for
	authentication of the update message, they are not required. If the		authentication of the update message, they are not required.
	updated zone is secured, the data affected by an update operation MUST
	be secured by one or more SIG records. For each RRset, if the update
	includes a valid signature by a zone key, this signature SHOULD be
	reused. Otherwise, the server MUST generate SIG records with one or
	more zone keys (of which the private components MUST be online). If
	multiple zone keys are online and an RRset requires a signature, a SIG
	MUST be generated by at least one of the zone keys.
	If a principal is authorized to add SIG records and there are SIG		If a principal is authorized to update SIG records and there are SIG
	records in the request, the following rules are applied. If the SIG was		records in the update, the SIG records are added without verification.
	generated by a zone key for the relevant zone, verification is attempted		The server MAY examine SIG records and drop SIGs with a temporal
	(the public key must be available if the determination that it is a zone		validity period in the past.
	key was made). If successful, the SIG is retained; otherwise, the SIG
	is dropped. Otherwise, the SIG is retained without verification, since
	it is considered immaterial to the DNSSEC validation process. The
	server MAY examine SIG records and drop SIGs with a temporal validity
	period in the past. At the completion of the update process, each
	updated RRset must be signed in accordance with the zone's signing
	policy; the SIGs must either be included in the update or generated by
	the server.
	The server MUST also, if necessary, generate a new SOA record and new		4.2 - Deleting SIGs
	NXT records, and sign these with the appropriate zone keys. NXT records
	are explicitly forbidden. SOA updates are allowed, since the		If a principal is authorized to update SIG records and the update
	maintenance of SOA parameters is outside of the scope of the DNS		specifies the deletion of SIG records, the server MAY choose to override
	protocol.		the authority and refuse the update. For example, the server may allow
			all SIG records not generated by a zone key to be deleted.
			4.3 - Non-explicit updates to SIGs
			If the updated zone is secured, the RRset affected by an update
			operation MUST, at the completion of the update, be signed in accordance
			with the zone's signing policy. This will usually require one or more
			SIG records to be generated by one or more zone keys whose private
			components MUST be online [signing-auth].
			When the contents of an RRset are updated, the server MAY delete all
			associated SIG records, since they will no longer be valid.
			4.4 - Effects on the zone
			If any changes are made, the server MUST, if necessary, generate a new
			SOA record and new NXT records, and sign these with the appropriate zone
			keys. Changes to NXT records by secure dynamic update are explicitly
			forbidden. SOA updates are allowed, since the maintenance of SOA
			parameters is outside of the scope of the DNS protocol.
	5 - Security considerations		5 - Security considerations
	This document requires that a zone key and possibly other cryptographic		This document requires that a zone key and possibly other cryptographic
	secret material be held in an on-line, network-connected host, most		secret material be held in an on-line, network-connected host, most
	likely a name server. This material is at the mercy of host security to		likely a name server. This material is at the mercy of host security to
	remain a secret. Exposing this secret puts DNS data at risk of		remain a secret. Exposing this secret puts DNS data at risk of
	masquerade attacks. The data at risk is that in both zones served by		masquerade attacks. The data at risk is that in both zones served by
	the machine and delegated from this machine.		the machine and delegated from this machine.
	Allowing updates of KEY records may lead to undesirable results, since a		Allowing updates of KEY records may lead to undesirable results, since a
	principal may be allowed to insert a public key without holding the		principal may be allowed to insert a public key without holding the
	private key, and possibly masquerade as the key owner.		private key, and possibly masquerade as the key owner.
	6 - Acknowledgements		6 - Acknowledgements
	The author would like to thank the following people for review and		The author would like to thank the following people for review and
	informative comments (in alphabetical order):		informative comments (in alphabetical order):
			Harald Alvestrand
	Donald Eastlake		Donald Eastlake
	Olafur Gudmundsson		Olafur Gudmundsson
	Andreas Gustafsson		Andreas Gustafsson
	Bob Halley		Bob Halley
	Stuart Kwan		Stuart Kwan
	Ed Lewis		Ed Lewis
	7 - References		7 - References
	[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''		[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,''
	skipping to change at page 7, line 46 ¶		skipping to change at page 8, line 21 ¶
	Specification,'' RFC 1035, ISI, November 1987.		Specification,'' RFC 1035, ISI, November 1987.
	[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic		[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
	Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore		Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore
	& Cisco & DEC, April 1997.		& Cisco & DEC, April 1997.
	[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC		[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC
	2137, CyberCash, April 1997.		2137, CyberCash, April 1997.
	[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC		[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,'' RFC
	2065, IBM, March 1999.		2535, IBM, March 1999.
	[TSIG] P. Vixie (Ed.), O. Gudmundsson, D. Eastlake, B. Wellington		[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington ``Secret
	``Secret Key Transaction Signatures for DNS (TSIG),'' draft-		Key Transaction Signatures for DNS (TSIG),'' RFC 2845, ISC &
	ietf-dnsext-tsig-00.txt, ISC & NAILabs & IBM & NAILabs, March		NAILabs & Motorola & Nominum, May 2000.
	2000.
	[TKEY] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''		[RFC2930] D. Eastlake ``Secret Key Establishment for DNS (TKEY RR),''
	draft-ietf-dnsext-tkey-02.txt, IBM, April 2000.		RFC 2930, Motorola, September 2000.
			[RFC2931] D. Eastlake ``DNS Request and Transaction Signatures (
			SIG(0)s ),'' RFC 2931, Motorola, September 2000.
	[signing-auth]		[signing-auth]
	B. Wellington ``Domain Name System Security (DNSSEC) Signing		B. Wellington ``Domain Name System Security (DNSSEC) Signing
	Authority,'' draft-ietf-dnsext-signing-auth-01.txt, Nominum,		Authority,'' draft-ietf-dnsext-signing-auth-02.txt, Nominum,
	May 2000.		October 2000.
	8 - Author's Address		8 - Author's Address
	Brian Wellington		Brian Wellington
	Nominum, Inc.		Nominum, Inc.
	950 Charter Street		950 Charter Street
	Redwood City, CA 94063		Redwood City, CA 94063
	+1 650 779 6022		+1 650 779 6022
	<Brian.Wellington@nominum.com>		<Brian.Wellington@nominum.com>
End of changes. 19 change blocks.
	55 lines changed or deleted		76 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/