draft-ietf-dnsext-tkey-02.txt		draft-ietf-dnsext-tkey-03.txt
	DNSEXT Working Group Donald E. Eastlake, 3rd		DNSEXT Working Group Donald E. Eastlake, 3rd
	INTERNET-DRAFT Motorola		INTERNET-DRAFT Motorola
	Expires: October 2000 April 2000		Expires: December 2000 June 2000
	Secret Key Establishment for DNS (TKEY RR)		Secret Key Establishment for DNS (TKEY RR)
	------ --- ------------- --- --- ----- ---		------ --- ------------- --- --- ----- ---
	<draft-ietf-dnsext-tkey-02.txt>		<draft-ietf-dnsext-tkey-03.txt>
	Status of This Document		Status of This Document
	This draft is intended to be become a Proposed Standard RFC.		This draft is intended to be become a Proposed Standard RFC.
	Distribution of this document is unlimited. Comments should be sent		Distribution of this document is unlimited. Comments should be sent
	to the DNS working group mailing list <namedroppers@ops.ietf.org> or		to the DNS working group mailing list <namedroppers@ops.ietf.org> or
	to the author.		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
	[draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating		[draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating
	skipping to change at page 2, line 26		skipping to change at page 2, line 26
	The comments and ideas of the following persons (listed in alphabetic		The comments and ideas of the following persons (listed in alphabetic
	order) have been incorporated herein and are gratefully acknowledged:		order) have been incorporated herein and are gratefully acknowledged:
	Olafur Gudmundsson (TIS)		Olafur Gudmundsson (TIS)
	Stuart Kwan (Microsoft)		Stuart Kwan (Microsoft)
	Ed Lewis (TIS)		Ed Lewis (TIS)
	Brian Wellington (TIS)		Erik Nordmark (SUN)
			Brian Wellington (Nominum)
	Table of Contents		Table of Contents
	Status of This Document....................................1		Status of This Document....................................1
	Abstract...................................................2		Abstract...................................................2
	Acknowledgments............................................2		Acknowledgments............................................2
	Table of Contents..........................................3		Table of Contents..........................................3
	skipping to change at page 12, line 43		skipping to change at page 12, line 43
	The resolver KEY RR MUST be authenticated, through the authentication		The resolver KEY RR MUST be authenticated, through the authentication
	of this query with a TSIG or SIG(0) or the signing of the resolver		of this query with a TSIG or SIG(0) or the signing of the resolver
	KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY		KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY
	for which they know the private key, and thereby the attacker could		for which they know the private key, and thereby the attacker could
	obtain a valid shared secret key from the server.		obtain a valid shared secret key from the server.
	4.5 Query for Resolver Assigned Keying		4.5 Query for Resolver Assigned Keying
	Optionally, a server can accept resolver assigned keys. The keying		Optionally, a server can accept resolver assigned keys. The keying
	material must be encrypted under a server key for protection in		material MUST be encrypted under a server key for protection in
	transmission as described in Section 6.		transmission as described in Section 6.
	The resolver sends a TKEY query with a TKEY RR that specifies the		The resolver sends a TKEY query with a TKEY RR that specifies the
	encrypted keying material and a KEY RR specifying the server public		encrypted keying material and a KEY RR specifying the server public
	key used to encrypt the data, both in the additional information		key used to encrypt the data, both in the additional information
	section. The name of the key and the keying data are completely		section. The name of the key and the keying data are completely
	controlled by the sending resolver so a globally unique key name		controlled by the sending resolver so a globally unique key name
	SHOULD be used. The KEY RR used MUST be one for which the server has		SHOULD be used. The KEY RR used MUST be one for which the server has
	the corresponding private key, or it will not be able to decrypt the		the corresponding private key, or it will not be able to decrypt the
	keying material and will return a FORMERR, and for which no untrusted		keying material and will return a FORMERR. It is also important that
	party (preferably no other party than the server) has the private		no untrusted party (preferably no other party than the server) has
	key, or the untrusted private key holder can capture the messages to		the private key corresponding to the KEY RR because, if they do, they
	the server, learn the shared secret, and spoof valid TSIGs.		can capture the messages to the server, learn the shared secret, and
			spoof valid TSIGs.
	The query TKEY RR inception and expiry give the time period the		The query TKEY RR inception and expiry give the time period the
	querier intends to consider the keying material valid. The server		querier intends to consider the keying material valid. The server
	can return a lesser time interval to advise that it will not maintain		can return a lesser time interval to advise that it will not maintain
	state for that long and can pre-expire keys in any case.		state for that long and can pre-expire keys in any case.
	This mode of query MUST be authenticated with a TSIG or SIG(0).		This mode of query MUST be authenticated with a TSIG or SIG(0).
	Otherwise, an attacker can forge a resolver assigned TKEY query, and		Otherwise, an attacker can forge a resolver assigned TKEY query, and
	thereby the attacker could specify a shared secret key that would be		thereby the attacker could specify a shared secret key that would be
	accepted, used, and honored by the server.		accepted, used, and honored by the server.
	skipping to change at page 13, line 43		skipping to change at page 13, line 44
	A server can optionally tell a client that it has deleted a secret		A server can optionally tell a client that it has deleted a secret
	key by spontaneously including a TKEY RR in the additional		key by spontaneously including a TKEY RR in the additional
	information section of a response with the key's name and specifying		information section of a response with the key's name and specifying
	the key deletion mode. Such a response SHOULD be authenticated. If		the key deletion mode. Such a response SHOULD be authenticated. If
	authenticated, it "deletes" the key with the given name. The		authenticated, it "deletes" the key with the given name. The
	inception and expiry times of the delete TKEY RR are ignored. Failure		inception and expiry times of the delete TKEY RR are ignored. Failure
	by a client to receive or properly process such additional		by a client to receive or properly process such additional
	information in a response would mean that the client might use a key		information in a response would mean that the client might use a key
	that the server had discarded and would then get an error indication.		that the server had discarded and would then get an error indication.
	For server assigned and Diffie-Hellman keys, the client must truly		For server assigned and Diffie-Hellman keys, the client MUST
	"discard" all active state associated with the key. For querier		"discard" active state associated with the key. For querier assigned
	assigned keys, the querier MAY simply mark the key as no longer		keys, the querier MAY simply mark the key as no longer retained by
	retained by the server and may re-send it in a future query		the server and may re-send it in a future query specifying querier
	specifying querier assigned keying material.		assigned keying material.
	6. Methods of Encryption		6. Methods of Encryption
	For the server assigned and resolver assigned key agreement modes,		For the server assigned and resolver assigned key agreement modes,
	the keying material is sent within the key data field of a TKEY RR		the keying material is sent within the key data field of a TKEY RR
	encrypted under the public key in an accompanying KEY RR [RFC 2535].		encrypted under the public key in an accompanying KEY RR [RFC 2535].
	This KEY RR MUST be for a public key algorithm where the public and		This KEY RR MUST be for a public key algorithm where the public and
	private keys can be used for encryption and the corresponding		private keys can be used for encryption and the corresponding
	decryption which recovers the originally encrypted data. The KEY RR		decryption which recovers the originally encrypted data. The KEY RR
	SHOULD correspond to a name for the decrypting resolver/server such		SHOULD correspond to a name for the decrypting resolver/server such
	skipping to change at page 14, line 49		skipping to change at page 14, line 49
	consideration should be given before the allocation of meaning for		consideration should be given before the allocation of meaning for
	Mode field values 0x0000 and 0xFFFF.		Mode field values 0x0000 and 0xFFFF.
	Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF		Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
	are allocated by IESG approval or IETF consensus.		are allocated by IESG approval or IETF consensus.
	Mode field values 0x1000 through 0xEFFF are allocated based on		Mode field values 0x1000 through 0xEFFF are allocated based on
	Specification Required as defined in [RFC 2434].		Specification Required as defined in [RFC 2434].
	Mode values should not be changed when the status of their use		Mode values should not be changed when the status of their use
	changes. For example, a mode value assigned for an Experimental		changes. For example, a mode value assigned based just on providing
	Standard should not be changed later just because that standard's		a specification should not be changed later just because that use's
	status is changed to Proposed.		status is changed to standards track.
	The following assignments are documented herein:		The following assignments are documented herein:
	RR Type 249 for TKEY.		RR Type 249 for TKEY.
	TKEY Modes 1 through 5 as listed in section 2.5.		TKEY Modes 1 through 5 as listed in section 2.5.
	Extended RCODE Error values of 19, 20, and 21 as listed in		Extended RCODE Error values of 19, 20, and 21 as listed in
	section 2.6.		section 2.6.
	skipping to change at page 17, line 9		skipping to change at page 17, line 9
	RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain		RFC 2539 - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
	Name System (DNS)", March 1999.		Name System (DNS)", March 1999.
	draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D.		draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D.
	Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".		Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".
	Author's Address		Author's Address
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	Motorola		Motorola
	65 Shindegan Hill Road, RR #1		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-tkey-02.txt.		Its file name is draft-ietf-dnsext-tkey-03.txt.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/