The 'I' in RPKI Does Not Stand for IdentityArrcus & Internet Initiative Japan Research5147 Crystal SpringsBainbridge IslandWA98110United States of Americarandy@psg.comVigil Security, LLC516 Dranesville RoadHerndonVA20170United States of Americahousley@vigilsec.com
ops
sidropsPublic Key InfrastructureSecurityX.509CertificateThere 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.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Requirements Language
. The RPKI is for Authorization
. Discussion
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
IntroductionThe Resource Public Key Infrastructure (RPKI), see , "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., Router Keying for BGPsec .In security terms, the phrase "Public Key" implies there is also
a corresponding private key . The RPKI
provides strong authority to the current holder of INRs; however,
some people have 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. But, 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 in .It has been suggested that one could authenticate real-world
business transactions with the signatures of INR holders. 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.The '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 the real-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 as Autonomous System Provider Authorization (ASPA) records.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 of an RPKI private key holder.Requirements Language
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 when, and only when, they appear in all capitals, as
shown here.
The RPKI is for AuthorizationThe RPKI was designed and specified to sign certificates for use
within the RPKI itself and to generate Route Origin Authorizations
(ROAs) 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.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.Registries such as the Regional Internet Registries (RIRs)
provide INR to real-world identity mapping through WHOIS and similar services. They claim to be
authoritative, at least for the INRs that they allocate.That is, RPKI-based credentials of INRs MUST NOT 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.Discussionthe RPKI base document says explicitly "An important property of this PKI is that
certificates do not attest to the identity of the subject.""Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)" states that
the Subject name in each certificate SHOULD NOT be meaningful
and goes on to explain this at some length.Normally, the INR holder does not hold the private key attesting
to their resources; the CA does. The INR
holder has a real-world business relationship with the CA for which
they have likely signed real-world documents.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 be user ID and password (with two-factor
authentication one hopes), a hardware token, client browser
certificates, etc.Hence schemes such as Resource Tagged Attestations
and Signed Checklists must go to great
lengths to extract the supposedly relevant keys from the CA.For some particular INR, say, 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, Randy's Taco
Stand, an IT vendor, or the Government of Elbonia. One simply can
not know.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.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?While Ghostbuster Records may seem to
identify real-world entities, their semantic content is completely
arbitrary and does not attest to holding of any INRs. They are
merely clues for operational support contact in case of technical
RPKI problems.Usually, before registering INRs, CAs require proof of an INR
holding via external documentation and authorities. It is somewhat
droll that the CPS Template does not
mention any diligence the CA must, or even might, conduct to assure
the INRs are in fact owned by a registrant.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 be in an INR administrative role, and not be a formal
representative of the organization.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.Security ConsiderationsAttempts 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.When a document is signed with the private key associated with an
RPKI certificate, the signer is speaking for the INRs (the IP address
space and AS numbers) in the certificate. This is not an identity; this
is an authorization. In schemes such as Resource Tagged Attestations
and Signed Checklists , 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.Control of INRs for an entity could be used to falsely authorize
transactions or documents for which the INR manager has no
authority.IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]An Infrastructure to Support Secure Internet RoutingThis document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)This document contains a template to be used for creating a Certification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Router Keying for BGPsecBGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.Informative ReferencesA Profile for Autonomous System Provider AuthorizationYandexJetLendInternet Initiative JapanArrcus, Inc.FastlyVigil Security, LLC This document defines a standard profile for Autonomous System
Provider Authorization in the Resource Public Key Infrastructure. An
Autonomous System Provider Authorization is a digitally signed object
that provides a means of validating that a Customer Autonomous System
holder has authorized members of Provider set to be its upstream
providers and for the Providers to send prefixes received from the
Customer Autonomous System in all directions including providers and
peers.
Work in ProgressWHOIS Protocol SpecificationThis document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK]The Resource Public Key Infrastructure (RPKI) Ghostbusters RecordIn the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK]A profile for Resource Public Key Infrastructure (RPKI) Signed Checklists (RSC)FastlyAsia Pacific Network Information CentreWorkonline Communications This document defines a Cryptographic Message Syntax (CMS) profile
for a general purpose listing of checksums (a 'checklist'), for use
with the Resource Public Key Infrastructure (RPKI). The objective is
to allow an attestation, in the form of a listing of one or more
checksums of arbitrary digital objects (files), to be signed "with
resources", and for validation to provide a means to confirm a
specific Internet Resource Holder produced the Signed Checklist. The
profile is intended to provide for the signing of an arbitrary
checksum listing with a specific set of Internet Number Resources.
Work in ProgressA profile for Resource Tagged Attestations (RTAs)Asia Pacific Network Information CentreAsia Pacific Network Information CentreAsia Pacific Network Information CentreNLNet Labs B.V.NLNet Labs B.V.Work in ProgressAcknowledgmentsThe authors thank and for lively
discussion, for some more formal text, for
useful suggestions, many directorate and IESG reviewers, and last
but not least, Biff for the loan of Bill's Bait and Sushi.Authors' AddressesArrcus & Internet Initiative Japan Research5147 Crystal SpringsBainbridge IslandWA98110United States of Americarandy@psg.comVigil Security, LLC516 Dranesville RoadHerndonVA20170United States of Americahousley@vigilsec.com