< draft-ietf-sidrops-rpki-has-no-identity-05.txt		draft-ietf-sidrops-rpki-has-no-identity-06.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: 6 October 2022 Vigil Security		Expires: 16 October 2022 Vigil Security
	4 April 2022		14 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-05		draft-ietf-sidrops-rpki-has-no-identity-06
	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 'holder'
	an INR. This document attempts to put that notion to rest.		of 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",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Status of This Memo		Status of This Memo
	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 6 October 2022.		This Internet-Draft will expire on 16 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	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 RPKI is for Authorization . . . . . . . . . . . . . . . . 3
	3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. Normative References . . . . . . . . . . . . . . . . . . 5		7.1. Normative References . . . . . . . . . . . . . . . . . . 6
	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.
	Router Keying for BGPsec, [RFC8635].		Router Keying for BGPsec, [RFC8635].
	In security terms, the phrase "Public Key" implies there is also a		In security terms, the phrase "Public Key" implies there is also a
	corresponding private key [RFC5280]. The RPKI's strong authority		corresponding private key [RFC5280]. The RPKI provides strong
	over ownership of INRs has misled some people toward a desire to use		authority to the current holder of INRs; however, some people a have
	RPKI private keys to sign arbitrary documents attesting that the INR		a desire to use RPKI private keys to sign arbitrary documents as the
	'owner' of those resources has attested to the authenticity of the		INR 'holder' of those resources with the inappropriate expectation
	document content. But in reality, the RPKI certificate is only an		that the signature will be considered an attestation to the
	authorization to speak for the explicitly identified INRs; it is		authenticity of the document content. But in reality, the RPKI
	explicitly not intended for authentication of the 'owners' of the		certificate is only an authorization to speak for the explicitly
	INRs. This situation is emphasized in Section 2.1 of [RFC6480].		identified INRs; it is explicitly not intended for authentication of
			the 'holders' of the 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 the private key attesting to ownership of their		and Sushi could use the private key attesting to that they are the
	AS in the RPKI to sign a Letter of Authorization (LOA) for some other		holder of their AS in the RPKI to sign a Letter of Authorization
	party to rack and stack hardware owned by BB&S. Unfortunately, while		(LOA) for some other party to rack and stack hardware owned by BB&S.
	this may be technically possible, it is neither appropriate nor		Unfortunately, while this may be technically possible, it is neither
	meaningful.		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 make		holder(s) of those INRs. The RPKI provides authorization to make
	assertions only regarding named IP address blocks, AS numbers, etc.		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 RPKI is for Authorization
	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 by design.		That the RPKI does not authenticate real-world identity is by design.
	If it tried to do so, aside from the liability, it would end in a		If it tried to do so, aside from the liability, it would end in a
	world of complexity with no proof of termination, as X.400 learned.		world of complexity with no proof of termination, as X.400 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, [RFC3912], and
	services. They claim to be authoritative, at least for the INRs		similar services. They claim to be authoritative, at least for the
	which they allocate.		INRs which they allocate.
	PKI operations MUST NOT be performed with RPKI certificates other		PKI operations MUST NOT be performed with RPKI certificates other
	than exactly as described, and for the purposes described, in		than exactly as described, and for the purposes described, in
	[RFC6480].		[RFC6480]. That is, 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.
	I.e., RPKI-based credentials of INRs MUST NOT be used to authenticate		I.e., RPKI-based credentials of INRs MUST NOT be used to authenticate
	real-world documents or transactions without some formal external		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.
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 19 ¶
	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
	important property of this PKI is that certificates do not attest to		important property of this PKI is that certificates do not attest to
	the identity of the subject."		the identity of the subject."
	The Template for a Certification Practice Statement (CPS) for the		The Template for a Certification Practice Statement (CPS) for the
	Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear		Resource PKI (RPKI) [RFC7382] Section 3.1, Naming, makes very clear
	that "The Subject name in each certificate SHOULD NOT be meaningful;"		that "The Subject name in each certificate SHOULD NOT be meaningful;"
	and goes on to do so at some length.		and goes on to do so at some length.
	Normally, the INR holder does not hold the private key attesting to		Normally, the INR holder does not hold the private key attesting to
	their resources; the Certification Authority (CA) does. The INR		their resources; the Certification Authority (CA) does. The INR
	holder has a real-world business relationship with the CA for which		holder has a real-world business relationship with the CA for which
	they have likely signed real-world documents.		they have likely signed real-world documents.
	As the INR owner does not have the keying material, they rely on the		As the INR holder does not have the keying material, they rely on the
	CA, to which they presumably present credentials, to manipulate their		CA, to which they presumably present credentials, to manipulate their
	INRs. These credentials may be userid/password (with two factor		INRs. These credentials may be userid/password (with two factor
	authentication one hopes), a hardware token, client browser		authentication one hopes), a hardware token, client browser
	certificates, etc.		certificates, etc.
	Hence schemes such as [I-D.ietf-sidrops-rpki-rta] and		Hence schemes such as [I-D.ietf-sidrops-rpki-rta] and
	[I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the		[I-D.ietf-sidrops-rpki-rsc] must go to great lengths to extract the
	supposedly relevant keys from the CA.		supposedly relevant keys from the CA.
	For some particular INR, say Bill's Bait and Sushi's Autonomous		For some particular INR, say Bill's Bait and Sushi's Autonomous
	skipping to change at page 4, line 36 ¶		skipping to change at page 5, line 5 ¶
	credentials to the CA account in which BB&S's INRs are registered.		credentials to the CA account in which BB&S's INRs are registered.
	That could be the owner of BB&S, Roberto's Taco Stand, an IT vendor,		That could be the owner of BB&S, Roberto's Taco Stand, an IT vendor,
	or the Government of Elbonia. One simply can not know.		or the Government of Elbonia. One simply can not know.
	In large organizations, INR management is often compartmentalized		In large organizations, INR management is often compartmentalized
	with no authority over anything beyond dealing with INR registration.		with no authority over anything beyond dealing with INR registration.
	The INR manager for Bill's Bait and Sushi is unlikely to be		The INR manager for Bill's Bait and Sushi is unlikely to be
	authorized to conduct bank transactions for BB&S, or even to		authorized to conduct bank transactions for BB&S, or even to
	authorize access to BB&S's servers in some colocation facility.		authorize access to BB&S's servers in some colocation facility.
	Then there is the temporal issue. The owner of that AS may be BB&S		Then there is the temporal issue. The holder of that AS may be BB&S
	today when some document was signed, and could be the Government of		today when some document was signed, and could be the Government of
	Elbonia tomorrow. Or the resource could have been administratively		Elbonia tomorrow. Or the resource could have been administratively
	moved from one CA to another, likely requiring a change of keys. If		moved from one CA to another, likely requiring a change of keys. If
	so, how does one determine if the signature on the real-world		so, how does one determine if the signature on the real-world
	document is still valid?		document is still valid?
	While Ghostbuster Records [RFC6493] may seem to identify real-world		While Ghostbuster Records [RFC6493] may seem to identify real-world
	entities, their semantic content is completely arbitrary, and does		entities, their semantic content is completely arbitrary, and does
	not attest to INR ownership. They are merely clues for operational		not attest to holding of any INRs. They are merely clues for
	support contact in case of technical RPKI problems.		operational support contact in case of technical RPKI problems.
	Usually, before registering INRs, CAs require proof of INR ownership		Usually, before registering INRs, CAs require proof of an INR holding
	via external documentation and authorities. It is somewhat droll		via external documentation and authorities. It is somewhat droll
	that the CPS Template, [RFC7382], does not mention any diligence the		that the CPS Template, [RFC7382], does not mention any diligence the
	CA must, or even might, conduct to assure the INRs are in fact owned		CA must, or even might, conduct to assure the INRs are in fact owned
	by a registrant.		by a registrant.
	That someone can provide 'proof of possession' of the private key		That someone can provide 'proof of possession' of the private key
	signing over a particular INR should not be taken to imply that they		signing over a particular INR should not be taken to imply that they
	are a valid legal representative of the organization in possession of		are a valid legal representative of the organization in possession of
	that INR. They could be just an INR administrative person.		that INR. They could be just an INR administrative person.
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 17 ¶
	rsc-06.txt>.		rsc-06.txt>.
	[I-D.ietf-sidrops-rpki-rta]		[I-D.ietf-sidrops-rpki-rta]
	Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels,		Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels,
	T., and M. Hoffmann, "A profile for Resource Tagged		T., and M. Hoffmann, "A profile for Resource Tagged
	Attestations (RTAs)", Work in Progress, Internet-Draft,		Attestations (RTAs)", Work in Progress, Internet-Draft,
	draft-ietf-sidrops-rpki-rta-00, 21 January 2021,		draft-ietf-sidrops-rpki-rta-00, 21 January 2021,
	<https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-		<https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
	rta-00.txt>.		rta-00.txt>.
			[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
			DOI 10.17487/RFC3912, September 2004,
			<https://www.rfc-editor.org/info/rfc3912>.
	[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)		[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
	Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,		Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
	February 2012, <https://www.rfc-editor.org/info/rfc6493>.		February 2012, <https://www.rfc-editor.org/info/rfc6493>.
	Authors' Addresses		Authors' Addresses
	Randy Bush		Randy Bush
	Arrcus & Internet Initiative Japan		Arrcus & Internet Initiative Japan
	5147 Crystal Springs		5147 Crystal Springs
	Bainbridge Island, WA 98110		Bainbridge Island, WA 98110
End of changes. 17 change blocks.
	35 lines changed or deleted		46 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/