< draft-ietf-dnsext-tkey-03.txt		draft-ietf-dnsext-tkey-04.txt >
	DNSEXT Working Group Donald E. Eastlake, 3rd		DNSEXT Working Group Donald E. Eastlake, 3rd
	INTERNET-DRAFT Motorola		INTERNET-DRAFT Motorola
	Expires: December 2000 June 2000		Expires: January 2001 July 2000
	Secret Key Establishment for DNS (TKEY RR)		Secret Key Establishment for DNS (TKEY RR)
	------ --- ------------- --- --- ----- ---		------ --- ------------- --- --- ----- ---
	<draft-ietf-dnsext-tkey-03.txt>		<draft-ietf-dnsext-tkey-04.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 months		Internet-Drafts are draft documents valid for a maximum of six
	and may be updated, replaced, or obsoleted by other documents at any		months. Internet-Drafts may be updated, replaced, or obsoleted by
	time. It is inappropriate to use Internet- Drafts as reference		other documents at any time. It is not appropriate to use Internet-
	material or to cite them other than as "work in progress."		Drafts as reference material or to cite them other than as a
			``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.
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	Abstract		Abstract
	[draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating		[RFC 2845] provides a means of authenticating Domain Name System
	Domain Name System (DNS) queries and responses using shared secret		(DNS) queries and responses using shared secret keys via the TSIG
	keys via the TSIG resource record (RR). However, it provides no		resource record (RR). However, it provides no mechanism for setting
	mechanism for setting up such keys other than manual exchange. This		up such keys other than manual exchange. This document describes a
	document describes a TKEY RR that can be used in a number of		TKEY RR that can be used in a number of different modes to establish
	different modes to establish shared secret keys between a DNS		shared secret keys between a DNS resolver and server.
	resolver and server.
	Acknowledgments		Acknowledgments
	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)
	Erik Nordmark (SUN)		Erik Nordmark (SUN)
	Brian Wellington (Nominum)		Brian Wellington (Nominum)
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	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
	1. Introduction............................................4		1. Introduction............................................4
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	5.1 Spontaneous Server Key Deletion.......................13		5.1 Spontaneous Server Key Deletion.......................13
	6. Methods of Encryption..................................14		6. Methods of Encryption..................................14
	7. IANA Considerations....................................14		7. IANA Considerations....................................14
	8. Security Considerations................................15		8. Security Considerations................................15
	References................................................16		References................................................16
	Author's Address..........................................17		Author's Address..........................................17
	Expiration and File Name..................................17		Expiration and File Name..................................17
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	1. Introduction		1. Introduction
	The Domain Name System (DNS) is a hierarchical, distributed, highly		The Domain Name System (DNS) is a hierarchical, distributed, highly
	available database used for bi-directional mapping between domain		available database used for bi-directional mapping between domain
	names and addresses, for email routing, and for other information		names and addresses, for email routing, and for other information
	[RFC 1034, 1035]. It has been extended to provide for public key		[RFC 1034, 1035]. It has been extended to provide for public key
	security and dynamic update [RFC 2535, RFC 2136]. Familiarity with		security and dynamic update [RFC 2535, RFC 2136]. Familiarity with
	these RFCs is assumed.		these RFCs is assumed.
	[draft-ietf-dnsext-tsig-*.txt] provides a means of efficiently		[RFC 2845] provides a means of efficiently authenticating DNS
	authenticating DNS messages using shared secret keys via the TSIG		messages using shared secret keys via the TSIG resource record (RR)
	resource record (RR) but provides no mechanism for setting up such		but provides no mechanism for setting up such keys other than manual
	keys other than manual exchange. This document specifies a TKEY RR		exchange. This document specifies a TKEY RR that can be used in a
	that can be used in a number of different modes to establish and		number of different modes to establish and delete such shared secret
	delete such shared secret keys between a DNS resolver and server.		keys between a DNS resolver and server.
	Note that TKEY established keying material and TSIGs that use it are		Note that TKEY established keying material and TSIGs that use it are
	associated with DNS servers or resolvers. They are not associated		associated with DNS servers or resolvers. They are not associated
	with zones. They may be used to authenticate queries and responses		with zones. They may be used to authenticate queries and responses
	but they do not provide zone based DNS data origin or denial		but they do not provide zone based DNS data origin or denial
	authentication [RFC 2535].		authentication [RFC 2535].
	Certain modes of TKEY perform encryption which may affect their		Certain modes of TKEY perform encryption which may affect their
	export or import status for some countries. The affected modes		export or import status for some countries. The affected modes
	specified in this document are the server assigned mode and the		specified in this document are the server assigned mode and the
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 4 ¶
	and considerations for its constituent fields.		and considerations for its constituent fields.
	Section 3 describes general principles of operations with TKEY.		Section 3 describes general principles of operations with TKEY.
	Section 4 discusses key agreement and deletion via DNS requests with		Section 4 discusses key agreement and deletion via DNS requests with
	the Query opcode for RR type TKEY. This method is applicable to all		the Query opcode for RR type TKEY. This method is applicable to all
	currently defined TKEY modes, although in some cases it is not what		currently defined TKEY modes, although in some cases it is not what
	would intuitively be called a "query".		would intuitively be called a "query".
	Section 5 discusses spontaneous inclusion of TKEY RRs in responses by		Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	servers which is currently used only for key deletion.		servers which is currently used only for key deletion.
	Section 6 describes encryption methods for transmitting secret key		Section 6 describes encryption methods for transmitting secret key
	information. In this document these are used only for the server		information. In this document these are used only for the server
	assigned mode and the resolver assigned mode.		assigned mode and the resolver assigned mode.
	Section 7 covers IANA considerations in assignment of TKEY modes.		Section 7 covers IANA considerations in assignment of TKEY modes.
	Finally, Section 8 provides the required security considerations		Finally, Section 8 provides the required security considerations
	section.		section.
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 4 ¶
	The Name field relates to naming keys. Its meaning differs somewhat		The Name field relates to naming keys. Its meaning differs somewhat
	with mode and context as explained in subsequent sections.		with mode and context as explained in subsequent sections.
	At any DNS server or resolver only one octet string of keying		At any DNS server or resolver only one octet string of keying
	material may be in place for any particular key name. An attempt to		material may be in place for any particular key name. An attempt to
	establish another set of keying material at a server for an existing		establish another set of keying material at a server for an existing
	name returns a BADNAME error.		name returns a BADNAME error.
	For a TKEY with a non-root name appearing in a query, the TKEY RR		For a TKEY with a non-root name appearing in a query, the TKEY RR
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	name SHOULD be a domain locally unique at the resolver, less than 128		name SHOULD be a domain locally unique at the resolver, less than 128
	octets long in wire encoding, and meaningful to the resolver to		octets long in wire encoding, and meaningful to the resolver to
	assist in distinguishing keys and/or key agreement sessions. For		assist in distinguishing keys and/or key agreement sessions. For
	TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD		TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
	be a globally unique server assigned domain.		be a globally unique server assigned domain.
	A reasonable key naming strategy is as follows:		A reasonable key naming strategy is as follows:
	If the key is generated as the result of a query with root as		If the key is generated as the result of a query with root as
	its owner name, then the server SHOULD create a globally unique		its owner name, then the server SHOULD create a globally unique
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 38 ¶
	789.resolver.example.net.server1.example.com.		789.resolver.example.net.server1.example.com.
	2.2 The TTL Field		2.2 The TTL Field
	The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to		The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
	be sure that older DNS implementations do not cache TKEY RRs.		be sure that older DNS implementations do not cache TKEY RRs.
	2.3 The Algorithm Field		2.3 The Algorithm Field
	The algorithm name is in the form of a domain name with the same		The algorithm name is in the form of a domain name with the same
	meaning as in [draft-ietf-dnsext-tsig-*.txt]. The algorithm		meaning as in [RFC 2845]. The algorithm determines how the secret
	determines how the secret keying material agreed to using the TKEY RR		keying material agreed to using the TKEY RR is actually used to
	is actually used to derive the algorithm specific key.		derive the algorithm specific key.
	2.4 The Inception and Expiration Fields		2.4 The Inception and Expiration Fields
	The inception time and expiration times are in number of seconds		The inception time and expiration times are in number of seconds
	since the beginning of 1 January 1970 GMT ignoring leap seconds		since the beginning of 1 January 1970 GMT ignoring leap seconds
	treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages		treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
	between a DNS resolver and a DNS server where these fields are		between a DNS resolver and a DNS server where these fields are
	meaningful, they are either the requested validity interval for the		meaningful, they are either the requested validity interval for the
	keying material asked for or specify the validity interval of keying		keying material asked for or specify the validity interval of keying
	material provided.		material provided.
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	To avoid different interpretations of the inception and expiration		To avoid different interpretations of the inception and expiration
	times in TKEY RRs, resolvers and servers exchanging them must have		times in TKEY RRs, resolvers and servers exchanging them must have
	the same idea of what time it is. One way of doing this is with the		the same idea of what time it is. One way of doing this is with the
	NTP protocol [RFC 2030] but that or any other time synchronization		NTP protocol [RFC 2030] but that or any other time synchronization
	used for this purpose MUST be done securely.		used for this purpose MUST be done securely.
	2.5 The Mode Field		2.5 The Mode Field
	The mode field specifies the general scheme for key agreement or the		The mode field specifies the general scheme for key agreement or the
	purpose of the TKEY DNS message. Servers and resolvers supporting		purpose of the TKEY DNS message. Servers and resolvers supporting
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 43 ¶
	2.6 The Error Field		2.6 The Error Field
	The error code field is an extended RCODE. The following values are		The error code field is an extended RCODE. The following values are
	defined:		defined:
	Value Description		Value Description
	----- -----------		----- -----------
	0 - no error		0 - no error
	1-15 a non-extended RCODE		1-15 a non-extended RCODE
	16 BADSIG (tsig)		16 BADSIG (TSIG)
	17 BADKEY (tsig)		17 BADKEY (TSIG)
	18 BADTIME (tsig)		18 BADTIME (TSIG)
	19 BADMODE		19 BADMODE
	20 BADNAME		20 BADNAME
	21 BADALG		21 BADALG
	When the TKEY Error Field is non-zero in a response to a TKEY query,		When the TKEY Error Field is non-zero in a response to a TKEY query,
	the DNS header RCODE field indicates no error. However, it is		the DNS header RCODE field indicates no error. However, it is
	possible if a TKEY is spontaneously included in a response the TKEY		possible if a TKEY is spontaneously included in a response the TKEY
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	RR and DNS header error field could have unrelated non-zero error		RR and DNS header error field could have unrelated non-zero error
	codes.		codes.
	2.7 The Key Size and Data Fields		2.7 The Key Size and Data Fields
	The key data size field is an unsigned 16 bit integer in network		The key data size field is an unsigned 16 bit integer in network
	order which specifies the size of the key exchange data field in		order which specifies the size of the key exchange data field in
	octets. The meaning of this data depends on the mode.		octets. The meaning of this data depends on the mode.
	2.8 The Other Size and Data Fields		2.8 The Other Size and Data Fields
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	other HMAC algorithms.		other HMAC algorithms.
	There MUST NOT be more than one TKEY RR in a DNS query or response.		There MUST NOT be more than one TKEY RR in a DNS query or response.
	Except for GSS-API mode, TKEY responses MUST always have DNS		Except for GSS-API mode, TKEY responses MUST always have DNS
	transaction authentication to protect the integrity of any keying		transaction authentication to protect the integrity of any keying
	data, error codes, etc. This authentication MUST use a previously		data, error codes, etc. This authentication MUST use a previously
	established secret (TSIG) or public (SIG(0)) key and MUST NOT use any		established secret (TSIG) or public (SIG(0)) key and MUST NOT use any
	key that the response to be verified is itself providing.		key that the response to be verified is itself providing.
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	TKEY queries MUST be authenticated for all modes except GSS-API and,		TKEY queries MUST be authenticated for all modes except GSS-API and,
	under some circumstances, server assignment mode. In particular, if		under some circumstances, server assignment mode. In particular, if
	the query for a server assigned key is for a key to assert some		the query for a server assigned key is for a key to assert some
	privilege, such as update authority, then the query must be		privilege, such as update authority, then the query must be
	authenticated to avoid spoofing. However, if the key is just to be		authenticated to avoid spoofing. However, if the key is just to be
	used for transaction security, then spoofing will lead at worst to		used for transaction security, then spoofing will lead at worst to
	denial of service. Query authentication SHOULD use an established		denial of service. Query authentication SHOULD use an established
	secret (TSIG) key authenticator if available. Otherwise, it must use		secret (TSIG) key authenticator if available. Otherwise, it must use
	a public (SIG(0)) key signature. It MUST NOT use any key that the		a public (SIG(0)) key signature. It MUST NOT use any key that the
	query is itself providing.		query is itself providing.
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 4 ¶
	Diffie-Hellman (DH) key exchange is means whereby two parties can		Diffie-Hellman (DH) key exchange is means whereby two parties can
	derive some shared secret information without requiring any secrecy		derive some shared secret information without requiring any secrecy
	of the messages they exchange [Schneier]. Provisions have been made		of the messages they exchange [Schneier]. Provisions have been made
	for the storage of DH public keys in the DNS [RFC 2539].		for the storage of DH public keys in the DNS [RFC 2539].
	A resolver sends a query for type TKEY accompanied by a TKEY RR in		A resolver sends a query for type TKEY accompanied by a TKEY RR in
	the additional information section specifying the Diffie-Hellman mode		the additional information section specifying the Diffie-Hellman mode
	and accompanied by a KEY RR also in the additional information		and accompanied by a KEY RR also in the additional information
	section specifying a resolver Diffie-Hellman key. The TKEY RR		section specifying a resolver Diffie-Hellman key. The TKEY RR
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	algorithm field is set to the authentication algorithm the resolver		algorithm field is set to the authentication algorithm the resolver
	plans to use. The "key data" provided in the TKEY is used as a random		plans to use. The "key data" provided in the TKEY is used as a random
	[RFC 1750] nonce to avoid always deriving the same keying material		[RFC 1750] nonce to avoid always deriving the same keying material
	for the same pair of DH KEYs.		for the same pair of DH KEYs.
	The server response contains a TKEY in its answer section with the		The server response contains a TKEY in its answer section with the
	Diffie-Hellman mode. The "key data" provided in this TKEY is used as		Diffie-Hellman mode. The "key data" provided in this TKEY is used as
	an additional nonce to avoid always deriving the same keying material		an additional nonce to avoid always deriving the same keying material
	for the same pair of DH KEYs. If the TKEY error field is non-zero,		for the same pair of DH KEYs. If the TKEY error field is non-zero,
	the query failed for the reason given. FORMERR is given if the query		the query failed for the reason given. FORMERR is given if the query
	skipping to change at page 11, line 4 ¶		skipping to change at page 11, line 4 ¶
	the keying material valid. Servers may pre-expire keys so this is		the keying material valid. Servers may pre-expire keys so this is
	not a guarantee.		not a guarantee.
	4.2 Query for TKEY Deletion		4.2 Query for TKEY Deletion
	Keys established via TKEY can be treated as soft state. Since DNS		Keys established via TKEY can be treated as soft state. Since DNS
	transactions are originated by the resolver, the resolver can simply		transactions are originated by the resolver, the resolver can simply
	toss keys, although it may have to go through another key exchange if		toss keys, although it may have to go through another key exchange if
	it later needs one. Similarly, the server can discard keys although		it later needs one. Similarly, the server can discard keys although
	that will result in an error on receiving a query with a TSIG using		that will result in an error on receiving a query with a TSIG using
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	the discarded key.		the discarded key.
	To avoid attempted reliance in requests on keys no longer in effect,		To avoid attempted reliance in requests on keys no longer in effect,
	servers MUST implement key deletion whereby the server "discards" a		servers MUST implement key deletion whereby the server "discards" a
	key on receipt from a resolver of an authenticated delete request for		key on receipt from a resolver of an authenticated delete request for
	a TKEY RR with the key's name. If the server has no record of a key		a TKEY RR with the key's name. If the server has no record of a key
	with that name, it returns BADNAME.		with that name, it returns BADNAME.
	Key deletion TKEY queries MUST be authenticated. This authentication		Key deletion TKEY queries MUST be authenticated. This authentication
	MAY be a TSIG RR using the key to be deleted.		MAY be a TSIG RR using the key to be deleted.
	skipping to change at page 12, line 4 ¶		skipping to change at page 12, line 4 ¶
	sent to the resolver encrypted under a resolver public key. See		sent to the resolver encrypted under a resolver public key. See
	section 6 for description of encryption methods.		section 6 for description of encryption methods.
	A resolver sends a query for type TKEY accompanied by a TKEY RR		A resolver sends a query for type TKEY accompanied by a TKEY RR
	specifying the "server assignment" mode and a resolver KEY RR to be		specifying the "server assignment" mode and a resolver KEY RR to be
	used in encrypting the response, both in the additional information		used in encrypting the response, both in the additional information
	section. The TKEY algorithm field is set to the authentication		section. The TKEY algorithm field is set to the authentication
	algorithm the resolver plans to use. It is RECOMMENDED that any "key		algorithm the resolver plans to use. It is RECOMMENDED that any "key
	data" provided in the query TKEY RR by the resolver be strongly mixed		data" provided in the query TKEY RR by the resolver be strongly mixed
	by the server with server generated randomness [RFC 1750] to derive		by the server with server generated randomness [RFC 1750] to derive
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	the keying material to be used. The KEY RR that appears in the query		the keying material to be used. The KEY RR that appears in the query
	need not be accompanied by a SIG(KEY) RR. If the query is		need not be accompanied by a SIG(KEY) RR. If the query is
	authenticated by the resolver with a TSIG RR [draft-ietf-dnsext-		authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
	tsig-*.txt] or SIG(0) RR and that authentication is verified, then		and that authentication is verified, then any SIG(KEY) provided in
	any SIG(KEY) provided in the query SHOULD be ignored. The KEY RR in		the query SHOULD be ignored. The KEY RR in such a query SHOULD have
	such a query SHOULD have a name that corresponds to the resolver but		a name that corresponds to the resolver but it is only essential that
	it is only essential that it be a public key for which the resolver		it be a public key for which the resolver has the corresponding
	has the corresponding private key so it can decrypt the response		private key so it can decrypt the response data.
	data.
	The server response contains a TKEY RR in its answer section with the		The server response contains a TKEY RR in its answer section with the
	server assigned mode and echoes the KEY RR provided in the query in		server assigned mode and echoes the KEY RR provided in the query in
	its additional information section.		its additional information section.
	If the reponse TKEY error field is zero, the key data portion of the		If the reponse TKEY error field is zero, the key data portion of the
	response TKEY RR will be the server assigned keying data encrypted		response TKEY RR will be the server assigned keying data encrypted
	under the public key in the resolver provided KEY RR. In this case,		under the public key in the resolver provided KEY RR. In this case,
	the owner name of the answer TKEY RR will be the server assigned name		the owner name of the answer TKEY RR will be the server assigned name
	of the key.		of the key.
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 4 ¶
	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
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	keying material and will return a FORMERR. It is also important that		keying material and will return a FORMERR. It is also important that
	no untrusted party (preferably no other party than the server) has		no untrusted party (preferably no other party than the server) has
	the private key corresponding to the KEY RR because, if they do, they		the private key corresponding to the KEY RR because, if they do, they
	can capture the messages to the server, learn the shared secret, and		can capture the messages to the server, learn the shared secret, and
	spoof valid TSIGs.		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.
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 5 ¶
	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		For server assigned and Diffie-Hellman keys, the client MUST
	"discard" active state associated with the key. For querier assigned		"discard" active state associated with the key. For querier assigned
	keys, the querier MAY simply mark the key as no longer retained by		keys, the querier MAY simply mark the key as no longer retained by
	the server and may re-send it in a future query specifying querier		the server and may re-send it in a future query specifying querier
	assigned keying material.		assigned keying material.
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	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
	that the decrypting process has access to the corresponding private		that the decrypting process has access to the corresponding private
	skipping to change at page 14, line 37 ¶		skipping to change at page 14, line 39 ¶
	length of each block is clear from the public RSA key specified and		length of each block is clear from the public RSA key specified and
	the RSAES-PKCS1-v1_5 padding makes it clear what part of the		the RSAES-PKCS1-v1_5 padding makes it clear what part of the
	encrypted data is actually keying material and what part is		encrypted data is actually keying material and what part is
	formatting or the required at least eight bytes of random [RFC 1750]		formatting or the required at least eight bytes of random [RFC 1750]
	padding.		padding.
	7. IANA Considerations		7. IANA Considerations
	This section is to be interpreted as provided in [RFC 2434].		This section is to be interpreted as provided in [RFC 2434].
	Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF		Mode field values 0x0000 and 0xFFFF are reserved.
	can only be assigned by an IETF standards action. Special
	consideration should be given before the allocation of meaning for		Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
	Mode field values 0x0000 and 0xFFFF.		can only be assigned by an IETF Standards Action.
	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 based just on providing		changes. For example, a mode value assigned based just on providing
	a specification should not be changed later just because that use's		a specification should not be changed later just because that use's
	status is changed to standards track.		status is changed to standards track.
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	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.
	8. Security Considerations		8. Security Considerations
	The entirety of this specification is concerned with the secure		The entirety of this specification is concerned with the secure
	establishment of a shared secret between DNS clients and servers in		establishment of a shared secret between DNS clients and servers in
	support of TSIG [draft-ietf-dnsext-tsig-*.txt].		support of TSIG [RFC 2845].
	Protection against denial of service via the use of TKEY is not		Protection against denial of service via the use of TKEY is not
	provided.		provided.
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	References		References
	[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,		[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
	Algorithms, and Source Code in C", 1996, John Wiley and Sons		Algorithms, and Source Code in C", 1996, John Wiley and Sons
	RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",		RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",
	STD 13, November 1987.		STD 13, November 1987.
	RFC 1035 - P. Mockapetris, "Domain Names - Implementation and		RFC 1035 - P. Mockapetris, "Domain Names - Implementation and
	Specifications", STD 13, November 1987.		Specifications", STD 13, November 1987.
	skipping to change at page 16, line 49 ¶		skipping to change at page 16, line 51 ¶
	RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography		RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
	Specifications Version 2.0", October 1998.		Specifications Version 2.0", October 1998.
	RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",		RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
	March 1999.		March 1999.
	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.		RFC 2845 - P. Vixie, O. Gudmundsson, D. Eastlake, B.
	Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)".		Wellington,"Secret Key Transaction Authentication for DNS (TSIG)",
			May 2000.
			INTERNET-DRAFT The DNS TKEY RR July 2000.
	Author's Address		Author's Address
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	Motorola		Motorola
	140 Forest Avenue		140 Forest Avenue
	Hudson, MA 01749 USA		Hudson, MA 01749 USA
	Telephone: +1 978-562-2827 (h)		Telephone: +1 978-562-2827 (h)
	+1 508-261-5434 (w)		+1 508-261-5434 (w)
	FAX: +1 978-567-7941 (h)		FAX: +1 508-261-4447 (w)
	+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 December 2000.		This draft expires January 2001.
	Its file name is draft-ietf-dnsext-tkey-03.txt.		Its file name is draft-ietf-dnsext-tkey-04.txt.
End of changes. 29 change blocks.
	42 lines changed or deleted		80 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/