summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9255.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9255.txt')
-rw-r--r--doc/rfc/rfc9255.txt317
1 files changed, 317 insertions, 0 deletions
diff --git a/doc/rfc/rfc9255.txt b/doc/rfc/rfc9255.txt
new file mode 100644
index 0000000..d63a2cd
--- /dev/null
+++ b/doc/rfc/rfc9255.txt
@@ -0,0 +1,317 @@
+
+
+
+
+Internet Engineering Task Force (IETF) R. Bush
+Request for Comments: 9255 Arrcus & IIJ Research
+Category: Standards Track R. Housley
+ISSN: 2070-1721 Vigil Security
+ June 2022
+
+
+ The 'I' in RPKI Does Not Stand for Identity
+
+Abstract
+
+ 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.
+
+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
+ https://www.rfc-editor.org/info/rfc9255.
+
+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
+ (https://trustee.ietf.org/license-info) 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
+
+ 1. Introduction
+ 1.1. Requirements Language
+ 2. The RPKI is for Authorization
+ 3. Discussion
+ 4. Security Considerations
+ 5. IANA Considerations
+ 6. References
+ 6.1. Normative References
+ 6.2. Informative References
+ Acknowledgments
+ Authors' Addresses
+
+1. Introduction
+
+ The Resource Public Key Infrastructure (RPKI), see [RFC6480],
+ "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 [RFC8635].
+
+ In security terms, the phrase "Public Key" implies there is also a
+ corresponding private key [RFC5280]. 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
+ Section 2.1 of [RFC6480].
+
+ 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 [ASPA-PROFILE].
+
+ 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.
+
+1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. The RPKI is for Authorization
+
+ The RPKI was designed and specified to sign certificates for use
+ within the RPKI itself and to generate Route Origin Authorizations
+ (ROAs) [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.
+
+ 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 [RFC3912] 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.
+
+3. Discussion
+
+ Section 2.1 of the RPKI base document [RFC6480] says explicitly "An
+ important property of this PKI is that certificates do not attest to
+ the identity of the subject."
+
+ Section 3.1 of "Template for a Certification Practice Statement (CPS)
+ for the Resource PKI (RPKI)" [RFC7382] 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 [RPKI-RTA] and
+ Signed Checklists [RPKI-RSC] 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 [RFC6493] 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 [RFC7382] 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.
+
+4. Security Considerations
+
+ 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.
+
+ 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 [RPKI-RTA] and Signed Checklists [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.
+
+ Control of INRs for an entity could be used to falsely authorize
+ transactions or documents for which the INR manager has no authority.
+
+5. IANA Considerations
+
+ This document has no IANA actions.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+ <https://www.rfc-editor.org/info/rfc5280>.
+
+ [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
+ Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
+ February 2012, <https://www.rfc-editor.org/info/rfc6480>.
+
+ [RFC7382] Kent, S., Kong, D., and K. Seo, "Template for a
+ Certification Practice Statement (CPS) for the Resource
+ PKI (RPKI)", BCP 173, RFC 7382, DOI 10.17487/RFC7382,
+ April 2015, <https://www.rfc-editor.org/info/rfc7382>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for
+ BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019,
+ <https://www.rfc-editor.org/info/rfc8635>.
+
+6.2. Informative References
+
+ [ASPA-PROFILE]
+ Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J.,
+ and R. Housley, "A Profile for Autonomous System Provider
+ Authorization", Work in Progress, Internet-Draft, draft-
+ ietf-sidrops-aspa-profile-07, 31 January 2022,
+ <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
+ aspa-profile-07>.
+
+ [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)
+ Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
+ February 2012, <https://www.rfc-editor.org/info/rfc6493>.
+
+ [RPKI-RSC] Snijders, J., Harrison, T., and B. Maddison, "A profile
+ for Resource Public Key Infrastructure (RPKI) Signed
+ Checklists (RSC)", Work in Progress, Internet-Draft,
+ draft-ietf-sidrops-rpki-rsc-08, 26 May 2022,
+ <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
+ rpki-rsc-08>.
+
+ [RPKI-RTA] Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T.,
+ and M. Hoffmann, "A profile for Resource Tagged
+ Attestations (RTAs)", Work in Progress, Internet-Draft,
+ draft-ietf-sidrops-rpki-rta-00, 21 January 2021,
+ <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
+ rpki-rta-00>.
+
+Acknowledgments
+
+ The authors thank George Michaelson and Job Snijders for lively
+ discussion, Geoff Huston for some more formal text, Ties de Kock for
+ useful suggestions, many directorate and IESG reviewers, and last but
+ not least, Biff for the loan of Bill's Bait and Sushi.
+
+Authors' Addresses
+
+ Randy Bush
+ Arrcus & Internet Initiative Japan Research
+ 5147 Crystal Springs
+ Bainbridge Island, WA 98110
+ United States of America
+ Email: randy@psg.com
+
+
+ Russ Housley
+ Vigil Security, LLC
+ 516 Dranesville Road
+ Herndon, VA 20170
+ United States of America
+ Email: housley@vigilsec.com