< draft-ietf-sidrops-rpki-has-no-identity-04.txt		draft-ietf-sidrops-rpki-has-no-identity-05.txt >
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft Arrcus & Internet Initiative Japan		Internet-Draft Arrcus & Internet Initiative Japan
	Intended status: Standards Track R. Housley		Intended status: Standards Track R. Housley
	Expires: 4 September 2022 Vigil Security		Expires: 6 October 2022 Vigil Security
	3 March 2022		4 April 2022
	The I in RPKI does not stand for Identity		The I in RPKI does not stand for Identity
	draft-ietf-sidrops-rpki-has-no-identity-04		draft-ietf-sidrops-rpki-has-no-identity-05
	Abstract		Abstract
	There is a false notion that Internet Number Resources (INRs) in the		There is a false notion that Internet Number Resources (INRs) in the
	RPKI can be associated with the real-world identity of the 'owner' of		RPKI can be associated with the real-world identity of the 'owner' of
	an INR. This document attempts to put that notion to rest.		an INR. This document attempts to put that notion to rest.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 4 September 2022.		This Internet-Draft will expire on 6 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. The Bottom Line . . . . . . . . . . . . . . . . . . . . . . . 3		2. The Bottom Line . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . 5
	7.2. Informative References . . . . . . . . . . . . . . . . . 6		7.2. Informative References . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The Resource Public Key Infrastructure (RPKI), see [RFC6480],		The Resource Public Key Infrastructure (RPKI), see [RFC6480],
	"Represents the allocation hierarchy of IP address space and		"Represents the allocation hierarchy of IP address space and
	Autonomous System (AS) numbers," which are collectively known as		Autonomous System (AS) numbers," which are collectively known as
	Internet Number Resources (INRs). Since initial deployment, the RPKI		Internet Number Resources (INRs). Since initial deployment, the RPKI
	has grown to include other similar resource and routing data, e.g.		has grown to include other similar resource and routing data, e.g.
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	over ownership of INRs has misled some people toward a desire to use		over ownership of INRs has misled some people toward a desire to use
	RPKI private keys to sign arbitrary documents attesting that the INR		RPKI private keys to sign arbitrary documents attesting that the INR
	'owner' of those resources has attested to the authenticity of the		'owner' of those resources has attested to the authenticity of the
	document content. But in reality, the RPKI certificate is only an		document content. But in reality, the RPKI certificate is only an
	authorization to speak for the explicitly identified INRs; it is		authorization to speak for the explicitly identified INRs; it is
	explicitly not intended for authentication of the 'owners' of the		explicitly not intended for authentication of the 'owners' of the
	INRs. This situation is emphasized in Section 2.1 of [RFC6480].		INRs. This situation is emphasized in Section 2.1 of [RFC6480].
	It has been suggested that one could authenticate real-world business		It has been suggested that one could authenticate real-world business
	transactions with the signatures of INR holders. E.g. Bill's Bait		transactions with the signatures of INR holders. E.g. Bill's Bait
	and Sushi could use their AS in the RPKI to sign a Letter of		and Sushi could use the private key attesting to ownership of their
	Authorization (LOA) for some other party to rack and stack hardware		AS in the RPKI to sign a Letter of Authorization (LOA) for some other
	owned by BB&S. Unfortunately, this is not formally feasible.		party to rack and stack hardware owned by BB&S. Unfortunately, while
			this may be technically possible, it is neither appropriate nor
			meaningful.
	The I in RPKI actually stands for "Infrastructure," as in Resource		The I in RPKI actually stands for "Infrastructure," as in Resource
	Public Key Infrastructure, not for "Identity". In fact, the RPKI		Public Key Infrastructure, not for "Identity". In fact, the RPKI
	does not provide any association between INRs and the real world		does not provide any association between INRs and the real world
	holder(s) of those INRs. The RPKI provides authorization to speak		holder(s) of those INRs. The RPKI provides authorization to make
	for the named IP address blocks and AS numbers.		assertions only regarding named IP address blocks, AS numbers, etc.
	In short, avoid the desire to use RPKI certificates for any purpose		In short, avoid the desire to use RPKI certificates for any purpose
	other than the verification of authorizations associated with the		other than the verification of authorizations associated with the
	delegation of INRs or attestations related to INRs. Instead,		delegation of INRs or attestations related to INRs. Instead,
	recognize that these authorizations and attestations take place		recognize that these authorizations and attestations take place
	irrespective of the identity of a RPKI private key holder.		irrespective of the identity of a RPKI private key holder.
	2. The Bottom Line		2. The Bottom Line
	The RPKI was designed and specified to sign certificates for use		The RPKI was designed and specified to sign certificates for use
	within the RPKI itself and to generate Route Origin Authorizations		within the RPKI itself and to generate Route Origin Authorizations
	(ROAs), [RFC6480], for use in routing. Its design intentionally		(ROAs), [RFC6480], for use in routing. Its design intentionally
	precluded use for attesting to real-world identity as, among other		precluded use for attesting to real-world identity as, among other
	issues, it would expose the Certification Authority (CA) to		issues, it would expose the Certification Authority (CA) to
	liability.		liability.
	That the RPKI does not authenticate real-world identity is a feature,		That the RPKI does not authenticate real-world identity is by design.
	not a bug. If it tried to do so, aside from the liability, it would		If it tried to do so, aside from the liability, it would end in a
	end in a world of complexity with no proof of termination, as X.400		world of complexity with no proof of termination, as X.400 learned.
	learned.
	Registries such as the Regional Internet Registries (RIRs) provide		Registries such as the Regional Internet Registries (RIRs) provide
	INR to real-world identity mapping through whois and similar		INR to real-world identity mapping through whois and similar
	services. They claim to be authoritative, at least for the INRs		services. They claim to be authoritative, at least for the INRs
	which they allocate.		which they allocate.
	RPKI-based credentials of INRs MUST NOT be used to authenticate real-		PKI operations MUST NOT be performed with RPKI certificates other
	world documents or transactions without some formal external		than exactly as described, and for the purposes described, in
			[RFC6480].
			I.e., RPKI-based credentials of INRs MUST NOT be used to authenticate
			real-world documents or transactions without some formal external
	authentication of the INR and the authority for the actually		authentication of the INR and the authority for the actually
	anonymous INR holder to authenticate the particular document or		anonymous INR holder to authenticate the particular document or
	transaction.		transaction.
	Given sufficient external, i.e. non-RPKI, verification of authority,		Given sufficient external, i.e. non-RPKI, verification of authority,
	the use of RPKI-based credentials seems superfluous.		the use of RPKI-based credentials seems superfluous.
	3. Discussion		3. Discussion
	The RPKI base document, [RFC6480], Section 2.1 says explicitly "An		The RPKI base document, [RFC6480], Section 2.1 says explicitly "An
	skipping to change at page 5, line 39 ¶		skipping to change at page 5, line 39 ¶
	is not an identity; this is an authorization. In schemes such as		is not an identity; this is an authorization. In schemes such as
	[I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the		[I-D.ietf-sidrops-rpki-rta] and [I-D.ietf-sidrops-rpki-rsc] the
	signed message further narrows this scope of INRs. The INRs in the		signed message further narrows this scope of INRs. The INRs in the
	message are a subset of the INRs in the certificate. If the		message are a subset of the INRs in the certificate. If the
	signature is valid, the message content comes from a party that is		signature is valid, the message content comes from a party that is
	authorized to speak for that subset of INRs.		authorized to speak for that subset of INRs.
	Control of INRs for an entity could be used to falsely authorize		Control of INRs for an entity could be used to falsely authorize
	transactions or documents for which the INR manager has no authority.		transactions or documents for which the INR manager has no authority.
	RPKI-based credentials of INRs MUST NOT be used to authenticate real-
	world documents or transactions without some formal external
	authentication of the INR and the authority for the actually
	anonymous INR holder to authenticate the particular document or
	transaction.
	5. IANA Considerations		5. IANA Considerations
	This document has no IANA Considerations.		This document has no IANA Considerations.
	6. Acknowledgments		6. Acknowledgments
	The authors thank George Michaelson and Job Snijders for lively		The authors thank George Michaelson and Job Snijders for lively
	discussion, Geoff Huston for some more formal text, Ties de Kock for		discussion, Geoff Huston for some more formal text, Ties de Kock for
	useful suggestions, and last but not least, Biff for the loan of		useful suggestions, and last but not least, Biff for the loan of
	Bill's Bait and Sushi.		Bill's Bait and Sushi.
End of changes. 9 change blocks.
	24 lines changed or deleted		23 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/