<?xml version="1.0"encoding="utf-8"?> <!--encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"> --> <?rfc comments="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc inline="yes"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?> <?rfc toc="yes"?> <?rfc tocdepth="6"?> <?rfc tocindent="yes"?> <?rfc tocompact="yes"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-sidrops-rpki-has-no-identity-07" number="9255" submissionType="IETF" category="std" consensus="true"submissionType="IETF" docName="draft-ietf-sidrops-rpki-has-no-identity-07" ipr="trust200902">ipr="trust200902" sortRefs="true" symRefs="true" tocInclude="true" tocDepth="6" xml:lang="en" updates="" obsoletes="" version="3"> <!-- xml2rfc v2v3 conversion 3.12.2 --> <front> <title>TheI'I' in RPKIdoes not standDoes Not Stand for Identity</title> <seriesInfo name="RFC" value="9255"/> <author fullname="Randy Bush" initials="R." surname="Bush"><organization>Arrcus<organization abbrev="Arrcus & IIJ Research">Arrcus & Internet InitiativeJapan</organization>Japan Research</organization> <address> <postal> <street>5147 Crystal Springs</street> <city>Bainbridge Island</city> <region>WA</region> <code>98110</code><country>US</country><country>United States of America</country> </postal> <email>randy@psg.com</email> </address> </author> <author initials="R." surname="Housley" fullname="Russ Housley"> <organization abbrev="Vigil Security">Vigil Security, LLC</organization> <address> <postal> <street>516 Dranesville Road</street><city>Herndon, VA</city><city>Herndon</city> <region>VA</region> <code>20170</code><country>US</country><country>United States of America</country> </postal> <email>housley@vigilsec.com</email> </address> </author> <date year="2022" month="June" /> <area>ops</area> <workgroup>sidrops</workgroup> <keyword>Public Key Infrastructure</keyword> <keyword>Security</keyword> <keyword>X.509</keyword> <keyword>Certificate</keyword> <abstract> <t>There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real-world identity of the 'holder' of an INR. This document specifies that RPKI does not associate to the INR holder.</t> </abstract><note title="Requirements Language"> <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </note></front> <middle> <sectionanchor="intro" title="Introduction">anchor="intro"> <name>Introduction</name> <t>The Resource Public Key Infrastructure (RPKI), see <xref target="RFC6480"/>,"Represents"represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers," which are collectively known as Internet Number Resources (INRs). Since initial deployment, the RPKI has grown to include other similar resource and routing data,e.g.e.g., Router Keying forBGPsec,BGPsec <xref target="RFC8635"/>.</t> <t>In security terms, the phrase "Public Key" implies there is also a corresponding private key <xref target="RFC5280"/>. The RPKI provides strong authority to the current holder of INRs; however, some peopleahave a desire to use RPKI private keys to sign arbitrary documents as the INR 'holder' of those resources with the inappropriate expectation that the signature will be considered an attestation to the authenticity of the document content.ButBut, in reality, the RPKI certificate is only an authorization to speak for the explicitly identified INRs; it is explicitly not intended for authentication of the 'holders' of the INRs. This situation is emphasized inSection 2.1 of<xreftarget="RFC6480"/>.</t>target="RFC6480" section="2.1" sectionFormat="of"/>.</t> <t>It has been suggested that one could authenticate real-world business transactions with the signatures of INR holders.E.g.For example, Bill's Bait and Sushi (BB&S) could use the private key attesting to that they are the holder of their AS in the RPKI to sign a Letter of Authorization (LOA) for some other party to rack and stack hardware owned by BB&S. Unfortunately, while this may be technically possible, it is neither appropriate nor meaningful.</t> <t>TheI'I' in RPKI actually stands for "Infrastructure," as in Resource Public Key Infrastructure, not for "Identity". In fact, the RPKI does not provide any association between INRs and thereal worldreal-world holder(s) of those INRs. The RPKI provides authorization to make assertions only regarding Internet Number Resources, such as IP prefixes or AS numbers, and data such asASPA<xreftarget="I-D.ietf-sidrops-aspa-profile"/>records.</t>target="I-D.ietf-sidrops-aspa-profile">Autonomous System Provider Authorization (ASPA) records</xref>.</t> <t>In short, avoid the desire to use RPKI certificates for any purpose other than the verification of authorizations associated with the delegation of INRs or attestations related to INRs. Instead, recognize that these authorizations and attestations take place irrespective of the identity ofaan RPKI private key holder.</t> <section> <name>Requirements Language</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <sectionanchor="bottom" title="Theanchor="bottom"> <name>The RPKI is forAuthorization">Authorization</name> <t>The RPKI was designed and specified to sign certificates for use within the RPKI itself and to generate Route Origin Authorizations(ROAs),(ROAs) <xreftarget="RFC6480"/>,target="RFC6480"/> for use in routing. Its design intentionally precluded use for attesting to real-world identity as, among other issues, it would expose the Certification Authority (CA) to liability.</t> <t>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 world of complexity with no proof of termination.</t> <t>Registries such as the Regional Internet Registries (RIRs) provide INR to real-world identity mapping throughWHOIS,WHOIS <xreftarget="RFC3912"/>,target="RFC3912"/> and similar services. They claim to be authoritative, at least for the INRswhichthat they allocate.</t> <t>That is, RPKI-based credentials of INRsMUST NOT<bcp14>MUST NOT</bcp14> be used to authenticate real-world documents or transactions. That might be done with some formal external authentication of authority allowing an otherwise anonymous INR holder to authenticate the particular document or transaction. Given such external, i.e. non-RPKI, verification of authority, the use of RPKI-based credentials adds no authenticity.</t> </section> <sectionanchor="discuss" title="Discussion"> <t>Theanchor="discuss"> <name>Discussion</name> <t><xref target="RFC6480" section="2.1" sectionFormat="of">the RPKI basedocument, <xref target="RFC6480"/>, Section 2.1document</xref> says explicitly "An important property of this PKI is that certificates do not attest to the identity of the subject."</t><t>The Template<t><xref target="RFC7382" section="3.1" sectionFormat="of">"Template for a Certification Practice Statement (CPS) for the Resource PKI(RPKI) <xref target="RFC7382"/> Section 3.1, Naming, makes very clear(RPKI)"</xref> states that"Thethe Subject name in each certificate SHOULD NOT bemeaningful;"meaningful and goes on todo soexplain this at some length.</t> <t>Normally, the INR holder does not hold the private key attesting to their resources; theCertification Authority (CA)CA does. The INR holder has a real-world business relationship with the CA for which they have likely signed real-world documents.</t> <t>As the INR holder does not have the keying material, they rely on the CA, to which they presumably present credentials, to manipulate their INRs. These credentials may beuserid/passworduser ID and password (withtwo factortwo-factor authentication one hopes), a hardware token, client browser certificates, etc.</t> <t>Hence schemes such as Resource Tagged Attestations <xref target="I-D.ietf-sidrops-rpki-rta"/> and Signed Checklists <xref target="I-D.ietf-sidrops-rpki-rsc"/> must go to great lengths to extract the supposedly relevant keys from the CA.</t> <t>For some particular INR,saysay, Bill's Bait and Sushi's Autonomous System (AS) number, someone out on the net probably has the credentials to the CA account in which BB&S's INRs are registered. That could be the owner of BB&S,Roberto'sRandy's Taco Stand, an IT vendor, or the Government of Elbonia. One simply can not know.</t> <t>In large organizations, INR management is often compartmentalized with no authority over anything beyond dealing with INR registration. The INR manager for Bill's Bait and Sushi is unlikely to be authorized to conduct bank transactions for BB&S, or even to authorize access to BB&S's servers in some colocation facility.</t> <t>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 Elbonia tomorrow. Or the resource could have been administratively 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 document is still valid?</t> <t>While Ghostbuster Records <xref target="RFC6493"/> may seem to identify real-world entities, their semantic content is completelyarbitrary,arbitrary and does not attest to holding of any INRs. They are merely clues for operational support contact in case of technical RPKI problems.</t> <t>Usually, before registering INRs, CAs require proof of an INR holding via external documentation and authorities. It is somewhat droll that the CPSTemplate,Template <xreftarget="RFC7382"/>,target="RFC7382"/> does not mention any diligence the CA must, or even might, conduct to assure the INRs are in fact owned by a registrant.</t> <t>That someone can provide 'proof of possession' of the private key signing over a particular INR should not be taken to imply that they are a valid legal representative of the organization in possession of that INR. They could bejustin an INR administrativeperson.</t>role, and not be a formal representative of the organization.</t> <t>Autonomous System Numbers do not identify real-world entities. They are identifiers some network operators 'own' and are only used for loop detection in routing. They have no inherent semantics other than uniqueness.</t> </section> <sectionanchor="security" title="Security Considerations">anchor="security"> <name>Security Considerations</name> <t>Attempts to use RPKI data to authenticate real-world documents or other artifacts requiring identity, while possibly cryptographically valid within the RPKI, are misleading as to any authenticity.</t> <t>When a document is signed with the private key associated with an RPKI certificate, the signer is speaking for theINRs, theINRs (the IP address space andAutonomous System (AS) numbers,AS numbers) in the certificate. This is not an identity; this is an authorization. In schemes such as Resource Tagged Attestations <xref target="I-D.ietf-sidrops-rpki-rta"/> and Signed Checklists <xreftarget="I-D.ietf-sidrops-rpki-rsc"/>target="I-D.ietf-sidrops-rpki-rsc"/>, 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 signature is valid, the message content comes from a party that is authorized to speak for that subset of INRs.</t> <t>Control of INRs for an entity could be used to falsely authorize transactions or documents for which the INR manager has no authority.</t><!-- <t>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.</t> --></section> <sectionanchor="iana" title="IANA Considerations">anchor="iana"> <name>IANA Considerations</name> <t>This document has no IANAConsiderations.</t>actions.</t> </section> </middle> <back> <displayreference target="I-D.ietf-sidrops-rpki-rsc" to="RPKI-RSC"/> <displayreference target="I-D.ietf-sidrops-rpki-rta" to="RPKI-RTA"/> <displayreference target="I-D.ietf-sidrops-aspa-profile" to="ASPA-PROFILE"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7382.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8635.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3912.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6493.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sidrops-rpki-rsc.xml"/> <!--<t>Note[I-D.ietf-sidrops-rpki-rta] IESG state Expired. Full ref in order toRFC Editor: this section may be replaced on publication as an RFC.</t>correct initials. --></section><reference anchor="I-D.ietf-sidrops-rpki-rta"> <front> <title>A profile for Resource Tagged Attestations (RTAs)</title> <author initials="G." surname="Michaelson" fullname="George G. Michaelson"> <organization>Asia Pacific Network Information Centre</organization> </author> <author initials="G." surname="Huston" fullname="Geoff Huston"> <organization>Asia Pacific Network Information Centre</organization> </author> <author initials="T." surname="Harrison" fullname="Tom Harrison"> <organization>Asia Pacific Network Information Centre</organization> </author> <author initials="T." surname="Bruijnzeels" fullname="Tim Bruijnzeels"> <organization>NLNet Labs B.V.</organization> </author> <author initials="M." surname="Hoffmann" fullname="Martin Hoffmann"> <organization>NLNet Labs B.V.</organization> </author> <date month="January" day="21" year="2021" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-sidrops-rpki-rta-00" /> </reference> <!-- [I-D.ietf-sidrops-aspa-profile] IESG state I-D Exists --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sidrops-aspa-profile.xml"/> </references> </references> <section anchor="acks"title="Acknowledgments">numbered="false"> <name>Acknowledgments</name> <t>The authors thankGeorge Michaelson and Job Snijders<contact fullname="George Michaelson"/> and <contact fullname="Job Snijders"/> for lively discussion,Geoff Huston<contact fullname="Geoff Huston"/> for some more formal text,Ties<contact fullname="Ties deKockKock"/> for useful suggestions, many directorate and IESG reviewers, and last but not least, Biff for the loan of Bill's Bait and Sushi.</t> </section></middle> <back> <references title="Normative References"> <?rfc include="reference.RFC.2119.xml"?> <?rfc include="reference.RFC.5280.xml"?> <?rfc include="reference.RFC.6480.xml"?> <?rfc include="reference.RFC.7382.xml"?> <?rfc include="reference.RFC.8174.xml"?> <?rfc include="reference.RFC.8635.xml"?> </references> <references title="Informative References"> <?rfc include="reference.RFC.3912.xml"?> <?rfc include="reference.RFC.6493.xml"?> <?rfc include="reference.I-D.ietf-sidrops-rpki-rsc.xml"?> <?rfc include="reference.I-D.ietf-sidrops-rpki-rta.xml"?> <?rfc include="reference.I-D.ietf-sidrops-aspa-profile.xml"?> </references></back> </rfc>