draft-ietf-regext-secure-authinfo-transfer-01.txt		draft-ietf-regext-secure-authinfo-transfer-02.txt
	Network Working Group J. Gould		Network Working Group J. Gould
	Internet-Draft R. Wilhelm		Internet-Draft R. Wilhelm
	Intended status: Best Current Practice VeriSign, Inc.		Intended status: Best Current Practice VeriSign, Inc.
	Expires: October 25, 2020 April 23, 2020		Expires: December 14, 2020 June 12, 2020
	Extensible Provisioning Protocol (EPP) Secure Authorization Information		Extensible Provisioning Protocol (EPP) Secure Authorization Information
	for Transfer		for Transfer
	draft-ietf-regext-secure-authinfo-transfer-01		draft-ietf-regext-secure-authinfo-transfer-02
	Abstract		Abstract
	The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the		The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the
	use of authorization information to authorize a transfer. The		use of authorization information to authorize a transfer. The
	authorization information is object-specific and has been defined in		authorization information is object-specific and has been defined in
	the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact		the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact
	Mapping, in RFC 5733, as password-based authorization information.		Mapping, in RFC 5733, as password-based authorization information.
	Other authorization mechanisms can be used, but in practice the		Other authorization mechanisms can be used, but in practice the
	password-based authorization information has been used at the time of		password-based authorization information has been used at the time of
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on October 25, 2020.		This Internet-Draft will expire on December 14, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 19		6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 19
	6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 20		6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 20
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 20		7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 20
	7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21		7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21
	8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21		8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
	8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22		8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22
	8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 22		8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 22
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 23		9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	11.1. Normative References . . . . . . . . . . . . . . . . . . 23		11.1. Normative References . . . . . . . . . . . . . . . . . . 24
	11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24		11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	Appendix A. Change History . . . . . . . . . . . . . . . . . . . 24		Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25
	A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 24		A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 25
	A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 24		A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 25
	A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 24		A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 25
	A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 26		A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 27
	A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 26		A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 27
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the		The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the
	use of authorization information to authorize a transfer. The		use of authorization information to authorize a transfer. The
	authorization information is object-specific and has been defined in		authorization information is object-specific and has been defined in
	the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact		the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact
	Mapping, in [RFC5733], as password-based authorization information.		Mapping, in [RFC5733], as password-based authorization information.
	Other authorization mechanisms can be used, but in practice the		Other authorization mechanisms can be used, but in practice the
	password-based authorization information has been used at the time of		password-based authorization information has been used at the time of
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 26 ¶
	automatically unsetting the authorization information upon a		automatically unsetting the authorization information upon a
	successful transfer. All of these features can be supported by		successful transfer. All of these features can be supported by
	the EPP RFCs.		the EPP RFCs.
	"Storing Authorization Information Securely": The EPP RFCs don't		"Storing Authorization Information Securely": The EPP RFCs don't
	specify where and how the authorization information is stored in		specify where and how the authorization information is stored in
	the client or the server, so there are no restrictions to define		the client or the server, so there are no restrictions to define
	an operational practice for storing the authorization information		an operational practice for storing the authorization information
	securely. The operational practice will not require the client		securely. The operational practice will not require the client
	to store the authorization information and will require the		to store the authorization information and will require the
	server to store the authorization information using a		server to store the authorization information using a
	cryptographic hash, with at least a 256-bit hash function, such		cryptographic hash, with at least a 256-bit hash function such as
	as SHA-256. Returning the authorization information set in an		SHA-256, and with a random salt. Returning the authorization
	EPP info response will not be supported.		information set in an EPP info response will not be supported.
	1.1. Conventions Used in This Document		1.1. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	XML is case sensitive. Unless stated otherwise, XML specifications		XML is case sensitive. Unless stated otherwise, XML specifications
	and examples provided in this document MUST be interpreted in the		and examples provided in this document MUST be interpreted in the
	character case presented in order to develop a conforming		character case presented in order to develop a conforming
	skipping to change at page 8, line 45 ¶		skipping to change at page 8, line 45 ¶
	registrant of the TTL when the authorization information is provided		registrant of the TTL when the authorization information is provided
	to the registrant.		to the registrant.
	4.3. Authorization Information Storage and Transport		4.3. Authorization Information Storage and Transport
	To protect the disclosure of the authorization information, the		To protect the disclosure of the authorization information, the
	following requirements apply:		following requirements apply:
	1. The authorization information MUST be stored by the registry		1. The authorization information MUST be stored by the registry
	using a strong one-way cryptographic hash, with at least a		using a strong one-way cryptographic hash, with at least a
	256-bit hash function, such as SHA-256.		256-bit hash function such as SHA-256, and with a random salt.
	2. An empty authorization information MUST be stored with a NULL		2. An empty authorization information MUST be stored as an undefined
	(undefined) value.		value that is referred to as a NULL value. The representation of
			an NULL (undefined) value is dependent on the type of database
			used.
	3. The authorization information MUST NOT be stored by the losing		3. The authorization information MUST NOT be stored by the losing
	registrar.		registrar.
	4. The authorization information MUST only be stored by the gaining		4. The authorization information MUST only be stored by the gaining
	registrar as a "transient" value in support of the transfer		registrar as a "transient" value in support of the transfer
	process.		process.
	5. The plain text version of the authorization information MUST NOT		5. The plain text version of the authorization information MUST NOT
	be written to any logs by the registrar or the registry.		be written to any logs by the registrar or the registry.
	6. All communication that includes the authorization information		6. All communication that includes the authorization information
	MUST be over an encrypted channel, such as defined in [RFC5734]		MUST be over an encrypted channel, such as defined in [RFC5734]
	skipping to change at page 23, line 7 ¶		skipping to change at page 23, line 7 ¶
	Auhtorization Information in the Info Response.		Auhtorization Information in the Info Response.
	Licensing: Proprietary In-House software		Licensing: Proprietary In-House software
	Contact: epp@centralnic.com		Contact: epp@centralnic.com
	URL: https://www.centralnic.com		URL: https://www.centralnic.com
	9. Security Considerations		9. Security Considerations
	TBD		Section 4.1 defines the use a secure random value for the generation
			of the authorization information. The server SHOULD define policy
			related to the length and set of characters that are included in the
			randomization to target the desired entropy level, with the
			recommendation of at least 49 bits for entropy. The authorization
			information server policy is communicated to the client using an out-
			of-band process. The client SHOULD choose a length and set of
			characters that results in entropy that meets or exceeds the server
			policy. A random number generator (RNG) is preferable over the use
			of a pseudorandom number generator (PRNG) when creating the
			authorization information value.
			Section 4.2 defines the use of an authorization information Time-To-
			Live (TTL). The registrar SHOULD only set the authorization
			information during the transfer process by the server support for
			setting and unsetting the authorization information. The TTL value
			is up to registrar policy and the sponsoring registrar MUST inform
			the registrant of the TTL when providing the authorization
			information to the registrant.
			Section 4.3 defines the storage and transport of authorization
			information. The losing registrar MUST NOT store the authorization
			information and the gaining registrar MUST only store the
			authorization information as a "transient" value during the transfer
			process, where the authorization information MUST NOT be stored after
			the end of the transfer process. The registry MUST store the
			authorization information using a one-way cryptographic hash of at
			least 256 bits and with a random salt. All communication that
			includes the authorization information MUST be over an encrypted
			channel. The plain text authorization information MUST NOT be
			written to any logs by the registrar or the registry.
			Section 4.4 defines the matching of the authorization information
			values. The registry stores an unset authorization information as a
			NULL (undefined) value to ensure that an empty input authorization
			information never matches it. The method used to define a NULL
			(undefined) value is database specific.
	10. Acknowledgements		10. Acknowledgements
	The authors wish to thank the following persons for their feedback		The authors wish to thank the following persons for their feedback
	and suggestions:		and suggestions:
	o Michael Bauland		o Michael Bauland
	o Martin Casanova		o Martin Casanova
	o Scott Hollenbeck		o Scott Hollenbeck
	o Jody Kolker		o Jody Kolker
	o Patrick Mevzek		o Patrick Mevzek
	o Matthew Pozun		o Matthew Pozun
	o Srikanth Veeramachaneni		o Srikanth Veeramachaneni
			o Ulrich Wisser
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 26, line 29 ¶		skipping to change at page 27, line 21 ¶
	A.5. Change from REGEXT 00 to REGEXT 01		A.5. Change from REGEXT 00 to REGEXT 01
	1. Added the "Signaling Client and Server Support" section to		1. Added the "Signaling Client and Server Support" section to
	describe the mechanism to signal support for the BCP by the		describe the mechanism to signal support for the BCP by the
	client and the server.		client and the server.
	2. Added the "IANA Considerations" section with the registration of		2. Added the "IANA Considerations" section with the registration of
	the secure authorization for transfer XML namespace and the		the secure authorization for transfer XML namespace and the
	registration of the EPP Best Current Practice (BCP) in the EPP		registration of the EPP Best Current Practice (BCP) in the EPP
	Extension Registry.		Extension Registry.
			A.6. Change from REGEXT 01 to REGEXT 02
			1. Added inclusion of random salt for the hashed authorization
			information, based on feedback from Ulrich Wisser.
			2. Added clarification that the representation of a NULL (undefined)
			value is dependent on the type of database, based on feedback
			from Patrick Mevzek.
			3. Filled in the Security Considerations section.
	Authors' Addresses		Authors' Addresses
	James Gould		James Gould
	VeriSign, Inc.		VeriSign, Inc.
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	US		US
	Email: jgould@verisign.com		Email: jgould@verisign.com
	URI: http://www.verisign.com		URI: http://www.verisign.com
End of changes. 9 change blocks.
	20 lines changed or deleted		69 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/